Introduction
Open source mashup of classic arcade games with Hive blockchain support. Read the bottom about section for more information.
A last pass at optimizing
The past two weeks have been mainly optimization, fixing and cleaning up. It is getting close to start on the last bits of the project and it felt like a good time to go over and fix things up first.
Back long ago when the project was an early prototype it looked like below and it ran at 50+ FPS on the low end test machine, a Raspberry Pi.
After working on the project for a while, the performance slowly, but steady, took a turn for the worse. When the project reached it appearance and feature set as shown below, the FPS had dropped to around 15. This is when the first optimization pass was made, as talked about in this earlier post from 4-5 months ago.
During that optimization pass the performance was improved up to about 40 FPS. That felt good enough for leaving it back then as the game ran a smooth 60 FPS on the iPad, Android phone and a better computer.
Two weeks ago, the performance had once again slowly dropped as the work had continued, and both the iPad and Android phone would start to see drops below 60 after playing for a while and the amount of objects increasing. I made a new pass at going over the project and finding things to optimize. This time it has been more or less 100% code changes and the performance is back up to a solid 60 FPS. In fact, the Raspberry Pi now runs the game at 60 FPS as well! Let's take a look at some of the improvements.
The Grid
The first thing was to change the grid. The grid is a bunch of colliders that are used to locate where objects are, keeping track of the objects as they move and then use that information to know which objects are in the same cell, or neighboring cells, in order to check for collisions between objects. The cells also know if they are on/off the screen and objects use that data to know if they are visible or not. If not visible, they can skip updating or update at a lower rate.
The grid consisted of rectangular colliders and all other objects use circles as colliders. As checking for collision between circles is faster, the grid was changed to use circles as well. In order to fit the circles together better, every other row is offset, creating the pattern of green circles as shown below.
When doing this, a side bonus was noted. When offsetting rows like this, instead of having a cell + its neighboring cells being a total of 9 cells, you save 2 cells and only need 7 cells. This lowered the amount of collision checks quite a bit, in particular as when this first was changed, all moving objects were using groups of cells (main cell + surrounding neighbors). Only static objects were in a single cell.
I then realized that having all dynamic objects do this was not needed. Only the player needs to do it, if the player is in 7 cells, then the player and any potential colliding objects will always know about it well in advance before a collision is possible, even if the other objects are moving as well.
Another not the most clever of choices, was that the objects kept track of the neighboring cells. Each time an object got into a new cell, it figured out what the neighboring cells were in order to use them. The obvious improvement was to make the cells know which neighbors they have upon the creation of the grid and then let the objects have that data when they need it.
All objects registered event listeners on/off for the cells. In particular dynamic objects created a lot of listeners on/off as they moved and registered to those batches of 7 cells. That meant that if the player collected a static star and a new enemy spawned, it increased the listeners count greatly as the star only had one listener and the enemy had seven. This idea of using listeners was from an old version of the project, earlier than the first screenshot and when the game was something completely different. This cell-event-idea was removed in favor of registering on/off to the main world update event when objects are enabled/disabled.
The Others
About to end this project update, but will briefly list other optimizations:
- Pooled more objects and shared more objects within a class. For example the shooting stars used to be one shooting star per enemy, now the enemies have a limited pool of shooting stars to use.
- Shared timed events. Previously at some events all enemies created timed sequences, now the main enemy creates the timed sequence and do the events on the rest of the enemies instead. This removed a lot of the overhead from creating requestAnimationFrames.
- Keep a history of time deltas between updates and use an average of that delta when doing increments. This smoothed out the stutter that previously occurred when the game ran below 60 FPS.
Found that you can turn off FPS limit and VSync in Chrome by using -disable-frame-rate-limit and --disable-gpu-vsync as launch parameters for Chrome. This made it much easier to test the delta at high frame rate. While not an optimization it helped fix some timing issues and hopefully making the game stable for those with higher than 60hz monitors.
Re-worked events from activating power-ups and when power-ups end. The old behavior was some what hard to predict as each power-up could have different types of enemy "start-up" behavior. Now they are always the same: Active enemies in normal state, will go to the activated power-up state. All enemies that are spawned, but no yet left their "awakening" state, and all enemies spawned after the power-up activation, will follow through with their regular awakening procedure and then go into power-up state when ready, if power-up has not yet ended. Should fix some of those accidental player deaths.
Thanks for reading!
About
Hive P v. S is a mashup of classic arcade games. You fly around collecting stars, each star collected spawn an entity that forms a tail that gets longer and longer. Avoid the tail for as long as possible until you get a power up that gives you a limited time to destroy the tail. If successful you'll get bonus points and new stars are spawned. Rinse and repeat.
When the final score is high enough, you'll get the opportunity to submit the score to the high score table. The high score table is saved on Hive and is viewable on Hive as well as in-game for all users.
Game will be released for browsers, as a PWA and as native builds for mobile and computer platforms.
Check out the following links to get a closer look at the progress!
Project links: GitHub, website and playable build.
Game development using web technologies.
Try the latest build of Hive P v. S
Try the latest development build of Purple & Eye
Great insight and I love the game, really! The new addiction and finally getting the hang of the power up system make it very very fun to play!
Oh, glad to hear!