NAG Online > Game Dev

Category: Game Dev

Sleeping man

The weekend of the 24th to the 26th of January was the Global Game Jam – an event where over 23,000 people around the world commit to making games in 48 hours.

What actually happens in a game jam though? Surely it’s not that hard to make a game? Click through to find out what it’s like.

Read more ...

Local Internet-lands have recently been abuzz with stories of a game called Legends of Echo. It’s a bit of good ol’ South African produce which uses the local Grid network to create a mobile, location-based MMO. The “mobile” bit means that it can be played on a cellphone (though models seem limited to Nokia and Sony Ericsson) and the “location-based” bit means that your real-life game spot is mapped to a unique place in the fantasy world of Echo. Swashbuckling adventures and epic battles await.

Legends of EchoFunnily enough, I didn’t hear anything about the game until its actual launch day, but its explosive arrival holds promise — especially since it’s backed by bigwigs like Vodacom and a the power of a “lower seven figures” budget. They’re naturally hoping to make a great deal of dosh from this — micro-transactions (such as the described ability to exchange airtime for “Elements”) as well as the oft-overlooked charge for data transfer should mean that all three mobile operators in this country will have something valuable to gain from the experience.

Some people may be tempted to roll their eyes at this whole thing and call it an evil corporate plot with the sole aim of getting us to spend more money on frivolous activities, but the fact is that local game developers really need big companies like Vodacom to agree with more initiatives like this. It makes a startling amount of sense for everyone involved: getting “the suits” to cough up funds for (potentially profitable) game projects gives budding developers a grand opportunity to cut their teeth and build up capital in an otherwise destitute local environment. Setting up a game studio — particularly in South Africa — can be a horrendously difficult task without external assistance or a nice whack of cash. Offering one’s talents to a corporation interested in advergames or other promotional projects may not sound like the most inspiring line of work, but it’s a far safer route than immediately diving into your own big game project.

Legends of EchoIt’s quite a pity that the Legends of Echo team decided to outsource their work to devs in Bangladesh instead of drawing on additional local talent, but it’s still a grand opportunity to take a long, hard look at how co-operating with big businesses can work to our advantage. It remains to be seen how successful Echo will actually be, but the fact remains that Vincent Maher and Nic Haralambous were given over a million rand and eleven months to make a game with.

It may sound like a once-off matter, but other local developers have also benefited from the idea of piggybacking “non-gaming” entities. Luma Arcade, for example, is a local game development company which just recently showed off a preview title for Microsoft’s XNA-based mobile games. It started off as a small side project of its parent company (a more generic graphics studio) with just a few employees and a budget supplied by the non-gaming ventures of the broader company. Indie developers QCF Design also began building themselves up with advergames for companies like Colgate and Tropica (as well as unrelated web design projects) before moving on to self-funded game projects.

It’s not the most glorious model, but it’s one which appears to be doing some good — advergames and sponsored opportunities are a viable way to give small-fry developers a foothold in the local market, and may soon become an accepted stepping stone for people looking to cut their teeth on commercial game development.

Although it may be little more than a myth to some, the lesser spotted ludus modus singulus — also known as the “single switch game” in day-to-day discourse — is a very real and fairly common kind of game. It operates on just one rule: input must be limited to a single keystroke. No arrow keys. No mouse magic. Just a handy little button on your friendly neighbourhood keyboard or gamepad.

strangeThis kind of interactive entertainment has fascinated game developers since the beginning of existence itself, and oral traditions speak of a time long ago when such games ruled the earth, roving the vast plains and humid marshes of a much wilder planet. To this day they are still relatively untamed  by man, and only the most skilled — or foolish — of developers attempt to create them. But the rewards for demonstrating mastery over this genre are immense. Ask the creator of iPhone hit Canabalt if you have any doubts.

