in the final analysis, you'll probably find you only have two categories of things with components that need updating: mobile, and immobile. whether to collapse these together is one of the design choices one must face with every game, since the number of unused components for an immobile object is low, i tend to just have one type of update-able object: a "target", and then i have the player object (with components), or the player's update-able components are simply a target (IE the player is target[0]), with the rest of the player's data in a separate player specific data structure. due to the fact that things usually boil down to just one or two object types with components, i usually just forego the whole components layer altogether, and just do update_player during input(), and updateall() is just: for each target, update_target, for each missile, update missile.

if you wanted to get really slick, a missile could just be another type of target. but games can have a lot of missiles, and missiles usually need less data than enemies, and the update functions often are simpler, or different than that for targets, so it often makes sense to handle them separately to save ram, run faster, and keep the code organization cleaner, simpler, more straight forward, and more compartmentalized.

note that

graphics type: 2d

and

platform: android

are totally irrelevant to this design question. these concepts apply to both 2d and 3d, any platform, and most genres (pretty much anything more complex than tetris, bejeweled, pong, or the like). ; )

one more thought:

not only do enemies and missiles sometimes tend to have different update code, the player often has more complex update code than enemies, another reason to handle all three separately, instead of with one generic update_component function.

components and generic functions that operate on them are really only applicable when the operation to be performed is identical for all components of a given type.

its often the case that player update, enemy update, and missile update are not the same. while the final change of a component like position might be the same for all three (new x = old x + delta x), determining the change to make can often differ (complex player moves / flight model vs simple enemy AI vs physics modeled missile movement). so its only the very last step of updating an object, where you change the component variables, where you can get any real advantages from generic code and components. and even there its reduced to just a generic update_location(location L, int dx, int dy, int dz) kind of thing. just about as easy to just do L.x+=dx, etc. after all, x+=dx, y+= dy, z+=dz is 3 lines, short, but perhaps not compiled inline even if desired, and update_location incurs the overhead of a function call, plus the 3 add's of x+dx, y+dy, z+dx once the call is made.

note that every games differs, and you may find commonalities in your update functions for your various object types that warrant some sort of component approach. in such cases, a "for each object update each component" vs a "for each component type update each object" approach would probably be simpler, easier to code, and run faster - just what every programmer wants. <g>

some games (like rpg's) also have a list of inventory items dropped on the ground, or carried on a player, in a treasure chest, etc.

yet another list of similar object types in the game world, like players, enemies, and missiles.

what list to put something in is up to you. in CyberTank, smoke and flames were projectiles. in Airships!, projectiles, smoke, flames, and craters are just another type of target as i recall (no missiles list). the player is target 0 plus additional player specific data structures (it uses a realistic physics flight model for the player's airship, which requires a LOT of variables).

in my new Zlib "game engine" i recently wrote (but have yet to use - need to start on yet another game! <g>), everything is a target. it can draw a target as a 2d billboard, 3d billboard, mesh and texture, static model, or animated model. it includes functions to update targets, do collision checks, do AI, etc.

my lower level Z3d library (used for CAVEMAN, Airships!, Armies of Steel II and the Zlib engine) handles window creation, d3d startup and shutdown, mesh, texture, model, and animation databases, animation player engine, timers, random numbers, file i/o, string <-> number conversion, a drawlist engine (throw graphics at it in any old order and it sorts optimally for d3d and draws using state management), a matrix manipulator, and a few other useful things.

then i have a 3rd module, a model and animation editor that works with the z3d library and can be linked into any game.

I think you should just start coding something learn from it. If your method is not viable, then change it.

This would be your fourth android game right?