How I Chose My New Game Development Tools

In yesterday’s post about end of Edoiki development I promised to tell you about selecting the new development tools. The decision to end Edoiki development was finalized after roughly a month (this week was my deadline). I have some theoretical experience (and little practical) from object-oriented programming and I know the basics, but I have never really got into OO in practice. As I’m starting the new project, I’m taking the leap to the world of object oriented programming.

The process I used to choose a new development platform was pretty simple (although took some weeks):

  • First I decided what I needed
  • Then I listed out potential engines
  • After that I made lots of testing, reading & learning and simply chose the engine

First I decided what I need
Before I started picking the engines, I had some requirements for the engine. Object-oriented development was a must. It had to be 3D. I also wanted it to be bit more powerful than Blitz3D which uses DX7. The engine must need to be well documented and have an active community. Proven projects (so that somebody has actually made something else than “tech demo” with the engine) was also a necessity. Price had to be “reasonable” (something around “not five number price, hopefully less than 4 number price”). Most of the possible indie engines seemed to be around $100 or $200 (which is extremely cheap as you think of it).

Edoiki was never for “casual gamer moms” (same goes for the new project), and many engines seemed to be using DirectX9. The fact that DirectX9 is already very widely spread made it easier for me to start development with a engine that uses DX9. See also some system requirements stats, which is taken from Steam.

I checked out for engines and put about dozen engines on my list of candidates. Many were dumped after seeing that they would lack some crucial features, and only a few survived to the “final round”.

Irrlicht was one potential candidate, but in my (humble) opinion, the engine I picked seemed to have better documentation, articles and tutorials than Irrlicht. Engine itself was pretty okay, but I was bit worried on how they will continue developing and supporting the engine. active community is fine, but since the engine is done on someone’s “spare time” as Nikolaus Gebhardt – the author – says, I think Irrlicht is not for me.

