General MUSH Startup Advice
-
Basically, I'm interested in starting a new MUSH (non-wod, fallout-style theme) and I have a lot of questions. I've only been MUSHing for about three years but I've been playing TT for a decade or two. I have low-to-passable wiki and MUSH code knowledge but I'm very willing to learn. I've already found several websites that are helping me in that direction.
Unfortunately, many of those websites are old, outdated. Are there any good, current websites or resources available for someone willing to learn? Any resources that have helped you and that you'd like to pass on?
I have a good idea but there's a lot I still need to learn. Links, advice, and tips are very much appreciated. (i.e. I need you guys, pleeease halp.)
-
Good luck. It takes a great deal of effort, dedication, and skill in a wide range of different things-- organizing people, storytelling, software engineering, etc.
I'm... still kinda burned out on everything, so I probably can't help much on the tutorial front. My best advise is: try things and see what happens. Don't be afraid to experiment, and be damn sure you are self-motivated and confident enough to read documentation, even when it seems inapplicable or partially outdated.
-
Get help. Don't do it solo. Starting a game by yourself is an exercise in futility.
-
Code wise, I personally have found that taking apart someone else's code and reading all the related actual platform help files has always been far easier for me; you get to see it in action, and if you're a hands-on learner, that's the way to go. Generally you can't throw a rock around here without hitting code that's open for use, so that shouldn't be a problem for you.
As far as the rest of it -- ask your questions here, or message me with the sorts of things you want to know. I cannot help with the management of the site or getting that up and running, but @Glitch has a great tutorial up here.
As @Admiral said, do not do this alone. Not only do you need someone else to help with the extensive amounts of work, but you absolutely need a sounding board -- preferably two, so you can get two additional perspectives in addition to how you feel about something. Mind, I do not at all advocate approaching it in a 'we should compromise' fashion. Absolutely not. Make your decisions, but let them be made with input from others and perspectives you don't have.
There are a lot of foundational decisions that need to be made, and I highly recommend it be kept in mind for every single decision that you'll get the behavior that you reward. If you want a particular behavior from your playerbase, figure out a way to reward it.
Learn to be very clear. The job of staff is to provide the framework and tools for players to have fun within. The job of policy files is to lay out what OOC rules people have to follow, rather than just leaving it to the social contract. The job of your news files (wiki articles, whatever) in general is to lay out specifically what game you are playing, how you're playing it, and what people should be expecting playing with you. It is the best (and really, only realistic) way to communicate your vision, to make certain that everyone involved can see it.
Most games utterly fail at this, which is why there's so many problems. Nobody ever outright states: This is a game in which we will be focusing on the interpersonal drama between characters; we aren't bothering with realism, and we play fast and loose with canon. They ought to, though -- then the game is exactly what it says on the tin, and people can make educated decisions as to whether or not your place is right for them. This is an area that always involves TONS of miscommunication. Your mission, should you choose to accept it, is to make your vision so clear that everybody knows what they're getting in to.
The best resources out there are the people on this board, really. I don't know that there are many help guides out there. Amberyl's Mush Manual is actually really a helpful read. A good chunk of it is outdated and unrelated, but there is enough information there that I do recommend reading it:
http://www.groundline.net/eu-mush/mushman/
I found that link just with a search, but it does look like everything is there.
Take your time, take it slow. Don't get people hyped up too early and let them pressure you into moving forward when you're not ready.
Once you open the game, even for soft RP, kiss any thought of further game development goodbye. You will be handling day-to-day stuff so much that it will be a nightmare to continue working on any of the foundations of the game. If you then take too long to make those foundation decisions and change something that people have gotten used to, you risk alienating your playerbase in a major way. Get all the important-to-you stuff done before you open the doors to anybody but your chosen few.
http://fort.chrysalis.me/wiki/Fate's_Tithe
This is the framework of how I personally build a game. I'm no longer doing this Pern game (at least right now), but you can see how I do it. Wiki stuff means I have been able to move away from doing it with a combination of bbposts, jobs, and notepad -- it's way helpful. There are a lot of decisions that have to be made (though a lot of those on that link are specific issues that the Pern genre has, I promise most games don't have to explicitly state that PCs can't get pregnant without the consent of all involved parties OOC). What I do is make a list of what I think needs to be done. I go through and make the big sweeping decisions, write them down. Then I discuss what I feel needs to be discussed, make the rest of the decisions, make little notes. Create links with the specific items, drop more in-depth notes and discussions there, things to consider/read, places to look, whatever. Then you just start writing the files to fill in the holes and take it from framework-sketch to actual news files/wiki articles.
Last tip: Bad staff is worse than no staff. Always. It's tempting to say 'oh, they're really active, that outweighs (this negative quality)'. It does not. Ever. Down the road you will have WAY more work to do than you will have slowly addressing all the things yourself. Bad staff poison the well, and there's very rarely any coming back from that no matter how awesome you personally are.
-
@Chime Thankfully, I have some good people helping me along.
I'm still learning most things by trail and error, though. Frustrating at times, but incredibly rewarding.@Sunny Thank you for the links! I'm not even that far yet, but they'll come in handy later. I'm still working out the kinks in setting/background/etc, and trying to get it up enough to let me start tweaking code.
This actually brings me to another question. I was planning on using Rhost since it's open source, but is there something else folks would recommend over it? And if not, is there anyone out there who can give me a little help/advice? Everything seems to have compiled correctly, I set everything as per the host's instructions. and I spent two nights reading tutorials and guides, yet I'm still having problems with the Port/connecting.
I'll admit I'm something of a newbie when it comes to server-stuff and advanced code, but I have basic code knowledge, as well as enthusiasm and time to learn, so why not? You have to start somewhere.
That said, sorry if I ask stupid questions.I appreciate any help. If not, I hope you gain some entertainment from my bumbling.
-
@Thisnameistaken A majority of the people on these forums use TinyMUX, which is similarly open source, but we do have some PennMUSH (also open source) and Rhost folks lurking about. Some of your basic setup questions have answers that can be found in our How-To category. Most of that info is TinyMUX based, but you might find hints in there that could lead to solutions for you.
-
Personally, I code in, and recommend, Rhost. All my prior games have used it, and I moved from MUX to that for various security and feature reasons. Not that MUX is bad, mind you!
After a lot of my recommendations and feature requests were integrated into the codebase, and then some, I doubt I'd ever recommend anything else to anyone. And I mean that from a coder's standpoint. When you can @cluster objects and use them as a single object, you change the game on data warehousing. Currently examining this approach for my new bulletin board system I'm writing.
As for game-running, yeah, it takes a lot of skillsets. Most people (none?) can be good at everything AND have the time to run a game, so it is awesome that you have started a small team of people to help with the vision. I too can say that communication and transparency of theme is probably the best starting advice. Always be willing to rewrite and tweak your info files as your players ask clarification questions. On my game, I plan/want to have Q&A sessions up front and solicit feedback as we get started.
Sent you a chat to help you get your tech issues sorted out.
