[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: 'Filing' structure



Messing with macros and header files isn't that neat, but there are some good 
ideas... Maybe the thing may be cleaned up a bit.

You say there are programming languages wich avoid all this.
Wich ones?

Thank you,
Francesco Orsenigo


J. Perkins:
>  Francesco,
>
>  I have been trying to send this to the list for the past couple of days
>  but it keeps bouncing back. If you find this useful, please forward it
>  to the list while I try and fix whatever is wrong with my settings.
>
>  Jason
>
>  Francesco Orsenigo wrote:
>   > I have lots of objects types in the game, each of wich is described
>
>  by a structure.
>
>   > For a variety of reasons (saving info or sending it to a client) i
>
>  must translate this information in a machine indpiendent (and run-time
>  indipendent) format, (snip)
>
>
>  I don't have any links handy, but a lot of research has been done in
>  this area. Keywords include "persistence" and "serialization", also look
>  for information on multi-player networking. There's an article on
>  Unreal's networking at http://unreal.epicgames.com/Network.htm that
>  might give you some ideas.
>
>  To be more constuctive:
>
>  * At the very least, write a serialization manager with functions like
>  read_int32(), write_int32(), read_float() that takes care of endianess,
> etc.
>
>  * Give each object a unique "handle" and use that instead of pointers.
>  In addition to making serialization easier, it will also open
>  possibilities for new features like load-on-demand. There are some
>  articles around on handle-based resource management, at least one
>  appeared in "Game Programming Gems".
>
>  * When I was doing this kind of thing in C, I would use macros and
>  include files to help automate the task. So I might define a structure
>  like this:
>
>     /* file: player_def.h */
>     BEGIN_STRUCT(player)
>       STRING(name, 32)
>       INT32(health)
>     END_STRUCT
>
>  Then you can change the meaning of the defines to do different things.
>  For instance, this would define the structure:
>
>     /* file: struct_builder.h */
>     #define BEGIN_STRUCT(n)  struct n {
>     #define STRING(n,len)    char n[len];
>     #define INT32(n)         int  n;
>     #define END_STRUCT       }
>     /* end */
>
>     /* file: player.h */
>     #include "struct_builder.h"
>     #include "player_def.h"
>     /* end */
>
>  ...while this would load it from disk, assuming that "stream" and "ptr"
>  were a valid variables:
>
>     /* file: struct_reader.h"
>     #define BEGIN_STRUCT(n)  read_struct_header(stream, n);
>     #define STRING(n,len)    read_string(stream, ptr->n, len);
>     #define INT32(n)         read_int32(stream, &(ptr->n));
>     #define END_STRUCT
>      /* end */
>
>     /* file: player.c */
>     int read_player_info(player* ptr, serializer* stream)
>     {
>     #include "struct_reader.h"
>     #include "player_def.h"
>     }
>     /* end */
>
>  Still a lot of manual work, but now you can change the layout of the
>  struct in one place (player_def.h) and it will get picked up everywhere
>  else, which is a big timesaver. With different header files you can
>  manage networking, scripting, and other tasks.
>
>  Finally, I must mention that a higher-level language would take care of
>  all of this for you, letting you concentrate on the fun stuff instead of
>  the drudgery. There are a lot of them out there, and most have bindings
>  to OpenGL, SDL, and the like.
>
>  Hope this helps!
>
>  Jason