From: <x51...@fe...> - 2001-04-22 21:11:04
|
> I've been thinking about map piece and cross-server portals mostly (It's > > just my style to start with the harder problems first), and that as long > as > we have this, why not apply the same or a similar system to smaller > things > like doors and windows. > > You've been thinking doors and windows and aren't thinking much about > multiserver yet and think I'm nuts for designing super-complex doors. :-) I have been designing Arianne for 3 years, and I have learn with the time that simple is better. Once simple version is running, it is easier to try a harder one. I also usually try to go for the complex way... the result is a great amount of time lost on something that may not run or if it runs we don't need it. I didn't said that I haven't though about multiserver, simply that we don't have even running a single server version. What game that is not even playable are going to requiere a multiserver architecture, that by the way is a lot of more complex that the single server one. > > > The Crude-But-Effective Algorithm > >WOOOOO!!! > >It won't NEVER run. > > Sure it could ('could' being the key word). It's basically follows the > same > plan as what you outlined only it implements it a little differently. The simple version will run. To know if the complex one will ( and it will of course but not perhaps at the requiered speed ) it will take too much time. Really trust me, Simple is better. Let's hack later, when it run. > See, it was so weird because I was thinking about the worst case - the > portal crosses to another server, and silly me, I never bothered to > simplify > it for same-machine. No problem, the best to show is always worst case, at least if worst case is possible to happen often. > > > >So the first approach is to add a comprobation and if the object being > >checked is a portal ( or have linked a portal, in whatever way we > finally > >do it ), then we also check objects of the other side. > > better for same-machine, worse for cross-server - uses 2-way > communication. I let multiserver away intentionally. Anyway as a sneak preview, multiserver don't work in that way. Each server will have a piece of map that will be as independent as possible from the others. So it shouldn't be possible for one server to access other server objects. > >This can be solved, by keeping a list of visited worlds and simply > >omiting already visited ones. > > better for same-machine, worse for cross-server. Sure, this one won't work with multiserver. > > > The portals I have in mind are a way of seamlessly 'flipping' > > between > >two or more maps without this being noticed. But this is a bad, imo, > the > >player should notice that he is going to use the portal, as the portal > >crossing operation is a high cost one, both in CPU and Bandwidth. > > yeah, probably (but in CPU?). Bandwith probably has a high potential to > be > optomized later (pre-caching maps and stuff). No big deal whether or not > the > Player receives 'warning' of some sort first. Crossing a portal will requiere a full perception message, while on normal map a delta perception message is enough. With a warning, I mean something ala Baldur'd Gate. So you have to click on the portal ( door, window, ... ). > >We only want that a fireball spell inside a house if visible at the > >outside. We are talking of no more than 75 meters radious sphere. > > A sound might be a better example. These would have a longer range and > be > much more common. longer range!?!?. We aren't doing a simulator, it is just only a game. Making actions with a bigger range can suppose a big drawback in performance. > >My idea is more simple, it object get near the portal ( on my idea if > >object USE the portal ) he is automagically moved to the other map. > > ok for doors. what happens at the border of map pieces? Map pieces? The one inside the world? Nothing. You mean when you reach the end of a world, and then you want to move to the next world? As each world may have a position and a size, it won't be too hard to choose the next world and move character to there. ALWAYS speaking on a single server system. > >Also I want to remember that the game is not about travelling through > >Portals or cast spells on portals to see what you break on the other > side. > >It is a game about ruling, about playing with friends, about > conquering. > > > >Definitively Arianne is not for the single Hack & Slash Player. > > That reminds me, I've been thinking a bit about groups, societies, > team-play, etc. and how they might be done (though apparently not quite > enough about portals). I haven't seen any plans regarding this here. My idea is to let the world build itself, so if you want to group, just go with them. But of course I let all this open for later. > WorldForge had a little on this. Is there any thinking on it yet? A lot > of > this seems to be largely unexplored territory for games. (And yes, I > know > it's 4-5 releases away or whatever so don't try to remind me.) No, at least at my side. By now our RP Man is out for 3-4 months, Dante & Pawel have my approval ( and Brian one's I suppose ) for RP decissions. My main focus is to get: - RP Engine to work ( Brian is doing great work with Python ) - Renderer plug-in system to work. - World structure to be stable. Miguel Angel Blanch Lardin -- http://www.arianne.cx -- Arianne -- The free open source massively multiplayer online role playing game nuclear cia fbi spy password code encrypt president bomb iran irak korea cuba Ala yihad mosad kgb free freedom human rights yugoslavia kosovo ebola dna -- Echelon must die -- |