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.

Compatibility Thoughts

I’ve been doing Dead Wake zombie game development for a quite some time now and I initially aimed to do a launch on this month. I’ve been messing around with the new Leadwerks update and updated parts of my code to reflect the changes.

In the back of my head, the compatibility point has raised its head. After releasing the new version I’ve got replies from people about the ‘screen going black’ emails (but also many ‘the shadows look awesome’).

I haven’t updated the existing content to use the new texture format (which basically means I need to get my 3D content up to date to be able to use it properly in game). I’ve also pondered more about the potential audience and even though I’m getting closer and closer to the release, I have second thoughts about the release & compatibility.

For that reason, I’ve dug some information about 2D versus 3D and I’m re-thinking the possibilities stop using the Leadwerks 3D engine and continue with BlitzMax alone. I know this is a big thing, and definitely something that I really should have examined more several months ago.

I know that taking away Leadwerks and proceeding with BlitzMax alone would help build more compatible game, but it also means major change – and delay – in the project.

I have listed pros and cons (and will mention these in a general level in my next post), but I also thought to simply try it out and see how it goes. I’ve coded my game using a decent encapsulation or following the “black box” tactic (classes interact with each other as little as possible), so I’m trying out what would it mean to take step away from 3D to 2D.

I’ll report back how this goes. (Feel free to give your thoughts as well)

Dead Wake Version 0.7 Out (And Some Lessons Learned)

In fact, it’s been there for some days now (version 0.7.6), and since I didn’t mention it earlier, I mention it now. Those interested in seeing how the Dead Wake zombie game is progressing are welcomed to check out the newest demo.

Even though this version is rough and contains some crash bugs, I must say that I was very pleased to actually get that version done – and get it out. I’ve got some good feedback, people have found bugs that I’ve fixed, and overall I got some information about how it works.

I’ve also got reports on some compatibility issues – some of which already have been fixed. I’ve adjusted the possibility to change brightness (which is a big issue since you cannot play if it’s too dark) and made other configurable possibilities in the settings file.

It has also helped me to continue with the version 0.8.

Getting releases out (whether they be screenshots, videos or demos) is good for development.

Beginners Guide to Editing Your Game Videos (Using Windows Movie Maker)

The “Beginners Guide to Recording Game Videos and Showing Them on Your Website” showed you how to create videos, and in this guide you’ll get information about how to edit your videos.

All you need to have is the basic Windows Movie Maker. In fact, the tool is so easy to use that there’s not much to do: after you’ve recorded some .avi files, and launched Movie Maker, you need to Import Media.

After importing some media files (.avi files for example), you need to drag the clips to the storyboard. Then you can add effects (fade in/out to/from black can come handy) to the dragged clips. Play around with the Titles and credits too.

You can switch to Timeline mode (Ctrl+T when in Storyboard) and you can split & reduce clip sizes (notice that you need to drag from left, or drag from the right to clip the file properly). It’s quite easy thing to do, and in the end you can simply publish your video.

I’ve published videos in .avi format and done the converting to mpeg later.

Example clip
Here’s something I created using the movie maker, and was quite pleased how simple & fast it could be. Take a look at this:

Good Signs (Odd Thing Happened to Me)

Yesterday, I was testing different zombie games to see how these games handled certain gameplay issues. I signed into Dead Frontier and launched the chat. My username was “deadwake” and somebody who was online there asked me “Have you played the Dead Wake game and registered to the forums?”.

I said that “yeh, I have” and was asked “How do you like the newest version?”. I got the impression that he liked the game, and I said that I liked the version very much (heh), and asked what was his username at the Dead Wake forums? They guy told his username and asked mine.

At this point I had no choice put to tell that I’m the developer of Dead Wake, and the guy laughed.

Randomly meeting some guy who happens to know my game by name is – I think – a good sign, especially when taken into account that the game is in this stage of development.

Dead Wake Version 0.5.51 Out Now (Lessons Learned)

I’m so proud to present the Dead Wake zombie game version 0.5.51. Before I say anything more, I’ll give you guys video to check out:

You can find out what has changed and what’s happening from the Dead Wake community forums, but there’s some things I consider pretty meaningful in terms of development.

What is ‘Beta’?
I decided to drop the word ‘beta’, since it was giving headache for some developers (didn’t hear any players complaining about this by the way) who were pointing out that ‘betas’ are considered more finished products than what Dead Wake version suggests.

Some guys suggested using ‘pre-alpha’ or ‘alpha’, but to me this also gives a bit bad impression. By the definition, betas are considered very ‘ready’ versions while ‘alphas’ are perhaps for internal testing only. Since the core idea of Dead Wake development was to provide monthly updates, it kind of escapes the definition. It’s not beta, but it’s not alpha either. It’s something in between.

This made me drop the word ‘alpha’ or ‘beta’ totally. I just call them versions. And that’s what they are: new versions. If somebody wants to categorize them… so be it. It doesn’t really matter what you call them. To me they are new versions, and that’s it.

(By the way, a comprehensive article about development stages can be found at Wikipedia – for those who are interested.)

