Dev Update #9 – Cheating from the Start

Since Game Tower is a game that essentially consists of UI more than anything else, I decided that to be a good place to start. So my first task will be creating the main menu and ingame UI.

This also will allow me to add in another feature early on that I consider vital: Cheating!
But first things first.

Following the Game Design Document
That is the mockup graphic from my design document of what I pictured the main game screen to look like.  Careful, cover your eyes, coder art incoming!

Creating the UI elements around the borders of the screen was very fast and easy. The new UI system in Unity is as easy to use as expected, and everything seems already pretty well documented. I spend about $20 on a button library from the asset store, so that I wouldn’t have to paint any buttons myself. That would cost me hours, so that price was a steal.

I created the main screen, which will eventually show all the floors of the tower, and a menu screen (the buttons don’t lead anywhere yet) that can be opened via the menu button in the main screen.

Include cheat features from the start
You might have noticed the shiny purple Debug button in the lower right corner of the menu. This button opens a debug screen where I can put all my development cheat buttons. Currently that is just a blank screen, but it will eventually contain buttons that give me more money, unlock all floors or turn on log output and the like.

I don’t need to make a case explaining why such little cheat helpers are needed during development, I suppose (and hope). I can however make a case that it pays off putting it into a nice menu.

Traditional coder cheat hacks get forgotten
Traditionally, when coders need a quick cheat to get something ingame, they will simply bind it to a key: Press the asterisk on the NumPad to get unlimited ammo. Press F8 to teleport to the last checkpoint. Press ~ to enable the log output. You get the idea.

The problem with these little hacks is that they are usually implemented all over the place inside the code base. When it is time to release the game, you need to comb through your code and remove all those little extra lines and hope that you don’t forget one!

Since they are also usually undocumented, other members of your team will probably not know about them. They might hit the keys by accident, or reimplement the same hack in a different place in the code and bound to a different key.

This not only leads to messy code in some places, it also increases the danger of shipping with this debug functionality enabled.

If one of your team members leaves, you won’t know which hacks you will have to remove. And if you yourself take a break in development and return to it a few weeks later, you can only hope that you remember all of your own hacks.

Put debug features into a UI
Putting your debug hacks into a nice UI will take a little bit of time once, to create the basic setup for it. After that, testing and debugging becomes a whole lot easier. I cannot recommend enough taking the time to add something like this.

All team members will see which hacks are available. Features won’t get implemented twice. And all access to the debug features is neatly bundled in one place, so that it can be disabled easily and safely upon shipping.

From experience I know how much time this can save – and I also know from experience how much time will be lost if there are no proper debug tools. No matter how small, all my games have proper debug UIs right from the start. And there hasn’t been a game yet where the screen stayed empty.

When my game is about to be released, I can simply disable, hide or remove that button – or even better: make it only appear if the device id matches my own test devices.

One less thing I need to worry about, which is great in a one-woman project.