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.

Environmental Artist (3D Modeler) Wanted For Edoiki

Our 3D artist Michael is leaving our “band” (because “life happened to him”) and while this was bit sad news to us (he was doing some awesome work) there’s no other thing to do than to move on. The biggest lesson so far in game projects is that people are the biggest factor. In the end, it boils down to having a great team that sticks together.

Edoiki game is coming along nicely and now we are after an environmental artist who is willing to work for royalties (up to 20%).

You need to be capable of doing Japanese/Chinese style quality buildings, foliage and props like in the picture below (For another example image, please click here – you should be able to create buildings and items like in the picture.)

You don’t have too be a pro or dedicate most of your hours in this project, but you need to do some hours and meet the following requirements:
- Modeling skills (3D Studio Max will do fine – as long as you can get us .3ds files everything is fine)
- Texturing skills (you need to be able to texture the models – with similar style as presented in the above images)

Your job
You would be responsible for creating outdoor objects (such as buildings, trees, rocks etc.) and naturally helping with the game design and testing as much as you want.

Brief project description
Edoiki is a Japanese themed single-player & multi-player game. The core idea lies in a tactical samurai game, where disguises and sneaking plays important role.

Contact me
If you got interested (or know somebody who could work with us), please contact me and please put links to your work samples or portfolio.

New Edoiki Game Screenshots

I posted some Edoiki screenshots to the new forums. In the shots there’s some new ground texture and some messing with the lights in game. (Yeh, maybe we should get torches – they are always look great in games). It’s good to show progress – it’s good for the team, and good for yourself.

We also solved the animation problem by sequencing animations in one file. I mentioned these problems in an earlier post and I’m glad that they are all sorted now.

That’s it for now, more articles and Edoiki game stuff coming in the future.

Update: I just realized that people needed to register to the forums to see the screenshots, I’ve updated the forum configuration and now the screenshots are visible to everybody.

Expect The Unexpected

I’ve mentioned our issues with game animations a few times in the past, and to be honest: I didn’t except animations to cause us that much work in the project. I’m glad we’ve found a professional animator in the team, but there’s still problems to solve before characters are done.

In fact, now we have finally managed to export animations in the project – but there’s another problem. Now the animations work when run alone. When we combine two different set of animations to one character, it won’t work. We are checking out the Max hierarchy and trying to find out what might be causing the problem when the game engine loads the additional animations. Since two files aren’t working, next we are going to put all the character animations in one file – and let the engine splice them properly.

There are unexpected moments in game production, and while it’s almost impossible to know what might unexpected might happen – it’s good to expect that something won’t work as planned.

Expect the unexpected, and when that happens – find the solution.

Keeping All The Balls In The Air

One of the most important things producer’s need to deal with are the people. Today I got bit “bad news” since two of our artists are doing work for other projects as well. They get paid well for these tasks so it’s understandable for them to do other contract work. These type of stuff happens when you deal with people.

For me, this means couple of things:

  • Put in detail the rest of the graphical elements: I wasn’t expecting the level modeler taking other contract work at this point, so it’s crucial to list all the elements we need to finish the game. This will give us better picture about what we need from the artists.
  • Cut unnecessary features or elements: While I revise what’s need to be done, I’m also going to take a very close look at all the planned features and think tough what will be done. This will help getting the whole project finished sooner.
  • Communicate more: Both of the artist will still be working with our project, but I need to be sure that the guys share openly about their plans – and how much they can do for the project. By this, I hope to ensure that there won’t be surprises.

While currently it feels bit difficult to keep all the balls in the air simultaneously, I’ve learned from the past that the difficulties are where you really learn.

This is a place for growth – and place to take steps forward faster.

One Way to Improve Gameplay

It’s quite typical to get stuck with some “tiny” gameplay problems when working on your game. These problems can be anything like how smooth the camera should move, what kind of particles to use in certain situations – you name them. There’s no end to the features that might need tweaking.

One simple way to find answers to these problems is pretty obvious: take some time away from the code, and check out how others have solved your problem.

Recently I have been thinking about how exactly the camera should work in our Edoiki game. One player will control the assassin, and other player will control several guards. The game is tactical it uses “far view” (like you can see in any real-time strategy game). I thought that since player 1 controls only one character, it might make sense to attach the camera to the controlled character. But because player 2 can control several character (and needs to change the control) it might make more sense to not attach the camera to one character, but let player freely move the camera.

There are some are some tactical benefits for having free camera instead of having an attached one so this needs to be tested. We might end up with some sort of hybrid in the end.

To get more ideas, I thought I would download some other game demos and check how they have dealt with the camera. I won’t necessarily take other people’s ideas like that, but at least by checking out what others are doing I can get another perspective to deal with this problem.

Bottom line: simply go to some gaming site, download some game demos and see how they’ve dealt with your problem. That won’t take much time, but it might prove to be a really fast and fine way to solve some tiny problems that seem to get into way.

Animator Wanted for Edoiki

I have a job offer for animators. Basically what I need is:

  • Somebody with decent animation skills (no need to be pro, although total beginner is not ok either)
  • Need to rig and animate 5 characters: 3 human characters (an assassin, a diplomat, a guard) and 2 animals (a pig and a raven)
  • There will be about 3-4 animations per character (such as: idle, walk/sneak, attack, death)
  • The exported animations should be in .3DS format, or alternatively in .B3D format (there’s a free pipeline to export .B3D files from 3D Studio Max)
  • Deadline: these animations should preferably be done in July 2007 (or in the beginning of August)
  • If you have previously worked as an animator at AAA studio, then our budget is probably not big enough for you. If on the other hand you don’t live in a high-income country and can meet the other requirements, then you most likely are somebody we looking for.

This is a paid position. We have a limited budget and preferably would like to pay the sum in parts (this can be negotiated). Alternatively, if you also have 3D modeling skills (so that you could do more besides animations for the game) then it could be possible to negotiate a place in the team – with royalties.

Animators – contact me
If you got interested, please contact me and send me an example animation you’ve created. Please include your rates in your proposal (and a link to your website if you got one).

The reason we need an animator
Our Edoiki game got some animations done by solving some tiny problems… just to realize that the animator was using ready made motion capture files from Studio Max. Basically this means that we cannot use those animations for legal reasons.

Now we need somebody to do the animations.

Update: We found an animator, so no this position is closed. Thanks everybody.

Tiny Things Sure Can Be Annoying…

We are processing with animations for our Edoiki game and our outsourced animator has got almost everything working fine:

  • Exports are now working nicely (after little bit tweaking)
  • Motion capture helps us to get top quality animations
  • Animations are getting done in a fast manner
  • Price is good

Almost everything is fine: the animations are nice, and our animator is doing a quality job.

There’s just one problem…
… we cannot get the motion capture to “keep the character in one location”. Currently the character is animated nicely, but he is moving away from origo coordinate – and this causes problems in the game. In the game the character moves away from the spot where he is supposed to stay so that the engine can handle the movement in the play field.

Death animation is okay (since we need to play it only once), but sneaking doesn’t work the way it should (because we need to loop the sneaking).

Our animator is checking on this, but any help (or ideas on how to solve this problem) are gladly taken. It’s a bit frustrating (not really – but a bit) to get very close to the perfect situation, just to see some small issue is messing up everything.

Tiny things sure can be annoying sometimes.

The Secret of Great Multiplayer Code

While we are waiting our animator to make our characters move, we managed to put most of the objects (diplomat, props, the famous pig among other thing) in the game. The multiplayer code received some additions as the level editor system was being integrated with the rest of the game. This caused some problems in the multiplayer code: basically the server crashes now and then as client sends invalid information (I’m investigating on this).

I started putting heavier methods to debug the multiplayer and realized that I should have done this much earlier. I realized one secret of a great multiplayer code: making sure your multiplayer code can easily catch errors.

I will get back to debugging and tracking the crash problem. It might take some time to find it, but at least now I’m putting even more effort on making the system stable.