Quantcast
Channel: GameDev.net
Viewing all articles
Browse latest Browse all 17825

Guidelines for determining what should be a component

$
0
0
Background: So I'm developing my first 2d C++ fighting game (for learning purposes) and I have a setup where I have 'components' which are really just data holders with maybe some simple utility functions such as GetComp(), AddToComp(), etc. All components get passed to component systems which are just functions which act on certain components (e.g. MovementSystem(PositionComp pos, VelocityComp vel), etc.) which are split up into their respective domains (Graphics, Animation, Physics, etc.). All components are held by 'Fighter' class which acts as the component holder that keeps everything together. Issue: The problem I'm having is I'm not sure how I decide what exactly should be made into a component vs what shouldn't. For example, for my animations I have a system which essentially takes a 'spriteComponent' and a 'animationClip' obj like so SetAnimation(spriteComponent sprite, animationClip anim). As it stands, my animationClip class is not considered a component and is not currently attached within my Fighter class, though I guess I could implement it that way. How do I decide what classes/types should be made into components? How is this typically handled in other ECS like systems?

Viewing all articles
Browse latest Browse all 17825

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>