16 Oct, 2009, Davion wrote in the 1st comment:
Votes: 0
I've had an idea for a game… well, not really a game. More a general theme/setting running through my brain for awhile now, and I'm considering starting a new MUD project.

Here is my dilemma. Whenever I work on a MUD project, I seem to focus my energy on adding system after system, feature after feature, and what I end up with is a MUD that does a whole bunch of stuff! But doesn't play anything beyond doing cool stuff. Before I even write a single line of code on this project I'm wondering, where do you start when it comes to planning out a game? How do you stay on track with advancing game play instead of game features?
16 Oct, 2009, sam.j.brown wrote in the 2nd comment:
Votes: 0
I would start by clearly defining in a couple of paragraphs what your game is, its goals and how it should play. You can then use this as a reference point to question everything that you may like to add to the game, along the lines of does feature X fit in with my stated goals of producing Y type of game. You can do this for every idea that is ever presented and keep a consistent and coherent whole.

I think this is where just about all muds go wrong and why many feel like an amalgamation of a lot of great ideas instead of a game that shows coherent logic with its design. I think some of this may be due to starting out with stock codebases, where many design decisions have been made by other people for a totally different game.
16 Oct, 2009, Omega wrote in the 3rd comment:
Votes: 0
My honest opinion on this is, start by creating your theme.

So futuristic, post apoc.. medieval, things like that. Always a good place to start.

After that is decided, tell yourself, if you want races, or not, classes or not.

As those are big game dynamics to deal with.

Then a base feature-set: example

arena
freeze tag
unlimited directions (so you can in-turn create 'tower' as a exit if you wanted)
etc… etc..

things like that.

Then you have to determine if you are going to use skills/spells, or base things off of equipment.
Example: if wielding this weapon, character gets x skill at y%. Which may be considered a feature
but I think of this as a game dynamic.

So essentially, create a list of core features (things required to play the mud)

And then create a list of extra's, things that aren't required, but are fun.

Remember, the core features should fit with your theme/story, which is always the first place to start.

Last thing you want is nukes in a dinosaur themed mud ;)

As for staying on track. Don't stray from the list of features set down in your initial core setup.
When all those features are completed, then expand on the existing core features. do this *BEFORE* expanding
the non-required features.

Make the core of the game important to the player, they don't need freeze-tag and CTF and a dozen other 'features'
because they overwhelm the rest of the game. I see allot of muds boasting dozens of these little systems,
arena's, freezetag, CTF, etc, etc, all that do nothing but give you trivia/quest points, which can only buy a select set
of items. The point is, they clutter up the game, players while they tend to like seeing a robust feature-set on a game
they often do not get the opportunity to appropriatly play within those features, due to lack of players, and as such
it just becomes a moot point.

But say you want to have in your mud, a series of dwarves that dig/tunnel, creating a 'virtual' maze if you will, at random,
and it fits in with your games story, (the dwarves of some mountain that like to dig… etc. etc…) then that becomes a core
feature-set, as it directly affects the overall game story.

Remember, just because you can write fancy systems, doesn't mean you should. Remember, the more you write, the more
you have to debug. Case and point, Sandstorm was 500,000+ lines of code, insane to debug the smallest of feature changes,
and in-turn, I shut it down because it was just too much to man-handle. Dozens of features, great gameplay, but nobody could
really get to the fun stuff due to all the 'features' eventually getting in their way.

Oh, and one last bit, if your going to dev for the sake of creating a basic tech-demo, features for the sake of saying you have them.
such as MySQL saving/loading, while good, are un-necessary. Don't overload the core engine with things like that, just to say you have them.

Thats my speal. Enjoy.
16 Oct, 2009, KaVir wrote in the 4th comment:
Votes: 0
I have the same difficulty. It can be really hard to overcome "cool feature" syndrome and stick to adding less interesting (but more important) things, but if you don't the mud can end up with no real direction.

