Browsing Category: Game Development

One of my favourite games of all time is Sonic Team’s "NiGHTS" for the Saturn. The core mechanic is very simple, and the graphics look a little ropey compared to more modern titles, but it still has oodles of charm and lots of playability. You can imagine my excitement when "Journey of Dreams" was announced, but having played it recently there was something that irritated me.

There’s too much story.

Don’t get me wrong, I love a good yarn, but there’s a time and place for it. Ignoring the fact that video games tend to have sub-standard plots, there’s several deeper problems that need to be addressed.

The biggest problem is games that have a plot for no reason other than to fit in. If Space Invaders was made today, would each level need to start with a monologue about the plight of the human race? Perhaps the ending would reveal that mankind were the real space invaders, destroying other worlds for their resources. That might sound like a great plot on paper, but do we really need it?

Let’s use horror films as another example. The bits we don’t see can sometimes be the scariest. A close-up of the victim’s face, followed by a cut to their shadow and a ghastly scream is far more effective than seeing them being sliced up whilst the killer explains about how he wasn’t loved as a child. The real power of the scene lies in the viewer’s mind. Perhaps they see the attacker as a clawed monstrosity, or maybe it’s the theme park owner who’s in it for the money. The important thing is that the viewer is left to decide what really happened.

That’s my problem with Journey of Dreams.

The first NiGHTS had some great FMV which set the story up nicely. From the opening film, it becomes apparently that Claris and Elliott were talented individuals plagued by fear and nightmares. There are no cut-scenes once the game has started, and it’s pretty much left up to the player to decide on everything.

Once the final boss has been vanquished, the two main characters meet in Nightopia, but again it’s up to the player to decide what happening. Have they fallen in love, or are they just cementing a friendship from their adventures?

Sadly Journey of Dreams decided to add dialogue to the mix. Lots of it. Although I’m not keen on the voice acting, my real problem is that it doesn’t give you chance to use your imagination. For a game that’s all about dreams, it’s a shame the developers decided to go down this route.

Games don’t have to tell a story. It’s nice when they do, but there’s really no need for hours of cut-scenes and pages of dialogue for a game that’s about collecting orbs and flying through hoops. It’s an important lesson to learn: More isn’t always better.

Unnecessary story elements aren’t a huge problem in indie gaming, but that’s mainly down to the limited budgets and time constraints. What’s more important is remembering that as indies we have a lot more flexibility in deciding how we tell stories.

Take time to consider what really needs to be told, and strip out the bits you don’t need. You want people reading your story to know just enough to be interesting, whilst still leaving gaps for their imagination to fill in.

Games can make us feel many different emotions. Fear, excitement and even sadness are common emotions in games, but what about love?

What is love?

Many people throughout time have attempted to describe what love is. Poets, philosophers and scientists have all had a go, but love remains a complex mystery.

If you’re the romantic sort, love is the greatest thing ever. It makes the world a more beautiful place. Birds sing more clearly, flowers smell better and everything is wonderful. If you’re not quite so romantic, love is just nature’s way of getting two people together to mix DNA.

The fact that love is so difficult to describe makes it all the harder to convert into a gameplay element. To some, even the very notion of turning love into something trivial for a videogame is unthinkable.

For the purposes of this article, I’ll be discussing two kinds of love. The first, and perhaps easiest to experience, is a caring, nurturing love. The second form is the romantic love that makes Valentine’s Day so very expensive.

How do we create love in games?

To create a sense of love, you must give the player something to care about. Several factors make a person more likely to care about a fictional character on their screen.

Create a connection between the character and the player. Creating a common ground between the player and the character is a good place to start. You’re much more likely to care if you see part of your own personality in the character.

Make the player feel important. You can foster a relationship between the player and the character by making the player feel as if what they’re doing is important. For example, Tamagotchi’s would get sick if they weren’t properly cared for. Creating this sense of responsibility in the player makes their decisions seem important, and increases the chances that they’ll care about their character.

Make the experience unique to the player. This is perhaps the biggest element into creating something special. Tamagotchi’s were special to people because they weren’t the same as someone else’s. You become more protective of something if you believe it can’t be recreated.

What about romance?

