31 Jan, 2008, drrck wrote in the 1st comment:
Votes: 0
Does anyone have any experience developing on a MUD that crossed over into the graphical genre, while still maintaining the basic text-based design? I'm interested in dabbling in a project that would have a client utilizing some kind of divided screen, with tile-based "old school" console RPG style graphics to supplement the regular MUD output. I have some basic design questions related to synchronization and "how much is too much" when it comes from converting game features to the graphical realm.
01 Feb, 2008, Mabus wrote in the 2nd comment:
Votes: 0
I can think of Crossfire and Daimonin off the top of my head.
01 Feb, 2008, Zenn wrote in the 3rd comment:
Votes: 0
Currently in development is CircumReality code - you can create your own graphical-style MUD with the software.

http://www.circumreality.com/Screenshots...
01 Feb, 2008, drrck wrote in the 4th comment:
Votes: 0
Mabus said:
I can think of Crossfire and Daimonin off the top of my head.


That Crossfire project is very similar to what I'm interested in (albeit very rudamentary). I don't suppose you or anyone you know is affiliated with it?
01 Feb, 2008, David Haley wrote in the 5th comment:
Votes: 0
Interestingly enough it looks like Daimonin was originally derived from Crossfire and still has a lot of server code in common.

I've been dreaming of doing something like Daimonin for a long time. I tried it a long, long time ago and failed miserably because I had no idea what I was doing (I think I was 14 at the time). I've been meaning to try again one of these days but time being what it is (i.e. lacking) I haven't started.

I'm not sure I like the idea of a real hybrid game where things are text-driven with a graphical display. I think that's missing part of the point of graphics: the graphics allow you to add a level of interaction that was simply not possible in text.

I've been thinking about what advantages you get by having graphics over text, other than prettiness or "coolness". I'm slowly concluding that the main advantage is being able to display positional information concisely and meaningfully. With text, sure, you can put up little ASCII maps of the surrounding areas with little characters indicating where people are. But you rapidly reach a point of information decoding overload in that you want to tell apart who's the fighter, who's the mage, who's on your side, who's taking swipes at you, who is who to begin with, etc. The map is then augmented with a legend, but that requires that much more (human) processing time to figure out what things look like.

Then if you want to add strategic elements, and not just tactics, it is very, very useful to interact with a map of the area. Things like "take this battle group and move it there; build resources here; connect the supply line from here to there" are much easier to express in a graphical client.

Well anyhoo, random thoughts, don't mean to hijack so will stop now.
01 Feb, 2008, Mabus wrote in the 6th comment:
Votes: 0
drrck said:
That Crossfire project is very similar to what I'm interested in (albeit very rudamentary). I don't suppose you or anyone you know is affiliated with it?

I am not. I just knew of them from tinkering with the code of them on my own. Did some sprites and skill/stat changes in Daimonin as a side thing.

If you approach their communities from a proper standpoint (intelligent questions, reading forums first, etc.) they may be receptive.
01 Feb, 2008, drrck wrote in the 7th comment:
Votes: 0
DavidHaley said:
Well anyhoo, random thoughts, don't mean to hijack so will stop now.


On the contrary, it seems that I've had many of the same concerns/thoughts/etc. as you have. Feel free to elaborate more if you like.

For me, it's a tough decision to deviate too far from the text-based format. Probably a vast majority of the reason I still enjoy MUDs to this day is the level of depth, detail, and innovative features that you get from playing a good one, which are near (if not completely) impossible to get from a graphical game. On the other hand, as you brought up, there are a ton of similar features that you can only get from playing a graphical game. I'm hoping to find some middle ground that incorporates as much as possible from each genre, without leaving the game feeling like a gimped version of both.

Some things that I like that are (to my knowledge) MUD-specific, or at least work better on MUDs, are:

* Information display - it's been my experience that graphical games try to use way too many symbols or other vague graphical representations of information that would often times be much easier to understand in text (i.e. the approximately 1 trillion different symbols in Guild Wars that get displayed when you get hit with effect spells -vs.- blatantly obvious strings in most MUDs that describe what just happened).

* Consolidation - it's quite hard to represent a large number of different objects graphically, as they would appear in real life, within the confines of a "room". Some prime examples of this are situations in games such as Diablo 2, where you amass entire screens full of dropped items on the ground. It's so annoying, in fact, that developers had to add a key command (I think it was <Alt>) to bring up the text for each item on the screen. A short list suffices on a MUD, without overwhelming players.

* Environment representation - I think it's actually counter-intuitive to say that MUDs are "better" at representing an environment, so a more accurate word might be "efficient". A typical room on a MUD can encompass anything from a 3x3 closet to a giant cavern. In creating a tile-based graphical game (what I feel is the easiest way to transition from MUD to graphics), how do you incorporate this? It would look and feel quite odd to have a 1-tile "giant cavern". It's not restricted to scale, either. What if a room has a few signs, a road, a tree, a hut, etc.? How do you represent all of this environmental information within the confines of a tile? It can't be feasibly done, and requires a complete restructuring of your representation system. Everything now has to be scaled and arranged properly and you have to abandon familiar room-based design techniques altogether.

