Monday, January 21, 2019

Thinking in ECS

If you have been following the new developments in the Unity Game engine, you would have found that they have been focusing on performance and modular code. One of the outcomes of this is a new way of writing code called "Entity Component System" where "Systems" operate on "Entities" which have various "Components" within them.  The ECS name is specific to Unity naming convention this "paradigm" also goes by the name of "Data oriented Programming".

This could easily be mapped to how "C" programming works, or in general any functional programming works i guess..

"Systems" == "Functions"
"Entities" == "Structures"
"Components" == "Data Types / Unions"

If we had to write a game engine in C i believe any reasonable programmer would write it this way, there would be an array of structures which contain the "position, rotation, scale" information of each object and there would be a update function that would loop through them and update the values as required.

I understand that that its' a stretch to call ECS the new functional programming because the systems are still classes, but it seems really easy to grasp the ECS concept when you look at it from the "C" programmer perspective. This is the trick i used to wrap my head around the whole ECS system.

Yet another way to look at it:
If you are a shader programmer or have spent any time trying to look at how GLSL/Compute shaders work, ECS can be mapped to a piece in glsl world as follows

"Systems" == "shader (FS/VS)"
"Entities" == "Input / Output Structures"
"Compoenents" == "Data types"

One of the main reasons these ECS systems make sense is that they can be pushed to GPU for running in parallel on thousands of these objects at once. 

Tuesday, November 27, 2018

Bone Rush (PyWeek26)

I've been a regular participant in the pyweek contest. The last time i participated, i tried to use cocos-creator to work as editor for cocos2d (python) and was fairly successful in creating a clone of Reigns (a mobile game about making choices).

This time i wanted to replicate the rush fight game, where the faster you tap the faster the game moves. It's pretty fun mechanic and would fit well with the theme "flow". So i got to work with the same workflow i had before, create characters in inkscape and create sprites to be used in game. For a while i pondered about supporting skeletal animation using cocos-creator setup but was not sure if i was going to find time to do it, so i choose to go with sprite animations instead.

Creating the sprites was a big deal as i was not sure if i wanted to setup the character in blender / cocos-creator / Inkscape for capturing the animation images. Inkscape quickly fell apart as an option as there was no way i could keep track of all the animations and modify and create multiple files to be modified later. I had to choose between blender / cocos-creator.. i thankfully ran into another tool called dragon bones. This was pretty good as i could iterate over the animations and generate the sprite frames from the tool itself.

I later used the cocos-creator to setup the scene and played around with fonts and stuff but was able to quickly able to tweak the scene as much as i wanted. I wanted to add additional particle effects etc but was strapped for time and couldn't get it done in time.
The game is called Bone Rush and the above is a video of the game in action.

You can visit the official website for the game : bonerush