[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