_.-~--~.
.'.:::::::`. petros katiforis (Πέτρος Κατηφόρης)
/.:::::: /
/.::: .---=*
;.:: / _~~_ Want to ask any question or perhaps share your thoughts?
; | C ..\ Feel free to contact me! <pkatif@mail.com>
| ; \ _.)
\ | / \ This post was published on the 19th of August, 2023
*~. \ / \)\)
`-| ) /
'--*-*
I'm writing this post as a medium to share with anybody of you interested the way I design and implement my indie games. Although I will only focus on the creation of my latest game, "Robocracy: Humanity's Last Hope"[1], my workflow doesn't deviate much when hoping from one project to another.
Robocracy: Humanity's Last Hope
Whenever I decide to invest a week's free time into a quick game, I start by grabbing a paper sheet and I then proceed to scribble different plans, themes and game mechanics. I've long promised myself to design games with an educational basis in mind as I highly despise addicting time killers. In the case of Robocracy I started out with the vague foundation of a robot-ruled apocalyptic future and gradually constructed a satisfying blueprint. I wrote down a multitude of game mechanics and sporadically canceled out the ones that I deemed not fitting for the game I had in mind.
The game's implementation phase took approximately four days, chiefly because I utilized a slightly modified version of my previous game's engine. With the engine out of the way, I could now focus entirely on what made the game unique. I kept it simple and stored all the game's source code on a single main.c file. I extensively made use of global variables and organized my code into separate functions solely when a block's functionality was required more than twice. My experience has taught me that organizing personal projects of a couple of thousands lines of code into multiple tiny files usually obfuscates the source and damages the project's simplicity and readability. My global variables describe data and only data: There's no inheritance, relations or any other fancy syntactical sugar that impedes fast compilation all while introducing counter-intuitive abstractions.
I first got the map generation and player movement code out of the way so I could interactively add new features while being able to playtest my hitherto work. Once the game loop was completed, I spent my time designing additional levels and enriching the program with new obstacles including buttons, bridges and guns.
Generally, right after I get the basics done, the creating process turns out chaotic. I sometimes slightly deviate from my original plan but that's OK. The paper sheet merely serves as a rough guideline which could and will definitely be altered when a sudden inspiration springs to mind. When implementing a game mechanic I will most often than not start with a minimal texture before I write the actual code so I can then refine it right before the initial release.