Hey there fellow deadheads - I've got a quick-fire update on the development of Project Rome, the game I've been making in GameMaker. First off, since it has been a while since my last dev diary entry, let me reassure you that Project Rome is still taking shape - it has not been cancelled or got stuck in the quagmire of development hell, I'm fully behind this project and want to keep it that way (I've even been toying with the idea of a Kickstarter campaign sometime next year but that is being kept under wraps for now). Development did go through a troubled period for a while; an insidious problem raising its ugly head at an inconvenient time. After several hours of brain-ache and occasional sighs of disappointment, I am thrilled to report that a solution has been found: an answer of cosmic proportion that has both allowed existing messy code to be rewritten in more streamlined and easily-understandable ways, and catapulted development forward at such a phenomenal pace that I can confidently say that I have achieved more this week than I have in months.
The main problem (and there have been several minor problems including a plethora of soul-destroying bugs) was that of depth.
GameMaker, being a primarily 2D game engine, has a concept of depth to make objects appear closer or further away from the screen; the player's viewpoint or camera if you want to get technical. This allows for some fairly groovy stuff; a platform game where the main character runs in front of the background hills and behind a tree in the foreground, for example. Basically, depth makes a game feel "alive" and not just a boring, flat computer program.
In addition to that, GameMaker Studio 2 - the super-fly new version of GameMaker - introduces the concept of layers; as far as I can tell, just groups of objects at the same depth - it's a convenient tool to keep track of objects that are in the foreground and those that are in the background and so on. However, as you may recall, Project Rome is isometric so I do not really have a simple foreground and background - more like levels of background. Consider the hastily drawn example below.
© Picture created using Microsoft Paint
There are two conditions that need to be satisfied:
© Picture created using Microsoft Paint
The obvious solution (trust me - it took a long while to become obvious) was to assign each tile a unique depth, starting from 0 and increasing with every tile down each tile column and repeating for all columns. In this way, objects on the grid could be assigned a depth according to what tile they were on in the isometric grid and appear in front or behind each other as required.
© Picture created using Microsoft Paint
This rough description is the basic summary of the method used to solve the depth problem. Implementing it was a bit more tricky as GameMaker has a funny interpretation of depth with higher negative depths objects appearing above lower negative depth objects. Other unwelcome factors came from the requirement of units to move around the grid (therefore, frequently having to change depth), the designed multiple levels of my maps and the simple fact that, to boost performance, tiles in my game are not objects able to store parameters but basic sprites; plain 2D images with only an id and individual coordinates to identify them. However, in the interest of preserving the sanity of whatever mortal decides to read this, I will not go into the details.
The Real Dev Diary of the Dead
Dive into the mysterious (and rocky) world of game development once more and uncover the latest progress on Project Rome. In this short episode, a diabolical problem rears from the depths, only to be thwarted by tyrannical solution.
24/09/2017