The last month has involved the holidays, and accordingly I kind of slowed down on the game and didn’t develop all of that much (too busy with other things to really get into the project). I did work on quite a few things leading up to Christmas which I’ll cover here, but the ultimate take away from this post is that I have been slacking for the past month, and hope to get back into the groove now.

Following last post, the first thing I did was add a PlatformType enum to the project. This enumeration is passed from the launcher of each platform and is maintained by the games singleton, and this can then be used by any game object to perform platform specific functionality wherever I decide that some feature needs to behave differently between platforms. This was handy, as I’m really hoping for this game to ultimately be released on the Google Play Store, and for that to happen the Android platform has to perform well. At last post, even though the Desktop and HTML versions looked and performed well, the Android version did not as it was attempting to layout the board the same way as the other versions.

So, following the addition of this PlatformType enum, I set about designing and implementing a better game layout for mobile (Android) devices. I played around with portrait vs landscape modes, and found that there wasn’t really a good layout in landscape mode that allowed for the cards to be big enough to be easily readable and interactable with touch controls, and also not so big that they would go off the bottom of the screen when in the largest possible column. I hadn’t expected a portrait layout to be the best option, but it seems to have all the desired properties, and is quite user intuitive. With this in mind, I drew out a game board layout on paper, and implemented it in the game. Again, this is only for the Android version of the game, the other versions don’t lay out like this at all.

As you can see I also added some backgrounds to the mobile version. I had a Christmas asset pack that had a lot of nice background images on hand, and it was December, so I made all the backgrounds Christmas themed for the time being (these are just engineering assets for now though, they’ll be changed to something else for the final release).

Since the mobile layout now seemed functional and responsive, I felt it was time to start adding other UI elements to it. I started by adding a row of buttons at the bottom of the screen. These will be the users primary access to features of the game outside of gameplay, such as starting a new game, modifying settings, undoing moves, and exiting the application. I picked a set of green square buttons from an asset pack. These also look fairly Christmas like, but will likely be replaced before final release.

I created a special class for these that overrode the scene2d Actor class, and added common functionality where the button will shift down a percentage of it’s height when pressed. I also added a hook for a ‘TouchUp’ listener, so that when the button is released it will return back to it’s original position, and then it will perform button specific functionality. Adding functionality for the undo button was easy enough, as undo funcionality was already built into the game, so I just had to tie that to the buttons response. For new game functionality, I wanted to give the user a choice when the new game button was selected. I felt that they should be able to either start a completely new game, or they should be able to reset the existing game back to it’s original state, and try it again.

Reseting the game was very easy from a gameplay standpoint, as I had previously built in a deck sort feature, and designed the shuffle feature so that it was dependent on a seed. So to reset the game we just move all cards back into the deck, sort the deck back into it’s default state, and then reset the deck’s shuffle random object back to the same seed that we used for the last match, and then shuffle as normal. The difficult part to this was giving the user the choice in the UI, as I felt that there needed to be a pop up dialog that presented this option to the user. By extending the scene2d Dialog class however, I was able to build a generic dialog that I could customize for this feature set. I wanted to make this dialog first, as most of the other buttons in the game will also need dialogs, and they should all behave generally the same way, but have their own options/elements.

You may notice the “Moves” and “Timer” trackers at the top of the screen. In my mind, the number of moves the player has made in order to win, the time it took to do so, and the game’s seed are the primary gameplay metrics that can be “tracked” with this game. The moves counter is just an integer counter that counts up every time a valid move is made, counts down when an undo operation is successfully performed, and is reset when the game resets. The timer is also reset when the game resets, and it does not start incrementing until the player has successfully made their first move. The timer will also pause if any of the dialogs are open (as the game doesn’t allow any moves to be made at this time).

Finally, I was having some issues with some low level calls across the various platforms of the game. Namely, in order to get the appliction to exit properly on mobile (actually dereference all sprite batches, not just keep everything open but go into the background), I had to add some low level exit calls. However, the GWT cross compiler did not know how to respond to these calls at compilation time, and would break during build. Even though we would never call these calls during an HTML play of the game, all of the code is still in the core library, so it does all have to be compiled together. Around this time I was also feeling that I was spending too much time worrying about cross compilation when I’m primarily targeting Android at this stage of the project. With that in mind, I removed the HTML5 project from the build list that gradle references during a build. All of the HTML specific code is still there, but it’s ignored entirely during compilation.

I’ve certainly been a bit lazier (or busier) then normal over the past couple of weeks, and I wish I had been able to maintain more forward progress on this project. However I feel like I’m getting back in the saddle, and I hope to make more progress in the coming weeks.