Controls:

Move: Arrow Keys,  Run: Space Bar (if you have enough stamina),  Pause: Escape

** Unfortunately there is a bug with FMOD Audio in WebGL, so the volume control won't work in the web version **

Treasure Gobblin' Dev Blog

Overview of Game and Motivation Behind Development

Treasure Gobblin' is an endless arcade-style game developed by three people. I (Kyle Welfare) did the programming in Unity/C#, the art was done by Scott Welfare, and the music was made by Brandyn Campbell.

It is a game in which you are tasked with collecting as much gold as possible before being overrun by enemies and/or the constant laser fire from the tower. As game time progresses, enemy spawn rates increase steadily, and death is inevitable.

Our inspiration for building this game was primarily educational. It was not developed with the intention of ever publishing, but served a dual purpose of allowing us to learn a variety of new skills relating to game development, and to act as a completed project for our respective portfolios. By keeping the scope small, we knew it would be achievable, and would allow us to polish it to a level we were happy with. For our initial idea, we looked through some past themes of Ludum Dare game jams (a popular annual game jam competition) and decided on two themes as the basis of our game: 'The Tower' and 'Entire Game on One Screen'.

As the idea developed, we settled on this reversal of roles, where the player character is the 'bad guy' and the enemies are the typical 'heroes' which would normally be controlled by the player. If you have ever played Diablo, this scenario of beating the gold out of a goblin may be familiar!

Programming Points of Interest and Learning Points

We treated this project almost as a casual game jam. We wanted to keep the scope small, but without the strict time constraint that a typical game jam would have. As a result, while the game was developed over a few months, it was almost fully coded in a few long coding sessions. I used the time to plan out exactly how I wanted to implement each feature, and to write efficient and clean code. A variety of challenges presented themselves, and acted as great learning opportunities for me as both a game designer and an object-oriented programmer.

The first of these opportunities was the use of an object pooling system for various reusable assets in the game. For those who are unfamiliar with object pooling in the context of game development, it is the process of reusing game objects through activation/deactivation. Constantly instantiating and destroying objects takes a toll on performance over long game sessions. Through object pooling, we only ever need to instantiate the maximum amount of objects that will be on screen at any given time. Realistically for this game, performance demands are very low, and unless the player is on Windows 98, they likely won't experience any slow-down. However, it was a great chance to get some practice in implementing this concept. Some examples of where this technique may be very useful would be projectiles in a bullet-hell game or waves of enemies in a tower defense.

In our game, both enemies and the coins they dropped are pooled for reuse. The object pooling system I used was the one in this video by One Wheel Studio, modified for my needs. By using a Dictionary to store GameObjects with string keys, I was able to create a dynamic object pooling system that could account for any objects I may want to pool. The size of the pool is dynamic as well, and will grow as necessary when more game objects are required on screen at once. It uses a Queue, a first-in first-out System to manage the activation and deactivation of GameObjects. This also presents the opportunity to have some code execute on both activation and deactivation of a pooled object, such as spawning a gold coin when an enemy dies.

One topic I spent a lot of time researching and playing with was the concept of timing within Unity. Treasure Gobblin' relies heavily on consistent timing for almost all aspects of the gameplay, from laser shots, to enemy spawns and stamina regeneration. There are numerous ways to implement timed events in Unity, and I focused on the three most common methods: Coroutines, countdowns using Update(), and Invoke(). I used a mixture of these methods to achieve the gameplay loop of Treasure Gobblin' in order to get practice with each. In a commercial product, it would likely be wise to remain consistent with a single method for all timed events in a game. Most Unity documentation recommends the use of Coroutines, however many game developers warn about the dangers of using Coroutines due mainly to instability and complication of code. By using manual float counters in Update(), the code will be much less prone to bugs, but your timers become frame-dependent. In a game like this, users experiencing slow-down is very unlikely, so this is likely the best method for my game.

In game design, sometimes we are forced to trick the player for their own good. While it seems dishonest, we as the game designer (should) know best. One situation in which this may be appropriate is the concept of apparent randomness. For example, when the laser fires in Treasure Gobblin', a series of explosions detonate in the blast area. While the explosions likely appear random, each was hand-placed by me in an attempt to simulate randomness. I could have just as easily made the locations of each explosion randomized each time, but this would have resulted in lopsided and unappealing explosion patterns, at least some of the time. If I planned on continuing development of this game, I would likely introduce quasi-randomness, in which explosions could not spawn within a certain surrounding area of the previous explosion.

These are just a few of the areas in which I used this small game project to learn and experiment, and ultimately become a better programmer.

Potential Future Changes and Progression

As development of Treasure Gobblin' progressed, more and more I felt that something was missing. Each time I got a feature working and tested it, I felt like there was a looming problem: the game wasn't very fun. Despite everything functioning as intended, the gameplay was lacking. Unfortunately with games, especially when deciding on a concept in a 'game jam' format, sometimes there is a disconnect between the idea and the finished product.

I believe the biggest downfall of Treasure Gobblin' is the orientation of the playing area. The top wall of the stage discourages the player from ever using the top-left and top-right laser blast zones. If I were to continue develop of this game, I would likely convert the playing area into a circle, with the tower located in the center. This would provide the player freedom to use the entire stage as they wished, without feeling disadvantaged.

Beyond that, a great deal of content would need to be added, such as alternate stages and enemy types. Through inheritance, addition of new enemies would be relatively simple, as much of the code is already written. Furthermore, monetization could be introduced through character skins, new stage appearances, or revival coins.

All that being said, I think this is where my journey with Treasure Gobblin' comes to an end. I feel that I achieved what I set out for when we began planning this game. I learned many new things, and reinforced concepts that I already knew, two goals that I always strive for when programming.