Nowadays, the average input device really spoils developers for choice. Keyboards are a sea of possible letters and numbers. Gamepads have thumbsticks, shoulder buttons and rocket-propelled grenade launchers up the wazoo. Even the humble Wiimote has quite a few input tricks at its disposal, especially when you consider the versatility of its motion sensor. But truth be told, not enough designers put that much thought into how players interact with their games: even when designing titles for something like a touch screen, too many devs try to force “many-button thinking” into a button-shy environment instead of forging new ground with the given platform’s unique restraints. I’ve seen it happen with cellphone games, iPhone prototypes and even mint dispensers, and the results can become rather… well, rotten. And rotten mints are just plain wrong.

One-switch games evolved as a tool to enable accessibility for disabled gamers, but they’re a damn useful exercise for developers in their own right. Offerings like Strange Attractors are excellent demonstrations of how versatile and interesting a project can become when given a one-button constraint, testing the developer’s ability to think in terms of context-sensitivity, emergent complexity and the various effects that any given environment can have on players. And sure, sometimes projects can be just plain fun (like the ever-delightful Dracula Cha Cha), but sometimes they’re also pretty astounding exercises in lateral thinking.


An interesting analogy would be to compare good game development to physical fitness (possibly the first and last time this will ever happen). For some poor, untrained bugger, doing a few laps across the swimming pool could pose quite a challenge. But if you force them to swim across the Atlantic — eliminating the practical drowning possibility, of course — those couple of laps suddenly become a lot less intimidating. Placing developers into such a restrictive situation can inspire levels of creativity and modes of thinking that otherwise may not have emerged.

A demonstration of some interesting one-switch games can be found in the Gamma IV games showcase, a collection of more than 150 titles which have also been featured at this year’s Game Developers Conference in San Francisco.

Have you ever tried making a game with a weird and creative constraint? Throw in a comment below and tell the rest of us about it!

Arguably one of the most difficult skills that a game designer can learn is the ability to duly cut something from a game. This isn’t simply about minimalism, or dropping features due to time constraints: no, this is all about hunting down and removing a piece of your own hard work from a project because the core idea unavoidably sucks.

We all hate undoing any sort of work that we’ve put time and effort into, but it’s something that’s important in just about all aspects of life. Writing several drafts of an essay can improve the final script, graphic designers often make multiple concept drawings for a single image and even scientists needs to be open to scrapping older theories in favour of newer, more accurate knowledge models.

Some game developers, however, seem to consider themselves exempt from this particular consideration: they hold the strange belief that once any given feature makes it into a game, that feature needs to stay there indefinitely. Somehow, subsequent versions of the game need to work around said feature’s flaw and turn it into an asset — after all, the more direct route of completely removing the feature would be too painful to even consider.

"The Team Fortress Engineer: always accept the possibility of your hard work being completely *obliterated*."

"The Team Fortress Engineer: always accept the possibility of your hard work being completely *obliterated*."

Fair enough. It’s difficult to kill one’s darlings, even for those who know that it may well be the right thing to do. We all have bad ideas from time to time, and such ideas can vary in scope: maybe it’s an errant menu option, or an unwanted enemy type, or even an entire section of the game. Of course, the size doesn’t really matter — if it turns out that an idea is well and truly poor, it’s time to throw it into the garbage compactor.

Many games go through an initial expansion phase, particularly if they’re complex or experimental in nature: early builds will attempt as many ideas as possible, usually because the best way to test an idea’s effectiveness is to simply code it in and see how it turns out. Dungeon Crawl Stone Soup, a massively popular Roguelike which has been in development for years, has taken this approach in many areas. This expansion, however, is tempered by an overall tightening of the design: along with every new feature added, the devs also remove classes, races, status effect groups and even entire spell trees — some of which have been in the game for a very long time.

Some players occasionally complain about the losses, but on the whole they tend to work towards a better game experience: even though the version number is at a mere 0.6, DCSS is successfully trimming a whole whack of game fat from its overall package.

Don’t be afraid of revising your own games: accept feedback intelligently, establish your project’s weak points and ask yourself honestly whether you can salvage them, or whether you need to remove them entirely. Remember that a wooden raft held together by frayed ropes is destined for trouble no matter how tough the wood may be. Strengthen your own raft by finding those weak points and replacing them with something better.

