Space, the final galaxy far, far, away

Ok, I've left my oringal message in place from when this blog was titled Where to go from here. However, I have a working theme for my MUSH, and I'm going to use the Space Opera system to run it, so I wanted to open with a summary of my MUSH and my thoughts about it. The MUSH will be Sci-Fi based. Space Opera, the role playing game it will be based on, is rich in details and I hope to elaborate on these as time goes on. To start I'm going to work on the character creation system. I will be using Space Opera's system which, as a lot of early role playing games, is very involved. Most of the action is done in table look ups, and I'll be able to hide this inside the chargen machine. Unlike some systems from that era however, once you get past character creation the system itself is very elegant.

I'm not sure what to do about hitpoints. The mechanic exists in the Space Opera game but I don't like allowing coded character death in, what I hope will be, a role play MUSH. I played on GarouMUSH for a while and I liked their policy about character death. If I remember it correctly, characters would die only if their players wanted them to, and then, if desired, a suitable roleplay would be developed around that. I may be remembering GarouMUSH character death how I want it to be, either way that is the system I want to use. On the other side I would like to allow for a coded combat system to be used against NPCs. In this case once you hit 0 you fall unconsious and perhaps gain an injury. I'm not sure about that yet. I think playing a character with an injury is interesting. I don't want it to be seen as a punishment, more as another aspect of your character to role play. As well, in the world of Sci-Fi nothing need be permanent.

In Space Opera playing multiple characters is encouraged. You play one character for a while then he goes away to train and is gone for a few months. During that interval you play another character. I did plan on allowing multiple characters to role play with, but I will also be encouraging multiple characters through the in game trainging system.

I'm not sure how I'm going to represent time. Usually a Space Opera's character's traing period would be months. Personally, I would like the opportunity to try other characters, but I can definately see people not wanting to give up their favourite character everytime they needed to learn new skills, and I understand that as well. I guess in light of that I will probably speed time up, but I'm not entierly sure yet. Anyway thats enough for now.

Well its been a long time since I've done any soft code and I've never actually altered hard code. I can code in C and have a few projects under my belt so I am not overwhelmed with the prospect that I might have to change some hard code. However, I'm not sure when to stop using softcode and when to start using hardcode. It's more of a theoretical question at this point as I don't even know what systems I'm going to code or what theme my MUSH will be. This looks like a great community. I've just listened to all the tinytalk casts in a row; it took around 8 hours take some minutes here or there for eating and general laziness :). There is a ton of good information in the tinytalk material. I will have to listen to them again just to start absorbing all the thoughtful comments and insights. There seems to be a lot of comment around the net these days on what can be done to avoid certain pitfalls when creating a MUSH. Hopefully I can avoid recreating the wheel, and especially avoid recreating a broken wheel.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Creating some comaraderie amoung different MU* code bases

So the SQL integration is completely new to me, do all the MU*s (or at least the prevalent MU*s) have the ability to access SQL? If so there could be a central SQL server that a MU* could connect to. That way MUSHes could have a BB system that MOOs could read. Even better, simple little games could be built that players from differnt code bases could play together while waiting to get top (do people still do that?). You could even do a cross game chat system that polled the database every minute or so and delived messages directly to their recipients on the correct MU*. That way players could get to know each other.

Is this sort of thing possible? I have an MySQL server that I would volunteer to run a test with. To make it very useful it would be nice if you could specify 2 sql servers. The basic one and an alternate. Then maybe have commands like @asql and asql(). That way a MUSH could have its own seperate SQL db and a shared db that the MU* community connects to. There would be a bit of accounting to set it up. Each MU* that wanted to participate would have to get a unique login to the database. Each login would have its own table(s) that it would have complete control over, and the same login would only have SELECT access to the other MU*s table(s).

Having basic and alternate

Having basic and alternate servers (or, by extension, allowing connection to multiple sql servers in general) would require some hardcode changes - not very hard ones, but probably of limited utility to most servers.

But the idea of setting up a central mysql server and arranging matters so that each mush is given a mysql user that has shared access to some common tables is a very interesting and doable one.

The database would have one

The database would have one table for each MUSH that connects. MushNameInbox. The table would have 4 fields (sendplayermush, sendplayername, recvplayername, message). There would need to be an object in room #0. Every so often (what ever doesn't drain too much resources) the object would do SELECT * FROM MushNameInbox. The object would then @pemit playername=sendplayername from sendplayermush sent you this message 'message' for the list of items returned. To place messages we would need a command like +imush 'mush' 'playername'=message. This would execute INSERT INT0 strcat('mush', Inbox) (sendplayermush, sendplayername, recvplayername, message) VALUES(mushshortname, %#, 'playername', message).

We would also need a table to hold shortend MUSH names so ReallyLongMushName might be shortend to rlmn. A +imushlist would query the table and show the shortend entries and thier corresponding names.

