|
I had a large PlayerController class in my game which was getting unwieldy, so Ive split it in to multiple classes to handle the various bits. Much easier to work with and now I can re-use certain classes for other game objects without cluttering them with the whole lot. So now I have: MouseTarget Class - all this does is looks for the coordintates of a mouse click if it is on navigable terrain, does a few tricks, but basically makes those co-ordinates available for other scripts if / when the mouse is clicked on the terrain. PlayerPath Class - gets the click coordinates for the overall destination from the MouseTarget Class (e.g. MouseTarget.clickPosition) , talks to the pathfinding stuff, and then based on the suggested path makes the target movement required for the next path segment available publically. PlayerMover Class - looks for the co-ordinates PlayerPath.nextPathSegment and moves the player to it PlayerAnimator Class - reads loads of properties from PlayerMover and executes animations based on how fast the player is moving, and their direction and orientation. My question is, as you can see above, I now have a whole load of public properties which my classes use to work together. But it seems really messy just accessing them as Class.property. It means there's a spiders web of links between these classes that is going to get really hard to manage as the game grows. Can anyone shed any light on a "best practice" to achieve things like this, in a more manageable way? I suspect it might be as much to do with C# class design techniques as Unity specifically, but even so, it would be great to get some pointers.
(comments are locked)
|
|
I would split the data from the logic. Encapsulate the data into mini classes (they are called Value Object) and inject them to all the classes that need to use the data in a given context. Inject them by constructor or by setter. Using static class is bad, using public members is bad :) You can decide to let your controller class hold the Value Object and then have a getter for the value object OR inject the value objects through an initialization phase (if you have any). Pseudo code for the second case: MouseCoordVO mouseCoord = new MouseCoordVO(); MouseTarget mouseTarget = new MouseTarget(mouseCoord); PlayerPath playerPath = new PlayerPath(mouseCoord); Good advice. Funny - I normally develop in php and use dependency injection as a matter of course - but never occured to me to implement it here. I think without the control over the underlying framework it feels a little more abstracted than if I were writing an app from the ground up, or on top of a framework that already provides a DI container.
Feb 16 '12 at 07:54 PM
cr0wn3r
Indeed, the nature of Unity Framework does not allow straightforward dependency injection, but there are solutions. I would like to write an article about it once I have the time.
Feb 17 '12 at 10:22 AM
sebas77
(comments are locked)
|
|
Hi, What I recommend (from someone who is dealing with hundreds of dlls and classes) - make a static "instance" of each item (public static CharacterAnimator Instance) so you can access it from anywhere without bothering to use getComponent all the time. Next I recommend using properties. You mention them above, however I'm unsure wether or not you're using this format: public Vector3 movement { get; set; } If you use that format you can easily write in methods to be run when the variable is called later on. In terms of the "web" of references, this is "just the way it goes". Just be sure to remember what each method does with good commenting, and use a program like Visual Studio 2011 with the ReSharper plugin to ensure that all your code is in good form. Feel free to edit with more suggestions! ~Christian Thanks for all the tips. Yeah, commenting is going to be important I can see. I havent been using get; set;... I should be though I can see.
Feb 16 '12 at 07:36 PM
cr0wn3r
(comments are locked)
|
|
We have implemented both events, as well as key-value coding ( KNKVC http://www.kennettnet.co.uk/code/ ) to solve this problem. Key value change observation is really nice but requires a lot of boilerplate code. Events are a simple way to pass data between objects. Thanks - I'll check out unity events more thoroughly. That links handy. I have so much reading to do...!
Feb 16 '12 at 07:35 PM
cr0wn3r
(comments are locked)
|
