Seeking DIY Advice

Phase Face

Hello!

Periodically, I'm struck by a desire to try making my own MU*, figuring that the only way to be sure I've got a shot at seeing some of the kinds of things I'd like to see in games is to do it myself. I'm in another of those periods, and - like a fool - I'd really like to give it a shot this time, if only to try and exorcise myself of it.

There's a small problem (besides a lack of server space, coding knowledge, and admin team), however: while I've played enough MU*s to have an idea of what goes into constructing one, it's tough for me to break those elements down into some sort of coherent plan of attack due to just how many there are, which makes it tough to do anything at all, as - absent a plan - I'm liable to just kind of flit wherever my attention takes me.

So I want to beseech the MUS community for advice with a question: What are the things one needs to think about, conceive, construct, and so forth to get a solidly functional game off the ground? I don't mean things like 'a server', or 'a codebase', the truly technical details; I more mean 'what kinds of policies do I need to think about?' 'What considerations should I be making WRT to grid design?' That kind of thing.

For reference, what I'm thinking of would involve existing properties with feature characters. I don't think I'm looking to include coded combat or significant coded secondary systems, though that's admittedly in no small part because I've not had any solid inspiration for any. Right now, at least, I would probably just use AresMUSH for the convenient web portal and relatively accessible entry barrier.

Thank you in advance! And, I suppose, apologies, as well, if this is entirely too vague/broad of a question to be useful.

Derp

@phase-face

Like all elephants, you eat it one bite at a time.

First, come up with your theme. What game do you want to play? What sorts of things do you want to create? What sounds fun to you?

Then, decide what system works best to bring that into fruition. Is it something that can fit well into something that already exists? Is it something that would require a pure homebrew system? That's an important choice. You have to balance what you want with what you can realistically get your hands on.

Once those two things are in place, it's just a matter of figuring out what commands you'll need to support that, and creating them. Some MU platforms have more readily available code than others. Some have more willing help than readily available code.

I would personally recommend Ares. If you're going to have to learn to code something from scratch, Ruby is a good code to learn, and it comes pre-packaged with a lot of the stuff that you would have to hunt down elsewhere. FS3 is also a fairly flexible system, assuming that you don't need much in the way of heavily coded magic. It can handle quite a few situations, and I'm having fun with it on a few games. Then, your overhead is pretty straightforward.

But all of this really starts at the top and works its way down, threading between those steps as necessary to balance an ideal with a reality.

Sunny

@phase-face

Continuity/retcons
Consent / FTB policies
Discipline policies
Character approval requirements
Censorship of public spaces (IC/OOC)
Chain of Command / Appeals of decisions, any attendant processes
What do you expect your players to be playing?
Rights / Expectations / Responsibilities, both for staff and players
System
Purpose/philosophy of game
Game's pre-game-on history
PRPs
Advancement / player goals for character
Realtime vs asynch vs both RP support
Channels

..not exhaustive, this is from an old brainstorming list. Trying to find my 'Things to do when opening a mush' checklist but I have a...lot...of folders on dropbox.

faraday