Have you included a list of short- and long-term player objectives in your design? I find it's much easier to develop features that add to the gameplay if I've got a clear goal in mind.
16 Oct, 2009, Igabod wrote in the 5th comment:
Votes: 0
@Kavir I've played your mud and, though it wasn't quite my style of mud, it had the looks of something that had a LOT of planning put into it before the actual coding began. I know the combat system is based off of your gladiator pits entry to the mudmagic competition, but the rest of your game appeared to have been planned out in entirety first. I could be completely wrong and you're just good at making it look like you planned it out, but if I'm not wrong then perhaps you could tell us how you went about starting on GW2.
16 Oct, 2009, shasarak wrote in the 6th comment:
Votes: 0
Davion said:
Here is my dilemma. Whenever I work on a MUD project, I seem to focus my energy on adding system after system, feature after feature, and what I end up with is a MUD that does a whole bunch of stuff! But doesn't play anything beyond doing cool stuff. Before I even write a single line of code on this project I'm wondering, where do you start when it comes to planning out a game? How do you stay on track with advancing game play instead of game features?
The fact that you're able to ask that question suggests to me that you're headed in the right direction this time. :smile:

It's really just a question of not putting the cart before the horse. If you're considering adding, say, magic potions to a MUD, the temptation is to say "right, I want to add potions to my MUD; how should they work?" What you should be asking instead are two questions. First ask "what is the actual impact on gameplaythat I want my new feature to have?" Once you've decided that, then ask "are potions an effective way to achieve my desired gameplay goal?" The answer to your second question may very well be "no". Always think about the impact and effect first, then work out the best way to achieve it, rather than starting by thinking about a mechanism and then worrying about the impact it has.

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?
16 Oct, 2009, KaVir wrote in the 7th comment:
Votes: 0
But did you ever play Last City, Igabod? That was my previous mud, once known as God Wars, which I decided should be more WoD-like. There was no proper design and no clear direction, I just kept tweaking and changing things, and after several years of work I had some pretty cool features (which admittedly did fit together very well) - but no actual "game" that people could really play.

For GW2 I did actually write up a design document beforehand. To be honest, most of the features were added later and weren't part of the original design - but because I had a very good overview of how the game should work, I was able to tie the features in with the design. Sometimes I'd come up with ideas for features I really wanted to develop, but if I couldn't find a way to tie them in with the original design, I wouldn't let myself add them.

Note that my combat system wasn't part of the original Gladiator Pits (my 16K entry), but of Gladiator Pits II - and that was actually intended to serve as a prototype for the combat system, so that I could make sure it was viable before the rest of the GW2 design was finalised. So much of the design hinged on the combat system that I felt I needed to see it in action before committing myself.
16 Oct, 2009, Igabod wrote in the 8th comment:
Votes: 0
Kavir said:
But did you ever play Last City, Igabod?

I don't know if I played Last City or not, I played a bunch of different GW muds back when I was still a frequent mudder.
16 Oct, 2009, Sandi wrote in the 9th comment:
Votes: 0
I'm still on my first coffee, so this may not be that coherent. :rolleyes:

For a good overview of game design, I recommend Raph Koster's work. A theory of Fun

I think a lot of your answers are embedded in your OP. A lot of systems are slapped on, and distracting. I think the history of MUDs displays a constant advance, each fixing the problems of the one before. The real problem is a lack of understanding of the causes. So my advice is study the earlier games, and see why various systems were put in place. "Alignment", for example, is a clever way of keeping people from willy-nilly slaughtering anything they come across. It worked until Builders started making Good and Evil areas.

I tend to wax poetic about Building, it is the world we play in, and far more important than the code that manipulates it, but a game will only work as well as the Builder's understanding of the code. The other side of this is, you can only code as well as your understanding of building.

In the ROM world, there was what was known as "the gold problem". High level players were so rich, money was meaningless. Shops never had anything worthwhile, because it was deemed 'too easy' to buy things. Think about that - this entire, complex and clever system of shopkeeping rendered useless. And all sorts of answers were proposed, various attempts at controlling the "economy", and none of the coders seemed to notice that one area, Descent to Hell (30 - 50), had been edited so every mob had 5000 gold. So, know your areas. GIGO, and the areas are basically the 'input' to your code.

Mobprogs are quite fashionable, and every Builder makes these little area specific quests, often involving 'guess the verb/noun' puzzles. I detest these things, but that's beside the point. As Koster notes, we humans love to learn. We get an endorphin rush from problem solving, but only if there's a usable benefit to what we've learned. Rather than limited quests, the learning should be the mastery of game systems that provide global, long term, benefits.

But let's go back to money for a moment. First there were coins, then gold and silver and the money changer, and then gems, and finally banks. Each was a 'solution' to a 'problem' that players encountered. Sure you could go back to having just gold, which is heavy, and creates a problem to be solved, but these days, you'd probably have a hard time presenting a MUD without banks. Sadly, part of your game design has to include pandering to what players expect.

