Author's Posts

When I first read the theme “Small World” at the theme voting, I thought in making a circular world again (just like my last LD game). However, everybody is gonna do that! So, after a 2-hours brainstorming, the 2 first hours of the competition, I came back with the game idea.

I love the aesthetics of Besieged. All levels show a small village or a small campsite merged into a white-ish background, creating a very cool mix of white emptiness and green alive. With this mixture, you have the feeling that the whole world is just that small portion of green you are seeing. I love that, and I would like to try something alike.

After deciding the aesthetics, I had the feeling that a board game would fit well in this style, where the tiles kind of merge to the background. With a board game in mind, I decided the base rules, which are based on Zombicide: multiple missions, swarm of enemies, climax during the gameplay, varying missions, etc.

All set. A board game inspired by Zombicide and Besieged.

And as usual, even before the theme voting phase, I decided that this game would have something technical that I haven’t developed before. LD#30 was behavior trees, LD#31 was flocking algorithm, LD#32 was circular world and complex behavior trees, and, finally, for this LD#38 I wanted to give more time to animations – not the animation like in sprite sheets, but the animation effects like moving a piece, spawning an enemy, changing scenes, etc…

What went right?

  1. Although the game is not very good, I could finish it, and that was the biggest achievement this time. Sure, other Ludum Dares I worked as hard as this one, but this time the schedule was very, very tight – 3 hours to end the competition I was considering giving up because it missed so many things – but I could complete the base project scope that I have decided at the beginning.
  2. There were, impressively, very few bugs during the development, even the A star algorithm I could code in minutes without any problem. Most bugs I could fix in the last hour.
  3. I could do some cool animations and developed a nice animation scheduling (see below for more details). The animations are not perfect, but they were fun to implement, in special the enemy spawn and enemy movement are very cool!

What went bad?

  1. Very, very tight schedule so that I could barely finish the base of the game. Everything went as I expected, but who wants to barely finish something?
  2. Unbalanced and not fun, again. This is the problem I find in most of my games. I dedicate so much time on the mechanics (usually a bit complex) and the visual that I don’t the time to make it good. I should probably focus that on the next game.
  3. The game provides a few visual feedbacks only, but the player don’t have much idea of what is happening within the combat, or the player can’t even track the pawn actions properly.
  4. No music or sound, but that has always been my Achilles heel.
  5. I implemented a great customization system in which I can add new pawns, enemies, tiles, maps, or event different goals very easily to the game, but I only had time to create one map. If a jam game have lots of customization and lack of content, the customization was just wast of time.
  6. Developing a board game is really hard. I expected it to be complex and take a lot of time to code the game rules, but it is really hard to change and tweak how the rules work and interact during the development. If I will ever implement a board game for a Ludum Dare again, I will keep the rules very very very very simple.

Technical details

Some details of implementation:

The board game logic is completely independent from the visual and the user interaction, which made things really easy later. When the user select an action, the game (visual) asks the board (logic) for more information and render things. When the user perform an action, the game sends it to the board, the board perform and compute everything internally and returns a list of events that occurred internally. For instance, if the user attacks an enemy, the board returns the events pawn attack, enemy defense, enemy damaged, enemy killed, etc…

This messaging system is really great for board games, in special because I wanted to animate all actions, one by one, sequentially. Each message have a different payload, which is used to update the visual object properly. You may see the messages while playing the game if the developer tools is open.

Animations are trick to do. The problem with animations is that you must wait it to finish in order to continuing the operation of the game, thus, making its operation asynchronous. However, as any asynchronous system, other things are happening while the animations are working, such as the user clicking and moving the mouse everywhere (which causes a bug on buttons, don’t know how to solve that yet). To create this system, I added a job function attached to the scene, which can create multiple jobs and run that in parallel.

The job functions receives the duration of the job, the delay to start it, an update function which will perform the animation, and a complete function which is called when the job finished. Moreover, the programmer may stop every job at any time.

At last, I just want to recommend the Affinity Designer, it is a wonderful software for vector drawing, and it save a lot of time with the automatic exporting. I used it together with the Texture Packer and a small script to make the sprite sheet. It was really efficient: I save the document; the Affinity Designer export everything to a specific folder; then I just click export sprite sheet on Texture Packer (I only have to add new sprites if I create new ones); and run the script (I have a console ready to execute it), and done.

Images

Links

Read more

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.

Conclusion

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++.

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&);

  private:
    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.

See http://stackoverflow.com/questions/860339/difference-between-private-public-and-protected-inheritance.

Virtual functions

Suppose you have two classes:

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

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

and the function:

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

Dad d;
Child c;