The tricky part will be synchonizing everything. We will need another table with a field that sets the universal poll time 1 min, 5 mins whatever. Ideally we want every MUSH to SELECT from its Inbox as close togehter as possible. So considering mush restarts and all kinds of strangness some sort of sync will have to be built in. So each central object will have @startup object=@set me=First_Check:0. We will need another field with a date time stamp. When a MUSH does its first check it will see if the current datetime stamp + the poll length < date(now). If it is <, then there is no current MUSH logged into the chat system so it resets the datetime field and sets a #ofchecks field to 0. Then when another MUSH connects to its inbox for the first time it would check this table (making the same checks the first MUSH did, but noticing that there is a MUHS currently connected) and it could determine when the first MUSH will check next and alters its next check to start then. The first MUSH would have to update the datetime field everytime it checked its inbox. And each MUSH would have to verify that the first mush was still connected. If it drops then a new first MUSH must be chosen and some policy about messages destined for dropped MUSHes must be made.

I'm not sure what to do if someone enters a bogus name, either on purpose or by mistake. My gut says just throw it away. Otherwise the central object has to capture the failed pemit and send a message back to the sender. That really screws up communication with typos though. What I'm worried about is someone spamming +imush commands. I suppose some limit could be placed on the number of messages you could send every poll. That would probably work.

There will definately be complications but how does that sound? I have two MUSHes I can run from two different domain names. They will be working from the same IP but I don't think that would matter once it is translated it into the real world, would it?

Ah, I didn't think you were

Ah, I didn't think you were talking about a cross-mush communication system. Frankly, for ephemeral stuff like messaging, I think a bot makes more sense than SQL. Been done well already.

I thought you were talking about sharing data with more permanence. Like character data. Or plot data. Or social reputation data. I would find that kind of thing a lot more innovative and exciting, personally (YMMV :)

And thanks for the tinytalk voicemail. I got it!

Ah good thing I'm talking

Ah good thing I'm talking this out then, wasn't aware there were bots that did that. I was just starting with a chat system as I figured that would be a good place to begin. I wasn't thinking so much as sharing IC information although I can see the benifits there. I'm thinking more along the lines of creating a Tic Tac Toe game and allowing people from different MUSHes to play against each other while they idle. Obviously Tic Tac Toe would be just a begining. You could do chess and the adventurous could create games similar to the old BBSes. I don't want to overshadow the point of each MUSH but I rembmer when I used to play there could be a lot of waiting for TinyPlots to happen. Sometimes your waiting with a lot of people who are idle. If, say, 5 or 10 MUSHes were connected to the same SQL database then they could all have an OCC games room with the same game objects that connect to the db. I'm bringing this up to address the concerns I heard in some of the Tinytalk episodes, and from what I've seen on the different community sites that there is a fracture in the MUSH community with each group staying for the most part with in its own genre. This would give people a chance to interact with MUSHers from other genres, but it would also create a larger player base so that when you go looking for someone to play Tic Tac Toe with there might actually be someone on looking for a game.

Yeah. :)

Yeah. :)

I forgot to mention this

I forgot to mention this earlier. If you look at my third line in the previous post - The database would have one: 'This would execute INSERT INT0' the INT0 is spelled witha a 0 (zero) instead of an O. If I used an O, even though I wrapped the line in code tags, it would give me this error: You don't have permission to access /index.php on this server.

I just reproduced this error with this message.

That'd be a protection

That'd be a protection against an SQL insertion attack, I expect, being levelled by Apache's mod_security.

Clever with the 0.

I just got approval for my theme

Well I'm all set to start creating my MUSH. It will be called Portents. It will run at mush.portents.ca 4201, 4202 for SSL. I originally wanted to create a new WoD MUSH, but I emailed them about using their content and got no response. Upon looking at thier FAQ page it seems they are only allowing 'experienced partners' to use their IP. Which is fine by me. I also emailed another company, Fantasy Games Unlimited, about their game Space Opera. They produced a lot of games in the late 70s early 80s and offer reprints of their games to this day. They emailed me back very quickly: this was part of their response "It sounds like you are talking about running a Space Opera game on the internet and not charging for it. I don't really think that is very different from running a game for your friends or at a convention." Which seems to me to be very sensible, and I'm glad that was their decision because I really like their system.

So I had already registerd portents.ca, as I was hoping to run a WoD MUSH under that name, which would focus on Mage and deal with the occult and divination. However, I like portents.ca, and even though its only $10 a year to get a .ca name I think I'm going to stick with it for my Space Opera MUSH. Space Opera came out shortly after Star Wars, and there is a force like system in it, so I may still put some divination themes into the game. I'm going to steer clear of occult stuff, as I don't think mixing occult with sci-fi would do my MUSH's theme's cohesion much good, at least in the begining.

Anyway I've turned off registration and creation for the time being, as I want to have at least character creation in place before I invite alpha testers into the game. Heres hoping another Sci-Fi game will find its niche.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.