Haunted Light – Button class

This time I’ll be talking about a simple Button-class that I created this weak and the planning involved around it.

When I was thinking this through and listing everything I needed for the class to do what we want it to do, I planned it to be unnecessarily complicated. How I planned it was that it would be very similar to SFML’s own Sprite class. By creating 4 points, or verticies, they dictate the buttons size and then we could apply a texture on that surface, or alternately giving it a background color. More or less making it a lightweight version of the Sprite class.

But after a while I realized that it didn’t need to have that many different variables and methods that I had planned for it. I didn’t even need to use the verticies system that I planned on using, since all of our buttons are sprites. After that realization how I had planned the class to work and what it would contain looked like an oversized garbage can. All I could do was throw it away and start all over with the planning phase.

This time over the button would be heavily dependent on the sprite rather than the other way around. The class was originally planned to contain 7 methods that impact the buttons looks and/or behavior:
-One to set the position of the button(setPosition)
-One to set it’s size(setSize)
-One to assign a texture to it(setTexture)
-One to add a text to the button(addText)
-One to give it a color, if no texture was going to be assigned to it(setColor)
-One to update the button, to check for collision(Update)
-And the last one to check if the button had been pressed(isClicked)

After the redesign that number shrank down to 3 methods:
-The first one to update the button(Update)
-The second one to draw the button on the screen(Draw)
-And the third one to check if the button had been pressed(isClicked)

The method that sets the buttons position isn’t needed since that is done in the classes constructor. The buttons size is determined by the size of the sprite, rather than the other way around. No need to assign a texture to the button, since it’s already a sprite. There need to add any text to the button coding wise since the buttons sprites already contain the text they’re surposed to have. And no need to give the button a background color, since it is basically a sprite.

The only two methods that survived the redesign were the Update method and the isClicked method. The Update method was in no risk of getting cut from the list since it handles and checks for collision between the mouse pointer and the button, which is crucial for any button to work. I kept the isClicked method for exactly the same reason. A new method was added to the list, the Draw method. And it does exactly what you might think, it draws the button on the screen. Or well, it tells the the window that’s being sent into the method to draw the sprite.

There are 3 more methods in the class, but they are methods that are only used for getting the position/dimensions/sprite of the button, and in no way do they actually affect the button since all they do is hand out some data about the button.

Next on the list for me would probably be creating a manager for the buttons.

Regards
Calle Johansson, Gamedesign and Programming