AresMUSH is a new kind of server for MUSH games. Don’t know what a MUSH is? It’s a unique style of text-based online gaming that blends role-playing games and collaborative writing. Check out our MUSH 101 Tutorial to learn more.
The code for the new web portal is complete. I’m working though some bugs and documentation updates in preparation for the next release. In the mean time, you can preview the changes on BSGU’s web portal.
For a more detailed breakdown of the web portal features, you can read the AresMUSH.com web portal tutorial.
It was a year ago to the day that I wrote about taking the plunge into a web-based client for Ares. In that time, it has evolved from a half-baked necessity for game configuration, to a modestly-functional supplement with web-based chargen and some other novelties, to a full-fledged game wiki replacement.
There have been some technical speedbumps along the way and I thought it might be interesting to talk about them.
TL;DR; – Turns out that grafting a full-fledged web UI onto a system that wasn’t designed to handle it is hard. (Shocker, right? :P)
Code geeks, read on…
My first attempt was simple. Using Sinatra, the game’s central EventMachine reactor could serve up web pages too. Because it was integrated with the reactor, the web server could use the shared code libraries exactly like the telnet server did. There was no risk of data collision because everything was being funneled into the same reactor thread. The template engine (ERB) was the same as the telnet side too. Sweet!
Just one problem… server-side rendering of HTML with ERB is fine by web standards, but slow by MUSHer standards. On a web site, you’d barely notice the processing time. But when you’re typing
+who in the game and it takes half a second to respond? It’s annoyingly noticeable.
So I split out the web server using Passenger. Same setup – Sinatra+ERB – but now it was running in its own process.
That fixed the lag, but now we’ve got a new problem. Passenger is essentially spawning a new copy of the game for each web request. Not only is this a horrible memory hog, it basically means that when the web server tries to use a game library function like “tell me who’s connected” or “notify players of a new bbpost” – it’s asking a different copy of the game that has nobody logged in.
I fixed that problem by splitting the game into three parts – the engine (telnet side), the web server, and a set of shared libraries that are used by both. The engine and the web server communicate via a special socket connection. That means the engine can tell the web server when someone posts a new bbpost, and the web server can ask the engine who’s connected. Both sides can access the database independently.
That basically works, but the 3-way split between engine/web/libraries made the code annoyingly complex. The communication between web and engine adds an extra layer of complexity that I really wish wasn’t there. The potential for database collisions isn’t disastrous, but it does present a minor nuisance. And since the whole thing is designed to run on a lightweight server, the performance of the web server is just a touch too sluggish for my liking.
- More responsive performance on the client.
- Lightening the load on the server.
- Generalized API that would let you build other clients on top of the engine.
The down side is adding a new technology into the mix that folks have to learn to code for Ares. But something’s gotta give. We can’t make something that’s simplistic code-wise and has oodles of features and can run on a tiny, cheap server.
I did some early prototyping with Ember, but I think React is a better choice for the long haul. It’s got more traction in the Ruby community.
It’s been a bit of a winding road, but I think it’s leading to a good place.
As always, stay tuned for updates. Feedback is always welcome on the Discussion Forums.
Back in July, I asked a question on the AresMUSH Forums: “Can Ares replace parts of a game wiki?”
The answer, pretty clearly, was “no”. Ares could not replace parts of a game wiki. Quite understandably, people did not want to have to go between two different websites to view a game’s information.
I soon realized that if I wanted the web portal to be successful, it would have to replace the entire game wiki.
So now it can.
You can see it in action on the BSGU Web Portal.
The scenes, character gallery, actors list, census, etc. are all drawn straight from the game’s database. No more needing to update your character’s wiki page just because you had a birthday or got promoted. No more log cleaning or entering
[[logIcon Faraday]] wiki junk to create a scene log. You can customize your web portal profile too, either from in-game or from the web portal editor.
The wiki operates like one would expect, allowing you to create and edit pages. So far it just has what I consider essential features. It can’t do everything that MediaWiki or Wikidot can do, but it can do a lot – dynamic page lists and markdown extensions that make it easy to adapt from Wikidot.
There’s still a lot of work to do, but I’m happy with the direction it’s all going.
MUSH help systems are generally pretty… unhelpful.
Traditional MU* help has been based around a screen of disjointed topics.
------------------------------------------------------------------------------- +help Topics +BG +FINGER +DESC +HELP +LIST +MAIL See +help for more information about a topic. -------------------------------------------------------------------------------
+BG? +FINGER? If you don’t already know what these things are, this “help” is nonsensical. Your only real option is to just go through them one by one typing ‘+help xxx’ over and over again. And don’t even get me started on ‘help’ vs. ‘+help’.
One of the things I’ve tried to do with Ares is to improve the help system.
The help is very web-centric. Help topics are organized into general categories (Character Creation, Community, etc.) and each display a brief summary.
Help files are Markdown, allowing you to use all sorts of formatting (bold, tables, callouts, etc.), hyperlinks and even images.
Inside the game itself, you can view the topic list organized by category, just like the web view, with links to the web portal.
In the game itself, you can get a link to the web portal using
help, or use
help/view to display the web text in-game.
And finally, can also do
help to display a quick reference for a specific command.
I’m sure there’s still room for improvement, but at least it’s a step in the right direction.
The last blog post declared “full steam ahead” towards the public beta launch of Ares. And while things are still chugging along nicely, I ended up taking… a little detour. Off the deep end, maybe.
In part I credit (blame) Sparks for my madness. She shared a screenshot of how she’d created a web interface for the BBS system on Evennia. I said: “Huh. I guess I could do that for Ares too.” So I did. Then. “Well, I could probably do mail too I guess.” So I did. “And maybe I could just add this one other thing…” and it just went from there.
So the Ares web portal now has… kind of a lot on it besides just the admin screens. Auto-logged scenes. Customizable character pages. Combat management. A locations directory, and more.
Here’s a character page as it originally existed on our pre-existing wikidot wiki for BSGU: Wikidot Page
And here’s the corresponding version on the new web portal: Web Portal Page
The web portal has a tight integration with the game. There’s no need to update your character’s wiki page when you get promoted or have a birthday, because it draws the data directly from the game itself. You can also edit some of the fields through the web portal too (shown here.)
The gang at BSGU have been super helpful in testing things out and finding my bugs, so the web portal has been evolving nicely. Once it’s shipshape, we’ll be back on track. Assuming, you know, I don’t decide to add some other huge new feature next week. You never know.
The configuration eureka moment I described in the last blog post was a huge breakthrough on the game administration front, and a sudden flurry of activity on BSG: Unification has shown that performance and stability are still solid when you have a couple dozen people logged in. (Whew!) The influx of players new to Ares has also brought a lot of good feedback, leading to new commands and bugfixes.
All in all, I’m feeling pretty good about the Ares beta. Now it’s time to start looking ahead to the first official release.
I’ve whittled the backlog of ‘wish list’ code items down to the ones that are essential, and I’ve also started working on the necessary tutorials. Things are moving along nicely. Full steam ahead!
For the past few months, I’ve been struggling with two competing goals of AresMUSH: make it easy to set up, and make it easy to create custom code. Easy setup leads you to a web-based system, but a good web-based system adds a ton of complexity to the code base and makes it much harder to customize the code. Catch 22, right?
After going round and round and round and round and… I finally found a happy compromise.
The most basic game config will now have dedicated screens in the Web Portal, making minimal customization super easy. For example, here’s a screen to edit the basic game information.
And here’s a screen to edit the FS3 Skills list:
That’s all well and good, but what about the rest of the configuration? I didn’t want to force plugin designers (or myself) to create a web config screen for every single plugin. But without that, configuring the plugins required you to connect to the server shell and edit config files in emacs. Yuck.
The solution was to make a system that’s reasonably easy but also generic – so it can work for any plugin. Happily, I found a web-based file editor module. So now you can use the Web Portal to edit any plugin config file in a spiffy editor with syntax highlighting and indentation help:
You’ll still need to connect to the server shell if you want to change the source code, but if you’re running the standard code you should be able to do everything you need from the Web Portal. I think this goes a long way to making Ares work for someone without any coding experience and overcomes one of the chief obstacles that’s been plaguing me.
The web front-end I talked about last time was neat and all, but it was clunky, and still fell short of making a game easy to set up for someone with no coding experience.
I found myself circling back to an idea I first touched on months ago: What would a MU* look like if you designed it today for the web?
Here’s my latest attempt:
The site is just a mockup to show what a game might look like. You can navigate to different screens, but a lot of the buttons don’t actually do anything.
It’s basically a MU and game wiki all in one, drawing inspiration from Play-By-Post games, Storium, graphical MUDs, and some sketches shared with me by Skinny Thicket@MSB.
It’s a bit of a different experience. Instead of gameplay being centered around a character moving through the grid, it’s centered around scenes.
You’d start a scene and either invite people to it or declare it public for anyone to join. The scene page (which looks remarkably like a MU wiki log page) would update live as people contributed to it. When the scene ends, you can keep it private or share it on the scene archive.
Chargen is also entirely on the web, allowing you to auto-generate things like faction lists and character profile pages.
Notably missing from all of this is live chat (channels and pages). Chat is the one area where I think a MU* would be better served with an off-the-shelf tool. Discord is ridiculously simple to set up, and I actually think there’s some merit to having a central Ares Discord server with sub-channels for different games. It might help the community, and allow you to talk to all of your MU friends no matter which game they happen to be logged into at that moment.
PBP By Another Name?
Certainly there are similarities between this and a Play-By-Post game, but there’s one important difference: time passes in the game in parallel to RL.
While you could certainly use do backscenes or multi-day scenes in this style of game, the default mode of gameplay is still “live”. It’s intended to be fast-paced.
Where Do We Go From Here?
So what does all this mean for AresMUSH? I haven’t decided yet. There’s a lot of allure to designing something that takes a bigger step forward. Something my kids might actually play someday. But it would delay the development timetable and I’m not convinced people would actually play it.
I’m curious to hear what you think.
Not too long ago, I nixed the idea of incorporating a web server into Ares because it would increase the code complexity too much.
But as I embarked on a project to make the game setup easy for people with limited technical experience, I quickly realized that a web configuration tool was absolutely essential.
Right now Ares uses plain-text configuration files on the server itself, similar to the
mush.cfg files of PennMUSH and TinyMUX. That’s great for programmers, but “telnet into the game shell and edit this file on the command line” is pretty off-putting for a generation who’s never had to use a C: prompt.
I briefly toyed with the idea of making everything configurable through in-game commands. That would work for some plugins, but you’d need insane commands to tackle the complex ones like FS3 and groups.
So I needed a web server to configure the dang thing. And once I had that, well… why stop there? I shamelessly stole ideas from Evennia’s web UI. For players, there’s a browser game client, web-based FS3 chargen, online help files and a character directory. Admins can access the configuration pages and some utilities like viewing logs and shutting down the game.
Some of the screens are still rough, but that can be improved over time. It’s still pretty nifty, in my terribly biased opinion.
Check out some initial screenshots:
Ares reached an important milestone last month when the first public beta game went live: my own Battlestar Galactica: Unification. There have been a few minor issues, naturally, but fortunately nothing major exploded. It’s a gratifying culmination of the last four years of effort. I’m grateful to everyone who’s given their suggestions and support along the way, particularly the friends who were the first to brave the new server.
Next up? Making it possible for people other than me to set up and run an Ares game. That means writing instructions, adding admin commands for common activities, and creating a web front-end to make it easy to configure and customize a game. Oh, and responding to any more beta testing feedback.
So there’s still a ways to go before it’s ready for public consumption, but we’re getting there!