[RELEASED] Code Control - Easy MVC for Unity

​

Code Control is a framework written in C#, specially designed to create an easy to understand workflow for creating games in Unity using the MVC design pattern.

Buy now​

Code Monitoring
Coming with three insightful ways to monitor what's happening in code while running the game. Including message visualization and a basic UML of data structures, all clickable to open associated code files, making it much easier for new programmers to hop in on your project and understand the code.

Smart Serialization
Data models can be saved effortless while having references to each other. The big problem with normal serialization is referencing. In normal serialization, having multiple references to the same model creates a separate serialized model for each reference. At deserialization this results in a new model for each reference, while at serialization it was only one. Code Control solves this problem using its ModelRef class.

Global Messaging
Controllers do not have a reference to each other to make sure they are not tightly coupled. Code Control's global messaging system avoids direct dependencies and keeps the code easy to change. The big issue with global messaging though, is losing sight of what classes are messaging each other. But luckily, that’s where Code Control’s Message Flow monitor comes in!

Code Monitors Demo Video

Released!
Code Control is now for sale on the Asset Store! Get your hands on this framework's full source code today, and gain access to all of its features!

Additional Links
Product Website: http://unitycodecontrol.com/
Tutorials: http://unitycodecontrol.com/tutorials/
Documentation: http://unitycodecontrol.com/documentation/
Demo: http://unitycodecontrol.com/demo/
Reddit Support Thread: http://www.reddit.com/r/codecontrol/

 

Code Control has been accepted by the admins of the asset store!! Wohoo! Make sure you check it out!

 

Hi Joris,
First of all, thank you for the framework, looks very promising.

I have two questions about saving/loading models on a remote server. In the tutorial http://unitycodecontrol.com/saving-and-loading-models/ at the ModelBlobs section you mention the dataString which is generated by the ModelBlobs object. How would such a string look like?
And, what is a best practice saving these data strings to a database? Using HTTP POST methods? And/Or using an ORM on the backend? So, how would you save the data coming from your system to a database?

Can you provide an example of this?

Thanks,
Cetin

 

Hi Cetin! Thanks for your comment

Answer to question #1: The string coming from the ModelBlobs actually contains multiple xml files, separated using a special char or a custom string. The default separator char is the ~, so a very simple example of a ModelBlobs.ToString() output would be:

"<LevelModel><id>0</id></LevelModel>~<TurretModel><id>1</id></TurretModel>"

Here the xml's are separated/joined using the default ~ char. Using this data string in the ModelBlobs.FromString(str) method will result back into ModelBlobs with that data. Do note that if you store string data inside your models that may include the ~ char, we advice you to use a custom separator. For example: ModelBlobs.ToString("CustomSeparator") and ModelBlobs.FromString(str, "CustomSeparator").

Answer to question #2: Saving these strings to your database is entirely up to you.. they're nothing more than strings after all. I suggest to indeed use the HTTP POST methods, and to save them in a (sql) database so they can be easily loaded. Of course, when dealing with large tables, it might be more optimized to store the strings in a separate txt file on your web server instead of directly in the database.

I hope this answers your questions! Let me know!

 

Hi!
Thanks for your extensive and clear answer. .
Are you planning to also do an export to JSON (ModelBlobs or loose models to JSON)? We have a back-end that accepts JSON which is ready to use for my game. So this would be very convenient.

Thanks again

 

Hey again ^^ Code Control will not be supporting JSON serialization in the near future as it is not supported in native C# in the way XML is, but you could still use JSON for the backend responses! Just use XML for the game's model data strings

 

Code Control 1.2 has just released! As of now, we are completely Unity 5 compatible!

 

For the next 24 hours the Code Control framework will be 50% off in the Asset Store's 24 hour sale http://u3d.as/bRG ! Really curious to your opinions!

 

Hey, this is awesome. Keeping a maintainable code base in Unity has always been a problem for me. I purchased and looked at the demo code base and the framework and I like what I see. I'll give it a go in my next game jam game or prototype.

Any thoughts on a unit testing example or, integration with an IoC container?

 

Hey Musicm122! Thanks for buying Code Control

About your feedback, I really try the keep the framework as lightweight and simple as possible. I think unit testing could easily be a separate (existing) asset, which could contain tests including functionality of Code Control. In my experience, Inversion of Control requires a big change in architecture and way of programming which a lot of programmers are not willing to make.

Thanks again for your feedback and purchase of Code Control!

 