Anyone who has ever tried to make a game (or write a book / draw a comic series / insert long-term creative project here) is probably aware of just how gosh-darn difficult it is to keep going at it. Sure, that initial burst of creativity can fuel a working spree of a few hours, days, or even weeks if you’re lucky enough. But at some point or another, even the most focused mind working with the most amazing project is going to start wandering. Here’s some advice on keeping to the straight and narrow, creatively speaking:

Shorter games1. Make shorter games

If you find yourself struggling with those big game plans of yours, try getting some practice with smaller projects first. If you find your average attention span for any given game to be about a week, start thinking about stuff that you can create in a few days or less. Not only does completing smaller projects give you a much bigger motivational boost than a mountain of half-finished Homerian epics, it also sets you up with a far more appreciable portfolio.

2. Be consistent

Sometimes our brains just deal better with clicking into steady routines. As tempted as you may be to engage in periods of frenetic game dev activity followed by long cooldowns, you’ll probably end up doing yourself a world of good by opting to work moderately — and consistently — instead. Giving your project even a little bit of love on a daily basis makes a huge difference when compared to working with sporadic “chunks” on the odd weekend. Remember: once you begin a work session, it becomes a lot easier to keep going!

Get organised3. Get organised

In general, people find it far easier to stick to commitments and work routines when they’re not operating in a realm of hazy uncertainty. Schedule time for your dev projects if at all possible — earmarking particular hours or days for your work is far more effective than simply thinking about “getting around” to it between games of DotA. Making yourself a nice, lightweight design doccie to sort your mess of a creative brain while you’re at it.

4. Chop it up

Jot down a bunch of project milestones and make them as small and frequent as possible. Doing this will help you avoid feeling overwhelmed by the task at hand, and allow you to feel a steady sense of accomplishment as you complete short-term goals. After all, it’s far less of a mental strain to consider your work in terms of the next sprite animation or level design than it is to think, “Holy crap, I’ve got a whole MMORPG to work on!”

5. Keep it fun

If you’re a hobbyist developer who happens to be game making for the pure fun of it, you can take quite a few liberties with your work. Hate designing menus? Make do with a crude splash screen, or just hop straight into the game! If you’re not into the art side of things, focus on games with small, simple sprites that can work with fewer animations. If your project really does become the Next Big Thing, there’s always time to work on the annoying details later. As long as you’re not completely abandoning or confusing the player, you should feel free to do what’s fun for you.

Keep it fun

People tend to roll their eyes at the idea of making design documents for small-scale game projects. Fair enough: screwing around for a few hours to make a generic platformer doesn’t require the care, precision and co-ordination of, say, an Army of Two co-op snipe — it tends to be a more casual exercise with no concrete direction.

This in itself is okay, but creating a “lite” design doc for even your simplest of endeavours can move it from the realm of “something crappy and experimental” to the hallowed fields of “something crappy and experimental that has everybody going insane”. Taking your game seriously (or at least taking the time to document stuff) will benefit your final product immensely. The idea of becoming a more organised dev doesn’t guarantee passage to Awesomeville, but at least it can get you in the queue for a ticket.

For a real design doc, it helps to remember what you learned in those InfoSys lectures...

For a real design doc, it helps to remember what you learned in those InfoSys lectures...

For a start, lite docs offer you the opportunity to clearly realise your own game goals. In the same way that crafting a one-sentence summary of your game is a notable marketing must, the ability to jot down and regularly refer to a few of your overarching design goals can be surprisingly valuable for the game creation process. Want to add a new enemy? Check your goal list: if it emphasises momentum-based platforming action, then you can design an enemy to slow you down or bounce you away instead of doing something cliché like firing bullets.

