This is the first one - it's pretty scrappy, more of an initial concept than a design document: http://www.godwars2.org/design/gw2_first...

This is the second one - it's still pretty vague in places, but it was enough to get started: http://www.godwars2.org/design/gw2_secon...

One thing to keep in mind is that the design WILL change. Don't get me wrong – you really have to put a design down on paper. But the reality of the situation is that you have no possible way in heaven or hell to know if that design will actually be fun until you code it. You might find some elements work well and others work horribly.

The real game professionals have some methods to doing design (and I learned these methods straight from the mouths of actual real-world game developers, not a goofy blog by some guy who's never even worked in the professional game industry):

1) Come up with a game vision. A game vision is a very short, simple, all-encompassing goal for the game as a whole. It is never more than one sentence; it's usually not even a whole sentence. Good game visions are things like "lava and fire everywhere" (Igneous), "visible sound" (my Sophomore game project), "be the Batman" (Arkham Asylum), "historically accurate warfare" (Mount & Blade), "platforming in space" (Mario Galaxy), "post-nuclear-holocaust survival simulation" (Fallout), "fast-paced deathmatch" (Quake3), etc.

Bad game visions are anything longer or more complex than those. A game vision is NOT the same as the game theme, game plan, game concept, or game design. It's just a single statement that you keep as the core heart of your game from start to finish. Thing is, you might have some specific game play ideas in mind… but if you build off of those instead of a vision, and those ideas don't pan out, you're stuck with a dead project. A MUD's game vision might be "brutal PvP" or "cooperative dungeon delving" or "social warfare" or so on.

2) Define your game concept. This is different from the game vision in a lot of ways. The concept is the overall description of what you envision the final game will be. This is what you'd use to pitch your game to potential investors, developers, and players! Arkham Asylum's game vision was "be the Batman" but its game concept would be more like "Metroid meets brawler as Batman – world's greatest detective – battles his most popular foes while trapped on Arkham Island, using the novel FreeFlow Combat System and a number of his infamous gadgets."

While that is what the final game's concept is, I will guarantee you it started out as something quite different. That's where the concept differs from the vision. The concept changes as you find out what ideas don't work and which do, but in the end, it always always always reflects the game vision. But you absolutely must have a game concept to start so you know where you're going.

Define a concept, but don't wed yourself to it. If your concept doesn't work out, be ready to change it. Just be sure you always have a clearly defined concept at every stage and that you follow that concept as closely as possible. Don't change it unless you prove it doesn't work, but dont' even just throw the concept out entirely and work without one. You'll never get anywhere without it.

3) Define milestones. Yes, a hobby project has no deadline. But without explicit goals and clearly defined stages of when those goals must be complete, you'll never get anywhere. You'll jump around from feature to feature with no plan and next thing you know 3 years have passed and you still haven't implemented a playable game.

I can't stress this enough. You MUST have milestones with target features. It doesn't matter so much if you have dates or deadlines (especially for a hobby) project, but you absolutely must have an idea which features you're going to get done and when.

The first miletone is generally "get a solid game concept and vision." This is the part everyone else is telling you to do: put down on paper what kind of game you want to build.

The second milestone is generally going to be "engine proof." If you're building off of an existing MUD codebase, this one is already done for you… maybe. Which features does your MUD absolutely need to work at all? It needs networking, it needs to allow players to connect, a room-based MUD needs at least basic rooms to navigate around, you need a basic command parser, etc. Figure out all the core low-level features you need to have any kind of MUD at all. Get those coded. Basically, code all the stuff you need in order to do anything else. Define those features on paper, put them in a Trac install or some other kind of issue/bug/task tracker, attach them to your "engine proof" milestone, and don't work on ANYTHING other than those tasks until they're all done. You won't have something you can actually play at this point, but you will have the technology you need to build an actual game.

Think of all those interesting features you want that make your MUD unique. Maybe you have a unique combat system in mind, or a feature where clans can build their own castles and conquer other people's castles, etc. List out all those features. Your third milestone isn't about implementing those fully, but it is about getting the basics for them. If you want clans to make their own castles, then for this milestone you would need to add very rudimentary clan support, support for each clan to have its own area/zone, and then some basic commands for letting a clan add or edit rooms in their zone. Again, this is all very basic. You don't need to add support for forcing clans to buy their zone, or doing access controls for which clan members can do the building, none of that. You're just getting the raw basic concepts down. They won't be playable, but you'll have the core components to make them playable.