Hey,
I'm tempted to purchase Code Control during the current sale. I have worked through the Tutorial and an "issue" has arrived for me. Namely that messages are handled via strings. I want to suggest that you use an enum instead. This offers the following advantages:
- intellisense offers you all messages available.
- no missspelling of messages, compiler ensures that they all exist. with strings you have to remember/copy each message.
- enumeration / switch of all possible messages fe for initialization, list them etc.
- all defined in a single place for easy addition, removal, renaming etc.
- utilize refactoring tools when renaming a message fe. having to look up strings all over the place is error prone.
- enums should be faster than strings and include no allocation (value type). be sure to use a default comparer though.

So basically by using enums instead of string for the message definition you gain support from your IDE/compiler and you avoid some potential bugs/errors what is very hard using strings.

I'm interested to hear your thoughts about that. Most messaging systems I have seen use strings and I think this is "bad" design when you rely on them. I have adapted a basic messaging system from the wiki using enums and I'm very happy with it. I think this is exactly what enums are intended for.

 

Hi Exiguous, thank you for taking the time to write your post!

I've considered using enums, but I got stuck on the part of extending the enum outside of the framework. I want the framework's code to be fully separated from implementation so I can update classes freely without users loosing their code. Giving the Message.Send a dependency on an enum would require that enum to be declared within the framework, and being that enums cannot be "sub-enumed" or declared as partial this would not get us very far.

The only real solution I found was to add a Send, AddListener and RemoveListener variant which requires you to define the used enum type. That would initially create an ambiguous call error as it would have the same structure as the Send<T>(T message) method, so one of those would evidently need to get a different method name. The Send methods could look like the following:

Message.Send(string messageName);
Message.Send<MyEnum>(MyEnum.MessageOne);
Message.SendTyped<MyMessage>(new MyMessage());

Is this something that you would likely use in your code?

Thanks again for your feedback!

 

Hi,

Does the system require any extra coding in scripts to function or works with any script. Also does it work if scripts are in DLLs ?

Thanks

 

Hi Nasos, thanks for replying on this thread!

The package does not need any extra coding to make it run.. but you'll need to use Code Control's Messaging system to make the Code Monitors do their thing of course.

I've made dll's of the source code and those run just fine!

Let me know if you got any more questions!

 

Thanks for clarifying

 

Hi. I am very interested in Code Control. I just watched the demo video and I am wondering how well the Code Monitor works with complicated projects and with opening files in MonoDevelop instead of VisualStudio?

Also I am posting this in the reddit thread but in the future would you rather have support questions posted here or in the reddit tread?

 

On the enum issue -- there's no reason you cannot have intellisense with a string:
public static class MyMessageTypes
{
public static const Bark = "Bark";
public static const Growl = "Growl;"
}

Then:
Messages.Send(MyMessageTypes.Bark);

The advantage to a string here is mods -- if you use an enum, you have to define all the possible values up front. If you use a string, you don't. Using the constants should be very nearly as fast (you'd have to test it) as using int or enum. Strings in C# are immutable -- using the constant means it should be a simple pointer compare.

That gets you intellisense without losing the flexibility of adding new messages in mods or DLC. If you modify the enum in DLC, you might have to repatch your entire game to add the new message types. That's architectural, and can be managed, but it's potentially a good reason to use strings.

 

I can just say that using your string method is a nogo for me . So probably I would have to adapt it to my method manually what makes updating difficult.

I don't see a problem here. You define an empty enum for the messages and put it in a file named differently (MessageEnum_rename.cs) so it is not overwritten. When the user first installs your package he shall remove "_rename" from the filename and fill in his enum values. When the user updates your package he shall simply delete your empty file or exclude it from import right away. This way usercontent is not overwritten during update and you even get compiler warnings when the type exists twice. Its a bit unusual but I don't consider this inconvenient.

Why that? You can add enum values as you see fit. You could theoretically even change the order or rename the values (globally). I don't see any issues here. If you forget it in a switch fe you even get a warning.

Your method adresses most of my listed points but not enumeration. In my messager for example I enumerate all enum values and create a delegate for each at startup. So I don't have to check at runtime if it is there already. And since enum can be cast to int it can be used to index a list/array instead of a dictionary.

Anyway, thanks for the discussion. Its very interesting for me. The "issue" of updating is one I usually don't have to care about in my own projects. But I'm eager to learn .

 

Thanks for the feedback guys!

I've implemented a mini-map in the Code Monitors that can be used when projects get more complicated. Of course, if you have a lot of events and/or model types it would help to have a second (actual) monitor to put the Code Monitors on full screen.

I've not explicitly tested the file opening on MonoDevelop, but I'm not using methods that specifically reference Visual Studio. It should work with any selected API from Unity's preferences.

