Unity3D GameObject Code Structure

0
votes

I am messing around in a Unity3D, making a 2D project. I want to create my own code architecture for Unity's component based system.

As I don't want to create God-Controller scripts, and being more into code resposibilities separation solutions ( having MVC, MVVM in mind ), I am trying to find some good solution.

My first take looks like this:

GameObject is created from:

Unity Components - for ex. SpriteRenderer, Animator, Rigidbody2D

Controller - The only resposibility of this component is to handle Unity functions ( like Update, FixedUpdate, OnCollision ), and executes functions from model.

Models|Proxies - this components contains data, functions to manipulate game object unity components, and dispatching events to outer world.

I am wondering what do you think about this aproach, what are your code habbits in Unity3D projects, and what solutions worked for you.

2
unity3d
Feel free to actually tell us what you intend on building. 'A 2D project' is too vague and it sounds like you want us to do too much of the thinking for you. - Happy Apple
I didn't want you to do any thinking. I am creating a platformer game to be specific, but I think that my question isn't connected with any specific game type ( of course not mentioning big projects ). The only thing I wanted is to hear from other users, how they are managing code separation in their projects, and I posted my solution, so I don't understand how I can be blame for non-thinking <lol> - MyFantasy512
If an answer helps you, consider upvoting and accepting it. - user3071284

2 Answers

6
votes

While I have learned and taught MVC and similar approaches, I find that when designing game architectures one usually has to be a bit more flexible. In unity I generally take the following approach.

I will create a few GameObjects to hold the necessary global logic. This would be things like the overarching state machine, networking, and sometimes control input. If anything needs to persist between scenes it will go here. Each object typically has one component script for game logic and one for temp/debugging functions that gets turned off or removed when not needed.

If the project has fixed levels I will make each level a scene and I will store level layout and other level specific information in the scene. If I am doing a more procedural project I will create a "LevelGenerator" object with component scripts that build and populate the level at runtime.

If I am building a system that has lots of mostly independent agents (e.g. enemy creatures) I try to keep the game logic and necessary state information for each agent as close to it in the hierarchy as possible. For example, the agent's position and rotation would be stored in it's transform. I might store the agents health, ammunition, speed, and current status effects along with the functions for moving, shooting, healing, and death in a component script on the agent's GameObject.

While there are countless other approaches that could work, I like this approach for a few reasons:

  • It saves me from having to manually manage tons of data access in a central script. If I need to know where all the monsters are, I can just keep a list of game objects rather than using custom data types.
  • When the agent gets destroyed all the local data goes with it. (No complex functions to clean up dead agents.)
  • From a game logic perspective (on the projects I typically work on) it usually makes sense that each agent would "know" about itself and not about everyone else.
  • I can still use all the OO goodies like polymorphism etc. when necessary.

This response likely says more about how I approach game design and software architecture than general best practices but it might be useful.

One note on encapsulation in Unity. Every component script you add to a game object has a bit of overhead. If your scene has a couple of dozen agents in it, than this is not a big deal and I would recommend trying to keep things as OO and modular as possible. If you are building a system with hundreds or thousands of active agents, cutting the components per agent from two to one can mean quite a bit of saved frame time.

0
votes

I use another approach.

  1. I don't use many controllers attached to game objects. I just have some kind of GameController which creates other structures.

  2. I have separate project shared between other games. This project contain design patterns and is built before main project did. I widely use State, Observer, Builder, ObjectPool etc. patterns to make my code clear and simple.

  3. Another reason I use such approach is performance optimization. I create objects once and then reuse them. Also I do once such things as gameObject.GetComponent etc. When I need to create many objects using the same prefab I use ObjectPool to avoid CreateInstance/Destroy.

  4. My logical game objects (actors) communicate each other using Observer pattern. My only one GameController just send events like Awake, Update to actors. Some objects have StateController which retranslate events like Awake and Update to current object state. This is useful to separate behavior of each object state.

  5. I have component system architecture similar to Unity. And I also have services like InputService that can be accessed via ServiceLocator in any object.

I have also points, but the idea is clear and easy maintainable code. This is difficult with standard Unity controllers and SendMessage approach.