Scribbling these core goals somewhere, even if nothing else is added to your documentation, can help you fight off looming feature creep: throwing random movement schemes into a game intended to be purely deterministic would be a bad move, yet it’s one that’s startlingly easy to make if a written reference isn’t handy. And when the game gets bigger and more complicated, you may not always remember the reasons why you’ve gone in a particular direction: plans made at the beginning of a project may well become blurry or even forgotten by the time you’re halfway through. This, more than anything else, can cause undesirable departures from your core “game plan”.

A design doc is also just a great way of forcing you to think through a game in advance. Sometimes, a project’s balance or progression can be vastly improved with a few scrawls and some pseudo-maths without writing a single line of code: for example, taking a page to summarise all potential enemies and their statistics helps you spot and fix undesirable effects before they emerge in-game among a bunch of more dissociated game objects and states.

...but an indie hobbyist's "design doc" can be hacked together in any form desired, for any purpose needed!

...but an indie hobbyist's "design doc" can be hacked together in any form desired, for any purpose needed!

Remember: a lite doc doesn’t need to be “proper” in any way. It doesn’t have to be a cast-iron set of rules that you adhere to. It can take the form of a comprehensive game plan, a stats sheet or even just a to-do list (if your game reaches any level of popularity at all, you can bet that there will be far more feedback and suggestions than you can easily remember). You can use a tool like WikidPad to organise your thoughts, or just fire up a handy copy of Notepad and start jotting down ideas.

The ability to communicate and store your ideas is an important life skill, so why not apply it within the realm of game dev? It’ll help you out immensely — both now and later.

Over the years, I’ve often expressed my deep and profound respect for the casual gaming industry: a branch of game development that is so often vilified because it supposedly appeals to stupid and unappreciative gamers. Aside from numerous write-ups in places like Dev.Mag, I also tend to explain my stance when chatting to friends and co-workers about classic joys such as Bejeweled, Lode Runner and even Minesweeper.

Of course, my own humble words may be considered about as effective as hamster droppings in a hailstorm. After all, who am I to persuade people that these shiny, simple games aren’t every bit as heartless, money-grabbing and uninspiring as popular culture makes them out to be? What self-respecting developer would create a game using only an elegant ruleset, a super-friendly interface and a streamlined routine that can see a session’s completion in as little as five minutes by practically anyone? The sheer nerve!

Contrary to popular belief, this isn't the only end goal for gaming.

I know that there are many cash-ins out there, and quite a few projects on websites like Facebook are the sort of things which make me silently throw up in my mouth until the mess starts dribbling down my chin, but this doesn’t mean that the casual game market as a whole should be maligned by developers. I recently had a delightful exchange with Jason Kapalka, a PopCap co-founder who confided that many PopCap employees — despite their drive to make “light” and accessible games — are gigantic fans of hardcore titles such as roguelikes and in-depth strategies. The devs that they employ certainly aren’t stupid, and even their most outwardly simple titles are created with determination and purpose: design decisions are made carefully, and everything is polished to a shine to make for a well-balanced and rewarding game experience.

Casual game development is one of the best ways to train up good game development skills: offhand, one can reason that it teaches you how to be nice to players, encourages you to make your games function on a very raw (and fun) level, and even frees up a bit of time to let you focus on alternative game design skills such as writing and level design.

Many people play and enjoy Minesweeper, yet it can still be maligned in "serious" game discussions.

Many people play and enjoy Minesweeper, yet it can still be maligned in "serious" game discussions.

Of course, casual games are a breeding ground for not only refinement, but experimentation as well. Consider Flash portals like Newgrounds and Kongregate which host thousands of online games, many of them under a megabyte and requiring only a few minutes of very simple play. Sure, there’s a bunch of pretty epic titles in the list, but many of them are designed to marry charisma, accessibility and a completely new play style to appeal to anybody who has half a mind for experimentation but not a lot of time to pour into anything.

… and consider the original game prototype for World of Goo, which basically consisted of stacking a tower of icky blocks to see how high you could go without the whole thing toppling over. What a simple, charming, casual game concept!

