Category Archives: games design

Game Pitches – actual pitch docs from real games

http://www.gamepitches.com/ (just discovered this, via TCE):

The repository for video game pitches and design documents

This site serves to be a free resource to game designers offering them the web’s largest single collection of game design documents and game pitches.

It says “resource got game designers”, but … pitch documents are hugely valuable to anyone working on the business/funding side too. (there are two aspects to the site – design docs, and pitch docs).

There’s some good stuff on there – from the GTA design doc to Spider’s original concept doc. Note to fledgling designers: they’re impressively brief and succinct!

…and if you work for a studio or publisher, perhaps you could ask about getting some of your company’s old pitch/design docs put up online?

Using Genetic Algorithms to playtest an iPad game

Looks like a “normal” KickStarter project for a new Tower Defence game.

Halfway through the demo video, it switches to “here’s how I’ve been using GA to detect game-design flaws, and to test ideas in tweaking game design”.

Something I’ve wanted to do for more than a decade, but could never find a company who’d take it seriously :). I really hope this iPad game does well – would be great to see a poster-child / real-world demonstration of a workable technique here.

New game (Risk clone) – need SVG maps!

As a free-time project, I’ve been writing a Risk clone (*) for iPad.

One of the bits I like best right now is that you can give it the URL of *any* SVG file on the web, and it automatically turns it into a Risk map.

(e.g. all the maps in Wikipedia articles are SVG files – it’s a common file format with good browser support)

This was one of those “interesting” technical challenges – I had to find an algorithm that would automatically work out which territories a human would “assume” were connected to each other.

I’m using an open-source SVG library which works fine for basic SVG files but has a lot of bugs with the more esoteric ones. I’ve already fixed a few of the major bugs (they’re now merged into the GitHub project) – but I’d like to get more SVG files to test with.

The one thing to bear in mind is that the colour-data gets wiped when it imports. So … SVG files that make heavy use of different colours or gradient-fills/pattern-fills lose detail when imported.

Also, files where none of the elements are close enough to be deemed “connected territories” … work poorly.

Everything else works fine.

So … if you’ve got any, please post a comment here with URL, or email them to me directly (address in the About link at top of this page).

(*) – I say “clone” because it’s the same genre – but the gameplay is “fixed” quite a lot. If you once loved Risk, but grew to hate it, you’ll see why I wanted to change the baic game design :).

GDC 2012 Rejection

Against my own advice, I submitted an eleventh hour proposal for the 2012 GDC. I’ve fallen in love with San Francisco, but I’m in two minds about going next year, it seems to have too much of E3 about it. The simple beauty of a conference for games people, about games, feels washed out and faded away.

“While we can’t comment on why individual submissions were declined due to the high volume of submissions received, be aware that it can often be due to multiple reasons — many of which have nothing to do with the professionalism or quality of the talk proposed.”

The more time I spend around inspirational people, the more I realise that it is never acceptable to refuse reasons for a decision. Usually, the reasons are things you’d rather not hear – criticisms too close to the bone, complaints too painful but fair – but they are things you need to hear anyway, to have a decent chance of moving forwards as a person.

CMP / Think Services is in the unenviable position that they own the only global event that speaks for mankind’s total relationship with computer games. I’m sure it seemed like a good commercial play at the time – but how fair is it that they now must shoulder the total face-time of every step forwards in the art and science of game development? Tough crowd, if you ask me.

Or is there some other (non judgemental) forum for face-to-face game design that I’ve missed?

Prototyping: Chess Quest v0.4

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

Major changes:

  1. Enemies have health, and can be killed by touching them
  2. Performance is another 30% faster (should be running OK on most phones now?)
  3. Enemies have a direction indicator (not necessary right now, but it’ll become important in a later version…)

Download link

Chess Quest-0.4.0

16 KB Game Competition (winter 2011) – Java

http://www.java-gaming.org/topics/lwjgl16k/25093/view.html

“the LWJGL16k competition starts right here, right now.” – Cas

The rules

First deadline: 25th November 2011
First task: get a black screen running using LWJGL

“you’ve got 7 days. All I’m looking for at this stage from you is a blank window opening up and maybe a rotating square or whatever. Of course complete games are even more welcome but the idea is to get something shipped.”

Well, what are you waiting for?

If you’ve got Eclipse installed, all you need do is download the LWJGL library, copy/paste the 50-line minimal project from the Wiki, and submit your entry!

(I believe Cas is onto a good thing here … force people to realise how easy it is to make a game if you focus on small-but-visible steps done *quickly* – No more procrastination!)

Prototyping: Chess Quest v0.3

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

Three major changes:

  1. You have a health bar, and can die
  2. The trackball is now supported for movement
  3. Performance is literally 1.5x – 2x faster

Download link

Chess Quest-0.3.3

So, a friend of mine tried it out today, and he couldn’t move around at all – something wrong with his HTC Desire (even though I’ve been testing on near-identical phone, for some reason his phone was losing the input gestures). This evening I did some improvements and fixes until it began to work “tolerably” on his phone – and I threw in some new small features too.

It’s still test stuff – not indicative of the final gameplay, but I’m trying out different basic ways of achieveing the stuff I want to achieve in the later versions.

