[the_logos]

No, we're not. With due respect and wishes of best luck to Emil, and without much understanding of what he's doing specifically, I don't believe that a text MUD with static pictures is going to expand the audience for that text MUD much, if any, and I don't believe that the cost of producing the art would be worth it.

All we're doing is creating pretty clients. The main gameplay input and output will still be textual.

--matt

[the_logos]

Well, to call a MUD a "text MUD" or a "graphical MUD" is over-simplifying in most cases. I'm not aware of any graphical MUDs that don't use text, for instance, and while I'm sure there are text MUDs out there that have NO graphics, they're few and far between. Most MUDs will have at least SOME graphics, however primitive. For instance, a graphic on login or wilderness map stuff or customized ansi-art stationary in-game or whatever. Graphics created with ascii characters are graphics just as much as any other kind; they're just far more primitive.

--matt

[Hephos]

[Hephos]

Well you will be able to download the client and play aeonfalls for free with a trial mode.

The client will not work for other muds however.

[shadowfyr]

Hmm. Well Hephos, this looks interesting, but isn't what I meant by crossing the two. The images are obviously static, as the_legos points out, which means the odds of this being possible as a 'free' games, like muds are prone to be, unlikely in the least. I suspect this one isn't. However, a 'bigger' issue than the time and expense needed to make such images is that because they *are* static in nature. What I meant is something like:

Ok, as a new wizard, here is some example rooms in language X, which the mud uses and BTW, if you are making a complex puzzle or want to make a real 3D version of some object or building or even the view of an entry to town, etc, there are examples of that too, using a scene description languages called Y. It shows how to set indoor/outdoor lighting effects, so that it shows the sun and moons in the right positions, etc. For indoors there is an example of how to make the windows show the outside lighting as well, etc. Also rain and other weather effects, tied into the muds weather system, will automatically be inserted into the code before sent to the player, so those are taken care of. All you need to do is use the existing textures, some pre-built objects, etc. and place them where you need them. Or you can make your own, though that can mean the player has to wait a few seconds for the entire object to be sent to them, before the image will be produced.

See, my point? Mud code + SDL, both easilly modifyable to allow rooms, objects, mobs, or even the images of the same, to be inserted, exactly the same way as you currently code 'just the room descriptions'. Did you look at the link I posted? There is one in there, which may not be practical for speed reasons, since it uses isosurfaces, which is I think a little under 800 bytes. Yes, 'bytes', which produces a perfect desert scene. With twice that you could add cacti, additional rocks, etc. Producing a small image for a client, say 200x100 would take maybe 10% of the time to produce and it could go with something like:

After crossing a great desert, you reach an outcrop of weathered stone:

-------------------------------------------------
| <Image> |
...

And it could be a night scene, a day scene, sunset, sunrise, moon in the sky or not, etc. Even overcast and raining if it was the one rare day that might happen in the desert when you come upon it. Even the 'best' muds are basically a thin veneer of static graphics over a what is usually a dynamic system, which could involve everything from basic weather to even droughts, hail storms, forest fires, or you name it, not one of which the images would show, unless someone sat down and spent hours drawing each version them.

What I mean by in between is the best of both worlds. Dynamic graphics, which can adapt to what is taking place in the game, but built using a scene description language that is as easy to fiddle with as the script running the mud itself. It would still take talent to make truely spectacular images, but not the hiring of a huge number of specialists to do it or the stagnation of the game, because there isn't anyone interesting in making new ones. The players end only needs a client with static images for stuff you can't generate easy, like races. The rest is all a client side code library and a 2-3k 'file' sent from the mud when you actually need to show one. Understand now?