I was filled with confidence when I wrote the first lines of code for Allacrost. Although I had no experience in game development, I had been writing code in over a dozen different languages for four years through my college coursework, as did our other primary developer. Additionally, I thought that the game we were building was rather modest in terms of its complexity. We were making a 2D single-player RPG, not a MMORPG with 3D graphics. It would be a few months before I began to realize how enormous the amount of work was to make the dream of Allacrost into a reality.
I had already familiarized myself with the technology and libraries used by Battle for Wesnoth  before work on Allacrost begin. Initially, the plan was to start from the Wesnoth codebase and make the necessary modifications to transform the turn-based strategy game into a RPG. As I began studying the Wesnoth code however, I found myself both frustrated and disappointed. The code was unorganized, difficult to understand, and there was virtually no documentation. After spending a couple days trying to make sense of it, I decided to abandon that path and began writing the code from scratch. Let me clarify that I did not regard the Wesnoth code as bad, just difficult for an outsider to comprehend at that time. I’m sure it has improved over the years, and Wesnoth has undeniably been a more successful project than Allacrost over the years.
This experience had a profound impact on both myself personally and the Allacrost project as a whole. I vowed with conviction that I never wanted anyone to look at the Allacrost code and feel as disappointed and confused as I had been with the Wesnoth code. And we’ve been very successful in that regard. I’ve lost count of the number of messages and e-mails I’ve received over the years from people who were impressed with the quality, design, and documentation of the code. The work that we’ve put in to keep the Allacrost code well understood and organized is something that I’m very proud of this team for doing.
After writing a few hundred lines of code , I began to realize just how ignorant I was about software development. I had no understanding of build systems, how to handle a large number of source files, logging and debugging, and many more critical pieces of knowledge. All of this I had to learn as I went along, as did many other programmers on the team as most of us were young students with little to no professional experience. Still, we seemed to be doing okay for ourselves. We were able to draw maps and sprites, play audio files, and navigate simple menus with a few days work. Things appeared to be coming together. I was deceived by how easy it all seemed to do, and others likely were as well.
Before work on the code had even begun, I had set out some goals  for the team to achieve over the course of the summer. I admitted that they were aggressive, but in reality they were simply impossible. The primary goal was to release the first playable module of the game on August 25th, 2004. And here we are in 2014, and that module still has not been released. Frankly speaking, highlighting that fact is rather embarrassing. Setting these types of goals at this time was a huge mistake, as there was no way to set any sort of realistic expectations with the massive collective ignorance of the team. Our goals should have been much more simplistic and aligned with gaining the necessary experience to produce a screenshot or simple demo. That summer passed with us not achieving much of anything noteworthy, although by the end of August we were definitely closer to moving ourselves and the project in the correct direction.
Coming up next:
- Designing a game engine from scratch (and why its a bad idea)
- Selecting code libraries
- Technical feature creep