Back to good old Blitz3D engine
When I started to develop the version 0.5, I made the decision to drop the NeoAxis engine development. That development started out fine, but the NeoAxis engine wasn’t simply ready enough for what we really would have needed, and having a programmer to code month after month costs something. We weren’t progressing the pace I had hoped, so after weeks of research and testing, I finally switched back to the engine that’s tested and I know well.

This switch meant that I needed to port some features (not all are done yet), and leave some away, but it also meant that we got some new benefits (such as no need for .NET or DX9) and of course this also meant that the much wanted multiplayer will be in the game.

In terms of gameplay things did same to some extent: the old FPS view is gone, but the current isometric view looks good I think. The idea about barricading and survival hasn’t gone anywhere, and we can get easier tools to use.

The most important element is that: now I feel I’m in control. I have the necessary resources and skills, and no 3rd party dependencies on any critical components. When doing Edoiki, there were 3rd party ‘variables’ in terms of art (such as animations). When doing Dead Wake using NeoAxis I was referring to 3rd party ‘variables’ in terms of programming. (Don’t get me wrong: 3rd parties are good, but you gotta be absolutely certain you have the budget). Now, with Dead Wake 0.5 (and future) the risks are minimized since I’m relying on content packs (although replacing some art by hiring if necessary) and mainly my own development skills (although I shall outsource some parts of the code). I’m getting help, but since I don’t have the budget to hire full time team members, I’m only outsourcing certain aspect of development.

Object oriented… kind of
During this year I’ve really got into object oriented programming, and switching back to Blitz3D to get things finished meant challenges: Blitz3D is not object oriented (well, not much anyway) engine, so it meant doing some creative thinking to get things working in (bit like) object oriented way.

I am quite pleased with the results (even though my main game object ‘class’ is huge!) and think that I can survive with Blitz3D until they get a better version. BlitzMax seems excellent, and when they get DX9 support there it might be the path I’m heading. Or perhaps it’s Xors3D, or perhaps Leadwerks engine (this one is an amazing game engine: I’m going to make a review about this one in the nearly future). But that’s a new decision to make in year 2009, not now.

What I value now is the engine I know inside out. I could have taken the path to try to learn these new engines, but right now my goal is to finish the game. Spending months and months learning new engines is not going to happen now. Maybe after 6 months, but right now I’m sticking with the engine I know well.

Anyway, I’m now really happy with the choice and feels like I’m getting a very nice progress using the tool I’m really familiar with.

With that being said, check out Dead Wake website.

Zombie Game Pre-Release 1 – Downloadable Demo Available Now (3 Mins of Gameplay)

Please continue to to see the latest information.

To make a long story short: Download Release 1 Demo (16 megs). The demo release 1 gives you couple minutes of gameplay, and some clue about what there’s going to be in the game. If for some reason the game doesn’t work in your computer, please check out the system requirements and necessary software (You’ll need .NET2 and DirectX9 to run the demo).

This is the December release, and the release 2 is scheduled for January 2008.

I would be eternally grateful if you’d test the software and give me feedback about the game. Any feedback is appreciated: good and bad. If you have suggestions or ideas, feel free to mention them.

While you are downloading the first release…
Check out the main controls:

ASDW = movement
Mouse = aim
Left mouse button = shoot
ESC = open menu (and restart the game, you’ll need this if you happen to die in the demo…)

What can you expect from the release 1 – and what’s coming in the future
I would like to point out, that this is very early version and it contains only some features. Here are some things that will change or will be added in the future releases. (Notice: not necessarily in the next release).

  • Zombie Models: These are 100% placeholders. Our artist – James O’Hare – has modeled a great looking zombie 3d character which you’ll get to see in the future releases. The current zombies are less “realistic” than the zombie model you’ll see in the next releases.
  • Levels: the demo contains only a very small area with couple of buildings. In the future releases you’ll get to play in a real level. (And you cannot jump off the cliff…)
  • Sounds: There are some sounds that will be used in the future releases, but there’s also placeholder sounds (like weapon and box collisions to name just a few).
  • More breakable stuff: The crates currently just vanish in the air. They will be much nicer & more realistic in the future.
  • More weapons: This release contains only one weapon, and what would a zombie game be without more weapons. I have some “typical” ones planned (anybody who has watched any zombie film knows that there must be a shotgun somewhere), but also something quite unique in my pocket.
  • More gameplay elements: I don’t want to reveal too much about this, but currently you can move (and break) crates in the game, and in the future “you will be able to do more than that”. This part will have major role in the gameplay.
  • Easier installation & better compatibility: Vista users will get easier installation. Integrated video card owners will be better supported in the future.

There are other things planned, but I think it’s better not to talk & promise too much at this point. I’ll focus on getting feedback and let the releases do the talking. I’m going to make one release every month, so you’ll see more after one month. But for now, feel free to test the demo and give some feedback if you want.

Also, if you wish to suggest a name for the game (and win a copy of it), feel free to do so. As soon as the name is figured out, I’ll move the releases & game information to the zombie game site.

Remember to subscribe to the mailing list to get informed about the project progress & lessons from the making of the game.