Category Archives: Secret Game Project Lessons

Lessons from the secret game project. What I’ve learned during the game production, and what you can learn too. Some of the posts show news and progress of the project.

The 10 Worst Game Production Mistakes

Game production is something where you can always learn something new. Sometimes the lessons can be really dramatic, and sometimes they can be very tiny. Here’s the 10 worst game production mistakes that came to my mind.

#1 – Changing plans
I’ve mentioned this in the past (and you can rest assured I will mention this also in the future): changing plans is by far one of the worst mistakes there is. It’s okay to revise and update plans – and adjust them, as long as you move towards the goal you’ve set. If on the other hand in one week you are doing a casual 3-match game and the next week you decide to do a million dollar MMORPG, something is wrong.

The more you change your plans – the more it might require time. For example, let’s suppose you’ve thought about having 3 male characters in your game. Your artists have just finished modeling one. Suddenly you come up with an idea of having 7 female dwarves in the game instead of the male characters. 3 male characters are trashed, and new work begins. That’s wasting time

Be careful when changing plans.

#2 – Not having specific and clear objectives
This mistake is pretty much as serious as the previous one. If you don’t have clear idea on what you are doing… then you will eventually waste time in doing useless tasks. You will spend time on useless emails. You will waste time coding useless modules. You will waste doing “something” which might never be used in the actual project.

The way to overcome this mistake is to make definite objectives. Even if the goals would be small, that’s fine. It’s much better to aim to something than not having a clue what you want. This lesson goes with life in itself.

#3 – Not firing people early enough
Even hobbyist teams should be aware of this mistake (or perhaps I should say: especially hobbyist teams). Years ago I remember I wasted time with people who couldn’t produce the results they promised. There were always some excuses (ranging from hard drive failure, to lack of internet connection to simply vanishing) – and some people never got done anything.

I believe getting rid of “bad blood” is crucial. It’s extremely difficult to do – but something that must be done.

If you work with your friends, that’s fine – as long as you make clear that your friends actually need to do something if they want to be part of the team.

#4 – Not giving clear instructions
I’m probably doing this still, but I try harder. Clear instructions are must to have. Giving “artistic freedom” is okay (and I try to give that as much as possible), but you have to define what you want – and define it clearly. Use videos, images, notes, text – anything to make sure that your message is received. Ask the other person “if there’s anything that is unclear” or “if there’s anything he would need to know more”.

Giving clear instructions will save everybody’s time.

#5 – Assuming others will know what you mean
This is related to the previous mistake, but still something to consider. There have been times when I’ve given pretty clear instructions, but after some time I have had to ask why the task wasn’t done – and the answer was something like this: “oh, I was waiting Mr. Other Artist to first do his job – I thought that’s how you wanted it”.

Basically I was assuming something that I shouldn’t have. If your team members don’t have a clear idea if something needs to be done (or haven’t done what “you expected them to do”), then first examine your own actions before judging the other and blaming “how he couldn’t do the job”.

#6 – Not enough resources
Lack of resources are problem for all projects. Not having enough money, time or the right people is problematic and must be overcome somehow. Sometimes these problems can be fixed by simply cutting features (a very good option actually), and taking action to arrange the necessary resources. Money doesn’t come automatically, so budgeting it is needed.

While there isn’t simple solution to this problem, you can still try to estimate your resources before the project so you can decide whether to start working on it or not.

#7 – Wasting money
This mistake can lead to the previous problem. If you waste your money to useless tools that get you nowhere, you are not heading to the right direction. By defining what you really need (getting stuff that you need “now or very soon” instead of buying stuff that you “might need in a distant future”) and getting it when needed, you will have better chances of not wasting your money.

#8 – Not spending enough money
Yet another mistake: I’ve seen people who work part time to earn $500 a week, spending 2 years to a game engine that they could have bought for $200. If they would have taken couple of extra days to work harder at their jobs – they could have saved 2 years in making the engine.

Same goes with physics libraries, network libraries, art, sounds, music – $100 might sound “expensive” for hobbyist, but if you look at your own hourly income, you may realize that by spending some money, you can actually save tremendous amount of time – and money!