I think it's more convenient to have all the posts in this thread.. but I'll keep the reddit thread alive just in case someone wants to post something there!

I do feel that this requires a bit too much of manual labor, and I hope to keep Code Control as user friendly and out of the box as possible. I think the Send method will evidently require you to define the used enum to keep things simple. Would that be something that you would be willing to use?

Thanks again guys! Really excited to see these discussions going on

 

Just got it!

 

Thanks for purchasing! Let me know if you stumble upon anything!

 

But this needs to be done with every call. My suggested method only happens once after package import/update. You could even automate it a bit more and check for the files in a static constructor so this is called "automatically" each time. Have seen this method at another package but don't remember which yet.
But I would also like to hear other opinions.

Also purchased it btw .

 

Would also love to hear more opinions! Automatically checking the files sounds interesting. Thank you for purchasing!

 

I bought it too.

 

You're awesome!

 

Hi,
I picked this up recently and have just started going through it. Looks great so far.

I like the idea of a simple clean MVC solution as all the ones I've come across impose more development friction than they are supposed to solve. I appreciate your focus on clean and simple, as too many developers in this area seem to get carried away with their technical cleverness rather than focus on providing a clean skeleton to speed development.

IOC proponents in particular are guilty of this.

Some initial feedback based on the above threads and my own *limited* evaluation so far:

• A comprehensive tutorial/example using new Unity UI would be much more instructive than using a custom one.
  
  
• I've done a lot of apps using the http://wiki.unity3d.com/index.php/Advanced_CSharp_Messenger which works really well, but can become a pita tracking message flows in a complex app.
  Enums as outlined above might be better than strings, even with your visualization..
  
  
• JSON might not be in C# core but there are a bunch of standard JSON libs around that are mature and solid.
  I don't really understand your reasoning for XML over JSON in this regard, given the general shift towards JSON as a more lightweight data format.
  
• Hard coded configuration in the example is also a bit strange. Shouldn't the base system have something flexible inbuilt, as data save/load is already a part of the framework?

Look forward to more developments.

ty!

 

Hi sonicviz! Thank you for your feedback!

I've thought about this but eventually decided to make some custom interactions as the new UI of Unity still seems very young, and will probably change a bit in the upcoming months.

I'm really excited to see how this will turn out.. I think the mini map will do a lot, but when people get to develop bigger and bigger projects using Code Control I'm open for feedback in managing the complexities.

Yes I think enums are a good idea.. I'm thinking about adding this using the Message.Send<EnumType>(EnumType enumValue) variant.

At the time I didn't fully commit to researching the custom serialization of JSON, but after reading into it a bit more it seems doable. I'll look into it a bit more

Thanks again for your purchase and feedback!

 

Haha! I like that!

I spent weeks recently looking at two very popular ones: an MVVC and an IOC one. My head is spinning! Code Control looks like it may be the best.

 

I got this in the sale because it looked interesting for future use, now I've been looking into starting to decouple my code and remembered I bought this and the message monitor really intrigues me.
Now I'm fairly new with the MVC pattern (been trying to write regular applications using it for work) and I have a few questions (I haven't had the time to touch the code yet, I'll revise my list as I get my hands on the actual code and look at the examples, if there are any. I did read the tutorials on the site. Let's pretend I'm a potential buyer for now):

- Is the model system exclusively for saving and loading data?
- How does it all integrate with the editor? Is the controller something I can attach to a gameobject or do I need to have another gameobject create a controller at runtime?
- Are model properties exposed to gameobjects in the editor?
- Can I just use the Message system in regular monobehaviours, or even other classes? Just got a minute to try this out, looks like I can! I just sent a message with a custom class and another script received it!

 

Hey man I really like your plugin! It's awesome. The only thing I would really like you to add is a view tutorial. You did a great job walking through the model and controller sections. Luckily I'm familiar with the MVC model, but if someone had never used this approach before that would definitely help.

 

Hi guys, thank you for posting!

Well, it basically is. It contains all fields that need to be (de)serialized for a later (gaming) session for a particular object. Fields that are only needed within the (game) sessions should be stored in the controller instead. In addition to saving and loading, you could give models some query methods like personModel.GetFullName() or levelModel.GetEnemyCount() to make establishing these values a bit easier.

In Code Control the controllers are components that need to be attached to a GameObject. The Controller class has static methods that facilitate this:

Code (CSharp):

1. // Instantiates empty GameObject, adds and returns a controller of type T
2. Controller.Instantiate<T>(Model model);
3.  
4. //Instantiates prefab duplicated from resource and returns its controller component of type T
5. Controller.Instantiate<T>(Object resource, Model model)
6.  
7. // Instantiates prefab located at path in resources folder, returns its controller component of type T
8. Controller.Instantiate<T>(string path, Model model);

