29 Jun, 2011, Sorressean wrote in the 1st comment:
Votes: 0
Hello:
First, i have a couple of questions to get started with. I have been working on a mud engine, and I would like to make ascii maps to help map out areas. I want to define the maps within a radius of the player, for example show 10 rooms either way. I am blind, so I'm curious how this works for a lot of people. When you look at an ascii map, how do you see what's going on? For example, I could do something like:
===
=x=
===
which would show the player in the middle with rooms to the north, south, east and west as well as northeast, northwest, southeast and southwest. While this makes sense, how would someone go about mapping out exits? maybe the room to the north is blocked by a door or something? Lets say you enter a house, and you start out in a foyer with a staircase that leads up. So the exits could be like north, south, and up; how would you show an up exit? For that matter, how would you show a room above you.

Second, I am looking for a good scripting engine to use in my mud engine. I had origenally thought of starting out in Lua, but that's feeling a bit hackish. I've also looked at Angelscript, but that feels like I'm hammering a round peg into a square hole. Essentially all I want is to use scripting for light lifting. For example, the way I am trying to set up my Angelscript code, each object defines an entrypoint that receives the object that the script belongs to. A global property may have worked, but that requires that i set up a separate engine per object, which is going to add a lot of overhead. I will expose some methods to the scripting engine, perhaps even allow for commands to be created, as well as events to be attached. My solution for events would be something like this:
void main(Entity obj)
{
obj.events.AddCallback("OnEnter", OnEnter);
}
void OnEnter(EventArgs args, Entity caller)
{
//do something here
}
Is there a better engine that would be suited for this?

Lastly, I would like to request any sort of contributions, suggestions, comments, and ideas toward the engine. The goal of Aspen is to be a light-weight flexable barebones engine that is easily extendable but does not require you rip out a lot of systems to make something happen. I have spent a lot of time with other mud engines, like Circle and others, but I always felt like I was going to end up spending more time ripping code out than I would have actually adding code. Aspen solves this; I try to use a modular design so that the core of the engine does not need to be edited, tweaked or changed in order to add functionality to the engine. Modules are for adding systems such as combat, a space system, etc, while components are for extending objects. With this setup you can make a weapon that can function as a container, or a worn item that can function as a container without putting all the functionality of a container on every object. If you are interested in looking at the code and possibly contributing, your time and effort would be greatly appreciated. I have the code up on googlecode:
http://code.google.com/p/aspenmud

Thanks,
29 Jun, 2011, quixadhal wrote in the 2nd comment:
Votes: 0
I'm not overly fond of ascii maps most of the time (I find they detract from immersion), but if you want one, my suggestion is to make one that maps each cell on the map to a chunk of terrain (IE: a room). The two most common types are ones where the map is simply a 5 by 5 or 10 x 10 grid of symbols, with the player at the center.

…~~
…..
..@–
%%|%%
%%|%%


In that example, the periods would be something like grassland or plain terrain rooms, the tildes would be water, the percent signs would be woods or forest, and the dashes and pipes would be a road. The at symbol is traditionally the player, as the whole display idea came from the roguelike games (and nethack in particular).

Another popular map style is to show exits as lines, essentially double-spacing the map. So if the room you're in has an east and south exit, you'd print spaces in the other surrounding cells.

.-.-. ~ ~
| | |
.-.-.-.-.
| | | | |
.-.-@-=-=
| | | | |
%-%-|-%-%
| | | | |
%-%-|-%-%


Not as useful for outdoor maps (where most exits are connected and can be used), but this can be useful for indoor areas where many of the directions won't always be used.
29 Jun, 2011, Runter wrote in the 3rd comment:
Votes: 0
I prefer displaying walls rather than exits. If you let each room be represented by a 3x3 cell with the center always empty (represent standing there) then you can full in parts of the cell based on where lack of exits exist.

A simple example follows for a room with no exits.
###
# #
###


Or a room with an exit in each direction:
# #

# #


I also usually display up and down exits with ^ in the top right corner or V in the bottom left replacing a wall tile if needed.
29 Jun, 2011, Rarva.Riendf wrote in the 4th comment:
Votes: 0
You can look at MapMakerV2, it works quite fine.

What I added to the mapper is to only display the rooms the player actually visited. It makes no sense to display the castle entire floor when a player is only at the gate and cannot see the rest. Same for a forest etc. I 'may' make so in open field he sees some more 'rooms'; but that is not even sure, as I consider field places like being 'larger spaces' , But that is because the mud is not coordinated base as well. (so a field room is to be considered like 100meter, while a 'room' is lot smaller)
0.0/4