Your third milestone would be something like a "first playable." This is where you take those core engine features and make some kind of playable game. For the clan-based PvP castle game, you would need to have rudimentary working combat in place for this milestone, as well as the means to capture/conquer a zone (even if it's just a temporary thing like "enter the throne room to capture the castle."). The game isn't polished or ready for prime time, but testers can connect and play and see what the game is all about and get an idea as to whether or not the game concept is fun or not. Bare basic game play, but working game play. Nothing more.

Your further miletones (and there will be more than just one here) are focused on finishing, changing, and polishing your features. Carrying on with the clan custom zones, you might say that your fourth milestone adds clan permissions, adds more advanced building commands, and cleans up the UI for building (this might be your Alpha milestone). The fifth milestone might include the ability to buy furniture, combat equipment, respawn/resurrection support, and built-in help pages. The sixth milestone would include the refined rules and special conditions for clan wars and castle conquering, stores for equipment, and ranking mechanics (this could be the Beta milestone). The seventh milestone might add the remaining features, and the eigth milestone is when you polish up features and UI (no new features at this point).

All these milestones get drafted before you start coding. They will almost certainly change as you work and realize some things don't work and other things do, but the point is that you always have a very clearly defined set of tasks to be working on, and that those tasks are reasonable for the stage of development you're at.

4) Let other people test your game at every stage. You cannot develop a good game in a vacuum by yourself. Your ability to judge your game's mechanics and playability is biased, inaccurate, and largely useless. You may well be emotionally attached to some unique design you came up with and be unwilling to recognize that the design really just isn't fun or playable at all. Letting testers at your game – and actually listening to what they say – is critical. They will stop you from wasting large amounts of time on bad ideas.

5) At all stages, you should have some beefy documents with all your design plans. Have a game design document that lists out every proposed game play feature, from the UI elements to how AI works to how the economy works to how combat works to how the world is represented. In a graphical game, this would include concept art. In a MUD, this might include example ways you want to format room descriptions and the like, example combat output, and so on. You will need a technical document that describes how you're coding the architecture for your game; how are rooms represented in the architecture, how do you code the AI, how do you deal with events and messaging, how is memory management handled, what file formats do you use, how do you structure your network I/O, etc.

Writing these documents up front will help you think about where you're going and help you plan. Once again, however, expect them to change. Don't force yourself to follow a bad plan. The plans are there to help keep you on track, not off it. If the plan is forced to change, though, update the documents!

One point I'd like to make though: While I agree wholeheartedly that documentation is extremely important, for many people it's also very boring. It can also be very demotivating to spend months arguing about every little detail and still not have any game to show for it.

At some point, you have to bite the bullet, and in my experience it's best to do so while you're still in the honeymoon phase of the project - because you're going to need every ounce of motivation if you want to make it through the first phase of development. Once you've got enough of a game for players to log on, things get much easier, but reaching that point is hard, lonely work.

So yes, write up your design, and make sure you cover all the important things. But don't quibble over every little detail. Save that for commercial products and paying customers. If the mud is your hobby, lack of motivation will kill it far faster than an incomplete design.

You're doing something preetty wrong if you're arguing that long. :)

I should add another axiom that the pros believe very firmly in: bias towards action over planning. If you don't know if something is right or wrong, find out the only way you can. Whip together a prototype. Punt on the design issue until you get enough engine up to prototype it. Whatever you need to do.

If you have two people arguing back and forth over a particular feature, just make a damn decision. The simple truth is that if two people cannot come to agreement on which method is better, chances are it just doesn't matter.

And to clarify further, the game deseign document initially is NOT about every little detail. It's the overarching plan. You aren't going to list in the specific math algorithms you use in combat or the specific placement of buttons/UI elements or so on in the GDD. You're going to list how the overall style of the UI you currently envision. If the UI ends up being something else, update the document.

The driving point I tried to make in my post is that YOU DO NOT HAVE ANY FREAKING CLUE WHAT YOUR GAME WILL END UP LIKE. You don't. End of story. You're not able to see the future. Don't try to nail down some specific exact definition of what your final game will be. Lay out the plan for where you want to go with a reasonable amount of detail, and do that solely so that you have something to measure your progress on set goals upon! When reality stops agreeing with the plans you have written down, change the plan to accomodate.

I would be a little wary of this, myself. There are some very good games which can be summed up in a single sentence; but if you insist on being able to do that, then you run the risk of limiting yourself to producing a game simple enough to describe in only a few words. Most of my favourite games over the years have been ones that can't be summed up quite so easily. A game like, say, "Black & White" could in principle be summed up as "be a god", but that summary gives you absolutely no idea at all about what the game is like to play. Similarly it's hard to sum up a game like "Bioforge" in one sentence.

By analogy, think about making movies. There are some good films that be summed up in a single sentence ("Die Hard", say) but, on the whole, if a film is simple enough to be summed up in that way, the idea behind it probably isn't substantial enough to carry a feature length movie. Try summing up "Being John Malkovich" or "Amelie" in one sentence. You can do it - "a shy waitress decides to try to improve the lives of the people around her" - but that doesn't really give you any idea of what sort of experience you'll have watching the film. So I'd be wary of one-sentence summaries.

