Tonitrus
Conjurer
Group: Members
Posts: 123
Joined: Jul 11, 2009
|
#16 Posted Oct 17, 2009, 11:39 am
|
What I meant to say is something more along the lines of:
Thinking about the game in terms of features is something that should happen only after you have a firm idea of the game from the perspective of theme/world/setting/et cetera. Starting from the perspective of features as features can lead to feature-itis, bloat, and inconsistency. Thinking of features as secondary to a greater goal of theme/world/playability limits this temptation and and is easier to prioritize. Of course, when I type it this way, it looks like what everyone else has said already. Oh well.
I'm sure that's probably not exactly what I meant to say either, but I've never managed to say what I mean before, and I'm not likely to start today.
|
|
|
KaVir
Wizard
Group: Members
Posts: 1,113
Joined: Jun 19, 2006
|
#17 Posted Oct 17, 2009, 12:27 pm
|
Tonitrus said:Thinking about the game in terms of features is something that should happen only after you have a firm idea of the game from the perspective of theme/world/setting/et cetera.
But those are also features.
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
|
|
KaVir
Wizard
Group: Members
Posts: 1,113
Joined: Jun 19, 2006
|
#19 Posted Oct 17, 2009, 2:10 pm
|
flumpy said:I have ideas for a game but I have no idea how to go about starting. With groovymud not yet where I want it and, er, stuff in my personal life atm, I probably will never get around to it.
When I wanted to test GW2, and there was too much unfinished to create anything decently playable, I created a spinoff mud - a really simple pure PK game. Have you considered doing something like that to test your codebase?
For some reason I've been having the strange urge lately to create a PK mud based on fish, which takes place entirely underwater. I get these urges from time to time (for different types of mud), but manage to resist - otherwise GW2 would never get anywhere...
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
Davion
Idle Hand
Group: Administrators
Posts: 1,188
Joined: May 14, 2006
|
#20 Posted Oct 17, 2009, 2:33 pm
|
Quote:This thread is probably as good a place as any to talk about your design goals. What sort of gameplay do you want your MUD to employ? What sort of experience do you want players in the game to have?
It's more along the lines of a fast passed adventure game, that promotes competition of the user base by trying to achieve similar (likely identical, if not the same one) goals but through different means. Something akin to multiple really log quests that have the same end point, but not necessarily the same result. I'm not really looking for a hack'n'slash (slaughtering the monsters). Combat would definitely be a big part of the game though. But I'd want the players to be feel pressured to do something when being attacked or attacking others. Probably by means of constant surrounding environment changes. Think top of sky scrapers.
KaVir said:For GW2 I did actually write up a design document beforehand.
Care to share this? I'm interested to see how it's setup.
|
......................... 
|
|
KaVir
Wizard
Group: Members
Posts: 1,113
Joined: Jun 19, 2006
|
#21 Posted Oct 17, 2009, 3:24 pm
|
Davion said:KaVir said:For GW2 I did actually write up a design document beforehand.
Care to share this? I'm interested to see how it's setup.
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.txt
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_second.txt
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
elanthis
Wizard
Group: Members
Posts: 760
Joined: Feb 26, 2008
|
#22 Posted Oct 17, 2009, 3:36 pm
|
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!
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
KaVir
Wizard
Group: Members
Posts: 1,113
Joined: Jun 19, 2006
|
#23 Posted Oct 17, 2009, 4:28 pm
|
Quote:5) At all stages, you should have some beefy documents with all your design plans.
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.
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
elanthis
Wizard
Group: Members
Posts: 760
Joined: Feb 26, 2008
|
#24 Posted Oct 17, 2009, 9:24 pm
|
KaVir said:
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.
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.
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
shasarak
Sorcerer
Group: Members
Posts: 273
Joined: Nov 28, 2007
|
#25 Posted Oct 18, 2009, 12:50 pm
|
elanthis said: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.
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.
|
|
|
David Haley
Wizard
Group: Members
Posts: 5,727
Joined: Jun 30, 2007
|
#26 Posted Oct 18, 2009, 3:16 pm
|
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.
elanthis said: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.
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. 
|
|
|
KaVir
Wizard
Group: Members
Posts: 1,113
Joined: Jun 19, 2006
|
#27 Posted Oct 18, 2009, 4:58 pm
|
elanthis said:You're doing something preetty wrong if you're arguing that long. :)
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.
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
elanthis
Wizard
Group: Members
Posts: 760
Joined: Feb 26, 2008
|
#28 Posted Oct 18, 2009, 5:39 pm
|
shasarak said:
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.
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.
Quote: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.
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.
Quote: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.
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.
Quote:It doesn't even really matter how popular the end product is, as long as there are enough players to make the game enjoyable.
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! :)
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
elanthis
Wizard
Group: Members
Posts: 760
Joined: Feb 26, 2008
|
#29 Posted Oct 18, 2009, 5:53 pm
|
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. :)
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
KaVir
Wizard
Group: Members
Posts: 1,113
Joined: Jun 19, 2006
|
#30 Posted Oct 18, 2009, 6:56 pm
|
elanthis said: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.
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.
elanthis said:You are totally wrong if you think a hobby project is immune to the need of proper team management, though.
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."
elanthis said: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.
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).
elanthis said: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?
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.
|
......................... KaVir at God Wars II: godwars2.org 3000 Roomless world. Manual combat. Endless possibilities.
|
|
