As Opticode expands during the coming months we’ll be looking to take on a few more programmers so shoot me an email if you’d like to work for an agile company working on some of the latest Microsoft technology.

I’m still working away on the back story to CIC which has become my spare-time hobby. I’ve been asked by quite a few people about CIC’s status and I’m happy to report that while the direct development is on hold, the design is always evolving and the game will be released eventually.

1. Keep it relevant

Too many of the tests have questions on content that simply isn’t relevant to the job. The whole idea behind a programming test is making sure the candidate is competent enough to fulfill the role. It shouldn’t be asking questions about arbitrary knowledge that you think ‘good programmers’ should have. That’s not to say that you shouldn’t be testing the basics, as your programmers will need to know these. The important thing is that you don’t test certain concepts just for the sake of it.

A good example of this is “friends” in C++. Nearly every programming test I’ve taken has asked a question about these. I’ve been programming for 5 years now, and I’ve only used them twice. Firstly at university and secondly when taking programming tests. I’ve asked a few other senior programmers and none of them have used them either. Why bother asking a question if it’s not relevant to the work they’ll be doing? I’m sure some people somewhere use them, and if that’s important, ask away, however if most programmers on your team have never touched them, why is it important that new programmers know them? Chances are, if the new programmer does use them, no one else on the team will understand them, or have a different solution to solving the same problem.

Of course, it would be ideal to hire programmers that just know everything there is to know about programming. In reality this isn’t going to be the case. It’s therefore important to make sure their knowledge domain includes exactly what you need. Asking irrelevant questions won’t help you find better programmers, it will help you find people who know how to pass programming tests.

2. Don’t ask stupid questions

Why bother asking questions about simple compile errors in code that is written on paper. These days, compilers will pick this up far quicker than a person can. Seeing if a programmer can find these simple mistakes is like asking an English professor to find spelling mistakes rather than fixing your sentence structure. Ask programmers to figure out logic errors in code. Get them to follow code logic and determine problems or simple output.

Also, don’t ask programmers trick questions. A lot of the time with trick questions you’ll spend a long time figuring them out, and once you know them, you’ll know instantly. Trick questions generally test whether someone has been asked that question before rather than whether they are a good programmer.

3. Be careful when asking optimization questions

Compilers and platforms are changing extremely quickly. This is particularly true within the games industry where we have entirely new hardware every few years. For these reasons you must be very careful when asking programmers to optimize code. What used to be a smart optimization even a few years ago can often be the slower option now.

For example some modern CPU’s (particularly on consoles) are very slow at executing branches (eg if statements). The simple question of optimizing a routine by using a lookup table that is cached may not necessarily be the fastest optimization anymore. What’s more important is asking people the general concepts of optimization. If they mention profiling with some explanation of best practices then you’re onto a winner.

If your work isn’t specifically about optimization then I would leave out any specific questions altogether. In games, optimized code is very important, so it’s necessary, but again, ask more high-level concepts rather than giving specific code blocks and asking them to write the fastest code. The best candidate would simply say that without knowing the exact hardware and without profiling they would rather write clean code than what they think would be optimized. Code Complete has an excellent section on optimizing code.

4. Watch your team coding, then write the test

If you’re stuck for questions then a practical hint is to simply sit for a little while and watch or talk to your team about what tasks they are performing. Ask the team what they spend most of their time on. You can then write your test around what they spend most of their time doing.

This will have the added bonus of keeping it relevant and stop you from asking optimization questions if they are not needed. I find that I spend 80% of my job doing fairly similar tasks and capturing what skills are used for these tasks and making sure new employee’s have them will almost guarantee you will find a good candidate. Obviously if you’re looking for a specific role to be filled this won’t work, but when looking for general programmers this will help.

5. KISS (Keep it simple stupid)

I’ve found that too many tests have the problem of being too complex. You know exactly what question they are asking, however they use a large convoluted example to ask the question, rather than simply asking the question itself. Rather than having a large “const” example and having the tester take minutes to figure things out, why not ask them specifically what “const” means.

The questions shouldn’t be complex, the answer should. While you don’t just want textbook answers, it’s better to keep anything complex to an interview. This leads to my final tip.

