Mistakes and Lessons Learned
The page documents some of the major mistakes that we, as a staff, and individuals have made regarding the development of Allacrost. As expected, Allacrost has been a learning experience for all of us, and along the way mistakes naturally happen. What we hope to do here is to reflect and remind ourselves of the mistakes that have been made in the past and how we fixed them. Hopefully, this page will also provide some good advice for other independent game developers out there who stumble their way upon this page.
Entries made into this file should typically be large design mistakes, and not "oops, my hard drive died and I didn't backup my data" kinds of mistakes. Use the entry template below.
== Mistake/Lesson Title == ''Mistake made in error by: comma-delimited list of names''<br> Description, background, and effects of the mistake made. === Resolution === Description of how the mistake was rectified and how it could have been avoided in the first place.
Know What You Don't Know
Mistake made in error by: Roots
What I am about to describe was the first major error I made in my tenure as a developer and leader of Allacrost. Quite simply, I didn't know what I didn't know. I had been programming in a number of languages for over 4 years while I studied computer engineering at Purdue University, and was fairly confident in my programming skills. However, I later found out that game programming was unlike any of the relatively simple homework or project assignments that I had done before. The amount of design, code, documentation, and implementation of a game such as Allacrost is huge. In the beginning, I had never done in audio programming, video programming, interaction between source languages (like Java and C++) and scripting languages (like Python and Perl), among a myraid of other things. Instead of trying to approach the design intelligently, I tried to jump right into the code, and initially I met a fair amount of success. I managed to learn the API and write all the code necessary to support the first audio engine in less than a single day (this wasn't because I was brilliant, but rather because SDL_mixer is so incredibly simple and easy-to-use). Shortly after that though, I hit a wall. A very, very big wall.
In short, I knew what I wanted to do, but I had no idea how to do it. Anyone can easily hard-code a simple game that does specific things. But I wanted the power of flexibility, and I didn't understand how we could achieve that at first. I laugh at myself now, but in the early days, I thought Allacrost was going to be written in 100% pure C++. It wasn't until I realized that we needed a scripting language that I finally started to shape my act up and start learning the techniques and tools of the trade necessary to piece together a powerful and flexible game engine. The net effect on Allacrost from this mistake? It was nothing more than wasted coding effort, wasted thinking, wasted discussions, and most importantly, wasted time. It effectively slowed down Allacrost's development, and we would be much further along with it today if I had only known how much I didn't know back then. I say that things were wasted, and they were as far as the game itself goes, but they were invaluable learning experiences to myself, and to others on the staff at that time.
The solution is pretty simple. Learn. Learn things before you try to jump in and write code to do stuff that you don't know how to do yet. Seek the advice of others with experience, and ask them what knowledge gaps you need to fill in (after all, if you're a complete neophyte you probably don't even know what gaps there are, or even that they exist). One resource I found invaluable to this learning period of mine was GameDev.net, which I would argue is the best site for learning about game development. I don't think coding should be abandoned altogether during this learning period, but instead done in tandem with the new knowledge learned. I for one, have always found that the best way to learn new things (especially regarding programming, APIs, design, etc.) is to do them, not just to read about them (although reading is a required co-resquite). Once you begin to understand more, the mental image you have of how the engine code functions and works together will become increasingly more clear, at which point you can focus more on coding and less on reading/learning. I think this type of mistake should only happen once, though, simply because of the nature of the error (lack of knowledge and experience).