First of all, this post is not intended to initiate or encourage a flame war, neither to be a deep comparison about these tools. This post is just my personal opinion about the matter, feel free to disagree with me or contribute with it in comments.

As written in my previous post, this last week I was trying to decide which engine I’m going to focus from now on – Unity 5 or Unreal Engine 4. Both tools are really great, with huge community, good documentation, several resources, etc. In special, Unity has grown A LOT since past few years acquiring a legion of fans (just look at ludum dare!).

However, I think Unreal Engine is a better option FOR ME, because:

Engine features

This is actually the most important reason of why I prefer UE 4.

Unreal is a mature tool with several years of development, so it is natural to UE have a lot more stable features compared with Unity. For example: material editor, behavior trees, animation editor, visual scripting, great debug tools, general game structure, etc. But…

Unity doesn’t have feature X, but you can find a solution for it on the asset store

I read this a lot. Unity does not have scene transitions, but you can buy it in the asset store for 75$. Unity does not have a node-based material editor, but you can but one in the asset store for 90$. It is good to know that there are so many stuff in the asset store, but still:

  • There are several essential things that Unity should provide.
  • Most assets are over-priced – 75$ in a scene transition? Really? – Moreover, it is pretty easy for an American or European to buy a couple of packages with 200$ or 300$, but for Brazilians trying to make some small stuff, 300$ is A LOT OF MONEY (in this very moment, this would be equivalent to 1500$+ for an American or 2000$/2000+ for an European).
  • Lot of assets sucks – the Unity team seems to understand that quality matters just now, and still they don’t have a practical solution for it.
  • Lot of assets are incompatible. Now suppose you buy 3 cool assets for 1500$/2000$ and then discover that you can’t use them together.

Again, it is awesome to have lots of useful stuff on the asset store, but I (with big I) don’t like and can’t afford this current model.

Programming and game structure

Unreal uses C++ while Unity uses C#. I need experience on C++. Not preference on this one, only utility.

Unreal also uses a visual scripting scheme called Blueprint – which enters on the feature discussion above. Blueprint is awesome and deserves an article exclusively for it.

Still in the programming aspect. I am a lot more comfortable with Unreal structure. Every time I try to do something on Unity, I end up frustrated. Unity enforces some crap solutions based on its entity-component system. Just look at the number of singletons that people spread around forums.

Open source

I’m an open source guy, and I believe that OSS is a sustainable solution for any kind of application. With open source softwares – in special those maintained by a big company – we have a more efficient flow of bug discovery/correction and the guarantee (in a certain level) of good features, since users can evaluate, criticize, and contribute directly to the code, even before its release.

On the other hand, companies with proprietary tools must have a bigger investment to supply this quality and efficiency on the development. Moreover, with proprietary tools, your project will be tied and sometimes hanged, for example: the Brazilian government lost MILLIONS of digital documents some time ago, because they were all in an old proprietary format that were deprecated and the company didn’t provided any real conversion solution for them – after that the government started to adopt open formats for their documents.

The Unreal Engine 4 is open source, they capitalize on a percentage over the revenue of your game. They also provide several GOOD QUALITY assets and example for free (for non-commercial usage), so you have a big base to start your prototype and study.


In summary, I’m going with Unreal because:

  • Features
  • C++
  • Better structure
  • Open source
  • Good base assets

Reminding that, this is a personal choice based on personal motivation and preferences. I don’t want you take this as confident basis for you. Both Unity and Unreal are great tools, try them for yourself.

Read more

Past weeks I could’t do much on my studies and developments on game dev. I had some big changes on my short-term life plan and, therefore, I had to think what to do with this. One of these changes includes how I am going to dedicate my free time – what I’m going to learn? – and how I am going to make my game programming portfolio.

First of all, I’m reading the book Game Engine Architecture and I hope to write my own engine and practice my C++ following this. However, this isn’t much for a programming portfolio, I also want to show that I know how to implement gameplay elements, quest systems, loots, inventory, stats, and some other common stuff we found in big games.

To be parsimonious with my time and efforts, I also would like to implement these stuffs in a – complete and professional – game engine, so I can learn something useful for the industry and don’t lose time with basic aspects of the engine. So this week I’m going to take a look at Unreal Engine 4 and Unity 5.

