40 ways to be a better (game) designer
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.
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. 🙂
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 😉
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.
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.
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.
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.
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.
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!
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.
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.
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.