6. Use the interview for determining thought process

Programming tests are great for weeding out the programmers that just can’t program (and unfortunately there are a lot of them). They aren’t good at finding out the thought processes the programmer has when solving problems. Trying to find this out from a written test just won’t work, leave it for the interview.

I like to ask simple questions where the programmer has to solve a coding problem on a whiteboard. Rather than finding out whether they can write code on paper, give them something that doesn’t use complex code, but that requires a complex design. The main aim of this is to find out the thought processes when solving problems. As a programmer, you’ll know the “right” way to solving the problem and you’ll soon tell if the programmer has no idea what they are doing. You can also be surprised by an interesting solution that you may not have thought of. Either way, don’t be critical of the code they write, but rather of the way they go about solving it. Tell them to say out loud what they are thinking as they solve the problem. Think about how those thought processes may extend to larger problems and whether you want that type of person on your team.

Conclusion

There are a few simple tips for writing a good programming test. I’d love to see more relevant tests that actually find good programmers rather than the cookie cut list of questions that try and find a specific type of programmer (whether good or not).

If you have any questions you’ve particularly liked or disliked in tests in the past please add them as a comment so we can discuss, and perhaps come up with a better question that looks for the same answer.

In other news I’ve been busily working towards big milestones at work and all is going well.  I’ve started playing with HGE (Haaf’s Game Engine) and so far I’m enjoying it.  I’ve just put a small game together which I’ll release later in the week for everyone to try out.  I decided after writing an article and all the months of work on BSG and CIC I needed a small pet project for the weekend so I threw something together in a few hours.  I’ll have full stats when I release the game.

That’s about all for now.  CIC is still creeping along slowly however with 9+ hours of work per day and then an hour or so of article writing I haven’t had the brain energy left to solve some of the complex problems I’m facing in CIC.  It is moving along smoothly though and I have movement with missile pathing working nicely.

From Bad to Good

I downloaded the demo when it came out, not expecting much as I’ve played most WWII RTS’s that have come out in the past few years (a lot). I played through the demo and was quite unimpressed. I also tried the multiplayer beta and I started to see what all the fuss was about. As I have a friend at THQ (thanks Damian) I decided to get it for cheap and give it a go. I started playing multiplayer and fell in love with the game. I was really bad though, so I decided to give single player a go to see if it was any good. I usually steer clear of SP in RTS’s completely, however after the first 3 missions I was hooked with SP as well. For some reason, the two worst missions out of all the Single player game were the two they put in the demo. I played through the entire campaign and both had a lot of fun, and learnt quite a few tactics to use online.

Unique ideas

Rather than give a regular review, I’d like to just talk about a few of the key features that makes CoH stand out for me. There are two unique concepts that CoH has that I’ve never seen in an RTS before, and I’ve played a lot of them.

1. Retreating
I’m a little embarrassed to admit that I only just found out about this, 50 MP games into playing. I’ve always said that RTS games should have a good retreat in them making ‘running away’ a viable option in the battle. In every other game, retreating only works if you have a faster unit than the enemy, and even then, it’s barely worth using. CoH actually has a ‘retreat’ button which makes your men stop whatever they are doing, and run at great speed back to their base. You can’t control them until they are back there nor where they go so they can sometimes cross in front of enemy fire, however most of the time it works. This is pure genius. It opens up so many great strategies and means that one simple mistake isn’t completely punished by losing your entire group of men and giving the enemy precious XP for the kills.

2. Snipers
I’ve been thinking about snipers since they appeared in C&C and wondered how they could be implemented properly. CoH has the best implementation I’ve seen. Take the regular hide until they shoot, add in some detected at close range or by a recon unit and you have a fairly standard sniper dynamic. This is done in a lot of games and works well. Where the guys at Relic have excelled is adding an extra element to the hidden status. The first few times the sniper fires it becomes visible for a brief instant, not long enough for an MG nest to re-man the gun to return fire. However after quite a few shots, the length of time he becomes visible increases, until after quite a few shots he is visible continuously. Just like in real life, the sniper gives away his position more actually the more he fires. It also means that a sniper can’t simply decimate enemy squads without moving around or having some kind of support.