* Information retention - If you cast a chain lightning spell on a MUD, you're usually informed that it just hit mob A, B, C, D, and E. This information stays on the screen until it's scrolled off (but is usually there long enough for you to comprehend it) and can play a key role in your strategy. On a graphical game, you'll see a quick lightning animation flash back and forth between 5 different avatars, and whatever information you could have gathered is almost instantaneously lost. The information loss can vary from partial to total according to the situation and how well you're paying attention (and how much information you have prior to the event), but it's still an issue.


Anyway, there's plenty more but I've already practically written a novella.
01 Feb, 2008, David Haley wrote in the 8th comment:
Votes: 0
I had a large reply to this written but then lost it due to accidentally closing the tab. :sad:

Short version:

1. Yes, graphical games are hard for innovative features because you need to split development time between server and client. Not nice.

2. Information: agreed. We already knew symbols were hard to grok due to trying to display ASCII maps of complex scenes, so it's funny to see same things happening elsewhere. On the other hand symbols have advantages once you get used to the symbol set.

3. Consolidation: agreed. Also, since text games usually don't have position, you can group items into one line in the item list.

4. Environment: I think you would have to change the paradigm somewhat and say that a room is a collection of tiles. In fact, it might be more advantageous to simply drop all notion of rooms, as you say.

5. Information retention: true, but on the other hand sometimes seeing something visually is much more compelling. I'm thinkin in particular of tactical information.



I'll probably rewrite some of what I had before at some point, but it's kind of annoying to have lost it all. Sigh. Normally Firefox remembers tab contents when you undo a close; not sure why it doesn't here…
02 Feb, 2008, drrck wrote in the 9th comment:
Votes: 0
DavidHaley said:
4. Environment: I think you would have to change the paradigm somewhat and say that a room is a collection of tiles. In fact, it might be more advantageous to simply drop all notion of rooms, as you say.


I thought about doing that and then changing movement from room-based to x/y coordinate-based, but that brings up issues of its own. For example, how to handle exits, where to drop objects, etc.

The best thing that I can come up with at the moment is to drop the concept of a room, but maintain that functionality for tiles instead. So an exit is from tile to tile, objects are dropped (and consequently stacked) on single tiles, and characters move around from tile to tile. I don't think I want to allow multiple characters on a single tile, though, so combat would obviously be different. Melee combat would take place only for adjacent tiles, and the possibility of true ranged combat exists, as you can now see your target moving around on your screen and vice versa. This is obviously going to have other repercussions, as well, such as areas being "full" or exits being blocked by people. Hmmmm…
02 Feb, 2008, David Haley wrote in the 10th comment:
Votes: 0
Personally I would also drop the concept of exit as well, at least the free-form exits that SMAUG has. The notion of 'exit' would be replaced by tiles being adjacent to each other, and augmented by things like some tiles being impassable or some boundaries being doors or whatever. In a graphical game it no longer really makes sense to have exits that aren't directional (or portals) – you wouldn't really have keyword-based exits anymore since movement is on Cartesian space, not the free-form "blob" that room-based systems use.

As for where to drop items, I'd also assume it would be wherever the character is standing.

And yes, having people being on tiles does open a lot of possibilities such as proper ranged combat.

And of course, if people can't share tiles, you have very interesting problems of full areas or even just blockading a direction. I think there'd have to be some notion of being able to "walk through" non-hostiles, but that people could also choose to "barricade" a tile in which case you would have to attack them to pass (or otherwise check your skills against theirs, e.g. your speed of movement). Of course, then you need to worry about whether the hostile act was the attack, or the act of barricading in the first place… But clearly barricading is a key element of combat, because it allows you to have the tanks protect the mages, and the only way to access the mages would be to force through the tank.
02 Feb, 2008, Tommi wrote in the 11th comment:
Votes: 0
There was a project out there a while back that used Smaug or MUDOS? anyway one of the LP family as the backend to a 3D MMO style game. I wold have to go googleing to find it, it was pretty interesting.

You build the areas using smaug or lpc and they were rendered into 3d. Someone else might remember this project, if not give me a few days to find it for you.
02 Feb, 2008, Guest wrote in the 12th comment:
Votes: 0
I think this is what you're referring to, yes? http://mudclient.skinhat.com/Smaugfuss

It basically adds some 3D information tags to the existing world file formats. It's a really cool idea but I never really checked into it more than looking over the website when it was first announced.
02 Feb, 2008, Tommi wrote in the 13th comment:
Votes: 0
Yeah thats it, i went googeling for it last night and couldn't find it. had downloaded and looked at it at one stage. I was thinking of making a 3d game and was looking for a toolkit to work with and came across the 3D Mud Client project, which i downloaded and took a look at because of my mudding background.
0.0/13