Red Coat here with another update.
Ok. Less an update and more a look at our methods for the production of our first game: Jacob’s Highway, Highway to the Moon.
What are we looking at? I’m glad you asked. We’re going to look at our approach to tools creation.
Firstly, it should be noted that, at least for our first games, we intend to eschew away from purchasing too much in the way of development software suites. This would seem a foolhardy decision, and certainly a time consuming one, but one of the tenants of this group (aside from making games that we enjoy) is to ensure that all participants involved have something to show for their efforts when all is said and done. Since our team home to multiple programmers of varying skills and proclivities, it was deemed cool that they get to flex and develop their coding muscles.
Secondly, we wanted to have full control and understanding of our code base, so that our code could match the requirements and needs of the game rather than having to build the game so that it matches the requirements and needs of a pre-created development environment.
Lastly, we believed that building our own code base would save us some money (tools wise), although it would mean that development time would be much longer than normal. Whether that sentiment proves to be true remains to be seen.
Anyhoo, when approaching the development of our tools for this, our first project, one big thing that influenced our coding practices and tool design philosophy was the notion that we would more than likely be using different parts of these tools in future projects (specifically, future schmups). That said, it was also understood that, as our first attempt at tools creation, we would more than likely tear it to pieces and cannibalize the remains when it came time to move on to our next schmup project.
Our main focuses with this project were on flexible enemy AI algorithms, ease of stage creation and manipulation, and easily editable graphics and physics that can be applied to any AI construct that we build.
Most importantly, we wanted to be as data driven as possible, to ensure that when changes needed to be made to the game on a content level, those changes could be easily executed with little to no extra development overhead.
So far we’ve ended up with three primary editing tools which each contain various internal development modules that loosely pertain to their prospective purposes. Early in development, a new module would be added to each of the tools almost every two weeks. Even now, we’re finding new reasons to expand the breadth of our tools. Most of these are changes that go on our list of things to keep in mind for tools of the future, but there are a few tweaks here and there that get put in when the need arises.
So yeah. Tools. They’re pretty useful.
At the very least, they make my life a whole lot easier.
And before I go, a little thank you for checking out this post