Overview of what’s changed

  • You have a very basic HUD
  • There’s a couple of coloured powerups scattered around – red restores health, green increases maximum health permanently
  • Enemies actually kill you now, every moment you’re touched by one, your health drains continuously
  • You can choose different levels at the start – I included one of the early test levels that was easy for me to upgrade with recent changes. I’ve got another one I can probably add quickly later (one which generates 100% random mazes each time you play)
  • The ultra-simple EntitySystem I’m using was running too slow. There’s no simple fix I can see – the ES really needs to be written for performance, if I want it to be high performance – but I was able to do a 10-lines-of-code workaround that took the worst piece of bad performance in my game and made it literally 5 times faster. That’s good enough for now!
  • Input system has changed *again* – the Android OS has poor input management, a bit buggy, with an inconsistent programming API, which *also* runs differently on different phones – so I keep trying to do as little work on this as possible. The Android OS is desperately trying to prevent me from doing any prototyping at all – it’s begging for me to write hundreds of lines of code to make up for Google’s inattention there – but if I do that, I will lose all the time I would have spent doing game design and dev, and the whole project will be a failure. So, yet again, I’m putting on a band-aid and dodging the rest for now. But … at least now you can use trackball instead of / in addition to swiping on the touchscreen
  • There’s an FPS counter on the screen

Prototyping: Chess Quest v0.2

(I’m prototyping a new game (working title: “ChessQuest”) – original post here)

A couple more hours work, a few more changes:

Overview of what’s changed

  • Obvious from the screenshot: added alternating black/white background tiles. I want it to feel like the traditional chessboard has become the “floors” of the dungeons/towers you’re exploring
  • Major fixes for collision detection: player and enemies now do pixel-precise collisions (previously, if e.g. a piece moved 5 pixels per tick, it would move either 0 pixels (if 5 would collide) or 5. Now it moves “as many pixels as it can before the collision happens”)
  • Major upgrade to renderering: instead of just “render everything, in random order” it now sorts all sprites once per frame. Each sprint is instantiated with a sort-layer; things in the same layer are rendered in random order, but before all things in the next layer
  • Minor tweaks to movement: not happy with this, but I found the “never stops moving” annoying. Now I find the “stops too easily” annoying.
  • Various experiments with zoom level – I tried 20px, 32px, 64px and 100px (very zoomed in!). I found 32 px was working nicest on the Nexus 1, so I’ve stuck with that for now. In a future build, I’ll probably bring back the option to switch to a zoom level of your choice.
  • Added Flurry: I’ve never done this with a prototype before, but then I’ve never prototyped in public :). I’ve added Flurry just so I can keep track of how many people are running the prototype; as I add to the prototype, I’ll start adding in-app feedback options, so you can effectively “vote” on things you like/dislike, and I’ll use Flurry to graph it all automatically.

Download link for this version

Version 0.2

Game prototype: Chess Quest

Last weekend, I was playing around with some ideas for a Chess / RPG mashup. I did some prototyping with Android (because iPhone apps can’t be shared, and Java is much faster to debug than ObjC).

If you’ve got an Android phone, try this, and let me know if it runs:

There’s not much you can do – touch and drag on the screen to move up/down/left/right (you’re the Rook – hence no diagonal moves). Bishops and pawns wander around randomly, pawns slower than bishops.

UPDATED: if you rotate the screen sideways, it’ll randomly pick a different size / zoom level. There’s four sizes, from 20×20 squares up to 100×100 squares. Player moves at different speeds based on the size too.

I wanted to make it a dungeon-exploration style, but with a Chess theme – and (like in chess) each time you complete a dungeon (kill the boss) you get to “pawn” and switch your character to the chess piece you killed.

i.e. first boss would be the Rook, second the Bishop, third the Knight, etc.

…but I’m not sure I’ll stick with that. If I get some more time this weekend, I’ll prototype a bit more.

NB: the APK above might run slow – I’m interested if it looks jerky / doesn’t work on your phone. It runs fine on an old Nexus One.

Alarm bells for Game Design failure: “evolving” someone else’s IP

There’s a new Syndicate game in development. After one of the most facepalm moments in game design – taking a unique game-genre and replacing it with an FPS, at a time when FPS market is massively over-saturated – the studio has gone one further:

“we’re taking the Persuadatron and evolving it”

It’s always possible that they’re going to make it better. On the balance of probability, that’s unlikely.

Even leaving aside the amazing decision to remove the single most important feature of the original IP – the genre itself. NB: this has been tried before: Syndicate Wars changed the core gameplay, and was a commercial failure (given the previous sales of the IP).

Sadly, it seems that in press conversations, “evolving” is often short-hand for “putting our own “stamp” on it, by changing it; it’s the change that matters, not the improvement. We MUST be able to claim this is “our” game, and not the original designers’”.

Often, it seems the thought process has gone something like this:

“the original idea was unique. At our studio, we don’t have many unique ideas – so we’re CERTAINLY not going to let anyone see how weak they are when contrasted with the genuinely strong ones in the IP we’ve just taken over.

Our cunning plan is to remove all the unique, innovative aspects of the IP, and replace them with dumbed-down, crappier mechanics that we thought up ourselves. But stick the original name on the new mechanics.

This way:

  1. we won’t be made to look stupid by our own game
  2. google searches will turn up YouTube videos of our scuppered mechanic, and people hearing “X was a great idea” will look at it and go: “Hmm. Not really”, without realising they’re looking at the scuppered version

(I’ve worked on two teams that tried to get approval for re-making Syndicate (not Wars!) over the years; I’m a big fan of the original, and still occasionally play it on an emulator. It’s amazing how much people want to over-complicate it – somehow forgetting that the original studio (Bullfrog) was reknowned for it’s quirky/bizarre/unusually inventive game designs, and that they’ll have a lot to live up to if they want to “extend” that)