Read more

This post is actually from the previous 2 weeks.

I finished the book Accelerated C++, by Andrew Koenig and Barabara E. Moo, and started the book Game Engine Architecture by Jason Gregory. Thus, this post is the last highlights through the Accelerate C++.


Assignment conversion

When using the assignment operator (=), the compiler may use constructors with single arguments to implicit convert the right value of the expression. For instance:

std::string s;
s = "this is a char*";

The assignment creates a temporary object string that receives “this is a char*” as parameter and copy all the temporary object attributes to the s object.

Friend functions

Inside a class, you can define external functions that are friends, for example:

void externalFunction(MyClass& c) {
  std::cout << c.private_var;

class MyClass {
  friend externalFunction(MyClass&);

    int private_var = 0;

This means that the function “externalFunction” can access the private properties of MyClass.

Class protection

  • Public methods can be accessed by all objects.
  • Protected methods can only be accessed by children of the class.
  • Private methods can only be accessed by the class that defines it.

Notice that this is different from Java, in which protected methods means that only objects in the same package can access that information.

Inheritance visibility

Inheritance in c++ also has visibility access:

class Grad: <visibility> Core { ... }
  • In public inheritance, everything is aware of the inheritance.
  • In protected, the child and subsequent children are aware of the inheritance.
  • In private, only the immediate child is aware of the inheritance.


Virtual functions

Suppose you have two classes:

class Dad {
  int m() { return 1; }

class Child: public Dad {
  int m() { return 2; }

and the function:

void printM(Dad d&) {
  std::cout << d.m();

Dad d;
Child c;


Normally, we would expect to be print “1” and “2”, but in both cases the result is “1”. That is because you must explicit say to c++ when you want to use the children methods in polymorphism. You do that with virtual functions:

class Dad {
  virtual int m() { return 1; }

With this, now we have “1” and “2”.

Note: the polymorphism is only possible when working with references or pointers.

Virtual destructors

This is really, really ugly.

The same example about virtual methods above is also valid for destructors. If you call the destructor of d, without virtual, the Child destructor won’t be called and this will probably send your program to hell. Always declare destructor as virtual if you want to use inheritance.

Pure virtual methods

When you do:

class Dad {
  virtual int m() = 0;

You are declaring m as a pure virtual. This means:

  • The method m is abstract and MUST be overridden by children.
  • The class is abstract and CAN’T be instantiated.

Forward declarations

Used when you need to use a name before defining them. For example:

class B; // forward

class A {
  B* ref;

class B {

Storage-class specifiers

Determine location and lifetime of a variable:

  • register: suggests that the compiler should try to put the variable into a register (in order to optimize the access);
  • static: preserves a variable after leaving the scope;
  • extern: tells the compiler that this is not a definition, only a declaration. The variable is defined somewhere else;
  • mutable: allows a variable to be changed even when an object is const.


How the book looks like after all annotations

Read more

The 32th ludum dare happened this weekend (April 16, 2015), with the theme “unconventional weapon“.


I have have to say that I hate this theme. Really, there were so many good themes there, why this one could win? Damn you!!!! The theme isn’t an excuse to not do a game, but I spent so much time thinking of what I could do with this… A game not based on fights? Weapon is love? The weapon must be abstract! This is clichê? Oh damn… I finally came up with an idea, after 14 hours (counting sleep time)!

My game entry is about “democracy”, with quotes. The democracy and progress are the weapon of the government in the game, they want you to attack other species in order to “spread democracy and progress through the galaxy”. The player controls the invasions to planets inhabited by bugs with the goal to kill the natives and collect the planet resources.

The game is a very humble tribute to starship troopers (novel by Robert Heinlein and film by Paul Verhoven and Edward Neumeier). I wanted to create, somehow, the sense of order and progress presented by movie.


I always start by the core mechanics because it is the main component of the game – if I can’t find time to make graphics, at least I have a block-based game.

I also always wanted to create a game in a circular world, that was my excuse. I had no idea how to do that, but at is was pretty simple. You have a world centered at (0, 0) with radius (r), than you can set the origin of all objects in the world to (0, r) and only manipulate the rotation to place than in the world.

After the basic world structure, I could drop structures, and these structures could create units. To control the units, I created a behavior tree to control each unit – the first time I really use behavior3js – and a behavior tree to control the bugs strategy. Figure below show these behaviors trees:

Behavior tree for player and enemy units.

Behavior tree for player and enemy units – Click to see in full size.

Behavior tree for the nests, its used to create orders to enemy units

Behavior tree for the nests, its used to create orders to enemy units – Click to see in full size.

Then it came to particles and easing! Man, I love these two. The animation below shows the game at this point:

Sample of democracy

After 28 hours I started to create the sprites and visual things in the world. I was stupid enough to lost time adding some details to sprites that don’t even will see because the sprites are very small (about 20 pixels). I also spend a good time trying to create a futurist screen aspect, which ended up very cool.

I added some scenes, UI and some other effects to the graphics:


When the clock marked 5 hours to end the competition I started create sounds effects and music. I was desperate because of the time, I still had to adjust the levels of my game and I didn’t know what to do with sounds. At the end it was pretty simple and I didn’t do much, actually recorded some sounds with Audacity, generated most of them in BFXR and generated the music in SoundHelix.

I finished the game in the packing hour, the extra hour after 48, the time to deploy and write about your game.


Good stuff:

  • Game finished is always good!
  • I’m using BTs successfully, even to control hundreds of creatures.
  • A circular world (always wanted to try).
  • Visually smooth and lot of cool PARTICLES!!!!!
  • Generative music and sounds worked well.

Bad stuff:

  • Balancing is hard as hell, I couldn’t do that properly.
  • Some details missing, especially the visual feedback when you win the game and the bug when restarting a level before a tween is complete.
  • Isn’t much fun due to balance, few types of units, and few levels.

I’m very critic about my games, I really fell for to not balance properly and create more content to the game, but well, it was made in 48 hours and this time the good stuff was really good! Moreover, this was the most complex and complete game I ever made for LD, it was really hard to do, thus of course some things would be missing.



Read more

So, what is happening here? Almost March and I didn’t post anything useful here, hum? Well, I’m working hard on Behavior3 and on my Ph.D project. There is a lot of interesting things happening, and I hope to share some with you in time. For now, let’s talk about some major changes on Behavior3 Editor.

First of all, Behavior3 Editor and Behavior3JS are now individual projects, each one with its own repository. Check it out:

In the first version (0.1.0), I tried to make a visual editor, a visual debugger and, common to these two, a viewer. The viewer were responsible for drawing the blocks and connections in a canvas, the editor were responsible for the edition of blocks and connections (adding, removing, selecting, changing properties, moving, etc) and the UI needed to handle that. The debugger were planned to control the execution of the tree and view the information of nodes. This architecture were suppose to be modular and easy to handle, but…

It was a complete nightmare, when you had to change something, you never knew  if you had to look to the editor or to the viewer, and when you modified something in the viewer, you had to build it (because editor were dependent on the built viewer), copy the built file to editor – then, you find a small typo, change again, repeat the process, over and over. Moreover, despite the fact that the editor worked fine, it was depending on the HTML elements, i.e., any change on the HTML stops the internal functions, any change to the internal functions stops the HTML elements.

To overcome these problems, I firstly merged the Viewer and Editor, so you don’t have to search inside two projects to find a piece of code that you want to change. The repetition of the build process was also solved, but the internal functions of the Editor were still coupled to the HTML elements.

AngularJS was the solution. A javascript MVC framework with two-way binding. Man, that’s awesome. So, I removed the dependence of jQuery and almost all other 3th party libraries, including foundation. I had to rewrite menu, scrolls and all other nice visual features, but at the end, it was worth and worked pretty well (some bugs on firefox, unfortunately). Check it out the general scheme:

b3editor - architecture

Current Behavior3 Editor Architecture – App and Editor are completely independent. App calls editor and listen to editor events.

With these architectural changes, I can add more features to b3editor. I already pushed a tree management (now you can add, edit and remove several trees) and I’m going to implement project management. To have a better follow up, check the issue list I hope to release the next version of B3 in the next 2 months.

Thanks for @grifdail, @elmarquez and @FunkMonkey  and Daniel Balster for suggestions and patches on this version.

Read more