The next version of Guncho is under active development. My main focus for now is updating the web application to make it easier to create, share, and play realms. Here’s a peek at how it’s coming along:
2 Likes
I can’t picture myself ever making a game in Guncho. I’m just too self-absorbed. But I remember reading about it in Aaron Reed’s book and thinking, man, I’d like to mess around there if someone else could make a game.
Please do keep us updated! We may not have anything to say, but we’ll probably all be thinking “cool.”
Also is there a public repository we can follow?
During last week’s IF Discussion Club, the topic of Guncho and multiplayer IF in general came up a few times.
Hopefully these new developments will help Roger’s prediction become a reality:
The first screenshot from mobile:
This is still very much a work in progress: the new libraries I’m using aren’t quite as well-supported on Linux, so I won’t link to the server since it’s going up and down as I debug it, and you can see there are some issues with text ordering (maybe caused by the slow mobile network?). Still, I think this is on track to make Guncho a lot more usable.
1 Like
This is cool, I’m glad you’ve accelerated development on this. I am going to be writing lots of tiny games with Inform 7 soon, and I probably won’t have time to also rough each one out in MOO. Can you remind me: What is the underlying MUD technology you are converting these i7 files to? I am really attached to MOO, because of personal projects I cannot really drop MOO either, and I’d rather not have to learn a whole new MUD scripting language in order to correct inconsistencies in translation.
How good is the underlying MUD tech? Regardless of where the source code comes from, it all ends up as a MUD, so for maintenance and admin, don’t you really HAVE to know the MUD’s native scripting language, as well as i7?
How hard do you think it would be for me to bolt Guncho onto MOO instead of whatever engine it is presently using? Probably would involve rewriting everything, right? sigh
Great project, I would dearly love to be able to feed my i7 projects into my multiplayer environment w/o much work — I just wish I weren’t so damn committed to MOO. Even the year Guncho came out, I had already deeply invested tons of time writing experimental tools in MOO that are still innovative and which no one has replicated. There is no way I’m going to translate them all to another MUD without even having tested them in public yet to know if they’re fun or anything. I have to write more ‘game’ to go with my tools, and so it’s going to have to be in MOO. I don’t have X more free months to just transcode things I thought up years ago; they must be tested where I originally coded them, or else I’ll need to just drop them and all those months/years of private work. 8(
This is problem when you work on the same things for too long. I have to change my whole process somehow.
Not quite, maybe this diagram will help:
There is no traditional MUD server involved: your I7 code compiles to a Glulx file that runs inside a virtual machine, just like single-player IF. Guncho simulates a MUD on top of that, using a combination of I7-level library modifications and server coordination.
When you join the game, you’re placed in an instance of The Outer Realm and allocated a player-character from its pool; your commands become actions taken by that character, and other players see your actions thanks to I7’s standard NPC rules. When you travel to a different realm, your character in the old realm is returned to the pool and you’re given a new one in the new realm.
Inform 7 was the easiest language to support, but this could be extended to Inform 6 with a little effort (since it runs on the same VM), or TADS, ZIL, etc. with a little more (since they use a different VM and would need a different low-level protocol to talk to the server).
Thanks for the diagram. It’s a little hard to wrap my head around coming from the MOO world, but let me see if I’ve got this correct. If I were to run a Guncho server, that server includes an inform compiler and and http server for remotely web-editing the source code of the ‘server database’ (which in the case of Guncho is not so much an actual database as a fairly standard Inform 7 source code text file). When that source code is changed remotely (can multiple players edit the a realm’s source at the same time?) and posted, the server automatically compiles and shifts to the new binary, or does it need to be restarted whenever the realm is edited? The ‘VM instance’ run by my Guncho server would represent a single realm that can be connected to by multiple remote players, correct? i.e. it doesn’t open a separate VM instance for every player right? The duplicate VM instance in the diagram is a bit confusing but I assume that signifies that you can potentially serve multiple realms at the same time?
Did I get all that right? Which parts did I miss?
Correct, although at some point I hope to add version control, which will make it more like a wiki page.
You can grant write access to multiple players, but there’s no Google Docs-style live editing, it’s one after the other (like wiki).
Once you submit the new code, the server tries to compile it, and if successful, it restarts the VM with the new binary. The realm has a chance to save player locations and a list of key-value pairs, but anything else will be reset.
Correct. There are multiple VMs running at the same time, one for every active realm instance. Multiple players connect to an instance, controlling different player-character objects.
There’s no concept of owning rooms and objects like there is on a MUD: if you add a rule to a realm’s source code, it can affect every object and player in the realm. That’s why dividing the world into separate realms is essential.
On a MUD, you might see an apartment building with a hallway owned by one player, with exits leading to apartments owned by other players. On Guncho, the equivalent would be a hallway in one realm with fake exits leading to realms owned by other players. When someone tries to go through the fake exit, the first realm instructs to the server to send them to the other realm; the transition is seamless to the player, except that they’ll drop anything they’re carrying since it doesn’t exist on the other side.
OK cool. That’s all very clear. What with the emphasis on trading players from realm to realm, the set up kind of reminds me of Eamon a bit, back in the day. What kinds of objects can players bring with them from realm to realm and how fully functional can they be? With Eamon there had to be standardised ways of describing weapons and whatnot, so an especially good battle axe in one Eamon scenario could be used in battle in another scenario and it would also be an especially good weapon, etc.
How compatible is it with web interface? Like, let’s say I wanted to create a web landing page for each room in the MUD, where you could see listed all the players who are currently in that room in the MUD - where would I put that code? i.e. How much flexibility do I have to use the MUD as a dynamic web server? Can I code ‘Before serving the web page at /pages/rooms/DebrisRoom.html:’ and do some preprocessing of what a web surfer will see? Just wondering how far this tool can go.
Interesting! I haven’t heard of Eamon – that’s this one?
As of now, the only thing players can take with them from realm to realm is their profile: name, description, and gender. No objects.
On another development branch, I started working on “bot realms”, where you’d code an NPC in one realm and they could interact with other realms as a player. It’ll be a while before I can get back to that, but I think it’s more feasible than carrying objects.
Nothing like that at this time. There’s a web API, but it’s all about the metadata managed by the server: list your realms, edit the source code, etc. - no requests that are handled by the realms.
It’s an interesting thought, and I could see adding some kind of website-per-realm feature. I’d want to avoid making the realm itself do too much of the work of handling requests, though.
Sorry for the delay. Got distracted by trying to get a dev cycle off the ground.
Nothing like that at this time. There’s a web API, but it’s all about the metadata managed by the server: list your realms, edit the source code, etc. - no requests that are handled by the realms.
It’s an interesting thought, and I could see adding some kind of website-per-realm feature. I’d want to avoid making the realm itself do too much of the work of handling requests, though.
[/quote]
Reason I asked is most MUDs seem to be capable of acting as generalised dynamic web server, with a little bit of custom code. Or at least, they have modules available that do this. In LambdaMOO I use E_WEB although you can’t even find ‘E_WEB’ online to install anymore — I may have the last active installation left! — but there are other, more modern HTTP 1.1 web servers for MOO and for other MUDs. E_WEB is only HTTP 1.0 but I hacked it to do persistent connections so it behaves more like HTTP 1.1 although it still identifies itself as a 1.0 server.
If MUDs didn’t have this feature, I doubt I would have stayed in LambdaMOO for so long. Heck, my personal blog software was handcoded in LambdaMOO/E_WEB. (It’s offline though until I can find time to harden it, which isn’t a priority until I release new artwork. When I started attracting negative attention by joining GG I felt I had no choice but to give up the luxury of having an insecure server online and trusting in obscurity.)
But MUDs do this because it’s easy for them. They already handle TCP/IP connections just like a webserver does – all they have to do is slightly alter their response format when presented with an HTTP header and BOOM they’re a web server. So web serving is kind of something MUDs typically get ‘for free’. As a result the support is often not very developed or sophisticated — I had to hack on E_WEB a LOT.
EDIT: For example, you say ‘avoid making the realm do too much of the work’ yes this is important so I wrote some routines to have the MOO write its html responses out to disk – that way I can run a concurrent more traditional (and much faster) webcache server, and only hit the ‘realm server’ for a dynamic rewrite when the page changes. This is done with redirects. Whenever the information on a page changes, the webcache of that page is replaced with a redirect to the dynamic MUD server instance of it, which serves the new page and rewrites it to the cache, replacing the redirect by rewriting the full new page to disk for all future static queries, until the info on the page changes again. Note that the cache is cleared at the time the info changes, and then not rebuilt until the first time the info is actually requested by a web browser. This prevents the MUD from constantly rebuilding web pages for no reason.
Paul.
Man! I think I know how you feel. I never got to see Eamon–my first hands-on experience was with Leadlight in 2010, as a tester. But I wish I’d had a way to save my old text adventures, even if they probably stunk.
Seeing what Eamon could do, and how it did it, is just cool–man, there was a whole game creating community out there, and I was bummed I missed it, but I’m glad the part of me that hoped something was out there was proven right.
Hope whatever development you’re doing is going well.
Eamon was limited in…SO many ways compared to today’s systems. It was a challenge, though not impossible, to write many standard IF puzzle-types with it. As a result, many Eamon games played more like combat crawls. A lot of the coolness of it was about finding an awesome weapon in one game (or writing a game to give yourself one) and then bringing it into other people’s games. Most of the coolness was just seeing the words ‘elvish sword’ printed in an unrelated scifi adventure, but the fact that it did more damage than a laser was cool. Imagine what such a system could if weapons (and perhaps other types of objects?) attributes were standardised across more than just a couple of combat stats? It’s hard to bring magical effects and the like into unpredictable IF environments tho… it’d really require a kind of generalised object-effect API in which coders of one game create hooks for things-that-burn, things-that-freeze, things-that-electrocute, etc., which other devs can trigger with their fireball spells and electric swords or light sabres, and then you can take the ivory torch into the spaceship and still burn things with it.
Eamon’s saving grace was that the game engine was written in BASIC, so you could generally hack it to create any effect you had seen in any other IF game, if you dug far into its innards. And you often had to. In order to write my games I had to hack in an ad hoc ‘special effects engine’ for puzzle effects beyond the ordinary combat and treasure mill, because I did that kind of thing too often to hack the engine every time. Another reason I wished I’d saved them.
I have a question. Can any Inform build go on guncho?
I know there’s some specific code in the extension, but could you take something like, say, Galatea and put it up so it was just the game, but you’d have other players in the same museum gallery room that you could also talk to?
The code in the extension is required. You could do that with most games for which you have Inform 7 source code, but Galatea itself is a closed-source Inform 6 game.
Right - but it’s as simple as including the extension in a work? That would allow multiple players to walk around and pick up and move things if implemented on a server?
Correct. Guncho even includes the extension automatically, so in general you can just drop in your I7 code and it’ll work.
There are some caveats: Guncho is a couple versions behind in its I7 support right now, so your code has to work with 5T18 or 5Z71. If you use any extensions, I have to make sure they’re installed on the server. And as with any extension, there’s a chance Guncho may define some names that conflict with yours (“PC” is probably the most likely one).
Since you use the actor interface to accomplish multiplayer, doesn’t that mean that in order to make my games fully compatible with Guncho, I would have to rewrite all the multiplayer-capable verbs to insert ‘an actor’ like so:
Before an actor examining the cel phone:
say “[The actor] flips open the phone. [run paragraph on]”;
And also changing any references to ‘the player’ to ‘the actor’, the way they do in the Standard Rules? Most people don’t write games this way because it breaks up a lot of i7’s natural elegance, but unless people do write verbs in this way, how can they correctly represent third party actions?
Yes, when you define new actions that other players should be able to witness, they need to have NPC report rules. I think that’s the only place you need to refer to “the actor”. The standard actions work out of the box.
IIRC, only the report rulebook is run for players who witness the action: “before someone examining the cell phone” will not execute for player actions, just like in single player I7. So if you use something other than report rules to say that an action took place, you need to explicitly say it to other players:
Before examining the cell phone:
tell "[The player] flips open the phone, stares at it for a minute, and closes it again." to everyone else near the player;
say "You flip open the phone. [run paragraph on]".