RPS says it best:

designer Rickard Johansson: “I don’t want people to stop playing the old games, but time has moved on.”

Has it? Has it really? Perhaps he didn’t notice that Starcraft 2 outsold most of EA’s (and everyone else’s) portfolio last year. Perhaps he didn’t notice that SEGA refer to Total War as one of the major jewels in their crown. Perhaps he didn’t notice that Valve are spending a fortune on a DOTA remake. Perhaps what he really means is ‘publishers will give us a bigger development and marketing budget if we make it a first-person shooter.’

LudumDare 21: Escape from the (Android) Pit

I couldn’t enter this LudumDare competition on a technicality, but here’s my entry which plays by the spirit of the rules. I took a total of 24 hours (out of 48), of which only 12 were actual design + development (see below). Hopefully next time I’ll be able to do it properly, and actually compete. I’ve kept to every rule, except that I did my 48 hours time-shifted :) from everyone else (two successive Sundays, instead of a contiguous Saturday + Sunday).

Screenshot + Android APK

Download link (APK – you need to know how to install APK’s manually (google it if you’re not sure, it only takes 5 seconds)):

Escape From the Pit

Aims

  1. Make a LudumDare entry as an Android application – none of this easy “make it in Flash” or “make it in java” stuff – let’s go for a full mobile game, designed, developed, and launched in exactly 2 days flat!
  2. Use an Entity System (c.f. my long-running series of articles, and also the public Wiki I created), and show that ES’s facilitate you writing new games VERY VERY QUICKLY
  3. Make a game that was mildly challenging and (almost) enjoyable

Failed to officially enter the competition, but otherwise succeeded…

Background

LudumDare challenges you to write an entire game in under 2 days (technically: 48 hours – it’s up to you how much of that you sleep). You can’t even design it in advance – there’s a theme that’s only decided shortly before the 48 hours starts.

LudumDare was the weekend before last – but I had to work that weekend on urgent day-job stuff. Like: I had to work all day Saturday, and there was no way out of it. So I couldn’t do the same 48-hour stint as everyone else.

Also, I know from previous experience that the “48 hours in one stretch” is very different from – say – “12 hours for 4 days”. When you do a 24 or 48 hour game, you tend to only manage a certain percent of “productive” hours. The challenge of designing + building something from scratch forces you to keep taking “time off” to go think about what do next.

