21–30 of 37 posts
I don't know much about cocos2d but since the dots are purely visual, do they need to be game objects? Couldn't you keep their transform in a separate data structure which you can update independently and pass to a shader (or similar) for rendering? I'm thinking something similar to how particles in VFX are usually done.
Earlier quoted context omitted.
Why should it be faster? It's doing the same work. In modern browsers with their heavily optimized and JITed JavaScript runtimes, an animation in JavaScript will often perform better than the equivalent CSS. (And that goes double if you're using WebGL and can just hand it off to the graphics hardware).
I'd like a citation for the claim that JavaScript animations are often faster than CSS animations. If it is true, it would be a very interesting read.
Thanks for the write-up. Always cool to see how different people solve these kind of problems. I don't know much about cocos2d but since the dots are purely visual, do they need to be game objects? Couldn't you keep their transform in a separate data structure which you can update independently and pass to a shader (or similar) for rendering? I'm thinking something similar to how particles in VFX are usually done.
I ended up not doing it in this iteration because:
- cocos2d's custom shader support is kind of poor, especially documentation is pretty much zero
- the dot is not "purely" visual. For example you can trace and highlight a resource's movement. This is not a blocker per se, but requires more work
Using Unity to compile to the browser seems to yield much better performance out of the box
Lots of cool stuff here. But on the last point about managing renders, for my money any browser game is in a state of original sin if its logic and render loops are tightly coupled. The Right Thing To Do is to run logic and rendering at separate cadences, with rendering driven exclusively by requestAnimationFrame. Then when the browser is minimized, RAF stops firing and rendering is skipped entirely (on top of the ot…
Hi, the game is already doing this. As mentioned in the article, logic tick is running at a much lower frequency than rendering loop (30/60FPS). When playing in the browser and is minimized, the game will simply pause - rendering and logic. Browsers will throttle timers which will cause inaccurate logic tick as well. Most idle gamers actually do not like this behavior [1] - people prefer the game to run in the backgr…
I think idle games are a special case here, in that variable timesteps aren't necessarily a liability for them. In an ideal world, one would like all the systems in an idle game to be able to quickly simulate arbitrary amounts of time (for offline progression etc), and if the whole game is made that way then in principle one is immune to throttling. But I think games actually built that way are pretty few and far between.
Lots of cool stuff here. But on the last point about managing renders, for my money any browser game is in a state of original sin if its logic and render loops are tightly coupled. The Right Thing To Do is to run logic and rendering at separate cadences, with rendering driven exclusively by requestAnimationFrame. Then when the browser is minimized, RAF stops firing and rendering is skipped entirely (on top of the ot…
I'd go further: for many games the right thing to do is pause execution entirely if the window is minimised or the user switches to another tab or application. Obviously not possible for online multiplayer games, but a good practice for single player. Rendering can be but isn't always the most expensive portion of a game's execution, but if you have a lot feeding into that in terms of object updates and game logic yo…
is the profiler a home-grown one? or publicly available?
Whilst I imagine the final line "I cannot get a discrete GPU at a reasonable price" is more a frustration, never underestimate the importance of working with restraints. If you develop against a terrible GPU you're forced to fix issues like this quickly. Although I'll of course agree a better computer helps the iterative dev cycle.
You forget what “real people” experiences are like when you’re on your $2000 beefy rig.
Whilst I imagine the final line "I cannot get a discrete GPU at a reasonable price" is more a frustration, never underestimate the importance of working with restraints. If you develop against a terrible GPU you're forced to fix issues like this quickly. Although I'll of course agree a better computer helps the iterative dev cycle.