It’s all about the tactics

Once you’ve played a few weeks of CoH, nearly every other RTS feels like it has no strategy (I’m talking about you Tiberium Wars). In CoH you can use every part of the terrain to your advantage from dead cows to walls to buildings. Unlike in nearly every other RTS where hopping into a building is a sure way of winning, in CoH it comes with its own disadvantages. The key here is that there is no perfect strategy that will always win the day. You may figure out an awesome setup (like putting MG’s at all the choke-points around a map) but there’s always a counter to the strategy. I’ve played 50+ games online now and I’m still continually learning tactics and counter-tactics each time I play.

A simple example of this is the movement of your troops around a map. When you start playing you figure out fairly quickly that different objects on the map supply your troops with different amounts of cover. The green, yellow and red shields denote Heavy Covert, Light Cover and Exposed respectively. Easy to pick up, instant strategy added at little cost. In fact, you don’t even need to worry about this if you don’t care. Players can just move their men around and they’ll automatically move to cover if left exposed. Once you move on though, you realise that each type of cover requires your men to position themselves differently. If you make them all huddle around a burnt out wreck they will have great cover, however they’ll also be tightly bunched. This means that throwing a grenade their way will inflict major casualties, negating the advantage of the cover. If you’re quick though, you can start out in good cover, draw the enemy out and then retreat to a more spacious but less protected area as the enemy draws close to throw their grenade. This kind of simplicity with layers of complexity is what RTS games should be all about.

Conclusion

So my recommendation if you haven’t played CoH is to go to EBGames or equivalent and buy it. Try it out for a week and try and get as far into the Single player game (and a little multiplayer) as you can and decide if you like it. If not, take it back, free of charge, but I’m fairly sure once you start playing you’ll see how truly original and deep the game is.

This is just a quick post to say happy Easter and let you know how things are going at the moment. Things at work have been going crazy leading up to big milestones so I’ve been putting in 10+ hour days for a while now. This has left me little time to work on my latest blogs, but rest assured, I have a number in the works. I’m currently playing Silent Hunter 4 in all its bugginess and as usual still playing as much Company of Heroes as I can with my limited spare time.

CIC is moving along quite slowly. I’m looking to convert my engine to use 64bit floating point numbers (doubles) so I can accurately represent the entire Solar System down to centimeter precision. Once things settle down at work (probably not for a few more months) I’ll look at getting back into ~10 hours a week so I can make some more progress.

I’ve had some requests for blog articles which I’m working on at the moment. If anyone else has any requests please post a comment and I’ll write up an article if I know enough about the subject. Until then, have a great Easter.

Read the article here first.

A bit of background
Game programming is one of the hardest forms of software development I’ve worked on.  From my experience, most poor saps can’t even program, let alone create complex games.  I used to work as a business applications programmer and I’ve found that games have one particular ingredient that makes them far harder to develop than most other apps.  That ingredient is ‘fun’.  You can’t easily measure it, set up a list of requirements nor do test cases to make sure it’s there.

Another area to discuss is languages.  The article talks about Basic and Assembly, and thankfully we’ve moved on from these horrid things.  While it’s great fun to hack away in close to machine language, the fact we have much higher level languages means we can spend more time making the game, and less making the computer do what we want.  Many people believe that C++ is old and useless; however it’s still the best choice for making games.  While it’s better than assembly, it’s still quite low level, allowing us to directly access memory and have lots of fun with raw pointers.  Many people still can’t get their head around such things (they’re called Information Systems majors).  While java and .net may be good for beginners, all the work they abstract or hide means the programmer doesn’t fully know or control what’s going on.  Don’t get me wrong, I’d love to start using a language like C# to make games, however at this point it isn’t really an option, but that’s for another blog.  Enough background, lets get on with the real story.

The Good News
A lot of the game programmers I’ve worked with have been up to the challenge.  Game programming is still in its infancy and we have much to learn from general software engineering practices.  A lot of the proven techniques to help with the complex task of developing software aren’t that difficult to learn, we just need to devote some time to learning them.  One of the hopes of this blog is to share some of the general software engineering principles I’ve learnt and share them with the game programming community.

