Some Things Dead Wake Development Has Taught Me

I’ve been working on my zombie game project for quite a while now (it actually started in November 2007). Recently (last month or two), I’ve kept pretty quiet about the upcoming release (it needs “some more work” and when I get it out I’ll blast you guys with some more stuff about the project), but here’s some thoughts about the project.

#1 – It’s good to have a vision (and it doesn’t harm to harm some plans on paper too)
Since the very early, I’ve got this certain vision about how the gameplay should function: the barricading, the zombie attacks. I’ve added and tweaked some things but even now as I look at the very first video I see that the same core stuff is there. I think having core values for your game can be an important asset and help you in the project.

I have used pen & paper to “schedule” my work, meaning – I’ve listed tasks & features on paper and then got rid of some notes, and also written more notes and prioritized notes. For me, it has worked pretty well and I suppose it’s quite important to have some sort of big picture about what’s going on and where your project is heading.

#2 – Technology juggling is no good (stick with what you are good at)
I know that jumping into a new technology can cause headache. Dead Wake was started with Ogre, then switched to NeoAxis (works “on top of Ogre”). This was better idea than using Ogre for rendering and coding everything from scratch. Then at one point I decided to get rid of NeoAxis (my C# skills were just too poor to get anything done, and needed to rely on external programmer) in hopes to get the game out. We considered Unreal Modding, but it too seemed bad choice (and didn’t really last for more than couple of weeks). Eventually I switched to Blitz3D (the tool I knew inside out) and released some version for this, but Blitz3D was not helping us with things like shadows (nor it had no object oriented support to say a few reasons why the search continued). From Blitz3D I eventually landed to BlitzMax and Leadwerks (which basically had Blitz3D like syntax and some object oriented stuff). This proved out to be the best choice so far (even though there’s still some compatibility problems), and now the project started moving faster.

It’s easy to be smart after seeing what’s happened. I know there was technology switches and I spent money & time for many things. In retrospect, it’s true that at some point I thought “I wasted months and months time and quite a bit of money”, but now as I look back I’m not so sure if I’d change anything. I made some good friends. I got help in object oriented programming – a crash course so to speak, and got some more first hand experience on what the cost of changes can really be.

#3 – Pick an engine that’s ready
Hint: loads of stuff in this lesson – read only the “bottom line of point #3″ in the end of this part and skip the rest if you wanna just get the “important stuff”

Some time ago I mentioned that we had compatibility problems. The Leadwerks engine’s physics had changed in one release (meaning, the player controller was acting totally differently – and my barricading feature couldn’t work anymore). This change also meant that I needed to go through every single texture file and manually save them and make them to DDS format (I still haven’t finished, but it’s pretty good now). The big thing was, that this new version introduced compatibility fixed for ATI cards.

Basically, now I had 2 choices: (1) use old version, and ATI cards won’t work. (2) Use the new version, and my game won’t work. As an additional option, I also looked (3) to see if I could continue with 2D.

Thanks to support from you readers (and after pondering this dilemman a bit) I decided to proceed with the option #2. Number 1 would mean the game sales would be harmed. Number #3 would have meant quite a bit of work. Number #2 meant that there was additional unexpected work and serious changes to the barricading system ahead, but it seemed the optimal way.

In retrospect, if I had known (or perhaps found out) more about the compatibility issues (I just assumed it worked since there was nothing mentioned about ATI cards, only that Shader Model 3.0 is required) I might not have trusted what the forums said (“next versions will fix this and that”). At one point I got a hint when there was Leadwerks forum talk about freeze problem saying “ATI’s fault – I cannot do anything about it” – but later “fixed ATI problem, it was error in my code”, it kind of made me think that more responsibility should be taken and not blame ATI.

Same goes for engine changes: I wouldn’t have expected such big changes, but one just has to accept these. The fact is that Leadwerks is now really nice tool and is evolving with nice speed. There’s lots of good stuff and if your game is okay with the Shader Model 3.0 minimum requirement, and can bear with some changes then it could be tool for you. My opinion is that I’d perhaps wait 6 months or a year or so before starting to using the engine (to ensure better compatibility, and more finished engine) but that’s just my feeling about the Leadwerks. I think anyone into making 3D prototypes could immediately start using it.

I realize that I’m also here suggesting that there’s “problems in Leadwerks engine”. I realize that these have been my choices and engine makers cannot cater for everybody, but in this situation I think making such drastic changes (“no more PNG whatnot support, DDS only support” and “player physics controller now works totally different”) are such things that affect only other projects, and I think it’s fair for me to say this. Of course now the situation is better: now it’s more ATI compatible, and creating DDS files isn’t too difficult so things are pretty okay. I realize that all tools have “problems” (or challenges) but to me Leadwerks is still at least partially “in development” and cannot be considered “finished engine” – but again, that’s just my feeling about the software.

Bottom line for #3: If you wanna make game and sell it, then I recommend picking up an engine that’s not the newest technology. Pick something that works with 5 year old computers. I also don’t recommend taking an engine that’s getting upgrades every month or two. Instead, pick an engine/framework/lib that’s proven (has finished & published games) and use the version that’s currently out. I don’t believe in “hoping to see some feature in the engine in the future”. You gotta take what’s available now.

#4 – Do you really need 3D? (Pay attention to the art pipe, animated stuff requires work)
In this project, I must say that I’ve spent quite a much time fiddling with the art stuff. I’ve been hunting down art packs. I’ve been working with an artist and an animator. I’ve been working with some particles and getting animations and shadows to work.

All this is of course important for the game (creating feeling), but has quite little meaning for the actual gameplay (shadows being somewhat an exception). In my opinion, one thing developers should really think is that “do I need animations in my project? Do I need 3D?”. I think animating stuff is really time consuming (especially 3D), and this decision should be really thought about. Of course animations can be eye candy… but I think it’s something that can become very expensive too.

I was doing fine with my Highpiled game, since I had a reliable & trustworthy & skilled artist who kept doing the art stuff, and I didn’t need to do much. I simply told him what to do, and he got me art. If you can get in such situation, then fine… but even then it means you might possibly need to deal with timing, changing some animations and pay attention to resources and so on.

If an alternative is: “no animations” (or “minimal animations”) then you might be getting work done much, much faster. Creating 3D game with good looking animations versus creating non-animated 2D game can have tremendous gap in how much time is needed. If you want to do 3D, then I really think people should considering modding existing games. That’s probably much faster way to go forward.

I think developers should really consider their own capabilities and resources: how much time you want to spend on your project? I’m glad that I’ve gone so far with my Dead Wake (3D project) and I’m taking the last steps to finalize it, but I think a pretty suitable deadline for any (indie) game could be around 6-12 months. Spending anything more than 1 year, and then it probably should be split to smaller parts (or episodes or something). I must say that all developers should really, really think whether they really need that 3D – and whether they’d be better of with a non-animated game project.

#5 – Listen to others (but don’t care what they think about you)
I’m such a person who listens to everybody and everything (well, almost everything). I try to learn from people, and suck the information like a sponge. I also ponder the stuff I hear. It’s not “Monkey see, monkey do”. It’s more like “Monkey hear, monkey think, monkey does – or doesn’t”.

For me, one good way to learn and get some good opinions is to: (1) not to give a rats ass what others think about me (or my product) and (2) pay really close attention to what others say to me. If other people think and say that “you and your product is the shittiest piece of shit they can think of… because it has fault A and B and especially C” then that’s their problem. I just ignore everything before the word “because” and pay close attention to the words after it (the reasons) in case there’s something useful there. Of course I try to remember thank people for taking time to give their opinion – I think it’s really important to thank these guys for taking time to help you out.

I don’t aim to get everybody to like my game. There’s 6 billion people on this planet. How could I? My primary goal is to have fun while working on my game (and of course sell bunch of copies…) – and I aim to get some people to comment to me “I like your game, this is awesome!” – then I know I’ve done a good job (my bank account is also a pretty good financial metric).

That’s it folks
This of course is just my 2 cents, but I’ve spent quite a bit of time, energy & money to come to these conclusions. Hopefully there’s something in this article you can take and benefit from.

8 thoughts on “Some Things Dead Wake Development Has Taught Me

  1. Juuso Hietalahti Post author

    polygone & ovo: they came from content packs. dds files were missing some value thus they were showing all black for ATI cards. Some png files were used since I could actually manipulate them and had no DDS manipulation (for example viewing) tool (and some came from pack files so I didn’t bother to change them). But… anyway, now the situation is what it is.

    Samuel: thanks.
    1. done ;)
    2. don’t tell me anything about textures! XD (well, unfortunately this might not change for now – we’ll see)
    3. good idea.
    4. yeh, I’ll add clip info (but no “current ammo left info” – see some blog posts earlier.)
    5. should work better in the next release…

    Thanks man.

    P.S. Please go to http://www.deadwakegame.com/forums too. Share ideas and give more feedback and talk with others. join us…. ;)

    Reply
  2. Samuel

    Cool post, I too have done a bit of searching around. I downloaded your game, and as an experienced indie 3d game dev., their were several things i noticed that could greatly improve it.
    1. The walking sound is repetitive. Try to mix it up some how.
    2. Have an option to use higher quality textures. Where I especially noticed it was on the buildings.
    3. Player health, your character should react somehow, maybe slower, maybe darker “red” screen, or maybe just a health bar the mouse-over thing was not working with me.
    4. Indicate ammo left.
    5. The shadows bug me. However; seeing all your engine changes, if the shadows are built in, and there is no way to modify then leave em.

    Sweet game!

    Reply
  3. Ovogame

    > I actually have also .dds files that won’t work

    This is weird. Are these texture special? For example not power of 2? Witch compression do you use?

    JC

    Reply
  4. Polygone

    You should not have been using .png format for textures in the first place. DDS files load faster and use less memory.

    Reply
  5. Juuso Hietalahti Post author

    Thanks for the tip Patrick. I actually have also .dds files that won’t work, so I first need to save them to .png, and then use Leadwerks converter to get them back to .dds (otherwise they are seen black).

    Reply
  6. Patrick

    Nice post Juuso. If you are still needing to convert images to DDS, I’d recommend XnView. It can batch convert folders of any image type it supports to dds.

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Pro-Human Quiz: