Archive for October, 2008

« Older Entries

The One Thing That Makes Your Indie Company a Real Company

Wednesday, October 29th, 2008

Get a company phone.

I remember how I felt when I founded my indie studio few years back, and bought the ‘first office cell phone’. Suddenly, my indie studio seemed like a real company. In my mind, it somehow linked that my copmany is more real one. After all, now you could even make a phone call to the company. You could reach somebody.

It felt like a concrete step years back, and I really enjoyed buying a new phone only for the company.

If you haven’t own a company phone, you don’t know what it means. It just might make a mental difference in your work. The difference might be tiny, but who knows, maybe an important one. It might adjust your thinking that you now really have a real company.

If you run an indie studio, and don’t have a phone yet, get one.

P.S. Nokia of course…

Posted in Business, Fun Stuff | 11 Comments »

Your Game’s “Useless Tiny Details” Might Help Promote Your Game Big Time

Monday, October 27th, 2008

Have you seen this video where somebody is presenting how World of Warcraft character animations offer variety of ways for dancing. In terms of gameplay, something like “dancing animation” might have close to zero gameplay value (after all, it doesn’t give you points or rewards when you cycle through these animations), they can be valuable for both entertaining the player – and of course they make a good videos.

Watch the following:

At the time of writing, this specific video has a view count of 11,161,676. 11 million views. That must be close to a youtube view count record or something. These kind of videos make great viral marketing vehicles, and they help make the game more popular.

When thinking of small details in your product’s game play, it might be worth remembering that the sum of all those tiny features might end up being pretty big.

Posted in Practical Marketing, Videos | 7 Comments »

The One Game You Cannot Pirate (Kind of)

Friday, October 24th, 2008

So, the pirate ship took a maneuver and evaded from the horrible fate of getting sunk. I was checking some discussion that was surrounding this topic, and couple of particular comments caught my eye.

One on the ‘pirate side’ said that:

If you make quality content, people will pay for it.

I have mixed feelings about this. I’ll tell more after you see the following:

People are sick of paying too much to view or listen to what is ‘a pile of crap’ half the time.

Personally i wouldn’t pay to see half the stuff i download. If i didn’t have the option to download i wouldn’t buy it, therefore no money is lost as i wouldn’t buy ‘item X’ in the first place.

“Personally I wouldn’t pay to see half the stuff I download”? I suppose this means that the other half of the stuff he has downloaded, he is willing to pay for?

The problem with this approach is that I’ve actually seen only like one or two incidents when person (1) first pirated a copy of software and then (2) purchased the real product.

Both of those times it was me doing it, and I haven’t been using pirated software in years now.

When I’ve asked some of my friends about this, they have reported similar incidents – but they also give the “I wouldn’t pay for the crap” excuse. The thing is: if they purchase 1 product out of 10 000, enjoy 50% of the products and say “I wouldn’t pay to see half the stuff I download” then something is not matching.

If they don’t like 50%, but like 50% of the stuff – why they are only purchasing much less than 1% of the stuff? If their excuse is “I wanna test first see if I enjoy it before I buy it”, then logically if they enjoy the pirated copy, they will also buy it? Right?

That’s the reason why ‘if you make quality content, people will pay’ won’t work always… but I do think it’s the key issue to concentrate: developers should have their focus on making quality content, not on ‘how to fight pirates’.

After all, the more we focus on piratism, the more it expands. The more we focus on quality & our paying customers – the more that expands.

The old busines smodel doesn’t work in today’s world
One another comment came from a pirate:

It doesn’t mean an end at all, it’s just the old business model doesn’t work in todays world.

I agree to some extent, and I got 3 visions where this could lead:

#1 – More console games, less PC games I don’t think this will happen, but I think there’s slight chance that at some point PC developers start abandoning the platform when they see that console sales are doing better. This has been said for the last couple of decades, so I don’t really think that this will happen. I just mention this as one not so likely, but possible way. (Naturally they will get back the moment people start to share pirated console games… technology won’t save anything – pirates are always one step ahead)

#2 – More ads in games: Other option could be that there will be more ads in games. The natural response (of course) from pirates is that they will create ripped versions where these ads aren’t shown. This model might die before it’s born. Maybe.

#3 – Focus on online gaming: At some point it might happen that our games are played solely on servers, where you only purchase a client for the game (Think year 2019 rather than year 2009). If you want to player a game of Tetris, you’ll contact to a server which will give you information how the game goes. World of Warcraft is already doing this (and it’s kind of the only game type you cannot pirate, since you need a server) and we might see more of this type of games. I know there’s already pirate-servers for some online MMOs where you can play using a pirated client, so… who knows.

So, how will it end?
I think some of the pirates are giving legitimate reasons why they are pirating their products. Blocking, banning, DRM won’t be the way to fight against the pirates. Fighting pirates most likely just backfires: you end up alienating your own customers.

One good example comes to my mind: I had this DVD that I bought. In the intro text there’s “pirating is illegal, blah bla blah, don’t pirate”. The legally purchased copy I have has this 30 sec intro which I always need to watch when I play the movie. Do you know what the pirated copy has done better? It has removed this part (surprise, surprise!). So, now the pirates can watch the movie right away (without seeing “don’t pirate” messages), but I (who bought the darn thing) am stuck watching the darn intro every single time I play the movie.

Piratism will be here to stay, and it shows us that we need to adapt in the situation. Old business models are getting less useful, so we gotta find a way to use new ways. It could mean more advertising, paid content, monetizing using special collector editions, or even having servers like in massively multiplayer online games where pirating gets much more difficult.

Whatever it will be, fighting won’t be the way to win.

Just like in real life.

Posted in Game Development, Philosophy | 7 Comments »

This Is a Small Step For a Zombie, But a Big Step For a Developer

Thursday, October 23rd, 2008

This week I’ve been working on the physics system for my game. Initially I was wondering a about how much work it would be, but so far the progress has been as good as I could have hoped. While I’ve been getting physics simulations (and faster collision detection that comes with it) I got couple of good practices that have been helping me so far.

Prototype outside your game (at least some features)
Okay, this might be pretty clear to many developers, but not perhaps for everybody. Some developers might try prototype inside their game. This means loading the levels might take time, compiling might take more time, and testing might take long time (unless you happen to have some sort of real-time scripting system in place – which probably won’t help when integrating physics in the game).

Anyway – instead of trying to get boxes and spheres move in the game, it’s better to do prototypes that first work outside the game. This worked for me, and made doing physics related code faster.

Break big changes into smaller changes (and prepare for changes)
This tip might also seem quite obvious, but it’s easy to forget. I prefer working on small steps – completing little by little than by trying to do a dramatic change all at once. When putting something like physics in the game for the first time, it probably requires quite big changes. Instead of trying to get all done at once, I split the big task to smaller pieces. Instead of changing the whole movement code, I simply added physics and let them work side-by-side with the other code.

After I saw that physics stuff was working, I started removing the other code little by little (or ‘module by module’). This way there wasn’t like a 3 day period when I could not have been able to build and test the game, but rather so that the game could be tested almost all the time (since I was making sure it was working after I was doing changes).

Do things only once…
I had done a very rough level editor for the game. When I started doing the physics system, I started to wonder if it was worth the extra effort to have separate level editor. I realized that with some changes in the main game code, I could integrate the level editor inside the game.

I decided to have level editor inside the game, and within just a few minutes I was able to save levels inside the game. I need to move some functionality from the old level editor code to the main code, but with this change, creating levels (and testing them) without external editor will be a really pleasant to users as it all can be done inside the one program.

Pretty funny thing is that I’m quite certain that the level editing might work during a multiplayer session (if you play as the server): you could be editing levels while playing the game with others. No idea if that’s any useful feature (or whether I intend to leave that in the final version since I have no guarantees how stable it would be), but I think it could make a fine feature when tuning the gameplay.

…and surprisingly good things will follow
One another good thing occurred. When putting level editor inside the game, I realized that I had (accidentally) created a save & load functionality. I could use the same code that’s used to save levels, to save (and load) player progression. Saved files would really be levels, with certain starting conditions.

The floating zombie
Oh, and here’s the video I made after seeing the first physics code inside the game. I had first created several physics prototypes outside the game (without using any models from the game) where I could move, jump, shoot and so on, and then started porting these prototypes to my game. You can bet your left leg that seeing pieces from the prototypes inside the game felt darn good (I know in this video all the 3d models are in messed up positions and the physics models aren’t done, but at least I’m controlling a game character and seeing physics working inside the game).


Please notice that this is very, VERY early video where the physics models, animations & 3d models don’t match at all.

Posted in Game Development | 5 Comments »

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

Tuesday, October 21st, 2008

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:

Posted in Game Engines & Tools, Videos, Zombie Game Project | 4 Comments »

The Nicest Fan Comment I’ve Ever Received

Monday, October 20th, 2008

I know I mentioned similar stuff week ago, but I couldn’t resist mentioning this. I’ve always been thinking that the goal of making a game is not to please everybody. The goal is to please some gamers for some time. There were some players that didn’t like the switch from the FPS view, but most of the people I’ve talked with have been pleased with the results.

Here’s one of them.

I was talking with one of the Dead Wake zombie game players and he said to me:

13:17 – player: i think i might cry when dead wake comes out
13:18 – player: my eyes would not be able to handle the awesomenessneesss

After that I told him a secret that “I will be integrating physics engine to the game in future versions”, and his reply was:

13:20 – playeR: OMFG THE CRYING HAS ALREADY STARTED….. damn you sob sob

Heh.

Posted in Fun Stuff, Game Development | 4 Comments »

Hmm, I’m In a Strange Situation: I Can’t Stop This Company From Sending Money to Me…

Sunday, October 19th, 2008

I’ve been Big Fish Games affiliate for some time, and I realized that I can’t stop them from sending payments to me. I’ve promoted the program (like I’m doing now) and it’s started to grow on its own. It’s still not a “huge money tree”, but the nice thing is that it’s growing without me need to watch it all the time, and it buys me a lunch every now and then.

From all the affiliate system I’ve tried I think Big Fish Games has the only one which comes with a snowball effect: you put the program in motion and you can’t stop it.

