Re: [Dev-C++] 'extern const' and std::vector

[Per W. <pw...@ia...>]

I would suggest the use of a map template. The access to a room is fast,
and you need not fill each element, i.e. it's ok with large gaps in the
number series.

One more thing. To keep code simple and allow easy change of it. Don't
allow all code to know how you store and retrieve rooms. Let them call
through a function or object method. Then it is easy to later change to
some other storage mechanism - in-memory or on disk. Just require each
player to have an address token (which might be an integer) to their room,
and let each room have a number of address tokens to neighbour rooms. If
you have a teleporter, it stores the address of the destination room.

One problem with multiple threads. Yes, multiple threads may read the same
variable. However, if someone else updates that variable, you're in for
some serious problems. You really should lock the rooms while updating
them, and deny all read operations while the room is locked.

I assume that you will not allow too many concurrent players. 10000
threads is no good. Even 1000 threads is generally bad. Must each player
run it's own script or what? Normally you might have a single thread
handle a large number of players by just round-robin the work. A player
that haven't sent in a command need not be reevaluated unless a timer has
reached zero - or someone else is attacking the poor sod.

/Per W

On Thu, 1 May 2003, David McKen wrote:

> The rooms are not nesesarily accessed in sequential order.
> One very used
> command (at least by admins) is the goto command. Syntax:
> goto <vnum or
> player>. This can cause an admin in room #300 to need
> access to room #50000.
> Also ceartain other command allow ordinary players to make
> different jumps
> to rooms that are not in sequential order.
>
> The assiging of rooms to the admins in charge of building
> makes it very
> likely that the rooms adjacent to the current room are
> going to be within
> that range (+ or -100) therefore with some exceptions
> (which are not that
> rare) moving from one room to another involves moving up or
> down a few
> vnums.
>
> Hmm, I understand about the making the global variable a
> class and actually
> that was my other question. (I guarantee you if it dosen't
> have to e global
> I don't want it to be global, that only increases the
> number of validity
> checks I have to make, eww)
>
> Each client is going to be in their own thread. For the
> reading functions
> this should prove no problem (two threads reading the same
> variable doesn't
> cause any problems? Right?) The writing functions (only
> avalible to admins)
> are what will require locking down (Mutex, Critical
> Section, etc.).
>
> One of my original thoughts was to create a vector of
> pointers to each room
> structure. Thereby allowing random room access and also
> allowing the
> numbering system to remain intact.
>
> if the vector currently only has rooms 1-100 filled in and
> an admin request
> to goto room #150 to start creating a new area then the
> rooms in between 100
> and 150 will be NULL pointers that can be checked for, if
> an admin request a
> room the does not exist then a template room is created for
> the admin to
> edit to their liking. This has the obvious disadvantage in
> that if an admin
> request room #999999 and the vector only has the rooms up
> to #1000 there
> will be alot of NULL pointers wasting memory. Given the way
> that these
> numbers are assigned this should not be a problem (with the
> exception of the
> top admins who can load and save any area) most admins are
> forced to remain
> within their assigned range.
>
> Any thoughts on this will be appreciated.
>
> BTW we have a project on sourceforge 'SinstradMUD'.
> The current codebase is in the cvs repository in the /src
> directory.
> The (extremly alpha, still deciding what library to use)
> code for the new
> codebase is in the Sinstrad2 directory
>
> ----- Original Message -----
> From: "Per Westermark" <pw...@ia...>
> To: "David McKen" <ci...@ya...>
> Cc: <dev...@li...>
> Sent: Thursday, May 01, 2003 2:11 PM
> Subject: Re: [Dev-C++] 'extern const' and std::vector
>
>
> > It still sounds like an object-oriented construct would
> work.
> >
> > Make all data protected.
> >
> > Add a lot of nice access functions.
> >
> > Create one function that returns a const room entry. Any
> user of the room
> > may then only call const methods.
> >
> > Give the administrators some way of retrieving a
> non-const room entry.
> >
> > class Room;
> >
> > class xx {
> >     public:
> >         const Room& GetRoom(RoomId& id);
> >         Room& GetRoom(RoomId& id,const char
> *admin_password);
> > };
> >
> > However, I still don't think that you need access to a
> room in constant
> > time. Logaritmic time would probably produce the
> reference to the room in
> > a fraction of the time that the work code need to perform
> actions on the
> > room - presenting contents of room, check for monsters or
> other players in
> > the room, ...
> >
> > There are a number of disadvantages to using a vector,
> unless the data is
> > absolutely static. It takes a lot of time O(n) to insert
> a new entry in
> > the middle. If new entries are not inserted last, all
> existing indices -
> > and probably also pointers to them - will be invalidated.
> >
> > /Per W
> >
> > On Thu, 1 May 2003, David McKen wrote:
> >
> > > Random access is essential!!!!
> > >
> > > We are storing them sequentially and the system for
> access
> > > uses the fact
> > > that room #3001 is located just after room #3000 (helps
> > > with speed).
> > > Concerning the comment that this is a bad design. This
> > > vector is what needs
> > > to be global. Only ceartain players (the admins) have
> the
> > > ability to
> > > directly edit this room data (this will also be
> > > controlled). No matter what
> > > part of the MMORPG is being used it will need access to
> > > this information
> > > (only some basic information commands don't).
> > >
> > > ----- Original Message -----
> > > From: "Ioannis Vranos" <iv...@at...>
> > > To: "Dev-C++ Mailing List"
> > > <dev...@li...>
> > > Sent: Thursday, May 01, 2003 1:27 PM
> > > Subject: RE: [Dev-C++] 'extern const' and std::vector
> > >
> > >
> > > > > -----Original Message-----
> > > > > From: Per Westermark [mailto:pw...@ia...]
> > > > > Sent: Thursday, May 01, 2003 8:23 PM
> > > > > To: Ioannis Vranos
> > > > > Cc: dev...@li...
> > > > > Subject: RE: [Dev-C++] 'extern const' and
> std::vector
> > > > >
> > > > >
> > > > > I assume MMORPG is Massive Multiplayer Online
> > > Role-Playing Game.
> > > > >
> > > > > If the game isn't too boring, I'm also assuming
> that
> > > you don't walk
> > > > > through the rooms in a sequential order.
> > > > >
> > > > > If you need random access, I would really go for a
> tree
> > > > > construct. Each
> > > > > node might point zero more alternative rooms, while
> you
> > > would still be
> > > > > able to locate a room in O(log n) time.
> > > > >
> > > > > If the tree for some reason gets too large to keep
> in
> > > memory, it might
> > > > > easily be placed partially on disk.
> > > >
> > > >
> > > >
> > > > I do not know much about trees but how can one have
> > > random access in a
> > > tree?
> > > > Trees involve sequential comparisons, don't they?
> > > >
> > > >
> > > >
> > > >
> > > > Ioannis Vranos
> > > >
> > > > * Programming pages: http://www.noicys.freeurl.com
> > > > * Alternative URL 1: http://run.to/noicys
> > > > * Alternative URL 2: http://www.noicys.cjb.net
> > > >
> > > >
> > > >
> > > >
> > > >
> -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Dev-cpp-users mailing list
> > > > Dev...@li...
> > > > TO UNSUBSCRIBE:
> http://www.noicys.cjb.net/devcpp/ub.htm
> > > >
> > >
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > The New Yahoo! Search - Faster. Easier. Bingo.
> > > http://search.yahoo.com
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Dev-cpp-users mailing list
> > > Dev...@li...
> > > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > >
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > >
> >
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>