If you still think that casual games are limited to the realm of the uninspired and money-hungry, it’s probably time for a radical paradigm shift. Defining what a casual game is can be a difficult task in itself, and standing on the hardcore pedestal is one of the single most limiting acts that you can take as a gamer and designer. Don’t fall into this trap: keep your mind pried wide open and remember that you don’t need an insurmountable wall of complexity and prestige to prove a game’s worth to anyone.

There have been a lot of things attributed to game development, but normality probably isn’t one of them. In fact, it’s been scientifically proven that the concepts of “regular” and “game developer” are mutually exclusive, and even addressing someone as “a normal game developer” brings the entire universe that much closer to a divide-by-zero implosion.

Of course, this sacrifice of normality brings about some really interesting and awesome scenarios. Imagine this: you’re locked inside a computer lab for 48 straight hours with several dozen other crazies and the end goal of making a game before your detention time expires. Aside from fellow developers, your only companions are some webcams tracking your work, enough caffeine to poison an elephant and whatever you can bang together to sleep on for an hour or two. Free pizza is abundant, and the frayed psyches of participants are held together by high hopes, amazing concepts and raw grit. This is the ultimate test of man’s endurance and determination.


Caffeine: our shining beacon in the darkness.

The Global Game Jam, which took place over the final weekend of January, was the execution of this very situation. Despite the misery and insanity that the above description implies, it was also surprisingly awesome: grouping so many individuals with such a passion together and asking them to do what they love can be an amazing thing despite the odds, and the promise of prizes and glory just sweetens the deal. On top of that, the “global” part means that people are doing this all over the world at pretty much the same time.

Ten games were produced in the local leg of the Jam at the University of Cape Town, with the competition theme of “Deception”. Additional game constraints and achievements were provided for bonus bragging points, and participants were able to use whatever tools they desired: Flash, Game Maker, PyGame, Unity, Unreal … anything they could get their hands on and bring to the table.

The Game.Dev community sported two entries amongst the local participants: first place went to ~Press Tilda, an intriguing platformer game which relied on “console commands” to manipulate obstacles, destroy enemies and find cunning ways to the level exit.

A herd of wild developers is spotted on the horizon.

A herd of wild developers is spotted on the horizon.

Game.Dev’s other representative game, YouDunnit, took second place at the UCT competition, presenting a causality-based, futuristic murder mystery where the player is trying to establish a suitable alibi for the heinous crimes that they committed.

Third place was awarded to Module, a physics-based machine creator which required players to go head-to-head and carefully manage resources while constructing the ultimate spaceship to destroy their opponent. This project was constructed by a team of six dedicated UCT students.

Prizes included several Take2 vouchers, assorted gifts from sponsors such as Derivco, Afrigraph and UCT, and even an Xbox 360 elite along with a full range of accessories.

If you’re interested in the Global Game Jam, hop into the Game.Dev GGJ discussion thread or visit the site itself for more info. It happens at the same time, same place next year and is a whole whack of fun.

Sometimes a game relies on the element of surprise to keep players on their toes and generate tense or action-filled moments. Horror titles do this a lot — sometimes a monster will leap out of the closet, or your in-game avatar will be shocked to find that dinner is actually a bowl of cabbage soup instead of a candy bar fountain. Some surprises don’t go for the scare element, but nevertheless require a quick reaction to sudden events: for example, conversation threads in Fahrenheit, or the end-of-stage block changes in Lode Runner.

There is, however, a certain hard limit to how surprised a player is allowed to be. Shock them in a safe environment, sure. Maybe even throw in some danger as long as it’s not immediately lethal. But for the love of gooballs and meat men, don’t ever go down the dark path of complete unfairness. Avoid dickery: give your players reasonable warnings.

Good games, old and new, know when to “telegraph” the right messages to players in advance. In classic platformers, bosses blink or shift posture before unleashing an attack. In Shadow Complex, power armoured opponents laboriously lift their arms before unleashing a killer strike. No matter how subtle these warnings may be, players take note of them and use them to do something before they get sliced/squished/punched to death. Like important clues in a detective game, advanced warnings of any sort — even if they’re just half a second in length — make the difference between a fun, challenging experience and a purely frustrating one. Being proactive is a good trait, but in the world of gamers, skilled reaction can be just as important.

For example, consider the two different gaming experiences offered by these Super Mario Bros. screenshots:



You’ll probably notice right away that simply having access to the full screen offers players a vast array of warning information not provided by the subsection. Leaps of faith aren’t required — platforms can actually be seen before a jump attempt is made, and the presence of enemies is noted long before the player can make actual contact with them. Even “surprise” elements such as cannon balls or Bowser’s fiery projectiles still offer a critical second or two of “Hey look, I’m over here!” before they actually meet the player.

Would you be able to play through the adventures of everybody’s favourite plumber if you only ever had access to Screen B? And even if you could, would you really want to?

Giving players suitable warning space is an oft-overlooked and rather subtle feature in game development. This is hardly surprising: it’s just one of those game elements which goes completely unnoticed when done properly, but ruins everything when it’s screwed up. If you put surprise or shock elements into games — particularly action titles — always ask yourself two questions:

(1) Could the player have reasonably predicted this behaviour or event?
(2) If not, does the player at least stand a reasonable chance of survival?

Consider these questions carefully: answering them honestly may just make the difference between a crappy and frustrating game, and a totally rad one. Nobody likes leaping off-screen only to be instantly chowed by a giant walnut — don’t make the same mistake in your own work. Give your players the break they deserve.

People who know me well enough are usually aware of my obsession with a Rogue-like game called Crawl. It’s said to be one of the most fiendishly difficult offerings from an already fiendishly difficult genre (victory is a mixed bag of “holy crap, I’ve finally won!” and “holy crap, what have I just wasted years of my life on?”), and stands alongside the likes of ADOM and Nethack as a popular activity on any masochistic gamer’s schedule.

What fascinates me most about the game is the documentation outlining its core design philosophy. Everything in the Crawl world is purposefully designed to be affected (and used) by the player in some way, from subterranean plants and mysterious altars to smoke clouds, water puddles, and even ordinary dungeon walls.

Better yet, every interaction is meaningful. Deciding how you’ll attack an enemy or deal with a dead body is never a straightforward process – the game is built in such a way that you’ll never have ridiculous quantities of any resource at your disposal. Even the most potent spellcasters will occasionally need to conserve mana and attack weaker enemies in hand-to-hand combat, while shop prices are structured in a way that forces careful spending of gold.


Crawl: a world where players should never, ever let their guard down

This is one of the secrets of absolutely awesome game design. Yes, a lot of games depend on rhythm and figuring out sequences through repetition, but other games inspire us through their lack of order – the idea that no matter how good you get, you’ll always have to pause and think about your next move and how it will affect you.

Some developers consider “obvious” decisions to be anti-game moments. If players know from the word go what needs to be done, the challenge is rendered moot and it becomes a matter of grinding one’s way to the finish line. The puzzle is solved in advance, the tactics have been figured out, and the intrigue is over with before a situation even begins. When victory is assured in such a manner, time investment becomes the only obstacle. And while steady progression and raw achievement accumulations are effective psychological hooks in themselves, the issue of meaningful gameplay can make the difference between a nice game and a truly great game.

If you’re designing a game (particularly a turn-based or puzzle title) remember that half of its value for a player will stem from making meaningful decisions. If there’s an obvious and one-dimensional way to approach all situations, consider designing instances and levels that force a rethink or even turn rules on their heads. When you add something to your game, make sure it has meaning and significance. Carefully consider every single element that you add, and try to give it depth – either on its own, or in the way it interacts with everything else. This doesn’t mean that you have to make a game as difficult and complicated as Crawl: far from it, in fact. The concept of meaningful design goes hand in hand with minimalism, and is especially important for indie developers who can’t afford to waste any resources on padding and weak concepts.

Do this, and you can turn your gaming experience from a routine chore into something that will engage and interest your players from beginning to end.



Login / Search

Latest games

Latest opinions