Romance is a completely different experience, and much, much harder to recreate. There are several barriers, both physical and moral. Is it right to make someone fall in love with a fictional character? Most players will be aware that “it’s only a game”, and won’t succumb to anything more than lust for what’s on screen.

A more realistic way of creating romantic love is to let the player take the role of a different character on screen, and have the romance play out between them. This approach is commonly taken in RPGs, but is often scripted and gives the player very little control over what is happening. This can create a sense of distance between the character and the player, and should be avoided if wishing to create something deeper.

The “S” word

Sex is quite popular, apparently. With adult books, DVDs, websites and more, it’s only natural that games should get attention from the adult industry. The majority of sex games are overly salacious, and merely an excuse to put some porn in the form of a game. Even the Atari 2600 got some of the action (pardon the pun), with some truly awful sex games being released, such as the infamous Custer’s Revenge.

With advances in artificial intelligence, and the proliferation of cyber sex in MMORPG’s such as “Second Life”, the future may see AI bots replacing pornographic games. It’s quite plausible that such a bot may one day pass the Turing test, and fooling the player into believing they are interacting with a human may be the best way to improve the player’s experience.

Conclusion

There is still a very long way to go, but using techniques from artificial life makes it easier to create a sense of love between a player and a character. It may never be the same as the love between two people, but perhaps that’s for the best. However, at least you don’t need to buy a computer dinner…

Music can easily convey feelings and information that graphics and text can’t or shouldn’t. Appropriate music and sound, employed effectively, will make your island platformer more jaunty, your subarctic wasteland more desolate and your army of forty-legged robots incomparably evil.

Imagine the scene.

Your player has just hit the spider boss between the eyes with a well-aimed rocket. It screeches and falls from the ceiling of the tunnel, crashing in front of the player. The music falls from a thumping beat to a clear silence. The enemy stops twitching and stiffens. The player leaps over it and runs towards the exit, the new upgrade clearly in sight, the final key…

BOOM! A deep bass drum resonates.

You can almost hear the gulp from here.

Music’s importance in mainstream games is now widely-recognised, but in terms of indie games it still seems to be an afterthought in some cases. Here’s why that should change.

Make it enjoyable

Every aspect of your game should be carefully planned to ensure the player will find it appealing and enjoyable. If your music is repetitive or unsuitable, you can be sure they’ll switch it off as soon as possible.

No matter what kind of game you’re developing or playing, good music is highly important. Think of any genre and there’s a classic game with a great tune attached:

 Puzzle – Tetris. Chances are you know it and like it.

 Platform – Sonic or Mario. Green Hill Zone and the Overworld theme are two of the most famous pieces of music for any game, widely recognised and admired.

 Racing – OutRun. I can say no more.

Good music will genuinely elevate the quality of your game if it’s suitable, memorable and enjoyable. You work hard on making the rest of your game those things, so why not the music?

Don’t waste chances

Unless you’re developing for a system that includes rumble or force feedback, indie games only use two senses: sight and sound. Not maximising those senses is a waste, and severely limits the impact of your game. 

Try playing your favourite game, indie or otherwise, with the music off. Does it feel different? I always feel much less interested in a game without music; there seems to be no mood, and I can hear my brain thinking “this isn’t any good.” It’s okay, you can put the music back on now. Much better, isn’t it?

“I can’t do it!”

You don’t have to. Hiring and collaborating with musicians over the Internet is easy; you send them artwork and they send you music. You send them money and they send you thanks. It’s straightforward, the quality of music will be much higher and it leaves you with the other nine billion jobs to take care of.

The key to good music in games is…

Not to waste it. Use suitable music for the mood you want to achieve and your player will become much more involved and, as a result, enjoy themselves so much more. Seeing as that’s your business, you owe it to everyone to put great music in your games.

James Newton is a writer and musician from York, England. He has written music for several independent films and documentaries, and has also created tracks for several games. You can listen to his work and read his thoughts on games and more at Prosody.co.uk.

There’s an interesting discussion going on at the IndieGamer.com forums about games we designed as kids. I still have the notebook I used to design games in, and although their scope far outweighed my ability, it’s fun to look at them to see how things have changed.

