Late console implementation

I’m sure you know a lot of games which have a console implemented one way or another. And it is not just for entering your cheat codes, it serves a higher purpose and that’s to make developer’s life easier by entering various commands for debugging.

Through all the years of the development, I had a big need for a console but for some specific reason I haven’t implemented it. I regret this so much now because I know it would save me countless of hours of debugging, switching between maps, placing various objects for testing immediately instead of placing them in the map editor…well, that’s just a few reasons among many others.

As a developer, you should have the console implemented at the beginning. Yes, I won’t argue and I will try to persuade you into this by showing you how the burden was lifted by finally implementing it!

Animated GIF

Using console to spawn some hood-heads.

General stuff

You know IDDKFA, IDDQD and Impulse9 cheat codes? They are not just there to give players satisfaction of immortality and unlimited amount of ammo which you can use on hopeless monsters. They were there for the developers in the first place. How can you test behavior of enemies without looking at your health? How to test weapons on various enemies without looking around for the ammo over and over? What about navigating through the long levels just to find that room where special sounds needs to be tested? So, I implemented stuff like this for invulnerability, unlimited ammo, ghost mode to walk through the walls and much more.

Before I had to bind all this stuff to my keys and believe it or not, it happened quite often to get those key binds to Early Access update. Of course, not-having console is not an excuse to bad and nasty programming practices but that wouldn’t happen if I had the console for stuff like that in the first place.

If I wanted to have a debug option to set 0 health to the player, I had to write something like this in the code.

if( key == KEY_u ) {
   GetPlayer()->SetHealth( 0 );
}

As you can see this is very limited and if I wanted to set health to another amount, I would have to change this code or added another line. This can get really nasty and it is waste of time due to breakpoints placement or recompiling the game every time.

Now I can simply open the console and write set health <amount>. That’s it and it works for whatever amount, even 500! It’s a simple example but the difference should be obvious.

Sound testing

If we go to the start, the first reason to implement the console was to make life easier for Zdravko for it is quite painful to implement new sounds and to hear them working in the game. This should be quite simple when working with existing engines like Unity, Unreal etc. but when you have your own engine you need to write tools and I can hardly afford time for bigger tools. Well, that’s another part I wish I had changed at the beginning but hey, we live and we learn. With the game going to its final release it was about time to make everything more proper so we can really do the polishing part with as less pain as possible, so there, I implemented the console so the sounds and music can be played from everywhere at every time. Not just that, you can also spawn reverb zones in the world without additional effort and see how everything sounds. Sorry Zdravko, I know I should have done this sooner! smile

Conclusion

Do the console system first before you start working on the game for it will save you countless of hours and number of hotkeys assigned. What I did with the console is the most basic thing I could do. If you have time you can easily extend it to assign values directly to your variables, acquire info from the game state (number of enemies alive, number of entities used, current boss health etc.). Possibilities are endless and there isn’t much work involved in this system so don’t hesitate and start today, or tomorrow…or…well, just consider this ok?

Happy console implementation wink