...That there were some way I could setup an infinite (or at least big) universe to explore, so that I would not be limited by those darned 500x500 maps (anything larger crashes). If only I could just say, "Planet, appear when the ship is in range of 3920x2046!" and it would do just that. There's nothing I hate more than launching my ship off at light speed and hitting the far end of my 500x500 map in just under 10 seconds...
If only there were a way...
ID:154240
 Mar 17 2002, 8:31 pm
|
|
That would probably work, technically, but there are two major downfalls I can see if it works the way I think it does.
1. Since it's opening multiple servers, wouldn't communication be limited only to the current server? 2. Horrendous lag/loadtime whenever you cross a map, since a new map has to be generated each time you do. Of course, I could use smaller maps, but then it would happen more often. | |
You could just make like 500x500 maps, and bump up the Zs for the maps. Then at runtime add map warps for the edges depending on x,y location in respect to which z level your own. Then like my 100x100 maps in Kemet, you could create larger maps out of smaller ones. Just make the map-map deal consider as Zoning.
LJR | |
I think what he really wants is one big map... I don't think he wants the rather noticeable transition from one map to another to ruin the impression of a huge expanse...
So any suggestion involving multiple maps isn't what he's looking for (of course I'm only a ssuming what he's thinking... I could be wrong...) Although since it would seem that a map transition is the only way here... We'd need to make it less noticeable... The best way to do this would be to move the warp tiles in from the edge by one tile more than the mob's view (just for good measure)... That way...he'll never see the edge of a map... It'll always look like the map goes on forever...besides the small blink when he warps from one map to the next... | |
The best way to do this would be to move the warp tiles in from the edge by one tile more than the mob's view (just for good measure)... That way...he'll never see the edge of a map... It'll always look like the map goes on forever...besides the small blink when he warps from one map to the next... If what I wanted to do were obviously doable, I wouldn't be wishing. The problem with this approach is that the sudden change in star formations is obviously noticable - as is an planets or nearby starships that suddenly vanish... | |
Which is why I said the "best" way to do it (meaning the best available)... Not that it's what you want...but that it's the closest you're going to get...lol
As for the problems raised...just don't put anything within view of the edge of maps... And if you do...make sure to put the same thing in the correct place on the next map... (I.E. if a planet is 1 tile behind the mob when they warp...put another one on the next map at 2 tiles behind them...so it looks like nothing more than they moved past it (except of course for the slight blink and jumpiness of warping)... Then the only really noticeable changes would be if a player saw another player warp off of the map... I suppose this could also be taken care of by creating a dummy copy of the warped mob on the old map and have it continue on in the trajectory of the old mob... That way...any witnesses would simply see a mob fly off the edge of their view... By the time they could catch up with it...they themselves would be warped to the new map and would then see the original mob... Of course that's still not perfect...but it's better than nothing...lol | |
If what I wanted to do were obviously doable, I wouldn't be wishing. The problem with this approach is that the sudden change in star formations is obviously noticable - as is an planets or nearby starships that suddenly vanish... You could try doing something very, very, very evil, which I originally wanted to do for APC (my bot-programming game -- that's why I was intrigued by mention of Robosport ;-)). That very very very evil thing is to create screens exactly equal to the size of the player's viewport. Whenever the player moves, the server tells him what he/she now sees based on the player's new coordinates. Naturally, you'd want to constrain the universe to local areas to prevent the server from having to poll the entire world to see what is within a certain range of the player... but, because you're essentially creating your own internal coordinate system, the boundaries of maps are completely non-existent. You could easily model a 1000000x1000000x1000000 spatial map with a setup like this, and it'd actually be fairly speedy too if you segmented it logically. The server-run viewscreen for the player would only ever have to be aware of the cube surrounding the segment that the player is in (since the player would have to be aware of nearby segments when nearing the border of the current segment). Basically, it mimics what BYOND does right now with the client/server combination, but it allows for a literally infinite map. At the same time, though, it's still client/server -- all of the displaying is happening on the server instead of the client. This means that handling synchronisation of the players is up to you. (This is the model that Warrior is going to follow, by the way.) | |
Not bad.. dynamically generated map. Also for pre-placed items, you could make a List X/Y List Matrix, which could be polled to see where items are. And you store the item type as numbers, letters or go a step more and add list to the locations so you could stack stuff just like BYOND does.
I've already made my own Tile Blit Engine before with Direct Draw and Win32API. 2D Matrix maps is what I used too. But now if I had to do it over again without BYOND I'd include list like item so more than 1 of something could be stored there. LJR | |
Have no map. Then generate terrain the screen of the player who's moving and as they move save the turf and it's relative coords in an associative list. Then just call up those turfs via the associative list when you fly over them again.
That way if you fly in a straight line it will just create a universe that is one big straight line. See how simple that is? :p [Edit] I just finished reading the rest of the posts and this is basically what Spuzzum said to do. Dern Spuzzum, stealing my ideas before I even have them! :p This is actually what my split screen demo essentially does. All I have to do is give it a list generated from the world associative list instead of the other players viewing window. | |
"seem" being the key word ;)
I'll go tinker, I may be getting myself into more than I realize :p [Edit] There is one major downside to doing it using the screen. No animations are shown, it just showns the raw movements :( I'll have to think about using the map some more. Animations would be a shame to lose... | |
English wrote:
"seem" being the key word ;) It would probably be best to just give everyone their own little mapspace. You will have the full power of the map (including animations) and it will be a bit more intuitive than munkeying around with more abstract screen objects. It would be very simple to set it up so that each player had their own Z layer. (If you do this, make sure to recycle Z layers when someone logs out. ;) ) | |
That's the direction I'm starting to head :) Then I can still use things like oview, view, and the whole suite of built in procs.
One problem that might occur is if many players start to group together (which is quite possible, and quite likely). I was going to handle viewing other players and mobs by creating a "dummy" mob when their general locations cross paths. If 10 players grouped together then you would have 9 copies of each player, per player. That's 100 mobs total with only 10 players. | |
But what happens when these dummy mobs start to interact? What happens if one mob lays a mine, or a few dozen of them, or they have a firefight, etc...
| |
English wrote:
That's the direction I'm starting to head :) Then I can still use things like oview, view, and the whole suite of built in procs. Make the z layers large enough so that when mobs get close to one another you can locate them in the same z layer and they can interact without all the copies. When they get far enough away from each other that they can't directly interact, relocate one to a separate z layer. It will be tricky juggling players back and forth, but that's better than having 10 linked instances of the same atoms. It will be really tricky if 30 people crowd into one area that's too large for one z layer, but they are grouped in such a way that everyone is in view of someone else. Wow! I'm glad this isn't my project. :) | |
Your right, that does sound hard. I'm glad it isn't my project either :) oh wait...doh!
Merging them onto the same z wouldn't be that tough once the basic system is in place. The width and height of that would have to be world.view * 3 + 2 and when they leave eachothers view they would be split again. The trouble comes when 3 or more mobs are involved. What if the top mob can see the middle mob but not the bottum mob and the bottum mob can see the middle mob but not the top mob? What if the middle mob is not a player, will there be two copies or merge the two players? This project seems to have exponential problems already and put me in my place. I vote Spuzzum does it :p The "seem" in my second post seems to have come true. Sorry Foomer, I guess you'll have to stick to your 500x500 map or try to split it up like was suggested. | |
Foomer wrote:
Ugh... There's nothing worse than hitting the "edge" of space. Well, of course there's an edge of space -- there's an infinite amount of edges of space, actually. After all, anything that isn't space is obviously on an edge of space. Earth, for example, is one of the edges of space. (Hee hee, I'm glad Jobe isn't wandering around much any more. I can talk nonsense that seems to make sense and no one really objects!*) Hmm... anyway, I could make a map system, except in my situation I'd be very likely to restrict it to small world.view*2+1 x world.view*2+1 sized screens, with each individual player on a separate Z level -- in that way, anything not player represented is handled off the map in its own code, and only if it actually comes onto one of the players' maps does it show up. Probably the coolest thing about having a system like that is that you could always have a player facing a certain direction, and then skew the objects in the universe appropriately. For example, both players would see another starship "in front" when facing each other. * There's a difference between spam and nonsense, by the way... | |
You might try looking using savefiles, startup(), world.Export(), and world.Import() to dynamically create and link to new worlds as needed. They'll each be a separate server so any communication between them will have to be done through the aforementioned Export() and Import() commands, but in theory this is one way to create "infinite" worlds in a nice, object-oriented fashion.
This is a pretty vague idea that I haven't personally explored much, but it sounds like something that might appeal to your sensibilities.