40 ways to be a better (game) designer
(Visited 213217 times) Game talk
Jun 262006
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.
116 Responses to “40 ways to be a better (game) designer”
Sorry, the comment form is closed at this time.
a list of ways to be a better game designer.
https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552
. It’s a good read.Link – posted by CC at 8:40 AM Permalink – Backlinks – photos – 0 comments
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
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
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.
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
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
40 ways to be a better (game) designer (Via Wonderland.)
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 !
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
| 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:
ęäøŗę“ä¼ē§ēęøøęč®¾č®”åøē40ē§ę¹ę³ļ¼äøļ¼ åčØ ē±äŗēÆå¹ ē大ļ¼å ę¤čÆč åäøŗäø¤éØåļ¼äøä¾æä¹å¤čæčÆ·čÆ»č č§č° ć ę¬ęęŗčŖRaph KosterēäøēÆęē« ļ¼åŗå¤åØäŗhttps://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552
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
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,
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.
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.)
Lobosolitario wrote:
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.
MikeRozak wrote:
Amen, man – the very reason we have 4.3 trillion reality shows on TV.
I said “a mechanic” not “the whole damn game”! š
That sums it up nicely š
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. š
[…] Comments […]
[…] 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 […]
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.
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 š
[…] 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.https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552 […]
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.
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.
[…] 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(); }); } […]
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.
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 š
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.
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.
Lobosolitario and Raph wrote:
Sorry. Me not can read… [sic]
Although, personally, I think mechanics are borrowed far too often.
Speaking of a mechanic:
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.”
Very nice. Thanks.
Yehuda
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?).
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.
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.
That’s pretty much what I was trying to say in my rambling way š
On #18, GameDevMike has comments about emergence.
My reply:
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. š
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.
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.
[…] 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. […]
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.
[…] [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 […]
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”?
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.
[…] 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. […]
[…] 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. […]
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…
SirBruce wrote:
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.
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. š
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)
Although I somethimes wonder about the inclusion of “inadvertantly” in my above statement.
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.
[…] 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 […]
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.
Heh, read the original posr more closely, Michael!
[…] 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. […]
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.
[…] ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½: 2006-6-28 18:16:00ļæ½ļæ½ļæ½ļæ½ | ļæ½ļæ½ļæ½ļæ½ | ļæ½ļæ½ļæ½ļæ½ | ļæ½ļæ½×“ | ļæ½Õ²ļæ½ | ļæ½ą¼ | ɾļæ½ļæ½ | ļæ½ļæ½ļæ½ļæ½ Raph Kosterļæ½ļæ½ļæ½ļæ½ĪŖŅ»ļæ½ļæ½ļæ½ĆµÄ²ß»ļæ½ļæ½ļæ½40ļæ½ļæ½ģ·Ø ļæ½ļæ½Ö·ļæ½ļæ½https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-55240 ways to be a better (game) designer […]
Yay for skimming to the actual content first and skipping the intro. =P
Ignorant question number 581 from moi:
Galaxies was my first mmorpg, and I didn’t know quite what to expect from it. One thing I did expect to see coming from the Jedi Knight series of games was some of the great level design that those games had. I was surprised to find nothing at all like those levels in the gameworld. So my question is, why, even in “instanced environments” aren’t that type of gameplay element included in mmorpgs? I hope I’m being semi-clear. š
Multiple reasons. There are a set of “subjective” reasons, which aren’t the main reason for this gameplay element being left out, but they do play a role. To start with, workload and focus – making those levels takes a lot of work. Since MMOs tend to be made up of very large areas, there’s a lot of work to be done just to make those semi-detailed, but much larger, spaces. Plus the development team tend to have other priorities – a FPS lives and dies on its level design, but an MMO depends more on other things, server functionality, rule systems for gameplay, balancing for those systems against large numbers of players… so detailed level design is often quite low on the priority list, especially because of:
Reason two, handcrafted content takes a lot of making, but doesn’t take much consuming – you may have spent a week designing that level, but a player who just wants to blast through and get the loot will probably go through it in a matter of minutes. Hence MMO designers tend to prefer “random” missions, which, once set up, provide an endless supply of content to blast through, at a lot less work.
Thirdly, the abovementioned player makes up a significant proportion of MMO gamers, which makes handcrafted levels even less valuable, since quite a large number of players *will* ignore all the nice work, and even complain bitterly if the interesting level design stops them from getting from A to B as fast as they would like.
Finally, technical issues. The main reason you can’t have highly detailed maps is because the servers simply can’t handle them adequately. High detail means high detail collision, which has to be done server-side (to prevent people cheating and walking through walls), putting a huge load on the servers. Every additional thing you can interact with also puts more load on the server. All the line-of-sight/fire calculations have to be done by the server, which, in a large firefight, could mean thousands of heavy duty calculations in a few seconds. At the current time, servers just aren’t up to doing all this, maybe sometime soon, but not quite yet.
Of course all the above could be avoided if the client (your PC) does all those calculations, which is fully possible. Unfortunately when all these things are done clientside, you get lots of people hacking their program, leading to all kinds of cheaters that can shoot through walls, walk through walls, hit people without needing to aim… just look at the history of counterstrike to see how doing clientside calculation effects online gameplay.
Those are all the reasons I can think of. Still, a degree of handcrafted content can be made – if you look at WoW, a lot of the world is hand-crafted and nicely detailed. But you still won’t get quite the degree of detail you’d get in a FPS.
This is one of my pet peeves with a lot of the MMOs I’ve played (SWG, Anarchy Online and Matrix Online especially). Making a world is a big job, and there often aren’t anywhere near enough man-hours to add all the detail that the team and players would like. But once release day arrives, in my experience, the world suddenly gets frozen in time. There may be some high level dungeons added, or even extra lands to explore. But why does no-one ever go back over what’s already been done, and refine it gradually over time? Maybe add in a few new low-level dungeons, an extra town here or there, a scripted quest, make the landscape more interesting… bit by bit, over time, the live team could make that world as detailed as it could be, within the technical limitations.
But why does no-one ever go back over whatās already been done, and refine it gradually over time?
1) Because they’re not paid to. Generally speaking, the area is Done. Therefore, why change it?
2) What if I accidentally mess up something really major!? This is the conversationist rationale: If it’s not broken, don’t fix it. Besides, there’s plenty of broken stuff to spend time fixing.
3) Because the customer expects predictability! I don’t think I need to elaborate on that one.
In short, there are too many reasons not to do it and too few to do it. This is not actually true, of course, but I think that people on the live team generally believe it.
[…] 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 […]
So my $15 a month is just going into thin air? Or is it only the people who are at (level 60 equivalent) who benefit from the live team? I guess that’s another reason to stick to a game, other than the server costs, all the rest of your subscription is wasted unless you get to the “endgame”.
A lot of the time it *is* broken, just not enough to have people screaming about it (the good old Known Ship). I remember an old hermit I used to visit on Corellia in SWG, lost out in the mountains. He was obviously a part of some jedi related thing at some point, but had been lost in the database, and now just wanders the mountains giving people a quest to go to an empty spot in the middle of Corellia over and over again.
This one I do agree on, but there’s a big difference between massive changes and refinements. Gradual changes are ok in my book, as long as the whole town isn’t wiped off the map ovenight.
Excellent post. Very good ands practical hints & tips for design. Thanks.
My dream game design job would be content design for the first EverQuest, and focusing solely on the classic zones….
It’s true that you don’t want to fix something that’s not broken, but that depends on how you define “broken.” A piece of moldy cheese isn’t really broken, it’s just moldy. But I wouldn’t eat it.
[…] 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). […]
[…] https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ […]
[…] Raphās Website Ā» 40 ways to be a better (game) designer […]
[…] 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: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. […]
[…] of Ruby on Rails tips in one place! – tips, tricks, and code snippets for Ruby on Rails developers # copy […]
[…] Raphās Website Ā» 40 ways to be a better (game) designer […]
[…] Also, see “40 ways to be a better game designer”: https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ […]
[…] 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.” […]
[…] 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.” […]
[…] ļæ½ļæ½ļæ½Ō·ļæ½ļæ½ļæ½ļæ½ļæ½Ņ»ļæ½Ā£ļæ½ļæ½ļæ½ļæ½ļæ½Ā©ļæ½ļæ½ļæ½ļæ½ÄµŲ·ļæ½ļæ½ļæ½Öøļæ½ļæ½ļæ½ļæ½ļæ½ 1ļæ½ļæ½ļæ½É«ļæ½ļæ½ļæ½ ļæ½ļæ½ļæ½ļæ½ļæ½Å“Ö²Ś»ļæ½ļæ½ę£¬ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ä»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·Ōļæ½Ķ£ļæ½ļæ½ļæ½ļæ½ļæ½Ź¹ļæ½ļæ½Ö½ļæ½ļæ½ļæ½Ź”ļæ½Ö½ļæ½Ęŗļæ½ļæ½ļæ½Ó”ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ö¶Īæļæ½ļæ½Ō¼ļæ½Ēæļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ß£ļæ½ļæ½ļæ½ļæ½Ē²ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½Č±ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Č¤ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ŁµÄ±ļæ½ļæ½ļæ½Ö¶Ī¾ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Č¤ļæ½Ä¶ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ć“ļæ½ļæ½Óµļ潊øļæ½ĆµÄ±ļæ½ļæ½ļæ½Ö¶ļæ½Ź±ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Č¤ļæ½ļæ½ 2ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½Ē”ļæ½ļæ½ļæ½ļæ½Ś”ļæ½Ź²Ć“ļæ½Äæļæ½ļæ½Ō°ļæ½ļæ½ļæ½ļæ½ļæ½Ć³ļæ½ļ潎¹ļæ½Ļµļæ½ļæ½ļæ½ļæ½ļæ½Ż”ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½Ł¼ļæ½Ņ»Š©ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ü°ļæ½ļæ½ļæ½Ńøļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½Ä±ļæ½ļæ½Ź”ļæ½ļæ½ļæ½Ņ»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ź½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ņ»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ģµļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ņ»ļæ½ļæ½ļæ½ļæ½Õ¾ļæ½Č·Ź±ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½ 3ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ņ»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ź¶ļæ½ļæ½ļæ½ļæ½Ä“ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·Źµļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ķ¬Ņ»ļæ½ļæ½ļæ½ļæ½Āµļæ½Ņ»ļæ½ļ潊”ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½Ļ£ļæ½ļæ½ļæ½ļæ½Ü»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ü¶ą”£ļæ½ļæ½ļæ½ļæ½ĻµĶ³Ö®ļæ½ļæ½ļæ½ļæ½Ś¶ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ż½ļæ½ļæ½ļæ½Ź¹Ņ»ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½Ę½ļæ½ā”£ 4ļæ½ļæ½ļæ½Ü½ļæ½ļæ½ļæ½Ó¦ļæ½ļæ½ļæ½Ü¹ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļ潊³ļæ½ļæ½Ņ»Š©ļæ½Ų¼ļæ½Ä¶ļæ½ļæ½ŹŗĶ¾ļæ½ļæ½Ó£ļæ½ļæ½Ō“ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ä“ļæ½ļæ½ā”£ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ä³ļæ½ļæ½Ų·ļæ½Ņ»ļæ½ļæ½ļæ½ļæ½ļæ½Ė“ļæ½ 5ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ćµļæ½ļæ½ļæ½Ļ·Ó¦ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ā”¢ĻµĶ³ļæ½Ķ±ļæ½ļæ½Ö·ļæ½Ź½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ļ”ļæ½ļæ½ļæ½ļæ½ļæ½Ź¹ļæ½ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ß·ļæ½ń”£²ļæ½ŅŖŠ”ļæ½ļæ½ļæ½ļæ½ń»Æµļæ½ļæ½ļæ½ļæ½ļæ½ 6ļæ½ļæ½ļæ½ß³ļæ½ļæ½Ä»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ē“ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ū»į£¬ļæ½ļæ½Ļ£ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½É¢ļæ½ļæ½ļæ½Ź±ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ö¾ļæ½ļæ½ļæ½ļæ½ļæ½Ē¾ļæ½Ę£ļæ½ļæ½ßŗĶ·ļæ½ļæ½ļæ½ļæ½ļæ½×”ļæ½ļæ½ß³ļæ½ļæ½Ä»ļæ½ļæ½é½«ļæ½ļæ½ļæ½Ā¼ļæ½ļæ½åæ¼ļæ½ĒŗĶ¹ļæ½ļæ½Śøļæ½ļæ½Ó»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ö“ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ū»ļæ½Ä½ļæ½ÕŗĶ¼ļæ½Ģ”ļæ½ 7ļæ½ļæ½Ź¹ļæ½Ć²ļæ½Ķ¼ļæ½ļæ½ļæ½ļæ½Ķ¼ļæ½ļæ½ļæ½ļæ½Ļ·ļæ½ļæ½Ęµļæ½Ņ»ļæ½ļæ½Ē³ļæ½Ēæļæ½ļæ½Ä¹ļæ½ļæ½ß”ļæ½ĶØļæ½ļæ½ļæ½ļæ½Ä»ļæ½ļæ½ļæ½ß»ļæ½ļæ½ļæ½ļæ½ļæ½Ō“ļæ½ļæ½ļæ½ļæ½ļæ½Ė¶ļæ½ļæ½ļæ½ļæ½Ļ¢ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ś°ļæ½ļæ½ļæ½Ņµļæ½ļæ½ļæ½Ļ·ļæ½ļæ½ļæ½é»ļæ½ļæ½ļæ½ļæ½Ē¼ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ĆµÄ”ļæ½ļæ½ļæ½Ņ»ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ņ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ŅŖļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½Ä²ļæ½Ķ¼ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ŅŖļæ½Ä±ļæ½ļæ½Ėµļæ½ļæ½ 8ļæ½ļæ½ļæ½ļæ½ŅŖļæ½Ś“ļæ½ļæ½ļæ½ļæ½ļæ½/Ö½ļæ½ļæ½ļæ½Ļ²ß»ļæ½ļæ½ļæ½ļæ½ļæ½ļ潊³ļæ½ļæ½Ļ² […]
[…] Raph Koster compiled a list of 40 Ways to Be A Better Game Designer. Check ’em out! […]
[…] […]
[…] 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 → […]
[…] 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. […]
[…] 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: […]
[…] 40 ways to be a better game designer […]
[…] Raph Koster’s 40 ways to be a better (game) designer https://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 […]
[…] Raph Koster’s 40 ways to be a better (game) designer https://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 Nice article.. rather long, but it’s worth the read. Read it here. […]
[…] 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 https://www.raphkoster.com/2006/06/26…game-designer/ I think the first three are vital as so often overlooked by bad designers! […]
[…] raphkoster.com post a huge list of 40 things he fells game designers should know and do. Some of my favorite include. […]
[…] Saw this, it's somebody's blog thing. He's an actual game designer,btw.https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ […]
[…] 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) […]
[…] https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/__________________Project (click to reveal)Earthlings StoryComing soon…Click to hide […]
[…] Ā 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) designerhttps://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552 […]
[…] 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 […]
[…] I found this off http://www.devmaster.net/ … some good policies to follow: https://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 […]
[…] 40 ways to be a better (game) designer https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/ […]
[…] 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 […]
[…] Raphās Website Ā» 40 ways to be a better (game) designer […]
[…] 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. […]
[…] ļæ½ļæ½ļæ½ļæ½Ō“ļæ½ļæ½Raph Kosterļæ½ļæ½Ņ»ĘŖļæ½ļæ½ļæ½Ā£ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½ļæ½https://www.raphkoster.com/2006/06/26/40-ways-to-be-a-better-game-designer/#more-552 […]
[…] just before I leave…This may be an interesting article for you guys! It is taken from here. (You can also find it on […]
[…] a review of the basics would help you;https://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] Raphās Website Ā» 40 ways to be a better (game) designer […]
[…] 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 […]
[…] 40 Ways to be a better (game) designer from Raph Koster […]
[…] 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 […]
[…] This post was mentioned on Twitter by jungly, fritz desir. fritz desir said: GREAT post by @raphkoster, 40 Ways to be a Better (game) Designer, 100% applicable to #UX: http://bit.ly/40waysGD […]
[…] be cut or at the very least get a seriously hard look. Tedium is the enemy of fun.ļ¼Sourceļ¼raphkosterļ¼ åäŗ«å°ļ¼ QQē©ŗé“ ę°ęµŖå¾®å å¼åæē½ […]
ipad pris…
Raph’s Website Ā» 40 ways to be a better (game) designer…
[…] 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 […]