Lessons Learned

Lessons Learned By: Peter Kuchnio Intro: This article deals with the lessons learned while I developed DDCK: Myth of Creation. These have been on my mind for quite a while and I thought that it would be a good idea to put them down on paper. Setting the stage: First, a little background on DDCK so everyone knows where I am coming from and what I'm talking about. The game my team and I developed is called DDCK: Myth of Creation. It's an RTS set in a mythical fantasy world called Caross. The player fights with elements, like Ice and Fire, in battle with other gods. DDCK was definitely an ambitious project. The game was started in December, 1999 and was finished in April, 2001, for a total development time of 16 months. It was programmed completely in Visual Basic with a few helper libraries like vbDABL and DSLibrary. Graphics were created with Bryce 3D and Paintshop Pro 6. DDCK was started at a very special time in VB game development history ;-) During the winter of ‘99 some very ambitious games were started which promised to be commercial-quality and would finally bring attention to VB as a viable game development language, plus they would be a helluva lot of fun to play =) DDCK was one of these "Big Five", which included Dragon's Wrath, DDCK: MoC, Impurity, Galaxy, and Enigma. Unfortunately, out of all of these only Lucky's Galaxy is still in development (and is shaping up to be quite a sweet game!). The rest have been canceled or given up on. Don't get me wrong, there are lots of cool games that have been started or completed since then, I'm just talking about the time when a lot of big projects were suddenly started up together. Now, before this article turns into a long talk about the advantages and pitfalls of developing games in VB I'll go straight into lessons specifically learned during DDCK =) Game Design: 1) The Design Document, its essential. A design document sets down exactly how the game will be played. This is important because it gives you structure, you know what to implement next and you know what is still left to be done. A design document doesn't necessarily have to be written up formally, as long as you clearly write down all your ideas somewhere. Personally, I'm more of a fan of the second method, but for my next project I'll try using a formal design doc. 2) Few things are usually constant. During development ideas were often changed, fine-tuned, added or scrapped. This is normal, but its also important to consider your core features and to not scrap those unless completely, absolutely, positively necessary. Total redesigns in mid development usually lead to the project getting scrapped, perhaps close to 95% of the time. One other thing I wanted to mention here is that as you update your ideas you should update your design doc or at least write things down on paper. 3) Feature creep - this is a big one, when you're developing its quite normal to think up of cool new stuff to add and run away with it. New features are good, but feature creep is bad. Basically, feature creep is when you have your features nailed down but as you develop you decide the game needs more, and more, and more! For example, "it would work better with a first person point of view, and a top down one, ooh, ooh and a 3/4 one" ... all for a Pac Man game ;-) That's obviously an exaggerated example, but its important to only add new features in mid development if it will clearly and visibly improve gameplay and will not significantly increase your development time. We had feature creep in DDCK and it almost caused me to scrap the game because of the sheer enormity of our design. Let me list some of the stuff I came up with when the game was about 1/4 of the way finished: - Environment affected by elements (ie: flowers and trees sprouting up, lakes created on the fly) - Upgrading your Citadel with elements (with individual graphics for each change) - Coloured-lighting (in DirectDraw ;-) lol ) - RPG elements (level ups, skills, etc.) There was more, and with so many features constantly being added to the game it grew more and more discouraging. Finally, I was on the verge of giving up. Instead, I scrapped a lot of the extravagant features that didn't have much of an impact or improvement on gameplay. This allowed me to gain back focus and continue. I think the game turned out much better because we slashed the feature creep. So to sum up: design your game before hand and try to at least sort of stick to the original vision =) Coding: 1) Writing code on the fly for important or big sections of the engine or game is a big no-no. Ideally, you would write a full technical design document for the game that outlined all the sections of code and how they would be implemented. Unfortunately, this is pretty much impossible unless you've already developed of a similar size and type. Still, a TDD is something that I definitely plan to have before I start my next project. But I've strayed from my point. Even if you don't have a TDD its important to know what sections of the engine and game you still have to code and in what order you'll tackle them, for example, tile-engine, path-finding algorithm, weapons system, combat system, AI, etc. It would be even better if you put down a general list like that on paper =) As you come to each section it's a good idea to take some paper and a pen and go sit somewhere away from the computer (ie: couch =) ) Work out what's needed for the block of code, figure out how it will flow in a bulleted list (or even a chart) and then write some pseudo code. This helps a lot! Your code will be easier to implement when you come back to the computer. It will be cleaner and easier to debug. 2) Starting coding: There are two schools of thought on this. Some programmers prefer to start writing their editor first followed by the engine while some start off writing the engine and write an editor when the engine is in a state where its ready to receive and use that type of data. I'm a big fan of the second method. I would never start off by writing the editor. To me that seems like taking things backwards. Usually, when your engine is reaches a good enough state its simple to cut and paste a lot of the code, simplifying and adding things as you go to make an editor. With this method you'll have an engine and the major features of the editor can probably be nailed down in about an hour. The player will be playing the game through the engine, not the editor =) therefore the engine should be the focus. Still, this is one of those things that's classified as "each to his own", the above was just my opinion. 3) Tools, tools, and more tools! : As soon as it's humanly possible I recommend creating some very nice and robust tools to help in development. This includes easy to use and easy to modify map editors, animation previewers, batch image croppers, and a few programs to take your separate images and form them into animation files. I didn't create tools for DDCK until very late in development. This required me to edit files by hand and even worse, hard code the necessary data. When the editors were created it was a last-minute half-baked affair. They did what was necessary but where difficult to use and hard to modify, I ended up altering quite a few things by hand anyway. The better your tools the easier it is to create content. The easier it is to create content you'll have more of it and it will be richer =) 4) Robust and flexible base classes and modules: Every game needs classes and modules to handle DirectX. Its important to make them very good and bug free. Setting these up to be as easy and painless as possible, it will speed the rest of your development process. Like the old saying goes, would you prefer to build your house on solid ground or a big pile of crap ;-) This is one of the things that was taken care of well in DDCK. The base module which handled DirectDraw I'm especially proud of. The surface creation subroutine not only loaded the specified file into a surface but also automatically filled out the RECT variable. The module also included functions that made including animations easy, it only took one call. (BTW, the entire Biohazrd engine used in DDCK is available for download here). 5) Engine Rewrites : Rewriting your engine in mid or even early development is a big no-no. The excuse I most often hear is "the code is messy, the new engine will be 10 times better!". This type of thinking usually ends up with the game being scrapped, because let's face it, constantly redoing your work is very discouraging. If your code is "Messy as Hell" then it should have been planned out better in the beginning. Still, unless the messiness is very extreme its much better to simply go on and fix the bugs in beta testing. Also, game engines, even the most planned out ones, are always a bit messy. It's okay to rewrite some sections of code if necessary, for example, in DDCK I ended up rewriting the collision detection code once and the alpha-blending code several times (before switching to vbDABL). 6) Playtesting while Developing: This is a very important point. It's something that I encountered in early development. I would write some code, spend a lot of time playtesting it to make it run perfectly. Then I would add some more code, this would mess up the previous code and everything would require more playtesting. This ended up making me playtest more than actually code. I think many people develop like this because its sort of an instinct (at least for me). However, this is totally counter-productive. I almost gave up the game at this point (the movement code was being created) because I was very discouraged with the progress. I changed my style at this point. Instead of coding and playtesting I coded the section of the engine I was currently working on. Then I would run the game to make sure the code actually worked and didn't automatically crash. If it did what it was supposed to I would move on, ignoring any of the more frivolous or occasional bugs (subscript out of range errors, occasional anomalies etc.) This was very important because it ended up making the development move at a nice clip. Its pointless to playtest while developing because new code that you add can and often will alter your previous code. I've seen beta versions of games that are practically flawless, however, for a large game its normal for it to be loaded with bugs, that is what a beta is for. I think that this style of developing is quite common among VB developers because when we first released the DDCK beta people were quite surprised that the game had so many bugs and crashed so often. The Beta is supposed to be buggy as hell. This style of development worked for me. So try to ignore most of the non-critical bugs until the beta test. I'm pretty sure this is how most of the big game developers function. The downside to this is that sometimes you will spend a few weeks doing nothing but fixing bugs. This can be frustrating and tedious, you'll just have to tough it out =) Art I don't have too much to say for the art side =) Mainly because this article will mostly be read by programmers plus I don't have anything too original to say =) 1) This one is for the developers who happen to be both programmers and artists. Doing both at once is often challenging because you lose your focus and sometimes end up spending a lot of time doing both at once and accomplishing very little. What worked for me was to focus on either one or the other. Spend a few weeks doing nothing but coding and fill in any gaps with temp art. Then, spend a few weeks creating nothing but artwork and filling in the gaps you left behind. It worked for me =) Teams Etc. 1) Most of us find ourselves working alone or in small teams. DDCK was created by a team of 3. Alex May handled some writing and helped out with the design, Alex Pederson created the music, and I was responsible for everything else. I've had some pretty bad experiences with teams before, for example people quitting or just delivering content that just wasn't very good. My team philosophy for DDCK: MoC was different. I knew I couldn't do it alone, so I talked to a few of my good friends who wanted to help out. There weren't any hard and fast rules, because the game was being created just for fun. Basically, anyone could contribute anything they wanted to. They didn't have to make anything they didn't find fun or found tedious. I think this approach turned out quite well =) 2) I think the project lead has the toughest job on the whole team because they are responsible for bringing it all together. Most of us are amateur or hobby game developers, this isn't our job and we're doing this for fun. Unfortunately, this often leads to lack of time to actually work on the game because of other responsibilities and things that come up that are more enjoyable than typing code, like friends, parties, movies, other games, etc =). On amateur teams, when a team member has to stop or can't deliver something I think its important for the lead to step in and help that person out. If they can't do something though, or a person can't be found to make a particular part of the game the lead has to step in and do it themselves. I think this approach will make the game they are working on actually reach completion. Planning and Milestones 1) Before you start it's a good idea to try to estimate how long the project you have designed will take to complete, just so you know how long to be prepared to work on it. I'm notoriously bad at this, a preview of DDCK back in 1999 estimated the time to engine completion at "about 1 month" =) For quite a long time I ended up saying "about 2 more months" ... for a year =) 2) Its also important to set milestones for yourself. For example, to say that in a month from now the engine will be complete or all the maps will be finished or one level from the game will be playable. Its not so much necessary to actually meet your milestones but they are important because they give you something to work towards. I think that during the development of DDCK we only met about 3 milestones =) Distribution and Tech Support I only have one thing to say for this section: 1) DirectX! You would be surprised at how many people who download your game don't have DirectX installed! 99% of the tech support emails I get are from people who don't have DirectX installed and the game won't start from them. This is something that I haven't done but should have, check if DirectX is installed and if it isn't provide an error message telling them that it isn't and where to download it. Putting it in the manual is not enough, believe me =) Conclusion Hopefully this article was somewhat useful or thought provoking =). It wasn't meant to be a formal treatise or anything, just a bunch of random things about game development that were on my mind. Good luck with your own games =) ~Peter