Behavioural Oriented Architecture for Unity Games - It's needed and we're doing it!

At a point in my life (5 years ago) I decided I wanted to make a business (a real business life) on games. I decided to learn several tools and what I found is that finding the right ones for me and me team was not really easy. It took some time to decide our workflow.

Worse, not only about selecting and learning some of the tools (Blender, Maya, MotionBuilder, Photoshop, Unity,...). I realized with some pain that creating a game (even a small game) is usually a big challenge. A small team needs to work on UI, objects and use interactions, scores, level design, missions, achievements, dynamics, saving information, networking, settings, ... This is why a lot of projects are abandoned without getting to a conclusion.

The main reason is that in order to make a game I realices we didn't have nothing close to the notion of an architecture to make games (this is usual when you develop Enterprise Software - people make their lives around it and, obviously, they need templates, guides and structures that make them feel comfortable with the projects they build). It was clear to me that in order to make a real life out of this we would need to generate games really fast. Hoping to make enough money with only one game is unrealistic so I decided to create this approach (the architecture, specifically, a Behavioural Oriented Architecture).

BoA is a project intended not only to accelerate the creation of games but, more important, to give the developers an architecture, well designed, efficient, easy to work on, extendable and oriented to behaviours in order for the community to create games faster, easier, more predictable.

Let me put an example: A Game has Levels. A Level has Achievements (Scores, Coins Collected, Distance or Time) and Missions (the challenges the player needs to achieve in order for the level to mark). A Game has a player with its input, has Objects that react to collisions, play sounds and particles, move around, react to orders, etc... In BoA everything is a Behaviour linked to an Object. Briefly an Object may have zero to an unlimited number of Behaviours (OnCollission, BecameVisible,...) and every Behaviour can call a number of Actions (Kill, Increase Score, Reduce Time, Communicate with another Object by Name or Tag, ...) as a result of this Behaviour. The concept is simple and elegant. This is an architecture.

The Architecture has skeletons that allow developers not to create from scratch their games. Really the games can evolve only adding (from Unity Editor) new Actions or evolving new Actions (extending the script Action_Custom). The GUI accepted is NGUI or Unity GUI (wrapped with Panels scripts that can have additional Behaviours with their own Actions).

As I said we're working on that. My intention right now is only sharing the idea and looking for feedback, challenges or questions.

My Challenge: I will share BoA (Beta because my intention is make it really affordable in a future in the Asset Store) at the time I can make "Space Invaders" with at least 4 levels in only one day. We'll try to crono ourselves in order to check how much time we invest in making Unity 2D Example (I expect no more than 1 hour). But more important, all that has been done will be reusable, extendible and efficient. We will be able to extend every game made with BoA without problems as no coding (unless extending Actions functionality) is needed and everything is tested.

BoA is no runtime. Everything is compiled so efficiency is no compromised. Not only intended to make prototypes as other tools, it's intended to make real games (with mobile decides as main target).

Any feedback will be greatly appreciated at this stage. I know little detail has been shared but you may agree with me that something is needed when you are a small team (maybe only one in the team ), with low budget and you REALLY want to make your game, publish it and have the possibility to improve it and/or generate another one in a fraction of time and with confidence.

Right now BoA is being tested in 2D environments but nothing prevent it to work in 3D environments. 3D will be released after BoA 2D is in production and accesible in Unity Asset Store.

Life is a Game: Play!

 

With Boa it's a matter of minutes. Ley's share the appeareance of the gane "Space Invaders":

 

Et voilá!
Game running!!!!!

 

???

What you've described with multiple behaviours attached to objects is pretty much Unity's component based design.

I hate to break it to you, but it's already built into the engine.

 

Yeah... That's what this looks like to me, too.

In Unity everything is a [Mono]Behaviour linked to a [Game]Object. In Unity the things you're calling "Actions" are just "functions" or "methods" a-la everyday programming.

How is your system practically different to this? What does it do that significantly reduces effort, thought or time on my end?

I like the concept in principle, in that you're looking at a "Minimum Viable Product" (MVP) to determine if it's worth further effort. However... it strikes me that this MVP only gives me something I already have. Providing a different workflow isn't enough. I can already make Space Invaders in a day (point in case: in my early game dev days I built Space Invaders in 2 days in XNA as an exercise to learn the framework - just switching to Unity alone would easily cut that to a fraction of the time).