The other good news is that not every position requires a John Carmack.  Even with little 3D and complex math skills there are plenty of areas of games development that programmers can work on to make successful games.  For every one hardcore engine coder on a project there are many gameplay, UI, script, etc programmers who must rely on creativity more than just pure programming skills.  With engines such as Unreal 3, a lot of the complex work is done for programmers, leaving them with the task of making a fun game, rather than writing the fastest rendering system they can.

The Bad News
While I’ve met many good programmers they are, unfortunately, few and far between.  There are plenty of programmers out there that can’t even put simple desktop applications together.  While making games sounds like fun, it’s also extremely complex, and a lot of these useless programmers just can’t hack it (if you’ll excuse the pun).  If you haven’t been coding since you were knee height to a grass hopper then you’re in for a long ride.  Programming is one of those things that people either get, or they never will.  Even if they ‘get’ it, games are so complex there’s a high chance they won’t be good enough to understand all the complexities.  It’s one thing to write code that performs a desired task, a lot of programmers can do that, but to write it efficiently enough that the game can still run >30 frames a second is a hard task.  It takes only one piece of poor code within the inner game loop to be slow and the entire game will bog down.  This is only getting worse as games become larger and more complex.  Add to this the fact each different console comes with its own complexities, pitfalls and challenges means that programmers must be completely comfortable with their language and general programming skills.

As game programming requires only the elite of the programming world there is an unfortunate side effect, the ego.  Game programming is one of those jobs that nearly any kid would love to have, and with so many people not being good enough, some game programmers take that as an opportunity to think they are the most amazing people in the world.  They often forget that their colleagues are in a similar situation and instead think they are better than everyone around them.  This is often called the “Prima Donna Syndrome” and I’ve seen it all too often from game programmers.  Awesome game programmers are like good looking people, it doesn’t matter how good they are, if they think they are the best, and act that way then it basically negates all of their ‘goodness’.  The problem here is that game development is a team exercise.  Programming is only part of the puzzle and people need to communicate well if the team is to succeed.  Within the small group of good enough programmers, there’s an even smaller group that can communicate well and don’t think they are God’s gift to the game development world.

The Pay Problem
Back in the beginning of game development, programmers were paid less than their regular counterparts.  The article paints a pretty picture of how it will be in the future (now) though.  Aren’t we lucky then that games are pulling in billions of dollars around the world?  Surely things would have changed since 1981 and this complex profession of ours would be receiving the remuneration we deserve, unfortunately not.

The majority of game programmers I know would take a massive pay rise if they left the games industry and used their genius elsewhere.  Combine this with much overtime, poor working conditions and generally badly run companies and there’s little incentive to stay in the industry these days.  Why else would the average years in the industry be as low as 5 these days?  Without having the pay to back it up, the industry is only ever going to get diehard gamers who wouldn’t dream of doing anything else.  Thankfully I’m one of them, and the current shortage in good programmers works out well for my peers and I, however for the industry in general it’s a problem. This pay problem is only making it harder to find programmers that are good enough.  A large chunk of the programmer market is simply not interested in the low pay and bad working conditions a lot of studios make them put up with.

Conclusion
So the simple answer is, yes, programmers these days are good enough.  The long answer is ‘kinda, it depends who you ask’.  There are plenty of Carmack style genius’s around at the moment.  There’s also plenty of people looking to the future of games from Tim Sweeney to David Jewsbury (who gave an excellent speech at game connect).  We have some excellent tools at our disposal, many different languages to choose from and an ever increasing budget to work with.  While I’ve met countless bad programmers, I’ve also met enough awesome ones to know that the games for at least the next five years are in good hands.

Since graduating from university I’ve worked steadily for 5 years in various programming roles. I’ve come to the conclusion that I’ve reached a crossroad in my programming life. While I have plenty to learn in my current position (more than could possibly fit into my short Homo sapien lifetime), there seems to be some new options presenting themselves to me. It’s the same crossroad that all programmers reach at some stage in their life, and quite a few follow the default path without even realising they have a choice. After investigating the crossroad ahead I see 3 paths leading off into my future. These include managing technology, managing people or managing business.

