Hello there. I've made LOTS of stuff in Unity, something that is always a question before starting a project, is what architecture I'm going to adopt. Generally, I end up deciding right away by the complexity of what I'm going to do, for example, if it's going to be a 'standard' game, with few procedural stuff an not much logic, then I use the architecture that Unity itself lays out for us, with various Components for all the logic (I like the single responsibility approach, so for damage I have a component that 'receives' the damage, then calls a 'health manager' component (cached ref), and the 'health manager' component have a cached list of 'health change receiver' components that are sub-classed to have different behaviours (e.g.: 'take hit', 'die'). The example above is a very good way to put a game together and is the intended way (I think) to work with Unity. It makes gamedev much easier and modular. It allows you to drag and drop for the win once you have all the components and assets. I see that generally others tend to have less scripts with more functionality. I don't like that. There is code around that use its own 'components' that are sub-components of the Unity's components. That quickly becomes messy and in terms of performance is not very worthy. Of course you could have a POCO for some kind of data, say, 'attacks', and have a single MonoBehaviour that have a list of various kinds of attacks, but that's about it. I'm not saying however that the performance of having GameObjects and various Components (or script components/monobehaviours in this context) is good. I would say it's enough for most games, and of course I know that Unity is a high-performance C++ engine and stuff, and that's why I think we should always take advantage of the tools it offers us - like the component system - to do stuff instead of rolling our own solutions which generally doesn't make a difference and sometimes performs even worse because C# in Unity isn't really fast - Mono is much slower than MS's CLR, and the Mono in Unity is very old what means it's much much slower than the current Mono which MS's CLR blows outta the water, so IMHO, sticking with the "Unity way" of doing things is the best approach for most games. A simplification of how things are done (just to be clear): Standard GameObjects for most objects Monobehaviours (aka script components) for most logic For objects interaction, you use the 'physics' engine, even if only for colliders/triggers (no sim) To access components on other objects you use GetComponent and variations This is a very decent approach and the productivity is incredibly high, in the past there was some myths, specially on IRC, that things like enabling scripts weren't performant, but from my own tests I've concluded that anything concerning the default component-based architecture is performant enough. So far so good. The problems emerge when you need something that that↑ architecture can't provide. Recently I've been playing with voxels and structural analysis (SA); in noobies terms: realtime physics for minecraft buildings/terrain, and obviously you can't use that architecture for something as massive as voxels. In fact it's bad even to use POCOs because 1.they are allocated in the heap 2.refs aren't lightweight (8 bytes on 64 bit) and 3.don't take advantage of processor cache because heap is not allocated in sequence. So, to tell the truth a clever architecture that uses Structs would be the best way to go imho. But anyway, I went with POCOs for the voxels data, and then you have to create a 'viewer' that will retrieve the data and generate the meshes in Unity, preferably in chunks. I've manage to obtain something usable, the SA is done on a separate thread, I'm taking advantage of atomic access not to lock the variables (I know locking do more than that, but in this case the possible problems aren't critical and the nanosecs multiplied by some million voxels are important), and the 'viewer' is smart enough to sort the chunks from near to far, and to skip generation if the deltatime is too high (0.02s in this case). The end result for the terrain itself was impressive, here are some screens so you know what I'm talking about: ↑ Benchmarking showed that 8vox³ chunks are the best for an average player speed. The numbers are inverted on some sides because the mesh is sharing the vertexes (8 vertex for a cube without neighbors), so UV mapping couldn't be correct, that won't make a difference in the end because the textures aren't going to have numbers/letters, and smoothing is going to be dealt with material. Basically, that approach can't take much advantage of the Unity's "intended" architecture, and you end up going with a pure OOP approach which, even when preferring composing over inheritance, ends up very different from the way the game engine actually works. Basically you're using two different paradigms and trying to make them work together. I've had no actual problem with that, since I've made a 'voxels manager' component that does all the abstraction and for the rest of the stuff I'm using the good ole Unity way of doing things, but while I didn't have any technical problem, it's a little bit of a pain to work like that. It ended up becoming so cumbersome that, I ended up going 2D, so I ported the SA and here's how it looks: It turned out that the 'view area', which is not only the 'visible area' by the camera, but the area where all stuff happens is quite good with 50x50 voxels, totalling in the worst case 2499 voxels on the 'interactive' area, and I found out that you can use standard GameObjects for that (I'm not targetting mobiles), and the thing still runs @ 1000 fps on my computer which is quite old (g3220, gtx550ti), and that is instantiating the objects! (no pooling). To make things even more impressive, there are blocks that are updated continuously, they represent mostly 'machines' in the game lore, and the world size is up to 8000x1000 voxels, and I managed to generate 4 million of those machines, and they update very quickly (on a separate thread), and the visible voxels, which are GameObjects they reflect the updates in real time. I'm not talking numbers here, but the performance was really impressive, and each visible voxel just reads the data from the array on Update(), what's the way Unity generally does stuff. The development was much more straightforward and I could take full advantage of Unity architecture. The difference was huge; I'm even using standard box2D colliders for the blocks. So far I'm extremely happy with the results. I would like to know what approach others are using (doesn't matter the complexity of the game), and if they are happy with it, what caveats they found, what advantages over other approach, and I would like to start an overall discussion on architecture since It's hard to find anything sane on the subject. Please let's not turn this thread into a freak show, noobies are welcome, trolls are not. If you've nothing valid to add please abstain from posting.