How does this make my life easier? Or, am I simply not the target market? (Eg: maybe it's aimed at non-programmers?)

 

There has been a ton of research into this type of design, it's loosely called entity component systems, and you are re-creating the wheel basically. Unity's design has some aspects of this type of design. Where I usually end up needing to extend the paradigm is with data.

Google entity component systems

 

Thx a lot for your messages. Really appreciate your views.

I agree with you. Unity as an engine is behaviour oriented but the reallity is that, as any tool, allows you to make things perfect or awful.

I discover it's the same problem I had in my early days of programming: I found C++, and later C#, perfect to program: they have classes to elegantly hide complexity, inheritance, polymorphism, late binding, ... all the tools I dreamed to make my systems. Buy without architectures, guidelines, templates you may end yourself navigating on complex code, strong linked systems and so on.

In the case of Unity (this is my opinion) adding scripts to objects and this way creating "components" is extremely useful and fast (I'm in love with Unity for this!), but on the other hand it may create bad habits and at the end may create systems that are very difficult to maintain and evolve.

I created games this way but it's like approaching the creation of the games in a very artisan mode. You can code almost everything in the Player component, create a GUI and create dependencies on every object or component that want to update it, missions; you can code the missions targets and completition on almost any script (as components are globally accesible by Unity). I think providing some kind of guidance (this the architecture word arises) is the way to put order in the way I would want to make games fast, pretested and reusable.

Say for instance you are supposed to create always a Game_Manager component (Empty object with Game_Manager Script). This object is able to launch events like GAME_PRESTART (that has a number of actions like Action_Play_Sound, Action_Play, and Actio_Panels that shows some panels prior to start the game).It's very simple but I want to show the concept of behaviour in a high-level point of view.

Game_Manager may launch another event GAME_START and at this time you may have other actions that may be launched (with parameters obviously, timing, conditions, ...) that may show the Levels Panel (Action_Panel). To have additional order the Game itself could be structured in Levels, a Level has Achievements, Sequencers, Spawners, Missions, ... all provided in a structured way.

You may end building your game adopting this approach. Nothing is interpreted. Everything is compiled and you can extend the components using inheritance. At the same time you can call almost anything to the architecture (like - all missions for the level completed, number of coins collected, load punctuations or ranking for the game, ...).

I'm very interested in reusability and fast creation of games. At the end I think it's definitively a business and until know, after trying a lot of tools what I missed is this structured approach to make a game. More than a guideline it's a coded way to "describe" what is supposed to happen in a particular moment (simple and multiple collision, spawning of objects, pool usages, ...).

Clearly I'm not explaining very good but I hope you'll get the point. In a while we will be prepared to post a fist approach (beta) of the architecture and I would love the people will taste it and give us his thoughts. At the end this is the most valuable asset we can get from you out there!

Thx again for your time reading my stuff and don't hestitate to put additional comments, doubts, critics or whatever you consider of interest.

 

Great comment. Thx

It's aimed to programmers basically. Non programmers only would have the opportunity to create objects, put the Events_Dispatchers and Events_Listeners and put the Actions that will be launched at suscription. The real power comes when you, more than reusing actions, develop additional actions to be launched. For instance: I developed in a matter of minutes how to populate the Levels panel with information of the Level_Manager components of the Game. Usually developing the panel and populating it is, obviously, no the most complicated task to do, but you need to put additional time in a part of the game that, honestly, doesn't add value, make you less efficient.

Every action is parametrized so non-programmers could use them but, again, it's oriented to programmers.

 

Thx a lot for your comment.

Let me disagree a little bit. I agree with you that the main part is to add data. But the way you structure not only your code, but the taxonomy of your game is important. The structure is important. In our tool you're supposed to have a Game_Manager object, with (n) Level_Managers. Every Level_Manager has (n) Achievement_Managers that comunícate with GUI_Elements. Level_Managers has (n) Mission_Managers with conditions like limited time to accomplish, greater or lower threshold to be achieved,... Level_Managers has (n) Sequencers that communicate with Spawners. The Spawners communicates with Pools or Prefabs. And every Object know how to communicate with other objects, achievements, etc...

This way you'll have a loosely coupled and structured system. You won't ask again where you're supposed to code something and will only focus on the "behaviour" of your game, with testing in advance as every action would be tested in different environments (Play sound, play FX, Kill, reduce or multiply velocity, move, disappear, collisions, ...)

All those elements (and actions) are parametrized and is where the "data part" of this history lives.

Again thx a lot for your comments

 

Thx a Lot.

Unity is designe this way but it "helps" you to mame awful things in termes of structure of the conde to mame the game.

Basically every object in the architecture has a Event_Dispatcher (catchs eventos from Unity, like Collisions, BecameVisible, ... and eventos that the architecture and any element can launch: on_gui, on_start, on_initialize, ...).

Any object that has this Event_Dispatcher will hace Event_Listeners that would be specialliced (for instance: ON_GAME_PRESTART will launch a Lot of Actions, that at the end are specialized scripts that do something). And this is the concept of multiple behaviours attached to an object. It really doesn't extend Unity, mor hides any particular thing, but rally helps to puf order and make ganes easier at the end. This is my goal.

 

Sorry for the awful reply. It appears my "autocorrect" decided to change words on the fly :-( ver y frustrating... my apologies.


Rewritting:

Unity is designed this way but it "helps" you to mame awful things in terms of structure of the code to make the game.

Basically every object in the architecture has an Event_Dispatcher (catchs events from Unity, like Collisions, BecameVisible, ... and events that the architecture and any element can launch: on_gui, on_start, on_initialize, ...).

Any object that has this Event_Dispatcher will hace Event_Listeners that would be specialliced (for instance: ON_GAME_PRESTART will launch a Lot of Actions, that at the end are specialized scripts that do something). And this is the concept of multiple behaviours attached to an object. It really doesn't extend Unity, nor hides any particular thing, but really helps to puf order and make ganes easier at the end. This is my goal.[/QUOTE]