Archive for March, 2008

Oberon has done a great job!

Friday, March 21st, 2008

My two favourite portals for selling games through are currently Big Fish Games and Oberon Media, although really Oberon is an “aggregator”. This means that they collect games and give them in the right format to other portals like AOL and Yahoo who cannot be reached by individual developers like me. Reflexive Arcade also deserves an honourable mention – they are great to work with and make good sales, but Oberon has sold more copies for me.

I can’t go into specifics because it would breach my contract but I was EXTREMELY pleased to find out that Oberon sold a four figure quantity of my Holiday Bonus game this Christmas. They pushed it onto some big portals like AOL and really delivered the sales. It helped that the game converted very well too (again, sorry can’t give specifics) – perhaps that fact that I overhauled it in December to make the sound run smoother on non-XP systems and fixed a few minor bugs helped too. So anyway, I’ll soon be receiving a nice big, and frankly unexpected, royalty cheque.

Of course the thing to bear in mind with Oberon is that they can’t pay as high a % royalty as other portals because they themselves are only paid a % of the gross selling price. They make up for this with volume though.

I find it interesting to track the Royalty Per Unit on portals to see how much I actually make of the $20 selling price. You get almost $8 from Reflexive because they don’t discount their games and they pay a healthy 40% royalty of the net fee (this information is publicly available so I can tell you it), and of course if you sell your games on your own site, you’ll get $20 per unit minus processing fees (normally around 10%), so like $18. Big Fish Games runs a “Game Club” where customers can buy your game for as little as $6.95 so your RPU is going to be a lot lower, but again they make up for this with a high volume of sales – also it could be argued that the Game Club members wouldn’t have bought anything at $20 so any money is better than none. Over the last couple of years I have watched the ratio of Game Club to full price sales increase dramatically – I can’t mention specific percentages (contracts again, sorry) but it’s a very high percentage and I know what the average RPU is too. Other portals often sell at full price with the odd discount scheme running occasionally but I haven’t found any of the others to generate that many sales to be honest, but I haven’t tried them all yet either – I’ve never got a game on Real Arcade for example.

150 Game Framework sales!

Thursday, March 20th, 2008

I reached that magic number a couple of days ago and I’m really pleased. I’ve been selling the Grey Alien BlitzMax Game Framework since may 2006 (nearly two years ago) and it’s gone from strength to strength. I’ve personally used it for 3 of my games including the top-selling Fairway Solitaire and many of my customers have made games with it too.

In January I set up a forum for framework customers and this has proven a success – in fact it wasn’t even my idea to set it up and I also delegated the task to someone more competent than myself! Now forum members can help each other and also show off their creations. Plus they helped me solve some Mac technical problems, which was great.

Making a framework is essential for any game developer. You need to put all your core reusable code in some special files that can be used (and improved) for each game you make. After writing a basic framework for three solid months I realised that it was pretty neat and I wondered what would happen if I tried to sell it. There was an instant demand for it and I was pleased to sell loads of copies. It continues to sell every month (the fact that I keep releasing real games with it helps) and is generating a nice passive income for me (over $8000 so far). Plus my customers make suggestions, spot bugs and help me to solve technical issues – this has made the framework way better than it would have been if I had kept it private. When I first sold it I did consider if I should keep it private in case I gave my competitors an unfair advantage but I thought that really there was enough room for us all in the market AND I’m encouraged to stay one step ahead and make great games!

When I hit 150 sales, I ran a little competition on the Blitz Forums where I said that I’d give a full refund to one of my next 3 customers chosen at random. The 3 sales came in two days – nice and quick. I ran the same competition before when I’d made 100 sales so I knew that it worked (it generates revenue and exposure). Is there some way you can encourage people to buy your product with a competition or a temporary discount? I guess the 3 people that bought it reasoned that they stood a 33% chance of getting it for free which is pretty good odds for a competition!

A big thanks to all my customers for your continued support, and good luck with your games!

How to supply art ready for programmers

Monday, March 17th, 2008

I’ve worked with quite a few artists now and I’ve realised that if game artwork can be delivered in a certain way it really speeds up my job as a programmer, and ultimately speeds up the artist because I don’t need to email them with unnecessary changes.

There’s nothing worse than spending hours laying out a screen only to have to spend hours repositioning it all again because new art has been delivered that has needlessly changed size or its position has changed within the image frame! Or how about having to figure out which image is which because the artist has changed all the file names? Or that the shadows and glows have been truncated and look bad on-screen. Or that the images look blurry because they don’t have even-sized dimensions?

The list of potential pitfalls is quite big and so I’ve made a list of requirements, which if the artists can comply with, will benefit the whole project as follows:

Files Names/Types

– Files to be named logically and the names shouldn’t change in future revisions so that I can plug replacement graphics directly into my game without having to rename them first.

– Instead of using spaces in filenames, please use the underscore character “_” OR capitalise each word e.g. GameScreenBackground.

– Always supply images as 32-bit pngs (24bit + 8 bit transparency) unless we can get away with a simple jpg because no transparency is required e.g. for static single layer backgrounds.

Image Sizes

– Try to reduce art dimensions to power of 2 numbers e.g. 8,16,32,64,128,256,512,1024 etc. Why? To save Video RAM (VRAM). Video cards only use textures with those dimensions so if you make a 129×257 texture the video card will round it up to 256×512! This is a huge waste of VRAM on lower spec machines. Ideally I try not to load in more that 32MB of textures to VRAM at any one time so that my games can run well on older PCs.

– The maximum size I can use safely is 1024×1024 because many video cards won’t handle textures bigger than that.

– Make sure that all dimensions are EVEN numbers. If I try to draw an image with an odd numbered dimension in my game, it will come out blurry because the centre of 31 is 15.5 for example (not a whole number).

Graphic Placement

– Centre all graphics/buttons/text as precisely as you can in each image based on the solid portion of the graphic i.e. ignoring shadows. This makes it easy for me to place the object in the game and if you send any replacement graphics later on, I won’t need to adjust the coordinates due to the centring being different (which is a pain).

– Always leave an empty 1 pixel border round each image. If any graphics are drawn right at the edge of an image and I later try to draw that image at sub-pixel coordinates, nasty anti-aliasing artefacts will appear.

– Try not to truncate any shadows or glows when cutting the image out. This is quite a common problem and can be easily tested by temporarily using a solid background like black to test glows and white to test shadows.

– Don’t leave too much blank space round buttons because the mouse over code treats the blank space as solid.


– If you are making a layered image of some kind, please let me know the Z order of the graphics so that I can draw them in the correct order (no thinking required on my part).

– Try to keep as many of the components of the artwork as possible in separate layers in case we need to adjust a small portion of one layer later on.

Replacement Graphics

– Where possible make sure that replacement graphics are a) the exact same dimensions, b) start at precisely the same x,y coords in the image, c) the same scale if applicable, unless there’s a good reason why a change has occurred (let me know of any changes to size/placement/scale that so I can alter my code). This enables me to plug them straight in without having to adjust them or my code first which is time consuming when we iterate a lot.

– When sending a batch of files, please zip them up. If you are sending updates with a date or number in the zip file name, please use the same format each time. I recommend using the date in reverse e.g. YY-MM-DD because when file names in that format are sorted alphabetically they also end up in date order which is very handy.

– Every time we make a revision it’s a good idea for you to leave the old file alone and save a copy with an incremented version number on your system in case we need to go back to a previous version.

Anything else?

Phew, quite a big list! It may be hard for the artists to remember everything at first but with gentle leading in the right direction the project will flow much more smoothly.

I hope that you found the list useful and I welcome additions/comments.