Some of the designs were detailed, spanning pages of documentation, maps and game elements. Others were just paragraphs describing a concept, and usually a pretty unoriginal one at that.

It’s amazing how much confidence a small amount of programming knowledge gave me back then. Copying a listing out of a book made me feel like a king, and my ideas reflected that. These days I’m far more grounded in my approach, which is surprising considering how my abilities have increased.

(Some of these ideas are typed directly from my old ideas book, and I’ve included the mistakes for comic effect.)

The Cream of the Crop

Psycho Bean

Not so much a game idea, as an entire franchise. I can’t take full credit, as it was something my brother cooked up whilst high on sugary “Lemonade Dippers“. It started out as an audio tape recording. Due to my brother’s high pitched voice and the tape recorders “double speed” facility, Psycho Bean was blessed with a voice worthy of Alvin and the Chipmunks.

The story followed a happy bean called “Cutie Bean” that gets struck by lightening and turns into “Psycho Bean”, a ruthless killing machine that destroys all in his path. Other characters included “Granddad Zimmobean” and “Baby Bean”. Complicated stuff.

Psycho Bean’s power came from lemonade dippers, but if he ate too many he would be sick. Levels included such original locales as “Bean Town”, “Bean City” and “Bean Laundry”. The penultimate level took place in the lemonade dipper factory, with a bloody finale in the Lemonade Dipper Burglar’s Hideout.

Like most of the games I designed in my youth, I got as far as designing the sprites. Perhaps I should have been an animator instead.

Unfortunately, Psycho Bean was retired once my brother’s voice broke. It was a cruel reminder of the brevity of youth.

Sonic Blast / Sonic Boom

OK, so now we’re into “Watch out for lawyers” territory. Sonic Boom started out as the sequel to a text adventure I wrote called “Sonic’s Adventure”. Sonic’s Adventure was actually the first game I’d written without any outside help, and the finished result was relatively playable. A sequel, Sonic’s Adventure 2 was started, but lost due to a corrupted disk. Many tears were shed that day.

Like most of my ideas, Sonic Boom started out as a small idea and grew into a mammoth undertaking. I wrote it for the Atari ST, long before I had the Internet, so I drew all the graphics myself. I remember painstakingly copying the Sonic 3 sprite from a sticker album. Tough days.

The game didn’t get particularly far, but it was my first foray into graphics so I was relatively pleased with how things went. There was no scrolling, it had annoying music and I’m not really sure what I intended for it. It had colour cycling though, which made for pretty waterfalls and sparkly gems.

Sonic Blast then mutated into Sonic Boom, which was more of a strategy RPG in the style of Shining Force. There were three different level types; side-scrolling adventure stages, top-down exploration stages and top-down turn-based battles.

Sonic Boom was easily the most playable game I ever wrote for the ST, and although the code was an absolute mess, I got quite far. There were four levels, and I had plans for approximately six chapters (that’s about 36 levels in total).

Another feature was “P-Life”, which was loosely based on NiGHTS’s A-Life. Every time you defeated an enemy, you would collect part of their DNA. This could then be fused with the creatures in a special garden, and you could create interesting hybrids.

As time went by and I switched to a PC, the dream of my own Sonic game lived on. DarkBasic was the first language I tried, and before long I had a terrible model of Sonic sliding around a terrible level. DB didn’t get much further than that.

I still have many folders crammed full of ideas and drawings, and of course I still have the dream. Sadly, most companies frown quite heavily on fan-games, so the journey will have to stop here.

Shining Force Online / Shining Force IV / Shining Force X / Shining Online

As with Sonic Boom, Shining Force Online was inspired by another commercial game – “Shining Force”. Many, many hours were spent playing it, so it seemed only right to devote more hours to creating my own version.

Clearly, I should have spent more time thinking up a decent title for it.

I can’t really take credit for this idea, as it followed the same pattern as most games these days; 1) find a forum about games, 2) tell everyone you’re going to make the best game ever and 3) find people to do it all for you. 

My brother and I signed up to help a fellow fan with his Shining Force game, but it quickly became apparent that he had no idea of what he was doing. Thankfully, he had quite a big team and had put all their email addresses in the “To:” line, so we instigated a coup to overthrow his leadership.

