Project Goals

The goal of this project was to aim high and get in as many features and as much polish as possible before an interview, where I would pass a link to this game to showcase my passion for developing games and my determination to learning for the job. It's been a week since I started and I've learnt a lot in this time, lost a few hairs in the process but that's fine because I didn't have many to begin with. I'll go over the project scope and how far into this goal I actually got.

Minimum Viable Product (MVP)

A typical MyFirstSlotMachine simple spin to win with basic sound and that's all it does, runs on Desktop. To get exposure to Java 2D game development and lay down a foundation of understanding to build upon.

Maximum Scope

All the features, all the polish! A clone of Greentube's 5 Line Hold & Spin (5LHS) but without the bonus round, great graphics, sound, and overall an enjoyable game that runs on Desktop, Android, and HTML. To get exposure to Java 2D game development and cross-platform development, and start building upon a basic foundation to bring my Java skills up to par with my C++ skills.

How I Did

Fruit Machine is a 3 reel fruits slot machine game with 10 icons and 5 win lines. It features Wilds that can act as any of the 9 fruit icons to give the player more wins, Wilds give the biggest payout and when the player doesn't win each new Wild on screen give the player a Hold. Holds can be used as currency to hold a reel in place, giving the player more control over the game, the player can't use Holds directly after a win.

I'm really happy with this feature set, I far supassed the MVP and instead of cloning 5LHS (because I'm poor and didn't want to spend money to playtest 5LHS's features) I designed some of my own features for the Wilds and Holds. It would have been nice to add more complexity with a bonus round but that would have went beyond the maximum scope I set.

It has good visuals and sound, it's not the best and there are clearly areas where it could improve upon but I think I did well to find some good assets and edit them to work nicely in the game. It's also pretty fun to play, especially with the flashing light strip that's syncronised to the sound effects! Seeing the lights dance around is one of my favourite parts of this game, it gives a nostalgic feel of playing on a bandit at the arcades or a pub. It would have been nice to add in better feedback for a win like 5LHS has with the cool animations, but unfortunately I'd need an artist to get that and it'd take some careful balancing to make it compliment the flashing lights rather than take attention away from them.

I managed to develop and release the game on Desktop, Android, and HTML! There were some tricky hurdles to jump over to get this to work but I'm really glad it does! It feels so great to be able to pass the game to my friends and it just works... Although the feedback I've received about my winning line indicators hasn't been so pleasant "What are those? It's like spaghetti splodged on the screen". There's also a few bugs and issues that appear only on HTML or Android that need polishing. Nevertheless I actually developed a game for 3 platforms, huge milestone in my development career!

I'm very happy with the progress I've made and how the project turned out! I've discussed a bit about what went right and what I'm proud of, now let's talk about the speed bumps I ran over at 80mph.

What Went Wrong?

EVERYTHING! Haha but seriously there were a few "minor" inconveniences, which is to be expected when switching to a new language using a new library and trying to release on multiple platforms, 3 firsts in 1! Let's discuss each one and how I'll never be the same again after going through such traumatising events.

Finding Assets

The asset pack I picked didn’t have it’s text as a font, so I had to manually edit pngs to make words which I then have to put on top of ui boxes to make any main menu buttons I want. I’ve had to customise a lot of my assets for them to work. This was a big issue throughout the entire process and it usually is when you don't have the means to create the assets yourself, every asset I use had to be tweaked in some way or another to work in my game how I intend it. A pain sure, but I'm kind of used to that by now after a lot of small solo projects and prototypes.

There's no such thing as a free asset.

Frame Buffer For Drawing Reels Off-Screen

This ate almost a whole day. I'm used to rendering things off screen and then drawing that whole render onto the screen, it's pretty standard stuff especially with UI. I thought rendering the reels off screen and then only drawing a 3 icon segment onto the reel would be an easy thing. I was wrong. LibGDX uses OpenGL frame buffers for off screen drawing, which is probably fine for serious libGDX users but for someone who's new to Java, libGDX, and OpenGL I had no idea what was going on. It's like the OpenGL rendering used completely different units and I had no way of figuring out how to normalise them between libGDX and OpenGL, no matter how many different stack exchange solutions I tried it just didn't work.

