Torb

Members
  • Content Count

    2
  • Joined

  • Last visited

  1. Thanks! And thanks so much for helpful answer! Alright! I'll probably do that then! This reminds me of what I've tended to do when I program in Processing (so, basically: Java). I mostly just never worried about object creation and so on, with *one* exception: when making particle systems (where several objects are created and destroyed every frame) I instead simply opted to preallocate all the objects in an array, let them become “inactive” when they die and instead of new Particle() I find an inactive and make it active with new values. I don't know if this strictly speaking is an object pool or not, but that's how I solved that and it was fairly easy to do for that specific situation anyway, Again thanks so much for your answer. It's helpful to get the perspective of someone with experience.
  2. 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!