We should have realised that some of those emails belonged to his friends, and he quickly found out. I can’t remember exactly how the email exchanges went after that, but I don’t think he was very pleased. First lesson of mutiny: Make sure you’re not the only people that want to rebel.

Once the excitement died down, my brother and I set about writing our own game. I’d already written most of the engine for Sonic Boom, so it was merely a case of adding new graphics and a plot. As you can see from the screenshot above, graphics were something of a challenge at the time. The Atari version even got reviewed in UCM Issue 23, although I think they were a little bit generous with the score.

After migrating to the PC, the game got a new title and a complete facelift. Two PC demos were released, and they generated around 4000 downloads between them. Not bad for a demo.

Other notable achievements include 3000 pieces of hate mail, all from the same guy. Downloading 3000 large emails via dial-up was no fun, especially as the connection liked to die during the process. Still, it was fun to inform his school of his transgression.

The source code also contains a set of quotes to inspire me. Most of them are of the “This game sucks” variety, but there were a few nice ones in there.

I made a lot of good friends whilst making the early demos, and I still keep in touch with them. It would be fair to say that the response to my early work helped me make the decision to become an indie developer. They were good times, and James and I still have piles of paperwork spanning all of our ideas.

Of all the game ideas I want to complete some day, this is right at the top.

The Bottom of the Barrel

Battle Racers

Description: “A racing game where you fight opposing cars or just race”.

That’s about as detailed as it got, apart from the “other details” section which had the following important information: “The car is red, with with [sic] white stripes, the opponents cars are white with black stripe.” With detail like that, it’s hard to understand why I never made it.

Immediate Action

Description: “You have to progress through various missions and achieve various goals”.

Somewhat inspired by Andy McNab’s book of the same title, this was set to be an army game with multiple vehicles, missions and weapons. As you can see from the description I wrote, it was thoroughly planned. From what I remember, designing the game was as complex as looking through books to find pictures of cool weapons and vehicles, and then writing their names down.

All Good Things…

That brings us to the end of our journey through my childhood dreams. Will any of these ideas ever see the light of day? Let’s hope not.

Do you have any ideas from your childhood you’d like to share? What ideas are you proud of, and which ones make you cringe?

Let’s face it, most of what I’ve been working on over the past few weeks has not been particularly exciting. In fact, it’s been downright boring. Unfortunately, game development is not all fast cars and multi-coloured particles. A lot of it is dull, tedious and less exciting than watching a race between paint drying and grass growing.

As if things weren’t bad enough, skipping over the dull bits to work on exciting things will always come back to haunt you. Talk about kicking a man when he’s down.

The Slightly Boring Bits

The blank canvas

It’s more intimidating than boring, but starting out with an empty project is boring in itself. Although there’s the initial rush of starting something new, it’s quickly followed by the realisation of how much work needs to be done. Creating the initial skeleton is a lot of work, and you’ll probably end up rewriting it at least once. That’s something to look forward to.

Setting up tools

It’s easy to waste days, even weeks, on setting up your build environment. Choosing a language, setting up working directories, version control, customising your IDE and creating build scripts are all part of the initial fun. You might even write a set of coding standards if you really want to put yourself off the project before it’s started. Remember to spend at least a page debating over how many spaces a tab should contain.

The Really Boring Bits

Testing

Hopefully most people realise that being a game tester is not the same as playing games for a living. Testing your own game is much worse, because by the time you’re ready to test you’ll be sick of the sight of it. To make matters worse, you have to wade through all your code and fix all the bugs that crop up. It’s bad enough having to test something you hate, but being reminded that you make mistakes (and lots of them) adds insult to injury.

Documentation

Need I say more?

Anything that involves accessing files

Ever been excited when a game reads something from the hard-drive? Thought not. Spare a thought for the soul that coded it.

The “glue”

Games are lots of fun things stuck together by lots of boring bits. Error checking, file manipulation (as mentioned), resource management and all the bits that glue the main components together are all parts of the job you’d rather never see.

It’s fun to watch things fly around the screen, but there’s a lot of work to be done behind the scenes before anything can start flying. It should come as no surprise to realise that coding all of this is no fun at all.

Planning

It’s not much fun.

The Good News

You could have to clean up this kind of thing for a living.