💾 Archived View for gemlog.blue › users › petros_katiforis › 1692433665.gmi captured on 2023-11-04 at 17:44:28. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

         _.-~--~.
       .'.:::::::`.   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
       *~. \ / \)\)
          `-|   ) /
            '--*-*

My Game Creation Process

Introduction

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

Brain Storming

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.

Implementation

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.