Skip to main content
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: http://stackoverflow.com/questions/1901251/component-based-game-engine-designhttps://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.


For example, take the player's ship in a space shooter. You don't know until some point during the gameplay, what weapons, armour, systems (i.e. components) that player is going to pick up, purchase, sell, lose, have destroyed, etc. So the only realistic way to model this is through object composition.

all that was possible without components a long time ago too

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: http://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.


For example, take the player's ship in a space shooter. You don't know until some point during the gameplay, what weapons, armour, systems (i.e. components) that player is going to pick up, purchase, sell, lose, have destroyed, etc. So the only realistic way to model this is through object composition.

all that was possible without components a long time ago too

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: https://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.


For example, take the player's ship in a space shooter. You don't know until some point during the gameplay, what weapons, armour, systems (i.e. components) that player is going to pick up, purchase, sell, lose, have destroyed, etc. So the only realistic way to model this is through object composition.

all that was possible without components a long time ago too

added 416 characters in body
Source Link

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: http://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.


For example, take the player's ship in a space shooter. You don't know until some point during the gameplay, what weapons, armour, systems (i.e. components) that player is going to pick up, purchase, sell, lose, have destroyed, etc. So the only realistic way to model this is through object composition.

all that was possible without components a long time ago too

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: http://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: http://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.


For example, take the player's ship in a space shooter. You don't know until some point during the gameplay, what weapons, armour, systems (i.e. components) that player is going to pick up, purchase, sell, lose, have destroyed, etc. So the only realistic way to model this is through object composition.

all that was possible without components a long time ago too

Source Link

For those who speak german an interesting book: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

A closer look about when and why use which architecture may be found here: http://stackoverflow.com/questions/1901251/component-based-game-engine-design

For my self I decide my architecture depending on the size of the project and the possibility to extend or reuse the code. Why invest hours and hours into the architecture of a micro project where there is no chance that you use the code again? In the same time you can have the project finished.

Composition vs Components Components are cool fancy stuff but in most projects/architectures composition will do the stuff also (without component-based overhead). It depends what your component-system can provide that composition can't.