Managing Technology

This is the default path for programmers to follow. If you haven’t realised you’re at this crossroad (and haven’t been flung along another path by someone else) then chances are you’re on this path. The reason it’s the default path is because it has its roots in the generic path that most programmers take straight out of university/school. We start out by managing bits of technology, from code to databases to websites.

Our main aim is to make technology do our biding. You could possibly look at it in this way: You start out fresh from school and begin ‘managing’ functions. You write little apps that do simple tasks, you then move up to creating classes followed by entire sub-systems and eventually end up writing entires game engines or ‘enterprise applications’ as the business world calls them. This path can ultimately lead to a technical director of a game or company where you make decisions about which tech is best for a particular need/project. If you were coding in your basement since you were 5 then chances are this may be the best role for you. John Carmack is a good example of someone who manages technology.

Managing People

This is the second most likely path that programmers take. The cold hard truth is that a lot of the time, people move into these roles as they aren’t very good at the managing of technology part. This, unfortunately, means that a lot of senior and lead programmers out there are only in the position as they couldn’t hack it as a ‘real programmer’. Thankfully though, there are plenty of people that move up into these roles as they actually have an affinity at dealing with people.

The main aim of this role is bringing the best out of people, making sure that teams work well together and that your programmers can be as productive as possible. I’ve found some great inspiration about how this should be done from books like “Peopleware” and from some of the managers I’ve worked with over the past five years. This role is different to a project manager (who managers an entire project rather than just the people) as it’s more technical. Lead programmers organise who will be best suited to coding what, and in essence make sure the coders below them can do the best job of managing technology possible.

Managing Business

Some people just aren’t happy working for someone else, and they go on to become entrepreneurs and start their own business (or just spend their entire careers complaining about the fact they work for someone else). It’s true that in this position, for a start-up at least, you get to have your hand in both of the other groups. However for most businesses, after a certain point it’s not feasible for the founders to also be in the other two groups. You may be able to choose one group and stave off reality for a few more years, but eventually if you’re successful you’ll need to move away from the micromanagement and start looking at things from a higher-level. Bill gates is a good example of this, he was both Director and Chief Software Architect of Microsoft Software Architect at the same time. However after a while he decided he wanted to spend more time coding and had to give up some of the ‘business managing’ to move into the other group.

You’re main goal in this group is making money. It’s the hardest work, gives you the most options and even has a small chance of making you quite rich.

Conclusion (What About Me?)

So what road will I take? To be honest, I’m unsure at this stage. While I like technology, unfortunately I didn’t start coding when I was 5. Some will say that means I’m not a real programmer, but I’d rather believe that it means I can actually communicate with other humans without the use of I/O devices, other than the acoustic resonance generator and receptors God made us.

During my time as a programmer I’ve been asked to start businesses with a number of people, and so far none have made me want to ‘quit my day job’. That could all change in the future and I’m not ruling it out, however for the time being, I’m going to continue on my current path (managing technology) and see what opportunities come up. The first step I see is acknowledging that the crossroad is there and I that have the choice about which to go along. I’d be interested to hear from others whether they think they’ve reached this, already chosen one, or think I’m full of crap and should spend more time coding and less blogging.

C++ For New Architectures
Zsolt Mathe, Software Design Engineer, Microsoft Game Technology Group

This was a great speech about tricks and techniques to get C++ code running efficiently on new hardware such as XBox360 and 64-bit processors. There were quite a few code snippets which he used, however you should be able to pick up most of his points just by listening.

Challenging The Given: Is There A Better Language Solution For Programmers?
David Jewsbury, IR Gurus

This was my favourite speech of the conference. As David states, it’s more philosophical than specifically answering questions. I think it raises some interesting points and while some of them are quite ambitious, I think even having dialog about such things will help to stimulate growth in this area.

Medieval 2: Total War: Postmortem
Ken Turner, Creative Assembly

Ken gives an excellent talk about the sequel to one of my favourite series of all time, the Total War Series. He talks about a wide range of topics from processes in place to dealing with legacy code and general discussions about what went right and wrong with Medieval 2: Total War. I found this to be the most informative speech at the talk with excellent advice on so many topics.

