Creating a custom world

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
retard



Joined: 03 Nov 2005
Posts: 3

PostPosted: Thu Nov 03, 2005 12:24 pm    Post subject: Creating a custom world Reply with quote

Hey everyone,

Sorry if this has been posted and discussed before.

I have been fiddling around with various mud codebases the last few months, learning how they work, and getting a better grasp on c/c++ programming as I mainly worked with Visual Basic onle.

Now after some time I have decided to go a bit more into the mud development scene and creating a much more custom based mud where I can create/design everything to my specifications.

Now although I am looking at creating a very large world, I am also thinking of having the world as detailed as possible, thus leaving me with using one of two ways to go about.

I could either use matrices or on the otherhand use links. By using matrices the main problem I am seeing is that once the world becomes imensely large and detailed it will become quite memory hogging, but as a plus point I can create a very extremely detailed world, where with using links it would be possible to create the same size world using much less memory, though I am not entirely sure how detailed it can be.

Using matrices would not be a problem for me as I am quite sure on how to go about, but using links might be a bit more chalenging.

Any advice would be appreciated.

Kind reagrds,
Retard

P.S Don't let the name fool you.

(--) EDITED (--)

If anyone knows of a mud using such a system where the staff would be able to assist me with some ideas and information, that would be a great help.
Back to top
View user's profile Send private message
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Thu Nov 03, 2005 3:03 pm    Post subject: Reply with quote

Could you define your usage of matrices and links?

When I think of a matrix, in relation to a mud, I'm thinking a coordinate-based system. For links it reminds me of a room-based system. Perhaps I am completely off on this however. Ultimately, the normal understanding of both systems is as just different extremes of the same concept. A 'coordinate-based system' is simply a room-based system with very small, transparent rooms. A room-based system is simply a coordinate-based system with larger coordinates (and not all coordinates may exist among other discrepancies).

Personally, I'm a big fan of a hybrid; semi-transparent rooms. By this, I mean that the boundaries (or links) between rooms easily conduct information. Players can see what is going on in the next room over, with certain exceptions (like if there were some visually opaque surface in the way). Players can hear and sense things that occur in nearby rooms. Gasses and water can move from one room into another following using a simplified physics simulation (cellular automata). Weapons may pass from one room to the other by design.

I'm not quite sure how a coordinate-based system could be far more detailed than a room-based system (given the above transparency options). Suppose your coordinate-based system generated descriptions for the player automatically to great detail. Now every room needs a similarly detailed description, but you already have an algorithm for description generation that can merely be applied from the standpoint of the room rather than the player. Rooms also may allow pre-written descriptions that may or may not be more detailed, but certainly involve human creativity and may be more interesting and deep.