Truevision3D was my second alternative, and actually the engine itself is fine. Basically there weren’t any problems with the engine, but there were other factors that made me skip it. The fact that they said in 2005 that “version 6.5 is here within months”, and it wasn’t until October 2007 when “pre-release of 6.5″ was published. Since the engine itself was nice, this wasn’t a major problem, but still something that bothered me. They also say that “you can use their engine with any language” (Blitz, C++, C#… you name it). They say it’s an advantage – but I say it spreads the documentation. Now if they want to write tutorial for animating a character, they need to have like half a dozen variations for each language. There is no enough documentation for languages, so it was tough for me to learn their system. Also the bit strange licensing system (read more about that on their site) didn’t seem very user-friendly, although they promised to improve it the last time I checked it out. I also heard that the community can be bit intrusive for new people, and these type of rumors had some kind of impact on my decision (although not the final reason why I didn’t choose Truevision). In my opinion, Truevision3D is a great engine – but the community, tutorials and documentation aren’t what I’m after.

Next I checked out Power Render. Engine seemed pretty nice, but the fact that the 7.0 is not out yet and there weren’t good public documentation (nor community) made me skip it. I’m sure many people can find it a great tool, but I wanted something more established (in terms of documentation, tutorials and community).

Microsoft’s XNA was one of my candidates. It seemed very good (or “almost right” for me), but the XNA version 1.0 isn’t quite right for me (no networking, art pipeline was giving some headache, no proper way to publish for Xbox, .NET download overhead when publishing to PC). 2.0 should appear by the end of the year – but still I’m not sure how well the art pipeline will work, or how good is their network system, or if they’ve dealt with the other issues. Maybe after 6 months the situation is different, but I’m not going to take the risk and hope that it will be a good solution for me. XNA uses C#. While C++ can be more difficult than C# (one could say that C# as a “higher level” language can be “easier to use” – at least in theory), I think C++ is rock solid language for games development, while C# is “making its appearance”. I won’t get into the C++ versus C# wars, and I won’t say which one people should use. I simply say that “it depends what you want and what your project needs” and leap to the next candidate.

3D Game Studio was another engine I checked. The name reminds bit of a “game maker tool”, but after testing it I could see that it’s very easy to use (for those with some programming skills) and very nicely done. There were only 2 problems with the engine. First of all the networking system is in amateur level (especially if you compare the rest of the engine features), and it lost the quick comparison in speed with my last candidate. If your game needs network play, then 3D Game Studio (at least at the moment) is bit of a problematic, but otherwise I think the engine is well tested and there’s a solid company doing the development – not to mention active community and lots of articles and tutorials they have. (Those interested in how networking is done in 3D Game Studio, I simply say that they use “wait 1 sec” type of commands to ensure that players are in game.)

The last candidate – which I ended up selecting
I ended up benchmarking Ogre3D (which is a graphics engine, not a game engine) and using various libraries for the development. Ogre3D is a tested rendering engine that I can count on. It has the features I need (although the art pipeline isn’t exactly the easiest to use), the documentation is superb and the community is active. The installation process is painful even for experienced programmer (friend of mine – a top notch C++ coder who uses Visual C++ 2005 Express Edition – mentioned that he tried to test it in the past but couldn’t get it working), not to mention for those with less experience. By carefully reading the tutorial on how to install Ogre3D I finally managed to get it working. I tested samples and even got my own animated model and shadows to appear in the right places. While not easiest the install (and with “not so good” art pipeline), Ogre3D is very powerful graphics engine and their site is filled with articles and their forums are a great place to get guidance.

Ogre3D is not a game engine, so I need to pick libraries for different usage (such as for input, networking and so on), but there are several games made using Ogre3D and the tutorials, documentation and community are excellent. Ogre3D uses C++, and that’s what I’m learning right now.

End of Edoiki Development

About two months ago, our environmental artist “left the building”. While Edoiki was coming along nicely, the fact that there wouldn’t be anybody to do stuff for the levels was bit of a problem. Getting a new (and the right) person with a minimal budget to do the wanted environment turned out to be very time consuming. Too time consuming. I was waking up realizing that the plans I had for the game simply weren’t in my budget. Due several reasons – resources being major one – I have made the tough (but right I believe) decision to end the Edoiki project development.

This article will go into reasons behind the rationale, and also detail some extremely important lessons I learned from the project.

Ensure that you have enough resources – big enough budget for your game
The game’s eastern theme brought some mystery (at least for us western people) in the game, and some of the models that were made for the game were simply amazing. Unfortunately when our talented environmental artist left the building, it was like a punch in the face. I didn’t see it coming (although I’m glad that the artist said about his situation, so at least I heard it as soon as it was happening). Replacing a key person can be a tough job.

Risk management
I honestly didn’t know that it would come a day when I truly emphasize the meaning of handling risks. I’ve been the kind of person who thinks that “most risks can be sorted out as they happen”, and “prepare only for the biggest risks” (if any) in indie game production.

In retrospect, the fact that I was relying on one artist to do the environment was a huge risk (since I had minimal budget, and was offering royalties for work done). For the new project (more about that in the future blog posts) I will minimize this risk by choosing a theme to which there are art content packs available. I will put some dollars into getting the game characters done, but will rely at least 90% (most likely closer to 99%…) for content packs for the levels.

With a bigger budget, it wouldn’t be such of a problem to hire somebody to do all the level stuff – but for indie game budget I believe this type of decision is fine. This means I don’t rely on people (and worry if their plans change), since frankly – I don’t have budget to ensure that the people stay on the team. Naturally there’s more involved than money, but for a long non-paying project it can be an issue.

That gets me to the next reason behind the decision.

Too long production time (ahead)
The whole team spent many, many hours to develop the game. Some came, talked, and left. Some helped out, contributed, and left. Some spent less hours, some spent more hours. I have talked with all the team members about the situation and I’m glad that we all are still friends, and people understood this decision. I appreciate the effort that Ben, Michael and Jean-Marc have put to the game, but now I want to say what I’ve done.

I have spent close to 2 years (part time) to develop the game, and I have poured lots of hours into planning, testing, designing, learning – you name it. I have learned enormously – and gave some of those lessons here on the Blog and in the articles for Insiders. The problem is not “how much I have spent”.

I repeat: it doesn’t matter anything how long you spent on the game. What matters is where you are now and what’s ahead. I see that getting another artist to do the environment would take too long: finding the right person, getting familiar with the content pipeline and ensuring that he stays in the team would simply take too long (I took several months to find the artist in the first place, and same happened with the animator).

I was planning to cut features and publish at least a demo of the game, but even that would require at least some weeks of time – and wouldn’t really serve me or the audience.

The eastern theme and features I’m after would simply take too much time – and I don’t have the budget to ensure that it will be done.

By the way, see also this blog entry: Why some games take 21 hours to produce and others 21 months.

No object-oriented programming
Lack of object-oriented programming wasn’t the main reason behind closing the project, but for me it’s one reason why I won’t be spending the rest of the year working on Edoiki game any more. Blitz3D – a great tool I’ve used for half a decade or so – doesn’t support object-oriented programming, and the fact that I want to “advance to the next level” and start using OO made me find another engine. (More on that in tomorrow’s blog entry).

It does a world good to me to learn object-oriented programming, and that’s what happens with the next project.

Bottom line
The Edoiki project has now officially come to its end. It wasn’t finished, but it was still a successful project for me. Within the two last years I’ve met more developers than ever, learned more than ever – and that’s something very valuable.

Zombie Or Not (Video Clip)

Found this funny video that really clears out what zombies are… or aren’t.

It’s pretty interesting how seemingly simple concepts (“what is zombie”, or “what is a casual game”) can have a variety meaning in the people’s minds.

Anyway, here’s the clip. I totally agree with the guy on the right (well… except perhaps about the last potential zombie seen on the video).

Why do we make these things so complex?

Getting Things Done With a Method Called DIA

“Do-it-anyway” I call it. It’s more of a way to think stuff rather than method. Being efficient often boils down to DIA.

There are lots of people who read more stuff about “how to get things done” or “how to motivate yourself”. They get more and more books, listen to more and more tapes – yet they won’t get more things done. Sometimes it might end up being just the opposite: the books and tapes might eat too much of their precious time.

Don’t get me wrong. I believe there are some good tactics, and there are ways that help to get motivated – but I don’t think people should get stuck with “how to get motivated to do something”. At that point “getting motivated” might not be the problem, it might be the “something” that you need to change.

Or use DIA.

Do it anyway.

If you don’t feel like doing some annoying task… then do it anyway – even if you don’t feel like doing it. If you know that you need to get something done, then why simply not do it?

All the books or tapes or seminars in the world won’t make that “something” any easier, so why not save some time & money and stop reading too many books and simply do the task.

That’s DIA. Do it anyway – even when you don’t feel doing it.

Game Distributors Could Learn From Steam

Valve’s Steam is a well done system for distributing games. Yesterday I created my Steam account and made my first order through the system. It was extremely pleasant surprise. Here’s some highlights:

PayPal payments: I expected to see only Credit card payment options, and was very pleased to see that PayPal payments were also accepted. It’s easy to forget that the more chances you give the customer to bring you money, the more likely he will do that. Steam is a good example about a system well done.

Instant delivery: I have ordered some casual games earlier, and now I bought Half-life 2 Deathmatch (AAA product, typically seen on the retail stores) – and got it delivered via Steam. Downloading was simple, and reliable. Steam even told me that the download will automatically continue in case I go offline. I have always been a “box person” who wants to get physical stuff… but the price and easy way to purchase games really made me a Steam fan.

Great overall experience: Steam has community features, tabs for “my games” and all “additional stuff” that make buying & playing easy. They show me news if I want. When I install Mods, Steam will tell about them. The server system is just great. The whole experience was very positive.

But there was one tiny annoyance.

One tiny problem, which they really should take care of. The game was automatically installed to C-drive, without asking me! I don’t know if there’s some sort of special settings from where I can change the download path, but at least it wasn’t asked in the installation process – and I couldn’t find it anywhere. It’s a small thing, but can be bit annoying if you can’t tell where to put the games you purchase.

Nevertheless, I was very happy with the system, and I believe game companies (who wish to create distribution systems) could learn from Steam.

Why There Are Hidden Objectives In Games?

I got a very interesting question about game design. One of you readers asked me:


I’m writing a term paper. I have been looking for this answer and I can’t really find the answer. Why do game software developers add “hidden things” (levels, rounds, and etc) to a game? My paper is (no laughing).. How game software developers are promoting hacking to the public. I am a gamer myself. All I’m hearing from my 11 year old cousin is “look at this cheat I found.” I know “cheats” have been around for decades but it has gone main stream. I was just curious you or a few others may know this answer.

I think the main point of adding “hidden things” boils down to bringing extra challenge to those who want it. This is my opinion (and I’m sure there’s lots of game designers out there who can add more into my answer). I think hidden objectives are a good thing compared to some alternatives.

Think about the following example.

Imagine some game that’s really challenging. Imagine that it’s so difficult that most of the players can’t solve the first level. The game developers decide to lower the difficulty level by decreasing the number of enemies, and suddenly the game is boring for those hard core gamers that enjoyed it in the first place – it’s too easy for them. Now it’s okay for the masses, but there’s also a group of very unhappy gamers. Putting “easy”, “normal” and “tough” difficulty levels could be possible… but it might turn out quite dull when you have “less lives and ammo” in easier levels.

But then Joe Designer gets it. He decides that they will have certain difficulty level instead of “easy” or “tough”, and he puts extra challenge (hidden objectives) in the game. Now the game might be easy to solve in some parts, but there would be alternative routes (dangerous ones) that would be more challenging. There could also be additional items that are only given if certain requirements are met (for example: player would need to collect all the gold keys in the levels to get access to mine of the dwarves).

Hidden objectives can give extra incentive for players to try to beat levels. That’s one reason for having them. Other reasons might be about the story line (like reveal additional information about the reasons behind the historical conflict) or perhaps they could give hints (or aid) in the upcoming levels.

The Second Worst Programming Language Innovation

Here’s another programming innovation that could perhaps* have been designed bit better.

Check out the code:

switch(value) {
case 1:
case 2:
// do something
break; // why here is a break?

It’s a “newbie mistake” to forget “break” from switch statements, but what if the syntax would be something like this:

switch(value) {
case 1, 2:
// do something

Marks {} are already used to indicate a “section” in programming languages (just think about IF), so why not use them in “switch” cases as well? Or why not replace “break;” with something like “continue;” – so that people would need to type extra stuff if they do not want to break the case.

Just wondering.

* and by “perhaps” I mean, that in reality I don’t have a clue how this should be done. I just think this for the beginner’s the command “break;” can be bit problematic sometimes.

Havin Team Democracy Is Not Top Priority

The objective of a game development team is to produce results. Having democracy and “hearing everybody” shouldn’t be top priority in every decision making. There are some reasons for this.

Democratic votes are time consuming
That’s the main reason why there should be leader in the team who is willing to make decisions when necessary. If you use “democratic voting” – hear what everybody has to say – every time you try to make a decision, it will be darn slow. Sometimes you should just cut corners and decide stuff on your own.

It might slip into being fake democracy
If people are just heard (but nobody is really listening), then you are just faking democracy. You are asking what people say, but then do whatever you already decided. That means wasted time (and basically is pretty annoying).

Democracy might indicate that you are a clueless leader
This is bit of an exaggeration, but think about it. If you are the leader, and you are always asking “what are you guys thinking about this” and “what are you guys thinking about that”… then people might get the impression that you don’t want to make decisions.

Leaders should bring vision and goals – people want leader to lead.

A word of warning. Being tyrant is equally bad (or worse). You have to keep the team motivated and ask their opinions now and then. Balance is necessary.

The point I want to make here that “having democratic team” over “having team that produces results” is not such a good idea – since the goal is to actually produce something, not make sure everybody gets heard always.

The Dumbest Bug I’ve Ever Created

I was testing stuff yesterday… and the bug I created was really dumb.

So stupid that I just had to write about it here.

Basically my code was something like this (I’ve used pseudo code here to simplify the situation). I have a code that loops 10 times and sets random texture to a character entity:

FOR (i=0; i<10; i++)
value = RAND(1 - 20)
textureName = "texture" + value + ".jpg"

When I launched the program, for some reason the first 8 entities were getting a same texture, and the last 2 were getting some other texture. I launched it couple of times and thought that is there something wrong with making random numbers.

I decided to debug and placed a breakpoint to the line of “value”, and watched what kind of numbers it was getting. It was getting number 3, then number 9, then number 5 and so on… when I debugged – the textures were random! But the moment I launched without debugging and breakpoints, the random number wasn’t working.

After some time… I realized that I had add that SRAND call inside the loop. Basically I was resetting the random number set every time I started the loop (for those who aren’t familiar with setting seed, basically you could describe it like that the computer will start giving “certain type of random numbers” based on the seed number. The bottom line was close to this: “when next RAND call is done, give me number 3″). I was using that command every time, just before asking the random number.

And that’s why the breakpoint mode gave “proper textures”, since some time had passed between loops (as I was checking the number value). But in the non-debug/non-breakpoint mode the loop went so fast that the “time” value was always the same.

It was easy (yet embarrassing for somebody who has been programming close to two decades ;)) to fix. I simply moved the SRAND to another place and now things started work.

SRAND(time) // initialize random number generating
FOR (i=0; i<10; i++)
value = RAND(1 - 20) //give random number between 1-20
textureName = "texture" + value + ".jpg"

Care to share your dumbest programming bug you’ve managed to create?

The Stupidest Invention In The History of Programming Languages

In programming, the award of the stupidest inventions goes to use of characters == and =. (setting value and comparing whether values are equal).

Just think about it. There are countless errors being made because somebody wrote IF (a=b) instead of IF (a==b). That error is really difficult to trace and it gives no compiling errors. (Okay, some programs don’t use ==, but there are many languages that do)

My rough estimation is that because somebody started using == several decades ago, it has already cost billions of dollars today (I base these estimates on average hourly salaries that’s wasted on debugging – and on the results of the dice throw I just had).

Why couldn’t they use something else… like < - symbol or something to “set value”.

Wouldn’t it make a lot of sense?

a < - b

That looks like “b value is put to a”.

I wonder why nobody asked me when programming languages were invented.

Update: After some thinking, symbol ¤ could be used as well. Check out the discussion at the forums and give your suggestion.