So last time I pulled a markup language out of thin air and presented it as the most likely candidate so far for representing the data for the new protocol. Like I'd mentioned, this wasn't really something I planned to think about this early in the development stages but hey, guess plans don't always work out. Most of the reason was that I'd already given it some thought, and I needed a quick example to show, because it's hard to communicate ideas at the level of abstraction of 'there is no representation, just think of data hanging off a bit of text'. Yeah.. In related news, there is no spoon.
Anyway.. I've already fielded some questions on why I didn't pick this other already existing format or another, and since these questions will come up more often, let me answer them here now.
I promised in my last few posts I wouldn't want to discuss the actual representation of the protocol. I guess I lied. An example I presented today was met with enthusiasm from various parties, including at least one of the poor sods who would have to implement it. Thus I present: ESE (Extremely Simplified Enamel)
Let me briefly cover two additional topics on the matter. One's about how to proceed once some ideas have trickled in. One's on, more or less, what the protocol would do as I envision it (but not yet HOW). I strongly suggest not reading this post until after you've made your suggestion on the previous one, if you're planning to do that.
Huge disclaimer to start: Nothing may come of this.
If you can live with that, let me add a redeeming thingy: If I don't actually work on this at all, at least the data will be available for future reference.
So are you ready? Okay.. Given an implementation of a new protocol to do the sort of thing Pueblo does, but isn't Pueblo, what sort of things would you require? What sort of things would you suggest avoiding?
In my first post, I discussed briefly the setting for the game, and in my second, I talked very briefly about the "feudal anarchy" which was said to have spread across Europe in the 10th and 11th centuries. I'll talk a little bit more about that here, and will get into more depth about the history of 12th-century Europe, as well as some of the reasons why I chose this period and not, as I discussed in my first post, the 10th or 11th centuries.
This is the second post in what will hopefully continue to be an ongoing series dealing with the development of ''Imperium Romanorum'', the MUSH I'm currently working on. Part I was an overview of the project. This will deal with narrative and RP, the community features that hopefully will enhance the experience of playing the game, and the administrative structure and techniques that will ideally avoid the pitfalls that have faced game admins in the past. A quick note on terminology: HC means Historical Character, and OC means Original Character.
As many know, I have been working for some time on a historical-themed game set in Medieval Germany, around the mid-12th Century, which I am calling Imperium Romanorum, which is how it was known contemporaneously. Although my historical studies have been getting the best of me, I've been meaning to blog about the process of developing the game for some time as a means of keeping track of where I'm at on the project as well as inviting feedback on my ideas for the game. This will be the first post in what will hopefully turn into an ongoing series, assuming I can keep myself on-track.
I've edited this to post an announcement here, and update the original post to the latest version. If people want to archive the earlier versions on this blog, I can do that instead.
All right, here's a real introduction. This project is a major re-write and expansion of one by Raevnos. The code that follows implements a number (111, to be precise) of functions from other codebases in PennMUSH. Nearly all of these are from TinyMUSH or TinyMUX, which are the two other codebases I've written a significant amount of code for, but there are also a few from RhostMUSH. I hope this would be useful in porting code. A full list of functions and known incompatibilities is in the main object's @DESCRIBE, but it would be easier to list the functions that I didn't port:
You might know me from M*U*S*H; from Shangrila; or from the TinyMUSH I joined years ago, started coding at, and ended up running. I'm here now because, thanks to a chain of events that started when that MUSH briefly went down, the other wizards and I amicably agreed that it would be a good idea to start a new MUSH and learn from our mistakes. I decided to make that a PennMUSH, I've spent the last few weeks coding on it, and the people on M*U*S*H suggested that I post about that here. I'm happy to do so.