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!

[Andrew Poelstra]

On 2006-06-04, CBFalconer <cb********@yah oo.com> 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.

In my code, it's fairly obvious what globals are being changed (I never
have more than three or four) in which functions.

If there's ambiguity (or a situation where I'll be maintaining instead of
rewriting), I'll comment what variables are changed, and why.

--
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!

[Default User]

Richard Heathfield wrote:

jaso said:

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.

In my reworking of my text adventure game (a programming project 15
years old and still going!) I've tried to limit most entities' access
to game state data.

One way of doing this is to sort of borrow a concept from OO
programming. I move a part of the state data into a separate
translation unit, and make it static within there. There are a
relatively few public functions for which can access the data only in
certain predefined ways, and a bunch of static helper functions to
accomplish this.

So, for instance, no other part of the game can directly manipulate the
player inventory. They can use the public functions to query for an
item, add one, drop one, output the list, etc. This allows changing the
underlying data structures to a large degree without affecting the rest
of the game.
Brian

[Malcolm]

"Richard Heathfield" <in*****@invali d.invalid> wrote

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.

When you are wriitng world simulators this approach, though generally a good
idea, doesn't work.
The problem is that real world objects do communicate their state to each
other. If I walk into a pool of hot water, the water state communicates with
my nerves and the block of butter I am carrying in my knapsack.
So the only way to handle things, in practise, is to have a "world"
parameter that is apssed to every function. That is not to say that you
don't try to communicate through interfaces as much as possible, but
inevitably someone will throw a curveball that you didn't think of some time
during development.The demon turns red when it is about to attack, but it
doesn't look nice against a red wall. So if the wall is red, just turn off
the attack routine. Great idea, but now the attack locic needs access to the
wall pixel data.

--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm

[jaso]

Malcolm wrote:

When you are wriitng world simulators this approach, though generally a good
idea, doesn't work.
The problem is that real world objects do communicate their state to each
other. If I walk into a pool of hot water, the water state communicates with
my nerves and the block of butter I am carrying in my knapsack.
So the only way to handle things, in practise, is to have a "world"
parameter that is apssed to every function. That is not to say that you
don't try to communicate through interfaces as much as possible, but
inevitably someone will throw a curveball that you didn't think of some time
during development.The demon turns red when it is about to attack, but it
doesn't look nice against a red wall. So if the wall is red, just turn off
the attack routine. Great idea, but now the attack locic needs access to the
wall pixel data.

Indeed. I've thought alot since my first post about the design, and if
I am going to avoid globals I need to pass a lot of data as arguments
to my functions. And a world structure would free me from the uglyness
of 6+ argument functions. For example, if I have a update_enemies( )
function that moves the enemies and make them shoot bullets at the
player, I would have to declare something like
update_enemies( struct enemy *e, int num_enemies, struct bullet *b,
int num_bullets, struct player *p, int num_players);
And if I add things like powerups or weapons I need to add more
arguments if I want the enemies to interact with them. IMHO,
that would be pretty messy.
A call like update_enemies( world) is cleaner, and then from that
function I can call functions that don't need all world data like this
enemy_shoot(w->enemy, w->player);

Does that sound reasonable, or am I way off?

[Andrew Poelstra]

On 2006-06-05, Malcolm <re*******@btin ternet.com> wrote:

"Richard Heathfield" <in*****@invali d.invalid> wrote

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.

When you are wriitng world simulators this approach, though generally a good
idea, doesn't work.
The problem is that real world objects do communicate their state to each
other. If I walk into a pool of hot water, the water state communicates with
my nerves and the block of butter I am carrying in my knapsack.
So the only way to handle things, in practise, is to have a "world"
parameter that is apssed to every function. That is not to say that you
don't try to communicate through interfaces as much as possible, but
inevitably someone will throw a curveball that you didn't think of some time
during development.The demon turns red when it is about to attack, but it
doesn't look nice against a red wall. So if the wall is red, just turn off
the attack routine. Great idea, but now the attack locic needs access to the
wall pixel data.

Well, you could have a "get_sight(WORL D_OBJECT self)" function,
which returns a struct or an array containing every object visible to the
caller. You could extract red wall data from there, and it would be basically
the same as the AI which allows the character to attack at all.

--
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!

[Richard Bos]

jaso <[e-mail] > wrote:

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?

Some people are scared of global data and want to pretend that it is a
local to main(). To avoid this abhorrence, they put all their data in a
struct in main(), and then pass lots of pointers to every non-trivial
function. The result is that you still don't know which function
modifies which member of the struct, and you have to pass world pointers
everywhere. Big win :-/.
IYAM, if data is global by nature, make it global by declaration, too.
If 90% of your functions are going to refer to the "monsters in the
dungeon" array, why pretend that it's not a global object?

Richard

[Andrew Poelstra]

On 2006-06-08, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

jaso <[e-mail] > wrote:

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?

Some people are scared of global data and want to pretend that it is a
local to main(). To avoid this abhorrence, they put all their data in a
struct in main(), and then pass lots of pointers to every non-trivial
function. The result is that you still don't know which function
modifies which member of the struct, and you have to pass world pointers
everywhere. Big win :-/.
IYAM, if data is global by nature, make it global by declaration, too.
If 90% of your functions are going to refer to the "monsters in the
dungeon" array, why pretend that it's not a global object?

The only functions to which I would pass an entire struct would be
a few initialization or cleanup functions.

Everywhere else, I pass specific members of the struct. I prefer the
struct system because it means that I can go to a header file and see
all of my members in one place.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Richard Bos]

Andrew Poelstra <ap*******@loca lhost.localdoma in> wrote:

On 2006-06-08, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

jaso <[e-mail] > wrote:

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?

Some people are scared of global data and want to pretend that it is a
local to main(). To avoid this abhorrence, they put all their data in a
struct in main(), and then pass lots of pointers to every non-trivial
function. The result is that you still don't know which function
modifies which member of the struct, and you have to pass world pointers
everywhere. Big win :-/.
IYAM, if data is global by nature, make it global by declaration, too.
If 90% of your functions are going to refer to the "monsters in the
dungeon" array, why pretend that it's not a global object?

The only functions to which I would pass an entire struct would be
a few initialization or cleanup functions.

Everywhere else, I pass specific members of the struct.

How does that help when 80% of all major functions need to read that one
member, and some 30% want to change it?

Richard

[Malcolm]

"Andrew Poelstra" <ap*******@loca lhost.localdoma in> wrote

[ world structures in video games ] The only functions to which I would pass an entire struct would be
a few initialization or cleanup functions.

Everywhere else, I pass specific members of the struct. I prefer the
struct system because it means that I can go to a header file and see
all of my members in one place.

You need to pass the entire struct, but not necessarily to access it.
The problem is that in the real world there are no barriers to information
flow, and requirements chance.
If a games designer says "stop the demon from attacking if it is standing
next to a red wall" he doesn't want to be told that we can't achieve this
because the attack logic is in the gameplay module whilst the wall pixel
data is locked up in the texture cache. The information is in the computer,
so he sees his request as reasonable.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm