Tuesday, October 29, 2013

DarlingJS / Intro to Entity-Component-System game engine / Draft

Ash

One British gentleman Richard Lord - game developer. I had first met him and had started to read his blog when I found his implementation of a particle system - it's called Flint and it has brilliant architecture. At first he used a lot of famous Patterns from the famous book of the band of four (Like Factory, Components, Strategy, State) and it was one of the best combinations of those patterns that I have ever seen.

One year latter he had developed Ash - Entity system game engine - at this time I had already developed my game engine that use composition over inheritance, It was very clumsy. But in hundred times better that any game engine with inheritance. As well I had left game industry and start developing creative tools so I not very interested in any game libraries. And have abandoned my own.

But half a year ago I decided to create a game on html5 and found that in javascript we have a lot frameworks, but most of them done in a very tied way. And they prefer to use inheritance over composition. I have been searching a lot and asked many people. But nobody gets me any answer - Why?

DarlingJS

So I have decided to port Ash to javascript. At the moment there was already one port of Ash - ash.js. But it had one big problem - it didn't use javascript native abilities as fluent-interfaces, objects with key-value data and polymorphism of functions.

And I decide to do my port of ash. I have started from scratch of API interface - I try to realize what API I'd prefer to use and what API can be more readability.

After reading a lot of API and sources of other game engines I decide to be closed to CraftyJS game engine. In my vision it has most fluent and easy reading API. It also looks like jquery. What is very familiar to every javascript programmer.

At this time I was under huge influence of AngularJS - so it was the reason my I have decided to add DI in game engine. For sure it can be optional - like plugin. But after that DarlingJS starts combine 3 parts: ash, crafty and angular.

Entity / Component / System

Idea

The DarlingJS approach combines 2 ideas: * use composition of properties for creating any game entity; * separate data and functions (try to done System stateless as much as possible);

Any game object in an application called - entity, all properties that has this game object grouped into components but over classical OOP game programming all logic of game object holds inside Systems.

Static

So for example if we create a block from Arkanoid game - we need add components: ng2D - component of 2d position, ng2DSize - component of 2d size (width, height), ngSprite - component that hold information about visualization, and ngLife - to store haw many life lift in the block. As you see the first part of the name of each component is prefix 'ng' - its mean eNGine - so they all comes from original repos of Darling..JS otherwise if you going to create your own components - you can use any prefix you like, for example: my2D, my2DSize, mySprite, myLife.

Main idea to break logic on smaller parts and create System for each part.

On the opposite side we have collection of Systems. Each System needs of some components of Entity. This needs described as property: $require: ['ng2D', 'ng2DSize], of each System.

As well we have Entities - that hold Components - and components in different groups (that describe in $require) - tied with System - This scheme describes a connection of logic and data.

Dynamic

But any game mutates its game state to reflect player interaction with the computer or historical development of the game.

For example in Arkanoid

The game state is - set of bricks, position and impulse of board and ball, dead zone on the bottom, scores, life. Historical Development - lay in a physics of the ball bouncing from walls and board, physics of breaking the bricks and checking collision of the ball with the deadzone. Player Interaction - reflection pressing of the left, right arrow keys to impulse to board.

Game is Conway's Game of Life

The game state is - set of states of live cells Historical Development - mutation of cells to live of die form Player Interaction - None

As you see Conway's Game of Life haven't any player interaction logic - and this is the reason why that game called - zero-player game. No any interaction with players.

What comes next

Now I start research of functional languages like Scala and planning then study Functional Reactive Programming - I'm learning them on Cursera on the lectures of Martin Odersky. And on the other hand start using python in my project - because it has a lot of List Comprehension functions - it's a different kind of generating list of elements in the closed form of the mathematical set-builder notation.

No comments :

Post a Comment