Well, coming up with a vision is quite difficult. You can always come up with fairly simple (or simplistic) summaries of basically everything. But sometimes slight modifications can make a big difference. The idea isn't to summarize literally, but to evoke what is happening, the feelings that are generated. For example, consider this "vision statement" of Amelie Poulain: "modern-day fairy tale of individuals finding each other and themselves". While this does not describe what literally happens in the movie, and we 'lose information' as we don't mention that she's a waitress or is trying to improve the lives of people around her, we get a little bit closer to the intention of the film. This intention is clearer, incidentally, when you look at the French title, which translates to "The Fabulous Destiny of Amelie Poulain". (Fabulous coming from fable, after all.) Coming up with vision statements is quite difficult, so I'd be wary of people who don't spend much time on it and wave it away with a fairly simple statement; even if you make a simple statement, it should be quite deliberate.


One thing to add to this is to not be scared of throwing stuff away. Initial attempts are made without knowing what the rest of the game looks like. Design decisions change. Code can be sloppy when rushing to prototype. Do not be afraid to scrap pieces and re-write when you have to. Do not use something that was only meant to be a quick and dirty prototype as the final product, unless you are such a good programmer that gold code naturally rolls off of your fingertips. :smile:

It depends how much effort you want to put into your design before you start development - starting too early has drawbacks as well.

But developing muds as a hobby isn't the same as professionally developing video games. You don't have the budget and timescale pressures, nor do you have paid staff who are prepared to consistantly work around the clock to meet deadlines. It doesn't even really matter how popular the end product is, as long as there are enough players to make the game enjoyable.

Developing a hobby mud is a labour of love, and IMO motivation is your most important resource. Sometimes you have to let people take it at a more relaxed pace - push them too hard, take away their enjoyment, and you'll have no staff.

I'm sure there are lessons to be learned from the games industry, but I don't think those lessons are any more important than other software industries.

You are missing the point entirely. The vision does NOT sum up the entire game as a whole. That is the game concept. Look at the example I gave. How does "be the Batman" limit you to a simple game? Arkham Asylum was a big, triple A title that went on to receive a whole ton of awards. Anyone who plays it definitely feels that vision. The game really does make you feel like your the goddamn Batman. Despite that fact, there are a thousand different games they could have made that would have worked just as well. The specifics of the game they made were not limited by the vision; they were made _possible_ by the vision.



That's not a vision. That's a plot synopsis. :)

A vision for a movie is really much simpler; you actually nailed it already, you just misunderstood what you had! ;) "Die Hard" is a fantastic example of a vision. Die Hard was an awesome movie. The movie was all about that vision. No, the vision told you nothing about the plot, the characters, the artistic style… and it's not supposed to! That's what the concept (or synopsis) does! The point is, if you're a script writer or a director working on a movie, and you know the vision is "Die Hard," then you leave out cheesy kids' humor, over-the-top romantic scenes, excessive comedic relief… you know that you need to go action, action, action, with a little sprinkling of the other stuff in there to make all that action flow. There are probably 10,000 movies out there that could have used "Die Hard" as their vision, sure. Nothing wrong with that. Nothing says the vision has to be unique. There are a ton of great action movies out there, and the reason that they're great action movies is because their writers and directors had a vision – maybe just "awesome action flick" – and ran with it, instead of trying to toss in a ton of other crap that did nothing to support the vision at all. The movies that DO toss in the ton of other crap end up being those crappy action movies you watch once at a friend's house after drunkenly renting it at Blockbluster and then never watch again because even in your highly inebriated state you knew the movie freaking sucked. :)

The game vision defines the foundation of all the cool things your game is about. "Be the Batman" gives you so many possibilities its not even possible to enumerate them all. "Fire and explosions" could be just about anything. "Platforming in space" has so many potential game possibilities, none of which are forced to be simplistic or limited. "Mario jumping around mini-planets in space to collect stars and rescue the princess" is not a game vision; it's the opening line of the game concept. The game vision remains "platforming in space" which can turn in to almost anything. Maybe the developers had the idea of the mini planets from the start… but maybe it doesn't work out, and they instead end up with Mario platforming on Spaceships… or they end up with the foundation for the next Metroid game. Or a whole new franchise.

Look at how Left 4 Dead came about. You might think its vision was "kill zombies," but it wasn't. Left 4 Dead's vision was "close combat with a bazillion enemies." Could have been aliens, zombies, roving packs of adorable cockney street urchins, or killer tomatoes. It could be horror, comedy, or pure action. It could involve axes or firearms. It could be in modern day times, the future, the past, or an alternate reality. It could have been nearly anything, so long as that thing involved close-quarter combat with a bunch of enemies at once. You can simultaneously see the freedom that vision allowed the developers as well as instantly see just how damn well they pulled off making a game solely about that single vision! It's perfection.