How To Use Testing Feedback To Shape Your Game Design
Matthew Ford, Auran
I recommend Matthew’s speech to anyone working on games at the moment. Matt was my project manager for a game a while ago so I have first hand experience with his techniques and can attest to how well they work. This speech was the best presented with clear, concise information, and lots of it, while being fun and engaging the whole time. There’s a large Q&A part at the end which gave even more information and showed that Matt really knows what he’s talking about.

Interactive Storytelling
Chris Avellone, Obsidian Entertainment

Chris has worked on some of the best games ever made. From the fallout series, to Planescape: Torment up to the latest Neverwinter Nights 2 (which just happens to be sitting on my desk in front of me right now). Chris has some great stories about his time working on these games and gives some great advice to any designer/writer who wants to make great RPG’s.

SPU Programming for PS3
Colin Hughes, Sony Computer Entertainment Europe

I won’t say too much about this speech as I’m not a fan of the PS3 nor developing for it. There are some interesting points Colin brings up however I found the speech quite dry and boring. If you’re a PS3 developer or passionate about new hardware then give this speech a listen however be warned, there is a LOT of content.

1. Building Mentor-Protégé relationships

For this to work, you generally need to have programmers of differing years of experience working together.  The more experienced of the two should be the one actually coding and they can discuss and talk through the decisions they make as they code.  Programming is generally a very solitary activity and I’ve found watching someone else with more experience to be invaluable as there’s only so much you can learn from a lecturer, text book or self-teaching.  Actually watching a master in the art of programming work their magic will give a lot of insight into where the protégé is going wrong and will help to build a relationship where they will feel more comfortable approaching the mentor to ask advice.  Simply sitting down and explaining to someone the good practices in programming can sometimes seem arrogant but watching someone code is far less confrontational.  There’s usually a lot of ego involved with coders and I’ve found pair programming a way for more experienced programmers to dispense their knowledge without stepping on someone’s ego.

2. Two heads are better than one

This benefit is more for the project than the individuals.  If there is a particularly complex or difficult problem that needs solving, it’s often good to have two people working together to solve it.  Rather than just discussing the problem, where ambiguities can creep in, having two people write the actual code means any misunderstandings can be cleared up as they write.  The code is the final.  Opinions, prejudices and communication problems just don’t exist within code; it’s the final contract for what the program will do.  Pair programming is also continuous and instantaneous, where sudden ideas that flash to mind can be discussed and implemented on the spot.

Some people may argue that it’s a waste of programming resources having two people do one person’s job, however I believe the benefit gained when working on complex or difficult problems far out ways the cost.  You really can’t put a dollar figure on having a better solution to a problem and while the time taken to write code won’t be half as much, the quality will often be high enough to warrant this higher expense.  The cost does mean that I wouldn’t recommend pair programming all day long as simple problems can often be solved by one person more easily.

3. Sharing specific knowledge

One of the biggest benefits from pair programming comes from the fact that every programmer is different and have different experience and knowledge in different areas.  Because of this, when two programmers sit down to create some code together one of the two will generally have more experience in the area and can share this experience with the other person.  This is similar to the mentor-protégé relationship however it’s at a lower level.  Despite the overall experience of either programmer, the person with the most knowledge of the particular domain should lead the way and share their knowledge with the other person.  If someone has written a number of implementations of the A* search algorithm then sitting down with another programmer and implementing a slightly different one for their current project will help that person share their specific knowledge.

4. In with good habits, out with bad habits

The act of having someone else watching your every move increases your awareness of bad habits you may have.  Better yet, if you aren’t aware of them, the other person can tactfully let you know of a better way of doing something, or that what you’re doing is just plain wrong.  On the other side you may find particular good habits that you can pick up from the other person.

So there are four simple reasons why I think pair programming is something you should at least try to see if it works in your given situation.  I’ve had only good experiences with it so far and I’d like to hear from anyone else either for or against the practice.

1. Buy Indie Games