This one defeated me, I had to scrap off screen drawing altogether and render the reel icons directly onto the screen. However because up to 4 icons can be visible on the 3 spaces for reel icons at any one time while spinning, I had excess drawing coming out of the top and bottom of the reel UI. I had to redraw parts of the background over the top and bottom to hackily hide the rapidly moving icons, it's a mess but typical for game development, slap something on top of it and call it fixed.

Text, Fonts, And How Much HTML Hates Them

I had my game working but it wasn't displaying any information to the player, so if I passed it to someone for a blind playtest they'd be able to assume things but not understand a lot, it needed some text besides my mishap of a title. At first I tried bitmapfonts in libGDX, sure it'd display some text but it was set at a specific font size with no way to increase it, so if you scaled it up it looked truly horrendous. I scoured the internet to find how to use custom fonts in libGDX, and I found it...

LibGDX Freetype. Alas, all my worries were gone, no more would a lack of custom text plague this game!

./gradlew html:superDev 

... Why won't the web version work? What do you mean HTML doesn't support Freetype?!

And we were back to square one.

So what did I decide to do? What any good developer does when prototyping (and sometimes even not when prototyping), bodge it in! I found a casino font online, opened up Aseprite, and added text to .pngs which I could then draw as textures. Viola! Now we have text! I do have to go through a slow and painful process of manually editing images, but at least it works! The players won't notice a difference anyway.

Textures Come In Specific Shapes And Sizes

So now I've tested HTML and got that working, it's time to test Android! Another crash straight off the bat, that's what we love to see! I had no idea that all the texture editing prowess I'd built up these past few days was about to be even more useful. So it turns out Android will only accept textures that come in sizes of the power of 2, so your 64s, 128s, 256s, and beyond.

Suddenly I'm burdened with the task of going through all my images and collecting them into groups of similar images, recording the positions and sizes of every one, putting all that into the game and making it render things nicely again. After the frame buffer and text, this actually wasn't so bad. Tedious yes, but the previous issues have steeled my resolve. I will get this game to ship on 3 platforms no matter what!

What Did I Learn?

I still have a burning love hate relationship for developing games. Running head first through wall after wall keeps things interesting, the constant problems that arise due to assumptions, having to solve all of these problems one by one in an endless onslaught is what I live for! I love programming and I love developing, becuase I love solving the many varied tiny massive problems that come with trying to do pretty much anything.

It's about learning the dos and donts of your language, your libraries, your tools. It's about learning how everything operates so that the next project I develop goes smoother, easier, and becomes a more pleasantly productive experience. I'm happy I hit so many problems because each one I come across is another learning opportunity, another thing that is going to make me a better developer than I was yesterday.

I learnt how to make a simple 2D game in Java using libGDX and publish it for Desktop, Android, HTML.

What Would I Do Differntly?

Mostly code related things, also I haven't eaten in a while so I should wrap this up, here's a quick list:

1. I would create utility classes that inherit from libGDX classes, so I could overload certain methods to make the code more readable. For example: Sprite’s setPosition doesn’t take a Vector2, so I have to store a local Vector2 and pass it’s x and y into the method, in an overload I could pass in the Vector2 and it could call setPosition again using the x and y components but all we'd see is it takes a Vector2. It’s a small change but there are a few methods like this in libGDX (setting texture regions look messy as well) so overloading them would cleanup the code making it look nicer and easier to read.
   
   

1. I would refactor all my hard coded values into variables that calculate the positions using a variety of different Vector2 size variables, general code cleanup to make it easier to both read and modify for maintainability. I haven't done rapid prototyping where function comes before maintainability in a while, so there's probably a few more readability pet peeves I have that could be listed here. I like a nice readable, maintainable project.
   
   

2. I would add more features to the game like a bonus round, better player feedback, more moving parts to the game to make it feel more energetic. Or maybe some dramatic pauses while a sound effect plays, to make wins and losses feel more impactful. All things that are typically done after a prototype anyway.
   
   

3. I would ensure all 3 platforms run nicely before releasing the game to anyone (looking at you Android sound bug!). Obviously I had a deadline for this so I had to just show whatever I had by the interview, but in an ideal world I'd fix a couple bugs or slight things I'm not happy with so it's running beautifully across all 3 platforms.

It was one hell of a week developing and I look forward to the many more to come!

Thank you for reading!