Quite honetly, you can't do anything without a vision. You can't even start on a MUD without a vision. It's literally impossible. You don't even have the drive or ambition to START working on a MUD without a vision. Literally, absolutely impossible. The only difference between the successful pros and everyone else is that the pros acknowledge this fact and embrace it, rather than ignoring it. They know how to separate out the core of the vision from all the specific concept details that they have. They spell the vision out. Put it on paper. Put it on a plaque in the office. It's the first line of the documents they send to investors and producers. It often turns into the advertising catch phrase used for marketing to consumers.

When it comes time to adding features or designing concept art, the vision is the first thing you think about. You think about adding vehicles to your game… but your game's vision is "platforming in space." Do vehicles really make platforming in space any more fun? Platforming as a genre has always been about jumping around, not driving. You can save yourself hours, days, or months of wasted time by just throwing the idea out right there before going another step. Many other ideas stay on the table though. Nothing about "platforming in space" dictates that it must be on tiny little planets the size of big beach balls. Nothing about "platforming in space" says what kinds of enemies you can have. Nothing about "platforming in space" dictates the art style, story tone, or so on. Nothing about "platforming in space" says that it can't involve using sound and music to solve puzzles instead of blocks and keys. That all comes through the game concept and the game design documents and concept art.

Think of it like the difference between three dimensional space, a plane, and a line. The space represents all possible games. The plane represents all games fitting a given vision. The line represents all games fitting a particular concept. Each point represent a specific game. There are still an infinite number of games on every line, and "more infinite" games on a plane, even if there are infinitely less games on the plane than there are in three dimensional space as a whole.

All the same stuff applies to a MUD. If your MUD is about PvP, and your game vision for the MUD is "high paced bloody combat," and you get an idea for a computer-controlled economy system, throw it out the damn window. Nobody playing a bloody fast-paced PvP game cares in the least about in-game economy. In fact, none of the players will even _notice_ your economy system, unless it happens to be so horrifically badly designed that it actually gets in the way of the bloody fast-paced PvP action. If the best the idea can do is nothing at all and the worst it can do is make the game unfun and it has zero chance of enhancing the fast-paced combat, DON'T WASTE TIME ON IT. Not even a minute.

For a good deal of MUDs, the vision is probably something like "expansive multi-player world of fantasy adventure." Seriously. That is an EXCELLENT game vision. One of the best examples you can give. Not limiting in the slightest, and yet it still drives every following decision you make! That is what the game vision is all about.

Your game concept, not the vision, is where you lay out your plans for building the actual game. Namely, how exactly are you going to deliver on a world of fantasy adventure. You need monsters and combat – add that to the concept. You need exploration of lost cities and undiscovered mysterious lands – toss it into the concept. Your concept is where you differentiate your game from all the other multi-player fantasy adventure games. Maybe you have a novel idea for group-based combat in a text game. That goes in your concept, NOT your vision. Maybe you have ideas for the world you want to build, its history, and the kinds of experiences the players will encounter in the world… again, that goes in the game concept, not the game vision. You know that you want to focus more on combat than exploration? That still supports the vision just fine, and it goes into the concept. You want an economy driven by players? Concept. High amounts of magic? Concept. And so on.

All those bullet-point feature lists that you have in your head are what you put in the concept. The vision is your motivation for having a concept at all.



Nothing I've brought up has anything to do with deadlines, other than the arguing-forever thing. That part of game development galls into the team management areas. Totally unrelated to game vision, concept, features, or fun, of course.

You are totally wrong if you think a hobby project is immune to the need of proper team management, though. The ways you manage the team are totally different than the pro game world, sure, and I never said otherwise. Letting two developers argue endlessly over features is just flat out stupid no matter how you look at it. All you are doing is wasting the other devs time, potentially driving them away from the project, and letting bad blood build up between the two developers arguing. Maybe picking one idea is going to drive one of the two developers away… but if you've got two guys who can't work together, you're going to have to get to that point eventually anyway. Why wait?

Taking the time to debate features is not a waste… not at all. Arguing about two features with no end in sight is nothing but waste. At some point, a decision must be made. If waiting two months isn't going to change anything, don't wait two months. Just make the decision now and move on.



That's fine. That still falls 100% under every point I've made. You have a vision for a game. You have a concept for a game. You throw out the features your little group of friends don't want, you focus on the features they do want. Maybe those features aren't popular with 99.9999% of the MUD playing populace… but they don't have to be. If your proposed features don't please the player base you're aiming for, though, then you do have a problem. If you're making a game for friends, your friends only like sci-fi, your game vision is "a sci-fi game for my friends," you don't go adding dragon-riding wizards. If the concept you're working on is a "Star Wars like space opera focused on interstellar exploration with space ships and robots using a semi-turn-based combat resolution system allowing players to explore at their own pace," then you don't go adding mini puzzles that none of the players are interested in. However, if it turns out the players don't like robots, you are free to modify your game concept to remove robots, and your game vision is left untouched – in fact, modifying the game concept in this case would actually bring the final game closer in line with the vision! :)

