Re: [palito-dev] on simultaneous orders

[barrett]

On Tue, Sep 02, 2003 at 06:14:31PM -0300, Gabriel Blum wrote:
> All help is always welcome, and I think, for your reply, that you have solid
> comp science foundations, and that will surely be helpful, even tough zed
> and barrett are pretty practical guys and not keen to long theorical
> discussions :-D

Not only that, but in this project I'm focusing on getting all the basic
infrastructure of an RTS to work first, before we can address the more
advanced ideas.

That is, in this case, to just make any working network code, no matter
if's good or efficient. And do the same with all the (numerous) others
parts of the game, so we can test the whole thing together, experiment,
and have a general feeling of the path to a more refined version.


That server sketch which you are talking about was just a brainstorm,
the actual development of the networking code doest not follow it
strictly (if at all :)


> Let's comment your email ... [ Maylander's complete message to me is in the
> end, skip to it to understand ]
> 
> > > This way is thecorrect way when server resources are limited;
> > > It's a scheduling system...
> 
> > A round robin is not bad, but a weighted fair queue would be even better,
> 
> Completly agree. The unix kernel implements this, doesn't it?
> Well, code it up man! ;-D

The current code just processes all stuff for all the units each frame.
And it is fast enough now to handle a lot of units.
Of course the unit processing can get more sophisticated and eat more CPU,
but I'll not worry about scheduling until it becomes necessary.
I don't even know if will be!, and that's the question here:
only do work only by demand. (More or less in the line of "If it's not
broken, don't fix it.")

Of course the main reason to have this policy is that there's too much
to be done to complete the game. If there is more manpower we can do more.


regards,
barrett.