(no title)
drjeats | 10 years ago
But any game-specific logic written by a developer, while technically using the same component system, is usually written from an individual scene object's perspective rather than from a "system processing components associated with various game objects in bulk" perspective.
You can still write code that looks like a system, but the framework really encourages you to attach those scripts to scene objects, so you end up basing a lot of logic around the structure of the game object hierarchy.
(The alternative to putting a script on a game object is to have one Master script of a scene that delegates updates to several subsystems, but you lose the benefit of things such as disabling a gameobject while the scene is running to temporarily disable a system.)
For instance, you'll see a lot of addons (example Fabric: http://www.tazman-audio.co.uk/?page_id=73#! ) that use prefabs to create hierarchical data even when it's not necessarily appropriate. But it's the path of least resistance.
When you go to implement gameplay logic, you're usually not writing systems as rasmusrn describes, you're writing behavior scripts on the roots of game objects hierarchies (not unlike Actors as you'd see in Unreal and other game engines).
Trying to make a bunch of click-together MonoBehaviours usually makes a mess.
These slides give a good overview of generally good ways to not shoot yourself in the foot in Unity, and it mentions this actor-ish approach: http://slides.com/cratesmith/how-to-use-unity#/
The hope (or at least my hope after working with Unity for a while) with the design rasmusrn is using is that composing per-entity data is more flexible than composing per-entity behavior.
norman784|10 years ago