As a further point to KaVir I should have brought up, we actually DO use these exact same principles (and even a lot or professional team management techniques) in our non-pro, hobbyist games. DigiPen student projects practically dominate almost every independent and hobbyist game competition there is, including both the IGF, IGC, and now PAX as well, and they're all done using the strategies, tips, and techniques that the professional game industry uses.

Take a look at Igneous (http://www.igneousgame.com/index.html). The game vision was "fire and explosions." The original game concept was going to be a bridge-running escape from the volcano Indiana-Jones kind of thing. Doesn't look _anything_ like that now, does it? And yet, it's definitely all about fire and explosions. It cleaned up at PAX '10. It was developed by 4 students, none of whom had ever written a line of code before 3 years ago. It was originally a school project with a deadline, yes, but that ended last year – it's now just a hobby project the students are still working on purely for their own amusement independent of the school or any deadlines.

They are probably using the Core Protocols (http://www.mccarthyshow.com/) for team management, which among other things includes rules ("protocols") for dealing with the situation where two developers can't agree on something. Instead of waiving hands, calling it a hobby, wasting three months and letting the team members get pissed off at each other until the project dies, they resolve issues they can't agree on immediately and move on to getting stuff done. Which – for a hobby project – is most important of all, because a hobby project is only worked on when its fun, and working on the project is far, far, far more fun than just arguing about it endlessly. Arguing kills projects, it doesn't help them. :)

Features can be very much impacted by deadlines, and to a lesser extent so can the concept - and even the fun, if you misjudge the timescales badly enough.

It's not at all uncommon for commercial projects to drop features in order to reach their release dates, regardless of whether they're in the games industry, medical industry, telecoms industry, etc. But hobby muds? They don't have the same sort of pressure, and they can far more easily afford delays.


Not at all - only that it isn't the same as a commercial project. As I said in my previous post, "Developing a hobby mud is a labour of love, and IMO motivation is your most important resource."


Which would be fine if you were talking about a single bottleneck. But designing a mud involves thousands of decisions. And who is going to "just make the decision" each time, when you've multiple people working on the project?

The solution to this, IMO, is for a single person to have the final say on all matters. This approach has its own drawbacks, but I've found it better than the alternative (and I've tried both).


Adapting the product based on customer feedback is hardly an uncommon strategy though - I use the exact same approach developing software in the medical industry, talking with surgeons to find out what they do and don't like, asking their views on current features, etc.

I'd just like to add another problem that results from "incomplete" designs. I regularly start and abandon mud projects. This is probably related to the fact that I keep trying to use smaug as a basis despite the fact that I loathe the diku license. Anyway, I'll end up coding furiously for several months at a time. One of the worst "problems" I've ever had is when I sit down to implement something that requires a design decision. I'm too much of a perfectionist to just pick one and run with it, meaning my weeks of incessant coding is forced to a total stop while I obsess over the issue in question. On more than one occasion, stopping to resolve a design decision in this way has kept me from a project long enough for me to lose interest entirely. I assume this is even worse when you have an actual team working with you.

For a hobby project, motivation is your currency. It's harder to acquire and easier to spend than actual money. With that in mind, I'd like to share something I read in the Linux kernel docs one day. I was reading random textfiles in /usr/src/linux/Documentation (I have no idea why), and I stumbled on a textfile describing how to succeed as a project leader. The main point I remember was basically that when deciding what to implement, you should try to implement only things that are reversible. If you try it and it doesn't work, and it's reversible, no harm has been done. With that philosophy and a habit of testing potential possibilities, it might be easier to hack your way through a project without writing up a 900 page design paper, which I'm sure most people aren't fond of. Designing things is my main joy in life, and I absolutely loathe writing design documents.

That said, though, implementation should still proceed based on your overall "vision" or "design", otherwise you'll probably just run around in circles.

Which isn't a topic I've brought up. You're arguing against things that I've never argued for. :)

In any project, you have to measure features against the feasibility of implementation. Sometimes that's just a matter of "can I actually do this or not." Sometimes it is "can I do this by X date or not." I explicitly stated that hobby projects don't have the deadline issue though, so I'm not sure why you keep bringing it up.



Definitely. That in part is where the vision comes in – it is, at some level, a core part of your motivation. If you're not into fantasy adventure, your MUD will reflect that fact. A vision that you really believe in is one you can work on with all your heart in it. :)