The Saving and Loading Models tutorial explains more about instantiating the controllers based on deserialized models. The example project included in the Code Control package shows this in greater depth

Models are actually no subclass of Unity's MonoBehaviour, so to won't show up in the inspector.

Like you said, yes, this is very much possible. I'd even say that the Message functionality and its Code Monitor could be useful for projects that don't even need the MVC part of Code Control!

This is a good point. I felt like the Making a Controller is already covering this a bit. The transform component that the ExampleController is updating in its OnModelChanged method is, in a way, a part of its view. Maybe a tutorial that uses Unity's new UI, like sonicviz said, could work for a dedicated view tutorial?

Thank you guys again for all the feedback!

 

The Message monitor is godly, that alone already justified my purchase, really well done

 

Woa, thank you!

 

Got it last Friday, and I am thinking about using it even if only for the model abstraction, to save and load data in a structured way. I like what I am seeing so far, but I have some some small comments/considerations:

The names of the classes are too generic. Model, Controller: these should probably be wrapped in a namespace, no? Or use something like CCModel, CCController etc. This would alleviate colllisions, I think, specially in bigger projects with lots of 3rd party assets.

Also I like the messaging system, and the strings do not bother me so far

 

Hi Piacentini! Thank you for your purchase and post

I agree. I'm thinking about putting them in a CodeControl namespace. My only hesitation is that it will make it harder for beginning programmers to follow the tutorials so I'd probably need to make a separate step for that, but I guess they should learn namespaces sooner or later.

Thanks again!

 

Hi,

In the "Making a Controller" tutorial it says that Controllers extend Unity's MonoBehavior class. But I looked that the Controller,cs file and the Controller class at the very top of that file doesn't extend MonoBehavior.

 

I think so. The new Unity UI is very stable and will only be added to.

re: Namespace

Yes, please! This is essential for any code component now.

 

I'm trying to conceptualize how Controllers and Views are in the Code Control world. Am I thinking in the correct way here...

Before finding Code Control I was studying StrangeIoC which, if I'm not mistaken, classifies views as the GameObjects that we see on the screen. Every GameObject has it's own view. So if the example provided with CodeControl, was done with StrangeIoC, the buttons, Towers, and Missiles would all be Views/Mediators and their controllers would be separate and not be attached to the GameObjects (since StrangeIoC Controllers are not MonoBehaviors). A StrangeIoC Controller may be responding to and updating multiple View/Mediators.

But following the "Making a Controller" tutorial and the Code Control concept, Controllers extend MonoBehavior and are attached to GameObjects. Therefore, unlike StrangeIoC, views are not GameObjects. The Controllers are the GameObjects (or more correctly, GameObjects have Controllers directly attached). Views would be how you display the game objects (how the game world appears in 1st person is one view, and then how the game world appears in a mini map is a second view). So a Code Control Controller is a Component on a GameObject.

 

1. In the Code monitor when playing the Example, under Message Flow, I can understand the significance of Model and Handler (Controller). But there is also a Controller under Actor. What is 'Actor'? And in what cases would a Controller appear under Actor as opposed to Handler?

2. If a Controller changes something in its Model and it calls model.NotifyChange, won't that cause a circular reference (infinite loop) when the same controller's OnModelChanged() method is called?

 

Hi again guys!

That's actually the static class of the controller, containing its instantiate methods. If you scroll down, you'll see the Controller<T> class when T is the model's type of that controller, which is a subclass of Unity's MonoBehaviour.

This is correct. I considered but did not see the value of having a controller that is detached from Unity's MonoBehaviour, as having a coroutine in a controller that is not derived from a MonoBehaviour would introduce much more complexities than it would solve. Like you said, a button, widget or other 3D object that is contained in another GameObject can still be used as parts of a controller's "view".

I think you are talking about the Model Relations monitor here. The actors are the classes that call the model's NotifyChange() method, and the handlers are classes that listen to that change. In this video I explain more about the code monitors of Code Control.

This would only become a loop if the controller would call the model.NotifyChange in its OnModelChanged handler. I wouldn't recommend on doing this

 

