Begin Engineering Log 1…
Take a moment to get the song out of your head. I’ll wait.
Now then, before continuing, picture this: You are starting a voyage on the open seas, and you must guide the ship without modern technology. Now imagine that your charts and maps you use to navigate are drastically outdated, or even entirely useless.
So what does that have anything to do with our company and game? We are venturing into uncharted waters, creating a game that is not like anything else, and my job as Code Artist is to bring elements the others create and combine them into a working game. With these development blog posts, I invite you to follow along as I document our struggles, triumphs, and process we go through to make this game a reality. Our ship is guided from the Command Center, but the heart of the game is maintained in Engineering.
Now then, let’s get on with the game talk. That is why you’re here after all. When work started at the beginning of June I had no references and only a vague idea of what kind of game we were going for. I knew certain elements needed to be in place and so worked on those. My job involves the actual programming of the game, but I actually do much more than that. In addition to the actual programming, I have been working with our two artists to bounce ideas around and integrate their creations into Unity
and the project. Those who have been following our Scrum meetings may recall the little snag we hit in week three and four when the organizational structure of the game came into question. For a mix of reasons including lack of references, new programming methods, and others, we had to rethink our approach. Thankfully, at the end of week four I found a wonderful tutorial that outlined a very basic structure for a Real Time Strategy (RTS) game, which our game pulls heavily from. Instead of combining and creating the more advanced sections of code from the beginning like we tried to do before, this new outline followed the same way the game would be played: the player would start with a building that created units and then later new units could create new buildings. There was just one tiny hurdle to overcome: the tutorial was written for Unity 4.1.
Since the structure was still sound I decided to adopt it as a rough outline for our game and integrate our systems with the structure, updating pieces when necessary. Now, at the end of week five, we have working buildings, units, and resources. The next step is to have units create new buildings. I have two things to say to others in similar positions to my own: never underestimate good code and become able to adapt to less than ideal conditions. Even though the code example is from a much older version of unity, the underlying structure is still viable. Also, I have had to constantly adapt the code and my thought process in order to overcome the various challenges faced thus far.
This week I have been hard at work getting the resource collection code done, and I am proud to say that finally our mineral deposits can be harvested by the miner units made by our artist Katey Bluel and deposit them at the nearest holding facility. A while back, Katey made many of the different shards, and we collaborated on how they might be used in the environment. After creating the crystal cluster-like deposits, we moved them in game and got to work on the unit to mine them and the code to accomplish the task. Now, our miners are able to collect resources. This is just the first step, as much more work is to follow, including animations. Now that we can collect resources, the next step is to have units create buildings using those resources, but that is a topic for another day.
Keep a look out for future Engineering Logs! If you have any questions about the game and want to learn more, keep checking out our website and follow us on social media and let us know!
Read Engineering Blog 2 HERE.