printM(d);
printM(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 {
public:
  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.

IMG_20150706_114553920

How the book looks like after all annotations

Read more

This was a long week. We had E3 conferences starting Sunday night (for Brazil) and ending on Tuesday, with a lot of awesome – official – announcements: Fallout 4 (my next love), Dishonored 2, Doom 4 and new IPs such as Horizon (which looks very promising), unravel and others. During the week I’ve been playing Fallout shelter also announced on E3, which is a good-looking and funny mobile game, but has the same problems of other farming games: there is no end and it gets bored fast.

In the weekend, I start-and-finished The Last of Us. Man! What a game! I love post-apocalyptic games with adult narrative. My only regret is that I didn’t gave more time to it – I had to play on easy in order to finish in this weekend because I won’t be able to play it for the next week, and if I have more than 1 week gap between my gaming sections, I just can’t continue from where I stopped.

C++

Even with all stuff that happened this week, I almost finished the Accelerated C++ book. Here are some highlights:

Maps

You can create ordered maps defined in <map> and unordered maps defined in <unordered_map>. Their usage is similar, but map is slower to add new items due to the ordering function. Usage:

map<string, int> dict;
dict['key'] = 132;

If you try to access a nonexistent key in the map, this key will be created automatically.

Maps return pair objects as iterators. A pair type is defined as pair<const K, V> and has the following attributes (to key and value, respectively):

auto pair = dict.begin(); // first key in dict
pair->first // key
pair->second // value

About double angle brackets

In cases like map<string, vector<int>>, the compiler may have problem to parse the statement (due to the >> symbol), so it is recommended to use map<string, vector<int> > (with the space). This seems to be a an old practice, I doubt that compilers nowadays still have such problems.

Default arguments

You can use default arguments on function parameters, like Python:

void my_function(int non_default, int default=123) { ... }

Notice that, the parameters with default arguments must be the last items on the list.

Constant methods

C++ has a mechanism to protect object from write access, for example when you define a function like:

void my_function(map<K, V>& writable, const map<K, V>& non_writable) { ... }

where non_writable is constant. When a parameter is defined as constant, C++ only allows to read public attributes and call const methods, such as:

void my_function() const { ... }

Brackets on const maps

Due to the constant restriction described above, constant maps don’t have the operator [ ], because this operator changes the map when the key doesn’t exist.

Generics/Templates

Generics are called templates in C++ and is used as:

template <class T>
T my_function(vector<T> V) { ... }

With stand-alone functions you don’t have to specify the template explicitly, e.g.:

int a = my_function(my_int_vector);

The typename keyword

C++ has so many features on it that sometimes the compiler simply doesn’t know what to do. For instance, when you try to define a variable within a subtype defined inside a template, like this:

template <class T>
Class MyClass {
  T::SubType * ptr;
  ...
};

In this case, the compiler interprets SubType as a static member of T, thus, it tries to multiply SubType with ptr, causing an runtime error. Because of this, you always must use the typename keyword, avoiding compiler mis-interpretation:

template <class T>
Class MyClass {
  typename T::SubType * ptr;
  ...
};

Reference: http://stackoverflow.com/questions/1600936/officially-what-is-typename-for

Iterator categories

There are 5 types of iterators. They are divided by what they can do (thus, which operators are allowed) with the object they reference. The categories are:

  • Input
  • Output
  • Forward
  • Bidirectional
  • Random access

Consult http://www.cplusplus.com/reference/iterator/ to see the table of all operations these iterators handle

Stream iterators

istream and ostream can be used as iterators:

std::copy(v.begin(), v.end(), ostream_iterator<int>(std::cout));

This piece of code sends all elements of a vector v to the console output.

Default constructor

To avoid double initialization when you create an object, you must use the constructor initializers:

MyClass::MyClass():
  attribute1(0), attribute2(0) {
    ...
}

Without this, C++ initializes the object attributes before the constructor body, and in constructor you probably will initialize the attributes again.

Pointers

Just a reminder:

  • &x returns the address of the object x
  • *x returns the object in the address x

Pointers to functions

You can create pointers to functions as:

int (*fp) (int) = my_function

This creates a pointer fp of a function that receives and return int values. Notice that you don’t have to use &my_function, because C++ convert functions automatically. The same can be applied to the usage (you don’t have to call (*fp)(2), only fp(3)).

You can also return a pointer to function from another function, this is a bit tricky because you have to use typedef to declare the pointer before:

typedef int (*fp) (int);
fp my_function() { ... }

To return a pointer to a function that uses template is trickier, you will have to define a struct with the pointer and return the struct.

Arrays

C++ arrays are pointers to values and, thus, they can be used as iterators:

int array[] = {2, 3, 4, 5, 6};
int sum = std::accumulate(array, array+5, 0);

Notice that, the variable array stores only the first pointer, thus *a == 2.

The index usage array[3] is equivalent to say *(array+3).

Because array is only a bunch of pointers, you don’t have the type_size directly, but you can use size_t from <cstddef>.

File streams

Using input or output files is pretty easy:

ifstream infile("input.txt");
ofstream outfile("output.txt");

The usage is the same as cin and cout.

Specific streams

Instead of cout, you can use cerr for error output (it is preemptive, so it prints the string when it is called), and clog for logging (non-preemptive).

New and delete

To allocate and deallocate objects manually, use new and delete:

int *p = new int(42);
delete p

int *p = new int[3];
delete[] p

If you allocate an object manually, it will only be deallocate manually too. You must be very careful to avoid memory problems!

Explicit constructors

C++ allow explicit and implicit object initialization:

int p(4); // explicit
int p = 4; // implicit

The explicit keyword prevents the compiler to use the wrong constructor due to wrong type conversions:

class MyClass {
public:
    MyClass(int) {}
    explicit MyClass(double) {}
}

This

Another reminder: this is a pointer to the object.

Copy constructor

Passing an object by value to a function, returning an object by value from a function, or simply assigning one object to another variable, implicitly copies the object. The constructor used in the case is called copy constructor:

T::T(const T&)

Rule of the three

To control all creation and deletion process of a class, you must implement at least the following methods:

T::T() // and other constructors

T::~T() // destructor
T::T(const T&) // copy constructor
T::operator=(const T&) // assignment operator

Citing the book:

Because copy constructor, destructor, and assignment operator are so tightly coupled, the relationship among them has become known as the rule of three: If your class needs a destructor, it probably needs a copy constructor and an assignment operator too.

Read more