22 September 2014

GRamer Society Episode 2: Behind the Episode

This time around had a lot more programming involved. And I even made 2 games for it. Here's the video:



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
With Processing, draw is a function reserved to be a loop. I specify 'noLoop' at the end of the draw function so I don't have to handle frame-rate or the fact that it would call draw whenever it can. I use the default mouseReleased function to trigger a change of game state and manually call 'loop' again, so it will trigger a redraw.

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.

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.

GRamer Society Episode 1: Behind the Episode

So I began a silly YouTube project. I'm making ridiculous/stupid games and pretending to submit them to a fictional society. Because my fictional persona wants to join the elite of the game designers. Here's the first episode:



I was able to whip out the code for "Live or Die?" in just a few minutes. It may be a little simplistic, but for this project it may be a good thing.

The meat of the program
Straightforward and simple. I'd enjoy getting into much more complex games, but for the sake of free time it's more difficult. And this way I can play advancement off as character development until these warm-up games help boost my confidence for more complex ideas.