game design

[jaso]

Hi,
I'm making this video game in C.
The game contains a player, enemies and bullets. These objects,
which are arrays of structures, are initialized, updated and drawn
in a game loop. Now I am unsure on where to declare these things.

I could declare them in main() like this

#define NUM_ENEMIES 10
#define NUM_BULLETS 20

int main(void)
{
struct *player player1;
struct enemy enemies[NUM_ENEMIES];
struct bullet bullets[NUM_BULLETS];

init_player(pla yer1);
init_enemies(en emies, NUM_ENEMIES);
init_bullets(bu llets, NUM_BULLETS);

while (1) {
update_...
draw_...
}
}

Or, I could declare them globally and make main() a little "cleaner"
by calling the functions with void parameters and let the functions
handle the objects and the count by themselves.

I don't know which one to choose, the second way seems a little
more modular, since I move the internal (should it be internal?)
stuff out of main.
But OTOH, I've read that local variables are better
than global. But again, if I put the handling functions in an other
file, and have static linkage, they won't be global, right?

I would be grateful if someone could give me some points on how
to do.

Thanks!

[Malcolm]

"jaso" <[e-mail] > wrote in message

Hi,
I'm making this video game in C.
The game contains a player, enemies and bullets. These objects,
which are arrays of structures, are initialized, updated and drawn
in a game loop. Now I am unsure on where to declare these things.

I could declare them in main() like this

#define NUM_ENEMIES 10
#define NUM_BULLETS 20

int main(void)
{
struct *player player1;
struct enemy enemies[NUM_ENEMIES];
struct bullet bullets[NUM_BULLETS];

init_player(pla yer1);
init_enemies(en emies, NUM_ENEMIES);
init_bullets(bu llets, NUM_BULLETS);

while (1) {
update_...
draw_...
}
}

Or, I could declare them globally and make main() a little "cleaner"
by calling the functions with void parameters and let the functions
handle the objects and the count by themselves.

I don't know which one to choose, the second way seems a little
more modular, since I move the internal (should it be internal?)
stuff out of main.
But OTOH, I've read that local variables are better
than global. But again, if I put the handling functions in an other
file, and have static linkage, they won't be global, right?

I would be grateful if someone could give me some points on how
to do.

This is a common problem.
The game needs a "world" and many quite low level functions need to operate
on this world.
For instance the gas-cloud baddy doesn't do its stuff whilst the hurricane
baddy is on screen, or else you need the game to handle gas clouds being
blow about by high winds. This sort of consideration destroys modularity.

So the answer is to declare a single header file, "game.h" and put all your
structures into that. Then have a single pointer to a "GAME" instance. It
doesn't really matter if this is global or passed to every function. Every
file include "game.h".
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm

[jaso]

Malcolm skrev:

This is a common problem.
The game needs a "world" and many quite low level functions need to operate
on this world.
For instance the gas-cloud baddy doesn't do its stuff whilst the hurricane
baddy is on screen, or else you need the game to handle gas clouds being
blow about by high winds. This sort of consideration destroys modularity.

So the answer is to declare a single header file, "game.h" and put all your
structures into that. Then have a single pointer to a "GAME" instance. It
doesn't really matter if this is global or passed to every function. Every
file include "game.h".

So you mean that I have a pointer to my world, and the
functions operate on this "GAME" pointer, am I getting this right?
What kind of type is a "GAME" instance?

[Andrew Poelstra]

On 2006-06-04, jaso <[e-mail] > wrote:

Malcolm skrev:

This is a common problem.
The game needs a "world" and many quite low level functions need to operate
on this world.
For instance the gas-cloud baddy doesn't do its stuff whilst the hurricane
baddy is on screen, or else you need the game to handle gas clouds being
blow about by high winds. This sort of consideration destroys modularity.

So the answer is to declare a single header file, "game.h" and put all your
structures into that. Then have a single pointer to a "GAME" instance. It
doesn't really matter if this is global or passed to every function. Every
file include "game.h".

So you mean that I have a pointer to my world, and the
functions operate on this "GAME" pointer, am I getting this right?
What kind of type is a "GAME" instance?

Create a GAME struct (I will call it "world" because I think that's what you
want):

struct world
{
/* All necessary world data here */
};

struct world *current_level = load_first_leve l();

The /only/ global you will need is a pointer to a world struct. This pointer
would be changed only by functions which move you from level to level, and any
other global variables would be accessed as such: current_level->global_var_her e

Having a struct or two to contain all globals makes fairly clean code.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
If we would just let the poachers into the zoo, we'd
have less squashed people and more fancy pianos!

[CBFalconer]

Andrew Poelstra wrote:

.... snip ...
Create a GAME struct (I will call it "world" because I think
that's what you want):

struct world
{
/* All necessary world data here */
};

Ridiculous. Well designed to make the end result unmaintainable.

--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.

[jaso]

CBFalconer wrote:

Andrew Poelstra wrote:
... snip ...

Create a GAME struct (I will call it "world" because I think
that's what you want):

struct world
{
/* All necessary world data here */
};

Ridiculous. Well designed to make the end result unmaintainable.

How come? Why will it be unmaintainable?
Could you please tell me how to design it well? It would
be nice to know beforehand, so it won't be a nightmare to fix it
when I understand I took the wrong decision.

Thank you

[Richard Heathfield]

jaso said:

CBFalconer wrote:

Andrew Poelstra wrote:
... snip ...

Create a GAME struct (I will call it "world" because I think
that's what you want):

struct world
{
/* All necessary world data here */
};

Ridiculous. Well designed to make the end result unmaintainable.

How come? Why will it be unmaintainable?

What usually happens is that the coupling between modules is drastically
increased by the existence of file scope data.

You're a maintenance programmer. You're fairly new to the project. You are
good at your job, but you don't know the code base terribly well. You're
debugging. This is a nasty one, you're really stuck, and you're stepping
through the code. All is well so far, and you get to this bit:

world.foo = 42;

seemingly_innoc ent_function();

baz = (world.foo + 117) / 35;

It seems obvious that baz should now have the value 4, but your debugger
tells you it has the value 6.

Finally, you twig that seemingly_innoc ent_function() must have updated
world.foo somehow. So you go digging around, and discover to your horror
that seemingly_innoc ent_function() is a wrapper around several thousand
lines. Nothing for it but to dig in and look for references to world.foo -
or maybe there's a world.p that is used to point to any of various world.*
objects - so maybe you have to look for that, too, and the whole mess gets
very wearying indeed. And you will find it almost impossible to decouple
seemingly_innoc ent_function() for use in other programs.

When you pass the data a function needs via its parameters, it makes it far
easier to track changes to the values of objects, and far easier to
separate out code for later re-use in a different context.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jaso]

Richard Heathfield wrote:

[snip]

When you pass the data a function needs via its parameters, it makes it far easier to track changes to the values of objects, and far easier to
separate out code for later re-use in a different context.

Ok, now I understand why to avoid the world structure. Thanks!
So, generally, the best way is to declare all structures separately in a
"high layer" like the game loop, and to pass all needed structures
all the way down to the lowest level functions?

[Richard Heathfield]

jaso said:

Richard Heathfield wrote:

> [snip]
>
> When you pass the data a function needs via its parameters, it makes

it far

> easier to track changes to the values of objects, and far easier to
> separate out code for later re-use in a different context.
>

Ok, now I understand why to avoid the world structure. Thanks!
So, generally, the best way is to declare all structures separately in a
"high layer" like the game loop, and to pass all needed structures
all the way down to the lowest level functions?

Yes, sort of. Ideally, each function should only be given the information it
actually needs for doing its job. So try to arrange your structures in such
a way as to minimise the amount of superfluous information you hand to your
functions. And localise your data as much as possible. If you must define a
structure in main(), okay - if you must, you must. But at least investigate
the possibility of making it more local than that.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Tobin]

In article <Zo************ ********@bt.com >,
Richard Heathfield <in*****@invali d.invalid> wrote:

Yes, sort of. Ideally, each function should only be given the information it
actually needs for doing its job. So try to arrange your structures in such
a way as to minimise the amount of superfluous information you hand to your
functions. And localise your data as much as possible.

None of this means that you shouldn't have a structure that gives
access to the entire state. It may well be useful to do this so that
you can easily pass it to a function that, say, saves the game. But
don't make it a monolithic structure - have it contain pointers to
other structures that make sense in themselves: lists of objects or
people for example.

And as has been said, don't make it a global variable. Apart from
the possibility of hidden modification, maybe one day you will want to
make a multi-player version of the game in which there are several
such structures.

-- Richard