Author's Posts

Last updates on Skald Engine:

Color utility functions

PixiJS handle colors by its int value (e.g., 0xFFFFFF), so I created a bunch of function to convert or manipulate colors in this format. Right now you can:

  • Convert color from/to RGB format (array, [255, 255, 255]).
  • Convert color from/to HEX format (string, ‘#FFFFFF’).
  • Convert color from/to HSL format (array, [255, 1, 1]).
  • Get the individual color channels (red, blue, green, hue, saturation, lightness).
  • Saturate a color by a given amount.
  • Desaturate a color by a given amount.
  • Covert the color to greyscale.
  • Lighten a color by a given amount.
  • Darken a color by a given amount.
  • Spin the color by the hue space by a given angle.
  • Blend two colors.
  • Tint (blending a color to white).
  • Shade (blending a color to black).

 

Utility for random generators

I also added a bunch of function to generate random numbers and other  stuff related:

  • `random.choose()` to choose a value from an array.
  • `random.inclusiveRandom()` which is similar to Math.random(), but it can include the 1 (i.e., it generates a number in interval [0, 1]).
  • `int()` to generate a random integer.
  • `polar()` to generate a number between -x and x.

Easing function and modifiers

I add more easing functions, a general bell curve and a gaussian shaped (using the normal distribution formula without the normalization term). So they can be used to generate interesting effects.

I also added two function that modifies the easing functions, one for mirroring the result of the easing (it repeat the ease function 2 times, but it invert the result of the second half), and one for repeating (pretty straightforward). I am still testing this format, so I don’t know if I’m gonna keep it.

Particle systems!

Added an initial implementation of particle system. there are some improvements to be made, but it is working pretty good.

Game config changes

I decided to remove the manifest as parameter of the game and added it as an item of the configuration. This should keep consistence among the API.

Additionally, I added a startScene and a preloadScene option, so the game can initialize and run a preload scene during the manifest loading, and start automatically the main scene when the game starts.

To help you in this initialization process, I also added a `start` event, triggered after the preload (if there is any item on the manifest), and added a default preload scene.

Scene stacking

I thought I could live without it, but I was wrong, so we have scene stacking now. Now you can add or remove scenes over the base scene (the one called with `play` method). The scenes are attached to the base scene, so if you remove the base, all scenes in the stack will die too.

 

Next steps

For the next alpha release, I want to add an event pool for event recycling (so we don’t have to create a new event instance everytime an event is triggered), and simplify the scene API. Right now the scene API is very limited and unintuitive.

Read more

About two year ago I started a game engine called Creatine, which was built upon CreateJS. I used this engine for quite some time, creating 4 jam games with it. However, I reached a point where I couldn’t improve Creatine anymore due to the limitations of CreateJS, in particular because CreateJS cannot use WebGL.

After some time without seeing anything about game development (I started in a new job, and hence my absence from this blog), I decided to start a new engine in order to enter make games for game jams again. This time, I decided to go with PixiJS, which is the status quo of 2D WebGL rendering in the JavaScript world.

But why I don’t simply use Phaser? Well, Phaser is undoubtedly a great project, with a mature code base and huge community, but I personally don’t like it. Its internal structure is confuse and I can’t understand properly (without spending a lot of time) how it works. Notice that, this is my opinion. I don’t like Phaser, but I am not saying you shouldn’t use it.

So I started Skald, my new engine, with some important pillars in mind:

  • The engine must allow me to create fast prototypes for my jam games, however, it must have a good architecture so I can create larger games with it if I want to.
  • Kind of consequence of the point above, the engine must allow me to reuse individual components, something similar to how Construct 2 works.
  • The engine architecture must be simple and intuitive, so anyone could understand what is happening under the hood.

Additionally, I would like that the engine be flexible enough so people can use it ignoring any part of it (e.g., you may rewrite how scenes and ECS works with relatively simplicity).

Right now Skald is on Alpha 2 – which means that I don’t recommend anyone to use it yet! – and the core features at this point are:

  • Game class with managers to control audio, inputs, scenes, devices, etc.
  • An extensible asset loader.
  • ECS objects. Not perfect or very strictly classic implementation, but it is working well.
  • Multiple and extensible audio systems. Right now with support to webaudio and html5 audio.
  • Support to 3rd-party plugins.
  • Scene transitions (similar to creatine).
  • Tweens, color and easing functions, and other utility functions and structures.
  • Most of the features of PIXI.

The final version of Skald won’t be released any time soon, but for the next alpha release I would like to add the following features:

  • Particles! Super important to have a particle system.
  • Scene stacking, so we can add, for example, a pause screen over the game without removing the game scene off the screen.
  • A better initialization procedure with a default loading scene (if there is anything to load).
  • Anonymous scenes and entities.

The project is hosted on github:

 

Read more

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