Cutshumoto: some game issues and our solutions

When you have to face a videogame development challenge, especially when it will be you first approach,  many questions are raised. The most obvious is … ¿How to?

The answer is not so obvious because this “How” require a lot of previous decisions. In our case some of them, like technology, were chosen by others.

This aspect will affect our game architecture because the engine provides some work directives and pipeline you have to follow to use it. However there are many decisions you have to take.

Project Anarchy provide a wide range of options to develop your game. You can choose  to design your entire level using VForge (WYSIWYG tool) and define your game logic using LUA scripts. This option has some pros like immediacy. You should have a C++ project in order to build your game but you spend less time exporting you scene, closing VForge, compiling your project, open VForge and loading the project again… In addition you have a lot wrapped functions in LUA which reduce code complexity. Doing this functionality using Vision C++ api is not so trivial.

Other hand you have some cons… the script development interface is much worst than Visual Studio, game performance, more control (custom render loops, shader operations…) and a totally subjective aspect: improve our C++ level and experience.


We need an intensive flow of creation and destruction of entities for our game and a lot of elements in screen. Also we wanted this enemies creation was pseudo random in realtime, using  patterns defined by the game designers in order to each play was different, so manage it in C++ seemed a  good idea.

Our first concept was (and it worked quite well in the prototype) create our scene in real time while the player runs and dynamically spread the terrain like if it were a child book, but it had a problem; the field of action for artists and designers was reduced dramatically because it has to be done from code (surely not but it’s a different history :P). Our enemies factory reads some json files to create them and these files include a lot settings that designers can edit but it’s hard to control the game rhythm because each rush is different.

Then we decided  to search another way to give more design control over  the levels and this decision means losing the randomness of the level creation, of course. Now appears the third work method you can use in Project Anarchy, integrate your C++ classes and functions in LUA using SWIG. This is surely the best option and we should have designed our architecture with it in mind instead of use it so late.

Thus, it was decided that levels would be totally designed using VForge, discarding also the dynamic terrain creation in order to give to artist all control over the visual aspect of the level. I have to say that performance was another reason … terrain tiles had a lot of bones and props which affects to FPS rate in some mobile devices.

To do this we created some dummies, each of them for each kind of enemy. Designers could position these dummies directly in the VForge scene. A trigger box attached to the main camera performs a calls to the enemies factory when a dummy enters on it and the correct enemy is created in this position.

We lost the randomness in enemy creation, we lost the spread of the level… but designers can define the game rhythm and which enemy is created every time. And artists can put each prop wherever they want and be more accurate in other aspects like the lighting design.  In my opinion would be better to reach an intermediate solution but I suppose the time and the newness played against us.


We raised some issues  about the enemies ,  Project Anarchy uses an Entity-Component based architecture and provides the possibility of inherit from Entity class in order to develop your own custom entities with an specific behavior. You can also develop your own custom components  so we decided to use the Vision base entities and define their behavior and properties using custom components. The enemies were already defined by designers  and we saw many similar behaviour between them, because of that we thought to develop these  components to be used in some different enemies instead of make different custom entity classes for each enemy. Currently from the enemies factory we compound our entity with some components and properties defined in a json file for each enemy type.

Reading files was also an important issue because was not a good idea have to read a file every time we want to create an enemy because it surely would affect to performance, Alike mesh loading. Vision engine has a global resource manager and one specific model is only loaded the first time but if this first load produces an slow down if you request it in gameplay. To fix this problem we developed an enemy preload function which is called from LUA script. Every scene call to enemies factory preloading the enemies used in this level. Enemies Factory uses the singleton pattern, we store in a data cache the enemy settings and we load the 3d model without create an entity so when we really need to create an enemy during the gameplay the action is performed immediately.

Talking about our components… I don’t know if it was because it was something new for us or because we are so noob developing videogames, ignorance about Anarchy tech… but we really make a lot of them. At the beginning we did components for everything because it was the easiest way for us to join our vForge scenes and C++ code. In this endless road of making components we lost the main target of the component concept because I think that it should have very specific functionality and it should be disengaged in order to use it in different entities. Most of them follow this idea but in other cases it would be better to develop a custom entity class because certain components have no sense if not are attached to an specific entity. As I said we fixed a lot of these bad ways.

Finally, a summary of our architecture:

Internal Components. Only can be used from code, no exposed values.

External Components. With exposed vars in VForge that designers can change. For example camera effects component (shaking time when player is damaged, screen color…)

Singletons. They works as managers and could be used from the code or from the scene/LUA. For example Enemies Factory, Sound Manager…

LUA Scripts. For management of specific functionality in each scene.

SWIG integration files.



To conclude I would like to say we are not entirely happy about how we designed our game architecture. At least it was getting better along the time but certainly we would do different things nowadays. Indeed we changed our approach a few times (Yes, for a while we tried to combine pre designed levels and random enemies creation but it’s a different tale…). In our defense I have to say we had to face with a technology like Project Anarchy that is hard to use for a first approach to videogames programming. It has a lot of bugs, it has not a big community with already resolved doubts and mobile debug is like a hell, we spent a lot of time searching bugs that we can’t reproduce in PC version. But there are good things… We have learned much more using Anarchy than other more friendly engines like Unity. It’s a personal challenge but I want to develop more games using Project Anarchy when my UTAD adventure has finished.



Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s