Version Two was going to be the final version of the Cup Game, however there were some roadblocks so it will be getting a version three. During play testing of version one the following issues where noted.
There was two issues with the movement of the cups. One in theory was easy to fix and the other will require future tweaking.
The movement in version one of the game is rather simple, the cup will move forward or backwards to a set location then sideways to it's target location and back to the middle. While this was fine to get everything working it looked really funny.
The solution I decide on to fix this was to move the cups along a Bezier curve, this once working made them move along a nice half circle. The issue was the game needed to wait for the cups to stop moving before moving the next pair. Not a large issue the first version had the same requirement. The solution from the first version however wouldn't work with the new movement, and after much debugging and testing. I found I needed to fire off an event on a delayed timer after the animation had finished. If I started the next one to soon, the game hadn't update the cup locations to the new spots yet.
The movement from version one worked along 3 animations and the speed for a complete movement was spread between them, with the new animation for the cups however it was all done in one go, so additional changes to speed control were needed.
After playing version one for a bit, and getting some feedback from others we all agreed the rate at which the cups moved from turn to turn needed to change. In version one the cups started at a fixed point and got 10% faster each time you picked the correct one, resetting on failure. This made the ramp up of the early game way to slow, and the late game near imposable.
The solution I have settled on for version two, while not perfect it is a large step forward. The early game is now controled by a table, which allows for good increase in pace. Once you reach the end of the table, the game enters endless mode where it will slowly increase the speed each time you win.
Further testing of version two's movement may result in additional changes for version three, but the framework is there for fine tuning.
First off I am not an artist. I can with some time and effort however make passable art for games. If this game was going to be turned into a commercial project I'd happily of spent only the minimal amount of time to make place holders while developing the game, and hired someone else once it was completed for high quality artwork.
The main issue of the art from version one was the lack of it. The initial background didn't make it into version one as I had given up on it, and needed a break from trying. The background in version two I am quite happy with, some minor perspective issues, but otherwise usable. I spent some time redoing the coin and cups as I wasn't quite happy with how they turned out for the first version.
The addition of a main menu, and GUI required some additional artwork to be created as well, though instead of making a second background for the menu, I reused the one for the game scene.
While not individually large the new features for version two took up some time.
Version one of the game didn't really need a main menu, if I had added one it only would of had 1 button saying play. Version two added a new muted mode by popular demand, and no music on the menu screen.
Creating the code for the menu was a breeze, most of the time was spent making the buttons for the two play modes, and the one for the high score table coming in version 3.
Not much to say about this, it is just a game mode that doesn't play any sounds.
Creating this was fairly painless, just needed a minor API search for how to pass data from one scene to the next. I had initially slated an options screen so people could mute the elements individually, but due to time constraints that has been moved to version 3.
Making a proper GUI seemed simple enough, but I ran into a few minor issues. I wanted the GUI to be moved out of the game scene for separation of code. Easy enough, a quick look at the API informed me what functions I needed to overlay the GUI scene onto the game. Another quick API dive to figure out how to pass the initial game state data the scene needed.
Then the issues, at the end of each round I needed to update the GUI with information from the game state. Looking at my options at that point, I could move the GUI code back into the game scene, I could make a game wide variable to store the current state of the game, or I could use events. I first tried events and following the tutorials I could find on using them, they weren't working. At this point I looked over the first two options and decided that I only wanted to use them as a last ditch effort. So I made a post on a dev forum with my issue and went to bed.
The next day I woke up to some wonderful news, silly me had been using the scene wide event emitter, what I needed to use was the game wide emitter, which was tucked away under a different section. After some minor tweaks to my events I was up and running again passing data to the GUI scene and back to the game.
If you want to check out the second version CLICK HERE.