koobas.hobune.stream
Game architecture best practices
Is there any best practices guides, or just advice regarding the best approach to game architecture for Unity? In particular Unity's component system seems to allow a completely different approach than standard object oriented design.
For example, generally composition is favored over inheritance and the component system makes composition so easy that it seems that inheritance is redundant. I realize you have to inherit from internal Unity classes like MonoBehaviour but I'm referring to inheritance of user created classes.
Similarly polymorphic behaviour doesn't require an abstract base class, you can just replace 'component A' with 'component B' to get different behaviour.
I'm moving toward this way of thinking lately and it got me wondering if there are any guides or resources that outline how to approach architecture in Unity.
Not quite an answer but some good reading can be had from: http://www.insomniacgames.com/assets/filesadynamiccomponentarchitectureforhighperformancegameplay.pdf http://cowboyprogram$$anonymous$$g.com/2007/01/05/evolve-your-heirachy http://stackoverflow.com/questions/1901251/component-based-game-engine-design/3495647#3495647
I was first developing my game using almost strictly OO design methodologies until I stumbled across a few posts on Unity Answers describing Component Based design.
and GOD DA$$anonymous$$N is it SO $$anonymous$$UCH EASIER to implement in Unity. $$anonymous$$y productivity in my game has doubled and it is SO EASY to extend and add functionality to game objects.
I still have some objects that inherit from others, but those instances are more specific functionality of generalized components.
Anyone wondering whether or not they should adopt a component based design for their game, especially in Unity, DO IT!!! It will help you in the long run.
Those resources are fantastic, thanks! Communication between components is not something I had given much thought to, it seems that is the biggest challenge.
Peter - just FWIW my observations match yours precisely. Purely FWIW I think you're probably right in that one should / one has to "go with the flow" of exactly the "architectural feel" you describe. Unity3D is meant to be, well, simple, the "particular flavour of OO suggested by the overall unity environment", just as you describe ... you just kind of have to go with it I think.
As petroz mentions "Communication between components" for example is completely obvious, natural and sloppy in Unity. I waste a lot of time being offended by architectural "feels" that don't match the previous system I had to work on a couple yrs ago.
"are any guides or resources that outline how to approach architecture in Unity" I think the actual answer is No. :) Unity is setup as a system for "civillian" programmers, I doubt that even 2,000 of the now one million Unity developers would even understand what the hell your post here is about, Peter!!!
$$anonymous$$y god, at last someone that understands me... I'm really struggling on how to "think" in Unity after doing OOP for years... did you ever find any useful info on those subjects related to Unity?
Well I'm completely opposite in terms of program$$anonymous$$g background. I started up with Unity as soon as I programmed a text game in Visual Studio in C++ that had a simple leveling and item/store system, turn based combat.
But even I find the lack of information regarding these kind of topics for Unity extremely annoying. There is really no good resources which explain how any of it works, all they do is give you a one liner syntax example which usually results in a debug notification.
It's kind of a joke to be honest. I am so OCD that I would probably $$anonymous$$r my hair out if I was co$$anonymous$$g from a proper program$$anonymous$$g background and had to deal with their resources. Even co$$anonymous$$g to Unity as a complete beginner I constantly find myself wishing they had useful information.
Generally it seems like the way to go is just don't even think about it, figure it out through trial and error because none of these answers seem to exist for Unity. It's like the whole Game Engine is just a toolbox with tons of random crap for you to sort through but no instruction guide.
All that being said I am amazed with the progress I have made in developing my game with Unity in this short time, it's just not a fun process to try to master a program when you are alone in the woods with a pocket knife and a box of matches.
I have just started to use Unity and was looking for some resources on this myself.
There is an excellent video on the subject by Mike Mittelman of Hangout Industries from Unite 2008 that can be found on Unity3d.com http://unity3d.com/support/resources/unite-presentations/techniques-for-making-reusable-code
Also check out http://forum.unity3d.com/threads/37896-Programming-architectures (I am currently using the iPhone friendly NotificationCenter class by Prime31 and it works in a similar way to the Actionscript 3 event model).
I found this thread a couple of months ago lacking a good answer, just found this page with more information I could ever dream of specific to unity:
Apparently this is the only article on the whole web that touches on the subject in a comprehensive way. We should have more of this...
Unity is a game engine and like probably all other premade engines on the market, it uses Component based software architecture. That means you see all parts of your game like components i.e I can put one component A into another component B which will give behavior A to the component B. For example I can add keyboard component to my component Player in order to make my Player move with keyboard buttons. As simple as that. If you were to use polymorphism and inheritance you could possible end up in inheritance mess, very hard to maintain. Engineers found that Component based structure is the best way to make a game engine.
I would recommend a rather old book on the OOD patterns which is kind of too broad but you will find Component pattern there as well: http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
This is also a good intro to Component based software engineering
Edit: The biggest problem of component based architecture is that all that visual and bussines logic is mixed within a component aka MonoBehavior. And even if you try to separate visual from bussines logic you will again need to use inheritance which will end in a mess. So I would recommend, functionality that can stand alone or in separate C# class to be moved from a MonoBehavior. That way your code will stay clean and maintainable.
Just to add a useful link for users like me; That are starting out, have some knowledge in program$$anonymous$$g, but missing the overall concept on how to dissect your game logic. I found the tutorials from Jesse Freeman very useful.
Since the question here is about Composition over Inheritance, maybe his video will help some of you. (Please note, that it's not free. Ofcourse you can subscribe for a trail) https://www.lynda.com/Unity-tutorials/Composition/540497/570507-4.html
