Since my last post, I decided to pivot to a (closer to) pure MUD version of Vanquish Vanguard Online, or VVO. The only differentiation I'd like to make from a pure MUD is to have support for a minimap and some primitive, static graphics for showing image locations, character and monster portraits, and the like. Even this primitive level of graphics does unfortunately mean that I can't go with the standard Telnet MUD, since that would obviously be text-only. That means I have to consider more sophisticated solutions.
Despite the fact that I sometimes have a burning hatred for CSS, I nonetheless like to gravitate toward HTML/CSS/Javascript for creating GUIs that don't require sophisticated graphics, mostly because it's the GUI tech I'm most familiar with, and I've never had good experiences with GUI frameworks like Qt, JavaFX, etc., always finding them a pain to work with compared to building a webpage. So, wanting to use a webpage for the client side, I decided to use a PHP backend for the server side since I have an account with a webhost with built-in PHP support.
This, as it turns out, wasn't a great idea. Some of you might already be shaking your heads at the foolishness of this as an architectural decision, using PHP as the server tech for a MUD.
Unfortunately, I wasn't really thinking things through, and I built out a fair amount of functionality -- a complete interface for the frontend, an elegant messaging system, a map editor, some database tables, authentication, and some other bits, before I reached the point where I was ready to have a player start moving around the map. That's when the fundamental problem hit me like a ton of bricks, the issue that probably should have occurred to me as soon as I considered this for a MUD architecture:
A PHP backend is fundamentally stateless.
The whole point of the typical web-based client/server interaction is that it doesn't have to remember state from one request to the next. It's also purely event-driven, where the client sends a request and the server responds to it. This is quite a problem when you need the server to update its internal state at regular and frequent "ticks" and then push those updates to every client. That's not a stateless operation at all, nor is it purely reacting to requests from the client; in fact it's pretty much exactly the opposite paradigm.
Now, this isn't an insurmountable problem. Here's a potential way I could wrestle this into working with a PHP backend:
But this has issues. First of all, it's getting kind of complicated, and VVO was intended to be a relatively simple project -- and the complexity is entirely because I've done a very poor job choosing the right architecture for the application. Secondly and even more problematically, I just have a simple shared account with my webhost, which means I don't have admin access to install Redis. So this, which is the most viable solution I can think of to the problem, isn't even available to me.
I could install an HTTP server on my local machine using any of various techs (Nginx, Apache, whatever), thus giving myself admin access and the ability to install any software I need, but then I have the security burden that comes with hosting an HTTP server on my own computer, and things are just getting even more complicated.
Honestly, the problem is just that I shouldn't have tried to use a PHP server for a MUD, and if I'd given it some thought before I started, I would have realized that before embarking on this quixotic quest. What I need to do, I think, is give up on the idea of using a standard webpage for the GUI so that I can just program the VVO server using whatever programming language and frameworks I want. That means no frontend web tech for me (because I've tried Electron and concluded it sucks), but I guess the lesser evil here is to just suck it up and use some kind of desktop GUI framework. I expect it to be painful, but given that the requirements of the GUI are not *that* complex, hopefully it will stop short of being agonizing.
So, another false start for VVO. The first one was not because there was anything wrong with the tech or the implementation, but because I started to have serious doubts about whether the gameplay would really be that fun -- and now the second try because I chose my architecture really, really poorly. But, I said from the outset that unlike my other filtered and curated online outlets, this one would discuss projects in all kinds of states of completion, including (probably) some that end up fizzling out and never seeing the light of day. This is how the sausage is made, and finished projects are built on mountains of failures.
None of which is to say that VVO has fizzled out (yet). I might give it another try, this time just programming both the server and the client as desktop applications using... well, I haven't decided for sure, but pretty much any cross-platform tech will work for my purposes. Or... I might decide I need a break from hobby programming and decide to do some creative writing instead. Further updates to come!
On a completely different topic, the Marmoreal Tomb came today. I haven't had time to read much of it yet, so this isn't going to be a full review. However, I have a few photos of the unboxing:
Photo of the Marmoreal Tomb box
The box art is very cool, and the box is quite heavy, suggesting the thickness of the material within. The box seems made of reasonably sturdy cardboard, but it's so heavy that it feels like I want to treat it gently or it might fall apart just due to the weight of its contents.
Photo of the Marmoreal Tomb books
Inside the box are four books: the core book, a wilderness expansion, an underworld expansion, and "appendices" (which doesn't SOUND very exciting, but I haven't looked at it yet so it might be cooler than an uninspired name like "Appendices" makes it sound). The books are softcover, which is a slight downer, since they'll be less durable that way and harder to keep open on a page if they're lying flat, plus hardcover is just cooler. But it's not the end of the world. The cover art is once again very cool, although two of the books just have the same art as the box.
Photo of the Marmoreal Tomb maps
There's a CRAPLOAD of maps in this thing. I tried to spread them out a bit so you could get a feel for it, but it's hard to capture in a picture just how many maps this set comes with. Tons of dungeon and overland maps. They have sort of a "colored pencil" look which gives them an oldschool feel, but they don't look cheap or poorly drawn. The dungeon levels are fairly sprawling, and at a glance, the layouts look interesting. They're pretty labyrinthine and probably not overly concerned with realism, but they don't fall at the extreme end of ridiculous oldschool-style dungeons filled with pointless mazes where the inhabitants would have a half-mile walk through a labyrinth to get to the privies, either. In other words, they look like they occupy a sweet spot of being big, confusing mazes (and thus fun to explore) but not having such absurd layouts that you have to suspend your disbelief with an adamantine chain to try to immerse yourself in them. There's also some variety in the maps, including one dungeon that looks like a hexagonal-comb giant insect nest, which is pretty cool (and horrifying).
Photo of the Marmoreal Tomb book interior
Here's a picture of a randomly-chosen page from the core book. The interiors are black and white, in two-column format, with a reasonable font size that gives decent words per page without making you squint to read it. The interior art is basically pencil sketches, but they're reasonably well-drawn and don't (from flipping through some pages) fall into the depths of "this looks like it was drawn by a six-year-old" that some of the earliest D&D art did.
The box set calls itself a "Campaign Starter," but just from eyeballing it, it looks like there's easily a year worth of material in here even for a group that plays every week, and possibly a lot more. It definitely doesn't skimp on the content.
I've not read much yet, just the introduction. It has a somewhat annoyingly high incidence of typos which characterizes so much third-party RPG content, but for me that only detracts mildly from the reading experience and I won't dock too many points for that if the content is good. The intro basically explains a play style which characterized early D&D but has become much less familiar over time, eclipsed by the linear "a party of heroes saves the world or completes some other epic quest" adventure path style of play (which is the kind of campaign I almost always run and is generally much more common today): namely, the weekly dungeon delve where each session is characterized by traveling from town to the dungeon, exploring as much as you can until your resources run low, then retreating back to town to recuperate and secure your loot.
In particular, the intro focuses on a variant of this playstyle it calls the "hobby shop dungeon" where a single DM runs the same material for multiple different groups IN A SHARED WORLD where each group's actions are persistent for the other groups as well. I've run multiple groups through the same material before, but always in an "alternate universe" style where each group's actions are completely separate and isolated from each other and often even contradict each other (where, for example, one group decides to kill a certain NPC, and a different group decides to ally with that NPC, etc.). Essentially, it ends up being totally different stories, just told from the same base starting point.
This idea of running multiple groups in a shared world is intriguing to me, and something I'd seriously consider trying in the future. It's the kind of thing that couldn't really be done in a story-heavy adventure path, at least not unless you took pains to have different groups pursuing separate quest lines. However, in a campaign where there's not really one single over-arching objective, but rather many smaller quests and goals to choose from (and could be player-initiated for more proactive players), this isn't really an issue.
The idea of each group's actions having persistent effects on the world that are visible to other groups, like one group opening up (or collapsing) part of a dungeon, another group slaying a particular group of monsters and its leader, another group unsealing an evil artifact and causing all hell to break loose -- and each group seeing and feeling the effects of the other groups' actions -- sounds to me like something that would potentially be a lot of fun. Right now the games I'm running are pretty tied up with the current VanVan playtest campaign, but once that's wrapped up, running a sort of "shared world" game (either with the Marmoreal Tomb or something of my own invention) is something I'd really like to try out.
As for the quality of the content and whether the locations and quests in Marmoreal Tomb look fun -- I don't know yet because I haven't gotten that far. Given the sheer size of the content in the box and that I'll probably mostly be reading it for about an hour at a time before I go to bed in the evenings (with perhaps occasional longer bursts), I don't expect to have read it through anytime soon. I might do a kind of multi-post running review, revisiting the Marmoreal Tomb and giving new impressions as I continue reading it. All I can say at this point is that I'm definitely looking forward to reading more and that my first impressions are positive.
Well, this has been a long post. Dr.J signing off for now, and may all your hits be crits.