Search the Community

I am using "pixijs/pixi-tilemap" library to render maps exported from Tiled, but the rendering frame rate is low. I am newbie and I guess there may be a problem with the rendering loop logic, My thinking is as follows: I have several rendering layers(PIXI.display.Layer) in my game, I call them 'RenderingLayer', there are several cameras in the game (inherited from PIXI.Container), each camera can render multiple 'RenderingLayer' And output to RenderTexture, finally use the PIXI.Sprite group to render the final result according to the depth property of the camera. I use the ECS architecture to implement the game Code of RenderingSystem.update: for ( const camera of this.cameraComponents ) { if ( camera.renderingLayers.length === 0 ) { continue; } // clear stage $app.stage.removeChildren (); // add current rendering camera $app.stage.addChild ( camera.cam ); // collect camera rendering layer for ( const layerName of camera.renderingLayers ) { if ( $app.renderingLayers.has ( layerName ) ) { let layer = $app.renderingLayers.get ( layerName ); if ( layer.visible ) { camera.cam.addChild ( layer ); } } } // rendering camera result Graphics.render ( $app.stage, camera.renderTexture, this.renderTarget ); // clear camera.cam.removeChildren (); } // render final result this.renderSprite.removeChildren (); for ( const camera of this.cameraComponents ) { this.renderSprite.addChild ( camera.renderSprite ); } renderer.render ( this.renderSprite, null, true ); May be frequent use of removeChildren / addChild affects rendering performance?? I use the ECS architecture to implement the game, You can find the code for the RenderingSystem class here: js/ecs/systems/rendering_system.js. Another guess might be that I did not use the pixijs / pixi-tilemap library correctly.? see here: https://lihaochen910.github.io/RPGMakerProject/ code is here: https://github.com/lihaochen910/RPGMakerProject

How many of you have experience developing games with an entity-component-system pattern? How about writing games in general with functional programming? It would be especially interesting to me if you have experience combining both. TL;DR (this is back story, feel free to skip) I have this very simple and crude frogger style game that I've been toying with. I have a plan for turning it into something a lot better, starting as the relatively simple and recognizable game that we're so used to and likely not interested in (all of this functionality is already finished) but then quickly ramping it up in weirdness (which I have well outlined to avoid creeping my own scope). However, some might say that I've been "sidetracked" in the development process because of my desire to experiment with and learn new things.. I've literally rewritten the game from scratch 5 times in the past week. It's sort of okay because it's still small, but it's also one of the first things people tell you not to do when writing games. I, on the hand, am more interested in these rewrites and what I'm learning from them than progressing in the game right away. Part of it is my inclination towards learning and experimentation, and part of it is knowing that it can have practical dividends that might not be apparent because I'm preventing problems that I might have when the project grows in size and complexity. Object-orientation My game started in a very typical ES5 object-oriented style where I used the "new" keyword. My first major revision was porting everything to ES6+ (for built-in module system with import/export, never ending a line with a semi-colon, object spread operator, etc). When doing that I started using ES6s new class syntactic sugar, but something about it reminded me of the idea spread by FP evangelists that we as JS developers should never use the "new" keyword and that class based inheritance is a bad idea.. I then rewrote everything to use functions that return objects (factories) instead of classes. Some object types needed their own custom prototype object and used Object.create() (ones that are created a lot and have shared functions), while others didn't and simply were created by my own function that returned an object literal. This caused me some headaches because of the general lack of consistency in the way I was creating objects and how they were actually structured and accessed. The ones which weren't made with Object.create(customPrototype) required getter functions for methods to access attributes which were block scoped within the factory function by let, while the others didn't and their methods could access similar values through "this". Entity-component-system I then stumbled on the ECS pattern while Googling about why the MVC pattern is rarely employed in games (in the web community, MVC is the only pattern that some people know and they try to religiously apply it to everything). The most interesting aspect of ECS to me is that it was originally devised as a solution to the problems introduced by classical inheritance (which many JS developers also see as a problem), but their solution was radically different than prototypal inheritance (also solving the problems that might be introduced by prototypal inheritance, such as a failed property lookup recursing down the entire prototype chain). The gist of ECS is that an entity is what we might commonly think of as an object. They're really no more than a unique identifier (typically an integer). Despite being nothing more than a number, you can construct "classes", "templates", or "assemblages" for actually associating these numbers to data (components), and groups of related functionality (systems). An entities position, velocity, and acceleration within the game would each be a component. Rendering and physics systems would then operate on these values and more to draw them to the screen and calculate new state. ECS is an abstract idea, and thus wherever you look at implementations, you'll see things understood and coded very different. One common idea is that systems are associated to only one component, such as the rendering system to a "renderable" component with "renderable" being a key in an object. The key could itself be an object with all the values the rendering system needs (thus giving a degree of data privacy if necessary), but others simply have it as a standalone value and require other ways of making sure that the rendering system has access to what it needs and not to what it doesn't (or the latter idea escapes people entirely). Some people also let systems traverse the entire set of all entities each frame in a game loop to see if they have the component of interest. This in particular was disturbing to me, so I opted for the idea of simply adding/removing an entity to a register of entities that a system traverses. On top of cutting down on unnecessary operations, this also allowed me to discard the idea of components such as "renderable", "updateable", and "animatable". This bugged me because of the ambiguity about what their actual value should be and whether or not certain values (such as position) would need to be duplicated in the case that their values would be objects to which that system was restricted. All of these issues hint at another big implementation ambiguity: How do you actually store all of this information, and where? I still haven't quite ironed this out. I also haven't quite ironed out where some of the related functionality will come from (such as having it abstracted to a part of the game engine). Since this is JavaScript, the data structure decision is between objects and arrays. Each has inconsistent performance tradeoffs because of the functions that operate on them and how this varies between browsers. On top of data structures and operational functions, there's also the question of just how many you'll actually need.. One article recommended a wide variety: one for just entities, one for just components, one for entity-component mappings, N (number of components) to store the actual values of the components, and then further ones for all "assemblages" and assemblage/component mappings. This seemed a little unnecessary to me, but after further thought it depends on the particular game and the resources available to the game. That author was coming from the world of MMORPGs, so it makes sense. Here's the article. My game is single player and state, at the moment, is being stored entirely in memory. Regardless of how much further I progress the game, it will never reach the point where I'm dealing with even hundreds or thousands of entities. I'm therefore not too interested in having all of these data structures floating around. Keeping one for all entities and all components seems like a prudent thing to do even if they're unnecessary, and I'm currently thinking that it could be stored along with generalized entity and component functions within a part of my engine (in the same manner that I store cached resources in the engine itself). What I'll almost certainly need access to frequently is a mapping of entities to components along with their values with the "primary key" being either entities or components (depending on everything else). Conceptually, to me this is a 2D jagged array: indexed by entity, with each index pointing to a list of component-value pairs. Of course, this is JavaScript, so an array would have an integer index making it more suitable for a component->entity:value type of arrangement (since entities will likely come and go while component definitions remain static). At the moment, there's no need to query by entity to get all components, which would be slow if the entity weren't the primary key. This would slow down a systems ability to look up the value of a component if a quick way to access it isn't registered. I'm thinking that any given system should generally know what components it needs to access (exceptions to this are certainly possible). A general registration process should be capable of handling everything. For instance, a rendering system might require an entities "position" component, but how do we know it knows the right name and that the name is in fact the right name? This points towards the need for either verification in the process of creating an "assemblage" (good for larger projects, especially if they have a custom interface for non-technical people to compose assemblages, which was one of the original goals of the pattern), or through a process of registration with the system (good in my case). I could get away with doing neither by simply naming everything correctly, but since registration also gives me a form of data privacy for free, I think I'll do it. Functional Programming I'll write more here later, since I have to leave. I've been looking at various aspects of my code and asking myself, "how could I do this more functionally?" This generally means, "how can I store and access state such that I'm not mutating values?" Furthermore, it leads to, "how can I make sure that this doesn't drastically limit performance?" General thinking now is to minimize the impact of state changes (which can be costly because of how often the game loop runs). One idea of mine has been to fragment state into discrete units (3-tuple or even just a pair) so that the common functional method of generating new values rather than mutating old ones is less expensive. Not sure if this will work yet or how to do it if it's possible, but my first guess is this: seed systems that operate on state with initial values during registration, then if there's a change later have them forward an entirely new value to the next iteration of themselves. At first glance, I think this has issues. A 3-tuple might work, but pairs need to be associated. If the system is a single function, then even forwarding new pair values to the next iteration would mean mutating an array or object in which they get their association. I could always forward a new copy of the entire array or object, but that's what I'm trying to avoid. Maybe a creative reorganization of the system itself could work to make pairs possible.. My conception has always been of a system as a collection of functions that iterates through it's register of entities performing operations for each one. An alternative would be the registration process setting up an array of systems to operate. Egh. Gotta go.

I have read tons of articles and forums threads about ECS but still can't understand how anything in engine should communicate with Collision System. Let's say I have Input System that handle keyboard input and then at some point it want to move player character forward. Before doing this I should ask Collision System if there would be a collisions after that move and only if no - change position. My current approach is to have requestTranslation function in CollisionSystem that take translation function and object like this: moveForward(){ V3.CollisionSystem.requestTranslation(this.mesh, function(object){ object.translateZ(-this.movingSpeed); }.bind(this));}What do you think about this approach? How good/bad it is? What are know alternatives?

Hello everyone, I will develop a new game with phaser, and I ask myself questions about how organize my code. I would like to use the ECS architecture but how implement it with Phaser? how you decouple the differents actors (player, enemies, objects,etc...) in your game? How you implement the differents interactions between the player and the environment (a door for instance)? Thanks!

Hi everyone, A few weeks ago Ezelia started a thread about ECS and HTML5 games. As a big fan of this pattern, I decided to build and release my own engine. It is called makr.js and is available on Github (https://github.com/ooflorent/makrjs) under MIT license. A basic sample is available into examples/. The library must be build using grunt in order to test the sample. Any feedback would be appreciated! Update (2015-01-06): Version 2 is under active development (more information) Feedback is welcome!

After fidding around with makrjs as my choice for an ECS on a little project using Phaser I decided to tidy up my code some and release it as a plugin for Phaser. https://github.com/woutercommandeur/phaser-ecs The repository contains the 2 examples that makrjs provides but then ported to the plugin I wrote. The examples are the only source of documentation for now as I have not worked on that. But it's all a pretty thin wrapper around makrjs so it should speak for itself. Hope it is useful to someone, enjoy!

Hi everybody! Let me start off by saying that I'm pretty new to Phaser – I've been playing around with it for a bit but never made a game with it... so I'm not super-familiar with it yet. However, I have made games using CraftyJS and while that engine pales in almost all aspects when compared to Phaser, I really loved its entity component architecture. Not having to create complicated inheritance tress to share functionality among game objects that are otherwise quite diverse makes so much sense to me. Here's what I've done to add similar functionality to my Phaser project, without touching the Phaser source. I want to get your guys' opinions on it. Also, I'm not completely familiar with the terminology so I'm not sure if these things I'm adding to game objects are mixins, components, traits or something else. 1. Create GameObject constructor function GameObject will be the constructor function that every visible object in the game will use/extend. GameObject extends Phaser.Sprite and adds some methods for managing components on a game object, for example: GameObject.prototype.addComponentGameObject.prototype.removeComponentGameObject.prototype.hasComponentGameObject.prototype.requireComponent // ensures that the game object has a particular component, otherwise throws an errorCurrently, GameObject provides an update method that goes through all registered components on the instance and calls their update-methods if they are provided: GameObject.prototype.update = function() { for (var componentName in this.components) { var component = this.components[componentName]; if (typeof component.update === 'function') { component.update(); } }};2. Create a component Here's a simple movement component that requires another component called "speed" to exist on the game object (entity). var movement = autoCurry(function(entity) { this.requiresComponent('speed'); var speed = entity.speed; var cursors = entity.game.input.keyboard.createCursorKeys(); return { name: 'movement', update: function() { // prepare var velocity = entity.body.velocity; // movement velocity.setTo(0, 0); if (cursors.left.isDown) { velocity.x = -speed; } if (cursors.up.isDown) { velocity.y = -speed; } if (cursors.down.isDown) { velocity.y = speed; } if (cursors.right.isDown) { velocity.x = speed; } } };});I'm using autoCurry to make the syntax a bit more appealing. 3. Add component to a game object var Player = function(game, x, y) { GameObject.call(this, game, x, y, 'player'); this.addComponents(speed(150), movement()); game.physics.enable(this, Phaser.Physics.ARCADE);};util.inherits(Player, GameObject);What do you guys think of this approach? Obviously there are alternative ways to provide components. You might want to have components be constructor functions or plain objects instead of curried functions returning an object – I think that part is probably preference. I'm interested in the viability of using such a system with Phaser particularly. I'm looking forward to a constructive discussion, thanks for posting your thoughts! Best, Max

Hi everyone, I just released my js13kGames contribution. It's a retro top-down shooter called Floor Thirteen. Every feedback is welcomed, shares too! http://js13kgames.com/entries/floor-thirteen The game is rendered using an HTML canvas. Internally the game loop runs an Entity-Component-System engine. That was a real pain to build a robust ECS engine which does not exceed 1kb. The source code is available on Github. https://github.com/ooflorent/floor13