Roadmap To Alpha
I realized I haven’t posted any sort of roadmap of where I’m going with all this stuff I’m coding. I have one, kinda. It’s just a lot easier to write about stuff I’ve done than stuff I haven’t done. But I’ll try.
If you’ve never played a MUD before, just think of it as a virtual world like you might find in a video game, but it’s primarily composed of text, not graphics. That’s the “D” part at least; the “MU” part stands for multi-user. You connect to a central server over a network and share a common space with a bunch of other people doing the same thing. The rest of this post will describe what you’ll do and what you’ll find inside this virtual world, once it’s ready for testing. This is by no means a comprehensive list of all the features planned for the platform, just the stuff I feel it needs before I can move from pre-alpha to alpha.
I’ve posted a little bit about the login object, so let’s start there. When you log in the first time, you’ll get dumped in your workroom. The only new character generation to speak of will be registering a new username and password. To target audience for the alpha release is primarily other developers. There won’t yet be any sort of game to play, just a development sandbox. No lounge, no roads, no That’s said, let’s talk about what there will be.
I mentioned that you’d have a workroom; even though there’s no game to speak of you’ll still have the ability to create rooms and move between them. Rooms are the basic unit of space in the game; you’re always in a room (and only one room), and rooms can contain multiple players. Rooms may declare exits in the cardinal directions, and the alpha will introduce the concept of “zones” which is a collection of rooms all interconnected by cardinal exits and only cardinal exits. You’ll also be able to establish exits between zones, which can be cardinal exits or custom exit directions.
You’ll be able look at your current location, or at other objects that are in the room with you. This includes a common query language for identifying objects on the command line by id, name, or other criteria. You will be able to talk to other users in the room using the say command, and you’ll have a soul, for issuing emotes (or feelings). Right now the login object just uses raw strings for all the messages it sends, but we’re going to need something more sophisticated than that for doing fancy things in the GUI. Some kind of markup language will be involved; we can use it to do things like replacements in feelings for participant names, or specifying message prefixes like “You say:”. We’ll also have some kind of system for selecting one or more CSS styles to apply to messages (or ANSI sequences in the case of terminal rendering). There’s probably more use cases I haven’t thought about yet; it will need to support prompts, fail messages, error messages, and general command output.
I haven’t mentioned much about the GUI, but the alpha will have a fully functional browser-based GUI, probably using React. I’m keeping things real simple for the first release; it just needs to function well as a communication medium. Right now I’m envisioning a bunch of splitters and then little applets that can be assigned to each frame. There’d be one for the console, one for prompt/input, and probably a toolbar. You should be able to save a given arrangement of applets as a “view” that can be restored later, and have access to multiple saved views. Even with just a console applet and rendering everything as you would in a terminal, you could set up multiple console windows and direct different messages to different consoles, for instance by topic. Or you could set up a side-by-side view of raw message data and the rendered output for debugging purposes. If it’s not too much work, I may build a custom login form just as a proof of concept of how you can use web forms in combination with the CLI; otherwise you’ll just manually use the CLI input widget to log in.
There’s a bunch of other stuff I’m going to bump into along the way to alpha that I haven’t figured out yet, but I’m putting it out of my head for now to work on the stuff I do know. These are things like flavor management, object initialization and state persistence, maybe quotas and metrics. Performance and security aren’t totally my bag, but I do actually want people to use this thing when it gets to a point that it meets their needs. This isn’t a complete roadmap and the alpha will be pretty rudimentary, so I don’t expect people to go out and replace their messaging apps with it quite yet. But if I can get the basics right, though, the path forward should become a lot clearer.