Not that I’m complaining or anything.

Posted in Business | 4 Comments »

One Useful Agile Method For Project Estimations

Saturday, October 18th, 2008

I’ve done (IT/games) project work for almost a decade, and one of the trickiest thing has been (accurate) work time estimations. I’ve been participating in doing estimates for small and big projects, and sometimes there has been more time to do these estimates, sometimes less time.

It’s a tough job
It has been quite typical that in a long run, estimates are really tough to do very well. If you give estimates in “how many hours it will take”, it feels like there’s always something that might be missed. Sometimes there might be new bugs appear that take time. Or, the code maintenance gets trickier. Or something else.

Agile methods help
One useful approach for this comes from agile methods. I think any team (whether they have interest in agile methods or not) can use this system for better estimations.

The idea is to use relative size estimations, not absolute size
It’s been suggested that it’s easier to estimate relative sizes instead of absolute sizes. Instead of saying that finishing certain task A will take 3 days and task B takes 6 days, you could say that task A will take 3 points worth time, and task B will be approximately double of work, or 6 points.

Take a look at the following picture:

Absolute estimation
How many proper blue and red poker chips there are? In this case could go through them one by one and say the number but it would take time and you might still make a calculation error, or some of those blue chips could be damaged and should not be taken into account. Some of them could be missing from the picture. If you want to know the absolute number of blue chips, it would take you some time and the number could still be inaccurate. Same goes for red chips. Or black. Or green. Or whatever colored chips there might be. You’d be counting the chips all day, and still make errors.

Relative estimation
Now, how many blue and red poker chips there are if you use relative estimation? You could say that there’s about half (+50%) as much red chips as there’s blue chips (for example, you could say “10 points worth blue chips, and 15 points worth red chips”). Of course you could wonder if there’s more of those black chips (and take a better look and ask others) and say for example that there’s 13 points worth red chips if you feel that way.

Again there could be some broken blue or red chips, but if we are measuring the relative size it has lesser impact. If for every 2 broken blue chips there’s 3 broken red chips, our estimate would still be correct. If on the other hand we see that there’s more broken blue chips compared to other type of chips we can re-estimate the points for the blue chips for example.

Back to game development: The idea is not to know how many hours one task will take. The key idea is to establish a common baseline for making evaluations (as in “this task takes 2 points, this one 1 point, and this one here feels 3 times bigger than the previous 1 point task so let’s call it 3 points task”) and use points instead of hours.

Getting to hours
But what if you want to know how much time it takes? Patience grasshopper.

The ‘how many hours it takes’ will come from experience. The goal is to keep estimating using points, and then track your progress as time goes on. After some time, you will be able to say that “okay, I spent 200 hours doing this, and finished 10 points worth of features. From this I can say that 1 point – in a long run – is approximately 20 hours of work.”

Let’s take an example:
This can be useful also when taking into account bug fixing. Let’s suppose you’ve estimated that coding a module takes one week. You finish the module in 5 days and are happy with the results. The bad news are that in the next week you spend 2 days fixing unexpected bugs that were found by the testers. Also, one more day is spent reviewing and refactoring the code since there were some problem areas that needed bit more work. That means the estimated module took 8 days instead of 5. The last 2 days you spend coding some other smaller module that was estimated to last 1 day.

With a points system you could have said that the first task takes 5 points (for example), and that the other smaller task takes 1 point. Your estimate is bit off (since the first task took 8 days, and the other 2 days – which means the relative sizes are 4:1.) but you can’t always know exactly how many points something takes and you can trust that this number gets better as time passes.

After a few more weeks, you could give a pretty accurate number that on average you managed to finish 6 points worth in two weeks, which means you’d have basis for evaluating how much work you can do.

The more I’ve been using this type of estimation, the better I feel about it.

For those of you who are interested in agile methods, I suggest reading Mike Cohn’s blog (and his books). He has plenty of good information on how to use agile methods.

Posted in Project management | 6 Comments »

World of Goo (And Who Dares to Say Indies Can’t Make Quality Games)

Thursday, October 16th, 2008

World of Goo, made by two guys.

The product quality looks stunning.

Take a look at this video.

Dang, they say it’s ‘region free’, but at least I couldn’t get the demo in my hands… Thanks Petri for the World of Goo download link.

Posted in Stuff | 7 Comments »

I’ve Created a Monster (Wicked Marketing Plot Spreads…)

Wednesday, October 15th, 2008

Yesterday I mentioned that I was spraying Dead Wake banners in Half-life 2, and showed couple of images about it (just updated images by the way, so check it out).

Well, today I wake up and saw comments that “we’re gonna do this too!”. Toni even showed a screenshot for his Taboo Builder game. Here it is:

Don’t know if some other people are already done this type of marketing earlier, but in case not: I wonder if I want to be remembered as the guy who brought spam in Half-life 2…?

P.S. If you happen to have a shot where you spray a banner inside Half-life 2, please email it to me and I’ll put it online (this offer expires whenever I want to, so please do this right away)

Posted in Game Development | 6 Comments »

« Older Entries