Top Mud Sites Forum - View Single Post

swampdog · 07-03-2012, 10:50 AM

Having this system in mind from the beginning is pretty much required. You can also think of the room as the player's "view", in addition to container. One method I have seen used is moving the room instead of the player, updating as needed based on location, and splitting off new rooms to carry other players or creatures when they seperate.

I mentioned the simple math because it becomes easier to do the above when you can use your co-ordinates to generate and retrieve information (like terrain type) using . Now you don't have to store that terrain type anywhere, you just have to call your noise function with the same arguments as you did initially (x, y, max range of types, and generally a randomized, saved seed for each new map) and you will always receive that terrain type back, as part of an overall map. I think the room space definition comes down to codebase and the actual gameplay you want to represent, which might be a global fantasy overmap or a galaxy of solar systems. It took me about a year to do the following, starting with gridding all the rooms and generating them at planet creation time and then moving to an on demand system:

1 50x50 and 3 100x100 planets running (how well this will work with more players is unknown (this example has about 15 players running around)) but just re-using some rooms that are not occupied is a memory saver compared to creating the actual rooms at each point:

From the player's point of view, he can walk/drive/fly around with only the room he is in. All his stuff is where he left it because the rooms persist when occupied, but when he treks between points of interest he's actually in the same room the entire time, updating the view as he goes.

Once he goes into space he's inside a solar system that handles all interactions (scanning, auto pilot, move to coord, docking, orbitting, firing) based on object co-ordinates and can hop out if he wants, floating around as the ship leaves him behind. So it's far from a complete 3d co-ordinate based MUD but based on the type of game you want I think the specs on that are going to vary wildly. Window line of sight, interior room position would be a big deal in a shooter or survival game but doesn't matter at all on a surface warfare game with orbital strikes and vehicles and vice versa.

Arrows were a bad example, I was thinking of bullets from an FPS - a more reasonable MUD/MOO example would be a boat or starship on a heading at a certain speed.

07-03-2012, 10:50 AM	#43
swampdog Member Join Date: Jul 2010 Posts: 31	Re: Can MUDs implement range/distance? Having this system in mind from the beginning is pretty much required. You can also think of the room as the player's "view", in addition to container. One method I have seen used is moving the room instead of the player, updating as needed based on location, and splitting off new rooms to carry other players or creatures when they seperate. I mentioned the simple math because it becomes easier to do the above when you can use your co-ordinates to generate and retrieve information (like terrain type) using . Now you don't have to store that terrain type anywhere, you just have to call your noise function with the same arguments as you did initially (x, y, max range of types, and generally a randomized, saved seed for each new map) and you will always receive that terrain type back, as part of an overall map. I think the room space definition comes down to codebase and the actual gameplay you want to represent, which might be a global fantasy overmap or a galaxy of solar systems. It took me about a year to do the following, starting with gridding all the rooms and generating them at planet creation time and then moving to an on demand system: 1 50x50 and 3 100x100 planets running (how well this will work with more players is unknown (this example has about 15 players running around)) but just re-using some rooms that are not occupied is a memory saver compared to creating the actual rooms at each point: From the player's point of view, he can walk/drive/fly around with only the room he is in. All his stuff is where he left it because the rooms persist when occupied, but when he treks between points of interest he's actually in the same room the entire time, updating the view as he goes. Once he goes into space he's inside a solar system that handles all interactions (scanning, auto pilot, move to coord, docking, orbitting, firing) based on object co-ordinates and can hop out if he wants, floating around as the ship leaves him behind. So it's far from a complete 3d co-ordinate based MUD but based on the type of game you want I think the specs on that are going to vary wildly. Window line of sight, interior room position would be a big deal in a shooter or survival game but doesn't matter at all on a surface warfare game with orbital strikes and vehicles and vice versa. Arrows were a bad example, I was thinking of bullets from an FPS - a more reasonable MUD/MOO example would be a boat or starship on a heading at a certain speed.