Re: Too many tasks? overhead questions.

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

system@niuhep.physics.niu.edu wrote in article
<5jlkdu$rub@corn.cso.niu.edu>...
> Hello,
> Largely as a learning exercize I am writing*  a mud** with Ada using the
> Gnat compiler.  One of the possibilities is to make it highly threaded 
> with each character getting their own thread. (Yes, there are design 
> reasons for doing this)
[etc.]


Yes, provided the machine you are running on will allow it, you should use
a task to represent each character (player and NPC), as well as each object
in the game (e.g. a magic door which opens under certain conditions, etc.).
No, don't use protected types for communication, use entries. However, be
careful about getting into race conditions (pragma Priority may help
(sometimes!)), lock-up conditions (e.g. tasks calling each other at the
same time), and so on. Define a task type for players, a task type for each
category of NPC and game object. Declare the task type specifications in
advance of the bodies. Declare a god task which has power over all the
other tasks. Ensure that this god (you!) has the ability to save the entire
game state to a file (it should interrogate the other tasks by calling
entries to them to get data from them), and reload from the file. Include a
room-defining feature: this is very popular with the punters, and is a
great way to expand the dungeon (watch out: it grows fast!)

To see if the number of tasks you require will run on a particular machine,
write a test program which spawns lots of tasks. It needn't be very
complicated.

Hope this helps. Good luck!

PS: Post us when you get your MUD going, some of us play MUDs!

Nick.