So, I kept a diary of hours worked, and hours taken “off” as well. I’m confident I’d have fitted all of this – development time AND down-time – into the 48 hours. But I had to spread it over 2 successive weekends :(.

Day 1

(3 hours) – install Eclipse and the Android plugin, and the Android SDK. Document what I’ve done (1 hour) and check I can re-do it at will. Google, please wise-up and fix your install process – it’s not changed in almost 2 years, and it SUCKS

(1 hour) – install some extra Android OS versions, get the emulator working correctly, get projects imported, get everything in source-control, get empty app running on hardware device. Ready to start project!

— NB: everything up to this line I should have done before the contest started. If I were the kind of person that had free time on weekdays. Which sadly I’m not —

(1 hour) – getting Android base classes up and running. Takes a while: Android is insanely badly designed for the “Core application” part. Needs hundreds of lines of code to make a Hello World app that *actually* works as an app (Google’s code example that does it in 4 lines is fake: no real app could do that).

(3 hours) – on the beach, not working

(4 hours) – upgrading the open source Entity System Libraries on http://entitysystems.wikidot.com to support a bunch of features I’ve been using for a while in my own projects. This required writing a lot of stuff from scratch (using my own old source as inspiration), and integrating some improvements from patches/forks that other people had submitted.

— NB: everything up to this line I could have done before the contest started. Interesting though that I thought this was going to be “about to start writing the actual game” and I’ve only finally got to the point where I can write my first line of game-code —

Day 2

(0.5 hours): trying to make textures in Photoshop. Photoshop really sucks. Half the online resources for making the kinds of textures I want require PSP’s unique filters/effects – useless :(.

(0.5 hours): get a single sprite to appear on screen. A couple of idiot errors in one of my libraries – plus Google’s Eclipse plugin being really really bad at understanding “the scroll bar” (bug in ADT: it implements the world’s only non-static scrollbar)

(1 hour): random maze generation (using: http://en.wikipedia.org/wiki/Maze_generation_algorithm#Randomized_Prim.27s_algorithm ) that makes nice mazes, printing out onto the screen, still with my default “starfield” background. Rotating the screen is causing the entire game-state to be regenerated – includkng the maze – which was an accident, but actually helped A LOT with testing the maze algorithm (just tilt to re-run the algorithm instantly)

(0.5 hours): learn how to do Android input-handling correctly; en-route, discover I’m missing the SDK docs, and set about downloading + installing them … + updating my blog instructions on how to install Android to include “SDK docs” as a section.

(2.5 hours): discovering MAJOR bugs in Google’s basic “touch handling” API for Android – including bugs on Google’s own website source code, and an API designer on crack who broke the core Java contract didn’t document it. Not Happy.

Day 3

(1 hour) – implementing a collision detection system that does proper swept-collisions, but works OK with the poor fine-grained control of touch input

(1 hour) – added filters to collision detection so I could have background images that the player will NOT collide with
(previously was colliding with every on-screen rendered sprite). Also added a very simple lighting system where squares that the player has walked close to or upon gradually light up, showing how much has been explored

(1 hour) – refined the user-controls so you can hold your finger still and character keeps moving in that direction. Added handling in collision-detection system to allow character to slide along walls and into side-passages without the player having to stop and be ultra-precise (pixel perfect!) in timing the change of direction.

(0.5 hours) – added an exit, fixed bugs in the maze-generation (if started on a right or bottom edge, it crashed)

(1 hour) – fix Android’s brain-dead handlig of Bitmaps, giving a big speed boost, and re-learning how to use DDBS memory-allocation-tracking. I’m now auto-caching each bitmap inside my Sprite object. Sigh. There’s no easy workaround: Google says “don’t use getter methods” but Google also says “don’t call our getDrawable method more than once”.

(1 hour) – added ghosts, made them move around the map nicely, and collide with player was *automatic* on first compile (freebie from using an Entity System!). Also made arrows float nicely in same place on screen even while scrolling.

(1 hour) merge code from laptop back to desktop. Finally add the “win” conditions that makes the app playable!

Source Code

To make this game, I improved the basic Java Entity System up on the ES Wiki, and added some usability improvements and features. I created a whole new page for it here:

http://entity-systems.wikidot.com/rdbms-beta

NB: It’s called “Beta” simply meaning “second generation (beta == second letter of greek alphabet)”. Not because it’s a beta-quality release :).

Source code to the game itself is also up on github right now – https://github.com/adamgit/Game–Escape-from-the-Pit – although that’s a closed repository at the moment. I want to double-check there’s nothing included that shouldn’t be before I set it to “public”.

Fix for Master of Mana Fay/Faerie suicides

Typical. Just as I finally brave the source code to Master of Mana (neé Fall From Heaven; the most popular / succesful mod for Civilization 4), and fix a major bug that’s bothered me for ages … the main server at masterofmana.com goes offline :(.

Anyway, if you’re playing the Fey, and you’re tired of the fact it becomes impossible after a certain point – when you put Faeries onto ships, they self-explode, turning the tile into land (usually Never-Never), here’s the fix. It’s especially bad for True White Faeries – which means “all of your top units” beyond a certain point in the game.

Edit the file:

[C:\ ... path to your Civ4 folder]\Beyond the Sword\Mods\Master of Mana\Assets\Python\Wildmana\Civs\CvFaeries.py

Find the following lines (very near the top):

		if pUnit.isHasPromotion(iPromWhite):
			iSnowChance=20
			if pUnit.plot().getOwner()==-1:
				iSnowChance+=-10
			if pUnit.plot().getOwner()==pUnit.getOwner():
				iSnowChance=-100
			if iSnowChance>CyGame().getSorenRandNum(100, "snow fall"):
				pUnit.plot().setTerrainType(iSnow,True,True)
			if pUnit.isHasPromotion(iPromGreen):
				if pUnit.plot().getFeatureType()==-1:
					if CyGame().getSorenRandNum(100, "Faerie plant trees") <= 75:
						pUnit.plot().setFeatureType(iForest, 1)
			if pUnit.isHasPromotion(iPromTrueWhite):
				pUnit.plot().setTerrainType(iNever,True,True)
	
		if pUnit.isHasPromotion(iPromTrueGreen):
			pUnit.plot().setFeatureType(iEternal, 0)
	

and replace them with this: (NB: because Civ4 is scripted in the horrid Python, you're going to have to be careful to get the indentation correct manually; Python is wonderful, except for this one feature - it makes sharing code changes like this much harder than it should be :( IMHO)

		if pUnit.plot().isLand():
			if pUnit.isHasPromotion(iPromWhite):
				iSnowChance=20
				if pUnit.plot().getOwner()==-1:
					iSnowChance+=-10
				if pUnit.plot().getOwner()==pUnit.getOwner():
					iSnowChance=-100
				if iSnowChance>CyGame().getSorenRandNum(100, "snow fall"):
					pUnit.plot().setTerrainType(iSnow,True,True)

			if pUnit.isHasPromotion(iPromGreen):
				if pUnit.plot().getFeatureType()==-1:
					if CyGame().getSorenRandNum(100, "Faerie plant trees") <= 75:
						pUnit.plot().setFeatureType(iForest, 1)

			if pUnit.isHasPromotion(iPromTrueWhite):
				pUnit.plot().setTerrainType(iNever,True,True)
		
			if pUnit.isHasPromotion(iPromTrueGreen):
				pUnit.plot().setFeatureType(iEternal, 0)

Yep - it's really that simple (insert one line, and re-indent the ones below):

"if you're at sea, don't turn the ground your ship is on into land. Because that will destroy the ship, you, and everyone else nearby"

I'm pretty sure it wasn't intended to do that - it would be an ultra-powerful ability to create land - automatically - instantly for the cost of a cheap ship and a level-1 faerie. If you really want to play that way (if you can be bothered), it's easy to create a Giant's Causeway like that in the current build of the game, making land out of the dead bodies of the Fey. But it's a very dull way to play, and it feels more like an innocent oversight...

PS...

If you're not playing Master of Mana, and wondering why anyone would care about a Mod for a game that originally shipped *almost 6 years ago*, then I strongly suggest you buy yourself a copy of Civ4 + Beyond the Sword expansion (usually bundled together for $30 or less), download MoM, and find out what you're missing.

The modded game is IMHO highly illegal - they stole art liberally from many many copyrighted sources - but the bulk of the content is their game-design, and that's fantastic. Many times better than many games released today - and (partly thanks to the lack of legal assets) the authors charge nothing for it.

The saddest / greatest thing about this IMHO is that 2KGames / Take Two did so little with this modding community. Beyond a few token steps (the dev team made the sensible decision to hire some of the leading mod authors, IIRC) they pretty much ignored it. They're making substantial money out of the mod authors - Civ4 should not still be selling as expensively as it does, and I'm sure this mod is the main reason it does - but they could have made a lot more. Look to Valve, and imagine what might have happened with a little more visionary leadership at Firaxis and Take Two...

Papa Sangre devs: are you sure it’s not because…?

“[with Android] We just can’t get complicated applications functioning with any kind of speed (if at all) … it’s not because we’re stupid or don’t know the platform well enough”.

(From this month’s Develop – an article by the the CCO of Somethin’ Else)

Develop is trade-press, for professional game developers (mostly coders, IME). No further explanation was given.

Kind of hard to believe, considering our own experiences on the platform. I asked a few others for their considered opinions. First three reactions:

  • “WTF?”
  • “Bollocks”
  • “Bullocks”

Hmm. I’m intrigued to know what they can code on an iPhone 3GS, but not on the more powerful Android phones from 2010 (let alone the ones from 2011).

Telling stories with Minecraft and GitHub

Minecraft is great. But it has one major problem: the narrative of each world is destroyed as it is created. Unless you work hard to do otherwise, the history of your relationship with the world is lost very rapidly. There’s no strata, no wearing, no signs of your involvement – just a too-clean result.

I found myself often deliberately “preserving” key moments in my worlds, such as:

  1. never alter the place I spent the very first night, except enough to allow a tunnel out into whatever larger base/home I turned it into
  2. as much as possible, build structures WITH the landscape instead of AGAINST it; the contours of my buildings, roads, railways are very little altered from the land that they’re build on / in / around / underneath / through
  3. mine and house entrances made as subtle as possible; e.g. all-glass exits from the water that are almost invisible from a distance, but glow slightly blue at night

So, here’s an experiment: a playthrough of Minecraft, but doing frequent git-checkins (approx once a day/night) to this github project.

I don’t even know if it’ll work; in theory it should – I’m versioning the Save directory for a single world – but I haven’t tried importing it to a new PC / install of Minecraft yet.

Feel free to try it – checkout the first checkin, see if you can load the world (NB: the save-directory is named “versioned” on my copy of Minecraft; you might need to name the containing folder the same).

Then try using git to advance through the different checkins, and see if you can view the world as I explore and modify it…

Richard Bartle: 10 Games you Should Have Played

Normally, I don’t allow “guest posts”, but I’m making an exception for my “10 Games You Should Have Played” series. I’ve been asking other games-industry people to write up their own lists + explanations, and that’s not always compatible with their personal/work/etc blog. When that happens, I’m happy to post them here instead.

So, here’s Richard Bartle‘s take (“co-creator of MUD1 (the first MUD) and the author of the seminal Designing Virtual Worlds” – but if you read this blog, you should already know who he is ;).

I think it’s a great list. I asked him to define in his own way what he meant by “should” (why are we saying “should”? who’s the audience? etc) and to run with it, which he did …

Come up with your own rules for a top-10, define it clearly, and share your list.

“OK, well modulo all the usual complaints about lists of 10, here we go.

I don’t have any rules per se, but I am sort of assuming that this is for people who play games or design games or want to know more about games.

Also, I’m going to go with categories rather than individual games (except in the last case). This is because it’s not the games themselves that are necessarily important so much as what you get from playing them. I will, however, give an example of a game in each category that I myself have tried.

1) A game you have bought but haven’t played yet.

You should always have a game ready to play. I don’t care what it is, but unless there is one you’re never going to expand your gaming horizons.

For me, right now that game is “Victoria II”, which I’ve installed and read the manual for but haven’t actually started to play. The reason I haven’t started it is because I bought “Mount & Blade: with Fire and Sword” and snuck that in front of it in the queue. Once I do start it, I’ll be looking for another game to play when it’s completed – hopefully not another damned sequel…

2) An abstract game.

Games can be many things, but unless they have gameplay they’re not games. An abstract game only has gameplay. To understand games, whether to design, play, or study them, you need to understand gameplay; an abstract game shows you the game mechanics with everything else stripped away.

You need to play one. You may, if you’re keen, try think of a skin for it, but that’s not essential.

In my case, I guess the game would be “Chess”. I captained my primary school Chess Club, but my interest in the game waned when I realised that the openings were always the same and that people who were less good at the fun, thinking part could win by doing the boring, memorise-the-openings part. That came straight from an appraisal of the clear-for-all-to-see mechanics.

That said, I’d also like to give a shout-out to the altogether more obscure “Besikovitch’s Game”. Now that’s a mechanic with potential…

3) A tabletop role-playing game.

Everyone thinks they know why they want to play games, but they also need to know why everyone else plays games. They’re not going to get that unless they understand what it means to be part of the game. In a tabletop role-playing game, with the other players right there next to you, there’s no escape: you have to participate, you have to involve yourself, you have to become part of the game, part of the narrative. In short, you have to live the game. Unless you’ve lived a game, how can you ever hope to understand what’s gamingly possible?

For me, the hours I spent playing “D&D” with my friends in my late teens were some of the best gaming experiences I ever hard. I wish I’d been able to get a “Call of Cthulhu” group going, mind you, but it came out too late for me.

4) A spectator sport.

