The "interface with Update/Render methods" pattern is often called a "game object" or a "game entity".

i figured someone had already come up with a fancy name for a "list object".

IMHO, having a larger number of smaller, more homogeneous lists of self contained objects (or 'systems' of objects), combined with a more complex main loop in which the flow of data and control is explicit and easy to follow, is a far, far superior approach.

yes. this is how i do things.

i have lots of lists:

* meshes, textures, models, wavs, animations - all are stored in list type databases.

* timers, the render queue, and probably many other things in the Z gamedev library are lists.

* terrain chunks are lists of renderables.

* the chunk list is a list of lists! <g>.

* players, monsters, missiles, dropped objects, inventories, NPC stats - all are lists.

* cloud, rain, and snow particle systems are also lists.

i think you get the idea.

i've often considered "one big list" for player, targets, and projectiles, but have never actually tried it. many small lists specific to their tasks seems to make things simpler.

in all the games i've done, i've always used a separate list for each type of thing in the game. however i do tend to treat explosions (particle emitters) as projectiles, rather than having a separate list of explosions. sometimes i'll include the player as target #0 in the targets list and then have additional player data in another data structure, which lets me use some target code (such as collision checks) for the player as well. but i usually keep the player as a separate data structure (IE a list with one entry). In the case of Caveman, the player can control a whole band, like a household in The SIMs, so there's a true list for band members.

as you say, you get a lot of control that way, as far as what happens when.

Couldn't this be considered the "visitor pattern"?.

much simpler - its just class based on a list type data structure of some sort.

What if you double-buffer your modifications of game data so that all changes don't take effect until after 1 complete iteration through all objects?

deterministic design of control code as described above by Hodgeman makes life SO much easier. I wouldn't code any other way unless i had to. i've been doing it so long now, in so many games i don't even think about it. i by and large assume that more or less any game will have at the very least a list of targets, and most likely a list of active projectiles as well, and also a player data structure or list of PCs. and making the player target #0 presents no problem, as target #0 always updates first - still deterministic.

What if you implement a system where each change to the underlying interfaces requires an investment of 1 week of pizza and beer provided to the rest of the team?

then i'd be buying a lot of beer and pizza! <g>.

How about you call it the "manager pattern"?

You could have playerManager, cloudManager, treeManager... And you could use a "Manager" base class so you can have a list of generic manager classes and update them all at once in the managerManager.

This reminds me of an article I read once.

OMG! ROTFL!

but seriously, a game could probably be put together using mostly classes of such type.

well, except maybe for trees type structures and such....

its probably safe to say that the list (in some form, array, vector, etc. ordered, un-ordered, etc) is the most common data structure in a game.

i use them more than 2d array type structures, and i almost never use true trees. i frequently use sparse matrix lists for sparse 2d and 3d arrays.