When objects have variables that are needed in the app delegate and each other, and there are many of the objects, are the variables usually made into global variables in a global variable header file or are they accessed by getset methods? What is usually done?

I typically have a globals.h and a corresponding globals.m file. While globals can be incredibly handy, they can cause problems with modularity and instancing, so it's best not to overuse them. For something like deltaTime and input, I personally prefer globals, simply for ease of access. This isn't usually a problem with games since you'll usually only have one instance of a game running at any given time. However, if you're doing something like an editor or multi-document app, globals can really screw you if you aren't careful.

Globals are always evil. Avoid. Pass parameters.

How "evil" globals are is relative to the project. Like I said, if you're making a game, and you know you only have one instance of that game, globals aren't as evil as needlessly passing a global pointer around as a parameter to 750 different functions.

What method should I use if I need global variables to do collision detection between two circles that are objects?

You shouldn't need global variables for any collision detection.

But if the circles are drawn by their own objects and not just pieces of code in the app delegates's drawing function, global variables are needed for collision detection. At least they are very good if very many circles are drawn.

Sounds like you're doing it wrong then. You should try a different approach.

Is it not good that theoretical objects that have much functionality are made into their own code objects? If not, it is strange that every piece of drawing and key detection for every moving shape in a game should be in the app delegate. What is a good alternative?

I personally wouldn't have hardly anything in the app delegate. I'd probably have a central game class. In there, in the update method, every tick of the simulation, one of the steps would be to loop through the array of circles and see if any of them are touching. You could deal with this in any infinite number of ways. For instance, you could generate a list of contacts, which are simple objects that contain a reference to the two circles involved in each collision (contact), and send them off to a contact resolver class, or just deal with them there on the spot. It's up to you, but in no way should there be a need for global variables in the collision detection/resolution/response process. If you need globals for it, then you're doing it wrong.

Or another approach might be: Let's say you have an asteroids game. Every tick of the simulation the spaceship wants to know if it has collided with an asteroid, so it calls the asteroid manager class, sending it's position, x and y, and it's collision radius. The asteroid manager simply loops through all the asteroids to see if the distance between the ship and any asteroid is close enough to be a collision. If it finds a collision, it destroys the asteroid and maybe splits it into two more asteroids right there, and then responds back to the ship that it did hit an asteroid so the ship can decide what happens to itself. This process is also repeated for each shot that is still floating through space too. No globals needed.

Thanks. So either getter methods are used to get the position values from asteroid objects or the asteroids are hard-coded into the manager. However, if there is an arbitrary number of asteroids, they can not be hard-coded.

I don't understand what you mean by them having to be "hard-coded". The asteroid manager is told when and how many asteroids to spawn. It does that by creating new asteroids and adding them to an array or whatever. Personally, I usually pre-allocate a pool of entities at launch and simply activate or deactivate them in an array as they are spawned or killed, but that's not necessary; you could just as well alloc a new asteroid object and add it to an NSMutableArray, or something, of asteroids in the asteroid manager class. The asteroids can be their own objects, but the asteroid manager has access to them through the array it maintains. Yah, you can use get/set "accessors".

Also realize again that this is only one approach among many. Because of inheritance and polymorphism, you could have a central array of entities in the game that respond to the same accessors and could potentially all be managed by one collision detector. Again, none of the approaches would require globals.

globals are evil even with only one instance of the game code at a time

[rationale: anything that writes a global has a side effect that is therefore order-dependent with everything else that interacts with the global. you can therefore mitigate the evil with careful coding, eg. setting your dt only from one place in the update loop. I prefer to take the slight extra effort to eliminate all chance of evil.]

(Aug 17, 2010 08:46 PM)OneSadCookie Wrote:  I prefer to take the slight extra effort to eliminate all chance of evil.

Well I like to use globals because programming wouldn't be as fun without a reliable way to screw things up.

...

now there's some sound-sounding advice