Karma - MVC Framework for Unity3D

Karma is an MVC framework for Unity3D. Because of how Unity is structured, it actually turns out to be an MVCP architecture (Model/View/Controller/Presenter) where the Presenter is a MonoBehaviour that serves as an intermediary between the Controller and the View. You can read more about this in MODEL VIEW CONTROLLER PATTERN FOR UNITY3D USER INTERFACES.

Based on Zenject

 

It's built on top of Zenject which provides Dependency Injection (DI). DI is mainly used to route the app to the desired view, it also enables us to build composable and testable systems.

 

Inspired by AngularJS and ASP vNext

 

Some of the basic constructs and code layout is inspired by other MVC frameworks such as AngularJS and ASP vNext.

 

Note to Game Developers

 

Karma uses concepts like views and presenters instead of scenes. The problem with scenes is that they are too heavy weight, there is no good way to communicate between them, changing scenes is slow (especially if you are doing UI stuff), and they aren't composable. The "Karmic" way of doing a game would be to store each level/scene in a prefab, treat it as a MVC View, store all your characters/entities in separate prefabs, and get them instantiated onto the level's view through DI.

 

Simple Routing System

 

Karma has a built in routing system that enables you to create isolated views/scenes as prefabs and easily switch between them. Using an http-like flow, a presenter can Request the router to render another view.

 

As Stateless as possible

 

Karma aims to be as stateless as possible to try to give you the guarantee that if you entered a view once with certain Request parameters and reached a successful state, then you will always reach that same state if you pass the the same parameters. Unity3D doesn't provide by default a best practice changing from a view to another. A common way to do this is to have all possible views instantiated in the scene but only enable the current one, the problem is that you maintain state when reusing Game Objects and often end in bad states because of the many paths you need to account for. Karma keeps things simple and functional by just destroying the current view and instantiates a new next view when changing views.

 

Message Passing

 

In Karma state is mainly maintained through message passing, being as true as possible to Go's philosophy:

 

Don't communicate by sharing memory; share memory by communicating.

The added benefit of this is that views become configurable without depending on local storage or static variables, is in turn is very important to keep a system testable.

 

Pub/Sub System

 

All Presenters integrate a pub/sub system that enables the communication between entities on different branches and levels in the dependency hierarchy. It's a simple yet powerful message passing mechanism on channels by topic where any Presenter can subscribe and broadcast. By convention the top level application is used as the main channel.

 

Folder Structure + Conventions

 

As many MVC frameworks, Karma tries to keep the developers sane by establishing conventions. Among these conventions are the folder structure, concepts (presenters, controllers, services, etc), code organization, a configuration mechanism (dev, prod, test environments).

 

Parts

 

Views

Plain old prefabs

Presenters

Handle the presentation layer

Extend MonoBehaviour

Are tied to a Prefab

Get instantiated on Game Objects

Integrate a Pub/Sub mechanism

Are Transient

Are divided as:

Plain Presenter (Routable)

Elements (Reusable)

Layouts (Provide context)

Controllers

Handle the logic layer

Don't extend MonoBehaviour

Are Transient

Are 100% testable

Are usually coupled to a Presenter

Services

Handle Resources

Should be Stateless

Are Singleton

Usually handle communication with a server on a particular resource, local storage, specialized logic for e.g. handling certain user inputs, etc.

Applications

Handle general configuration

Are Presenters

Contain the current view

Can be nested to create subviews

Router

Belongs to a specific Application

Tells the application which view to render next

Can store request history

Middleware

Each application can configure its one pipeline

Each middleware can modify the Request and Response

Enables to e.g. create an authentication layer separate from the view itself

It's asynchronous so e.g. http requests can be made to the server to get extra information

下载