Ok, I think that you're right. I'll try to clean the code a little and
comment it a bit more.
About the extract function, well, I put it first in NetManager because
it only proccesses network things. Later, I need it in GameEvent, but
for the same thing. But you have all the truth, it's a lots better put
it in a file of utility functions.
About repeat code of CS, there are a lots of classes in CS, when i want
some funcionality, I search in it, but maybe I can't find a
functionality that exist already in CS. I think that ToString methods
can be simplified, but i didn't find a way with all the classes in CS.
What we need is simple, some method that can dump into a char* and later
recovering it (like the pickle class in Python).
One thing, I think that now, the code is broken (all works fine until
you try to move). I know where is the bug, but I can't get by CVS a
working copy of CS. The broken code is that Extract has been removed
from StringArray, but Pop() is not the same that Extract(0). Pop() is
similar to Extract(lengthofStringArray). Instead of that Pop(), we must
use DeleteIndex(0), but I can't change it because is a new feature of
One thing about network and Events. First there is now a event saver,
with that, we can save all the events so we can reproduce later. There
is commented code to load an save game (in game.cpp). I say this because
you want give a try, you must note that it saves automatically the last
session. Now, it save the code with your name, so, now, if you want try
it, you should create a network game.
Second. There is a network load display. If you play a bit, you will
discover that the network load for one soldier can reach about
32KBytes/second. Too high, IMO. Of course, if we have 20 working
soldiers, that value is multiplied by 20. But what is worse, it depends
of the FPS that we can reach. Ok, with the actual ToString and
FromString methods, I think that rewriting it (to don't use csString and
use a more basic classes) we can use the half of bandwith that is used
currently. The bad things of doing that is that is more hard to debug
it, because now is in readable code. Other option is to change a bit the
way of Events is managed. Now, when we press a key, there is an event
for each FPS that says that we are presing the key with its duration.
Ok, on a machine that displays 100 FPS, if I press the up key and
release it one second later, we will send 100 Events, but we can send 2
Events to cover all the movement, the start up event and the stop up
event. I think that, in this way, we can reduce the bandwith about 100
One last thing. I thing that maybe will be an interesting thing to start
a profile class. In that class, we can save the options of a particular
user. It's like the file game.cfg. The game.cfg will be the default
option for a new profile, it can be saved in the save directory. It can
store, for example, the name of that user, the keys, the default port,
the ip to connect to, the color that it prefer, the display options, if
save the events, the name of the file to save the events, etc.
Bjorn Hansen wrote:
>I've got a couple of requests for the sake of code readability; with multiple
>people working on the same code a little extra effort must be made to make
>the purpose of a function clear than is necesarry in personal code.