Memory-wise, a room-based system is likely to eat more than a coordinate-based system. This isn't necessarily going to be the case however. A coordinate-based system saves a lot on memory by dynamically generating descriptions. For a large mud though, all the objects and players in the world can't (shouldn't) be scanned through all at once, so there needs to be some method of efficiently partitioning the data so it can be referenced quickly. This will typically be what eats the memory in a coordinate-based system (binary partitions, octrees, etc). A room-based system, arguably, is just a design based on the partitions of the coordinate-based system (which is therefore just as effective). The extra options available to a room-based system however (human-written descriptions, for example) may necessitate more memory being eaten, but that is due to the usage of a feature - not because it is a room-based system.

- Kelson
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
retard



Joined: 03 Nov 2005
Posts: 3

PostPosted: Thu Nov 03, 2005 3:22 pm    Post subject: Reply with quote

Hey,

Ok let me try and explain it in the sense that I have come to understood matrices and links.

When using a matrix you would create a location consisting of x, y (and z) amount of co-ordinates, thus having [0][0] at a point the same with [5][100] for example. So you would be either using a single point on an array as a point within a location.

By using links you would have a parent (which would be the location) with links to childs (basically a multi-branch tree system), where the parent would have pointers to each child and each child would then have pointers to the parent and to corresponding child lists.

Although the latter of the two is so much harder to set up, and get it to work correctly, I think it could be a more suitable way of doing it.

In other words, using links you would go in the same way as how many First Person Shooters these days are designed, where the world (current stage) is the parent, a building in the world is a child, a door within the wall is a child to the building, etc.

Hope this explains it.
Back to top
View user's profile Send private message
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Thu Nov 03, 2005 4:23 pm    Post subject: Reply with quote

If I'm getting this, you're talking space partioning data structures versus raw coordinate storage.

Go with space partioning for relatively static things (that is, if players aren't going to be rearranging 90% of your mud all the time). You're not going to lose detail, all the information about coordinates and so forth survive. It is not, however, more memory efficient, but what it does do is allow you to do is parse your data very efficiently for field-of-vision and what not.

That said, I offer one caveat to the above. It depends heavily on how you're going to display things. Space partionining is great if either a) players are on an ASCII map but can't see what's behind them, or b) you're generating descriptions. If you want a standard ASCII map type setup, go with multi-dimensional arrays since that's how you're going to be displaying anyways, and simply cache to disk (or... use generation algorithms to generate on the fly).

My 2 cents.
Back to top
View user's profile Send private message
Author Message
retard



Joined: 03 Nov 2005
Posts: 3

PostPosted: Thu Nov 03, 2005 4:37 pm    Post subject: Reply with quote

Well the players will have a field of vision, so in terms they won't see what is behind them, although there may be circumstances which would allow them to know (not see) what is behind them, like a type of sense.

Also all descriptions will not be static but generated, as everything will depend on the surroundings. For example you might be in a location right now and leave, when you come back there might be a large hole in the ground, due to a spell a mage casted which caused it.

In otherwords, the concept of the world is to have it to interact completely with players, so there is a tree, the player can chop of the tree, but the location won't have a description saying there is a tree, seeing that a tree would be an entity like an object which is placed there.
Back to top
View user's profile Send private message
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Thu Nov 03, 2005 5:34 pm    Post subject: Reply with quote

This is difficult because we're not on the same page lingo-wise. With mishmash jargon, it's... like mishmash jargon. ^_^

Basically, my point is thus... the advantage to partitioning systems is not space or speed, but the ability to use their inherent organizational schemes to handle certain calculations quickly. You used the FPS example - the main reason first BSP trees and then other, more complicated algorithms found a place in FPS development was the need to draw things "in order" and based on vision ("Painter's Algorithm"). If you're aiming at applications like that (so, generating beautiful natural language descriptions with occlusion and the works, or say limited FoV, or say the need to handle flamethrowers, etc) then I'd say go with partitioning algorithms and data structures.

If your world is going to be like most of the other muds that attempt this, and appear to the player like:

$#*@*$*#@*#^*^
@#*#^*@#*^#@*
#@*$*#X*#*^*^*#
#$@!*$*@#$*^*^*
#$@!*$#@!*$*^*^*

There is a tree stump here.
There is a fresh log here.
There is an ugly, green giant holding an axe here.
There is a pretty, purple mastodon to your east.
There is a smelly, sarcastic Tyche to your west.
There is a big, hulking KaVir holding a Godwars far to your south.
There is a small, orange Kelson far to the north.
etc...

Then go with multidimensional arrays and cache.

Maybe there are other approaches, other arguments. This is my position, though.
Back to top
View user's profile Send private message
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Thu Nov 03, 2005 7:41 pm    Post subject: Reply with quote

Kelson wrote:
A 'coordinate-based system' is simply a room-based system with very small, transparent rooms.


I tend to think of it as being a room-based system with only one room ;)


Spazmatic wrote:
$#*@*$*#@*#^*^
@#*#^*@#*^#@*
#@*$*#X*#*^*^*#
#$@!*$*@#$*^*^*
#$@!*$#@!*$*^*^*

There is a tree stump here.
There is a fresh log here.
There is an ugly, green giant holding an axe here.


The problem is that unless you've got a graphical client (or a VERY simple game), the graphics alone aren't going provide sufficient information for the player to go by. Equally, if things can be at all sorts of positions around you, words alone are going to be much harder to digest when trying to work out your position (okay so there's someone to the north-west, and...wait...another person to the south-east - they've got me from both sides! Should I retreat south-west or north-east? Hmmm (quick calculation) it's slightly faster to move out of their arc of attack if I retreat south-west...*whack* (falls over the log, landing flat on back) - oops!).

You said "most of the other muds"...have you seen any better solutions?
Back to top
View user's profile Send private message Visit poster's website
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Thu Nov 03, 2005 8:25 pm    Post subject: Reply with quote

Quote:
You said "most of the other muds"...have you seen any better solutions?


When I said "most", I meant "most". It's a popular method.

As fro the second question, "better" would depend on your goals, no? If you mean for processing large amounts of information very quickly, I haven't seen a better pure-ASCII solution. I'd advise, tough, that if you're pushing in that direction, create a graphics-text hybrid client.

However, that's OT. My main point is that, that's the most popular method, but it doesn't work as well for, say, a mud built for questing and problem solving. In that case, things can be slow and information doesn't have to arrive exceedingly quickly, and you may prefer a beautiful, intricate world with dynamic descriptions. That said, I don't know of such a mud... I built a prototype (half-a-prototype?) system for it, though I hadn't implemented most of the description generation algorithms yet (still operating off very basic templates). My research directions moved away from text towards computational learning theory, and I haven't had time to work on it again since.

So, if he is proceeding in that direction, then I'd recommend multidimensional arrays with caching. If he wants to try for a pure-text interface with long, dynamic descriptions (not necessarily better, but it appeals to both the algorithm-lover and prose-lover in me), then I'd suggest partitioning data structures. Also, if he wants occlusion and the like, he might still want to go with partitioning.

And yes, I realize my use of "dynamic descriptions" is vague. I'm rather hoping it's clear enough that everyone can fill in the gaps - I hate writing technical definitions.
Back to top
View user's profile Send private message
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Fri Nov 04, 2005 10:17 pm    Post subject: Reply with quote

KaVir wrote:
I tend to think of it as being a room-based system with only one room Wink


I actually wrote that at first, but changed it since it would seem a hack to include an internal coordinate system with regard to abstract room spaces within a room-based system. Were that the case, the rooms are no longer the 'physical' rooms we describe players in (more appropriately, the room is a certain distinct 'view' of a location than the physical boundaries), but rather merely a partitioning of the underlying coordinate-based system.

Of course, I'd find the transparent room implementation interesting since it would handle a lot of sub-structure traffic (one person existing in two, three, more than six rooms perhaps).

- Kelson
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Tue Nov 08, 2005 2:15 pm    Post subject: Reply with quote

Partitioning space can have "issues" if you're not careful.

For example, suppose you're inside a house, but the door's open - how do you handle the line-of-sight calculation that allows a player inside the house to see someone outside the house if the door is directly between them, but not otherwise?

Space partitions also tend to make for a rather static environment. If the space inside a house is not continuous with the space outside it, what happens if someone blasts one wall out completely, but leaves the others standing? You've moved from an enclosed space to a non-enclosed one, but you still have a lack of visibility on 3 sides. This is actually one of the reasons why so many FPS games don't allow you to blow holes in walls with a rocket launcher (except in specifically designated places) - they depend on having walls that represent absolute sight-barriers, so nothing beyond the immediate partition has to be processed for visibility.

These are things that one can work around, but care is needed.

I have to agree with KaVir as well - it's easy to get too hung up on accurate spatial positioning in a non-graphical environment. If the relative position of other objects is to matter, the player really needs much detailed and immediate feedback about the relative position of other objects than a text-based interface is able to provide.
Back to top
View user's profile Send private message
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Wed Nov 09, 2005 12:02 am    Post subject: Reply with quote

shasarak wrote:
If the relative position of other objects is to matter, the player really needs much detailed and immediate feedback about the relative position of other objects than a text-based interface is able to provide.


Are you suggesting that a picture is worth a thousand words?
Infidel! Razz
Back to top
View user's profile Send private message Visit poster's website
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Wed Nov 09, 2005 1:17 am    Post subject: Reply with quote

Quote:
How do you handle the line-of-sight calculation that allows a player inside the house to see someone outside the house if the door is directly between them, but not otherwise?


I see this as a problem with a solution. That said, I'd have to review the literature to find a good solution. However, don't see it as a big issue.

Your next point, though...

Quote:
Space partitions also tend to make for a rather static environment.


I know, I've built an engine before. Like I said, there are limitations, and it's not good for highly dynamic systems (I think I mentioned that, I'm pretty sure I mentioned that).

That said, it IS possible. New partioning algorithms use some clever tricks to allow limited effect changes pretty efficiently. However, they tend to suffer in other areas, which is why you don't see them in most FPSes. However, some of those problems deal with locational details that may be partially avoided in text.

The fact is, it's not perfect, and I don't recommend it for most situations. Only the very specific case I described.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign