Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Good day sirs, I know this is a newbie question but I really need to ask it. I've been reading a lot of sample codes on libgdx, and I have seen entities(player, enemy, boss,etc.).

my question is what should an entity class contain?as I have seen it contains states which i will use to animate my sprite, should I also put my inputs/controls, and animation in this entity class?

share|improve this question

closed as too broad by Anko, bummzack, Sean Middleditch, Seth Battin, Byte56 Jul 25 '13 at 12:59

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

This is pretty vague. It should contain whatever it needs. What does it need? Depends on the game, the developer, the target audience, the budget... – Anko Jul 23 '13 at 8:54
To clarify, are you using or building an entity/component sytstem? – ashes999 Jul 23 '13 at 9:27
@anko oh sorry for the vague question dear sir. I'll try to be more accurate next time that i will ask. thanks for the answer. – badasskitteh Jul 23 '13 at 11:13
@ashes999 I'm trying create a set of entities for my game which are player, enemy,and bosses. since my knowledge in programming is still pretty basic, I was wondering what should a player entity should contain?just a basic guideline would do or is it still to vague? – badasskitteh Jul 23 '13 at 11:17
up vote 2 down vote accepted

It sounds like you're struggling with basic object-orientation. There are really two ways you can do this:

  1. Use classes. This is tricky, because your Player class will have data (player health, etc.) but also the current view to draw (sprites, etc.) A better way would be option #2
  2. Use a component-entity system. This article describes it quite well, as an improvement over option #1; you basically create small components (eg. Sprite, KeyboardInput) and entities (eg. Player) that are a composite of multiple components and "wiring" to make them work together.

If option #2 seems too "hard," try option #1 first. If your game is a small size, it may be "good enough" for you.

share|improve this answer
I noticed you accepted this answer. Which approach did you go with? – ashes999 Jul 23 '13 at 20:22
I am trying to use the #2 approach. But my progress is pretty slow, I'm still trying to figure out which is which. I'm reading the article though it is really useful. anyway thanks dear sir. kudos to you. – badasskitteh Jul 24 '13 at 5:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.