Most of which are pretty easy to make once the pros and cons are weighed out. Discussion and brainstorming is not the same as arguing endlessly when two parties have two sets of mutually exclusive points.

At the end of the day, if you've got one guy saying "goblins should be everwhere," another developer saying, "goblins are cliche and shouldn't exist," and then 4 devs who don't really care one way or the other, you need a way to resolve it. Doesn't matter how, at some point, it needs to be resolved. Might as well do it now rather than later if you know nothing is going to change by waiting.



Something the project should have laid out from the very very beginning. Agian, it's a team management issue, not so much a game design issue, though. A hobby project with one developer doesn't have that problem at all, but he still has the same game design workflow. ;)

Check out the McCarthy Core Protocols. I'm very new to them, but they really do seem to work. They're used both by the tiny little 2-4 person student and hobby teams as well as the massive 100-developer teams, and I've had a lot of people who've been using them for some time swear by them. best part is, they're kind of like a do-it-yourself set for managing teams. You don't need to have all developers learn the whole set of protocols; you can just say that you're using the Proposal protocol for making decisions if that's all you feel the team make-up needs.

Here's an interesting story from Microsoft's Visual C group (which went on to found the McCarthy group, btw) from back in the old days when Visual Studio was still considered crap, Borland was king of the Windows IDE world, and Microsoft was considering shutting down the whole Visual Studio product line. They hadn't yet come up with the Core Protocols and they were experimenting with how to get 70 developers to agree on _anything_. One group wanted to approach a problem one way, another group wanted to approach the problem another way, and they could not come to an agreement after discussing all the pros and cons.

How did they pick the winner? They brought in 70 drums, and the person who could rum the loudest would get to choose the solution. Seriously. They did that. When you step back you realize that's really just a funny way of saying "whoever was the most passionate about their solution was right," but it was done in a quantifiable way. They only did that once (they were experimenting with all kinds of different techniques, and that was just one experiment), but they did quite a few other "weird" things that worked out quite well.

The point is that it _doesn't matter_ how you pick who is right. Because it doesn't matter who is right. If you've got two solutions to a problem where there just obviously isn't a clear winner, just freaking pick. Pick however you want. Flip a coin. Have a group vote. Whatever. Just pick. The chances of a solution picking itself is pretty much zero. :)

… which brings up another good rule. Bias towards action instead of planning. You know plans will change. Spending a month documenting every last little detail of a game is silly because it's pretty much guaranteed that once you get rolling you're going to have to change the plan. Don't over design from the start. Get the core key points down, and then _start coding_. Even if it's just a prototype. If you're unsure which of two solutions are best, try whipping up a couple prototypes. If you've got two developers arguing about something and it won't take too terribly long, tell them to both go do their version and show the team their results. Actually writing code will provide a lot of answers that you just can't possibly hash out on paper. (There is a line here, of ocurse – just jumping straight into coding with no plan doesn't work, obviously.) Plan as much as you can, but when the planning gets in the way or hits a wall, jump into the code and blast through it. If nothing else, it's a lot easier to get a team to agree on your solution if you've already got it written and can show how well it works… or easier to get you to realize you're wrong when you realize your solution kind of sucks after implementing it. ;)

That's one reason I LOVE git over any other SCM, and why all projects should have one. You absolutely positively need to let developers easily create experimentation branches. Subversion sucks so hard because of what a pain in the ass it is to merge and update branches (at least pre-1.5, anyways), and not using any SCM is just insane in this day and age. Even if you're coding all by yourself, using git lets you hack on a couple different experiments when the mood hits while being able to work on the mainline during your serious coding sessions, and lets you merge and diff your changes easily. (That's not directed at you specifically KaVir, I'm sure you know all about SCM already.)



I generally agree with you there. I'm a fan of the "benevolent dictator" approach to management.

It's worth noting that a dictator can still use things like the Core Protocols (or whatever other team management techniques you prefer) to resolve conflicts. It's a help for nothing else in that it removes the chance of developers feeling that the leader is being preferential in how he selects resolutions to conflicts. It can also help get unbiased decisions when the leader himself can't come to terms with another developer without pulling the "I'm in charge so screw off, I win" card.

When a team gets large enough it's also key that the leader know how to delegate, too. Even in smaller teams it can be useful to appoint someone with the appropriate skill and experience to resolve technical disputes while letting someone with more interest deal with story and game world disputes, among other things. Large enough projects break into totally separate groups in some cases, but I'm not sure I agree with that approach. Putting a wall between developers is a lazy man's approach to team management, IMO.



Of course. I was just pointing out an example of how the entire game concept can change while the game vision does not change at all. :)