#9 – Not learning from mistakes
This is the mother of all mistakes: making mistakes is fine, repeating them not. It’s okay (and necessary!) to make mistakes. That’s the greatest way to learn and improve. Making same mistakes over and over on the other hand is not needed.

Make lots of mistakes, and learn from them. That’s something they call living.

#10 – Allowing artists to help in game design
As soon as you give artists the opportunity to design something to an ancient kung fu game, they come up something like this:

A pig.

Yeh, that’s what our modelers came up when I asked if they could “create a prop that could be broken in the game”.

A pig.

(…to make sure I leave no doubts, I wasn’t serious about this last tip – it was actually a great idea that really helped to make gameplay better. It’s a mistake NOT to ask others for game design ideas.)

New Level Graphics for Edoiki – And a Lesson Learned About Tiny Things


Click here for a larger view

Edoiki is progressing: we have been just contacted a new animator who should get into work soon. There are four different characters to be animated, so the job is not huge – but something that really needs to be done.

One quite strange “problem” occurred when I got the new house. I realized that my plan to have players move only in ground level (their Y position in the world would never be higher than zero – meaning they would keep they feet in ground always) is going to a trash bin. Originally our level builder didn’t plan the stairs… but as they looked cool he added them. We could get rid of them, but as I think they add additional detail they are fine: we’ll just have to set up some code that allows players to get over those steps.

For any non-programmer this might sound quite silly to even talk about a task like this (“shouldn’t it be pretty simple to get characters to go over those steps?”). In reality these kind of “tiny issues” always require time. We have to make sure the network code is fine (we’ve taken care of that), we have to make sure the collisions work properly, we might have to think about how the unit moves when he faces a step and so on.

Or like our artist put it:

it is funny how I cant understand how hard it is to get it up the y axis

It’s almost the same as programmer asking “how rigging one simple character can take that much time?” I know it can take – and I’m sure all the artists know that as well. Basically you have to see things from both sides, not just from yours. There’s lots of tiny things that need to be taken care off.

And that’s probably one of the reasons why some games take 21 hours, and others 21 months to produce.

But now we have a new graphics, and that’s good.

Edoiki Sneak Peek


Sample shot, although this perspective won’t probably be seen in the final game

Our Edoiki online multiplayer game is about to get first animations. We are anxiously waiting for animator to get everything finished. Meanwhile we are working on a simple level editor and starting to put things together for a tech demo.

The first demo will show briefly what the game will look like and little bit of content. There will be very simple game play (which will be completely different in the ‘real’ release), something to test about the technology. And… I’ve learned from the past that at this point I won’t be promising it next week. Anybody who wishes to hear “when it’s available” will simply hear my saying “before the next ice age”.

Putting things together takes time
As the project is progressing, I’ve come to really see how integrating everything together takes time. There are so many moving parts in the project (sounds, music, animations, textures, environment, characters, level editor, code, network code – you name it) and at some point they all must be put together.

Here are couple of practical tips I’ve learned about making integration as smooth as possible:

  • Plan it: This is important. Don’t assume that everything will just magically work with everything else. Plan how you will stick level editor together with the rest of the game. Plan how textures will be dealt. Plan everything.
  • Naming conventions: this is important. I haven’t been strict enough with naming conventions, and this might cause minor delays or problems. I had put some documentation regarding this, but it wasn’t until some days when I had a conversation with one of the artist explaining how all the art files need to be delivered. For example, the assassin character will need to be “assassin.3ds” and the corresponding texture must be “assassin.png”. Not “Assassin mesh.3DS”, not “uv.jpg”. If you need to make changes and get files again, then it’s a pain if you need to rename stuff.

Now I’m continuing with the level editor and hopefully get soon to start putting the tech demo assets together.

And Then There Was… a House

It’s been a while since I’ve told about Edoiki progress, so here’s a new picture of a house for the Edoiki game. I’ve mentioned it several times to our artist, but I can’t but say that the house looks absolutely great in my eyes. I always thought only AAA games projects would have artists that can do stuff like this… and now I’m fortunate to see these talents in our team.

There have been some changes and major things going on (like team structure, milestone scheduling, etc.) which I have not mentioned yet – mainly because I want to wait to make sure I don’t announce things that won’t happen (hint: that last sentence contains a very valuable lesson). In the future I will tell more about our team, and our team members – so that those who contribute to the project actually get the credits they deserve.

