Back to For Beginners

Game Logic & Component Based Entity Design question

For Beginners

Started by Kasya March 23, 2011 05:38 AM

3 comments, last by Kasya 13 years, 1 month ago

Kasya

207

Author

March 23, 2011 05:38 AM

Hello,
I have been working on my component based game object design. The thing I got stuck is what is actually Game Logic? Is it, for example, players health, ammo, and other in-game related stuff? If yes, should I consider my "game object" as a game logic element.? The thing I am trying to make is, every subsystem has its own container which stores the id of the component and the entity depending on the subsystem:
Graphics -> MeshEntity
ParticlePhysics -> ParticleEntity //physics is not main concern, so not worried about this one
RigidBodyPhysics -> RigidBodyEntity //"" "" "" ""
Logic -> LogicEntity

and each subsystem updates its data in its own world and the events occur between subsystems rather than between components. So, Game Object is more of a helper class to combine these stuff and remove from subsystems with one system call like: delete myObject; (which will trigger deletion of entities in the subsystems it uses)

If the GameObject is a Logic Element, I can just use (e.g) health_component, ammo_component etc, and totally remove Logic Subsystem and use HealthSubSystem, AmmoSubSystem etc

btw. is this a good design for a game entity class in terms of performance and memory?

I hope I could explain what my problem and idea. Sorry for english (not my primary language. working on fixing it).

Thanks,
Kasya

Kasya

207

Author

March 23, 2011 03:10 PM

bump. anyone?

BCullis

1,955

March 23, 2011 03:47 PM

Game Logic is usually the interaction between your game objects, not an object type itself. Think of it as the "rules" of the game, in a sense. A fair amount of the game logic can actually be comprised of object methods: if you have a Player class that has methods TakeDamage() or more generically Attack(target), those are part of your game logic, as they probably contain the rules for how damage should be mitigated, or attacks should happen. Looking at your example of systems, I would imagine an object would have its own set of entities, one from each system, depending on what type of object it was.

"Having" a logic entity could work if you're creative enough, but you may be causing yourself undue grief by trying to fit an abstract idea into a concrete structure. Objects in your game interact according to game logic and rules, the logic itself probably shouldn't be an object. It could even be defined in your larger manager classes.

Hazard Pay :: FPS/RTS in SharpDX (gathering dust, retained for... historical purposes)
DeviantArt :: Because right-brain needs love too (also pretty neglected these days)