Search the Community

I'm just curious what are regarded as best practices to avoid the dreaded GC pauses that can mess with the framerate of your game. I've only made some really simple games so I don't really have that much experience with this. Generally the way I've made objects when outside gamedev type situations is pretty close the Crockford-style way of making objects by have a factory function that returns an object literal with functions that closures that refers to variables inside functioning as private variables. (Technically I use TypeScript, but I don't really need to get into the types for this discussion.) const createObject = (someArg) => { let variable = someArg; return { changeVariable: (change) => { variable += change; }, getVariable: () => variable, }; }; const o = createObject(42); o.getVariable(); // 42 o.changeVariable(3); o.getVariable(); // 45 From a purely programming ergonomics perspective this is the way of writing objects I find the most comfortable (not trying to convince anyone else here, this is just my preference). However, I've read many places that aspects of this can be bad for performance (even Crockford admits this about his own pattern). in typical JavaScript programming this seems fine to me, but for games I worry that I'm limiting myself in performance which can lead to slowness or limits to for exampe how many objects I can have running in my game. This has made me think that I maybe ought to be using ES6 classes (or something else that uses prototypes) instead of my closure based approach. Also, maybe I should use object pools? Or hell, maybe even entity-component-systems? Suddenly this stuff seems really complicated (I'm _almost_ wishing I could just use malloc and free, haha). How do you people deal with this? How do you balance ease of testing out ideas while having an reasonable path towards optimization if needed be? I'm generally thinking of using Pixi.js for graphics (hence why I posted in this forum), and Matter.js for the times I want a dedicated physics engine. Sorry for the long post! I'll be very grateful for any thoughts on this!

Greetings. Trying to implement object pooling in my isometric game. Here is my code. Any idea why no "swords" are showing up? // methods // the_sword_item : function () { //the_sword = items_group.createMultiple(10,'sword'); // for some reason this stops the rest of the game from rendering only showing the background colour so I used a for loop... // var swords_number = 10; for (var i = 0; i < swords_number; i++) { the_sword = items_group.create(20,20,'sword'); } the_sword.scale.x = 0.05; the_sword.scale.y = 0.05; game.physics.isoArcade.enable(the_sword); the_sword.body.collideWorldBounds = true; the_sword.body.immovable = true; the_sword.checkWorldBounds = true; the_sword.outOfBoundsKill = true; the_sword.kill(); }, spawn_item: function(x, y, type) { var the_sword; if (type == 1) { the_sword = items_group.getFirstDead(); if (the_sword) { the_sword.reset(x, y); return the_sword; } } return the_sword; }, // var the_sword, items_group; // Inside my create function // items_group = game.add.group(); this.the_sword_item(); // Inside my update function // this.spawn_item(30,30,1); // will give later random X any Y inside viewport but still should work for now...

I am in the process of bolting PixiJS onto an existing JS game engine. Currently the engine uses object pooling comprehensively for all components and game entities, and I was planning on having the engine's Sprite component contain a PIXI.js sprite that is used during rendering. My main question is this: What is the proper way to go about "re-initializing" A PixiJS sprite if I were to pool them? Are theres some general pooling strategies that I should use (e.g, only re-use Sprite objects if the Texture is going to be the same, make sure to reset some underlying cached state... etc). I know I'll have to (re)set the position, rotation, etc properties, but was wondering if there are some larger caveats I need to be aware of. I am only using the WebGL renderer and not making any use of interactivity, if it matters.