For software like what you work on professionally, the vision is probably a lot more boring, but just as important. I'm sure your guys' vision is something like "reliable, safe, powerful software for medical professionals," or something along those lines. The company motto, the product division motto, etc. The vision is still there, even if nobody in your company is actively acknowledging it. :) The best developers are your company are probably the ones who believe in that vision whole heartedly, and the worst are probably the ones who don't care about medical software at all and drag ass. You can probably think of people in both categories at your work. ;)

Elanthis, you are the current holder of the Hades_Kane_Epic_Post_Award.

These new so-called distributed version control systems are marvelous for this kind of thing. Other options are bzr, hg, and darcs. I've used bzr, git and hg myself, in order of how much I've used them. bzr is slower than git but its syntax is easier to deal with IMO.

I either thank you kindly very much or wish for you to go screw yourself with a rubber hose… whichever is the appropriate response.



Yeah, they all pretty much get the job done. It saddens me deeply that Perforce is still the tool of choice in the corporate world and that the only tool even making noticeable inroads against it is Subversion. I don't even care if it's really a distributed SCM though, so long as it makes branching and merging super easy and tolerably fast… not like Subversion where you branch and then merging trunk in requires you to manually dig through commit logs to find specific revision number ranges to merge, and then merging back into trunk requires a different set of revision number ranges to do the merge, and where the half-assed merge tracking they added only kind of works sometimes, causes problems in other times, and actually leads some projects to requiring massive property surgery after a merge to clean up the cruft. Subversion's design was very simple, which is good (simple is always better), but they didn't think through what they were designing at all. git is even simpler than Subversion and yet works far, far better, because it was designed to be a simple source control system instead of a simple versioned file storage system. … another case of vision (or lack there of) defining a project. :)

Quoting for emphasis (I'd quote Kavir as well, but.. I'm lazy. :devil:) I don't know if it's been mentioned yet but the enjoyment factor is important with hobby projects as well. Don't do something that you don't enjoy making or won't enjoy playing when it's finished*.

*There's not really such a thing as a completed MUD! There's always something to do IMO. :cyclops:

Considering the quality and excellent information stored in your (and everyone elses for that matter) posts in this thread, I'd take it as a compliment! I've been reading and re-reading this thread over and over to pound some of these ideas in my head and I think it's working! This thread has been a large inspiration for some of the additions I've done lately (linked to such statements as listen to the players/userbase!)

My comment was in reference to your statement "Nothing I've brought up has anything to do with deadlines, other than the arguing-forever thing. That part of game development galls into the team management areas. Totally unrelated to game vision, concept, features, or fun, of course." I interpretted that as saying that deadlines are unrelated to features, etc, and that's what I was responding to (but even if it's not what you meant, I still think the point is worth reiterating in general for the point of discussion).

The point I was making earlier is that a hobby mud (in comparison to a commercial video game) doesn't have to deal with the same budget and timescale pressures, nor does it have paid staff willing to work around the clock to meet deadlines. This lack of external pressure (and lower internal priority) requires a very different approach to project management, and this will be reflected in every part of the game design, including the vision, concept, features and even (the highly subjective) fun.

A hobby mud developer's priorities will be very different to those of a commercial project, and as such I don't think it pays to follow the advice of the commercial video games industry too closely - listen to what they've got to say, sure, but I think it's well worth keeping in mind that hobby muds are not part of their industry, and the reasons behind many of their 'rules' simply don't exist for us (and many of the concepts that are useful for us could just as easily be taken from other software industries).

The people I'd consider 'pros' in our field would be people like Richard Bartle and Raph Koster, and I think their views are far more valuable to us than those of regular video game developers.


Emphasis mine. I think it's worth stressing (in general, not specifically to you) that that really is just a part of it, and IMO the easy part. Getting started is easy - everyone and and their dog can start working on a mud. But keeping yourself (and your staff) motivated, that's the really hard part, and I think is the main reason why so many muds fail.


The problem isn't picking a solution. It's picking a solution that everyone is happy with. The more compromises you make, the more you drift away from what you enjoy, and the harder it is to keep motivated. If you end up with an overall design that none of the team are particularly enthusiastic about, it's pretty safe to assume that the game will never see the light of day. The same obviously wouldn't be true for a commercial game with paid developers.


Not especially, actually. People care more about financial incentives (pay rises, bonuses, etc) and personal development (training courses, promotions, and anything else that looks good on the CV). Having interesting and challenging work is always a plus, but that's true of all industries, and I don't personally know of any developers who would write medical software purely for fun.

Well, that's true - in the same sort of way that it's true that water is wet, the Pope is a catholic, a cloudless sky during the day is usually blue, and ursine carnivores excrete faecal matter in forested areas; it's sufficiently self-evident that it's redundant to say it! You might as well point out that a game needs to have gameplay. :smile:

But, more importantly, that's not what you were saying in your previous post. The statement you made then (and that I was disagreeing with) is the suggestion that a game vision should only be a few words long:
I disagree about the usefulness of having a vision so limited it can be condensed down to just a few words.