I agree with @Derp that you have to start with your basic goal. Not just a setting (though that's important too), but a vision.

I think that a TV series is a good analogy for a MUSH. Start with the elevator pitch that you would use to "sell" the game to execs - only in this case it's selling to prospective players.

Then make decisions about your cast. Not specific characters (unless it's going to be a roster game), but general roles and focus. Think about things like factions, PVP, organization.

Then make decisions about the story. Unless you're going for a full-sandbox mode, you probably want to have at least a "season" worth of ideas sketched out. Think about what the characters are going to do between events, and what systems/structures you need in place to support those things.

Then think about the OOC atmosphere. How will the players interact with each other? This is where things like consent, PVP, plot guidelines, etc. come in. Also, are you looking for a more narrative free-form feel, or a more crunchy immersive feel.

Only when you've answered all of the above should you make any decisions on server tech and code. Ares has a lot out of the box and is easy to set up, but it's not a good fit for every game. Nor is FS3. So you should pick the tech that fits your vision. It might make a lot more work for you getting the place started, but you'll save yourselves headaches in the long run.

Sunny

How will people find RP?

What can you do to encourage/help with that?

What do you expect people to RP?

What can you do to support that?

How strict will you be about your theme?

How will you enforce that?

What level of safety do you feel it is your responsibility to provide to your players?

How will you communicate that to them?
How will you enforce that?

Does your planned IP need permission, or is blanket permission out there?

Do you care?
What are the consequences of the above answer, and how will you address them?

What is the role you feel a grid has in roleplay?

How do you best execute that?

bear_necessities

What are you going to do to make people want to RP with one another and be open to RPing with people outside of their comfort circle?

How many people are you able to sustain GMing for? What are you going to do if your game gets 3-5x that? What are you going to do if the inverse happens and you get 3-5x less?

Are you going to allow STs/player run plots? What tools are you going to give STs, how involved are you going to be, and can you handle the level of involvement you expect to have?

Finally, how passionate are you about actually running a game, and how passionate are you about running THIS game that you're building? That goes a long way, I think, in the "buy in" that people need to play there.

Sunny

My definitions are not everyone's definitions, but these provide a framework for things you need to address, for storytelling:

Theme: The overarching "feeling" element that ties all of your game's stories together -- hope, humanity becoming more, exploration, reflection -- whatever, this is short and simple and a bite sized marketing blurb. My game is about INSERT THEME HERE. Mind, this is NOT where you say 'superheroes'. I mean it could be, but superheroes as a /theme/ -- instead of a vehicle to get to that theme -- is not what I'd recommend

Metaplot: The background high-level long-term plot that plods along that provides a Background Reason for your other plots; the plot that creates the plots you actually run; the 'history', behind the scenes, what REALLY happened; the Big Picture -- this is the glue that holds your stories together that you don't interact with very much -- the Antediluvian sleeping under your city, the origin of the Hellmouth, the fact that it's actually the strain of grain that they're being fed on the space station that's giving everybody these powers...this is the story behind the story.

Chapter/Season Plots: These are the active day to day staff run "what is happening on this game" that your players can and should be able to directly impact. They should have a start, a middle, and an end. They should have LOTS of hooks for people to run PRPs from. They should give people stuff to RP about. So when you're deciding on your chapter/season plot, you REALLY need to consider beyond the story itself:

what are my hooks for PRPs?
what will people RP about, in relation to this plot?
what RP will this plot create when I am not around?
What impacts will this plot have on peoples' day to day RP?
** Where are the pain points? What can I do about them? What will stall people's RP about this?

DO NOT SEPARATE YOUR PLAYERBASE IN YOUR CHAPTER PLOT -- THEY TAKE TOO LONG TO RESOLVE

Episodic Plots: This is what makes the game go round. This is all the little things that get run weekly, from parties to monster of the week to scheduled events that feed into the above types. They are typically self contained, and keep people entertained while the Chapter/Season gives them things to RP about. You want to make these REALLY easy to run -- give people LOTS of easy hooks into your Chapter, and plenty of info with which to run them. You ALSO want to make sure it's really clear what they CAN'T do, because people always have an easier time when they know what their boundaries are.

Apos

@phase-face It might be helpful to think of what kind of role you see or other staffers filling, since that can kind of suggest the game you want. A head storyteller, where you are creating plot everyone can join in? An arbiter, where people are all making their own stories and you help curate them? And so on.

I think trying to think of how you want to spend your time running your game can help shape the game you want to create and how it plays.

Pacha

@phase-face

I can say that in my (limited) experience Ares has been an absolute godsend. It costs around a Starbucks a month to run if you use the recommended provider, and as long as you are willing to read and carefully follow instructions, it can be done with zero knowledge of coding. The FS3 system was really customisable, and it is relatively simple to include (or not) the combat module. I went from being sort of sceptical about Ares to somewhat evangelical about it as I was working through and getting everything as I wanted it. Whenever I did get stuck, Faraday was always extremely helpful and supportive.

Ganymede

@derp

Dude, when did you start eating elephants?

I concur with everything here but add that I believe the most important first step is envisioning what you as a player would want to do within the game’s setting. In short: what am I the player to do here?

That will help you choose if you need a simple or complex stat system, which will help you pick which platform to start with, which is where I would start when it comes to cobbling together the code.

Derp

@ganymede said in Seeking DIY Advice:

Dude, when did you start eating elephants?

Look, some people like raw fish and rice, some people like snails, some people like elephants. Don't judge.

Ganymede

@derp

Racist

Anyhow, all good ideas. My point is or was that code is the key.

krmbm

@ganymede said in Seeking DIY Advice:

In short: what am I the player to do here?

This. A lot of this.

It's all well and good to have a great idea!!! But it's harder than you might think to make that idea interactive. Making a world people can look at is easy; making a world people can play with is hard.

Figure out how characters can touch the theme, not just look at it. Super important.

Carma

This post is deleted!

Griatch

@phase-face

Whereas you ask some good specific questions about design, I would like to be a little more generic and add that the main thing for any hobby project is to get to something playable before your determination runs out or your hard drive crashes.

In a hobby/free-time-driven game development process, 99.99% of good ideas never lead to a game people can actually play. People in this thread have good specific advice - you should heed those you like. But I'd suggest not covering all bases immediately - planning is fine but you need to eventually do something, create something you can show off. A sort of save-point you can continue from should the unforeseen happen and you have to take a break from your project.

Keep your grand plans in mind but strip most of them away for your first version - you will often find even 'must-have' features are not so must-have once you realize other things are not yet in place. The 'perpetual beta' is a tried and true concept for a reason; not assuming (indeed knowing) that your first few versions will be incomplete and imperfect can be quite liberating and allow you to get something out sooner.