If a game is good enough that people will pay to watch it played, you need to understand what it’s like to play it. This gives you an insight into the theatrical aspects of games that you wouldn’t easily get from merely observing the performance. You don’t actually have to be any good at the game, and the game itself doesn’t have to be all that good either (in my case, “Snooker” fits both those categories); the important thing is to understand what gives a game presence. I don’t care whether it’s high
skill, clever strategy, viscerality, physicality – if you don’t play it, you won’t appreciate it.

In my own case, I played “Association Football” (yeah, soccer) at school (attacking midfielder if you must know); I was good, but we were never taught any skills or anything and most games descended into kicking matches. I nevertheless found out what made it “the beautiful game”, though.

5) A game in which you can lose actual money.

There is a dark side to games, and gambling gives people a chance to sense it. Personally, I don’t like playing games for money at all; however, a lot of people love it. Everyone has their limits, though.

For some, gambling games are at their best when the amounts involved actually hurt if you lose them; for others, it’s the amounts that can be won that make the difference. The point of playing a gambling game from the perspective of this list is to gain an appreciation of the morality of games. When something stops being “just a game” and starts to take over the player’s life, that’s potentially a bad thing. Unless
you’ve seen it (or something close to it), you’re never going to understand that fully. Gambling games let you do that. Warning: you run a big risk with this if it turns out you’re the one who gets hooked…

For me, I used to play “Poker” with my friends over lunch when I was 17 or 18. We played for Tic-Tac mints. This was before “Texas Hold ‘Em” got big, so we’d play mainly “Draw Poker”, “5-Card Stud”, “7-Card Stud” or, occasionally, “Montana Red Dog”. We stopped playing when one of my friends, who consistently lost, had to borrow money to buy more Tic-Tacs; I decided things had gone far enough, and called
the lunchtime sessions off. From that point on, no way would I design a game that deliberately tried to addict someone to it.

6) A game released in the year you were born.

Most games are built on the foundations of games that went before them, and an appreciation of their history means you appreciate the games themselves more. Games have a very long history (indeed, they go back into prehistory), but a modern game is unlikely to quote directly from ancient archetypes. They’re more probably going to quote from games from the generation before them. You therefore need to
play a bunch of old games to see where the advances were made. Unfortunately, “old” is a relative term: what you think is old might, to me, seem fairly new. What’s old enough for both of us is something from the year we were born in (or a year close to that). Play a game from back then and see how things have (or haven’t) changed. Bonus: you’re almost guaranteed to notice the gameplay more than you do in a (what currently looks) slick, modern game.

For me, the old game would be “Diplomacy”, which was released commercially in 1959 (the year before my birth, but that’s near enough). Ah, what a game! It’s trapped in its time, because it needs 7 players and could only really be played by post. Play-by-email is even more of a niche than play-by-mail was, so it’s not a game that is played a lot nowadays. Lovely mechanics, though!

7) A really bad game.

Some games are just BAD. The mechanics are all wrong, they’re unfun, or no fun, or the rules are ambiguous, or they drag on and on, or there’s a dominant strategy, or … well, the list continues. If you play such a game, you can ascertain what it is that’s bad about it; this will enable you to avoid similar games in future and to avoid
making similar mistakes in any games you design yourself (see next point). The more you understand about games, the more you’ll be able to find the games that are right for you.

For me, tempting though it is to nominate “Trivial Pursuit” as the game that laid waste to the British board games industry, I didn’t actually play that. However, my personal pick is one that I’m sure many other people will share, too: “Monopoly”…

8) A game you wrote yourself that no-one else has played.

Game design is actually quite hard to do well. You’re not going to know quite how hard unless you try it yourself. In the attempt, you’ll come to understand more about games and what makes them tick – but only if you actually play the game (if
it needs more than one player, play it against yourself). If you actually are a game designer, this is something you will have done many, many times before, of course; just make sure you keep on doing it.

For me, well, all game designers have a corpus of games in various stages of completion that they have never shared with anyone else, simply because doing the design itself was the fun part.

I’m a bit low on computer games in this list, so I’ll go for one I did called “Mombasa” about the exploration of Africa. It’s not all that good, but the point is that I wouldn’t know that if I hadn’t played it…

9) An MMORPG.

This is because I co-wrote the first virtual world, and therefore the more people who play these, the higher my kudos rises.

I’ll list the last MMO I played through up to the level cap as my example here: “Rift”. I came away not so much impressed by the game itself but by its developer, Trion Worlds, which is more understanding of its players than any other developer I’ve
come across except perhaps CCP.

10) “Mornington Crescent”.

It’s actually called “Finchley Central”, but I’ll go with the version that’s best known. This is a very simple game, the rules of which, in their entirety, are as follows: players take it in turns to name London Underground stations, and the first to say
Mornington Crescent wins. This is a game everyone should play, because it gets to the heart of what a game is: what happens when you freely and knowingly bound your behaviour according to a set of rules in the hope of gaining some benefit that you might not get. You play it for just so long as it’s fun, with people who also play for just so long as it’s fun. It’s the Magic Circle incarnate.

So those are my top 10 games that people should play. If you already played them, my apologies for having wasted your time with this list. If you haven’t played them, I envy you the treasure trove that lies ahead.”

Google Street Maps … of a videogame (GTA IV)

This is cool – a great use of Google’s tech, a great example of what it *really* means to drag Online Games and MMO’s out of the stone-age of “do what Diablo did, but with more people on screen”.

Sadly, it doesn’t quite work – none of the stereographic projection stuff (which is key to making Google StreetView) is working here. Oh well.

And it raises the question: why didn’t R* do this themselves, and make more of the R* Club (their “social/online” part to GTA) than the silly farting-about it was at launch?