Anyway….. time for more coffee!
16 Oct, 2009, Hanaisse wrote in the 10th comment:
Votes: 0
Davion said:
Before I even write a single line of code on this project I'm wondering, where do you start when it comes to planning out a game?

You're on the right track already. Before writing a single line of code plan and design on paper. You have a theme in mind, that's a good start. I think the next logical step is asking if there is a code base out there already that would suit your theme or will you have to start bare-bones and build something up. Always keep your design in mind when making any decisions. Would it best suit different classes and races? Multiclasses? Classless? There's a million questions.

Davion said:
How do you stay on track with advancing game play instead of game features?

Ask yourself what does game play mean to you? To me there's two types of game play - typical hack 'n slash, and roleplay. Roleplaying MUD's defintely require more dedication, more background story, zones that stick with the theme and more interaction whether that be from quest mobs or staffers that can run live quests. Every little idea you have for a feature you have to put yourself in the players shoes and ask yourself does it logically fit with character development and advancement? Or is it just "cool stuff"? Take yourself out of 'coder' mode for awhile and just be Mr. Admin. What kind of experience do you want your players to have?
I'm kind of the opposite of you but we share the same problem. I'm not a coder at all. My focus is design and one of the ways I believe to achieve that is building good areas that all relate to an overall world. However I find myself getting bogged down occassionally with 'wouldn't it be nice to have this feature or that'. You'll find yourself swaying from time to time but just take a step back and force yourself to rethink.

Davion said:
I end up with is a MUD that does a whole bunch of stuff! But doesn't play anything beyond doing cool stuff.

Is that wrong? Not necessarily. I'm sure there are many people who play MUD's for the "cool stuff". Playing Trivia while whacking goblins over the head? Sure!
16 Oct, 2009, Scandum wrote in the 11th comment:
Votes: 0
Davion said:
How do you stay on track with advancing game play instead of game features?

By sticking to a barebone implementation and a strict avoidance of creating cosmetic or duplicate functionality in the beta stage of the game perhaps?
16 Oct, 2009, David Haley wrote in the 12th comment:
Votes: 0
You might like this thread, and in particular a post Nick made near the top – a very long one asking a long list of interesting questions to think about.

Not much to add to what has been said, except to summarize perhaps by saying that you should not lose track of the goal: don't let the means to the goal become the goal.
17 Oct, 2009, Tonitrus wrote in the 13th comment:
Votes: 0
I would say that, as a rule (this is a rule you should break from time to time), your game shouldn't have any features at all.

Your vision of the game should be viewed from how you want players to perceive the world you intend to create, while keeping an eye on balance issues (they won't get any easier to fix later on). Then it's a simple question of what you need to implement to create that vision. Everything else is secondary.
17 Oct, 2009, KaVir wrote in the 14th comment:
Votes: 0
Tonitrus said:
I would say that, as a rule (this is a rule you should break from time to time), your game shouldn't have any features at all.

Your vision of the game should be viewed from how you want players to perceive the world you intend to create, while keeping an eye on balance issues (they won't get any easier to fix later on). Then it's a simple question of what you need to implement to create that vision. Everything else is secondary.

Even core gameplay elements can be broken down into individual features. If they're well designed, they'll fit together seemlessly with the rest of the game, but from a development perspective it's almost always easier to build the mud one feature at a time.

Note that IEEE 829 defines the term feature as "A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)".
17 Oct, 2009, Orrin wrote in the 15th comment:
Votes: 0
I'd recommend that you set out some clear gameplay goals first and then design the systems of your game to support those goals. For example, with Maiden Desmodus my main goals were to encourage player conflict, competition and cooperation. Each game system or feature, from combat to politics to the economy was designed to work (I hope!) to promote those goals.
17 Oct, 2009, Tonitrus wrote in the 16th comment:
Votes: 0
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.
17 Oct, 2009, KaVir wrote in the 17th comment:
Votes: 0
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.
17 Oct, 2009, flumpy wrote in the 18th comment:
Votes: 0
This topic is great.. more plz.

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.

Plus, my ideas sounds kinda wacky in my head and I have no idea how to go about actually coding them. :sad:
17 Oct, 2009, KaVir wrote in the 19th comment:
Votes: 0
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…
17 Oct, 2009, Davion wrote in the 20th comment:
Votes: 0
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.
Random Picks
0.0/130