Anyway, we are going to publish a public tech demo soon (“soon” here meaning some date between “time right now” and “hopefully before the next ice age”). There’s no official Edoiki newsletter yet, but those who want to get informed when the public tech demo is available (and when we start to offer beta tests) – feel free to subscribe to GameProducer.net newsletter. I will send GP related information (like interviews, sales stats) also in that newsletter, but eventually the tech demo will be announced there as well. The GP RSS feed is also available for those who prefer waiting for the announcement in that way.

In summary: Edoiki is progressing steadily, and we have a good drive going on.

Why Some Games Take 21 Hours to Produce While Others Take 21 Months

I’ve been pondering this question, and it really amazes how much one can accomplish in just 21 hours. The box stacking mini game didn’t take much of my time, but I have poured unbelievable amount of hours to making of multiplayer game framework, mostly for Edoiki. Initially I planned that the Edoiki game would be produced in just few months, but then various events occured (such as lead programmer leaving the house, getting lots of new ideas, chancing the core network code and so on) which have delayed the project for over half a year already.

All the things haven’t necessarily been bad: even though completely re-coding the core network code did took time, there has been benefits as well. It’s now faster to try new things and the server-client architecture seems quite solid. Also, while the programmer left, it has given me chance to learn more coding. There are open issues in Edoiki development: at the moment I’m pondering publishing the game in Episodes. That way I might be able to cut down some features and actually get playing the game faster. This is one open issue, which will get answered soon. I want the game out. All these decisions will have an impact on the project progress.

It’s amazing how much you can accomplish in just few days. And even though a game would take 21 months to produce, it must be finished in small steps: doing 21 hours after 21 hours. If you keep taking baby steps one after another, eventually the game will be finished.

Worrying about how badly deadline was missed, or worrying about the “upcoming workload” is useless. It only gives you a bad feeling and doesn’t help progress. Instead, concentrate on what you can do and take those steps forward. One by one. That’s the only way to reach the place where you want to go: by taking action.

Edoiki Design Improvements and Developer Role Talk

Edoiki gameplay benefited from the presentation

Yesterday I presented Edoiki in a Finnish game design event and while my presentation was simply a white board with green and red dots I got some great feedback and ideas. In the first game mode – without revealing too much – there is going to be an assassin which will try to eliminate civilians.

A very simple idea that I got from Eero Tuovinen (a real mastermind when it comes to game design) was this: “How about giving different targets for the assassin, not just civilians but buildings?” He suggested that assassin could bomb a building and when he the assassin is setting a bomb he becomes visible (normally assassin is invisible to guards). This was a very simple idea (like good ideas always are, right?) but it adds great variety and another strategical dimension in the game. I’m sure that will be added in the gameplay in some way.

I have a list of about 20 new ideas with me and can’t wait to start implementing those.

Funny how people think they are special

Since the event was focused about game design it was natural to hear designers’ point-of-views and arguments. I heard arguments stating how “core gameplay and a good design is probably the thing that makes a game fun”.

I’ve heard different points from somewhere else, and I couldn’t help thinking an imaginary conversation between different game developers. If a game designer, programmer, artist, marketing specialist and a game producer would sit around a table, the conversation might go something like this:

  • “If the core game mechanism isn’t designed well, no matter how nice graphics you have it simply won’t work”, the designer starts.
  • Programmer would interfere by saying: “everybody can get ideas, but somebody must actually take action and code those features to make sure the game ever sees daylight”.
  • Graphics and sound artist would continue: “okay, you’ve got some boxes moving on the screen but without great voice acting, music and sounds it’s not possible to reach a great level of immersion – game needs to be visually stunning to work. Without artists you cannot reach that level.”.
  • Marketers adds “okay, you might have the greatest game play, the greatest code and the greatest visuals but if you lack marketing – who will buy your product? Marketing is the most important part to make the game sell“.
  • Game producer or team leader would add: “Okay, you got all the different pieces – but who is going to make all the parts work together and make sure the project is actually finished before the next ice age? Without a great leader, a project won’t succeed”

Who is right?

