Skip to main content
Game Development

Return to Question

edited tags
Link
Tetrad
Tetrad
  • 30.1k
  • 12
  • 95
  • 143
Rollback to Revision 1
Source Link
user9993
user9993
  • 143
  • 4

Should How should I design my class hierarchy contain >1 Update methodclasses in a game?

I'm stuck constructing a class hierarchyfor ideas on classes in game programming. This is probably more of an opinion based question. I'm looking for information that is proving hard to find on the internet.

Say I have classesa class called   Bullet andor Mob. (The names are unimportant; they're, the name doesn't really matter it's just examplesan example.) With this, there are two options I can think of two approaches:.

  1. Centralised: Classes are Have the class purely as a way to storeof storing data and nothing else. So I could have, for example, properties such as EntityID, Velocity, HealthPoints, NumberOfAttacks properties. SomeI would then have some other part of the game could then iteratewhich iterates through every instance of every object and update itsthe properties from there.

    Example Example: During such anthe iteration, depending on theit checks what type of object it is, such as (Bullet etc.), its movement is handled differently. (Bullets fly forwardOnce it has checked this, it will calculate where the bullet should move to next based upon the MobVelocity AI is applied, etcproperty.)

  2. Decentralised: Each class contains its own Or, have the same properties and alsowithin the class, but also have all the code for updating itsit's own properties in there too.

    Example Example: The Bulletbullet has some kind of Update() method which get's called periodically by the game engine calls periodically. This Update method would then take it upon itself to calculate athe new Velocity, and update it's position, etc.

  3. Some combination of the both? Something else I haven't thought of?

Are there combinations of these or other alternatives I haven't thought of?

Which of these options is the more commonly used approach in game programming? What are the benefits or disadvantages of these different methods?

Have I got it all completely wrong?

Should my class hierarchy contain >1 Update method?

I'm stuck constructing a class hierarchy.

Say I have classes called Bullet and Mob. (The names are unimportant; they're just examples.) I can think of two approaches:

  1. Centralised: Classes are purely a way to store data and nothing else. I could have, for example, EntityID, Velocity, HealthPoints, NumberOfAttacks properties. Some other part of the game could then iterate through every instance of every object and update its properties.

    Example: During such an iteration, depending on the type of object (Bullet etc.), its movement is handled differently. (Bullets fly forward, Mob AI is applied, etc.)

  2. Decentralised: Each class contains its own properties and also all the code for updating its own properties.

    Example: The Bullet has some kind of Update() method which the game engine calls periodically. This Update method would then take it upon itself to calculate a new Velocity, update it's position, etc.

Are there combinations of these or other alternatives I haven't thought of?

Which of these is the more commonly used approach in game programming? What are the benefits or disadvantages of these different methods?

How should I design my classes in a game?

I'm stuck for ideas on classes in game programming. This is probably more of an opinion based question. I'm looking for information that is proving hard to find on the internet.

Say I have a class called   Bullet or Mob, the name doesn't really matter it's just an example. With this, there are two options I can think of.

  1. Have the class purely as a way of storing data and nothing else. So I could have, for example, properties such as EntityID, Velocity, HealthPoints, NumberOfAttacks. I would then have some other part of the game which iterates through every instance of every object and update the properties from there.

    Example: During the iteration, it checks what type of object it is, such as Bullet etc. Once it has checked this, it will calculate where the bullet should move to next based upon the Velocity property.

  2. Or, have the same properties within the class, but also have all the code for updating it's own properties in there too. Example: The bullet has some kind of Update() method which get's called periodically by the game engine. This Update method would then take it upon itself to calculate the new Velocity and update it's position etc.

  3. Some combination of the both? Something else I haven't thought of?

Which of these options is the more commonly used approach in game programming? What are the benefits or disadvantages of these different methods?

Have I got it all completely wrong?

More descriptive title. Trimmed redundant or unnecessary detail. Formatted for clarity. Some grammar.
Source Link
Anko
Anko
  • 13.4k
  • 10
  • 55
  • 82

How should I design Should my classes in a gameclass hierarchy contain >1 Update method?

I'm stuck for ideas on classes in game programming. This is probably more of an opinion based question. I'm looking for information that is proving hard to find on the internetconstructing a class hierarchy.

Say I have a classclasses called  Bullet orand Mob, the name doesn't really matter it's just an example. With this, there(The names are two optionsunimportant; they're just examples.) I can think of. two approaches:

  1. Have the classCentralised: Classes are purely as a way of storingto store data and nothing else. So I could have, for example, properties such as EntityID, Velocity, HealthPoints, NumberOfAttacks properties. I would then have someSome other part of the game which iteratescould then iterate through every instance of every object and update theits properties from there.

    ExampleExample: During thesuch an iteration, it checks whatdepending on the type of object it is, such as (Bullet etc. Once it has checked this), it will calculate where the bullet should move to next based upon theits movement is handled differently. (VelocityBullet propertys fly forward, Mob AI is applied, etc.)

  2. Or, have the same properties within theDecentralised: Each class, but also have contains its own properties and also all the code for updating it'sits own properties in there too. Example

    Example: The bulletBullet has some kind of Update() method which get's called periodically by the game engine calls periodically. This Update method would then take it upon itself to calculate thea new Velocity and, update it's position, etc.

  3. Some combination of the both? Something else I haven't thought of?

Are there combinations of these or other alternatives I haven't thought of?

Which of these options is the more commonly used approach in game programming? What are the benefits or disadvantages of these different methods?

Have I got it all completely wrong?

How should I design my classes in a game?

I'm stuck for ideas on classes in game programming. This is probably more of an opinion based question. I'm looking for information that is proving hard to find on the internet.

Say I have a class called  Bullet or Mob, the name doesn't really matter it's just an example. With this, there are two options I can think of.

  1. Have the class purely as a way of storing data and nothing else. So I could have, for example, properties such as EntityID, Velocity, HealthPoints, NumberOfAttacks. I would then have some other part of the game which iterates through every instance of every object and update the properties from there.

    Example: During the iteration, it checks what type of object it is, such as Bullet etc. Once it has checked this, it will calculate where the bullet should move to next based upon the Velocity property.

  2. Or, have the same properties within the class, but also have all the code for updating it's own properties in there too. Example: The bullet has some kind of Update() method which get's called periodically by the game engine. This Update method would then take it upon itself to calculate the new Velocity and update it's position etc.

  3. Some combination of the both? Something else I haven't thought of?

Which of these options is the more commonly used approach in game programming? What are the benefits or disadvantages of these different methods?

Have I got it all completely wrong?

Should my class hierarchy contain >1 Update method?

I'm stuck constructing a class hierarchy.

Say I have classes called Bullet and Mob. (The names are unimportant; they're just examples.) I can think of two approaches:

  1. Centralised: Classes are purely a way to store data and nothing else. I could have, for example, EntityID, Velocity, HealthPoints, NumberOfAttacks properties. Some other part of the game could then iterate through every instance of every object and update its properties.

    Example: During such an iteration, depending on the type of object (Bullet etc.), its movement is handled differently. (Bullets fly forward, Mob AI is applied, etc.)

  2. Decentralised: Each class contains its own properties and also all the code for updating its own properties.

    Example: The Bullet has some kind of Update() method which the game engine calls periodically. This Update method would then take it upon itself to calculate a new Velocity, update it's position, etc.

Are there combinations of these or other alternatives I haven't thought of?

Which of these is the more commonly used approach in game programming? What are the benefits or disadvantages of these different methods?

Tweeted twitter.com/#!/StackGameDev/status/434265317356093440
Source Link
user9993
user9993
  • 143
  • 4