Once again it is clear to me that the advice I read is completely true, I need to make game design/development a habit, I should do a little every day. Whether it’s a day off when I can do substantial work, or a busy day when I can only do a little. But by doing a little each day I can surely make much better games, be it making one sprite, or writing one paragraph of a design document. It’s all practice and it’s all learning. I’m now three months into my personal #1gameamonth challenge and if no other experience was gained from this month’s challenge, it was getting a taste of the crunch, I had made a good start for Aprils game, then life and laziness got in the way and I found myself without any free time left in the month and a project nowhere near completion, so my Sunday was spent frantically trying to pull together a game. It was a stressful experience and made me really wish I’d devoted more time to the project throughout the month.
The project was chosen for it’s perceived simplicity, and once again it proves to me that there are now simple projects. The brief I gave myself was to make an Idle RPG (a genre of stripped down RPG’s with minimal mechanics, game currency/experience builds up over time automatically and you buy upgrades to progress and accumulate money/exp quicker), it looked easy, there was no game play so to speak, not in the traditional sense, surely there’s nothing more to code than just variables affecting each other over time. And variables is a big part of it, and far harder than I expected. It’s actually a difficult challenge, I created some graphics to convey the setting of the game, but the game play is all numbers, and with nothing more than numbers, you need to shape a sense of progression and find a good balance of fun and challenge. I chose to make the increasing numbers grow procedurally; I made calculations so that the price of upgrades and strength of the blocks that the player would destroy would grow exponentially. At this I feel I failed, at first the numbers grew so rapidly that they quickly became far too high for the game, I scaled them back, and in the end, the growth became flat and un-enjoyable, there were no peaks and troughs in challenge, progression was as hard at the beginning as it was at the end, and worst of all, the upgrades lacked any kind of punch, when you bought an upgrade, the affect was often, hard to notice.
This experience has really highlighted how important variables can be in game design. Computers after all don’t speak English; they speak the language of Mathematics. You can’t program a game by telling the computer that this enemy is strong and this one is weaker but faster. You have to translate all that into number values. The enemy has X health points as can deal Y damage to your player, and move at Z pixels per second. Getting this wrong is the difference between a frustratingly hard (or impossible) challenge and a piece-of-cake boring ride to the finish line. But somewhere in between is the balance that comes with great game design and you can never get there with guess work and assumptions. What this game truly lacked, was iteration in the design. To try and try again until the numbers made a great experience.