Light Switch
For the previous episode, I made my life easier by rushing with C# .NET. This time around, I chose Processing. It's a language wrapped around Java that makes it easy to do visual things. The only trick to this "game" was with the images -- I used Photoshop to create a 'switchOn_img' and 'switchOff_img.'
The meat of the game |
Deathsweeper
What can I say about Deathsweeper? It's a bit more complicated than its predecessor. I actually spent most of a Friday night and Saturday morning programming this one. There are 3 game states -- I called them TILE, REVEAL, and GAMEOVER. I treat the draw and mouseReleased functions differently based on which state it's in.
TILE draw function -- all of the squares! |
Yes, yes -- absolute positioning and all. Bite me for bad practices.
TILE mouseReleased function - which tile did you click? |
That's... awkward-looking, isn't it? Loop through the x-coordinates of the squares and compare with the mouseX position. If it's within range, do the same for the y-coordinates.
REVEAL draw function -- should be straightforward |
revealedFile is the name of the text file that has the scenario's text (without the extension).
revealedText is the scenario's text (the content within the text file).
goodResult is my boolean for whether it was a good or bad result.
revealedText is the scenario's text (the content within the text file).
goodResult is my boolean for whether it was a good or bad result.
REVEAL mouseReleased function - state is success or fail |
The REVEAL state's mouseReleased event only moves back to the TILE state or forward to GAMEOVER.
GAMEOVER mouseReleased - Exit or re-initialize the game! |
The GAMEOVER draw function should be pretty self-explanatory -- just text and a rectangle. The mouseReleased checks if you click in the rectangle to exit, or it starts the game over.
Now, the tricky part of the game was loading the success/failure states.
Find all the files! |
I find all the files within the failures/successes folders and pull their file names. Then, each tile will be either a success or failure. What a tile is gets loaded as part of the initialize step:
Randomize good/bad, and choose a random good/bad result in getRandomFile |
When the state gets changed to REVEAL, that's when the content of a success/failure is loaded:
Pull the text from that file for the REVEAL draw function |
That's... just about it. I'd also made my own Tile class to store whether a tile is a good/bad result, the file name of it's revealed scenario, and whether the tile has already been revealed.
My main regret here? That Processing doesn't do Enums. It felt cheap to use a String to store the current game state -- technically could have stored it as a number, but I'm not yet at a stage where performance is an issue.
The logic for making the scenarios dynamic was actually quite fun. All things considered, it's interesting to think that I created 16 scenarios for the game when the video showcased very little.
No comments:
Post a Comment