http://www.gta4.net/map/

“by running a spy network I am griefing”

If you’re an MMO designer, and you *still* don’t grok the griefer-mindset, or you somehow hope/believe that “one day, there will be no griefers”, then maybe this RPS interview with the always-fun-to-watch Goonswarm will help you:

MT: We are griefers. If nothing is going to happen then we’re going to try to find something that screams and bleeds and poke at it.

RPS: Griefing is something goons are known for doing, but now I’m talking to you it’s not something I can imagine you personally doing.

MT: Technically speaking, by running a spy network I am griefing.

RPS: But would you go out and aggravate other players for the Hell of it if you were a lower ranking member of Goonswarm?

MT: Well, most lower ranked Goons make their money by doing that. Scamming people is a very quick way of making money in Eve. Rather than making an honest buck, you take that buck from somebody else.

and, much further down, maybe this will help you see how griefers often serve just as positive and valuable a role as all your “preferred” player-types:

RPS: For my money, Eve might be the most fascinating game in existence today. But that doesn’t stop it from being interminably boring as well.

MT: Right. I mean most Eve players are stuck in high security space mining, and a lot of the core PvE in Eve has you sitting there are watching three grey bars slowly turn red.

Goonfleet is a socialist alliance. We give people ships so that rather than being forced to rat [fight low-powered AI NPCs] they can take part in PvP, we teach them how to scam so that they don’t have to mine, we teach them how to make ISK most effectively, we give them a lot of ISK and we reimburse their losses. This way they can focus on the fun aspects of the game, like griefing and warfare, so they’re not forced to endure derp-derp-ing around high sec.

If they play your game, you should be glad; if they grief, you should be asking yourself why – and if you’re a commercial operation, you should probably be asking:

“are they fixing a problem for us?

can we afford to leave them to it, part of our unpaid workforce?

and:

is it worth our time trying to fix the problem itself, or should we accept their help and move on down our never-ending list of pending fixes?”

The 10 Games You Should Have Played

This list is WRONG (and it’s on the Internet)

…and here’s your chance to challenge it.

This was written in a frantic half-hour with 30-odd people with many different ideas and suggestions. My role was to shepherd the opinions towards a concrete list of 10. There *was* a specific agenda/aim I had in mind – but I didn’t tell people that up-front, I wanted to let them go in whatever direction they wanted.

Now it’s done, I’m reaching out to everyone who cares about this stuff, and saying:

Come up with your own rules for a top-10, define it clearly, and share your list.

Blog it, link it back here, and we’ll see what people come up with. I’m expecting a lot of variation on the inclusion-criteria for a top-10, and (hopefully) as much variation on the games people choose / reject.

Other people’s top-10′s

The original top-10

May 2011 – GameCamp 4

A few weeks ago, London was host to the fourth GameCamp – a 1-day unConference devoted to games, game-design, and game-playing.

I wanted to give a talk, because that’s half the fun of an UnConference. I wanted to do something fun, interesting, and above-all *new*. What’s the point of giving a talk you could have given at a “normal” conference?

My Plan

I vaguely remembered that Darius had once run a session on “Indie games that haven’t had the attention they deserve” (or something like that), where he’d cherry-picked some great fun games that were relatively unknown in mainstream circles, and gave them a free boost of attention.

I didn’t feel confident to do that myself,but I knew there were plenty of people at GC4 who were much deeper into the fringe of games and game-design, and no doubt *they* knew what was out there, and had played it all.

So, one quick scribble later:

“10 Games you Should have played (but probably haven’t)”

Reality

I was afraid I’d get an audience turn up and expect me to do all the work, where I needed them brainstorming and providing the ideas themselves. I could see it easily being shaped by the (lack of) variety of the first few suggestions, so I set out to come up with a wide range to kick off.

With a full TEN MINUTES before the start, I roamed the hallways, looking for victims. I spotted a few familiar faces, game designers and writers I could corral, and asked them for a quick 3 “games people should have played”.

First response I got, courtesy of Adrian Hon: “Paintball”. Ah. Thanks, Adrian. You just exposed the flaw in my title. I never mentioned the words “video” or “computer”, although I’d assumed them.

Other interesting titles I was given in the hallway included: Civilization (the computer game, via Adrian), Journey to the End of the Night (via Holly Gramazio, I think), Tetris Attack (ditto)…some good variety to kick us off.

Those 10 games in full

We had a packed room, approx 20-30 people. I won’t detail the process, but in our 30 minute slot we managed a long list, with some brief explanation of the more obscure games, and then we voted on which ones should go to top-10. Fortunately, there were 10-12 games that were CLEARLY a lot more popular than the rest.

Here’s the full list (illegible with crossings-out)

And here’s the top-10, with their respective (approximate – I was counting fast!) votes:

  1. Tetris [*]
  2. Portal [*]
  3. SimCity [*]
  4. The Secret of Monkey Island (either/both) [11]
  5. Hitch-Hiker’s Guide to the Galaxy (text adventure) [10]
  6. Mario Kart [10]
  7. Zelda (any/all) [10]
  8. Deus Ex [9]
  9. Day of the Tentacle [9]
  10. Populous [9]

[*] = so many I didn’t bother counting; more than 2/3 of the audience.

“Do I look fat in this?” … “You do now!” (Kinect FAIL)

Here’s an excellent idea: use Kinect to display clothes on people in real-time, inside a fashion retail shop:

http://ar-door.com/2011/05/virtualnaya-primerochnaya-dlya-topshop/?lang=en (Scrub to 0:25 – first 30 seconds is moronic marketing-person bumf)

