Archive for the ‘Game Development’ Category

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.

Layers

- 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.

Passion Vs Profit Photos from Casuality 2008

Saturday, February 16th, 2008

Whilst I was at Casuality 2008 in Amsterdam I attended lots of great lectures. One was by Reflexive and Enkord and was called “Passion Vs Profit”, a topic which particularly interests me.

Basically it can be summed up simply as: do you make games that you really want to just for passion, or do you calculatingly make games just for profit? Or is there some kind of middle ground?

During the presentation, Reflexive and Enkord explained which of their games were made for passion and which were made for financial reasons (also some were made for both reasons). They showed this on a simple diagram where passion was on the left and financial was on the right. Then, very interestingly, they revealed whether those games were a financial success or not based on if they had made a profit or loss. This was shown in another diagram beneath the passion/financial one. I took photos of Reflexive’s and Enkord’s diagrams as follows (you may wish to click them to view the full-size images):

Reflexive

Reflexive

You can see that some of Reflexive’s games have indeed made a loss; in fact the worse losses were the games that they made purely for profit! One of their most passionate games, Ricochet Extreme has done extremely well, and interestingly so has Big Kahuna Reef, which they made for both passion and financial reasons (in fact they said that the team was led by James C. Smith who was very passionate about the title but they were sure it would also be a financial success. James really helped to motivate the whole team who just jumped straight to action and made what they felt to be a great game, and I guess that’s reflected in the great sales).

However, it should also be noted that two of the games they made for passion have barely broken even (Wik and Swarm). I also asked them about The Great Tree and they said that it was made for Passion AND Financial reasons and that it seems to be doing pretty well but they don’t have enough data yet to say how well (or they didn’t really want to tell me).

Enkord

Enkord

Enkord had a different story to tell (well sort of). Because costs are so low in the Ukraine, EVERY game they have made has made a profit - this amused me :-) (I thought it was cool). As a side note, all of my games have made a profit too (some much smaller than others). However a similar pattern is revealed to Reflexive’s - the games that they made for financial reasons only (trying to anticipate the market) have made the least profit, and the games they made for passion, Clash ‘n’ Slash and Emerald Tale, have done very well. Also a game they made for Passion AND Financial reasons, Jewel of Atlantis, has done very well too.

Conclusion

So it seems that when these companies have tried to anticipate the market and have made games purely for financial reasons, those games have not done very well (this may not be the case for all developers of course, especially those now making Hidden Object games). Games made for passion can be hit and miss but when they are a hit they do very well. Perhaps this is just due to the extra care and feeling the developers put into the game.

Also, where passion and financial has been combined so that the market has been studied and a game has been programmed to meet that demand AND the developers have really enjoyed making it, those games have done very well. Personally I think this is the best route and it’s one that I follow. I’ve enjoyed making my games a lot even though they were done for financial reasons also. I played Bejewelled a few years ago and thought it was a great game; I thought that I could improve on it and I had really good fun programming my match-3 clones. Furthermore, when I first played the online version of Fairway Solitaire I was instantly hooked and knew that I’d have a great time programming the downloadable version of the game. I put a lot of passion into that game and I think that it shows; and, bearing out my theory, the sales were great too.

I hope that you’ve enjoyed my synopsis of this great lecture at Casuality. Thanks to Reflexive and Enkord too for a very informative presentation.

P.S. Yes, I’ve just installed the Photopress plugin for Wordpress and I aim to have some more colourful and visually informative posts in the future :-)

How many game submissions do the portals get?

Sunday, February 10th, 2008

OK, whilst at Casuality 2008 in Amsterdam (more on this soon), I talked to the people at Reflexive and BFG who process game submissions to decide which games make it onto their site.

Reflexive put up about 5 games per week but are sent over 50! Terri Hardie at Reflexive told me that they get some really bad games submitted but she is always really excited to look for the gems that really shine out of the submissions. She does look at screenshots (so include links) and she appreciated nice polite emails (like mine - I’m English you see ;-)).

BFG put up a “game a day”, so 7 a week (for the mathematically challenged of you). They used to have two front line people evaluating the submissions, Jessica Sachs and Nate Webb, but now they have a 3rd person called Jeff (and probably even more) because they are getting so many submissions and find it hard to keep up.

I also spoke to some other people that worked at the portals and they said that they try to play every game which is published (even just for 10 minutes) to keep abreast of what the current games are like.

So what can we conclude from this? Basically only 10% (or less) of games sent to portals are actually put on the sites! This means that your game had really better shine out more than the others. Well actually it needs to be RELEVANT to the portal, so don’t sent “Zombie Killers 3″ to BFG (although it might do OK on Reflexive). Then make sure it is polished and has enough content to compete with modern titles.

How can you find out how polish you game should be and how much content it needs? Simply play the current top 10 games on a variety of portals. It’s amazing how many people don’t follow this simple tip before embarking on programming “Killer Car Death Chase Vampire Shooter”…