AW: [Arianne-devel] Arianne new design - Codename Ulises -

[<Min...@t-...>]

I personally think most of the stuff you write there sounds pretty
cool... I am all for it....

However that part of the design is kinda independent from the design
stuff I was talking about,
as my stuff is more low level and affecting only the data structures and
access structures...

I think first we need to redesign my stuff and then redesign that stuff
you are talking about...

Also I think that although I dont know Lua at all its a good idea to use
a scripting language,
but maybe one that most people know?

I dont know if there is a way to implement it using PHP, but if there is
I would prefer that cause
its the main scripting language on the net (and heavily on the rise) and
about everyone uses and knows it...

Second probably comes in Perl or Python. (Yes I know there are more
scripts for Perl out there but Perl is
used less these days and PHP is coming up pretty fast)

Of course I am biased cause I know PHP better than Perl... but maybe its
not even possible, so I can learn whatever
scripting language is needed...

For the redesign, well you got my code miguel... I think the data
structures need to be made a lot more efficient and bug resistant,
I tried to do that. I am still missing a BSP data structure, and I am
not good enough to implement a BSP from scratch.
I worked with one once and implemented it but had a lot of help back
then.


For my design ideas I will only plot the outlines here, some of it I
also wrote on bug tracker:


1. World
--------

- contains indexed Pieces in a map.
- manages those and can later hold the distributed server code by adding
managing code that syncs the pieces with other servers.
- Gives out piece pointers to anyone requiring one.
- Adds Objects to the world by selecting the correct Piece for the new
Objects position and calling Pieces CreateObject function.

2. Piece
--------

- contains indexed Objects in a map (every Object is in here, its a
ObjectID -> Object Pointer lookup table)
- contains helper structure:
        - a visible Objects map (used for knowing which Objects are NOT
in a slot of another object)
          (LATER: a BSP tree of the visible Objects (used for building
perceptions based on player position) (NOT CODED YET AT ALL))
- Creates, Modifies, Deletes Objects. Has member functions to do
everything concerning objects. No one else can touch an object
- Moves Objects from VisibleList into Slots and vice versa by using
Objects member functions

- The size of the piece can be very big (like maybe 1000 screens and
10000000 objects if the server can handle it),

  HOWEVER: Every piece NEEDS to have unpassable walls on every side of
the piece. You CANNOT view past the borders of a piece
  by any means. A Piece is something like a ZONE in Everquest where you
are in. To exit it you must take a special Exit that leads
  to another Pieces Entrance. That will be coded in the multipiece code
later on.

  Players should never walk up on a flat wall though, the actual layout
of the piece may be round or better irregular
  by placing unpassable graphics all around the area so that it looks
cool and then defining exits. ("Exits" Not coded yet)

  Currently the whole arianne is using a single piece only. THATS
PERFECTLY LEGAL.
  The optimization will be inside piece, so that even if you have a very
LARGE piece the server wont die while doing perceptions.
  Thats done by the BSP tree.

  Pieces have two large goals:  - present a zoning concept where you
definitely can DIVIDE a world into areas which have no influence
                                  on another, thereby:
                                - making it possible to outsource pieces
to other servers later on (I dont wanna redesign later on AGAIN)

  Every piece can have any size you choose. You can make a small piece
with many objects like a town and then a very large piece with almost
  no objects like a large desert in a single piece without any
performance penalties.

3. Object
---------

- contains Object data, attributes and slots
- Has member functions to access most of those
- Slots are maps of Object IDs
- Only Piece can access Object, everything is private


Big Overview
------------

- Nowhere in the code there will be any Object copying or creating
EXCEPT in World and in Piece

That means it is not possible to create an object and lose track of it.
Object creation works as follows in 3 steps:

1. Call Piece::CreateObject (...)

  - An Object is dynamically created
  - The Object Pointer is added to the complete ObjectList
  - Some basic things are set like a new ID is created and the position
set.
  - ObjectFactory is called on the Object Pointer, which loads up
attributes and slots based on Object type (= human or orc or something)

2. You call Piece::SetObjectAttribute and set everything you want for
the new Object

3. You Add it to the Visible World by calling Piece::AddObject (ID)

Now the worst thing that can happen is that you have a "renegade object"
that was created but not put to either VisibleList
or another objects slot. Those objects can be easily filtered out and
managed in some error handling code later.

Or you just let them cause the garbage collector will delete them anyway
on piece destruction.

Perceptions:  Will call Piece::GetPerception (player) which uses
currently a map and later a BSP tree.

TODO: I am not perfectly sure how this will work out, but I think
Piece::GetPerception will have to actually send it when called cause
of performance reasons. It makes sense that when Piece actually HOLDS
the Object data it sends the objects itself when being
called by a higher object to do so.



Ok thats it for now, going back to coding... please ask questions about
other parts I may have missed that need integrating...

SkyFlash