This has huge potential:

  1. Much much faster than browsing – potential for more positive purchase decisions in less time
  2. Less space lost to changing rooms – fewer rooms needed for same number of customers (space is often at a premium in retail outlets)
  3. Show an enormous range of stock while keeping very little on-site
  4. Show every size, rather than just the sizes that are in stock on-site

But hey – wait a minute – look closely at the person who’s posing in each case. Why does the on-screen person look like they weigh twice as much as the person who’s in front of the camera?

Ah. I see. It’s that recurring problem again: marketing companies that don’t know where to hire skilled tech staff. Here we’ve got 3D model wrapping apparently done by someone who’s never heard of Convex Hull. This is basic Computer Science (IIRC it’s taught in almost every CS undergrad course today) – wrapping string (or cloth) tightly around a solid object is an interesting and very common problem.

OK, it’s version one; “we’ll fix that in beta”; etc. Except … you’re demoing this to:

  1. women
  2. in a fashion store
  3. in public
  4. when they’re about to pay money
  5. for clothes

…and you’re making them look:

  1. uniform weight (which for short, young Muscovites is – according to the video – usually “much larger than reality”)
  2. saggy (look at the video – they failed to register / stretch the clothing for the head/neck-to-knees length; in most cases, the women’s busts are aroudn their waists, and their waists are around their knees)
  3. masculine (most women’s clothing hangs; it’s soft, flexible; here, the Kinect models have no physics, not even primitive struct-based bending, let alone springs. Doh)

All of which put together makes this a FAIL. Technologically it’s all fixable, but from a sales/marketing perspective it’s enough to send many people screaming. Fingers crossed that the company (ARDoor) manages to make huge sales anyway – the potential here is enormous, and some of what they’ve done looks great (I like the simple interface, and the giant “Smile!” instruction).

Love failure: make better games, faster

In my experience, most people can grasp one, but not both, these concepts when prototyping a game:

“If you fail, there will be dozens more”
“failure is ok! That’s what prototyping is for, so go crazy!”

Too often, I meet people who go crazy – but only once. It ends horribly, and they give up in shame.

Just as often, I meet people who make lots of stuff, quickly – but it’s all generic derivative crap; they never took creative risks.

The linked article above is a must-read for any serious designer: it’s a post-mortem from the Experimental Gameplay Project guys (“design + implement a new game every week for a whole semester” – if you haven’t played the games, or read about the concept, I can’t recommend it enough). I *frequently* tell wannabe-game-designers to go do exactly the same themselves – there’s no better way to learn the art and craft of game design.

Other choice quotes from the article include:

… how bad can it be?

“Although they were utter failures, the whole team was thrilled to take such a bold risk to prove the failure of audio-only gameplay, and I could point with pride to my hideous creations.”

… for all those misguided individuals who still think designers shouldn’t learn to code:

“Each member of the team had to be comfortable with all aspects of game development. Everyone was responsible for their own programming, art, sound, and everything else that went into the final product.”

(as Designers, you should aspire to be the games-equivalent of a Product Manager: making the final, shipped product come together as an awesome whole, rather than locking yourself in a cupboard doing your little niche thing, and ignoring the end-product)

…an observation I made a few years ago, and lead me to plan a 4-day week for our studio:

“after much investigation, it appears that you just cannot schedule creativity.”

…Scrum: start with a vertical slice of cake, and add slices, not layers:

“we found that gathering art and music with some personal significance was particularly fruitful”

(if you want further correlation of this, IIRC Jonathon Mak made the same point a few years back at GDC: Everyday Shooter sucked and was dull when he prototyped “game mechanics without animations”, and lead him down the wrong paths of improvement; you cannot take the style out of gameplay, it’s too tightly interwoven)

…how to: Simulate a prototype … in your head:

“It’s really easy! All you have to do is imagine your game audience saying, “Wow!” And then just work backward and fill in the blanks. What’s making them enjoy your game? What emotion are they feeling? What is happening in the game to make them feel that way? ”

Go read the article…

If you’re not convinced already, here’s their Handy Cut-Out List! (which won’t help much till you read it, as each line is one of the sub-headings:

Setup: Rapid is a State of Mind

* Embrace the Possibility of Failure – it Encourages Creative Risk Taking
* Enforce Short Development Cycles (More Time != More Quality)
* Constrain Creativity to Make You Want it Even More
* Gather a Kickass Team and an Objective Advisor – Mindset is as Important as Talent
* Develop in Parallel for Maximum Splatter

Design: Creativity and the Myth of Brainstorming

* Formal Brainstorming Has a 0% Success Rate
* Gather Concept Art and Music to Create an Emotional Target
* Simulate in Your Head – Pre-Prototype the Prototype

Development: Nobody Knows How You Made it, and Nobody Cares

* Build the Toy First
* If You Can Get Away With it, Fake it
* Cut Your Losses and “Learn When to Shoot Your Baby in the Crib”
* Heavy Theming Will Not Salvage Bad Design (or “You Can’t Polish a Turd”)
* But Overall Aesthetic Matters! Apply a Healthy Spread of Art, Sound, and Music
* Nobody Cares About Your Great Engineering

General Gameplay: Sensual Lessons in Juicy Fun

* Complexity is Not Necessary for Fun
* Create a Sense of Ownership to Keep ‘em Crawling Back for More
* “Experimental” Does Not Mean “Complex”
* Build Toward a Well Defined Goal
* Make it Juicy!