Raph's Website » 40 ways to be a better (game) designer

40 ways to be a better (game) designer

June 26th, 2006 (Visited 84682 times) Tags: game design, game grammar

I’m always looking for ways to become a better game designer. I frequently think I am no good at it, after all. (Just ask in random forums such as Blue’s News or the Fires of Heaven guild forums). So it’s with interest that I read articles like 50 ways to become a better designer.

Much of the list isn’t directly applicable, but some of it is, and it inspires a list of my own, centered around games. Not exhaustive, and probably not even accurate, but stuff I have often helped myself with. Many are cribbed and adapted.

Blue squares
Prototype with abstracted graphics or stolen graphics. Or pen and paper, cards, and dice. Art enhances, multiplies, improves. It does not replace missing fun. If you can get to something fun with minimal presentation, it will get more fun with good presentation.
Metaphors
Deciding what your game is “about” can help you cut out the extraneous stuff. Think about simpler games, board games, if it helps you cut to the quick. “A bidding game.” “A territory game.” “A timing game.”
Compartmentalize
If you’re working on a big game, perceiving your big game as actually being a collection of smaller games that share a setting can help a lot. Excessive interdependence between systems makes a game really hard to balance anyway.
Summarize
You should be able to pull out key verbs and phrases from your game design concept, and boil down the idea. If you can’t do this, somewhere you’ve gone awry.
Brand
The best game is going to have a marriage of theme, mechanic, and presentation. This is what makes a brand strong. Don’t look down on the exercise of branding.
Long meetings suck
Particularly creative meetings, where you want people to leave energized, not tired and cynical. Long meetings trend to groupthink and overcomplication. Keep design meetings tight and relatively brief.
Use a sketchbook
Sketches are an extremely powerful tool for game design. So much information about game state is conveyed via the screen or board that doing quick sketches of user experience early is critical. Draw a quick pic of what the player will see and do. Doodle logos in the margins.
Don’t design in the code/with the pieces
Design on a bike, riding down the street. Or in the shower. Or on a canoe. Design somewhere else. Worry less about what you might lose because you cannot write it down, than about keeping the core essence of what excited you. A change of scenery drives creativity.
Talk and listen
Fresh ideas colliding, or even old ideas colliding in unpredictable ways, is where creativity comes from. You get these new things to rub together by listening. You trade by giving ideas of your own. Ideas are cheap, don’t hoard them.
Every snowflake is different
If you assign twelve people to create “a space-based game about intergalactic trading” you will get twelve different games — it doesn’t matter how specific the idea is.
Assets
Think about assets early; doing the exercise of calculating how many sounds, graphics, and so on you’ll need for each given game or system is often eye-opening.
Steal and borrow
Mechanics are not sacred. They are tools towards an eventual game. If open draw card piles is a useful mechanic, use it even though you have seen it in other games. Nobody but you cares if you are sick of the health bar.
Playtest early and often
If your first control mechanic is briefly entertaining even before you have a game, great. If not, worry. If it’s entertaining to lay out the pieces on the board even before the rules are settled, cool. If not, worry.
Different players play differently
Don’t playtest with only the same old group of people. Mix it up.
Shut up
Don’t say anything when watching someone else play. Just watch and note down all the stupid things they are doing because you were stupid and didn’t make the right thing to do really obvious.
Play
You don’t have to finish the games people are talking about. But you do need to try them. Ten minutes is often enough, but through the first boss is better.
KISS
If you have a lot of systems, make each one simple with simple data. If you have one simple system, spend on the data.
Algorithms, not static data
The best games have an algorithmic style of variation, where gameplay emerges out of the possible permutations; this is as opposed to games which rely on a supply of static puzzles you supply. Shoot for the former — you may not make it (which is fine) but you’ll probably be forced to be cleverer.
Save everything
The sketches, the early draft docs, the old prototypes, the boardgame version, the alternate ruleset. You never know when you will need it.
Don’t marry any art
Once the game is fun, try out an art style on it. Then try another. And another.
Don’t use lossy data
Photoshop layers are your friend. High res is your friend. The link to the website with the free textures. The screencap you cut up. Save the originals!
Have an editor
Someone who can tell you when you are full of crap even though they are a fan.
Comment
Six months later, you won’t remember why the magic number is 37.5. Put a comment in the code and explain the logic in a design doc.
Giant design docs are useless
They are usually overelaborated piles of daydreams that nobody will actually implement. A bulleted list of specifics is far more fruitful.
Back to the beginning
Every milestone you hit, go back and compare against your original vision, your original theme, and your original goals. It’s OK to say you want to change them because you really do want to change them; it’s not OK to say you want to change them because you drifted off without realizing it.
Know when to stop
It’s easy to spoil something by adding too much. One more mechanic, one more axis of variables, even an extra row on the game board, and it might all break apart.
Eat your own dog food
Play your own game. If you find yourself playing it for enjoyment, you are onto something.
Learn abstraction
Learn to see the underlying mathematics of your design, rather than the dressing. See the projection of force, the spheres of influence, the hidden slot machine and the number of keystrokes per second. You will understand the actual play much more deeply.
Learn art. And coding. And marketing.
The more you understand what other disciplines bring to the table, the better you will design. You don’t need to master these — just acquire some degree of basic competence.
Don’t argue with players
They are always right about their experience. Telling them that it isn’t actually that way is a waste of time. The question is why they think it is that way.
Be frivolous
Frivolous bits that are there just because they are cool are often what puts a game over the top, making the player feel the enjoymentand passion that went into something.
Tell a story
A prospective player or a prospective funder — either way, you need to sell them on the game, and the way to do that is with a story.
Limitations are good
A lot of creativity comes from working within limits. If you’re stumped, try giving yourself some more limits and see what pops out.
Let go
Once it’s out there, it’s not yours. Abandon all notions about how it “should” be played.
Do the work
A lot more people talk about making games than actually make games. Anyone can make a game with some cut up paper and a few crayons. Whatever excuses you are making for yourself are bad ones. You just put one foot in front of the other until you cross the finish line. And once you make one, make another. And another. Keep doing it.
Don’t settle
It’s all too easy to be tired and frustrated and accede to something dumb and lower your standards. The impact can be truly massive on the final product. It’s one thing to compromise: compromise is inevitable and will often improve the product. Settling, however, is frequently fatal.
See out of player eyes
When you work on a system, picture the movements the player makes. Envision the path they take. Practice the sequence of actions to reach a goal. Visualize the route they take to reach that goal. See from the player’s point of view, not from the point of view of “it should take 30 kills to reach the next level.” You design for them, not you.
Reward
When a player does something right, give them a reward cue. A splash of light, a cheerful sound, a bit of feedback that sticks out.
Use the list
Check against the list of key pieces required for fun: preparation for a challenge mattering, territory/environment mattering, choices in how to solve a problem, variations in the nature of the challenge, risk to loss, skill in execution, no bottom-feeding, and multiple possible success states. You may have your own list, but this is the one that has worked for me.
Eliminate marking time
Anything you do in the game “because you have to do it” should be cut or at the very least get a seriously hard look. Tedium is the enemy of fun.

Do I always follow these? No, but I usually regret it afterwards. There are probably some that you do instinctively and never have a problem with. There are some you probably have a weakness for.

[?]
Type in a relevant tag, and click the button, and help organize this blog's information.
[More Help]

You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.

No More Hero wrote on November 30th, 1999 at 12:00 am:

成为更优秀的游戏设计师的40种方法（上）前言由于篇幅甚大，因此译者分为两部分，不便之处还请读者见谅。本文源自Raph Koster的一篇文章，出处在于http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552

Faith wrote on June 26th, 2006 at 3:55 pm:

[...] Comments [...]

MMORPG - Raph Kosters Wege zum besseren Game Designer wrote on June 26th, 2006 at 4:04 pm:

[...] Blue squares Prototype with abstracted graphics or stolen graphics. Or pen and paper, cards, and dice. Art enhances, multiplies, improves. It does not replace missing fun. If you can get to something fun with minimal presentation, it will get more fun with good presentation. Metaphors Deciding what your game is �about� can help you cut out the extraneous stuff. Think about simpler games, board games, if it helps you cut to the quick. �A bidding game.� �A territory game.� �A timing game.� Compartmentalize If you�re working on a big game, perceiving your big game as actually being a collection of smaller games that share a setting can help a lot. Excessive interdependence between systems makes a game really hard to balance anyway. Link: 40 ways to be a better (game) designer 150)?150:this.scrollHeight)”> __________________ The tools suck! — Raph Koster [...]

blog: 40 ways to be a better (game) designer wrote on June 26th, 2006 at 5:38 pm:

[...] the always good raph koster game design blog.he also mentions http://www.computerarts.co.uk/in_depth/features/50_ways_to_become_a_better_designerQuoteI�m always looking for ways to become a better game designer. I frequently think I am no good at it, after all. (Just ask in random forums such as Blue�s News or the Fires of Heaven guild forums). So it�s with interest that I read articles like 50 ways to become a better designer.Much of the list isn�t directly applicable, but some of it is, and it inspires a list of my own, centered around games. Not exhaustive, and probably not even accurate, but stuff I have often helped myself with. Many are cribbed and adapted.http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552 [...]

Tales of the Rampant Coyote: Ways To Be A Better Game Designer wrote on June 26th, 2006 at 6:50 pm:

[...] was usually the case.Budding indie game developers, take note! - posted by The Rampant Coyote @ 5:28 PM (Permalink) Comments: Post a Comment Links to this post: See links to this post posted by @ if (typeof BL_addOnLoadEvent == ‘function’) { BL_addOnLoadEvent(function() { BL_writeBacklinks(); }); } [...]

Designostic: Como ser mejor diseñador wrote on June 27th, 2006 at 9:16 am:

[...] Jare me ha mandado este link sobre 40 formas de ser mejor diseñador de juegos (en ingles), en el blog de Raph Koster.Es una lista interesante, que incluye aspectos como abstracción, playtesting, reuniones, documentos de diseño y robar (buenas) ideas, entre otros. [...]

Ranger - A Lifestyle, Not A Profession wrote on June 27th, 2006 at 10:22 am:

a list of ways to be a better game designer.

JoDiamonds - 40 ways to be a better (game) designer wrote on June 27th, 2006 at 10:29 am:

[...] [Tags|design, game, learning, raph koster]Raph Koster wrote up 40 ways to be a better (game) designer.I don’t disagree with a single one, and as a small list of “best practices” it’s pretty good. Some of it’s a bit fluffy, and almost all of it a bit haphazardly ordered, but pretty much all correct. It’s exactly the kind of thing you should look at during all stages of a project as a way to step back and make sure you are doing the things that need doing.It’s not an amazing comprehensive checksheet. Rather, it’s just another thing you should be checking against (of which you should eventually compile your own enormous list, but it gets more specific to what you are doing). linkReply [...]

IGDA SAN DIEGO » 40 Ways To Better Game Design wrote on June 27th, 2006 at 11:03 am:

[...] Local game designer Raph Koster, former Chief Creative Officer of Sony Online Entertainment, recently published a list of 40 Ways To Be A Better Game Designer. Check ‘em out! Feel free to add your own. [...]

Consejos para dise�ar un buen videojuego :: CodePixel :: tu dosis de programaci�n gr�fica y animaci�n 3D wrote on June 27th, 2006 at 2:22 pm:

[...] En esta web podemos leer 40 consejos muy utiles para desarrollar la idea de un videojuego y ser capaz de llevarla a cabo (la parte mas dificil de todo esto). En general se pueden aplicar a todo tipo de lo projectos, y mas si trabajas en una empresa de graficos por ordenador. [...]

And Maw! This wrote on June 27th, 2006 at 2:33 pm:

Raph Kosters Top 40

Raph Koster put up a list of 40 ways to be a better game designer. We try to follow most of them when designing a game, but some things we come up a little short on.
Most importantly…
5. Brand - Boxen is too generic, and doesn’t reall…

Learning Games wrote on June 27th, 2006 at 2:40 pm:

Raph Koster (author of A Theory of Fun) made a blog entry that describes 40 ways to be a better (game) designer. It’s a good read.

한RSS wrote on June 27th, 2006 at 7:09 pm:

[...] Lovely. BOARD GAME To bait the intelligence of our youth: if nothing else, it will make them happy. They have disgraced me, and hindered me many millions; laughed at my losses, mocked at my gains, scorned my mechanics, assigned me to bargain bins, wrecked my reputation with licensed copies of poor games; and what’s the reason? I am non-electric. Hath not a board game fun? hath not a board game rules, players, winners, tension, strategy, passions? played with the same breath, poor by the same faults, subject to the same arguments, won by the same fortitude, dragged and rushed by the same gamer types, as a video game is? If you ruin us, do we not break? if you play fancifully with us, do we not make you laugh? If you play vengefully with us, do we not make other players Uncomfortable? and if you steal our market share, shall we not market back? If we are like you in the rest, we will resemble you in that. If a board game is promoted over a video game, what is his humility? A press release. If a video game splash the front page, what should the board game’s sufferance be by video game’s example? Why, blogging! The marketing you teach me, I will execute, and it shall go hard but I will better the instruction. 40 ways to be a better (game) designer Raph 2006-06-27 06:06 작성 | Games [...]

Dimensión 2.5 » Blog Archive » 40 claves para hacer un buen videojuego wrote on June 28th, 2006 at 1:53 am:

[...] Hacer un buen videojuego no es tarea fácil, por lo que todo consejo es bienvenido. Pues aquí tienes nada menos que 40 consejos para el desarrollo y planificación de un buen videojuego. [...]

大风起兮云肥羊 wrote on June 28th, 2006 at 2:20 am:

http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552

Raph Koster��Ϊһ��õĲ߻��40��취 - GameRes��Ϸ��̳ wrote on June 28th, 2006 at 6:40 pm:

[...] ��: 2006-6-28 18:16:00�� | �� | �� | ��״ | �ղ� | �༭ | ɾ�� | �� Raph Koster��Ϊһ��õĲ߻��40��취 ��ַ��http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-55240 ways to be a better (game) designer [...]

Trackback - Eye On Gambling Forums wrote on June 29th, 2006 at 5:59 pm:

[...] They’re designed for blogs, linking to each other.. Raph’s Website � 40 ways to be a better (game) designer Terra Nova: Fifteen new papers on virtual worlds TrackBack - Wikipedia, the free encyclopedia [...]

Raph’s Website » From the mailbox: 40 ways desktop image wrote on June 30th, 2006 at 6:23 am:

[...] Sulka Haro says, Hi! I wanted to have your 40 ways accessible somewhere but wanted something that looked nicer than a print of the site so I made it a background on my desktop. I uploaded it to http://www.kotska.com/sulka/kuvat/gamedesign.jpg in case you want to see it. The damselfly in the picture in Scarce Blue-tailed Damselfly (Ischnura Elegans). [...]

small talk wrote on July 2nd, 2006 at 6:30 am:

[...] http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ [...]

Game Design Training and Education. 01play.net wrote on July 9th, 2006 at 1:51 am:

[...] Raph’s Website » 40 ways to be a better (game) designer [...]

Nephilim wrote on July 9th, 2006 at 11:05 pm:

. It’s a good read.Link - posted by CC at 8:40 AM Permalink - Backlinks - photos - 0 comments

GameDevMike - News, opinions, articles, tips & tricks on game development with an Indie twist. wrote on July 10th, 2006 at 1:19 am:

any feature your heart desires without being subjected to approval by a higher authority (like a project manager), the temptation to throw in every cool thing you think of is high. You have to draw the line somewhere. In Raph Koster’s blog entry, 40 ways to be a better (game) designer (which

Words » Blog Archive » links for 2006-07-12 wrote on July 12th, 2006 at 1:17 am:

[...] Raph’s Website » 40 ways to be a better (game) designer (tags: games design raphkoster gamedesign gamedev development) [...]

The PANTS Daily Chump, last cranked at 2006-07-11 20:56 wrote on July 13th, 2006 at 6:21 am:

[...] The PANTS Daily Chump, last cranked at 2006-07-11 20:56You get what you pay for from gilesWednesday links and observations from gilesMy special son from gilesPainty toes from gilesmore blogs more photossearchrecent chumps2006/07/122006/07/112006/07/102006/07/09older chumps2006/072006/062006/052006/042006/032006/022006/012005/122005/112005/102005/092005/082005/072005/062005/052005/042005/032005/022005/012004/122004/112004/102004/092004/082004/072004/062004/052004/042004/032004/022004/012003/122003/112003/102003/092003/082003/072003/062003/052003/042003/032003/022003/012002/122002/112002/102002/092002/082002/072002/062002/052002/042002/032002/022002/012001/122001/112001/102001/092001/082001/072001/062001/052001/042001/032001/022001/012000/12 last updated at 2006-07-11 20:56 mattb fondly recalls gobsausage week International Envelope Sizes: A Selective Annotated Guide posted by edd at 2006-07-11 20:56 (+) edd: A wonderful page which, coincidentally, taught me what DIN stands foredd: Also marvel at how random the US is compared to the rest of the world.gavin: But our names are awesome, “Baronial”, “Banker’s Flap”, etc.gavin: Sadly they seem to have misspelled “Catalogue.” Should be “Catalog.”gavin: Oooh, another quaint favorite: String-and-Button! Second Life travel agents posted by mattb at 2006-07-11 19:56 (+) mattb: paying US$10 per usable blog post for people to create pictures, writeups and machinima of interesting in-world stuff 40 ways to be a better (game) designer posted by mattb at 2006-07-11 17:04 (+) games design interactive mattb: via yoz, who rightly says, “good tips that apply to code and creative projects in general, not just games” Quite a nice interface to the xen-user archives posted by edd at 2006-07-11 10:50 (+) Copyright © The PANTS Collective. Created by the Chump Bot. A Useful Production. Contact us. Grab our RSS. [...]

Infovore : a weblog by Tom Armitage wrote on July 13th, 2006 at 11:27 am:

Going beyond just pluralize. Cute. Tagged as: gem language linguistics ruby Interactive Fiction: First-Timer Foibles — A nice look at some common stumbling blocks in IF Tagged as: design fiction game if interactive writingRaph’s Website » 40 ways to be a better (game) designer — Matt B is right; it’s not just about game design, it’s about any system - code, rules, perhaps even mechanical. Really, really cracking. Tagged as: design development games play

Hot Links - Archives wrote on July 13th, 2006 at 11:37 pm:

[...] of Ruby on Rails tips in one place! - tips, tricks, and code snippets for Ruby on Rails developers # copy [...]

Links for Wed 12 July 2006 [paulhammond.org] wrote on July 17th, 2006 at 1:44 pm:

MMORPG.COM - MMORPG Gaming Forums - Everquest, Final Fantasy XI, World of Warcraft & More! wrote on August 5th, 2006 at 9:23 am:

[...] Also, see “40 ways to be a better game designer”: http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ [...]

shiner.clay | blog wrote on August 7th, 2006 at 3:28 pm:

Ulterior Motive make superb Swedish ties and cufflinks Say hello to Hubpages - “Share what you know - Rake in the dough” 40 ways to be a better game designer Bluetooth and SMS take dating in Saudi Arabia to new levels Liveplasma is another music/movie/Pandora meets Google search engine Oregon Scientific now has pretty cool clock/weather stations from the likes of Phillipe Starck and Stefano Giovannoni

disobey.com | content for the discontented wrote on August 8th, 2006 at 5:21 am:

[...] 40 ways to be a better (game) designer: “I’m always looking for ways to become a better game designer … it’s with interest that I read articles like 50 ways to become a better designer. Much of the list isn’t directly applicable, but some of it is, and it inspires a list of my own, centered around games. Not exhaustive, and probably not even accurate, but stuff I have often helped myself with. Many are cribbed and adapted.” [...]

Traumwind - Traumwind RSS reader wrote on August 9th, 2006 at 3:21 pm:

��Ϊһ��õĲ߻��40��취 wrote on September 13th, 2006 at 8:05 am:

[...] ��Է��һ�£��©��ĵط��ָ�� 1��ɫ�� Ŵֲڻ��棬��Ļ��Ϸԭ�ͣ��ʹ��ֽ��ʡ�ֽ�ƺ��ӡ��ֶο��Լ�ǿ��ߣ��ǲ��Ϸ��ȱ��Ȥ��ٵı��ֶξ��Ȥ�Ķ��ô��ӵ�и�õı��ֶ�ʱ��Ȥ�� 2��Ϸ�ǡ��ڡ�ʲô�Ŀ��԰��ó��޹�ϵ��ݡ��Ϸ��ټ�һЩ��Ϸ��ܰ��Ѹ��Ϸ�ı��ʡ��һ��ʽ��Ϸ��һ��̵��Ϸ��һ��վ�ȷʱ��Ϸ�� 3��һ��Ϸ��ʶ��Ĵ��Ϸʵ��ͬһ��µ�һ��С��Ϸ��ϣ��ܻ��ܶࡣ��ϵͳ֮��ڶ��ݽ��ʹһ��Ϸ��ƽ�⡣ 4��ܽ��Ӧ��ܹ��Ϸ��г��һЩ�ؼ�Ķ��ʺ;��ӣ��Դ��Ĵ��⡣��ĳ��ط�һ��˴� 5��õ��ϷӦ��⡢ϵͳ�ͱ��ַ�ʽ��ϡ��ʹ��Ϸ��߷�񡣲�ҪС��񻯵�� 6��߳��Ļ��Ǵ��ۻᣬ��ϣ��ɢ��ʱ��־��Ǿ�ƣ��ߺͷ��ס��߳��Ļ��齫��¼��忼�Ǻ͹��ڸ��ӻ��ִ��ۻ�Ľ�պͼ�̡� 7��ʹ�ò�ͼ��ͼ��Ϸ��Ƶ�һ��ǳ�ǿ��Ĺ��ߡ�ͨ��Ļ��߻��Դ��˶��Ϣ��ڰ��ҵ��Ϸ��黭��Ǽ��õġ��һ��ҽ��Ҫ��Ĳ�ͼ��Ҫ�ı��˵�� 8��Ҫ�ڴ��/ֽ��ϲ߻��г��ϲ [...]

IGDA Forums - 40 Ways to Be A Better Game Designer wrote on September 19th, 2006 at 5:23 pm:

[...] Raph Koster compiled a list of 40 Ways to Be A Better Game Designer. Check ‘em out! [...]

VIRALGAMES.ORG ::Un blog particular sobre videojuegos:: wrote on September 25th, 2006 at 10:14 pm:

[...] [...]

Kloonigames - Monthly experimental games wrote on October 18th, 2006 at 8:54 pm:

ll have to create the early prototypes with the ugliest graphics ever. Not wasting my devtime in the beginning creating the graphics, but I’ll spend it making the blue square prototype fun to play. As Raph Koster said in his great blog post 40 ways to be a better (game) designer: Art enhances, multiplies, improves. It does not replace missing fun. If you can get to something fun with minimal presentation, it will get more fun with good presentation. 2. Player Has Too Little Control

StumbleUpon wrote on October 22nd, 2006 at 4:15 pm:

[...] Your page is now on StumbleUpon! For each appearance in your referral logs, one of our members has ’stumbled upon’ your site after clicking “Stumble!” on our toolbar to discover a new great site. Enter Your URL → [...]

CodePixel :: tu dosis de programaci�n gr�fica y animaci�n 3D - Consejos para dise�ar un buen videojuego wrote on December 7th, 2006 at 1:27 am:

Graphic or Coding? which one comes 1st? (For Indie Lone Ranger) - Indiegamer Developer Discussion Boards wrote on December 10th, 2006 at 8:02 am:

[...] I usually start with a very hazy little sketch and after that I code the deliberately ugly prototype. And only after the ugly prototype is fun enough to play I start working on the graphics. And I actually have good reason for working on the code first. Raph Koster pointed it out in his blog post 40 ways to be a better (game) designer. Quote: [...]

Raph’s Website » Some year-end site stats wrote on January 1st, 2007 at 9:03 pm:

[...] 40 ways to be a better game designer [...]

devbump wrote on January 2nd, 2007 at 11:44 am:

[...] Raph Koster’s 40 ways to be a better (game) designer http://www.raphkoster.com posted by marshmonkey 53 minutes ago view profile Game designer Raph Koster has a list of 40 things to keep in mind while designing a game up on his blog. A good list of reminders to muse over once or twice (or regularly). discuss | trackback | tags: raph koster all [...]

devbump wrote on January 2nd, 2007 at 3:00 pm:

[...] Raph Koster’s 40 ways to be a better (game) designer http://www.raphkoster.com posted by marshmonkey 4 hours ago view profile Game designer Raph Koster has a list of 40 things to keep in mind while designing a game up on his blog. A good list of reminders to muse over once or twice (or regularly). discuss | trackback | tags: raph koster all [...]

40 ways to be a better (game) designer - GameDevID.org wrote on January 2nd, 2007 at 6:36 pm:

[...] 40 ways to be a better (game) designer Nice article.. rather long, but it’s worth the read. Read it here. [...]

Deep Machines wrote on January 3rd, 2007 at 6:43 am:

40 ways to be a better (game) designer (Via Wonderland.)

Multiverse Network :: View topic - Good read: "40 ways to be a great (game) designer&quot wrote on January 4th, 2007 at 10:49 am:

[...] Another great little read from Raph Koster titled 40 ways to be a better (game) designer. Great stuff in there._________________Mars Colonization Authority - Sic Erat In Fatis [...]

40 ways to be a better (game) designer - DevMaster.net Forums wrote on January 5th, 2007 at 3:44 am:

[...] 40 ways to be a better (game) designer http://www.raphkoster.com/2006/06/26…game-designer/ I think the first three are vital as so often overlooked by bad designers! [...]

Plaidbuttonup.com » 40 tips to be a better game designer wrote on January 7th, 2007 at 4:04 am:

[...] raphkoster.com post a huge list of 40 things he fells game designers should know and do. Some of my favorite include. [...]

40 ways to be a better game designer wrote on January 8th, 2007 at 4:28 am:

[...] Saw this, it's somebody's blog thing. He's an actual game designer,btw.http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ [...]

muodostelma wrote on January 8th, 2007 at 9:19 am:

Conference on Information Visualization which has a symposium on various uses of computer games swfmill swf2xml and xml2swf wfmill is an xml2swf and swf2xml processor with import functionalities. 40 ways to be a better (game) designer List of 40 things to do to make your game designs better by Raph Koster. Brajeshwar | ActionScript 2.0 Language Reference

Anti Patterns wrote on January 8th, 2007 at 11:17 am:

limits. If you’re stumped, try giving yourself some more limits and see what pops out. Reward When a player does something right, give them a reward cue. A splash of light, a cheerful sound, a bit of feedback that sticks out. … [ Raph Koster ] Allez lire les autres, c’est vraiment pas du temps perdu !

Mildly Diverting wrote on January 9th, 2007 at 7:08 pm:

| Writing and Humanistic Studies | 21W.765J Theory and Practice of Non-linear and Interactive Narrative, Spring 2003 | Home Computer Arts - 50 ways to become a better designer Creating Passionate Users: The “Dumbness of Crowds” Raph’s Website » 40 ways to be a better (game) designer The future of television and the media triathlon. Many-to-Many:

Gameto, un espacio sobre la creación de videojuegos wrote on January 19th, 2007 at 10:47 am:

[...] Cuando se empieza a desarrollar un concepto nuevo, los mejores diseñadores recomiendan no perderse en el universo de la abstracción y los documentos, y tratar de probar la idea lo antes posible. Hay diversas formas de hacer esto. Una posibilidad, más frecuente de lo que parece, es desarrollar el juego, hasta que esté casi completo, para entonces evaluar si la jugabilidad es la esperada y el juego viene cargado de horas de diversión sin límites, o no. Si es que no, pues toca cambiar aquello que no funciona, si es que da tiempo y hay recursos. Si tampoco, pues entonces queda para la continuación.Otra posibilidad, que parece se va poniendo de moda poco a poco, es desarrollar sencillos prototipos, que contienen la esencia de la jugabilidad, y sirven para evaluar si la idea funciona o no antes de lanzarse a producir el juego. Parece razonable y, desde luego, mucho menos arriesgado que la otra opción. ¿Por qué no está todo el mundo haciendo esto? La culpa la tienen los árboles y el bosque.Tienes una idea. Es brillante, nunca vista. Vas a utilizar puertas tridimensionales y juegos con la gravedad para crear puzzles únicos. O vas a diseñar un juego en que el objetivo es ir agolpando objetos en una bola que va creciendo y creciendo. Antes de empezar a modelar personajes de 50.000 polígonos, quieres probar la idea. Algunos diseñadores defienden montar un prototipo con “cuadrados azules”, o sea, sin gráficos o con gráficos de mentira (o peor, de programador). La justificación es que todo el apartado gráfico y sonoro aporta al producto final y es imprescindible para el consumidor, pero no modifica la esencia de la jugabilidad, con lo cual ésta se puede evaluar si pagar el alto precio de crear contenido para las consolas de hoy. Todo esto parece demasiado evidente, así que vamos a hacer por un momento de abogado del diablo.Tomemos como ejemplo un juego moderno, como la franquicia de Medal of Honor o Call of Duty. La esencia de estos juegos es bien conocida: disparos en primera persona durante la segunda guerra mundial. Cuando juegas, una parte de la experiencia es el “juego” en sí, el reto, apuntar a los enemigos, evitar que te acierten, buscar rutas alternativas o simplemente ser más hábil o más rápido que ellos. Pero otra parte, tanto o más importante, es la ambientación. He oído a mucha gente decir que en estos juegos, “puedes pararte a ver lo que pasa a tu alrededor, y es increíble”. Ahora imagina que estás diseñando el principio de Call of Duty, con la escena de Stalingrado, o el asalto a la playa de Omaha en Medal of Honor. Y haces un prototipo con cuadrados azules, moviendose por el mapa como si fueran soldados acompañándote. De algún modo, no parece lo mismo. Siendo menos extremos y probablemente más realistas, imagina que pruebas ese nivel, pero que el nivel incluye sólo la jugabilidad básica. O sea, no hay explosiones en el fondo, ni pasan aviones por encima tuyo, ni decenas de soldados huyen o son despedazados por todas partes. ¿Es realmente posible hacerse una idea de cómo va a resultar el producto final sólo con eso? Quizás, pero no es tan evidente como el ejemplo de la bola atrapa-objetos.Un problema similar, aunque ligeramente distinto es el los bugs. Cuando estás probando un nivel, y encuentras un bug, de repente cobra un protagonismo tremendo, casi obsesivo. Puede que sea un enemigo que, por un error en el código, anda de espaldas haciendo el Moonwalker, o tal vez al morir los enemigos no tienen animaciones y se quedan en la pose, con los brazos en cruz y la mirada perdida. Quizás llevan la ametralladora mal colocada y parece que disparan con la rodilla. En cualquier caso, una vez que ves esto, como se suele decir, la suspensión de la incredulidad desaparece. No importa que seas un diseñador, y que sepas perfectamente que eso es un juego y que el bug se resolverá (y que no es más que un bug tonto). Te distrae, y en vez de fijarte en si la fase tiene buen ritmo y ofrece desafíos o espectáculo, te dedicas a hacer una captura de la pantalla y mandarla por correo al resto del equipo con un comentario jocoso (”no sabía que habíamos fichado a Michael Jackson!”).Es normal. Los árboles no dejan ver el bosque. Esos pequeños problemas, o la falta de elementos que algunos no considerarían esenciales en la jugabilidad son como ruido, que distorsionan la experiencia, y hacen más difícil evaluarla adecuadamente. Más difícil sí, pero no imposible. Los defensores de los cuadrados azules los utilizan porque ellos sí son capaces de olvidarse de estas distracciones. Pueden filtrarlas, del mismo modo que cuando ponen anuncios en la tele o banners en una página web, y luego ni siquiera recordamos haberlos visto. No todo el mundo tiene esta capacidad. Para la mayoría, se puede ver claramente como un juego en desarrollo, un buen día, deja de ser un montón de píxeles puestos juntos y pasa a ser una experiencia divertida. Ese día probablemente se incluyó algo que decantó la balanza del lado del bosque, y de repente los árboles dejaron de ser tan importantes. Muchas veces, a esto se le llama “pulir” el juego. Añadir un montón de detalles que eliminan las asperezas que pueda haber, y hacen la experiencia más “cinematográfica”, sin cambiar su fondo. El trabajo de pulir un juego es enorme, y se podría decir que no está acotado. Se pueden seguir identificando cambios y mejoras indefinidamente. Y el nivel de pulido que tiene un juego al ser lanzado a la calle se suele corresponder con el prestigio y la capacidad de producción del desarrollador, y muchas veces también con el éxito del juego en reviews y en ventas.La importancia de pulir un juego y la dificultad de ver la esencia del juego entre bugs y elementos no acabados es una de las causas de que el uso de prototipos siga siendo complicado. ¿Cómo reducir entonces el riesgo de tener que trabajar durante meses en un juego para poder evaluar si la idea merece la pena o no? No hay una buena respuesta para esta pregunta. Muchos estudios optan por reutilizar fórmulas bien conocidas, con lo que pueden entrar en producción sin preocuparse de que la idea no vaya a funcionar. EA no duda que FIFA’07 va a utilizar en buena medida la misma mecánica que los diez anteriores. Otros, desarrollan una primera parte, que sale a la calle con evidentes problemas, y van refinando el concepto y mejorándolo en sucesivas versiones. Ahí tenemos el ejemplo del Shogun/Medieval/Rome Total War. A Will Wright le está costando varios años desarrollar Spore porque montó un prototipo enorme, que era casi el juego completo, y luego decidió tirarlo y hacer el juego de verdad. Los chicos de High Moon defienden el uso de tecnologías ágiles como Scrum, donde la filosofía es tener constantes iteraciones y siempre una versión funcionando, y pulida, a la que se pueden ir añadiendo o eliminando elementos. Muchos otros estudios lo resuelven como pueden, rehaciendo con gran esfuerzo aquellas partes en las que se equivocaron. Malditos árboles. ¡Danos tu opinión! (1 comentario) [...]

Gaming World Forums - Useful gamemaking/ design tips wrote on January 20th, 2007 at 5:17 pm:

[...] http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/__________________Project (click to reveal)Earthlings StoryComing soon…Click to hide [...]

大风起兮云肥羊 wrote on January 21st, 2007 at 5:48 am:

[...] 8:59 AMAdd a commentRead comments (3)PermalinkTrackbacks (0)Blog itPermalinkhttp://oncehandsome.spaces.live.com/blog/cns!29DE2201D3C8BC93!324.entryCommentsFAYE阿宝哎…… 另，居然在这儿看到柠檬，好诡异……圈子真小。January 18 1:05 AM (http://luodandenaicha.spaces.live.com/)白骨第一次对未来失望的时候,就是看到功夫的游戏画面,那时候就突然觉得没前途了-.-July 21 8:19 PM (http://zichong.spaces.msn.com/)（没有名字）没有办法，我们都没有办法。黑恶势力已经形成，我们要么螳臂挡车，要么随波逐流July 06 2:26 AM (http://xhey.spaces.msn.com/)You must sign in using a Windows Live ID™ to add a comment to this space.Don’t have a Windows Live ID? Sign up now.Add a commentYour name:Your e-mail address (optional):Your blog web address (optional):Comment (text only):AddCancelTrackbacksThe trackback URL for this entry is:http://oncehandsome.spaces.live.com/blog/cns!29DE2201D3C8BC93!324.trakWeblogs that reference this entryNoneJune 28Raph Koster’s 40 ways to be a better (game) designerhttp://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552 [...]

Game Design MiniCourse - Kim Gregson - Ithaca College Spring 2007 wrote on January 22nd, 2007 at 5:34 am:

[...] Assignments Week 1introductions, go over project requirements, check out the game design software and play a couple of games made with it, define a game and go over some basics, industry structure - look at this website, define, discuss “what makes your favorite game fun”, Week 2game design phases (concept, preproduction, production, QA, launch), game genres, career info - look at this website, story boards, design documents, generate game ideas, go over concepts: game play, points, rules Week 3go over first 1/2 of Raph’s book, generate game design ideas, define fun, go over objectives, levels, character development, how story is implemented, group work time Week 4finish Raph’s book, groups present ideas for their game (have at least 2) for class to critique, talk about game look and feel (lighting, interface), resources, group work time Week 5discuss conflict & outcomes, generate game ideas, game video and audio, group work time Week 6generate game ideas, group work time, talk about how deals are put together in the industry Week 7Presentations of final ideas and story boards, group work time Spring BreakSpring Break week 1 - what’s a game, some key terms (interactivity, gameplay), Tour of the lab we’ll be using, into to 3d game studio, intro to the tutorial - assignment for week 2 - do the tutorial books in ebrary Game Design - ch 3 on genre specific design choices - has lots of good chapters Game Design for Teens - ch 3 - the design document Game Level design - ch 1, 2, 4 (Ed Byrne) Beginning Game Level Design - ch 8 about storytelling (by Feil and Scattergood) - has lots of other good chapters Jenkins Game design workshop Homepage for 3d Game Studio and movie of games made with 3dGS demo’d at GDC On Virtual Economies by Edward Castranova 40 Ways to be a better (game) designer from Raph Koster PDF from the US government about careers int he videogame industry, from 2000 - some stats may be dated, but the basic description of career paths is good Game Career Guide IGDA’s Career guide GameDev.net - tons of game development resources GameSutra - art and business of making games - primary resource for lots of designers Ernest Adams Designer’s Notebook articles from Gamasutra Design document article from gamasutra in 1997 an example brief game design doc - word doc, for game Harmotion -> Harmotion another game design doc - this one from a student project from DigiPen PDF game design doc for game EMberScribe for the nintendo DS - has some interesting features (tables, mini-faq, market research Forums from indiegamer.com - has stuff for artists and musicians looking for work, help wanted jobs, lots of good looking discussions on development another design doc example Gamasutra article about preparing your portfolio for your job search Good article by Ernest Adams about designing more innovative games postmortem example for Black & White postmortem example for Zoo Tycoon:Marine Mania Game Design features from gamasutra.com - articles, videos from gdc Top 20 publishers of 2006 from game developer magazine Open letter to academic researchers about why industry ignores us and how to change that [...]

Genesis :: View topic - 40 Ways to a Better Game (Design) wrote on January 27th, 2007 at 7:56 pm:

[...] I found this off http://www.devmaster.net/ … some good policies to follow: http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/_________________<homestar14> What is the first thing that need to be coded? <Alex||> the intro video where thugs steal your girlfriend and you come out of the garage [...]

M�nguMeistrid - 40 ways to be a better (game) designer - Powered by XMB wrote on March 2nd, 2007 at 1:37 pm:

[...] 40 ways to be a better (game) designer http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ [...]

Halycopter o/ » Machinima and Game Design wrote on March 5th, 2007 at 8:47 am:

[...] come up with a game concept for a presentation shortly. So I googled around a bit and came across ‘40 Ways to be a better (game) designer’ on Raph Koster’s website, Raph Koster having worked on Star Wars Galaxies as Chief Creative [...]

Reverse : A Javascript Game in 24 hours at ArunRocks wrote on April 23rd, 2007 at 4:04 pm:

40 ways to be a better (game) designer - FlashMove Forum wrote on July 31st, 2007 at 2:53 pm:

[...] ways to be a better (game) designer 40 ways to be a better (game) designer __________________ Our greatest glory is not in never falling but in rising everytime we fall. [...]

No More Hero wrote on August 30th, 2007 at 5:46 am:

[...] ��Դ��Raph Koster��һƪ��£��http://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552 [...]

QANTM College Amsterdam - Weblog » 40 ways to be a better (game) designer wrote on September 28th, 2007 at 1:19 am:

[...] just before I leave…This may be an interesting article for you guys! It is taken from here. (You can also find it on [...]

Developer Bored: Pitch Me Game Idea - GP32x.com Board [GP32 GP2X XGP] wrote on September 29th, 2007 at 12:31 pm:

[...] a review of the basics would help you;http://www.raphkoster.com/2006/06/26/40-wa…-game-designer/personally break all of it but it's always good to know what rules you're [...]

Discover From Your Favorite Topic or Web Page wrote on October 8th, 2007 at 7:52 am:

[...] [Discover] Raph’s Website » 40 ways to be a better (game) designer [...]

Dimensión 2.5 » Blog Archive » 40 claves para hacer un buen videojuego wrote on December 1st, 2007 at 3:03 pm:

[...] un buen videojuego no es tarea fácil, por lo que todo consejo es bienvenido. Pues aquí tenéis nada menos que 40 consejos para el desarrollo y planificación de un buen [...]

Game Design MiniCourse - Kim Gregson - Ithaca College Spring 2007 wrote on December 3rd, 2007 at 11:39 am:

[...] 40 Ways to be a better (game) designer from Raph Koster [...]

Iste Aleator » Blog Profile: The Whimsical World of Raph’s Website wrote on January 29th, 2008 at 9:52 am:

[...] of this post. It also has 24 Technorati fans. Mention (and link to) the two most interesting posts: 40 ways to be a better (game) designer and Project Horseshoe: Influences. 40 ways is interesting because it not only offers advice for [...]

Iste Aleator wrote on January 29th, 2008 at 5:23 pm:

How popular is the blog (by activity and/or technorati rank)? Raph’s Website has a Technorati authority score of 467 at the time of this post. It also has 24 Technorati fans. Mention (and link to) the two most interesting posts:40 ways to be a better (game) designerand Project Horseshoe: Influences. 40 ways is interesting because it not only offers advice for budding designers, but it enumerates said advice as well. I saw Influences cited somewhere (I can’t for the life of me dig up where, and I wish I knew so

WorldIV » Online gaming, commentary… and maybe some coding too! wrote on April 14th, 2008 at 7:05 pm:

re left with a system of Virtues that feels poorly integrated with the rest of the game. Players come back to it later, when there’s nothing better to do. And thus has come one of the deadly sins of game design.Quoth the Raph in “40 Ways to be a Better Game Designer”:#39 […] Check against the list of key pieces required for fun: preparation for a challenge mattering, territory/environment mattering, choices in how to solve a problem, variations in the nature of the challenge, risk to loss, skill in execution,

Lobosolitario said on June 26th, 2006 at 2:24 pm:

Steal and borrow
Mechanics are not sacred. They are tools towards an eventual game. If open draw card piles is a useful mechanic, use it even though you have seen it in other games. Nobody but you cares if you are sick of the health bar.

This is one of my personal favorites - I’d add “When you’re making a game, look at all the other similar games, and see what they do right”. I’m still amazed at how many games come out and totally ignore the very sensible basic mechanics of their peers. For instance, Total Annihilation came out in 1997, and *still* most RTS games since have failed to incorporate a lot of the simple, but effective, methods of control present in that game. Games are like societies - you have to build on your predecessor’s work, or you’ll never get off the ground if you keep trying to redesign the wheel.

MikeRozak said on June 26th, 2006 at 2:37 pm:

Random commments:

Meetings - My theory: The efficiency of a meeting is inversely proportional to the square of the number of people attending the meeting. Corralary, the amount of work accomplished by a meeting is inversly proportional to the number of attendees. (Thus, efficiency = (work / attendees) / attendees = work / sqr(attendees)) … which means a meeting with 8 people for an hour accomplishes about 1/2 as much as a meeting with only 4 people for an hour … or it takes twice as long a meeting to accomplish the same thing.

Related theory - Project groups are just like meetings… Which is why you start a project group out small to produce the core vision, and gradually increase the size of the group. If you start with a large group, or scale up too quickly, people end up wandering around with confused expressions and continually ask, “What are we really trying to accomplish here?” (Raph’s post about a skunkworks UO team suddenly getting an influx of the Ultima IX team reminded me of this one.)

MikeRozak said on June 26th, 2006 at 2:43 pm:

Lobosolitario wrote:

Games are like societies - you have to build on your predecessor’s work, or you’ll never get off the ground if you keep trying to redesign the wheel.

Or is this the problem with games? This approach often leads to perfection of form (aka: WoW), but lack of innovation.

“Redesign the wheel”… Do I really need a wheel in the first place?

I (think I) understand what you’re getting at though: Understand what predecessors did, and why they did it.

chabuhi said on June 26th, 2006 at 2:50 pm:

MikeRozak wrote:

This approach often leads to perfection of form (aka: WoW), but lack of innovation.

Amen, man - the very reason we have 4.3 trillion reality shows on TV.

Raph said on June 26th, 2006 at 2:52 pm:

I said “a mechanic” not “the whole damn game”!

Lobosolitario said on June 26th, 2006 at 3:01 pm:

That sums it up nicely

Jare said on June 26th, 2006 at 3:33 pm:

There’s something to be said about not trying to make every single aspect of a game new and different from everything else. I was talking to my team today about the warm feeling of comfort I get when I start a new FPS and my fingers calmly adopt their WASD+mouse positions. I’m hoping the FPS has lots of interesting ideas and innovations, but if they are going to change the control system, they better have a damn good reason for it. Same goes for (potentially) every feature.

So, hum… yes, I agree.

John said on June 26th, 2006 at 4:40 pm:

I have one to add, or maybe I’m restating “Blue Squares” a different way - Don’t be afraid to be wrong, Iterate. Being frozen in the decision making process is taking away valuable iteration time, and fun games can frequently come from having the greatest number of iterations possible.

Wilfried said on June 26th, 2006 at 5:07 pm:

Great list. I agree with everything. Except that point 18 is not my taste if used too much - but see point 30 for that

What I missed in the list is more about content. If you design a MMORPG you need content, content and more content. That’s a key point many MMOs lack in and fail just because of that.

If you are making content, stop thinking that randomized stuff is called content. It’s not. That’s why I’m not too comfortable with point 18 - it’s good to have dynamics, but no algorithm in the world can keep up with good handmade (static, not that static is good, but there is no way around it so far) content. If you write a book you should concentrate on the story and not on an algorithm doing the story for you. AI isn’t and won’t be good enough for that for still a long time to come.

I recommend James N. Frey’s “How to Write a Damn Good Novel” when starting to think about conent. Not only for storywriting, there are better books about storywriting out there (”Stein on Writing” for example), but Frey has the right way to repeat the key points over and over again. Many of them fit on every bit of content of a MMO perfectly. You don’t have the time to make a masterpiece of fiction, so don’t try. But try very hard to stick to the principles of storywriting with all content (again, that’s about all content, not just the story).

Some rules you could learn from that are for example:

To have conflics, have a lot of them, have zones and kingdoms (for a fantasy example) rival each other, have NPCs that hate the next shopkeeper, have antagonists with a reason, have creatures that fight each other in the wild (and have a reason for that), have NPCs with a background why they are doing bad™ things (and never forget to actualy have NPCs that do bad™ things) etc.

Have a premise for all of your content. What is this quest about? What is this NPC about? What is this zone about? It’s simply just a sentence, but it makes a huge difference to have a good premise and stick to it. And learn what a premise actualy is about. Once you get used to it, it’s easier than one might think, just minutes of work - but it can have a huge impact if you stick to these words.

Learn about Storyarcs that follow every part of a players life. What does a player do with level 42 (for example, if your game is level based)? Give his life with level 42 a meaning. Give him an experience. Let a story begin in the zones he will most likely visit with this level, and let the story follow his life until he is 43 (or 44, or whatever you aim for). Again, “story” does not mean an actual story, but the story all your content together tells the player. Don’t misstake this as “lore” for example. It’s about the world and how it presents itself to a level 42 player.

Remember to show the player the world and the story, don’t just tell him. Raph, you mentioned some wisps in another blog and that they whispered something back to the players. I agree that this a great thing to do - however, letting the MUD days behind me, I would say letting the wisps do something would be much better. Don’t let them just pick up some words and mangle them, but let them react visually on the words. How about a wisp that knows a lot of directions and will show you a few meters the way you have to go to find “robin the innkeeper”? How about wisps that fear the word “king” and will jitter every time a player speaks it out? Maybe some wisps turn red when someone mentions “Love”? You get the point.

It’s very hard to tell a story in a world that hardly knows linear time. But that’s just one more reason why you should try your best to do the little things that actualy can be done in this worlds. And don’t fear spoiler sites too much. They spoil the quests, but this is about the players experience, not about a spoiled quest.

Again, for risks and adverse effects with my opinion see point 30

SirBruce said on June 26th, 2006 at 6:05 pm:

I find #30 and #37 are pretty fun. Right now I’m struggling with #12, which is a double-edged sword. For instance, I’ve been trying to design a card game off and on for years, but it always wound up as being too much like Illuminati, just with different cards, so I had to come up with a completely different mechanic. I think I’ve got the thing down now, but I’ve prototyped so much I’m not sure if it’s really any fun. I have to get it into the hands of some other people.

Lobosolitario said on June 26th, 2006 at 6:21 pm:

Ok, I’ll rephrase to:

“Do your homework beforehand, and during”

Meaning that whatever you do should be (mechanically) at least as good as everything that went before it(and anything that pops up during the making) put together, and hopefully improve upon some areas, or add new ones. Interfaces, registration systems, webpages, pay systems, to name a few things, have been done many many times before, and often quite well, yet I still see programs with serious flaws in these areas.

Lobosolitario said on June 26th, 2006 at 6:54 pm:

it always wound up as being too much like Illuminati, just with different cards, so I had to come up with a completely different mechanic.

Maybe you should try to make a game using the Illuminati system, and see what you can do to the feel and balance of the game by changing other things that aren’t related to the set of rules you keep coming back to? In doing so, you may discover deficiencies or subtleties in the ruleset that will lead you to a new ruleset.

I often find that in modding games, I come up against the limitations of the rules very quickly, limitations that I didn’t necessarily know about beforehand.

Lobosolitario said on June 26th, 2006 at 6:58 pm:

Oh, and if you want playtesters, we have an office full of professionals, so feel free to throw your game at us for some testing

Michael Chui said on June 26th, 2006 at 7:11 pm:

The caveat to borrowing mechanics is to know why you’re borrowing.

The analogy is programming. I’ve helped far too many people who copied twenty lines of code and is confused at why their entire program isn’t working.

Anecdotes: Being a longtime player of Dragonrealms, I’ve furthermore worked on games by people who got sick of it and wanted to do their own thing. I also know it’s doomed to failure the moment I see blatant copying without any justification. “Why do you have that in there?” “It worked in DR…, and we’re DR, only better.”

Which is a fine sentiment, but… not the right one.

Raph said on June 26th, 2006 at 9:25 pm:

Wilfried, I left out everything related to content because it’s usually not game design — like, your examples are old creative writing adages. Plus not all games even have or need content — it all depends on the sort of game.

MikeRozak said on June 26th, 2006 at 9:36 pm:

Lobosolitario and Raph wrote:

Sorry. Me not can read… [sic]

Although, personally, I think mechanics are borrowed far too often.

Speaking of a mechanic:

Nobody but you cares if you are sick of the health bar.

What is this obsession with hit points? Gary Gygax used hit points because they were a convenient way of simulatuating wounds. Various table-top RPGs later tried to get away from hit points, but found hit locations too tedious to keep track of, particularly when a GM had 10 cannon-fodder orcs to keep track of. (Damage locations also led to one-legged, no-armed characters, but that’s remedied with magic, just as HP are healed with magic.) However, with the advent of computers that can easily handle a more complex damage model, CRPGs/MMORPGs still use HP!

PS: The combat game experience/mechanics change significantly when HP are replaced by hit locations and flesh wounds/bleeding, which affects the feeling of the entire game. I can go into excruciating detail, but won’t tortue you with specifics of how the game changes. And, yes, Conan is doing hit locations, although I haven’t read much about the implimentation, so I don’t know if it’s just HP per limb.

As Michael Chui wrote, don’t borrow mechanics mindlessesly. Understand why they’re there, how they work and interact with other mechanisms, and then decide to borrow them (or not).

Borrowing UI, such as WASD, is mostly a good thing since it makes it easier for users to get up to speed. One could say the same about mechanics (such as HP), but mechanics include the downside of “I’ve played this game before.”

Yehuda Berlinger said on June 26th, 2006 at 11:18 pm:

Very nice. Thanks.

Yehuda

SirBruce said on June 26th, 2006 at 11:53 pm:

Computers may be able to handle more complex damage models, but it’s not clear that the conscious mind can. A health bar is a quick, easy to understand method of determining how close you are to a “losing” state which require you to restart the game from some previous point. Replacing this with, for example, visual damage clues, body parts going lame, etc. not only probably reduces the fidelity of the system (are you really going to have 100 stages of impairment to correspond to what were 100 “hit points”? More likely you’ll have closer to 10), but also makes it more difficutly for the observer, the player, to accurately gauge (Is a lost finger better or worse than a gimped leg? How many more typical encounters can I survive if I only have one good arm left vs. one good leg?).

Almagill said on June 27th, 2006 at 2:15 am:

I’d add “don’t be different ‘just because you can’ only be different if you’re doing it better”.

eg, players have got used to WASD for movement (even hardware manufacturers have and make kboards with big chunky WASD keys for the hard of thinking like me), so don’t suddenly decide to make your movement keys U,D,ctrl+F4,RMB ‘just because you can’…

Actually, I’ll rephrase that. “Don’t introduce Obstacles TO Play without a cast iron reason for doing so”. And come prepared with a good explanation of *why* it has to be so.

Lobosolitario said on June 27th, 2006 at 2:29 am:

I read mechanics more as “UI” than as “health points”, although it’s applicable to everything. And by copy I’d read “copy in spirit”, not “cut and paste”. Health bar or wound system, that’s down to choice, but you should know what went before, and how it worked, and be able to compare the playability of your new feature to the other methods available. More importantly, just because you’re being innovative isn’t a reason to ignore everything anyone else has made on the basis that “I want to be totally original”. Originality is good, but if you design a UI from scratch, without looking at other UIs, you’ll probably make something that is A)Unoriginal and B)Doesn’t work very well. The bottom line is: learn from other people’s mistakes. That doesn’t mean cut/paste other people’s work, it just means know what they did, how they did it, and don’t make the same mistakes they did.

Lobosolitario said on June 27th, 2006 at 2:30 am:

That’s pretty much what I was trying to say in my rambling way

Raph said on June 27th, 2006 at 4:16 am:

On #18, GameDevMike has comments about emergence.

My reply:

I meant something simpler — given the choice between designing a game like Tetris and a game where you have to design every level in advance, try to design Tetris.

You can always design levels for a game which offers algorithmic challenges; you cannot supply algorithmic challenges for a game that requires handcrafted content to be enjoyable. And the handcrafting is much more work and gets dull faster.

A good algorithmic game is fiendishly hard to pull off, however.

Michael Little said on June 27th, 2006 at 5:13 am:

Speaking of hit points and whether CRPGs/MMORPGs can do better, there was a game several years ago that did change the texture on the creatures you were fighting to display their health. I am trying to remember the name. I think it may have been the last of the Wizardry series. I am just thinking the joy the art department must have felt to do three+ times the artwork for every creature.

SirBruce said on June 27th, 2006 at 5:45 am:

Oh, I think several RPGs have done the texturing route to show damage, but most all of them showed health bars as well. If they didn’t, it was usually only because you couldn’t see the health bars on the enemy NPCs, but you still could on your player character, and enemy NPCs tended to have much lower health than the player character anyway.

Allen Sligar said on June 27th, 2006 at 8:29 am:

Great stuff here.

Thanks

PS: SirBruce your previous post about health bar vs targeted damage brought to mind a certain Monty Python movie involving a certain Black Knight, it is after all “only a flesh wound”….heh.

Anon said on June 27th, 2006 at 10:21 am:

You’ve already got a couple of comments about #18, but let me add another. I think you mean to write something like:

“Algorithms can be your friend
The games with the most variety have an algorithmic style of variation, where gameplay emerges out of the possible permutations; this is as opposed to games which rely on a supply of static puzzles you supply. Clever use of the former can produce excellent games with continuing challenges and freshness. Nonclever use of algorithmic variation can produce large, boring games.”

instead of:

“Algorithms, not static data
The best games have an algorithmic style of variation, where gameplay emerges out of the possible permutations; this is as opposed to games which rely on a supply of static puzzles you supply. Shoot for the former — you may not make it (which is fine) but you’ll probably be forced to be cleverer.”

Algorithms are not the be-all and end-all, nor are they always the best games. Halo 2 dumps new enemies in identical locations. If it didn’t, it would be totally unplayable on Legendary, where the snipers kill you in a single shot. I’m sure it would have been trivial to randomize the enemy spawns, but would it have made a better game? Not at all. The difference between algorithmic and handcrafted content is like the difference between C and Java, not like the difference between good and bad. Each has its place.

tuebit said on June 27th, 2006 at 10:30 am:

Great list Raph. Some I intuitively knew to try, other’s are great reminders.

One question with regards to #39. Could you elaborate on what you meant by “no bottom-feeding”?

Morgan said on June 27th, 2006 at 10:49 am:

Some principles of mine…

"Design to sell, not to impress." In advertising, agencies constantly compete for awards. To win an award, the key is to impress colleagues and competitors; unfortunately, when the focus is on impressing colleagues and competitors, the actual customer with which the design is supposed to communicate is left out of the loop. Don’t forget the customer. Don’t forget the player. Design to sell, not to impress.

"Strive to eliminate that which adds little or no positive value to the experience." First, understand the market, identify customer and player experiences, and prioritize the segments in order of importance to business continuity. Then, eliminate the elements of the design that add little or no positive value to those customers and players.

MikeRozak said on June 27th, 2006 at 2:44 pm:

SirBruce wrote:

Computers may be able to handle more complex damage models, but it’s not clear that the conscious mind can. A health bar is a quick, easy to understand method of determining how close you are to a “losing” state which require you to restart the game from some previous point.

Changing from HP to hit location and a different damage model completely changes the combat experience, including the issues you’re describing. For one, the pace has to slow down. Most importantly, the game changes from one of intense resource management (HP slowly draining away, cool-downs, and limited health potions/mana) to some resource management with significant rock-scisors-papers added, understanding your opponents fighting style, and trying to get your opponent to misunderstand your fighting style.

I’m not saying that hit-location combat is better than HP, just that it is different (and viable), and that having a different experience is part of the fun (if it’s well executed, yada yada yada). (As Raph talks about with pattern recognition in his book.)

You’re also right about the problems with showing wounds. I’m not sure how Age of Conan will try to solve this, but they must in order to make hit-based combat succede.

BadMisterFrosty said on June 27th, 2006 at 4:01 pm:

[...] Anything you do in the game “because you have to do it” should be cut or at the very least get a seriously hard look. Tedium is the enemy of fun.

This leads to the »its not fun, remove it« mentality. Was it fun to wait at a teleporter to reach another location? It wasn’t, but that way the whole flow of the game was different, it created social hubs while waiting, some filled the wait-time with something creative. Thats one example. So some things may be negative and not fun viewed isolated, but may be a vital centerpiece of the fun in other parts of the game. Yes, I believe in holism when games reach the complexity of mmorpgs.

Cosmik said on June 27th, 2006 at 4:25 pm:

Preventing high level players from chewing through content intended for lower levels - either because the player has nothing better to do or because the game was inadvertantly designed that way.

(A classic example would be a high level player having to go to a low level area and farm components used in the creation of a high level item)

Cosmik said on June 27th, 2006 at 4:26 pm:

Although I somethimes wonder about the inclusion of “inadvertantly” in my above statement.

pantomimeHorse said on June 27th, 2006 at 4:31 pm:

So some things may be negative and not fun viewed isolated, but may be a vital centerpiece of the fun in other parts of the game.

This is very true in multi-player games. In Counter Strike, for instance, players can’t respawn after dying, forcing them to wait for the next round. Forcing players to wait is essential for the other players because it means that opponents won’t pop out of no where, destroying all strategy of positioning in the game. It really frustrates me that no one making FPS has made the slightest attempt to resolve this dillema with some happy medium.

Michael Chui said on June 27th, 2006 at 9:08 pm:

I just found this:

http://www.computerarts.co.uk/in_depth/features/50_ways_to_become_a_better_designer

The similarities are striking.

It really frustrates me that no one making FPS has made the slightest attempt to resolve this dillema with some happy medium.

Are you sure? My (admittedly very, very minimal) experience is that some FPSes permit you to capture spawn points, thereby making it impossible for an opponent to spawn behind you. I believe Battlefield does this.

Raph said on June 27th, 2006 at 9:28 pm:

Heh, read the original posr more closely, Michael!

tuebit said on June 28th, 2006 at 6:50 am:

I’d like to suggest an addition to #39, the list (I know it was your own personal list, but nonetheless) …

For multi-player games, feature shouldn’t break community.

When playing with others it’s frustrating for all parties when part of the group progresses to the point where another part of the group can nolonger participate. Members are forced to make a choice … leave friends behind, or avoid progressing forward (pitting one source of fun against another).

That’s not to suggest that all players need to have equal power at all times. Only that it should still be possible for the lower powered players to tag along and participate to some degree.

Michael Chui said on June 28th, 2006 at 9:15 pm:

Yay for skimming to the actual content first and skipping the intro. =P

Athela said on June 29th, 2006 at 5:17 am:

Ignorant question number 581 from moi:

Galaxies was my first mmorpg,

40 ways to be a better (game) designer

111 Responses to “40 ways to be a better (game) designer”