I don't want to risk dragging the thread too far off-topic by talking too much about movies, but I reiterate what I said in my previous post: Die Hard is a notable exception to a general rule. The biggest problem in Hollywood for the past 15 years has been that films are based on ideas which aren't substantial enough to support them. I've long ago lost count of the number of movies I've come out of saying "well, that would have made quite a good thirty-minute short, but there simply weren't enough ideas in the script to make a feature film". The problem is that people in the industry require films to be something you can condense down into 10 words; and, as a rule, films that can be condensed down into 10 words are films I don't enjoy watching.

Die Hard, as I say, is an honourable exception to that rule; but even then, what makes the movie good is the elements in it that can't be condensed down in that way. It's not good because it's "a fast-paced action film". Fast-paced action films are a dime a dozen in Hollywood these days, and they're nearly all absolutely terrible. Why? Because the makers are under the impression that so long as the partial-sentence vision is there, the film is worth making; and we end up with a never-ending series of dire, boring, mindless action movies that the world would be better off without. What makes Die Hard a good film are things like the fact that Alan Rickman is an extremely charismatic actor, the fact that both hero and villain are clever rather than merely physically vigorous, and that the conflict between them is as much a battle of wits between evenly-matched opponents as it is a physical struggle.

And, as I said earlier, most of the films that I like are films that are too complicated to condense into a single sentence: I enjoyed Adaptation and Amlie; I did not enjoy Home Aloneor Mousehunt. The problem with the latter two movies is precisely that they canreasonably be summed up in one sentence. An idea good enough to hang a whole movie on is almost certainly going to be too big to fit into a one-sentence "vision".

I think much the same applies to computer games. Again, there are exceptions: "be the bat man" is certainly a very good game concept which (as it happens) can be condensed down small; but again, that's an exception; and, even there, the reason why it can be condensed down to that level is because the form of words you're using to describe the concept is highly abbreviated, and makes substantial use of knowledge the reader already possesses before looking at the vision statement. Imagine you didn't know who Batman is - how many words would it then take to give you any sort of impression of the game?

Again, the sort of games I tend to enjoy are games that can't easily be summed up in one sentence; and those that can easily be summed up in a sentence, I tend not to like. I hatedQuake, for example. I didn't hate it because it's "a fast-paced, first-person-perspective shooter"; the reason I hated it was because it was a fast-paced, first-person-perspective shooter AND NOTHING ELSE. It was true to its vision; but precisely because the makers were too hung up on staying true to the vision, it's a game I have no wish to play.

Consider, by contrast, a game like Black & White. The original vision for that was quite complicated and multi-faceted. One part of the vision was that the player's character would be a god. Another was that the action would take place in a detailed 3D environment, within which objects would interact in a realistic fashion. Another was that the interface would be entirely free from icons, and that everything would be effected by interacting with the afore-mentioned 3D environment. Another aspect is the Creature - something that can function as your avatar, but which has independent intelligence and must be trained rather than directly controlled. Another was that the game would be strongly based on moral choices; that you would often have the freedom to choose between "black" and "white" solutions to the same problem, and that the game would assess the morality of your choices and respond accordingly. So the "vision" for Black & White was much too complex to express in a partial sentence; to express the vision you need at least a paragraph; and that, IMO, is precisely what makes the game good.

Much the same applies to, say, Deus Ex. The vision for that game involved it being a futuristic RPG, but with well-fleshed-out characters you actually cared about; with a mixture of first-person shooting action and stealth; puzzles having multiple, equally valid solutions; the ability to develop your character in meaningfully different directions; character-development choices having an immediate, tangible impact; and a back-story laced with paranoia and conspiracies. Again, if you could usefully sum up the game in one sentence, it wouldn't be nearly as good.

Or there's the original System Shock, another of my favourites. Superficially it's a shooter, but under the covers it's an RPG whose elements are so well concealed within the gameplay mechanics that many people who played it didn't realise they were playing an RPG; the main character is cybernetically enhanced to be able to directly interact with computer systems; it's a tense, claustrophobic experience with an adversary who is very clever, and who makes the struggle between you increasingly personal. All of those things are critical, fundamental elements of the game vision.

In general, a game only becomes good when you stop thinking about a half-sentence vision and start thinking about actually making a good game. The more hung up on a half-sentence "vision" you get, the lesschance there is that the game will actually be enjoyable (or at least to an audience like me).

I fear that audiences like you (and me, and most of us reading this) are a minority, though, Shasarak. As with creating a movie, the main objective of a commercial game is to make money, and simplicity appeals to a wider audience. That's why hollywood will continue to churn out cookie-cutter movies, and why Farm Town will always be more popular than any mud. That's why we'll keep having to listen to those radio friendly songs…