Still wrapping my head around the concepts of the framework, so it would not hurt to ask... I see that you have a way to instantiate and bind a GameObject from a prefab when you instantiate a controller. So you have for example a Rocket prefab that is instantiated automatically when you create the controller, and when the model is deleted it takes the controller with it, and the prefab as well. Am I right so far?
In my case, I have different prefabs that can be used for the same generic Type of object. Let me explain: I have an Apple prefab, an Orange prefab, and a Banana prefab. They are all really just Fruits. So I would like to create a FruitModel and a FruitController only. The type of fruit is a property of the model (much like the color of the turret is a property of your example model). How would I go about implementing this without too many twists?
One possible solution would be to instantiate an empty 'fruit' gameObject and then later (as part of the controller) instantiate another banana/apple/orange prefab that is child of it, based on the type. Or is there another way that is easier/more reliable?

 

That sounds like the best solution, yes. The empty "fruit" object would have the FruitController attached and it would create a banana/apple/orange as a "view". Indeed, when created as a child, this would automatically get removed together with its parent (controller). If the view would not be a child then the child should be cached upon instantiation and removed manually in the controller's OnDestroy method.

Let me know if it's still unclear ^^

 

Hi,

In your sending messages examples you always add listeners in the Controller's Awake() method, and remove the listener in the corresponding callback as soon as the message is received. But I don't think that is good because if the same message is ever sent again, that listener will not exist. Therfore is there another place where listeners can properly be removed? I was thinking in the Controller's OnDestroy method because that will be called when the Controller's model's Delete() is called. Or is it too late to remove the listener there?

And what about if I delete the Controller without deleting the Model? In that case where would be the best place to remove the listener? In the Controller's (Monobehaviour's) OnDestroy() ?

 

Hi TokyoDan!

Indeed, the tutorial is just an example that shows how to listen and stop listen to a certain message. Most controllers will probably remove their listeners in their OnDestroy method. For the sake of the tutorial I decided to keep it simple, so no added OnDestroy. But based on your feedback I will consider making a small side note saying that in practice it almost always uses OnDestroy!

Thank you for the feedback! Please let me know how your projects using Code Control are progressing

 

In the Message Flow window I'd love it if I could drag the objects in the display around. Here is a screenshot of what CodeControl does. You can see that everything starts from the ByuButtonView which is in the center. On the Right is the TwitterServiceController with its incoming and outgoing messages. On the left is the FBServiceController with its incoming and outgoing messages. But although the right side is easy to understand at first glance, the left side isn't. Or visa versa. because they are positioned differently (although they represent the same information) Which side makes sense and which side doesn't I guess depends on which side you look at first.

It'd be nice if I could drag the objects into the same positions on the left and right so that each side makes visual sense at first glance. What I'd like to see is something like this: (It doesn't matter how the arrows are placed or angled. The important thing is that both sides are equally placed)

 

Hi again!

This sounds like a cool feature, I will look into it. Though it does mean that, as the Message Flow is generated in runtime, the custom positioning is probably lost when the game restarts.

 

I could live with that. I realize that it'd be almost impossible to get everything (that can be symmetric) symmetric in a more complicated MVC graph. And what makes sense for one person may not make sense for another person.

Hmm. just thought of something. How about being able to save the positioning so that you can reload it (if desired) after the game restarts. There could be a 'dirty' boolean that is false if no changes (that'd possibly cause different positioning) have been made, and set to true if changes have been made. Only if 'dirty' is false (no changes) could the saved positioning be loaded. If some change causes 'dirty' to be set to true that could also cause the saved positioning to be deleted to keep it from being loaded.

 

Good idea, I'll keep it in mind!

 

In the CodeControl example I am trying to figure out how the Rockets pick up their models. I know that Rockets are instantiated in GameController and TurretController. And I know that Instantiating a RocketController creates a gameObject with the RocketController.cs script attached. And I can see that each Rocket(Clone) gameObject has a Fbx_Rocket child that is the model which we can see.

How/where/when is this Fbx_Rocket childed to the Rocket(Clone) gameObject?

 

The models are passed on to the controllers when they are instantiated:

Code (csharp):

1. // Instantiate ExampleModel for the ExampleController
2. ExampleModel model = new ExampleModel();
3. model.Position = new Vector3(1.0f, 0.0f, 1.0f);
4.  
5. // Instantiate the ExampleController and assign the model
6. Controller.Instantiate<ExampleController>("ExamplePrefab", model);

I've added an optional parameter to the Instantiate method of the controller so it is easier to define the parent transform of the child. Making it an actual child will automatically destroy the child when the parent controller is destroyed, which is often what you want.

Code (csharp):

1. // Here, no parent is set and the rocket will be parented to the root of Unity's hierarchy
2. Controller.Instantiate<RocketController>("Rocket", rocketModel);
3.  
4. // Here, the current class's transform is set to be the parent of the rocket
5. Controller.Instantiate<RocketController>("Rocket", rocketModel, transform);

Let me know if this is what you meant! ^^