Some people are blaming the lack of good games at the moment on the big publishers and their obsession with sequels. I agree that they are partly to blame, however just as much blame falls on the average gamer who goes out and buys these drab excuses for games. By buying Indie games not only will you find some more interesting, fun, cheaper and original games, you’ll also be helping to support those who want to make games like that (such as yours truly). I don’t want to start listing lots of games to go out and buy, follow #3 on this list and try some demos for some excellent indie games, there are hundreds out there and you can almost be guaranteed there’ll be one you like. Not surprisingly one of my favourite indie games is ShortHike – Space Station Game.

2. Don’t play multiplayer until you’ve finished the single player

This one is so obvious a lot of people miss it. Have you ever found yourself playing a game where each level you unlock a new special ability or weapon with the excitement building each time. Often the developers will put a lot of time and effort into making this an important part of the fun in a game. The best way to ruin this is by hopping online and getting given every possible weapon in the game, ruining the suspense and giving you an overload of information. There’s a reason single player games only give you a few rewards at a time, it’s a simple tactic to keep the player engaged and always wanting that little bit more. Take the time to finish the single player game all the way through (or as far as you usually like to go) before stepping out into the big bad world of the internet.

3. Try demos before buying, rather than reading reviews or listening to hype

I used to buy every PC Powerplay magazine (and before that Hyper) when I was growing up. I’d read all the previews of games coming out and I’d go to websites to get every piece of information and screenshot I could find. I’d pre-order the game and when it was released run down to EB to buy the game. I’d get home, play it for a few hours and realise that 90% of the promises made weren’t kept, and that generally most of the games turned out to be rubbish. I no longer have subscriptions to these magazines, and I only visit the news sites for general information about games coming out. The best way to tell if a game is any good is to play its demo. You’ll pick up more from 5 mins in a demo than hours of previews and interviews with developers. If your game doesn’t have a demo then there’s a good chance they’ve got something to hide and I’d steer clear of it. Most games have demos these days and Indie games especially use these as their main tool for winning customers. We’re lucky in the games industry to be able to ‘try before you buy’ so make use of this and don’t get caught out buying the next ‘Tiberian Sun’.

4. Order online to increase suspense

This is particularly useful if you live in Australia where ordering games from the US will often get them here on or just after their Australian release date and often for a fraction of the price. As I’m a stingy bastard, I now order nearly all of my games online. If it’s a really big, hyped, release this makes it even better, as I found with Civilization 4. It’s like waiting for Christmas morning every time you wait for a game. I actually found this suspense more alluring than I had first thought it would be, as in our current society if you have enough money you can pretty much get anything you want instantly. Being forced to wait a few extra days for a game makes the suspense just that little bit more unbearable.

5. Buy fewer games

While this may seem to counter #1 and #4 it actually fits in well with both of them. The important part to this rule is to make sure you don’t buy too many games. I’ll never forget when my good friend Nick and I went to EB and he brought Half-Life and Delta Force on the same day. We went home, played Delta Force for a few hours thinking it was the coolest game ever, we then tried out Half-Life and realised that it was THE game of the century. The delta force CD then gathered dust over the following weeks as we were completely engulfed in the epic that was Half-Life. If you buy less games, you can spend more time on the games you own, and experience their full potential rather than just playing a few hours, discarding them and moving on to another few hours of the Next Big Thing.

6. Don’t pirate games

Not only is pirating bad for developers and their pay cheques, but it also hurts those who are pirating the games. It seems there’s a lack of respect for the game as it’s not paid for which leads people to become bored of the games more quickly than if they’d gone out and paid for them. Not only do you have no suspense, even as small as walking into EB seeing if the game’s released yet, you’re just not getting the full experience of opening the packet, reading the first few pages of the manual (or the whole thing if you’re like me) and really soaking up what games are all about. I’ll admit the publishers have a lot to answer for with their paper sleeves and ridiculously small manual if they even supply one, however once again, take the higher ground and just don’t buy their games, there are plenty of other games for you to spend your hard earned money on.

So that’s it, while some of these steps may seem a little weird I implore you to try them at least once to see just how much more you can enjoy your games if you try them.

On an unrelated note, two of my good friends (and co-workers) have just released new indie products that you should check out. Cliff has just released Xion, the most kick-ass media player around, and Walter’s just released Cavemen for pocket PC.