I believe everybody is right. Producing a video game is teamwork. I think the designer is right about stating that the gameplay and mechanism must be designed properly. Every game production team will benefit from having a designer in the team or at least reading about game design.

The programmer is also right. If project is just about having nice ideas it won’t get very far. Programmer is definitely a key person in the team.

What about artists then? Some people might say that they aren’t needed (and all 3D games should be done in 2D) but I believe there is no reason why game couldn’t look good. And nowadays art and visuals can actually play a big role in games: shadows and lights are good examples about the artistic elements that can be used in gameplay and to add depth in the game. I think artist is right here as well.

And so is the marketer. He is right: if your game is not promoted in any way, and nobody knows about it – then it won’t sell. It might be a fine game, but it won’t be a very successful product if it lacks marketing.

Are game producers needed? Well, yes. Somebody must take the lead and manage the project and lead the people. Producer is also right. Sometimes there must be somebody who says what happens next and makes sure the project is finished.

Naturally in indie (and other) projects one man can have several roles: artist, designer, marketer, programmer and producer hat might be worn depending on the situation. Whenever you need more than one person in a project, it will change. There aren’t (always) no right or wrong answers, and there doesn’t need to be. It doesn’t really matter whether the designer is right or the programmer is right, what matters is that the project is done and finished.

I believe everybody is right.

A Demo Is Worth a Thousand Images

When you present a game it’s okay to tell about the game, show images and video clips but nothing beats letting user experience and evaluate the game by themselves.

Yesterday I talked with Edoiki game artist after he had read my idea for a new game mode. I had explained the game mode idea in our forums, but before artist had a chance to say anything I asked him if he would like to test the demo. “Sure”, he said.

The gameplay was made roughly in just few hours and all the unit graphics on the screen were placeholders, and even the user interface code was far from being polished. Before we could start, I needed to explain some rules and meanings like “blue color means dead unit”, “red is for civilians” and so on. In this alpha prototype there was nothing expect the core game mechanics made for two players.

We took couple of quick matches that took a few minutes each. Here’s the comment he wrote to our project’s discussion forum:

“hum-hum, game description text seemed a bit vague for a description and i was just about to complain on the down sides of it (as usual)…but once we got playing with the actual game, it all were clear and obvious, and it was a whole bunch of fun and excitement too…seriously, it ROCK’S AND KICKS (bottom)! Brilliant!!! “

While I was pleased to see his reaction, I must say that this lesson about letting user experience the product really hit me. Design documents are okay, but before players can fully understand what the game is all about you need to have a demo.

Some marketing specialists might recommend “showing instead of telling” but I really think “experiencing instead of showing” beats that. Rather than just giving a sales speech, let the customer experience your product.

Very Simple Trick That Will Save Hours When Balancing Your Game

When developers write games they might forgot that it’s not necessary to store all the game data in the actual code. Some programmers simply use arrays to store information about weapons or units. I really recommend using Excel or some other external program for this. If you need to store values for real-time strategy or for a role playing game (besides some other genres) then it’s very handy to use some sort of spreadsheet for this, instead of trying to manipulate arrays.

When you store game information (like weapon or armor attributes) to an external spreadsheet you can export them and use the exported file in your game. Besides, when you use some external file format (like .CSV) then you also give players easier chances to create mods for your game. It’s very easy to change weapon and armor values when they are stored like this.

Here’s an example pic on how we are handling strikes for Edoiki game.

When I need to change something, I simply edit values and export .CSV file and the game reads the values using a small code I’ve made. Believe me – it comes extremely handy when there are lots of modifiers and you need to balance game.

Eidoki

I’ve encountered a small problem with the name of the game Edoiki. Some people say “Eidoki” instead of “Edoiki”. I decided to register eidoki.com and make it point to edoiki.com to make sure people who try typing the URL directly will find it.

Letters E and I are bit difficult in names. “Weird” or “wierd”… which one was it? Also word “gray” can be problematic. It’s different in USA and UK. Depending on the country you use “grey” or “gray”. One solution to problem is simply ignore it, or register couple of additional domain names to make sure people who type your website URL incorrectly will reach your site right away.

I don’t have that much experience on domain names, but since several people have typed the game name incorrectly, I decided to spend couple of bucks to make sure I have the domain name space covered.