During our last blog post, we announced that we were ‘Feature Complete’. The purpose of this blog post will be to provide an update on the status of our regression testing. We will talk about our general testing approach, go into detail on a few specific bugs we fixed, and provide an estimate with how much is left to test. And as always, we will showcase some new forge maps that have been made since the last blog post (In Part 2 below).

Regression Testing

We are currently in a ‘Regression Testing’ cycle where we test every feature that we have added over the past two years.

Since the release of 0511, there have been around 1700 new commits to the Eldorito github. To put this is perspective: that is around twice the number of commits that occurred from the very initial commit of the project up until 0511. This single update is twice the size of all the other updates combined, from a git commit perspective at least.  

Over this time, a new UI architecture has been put in place (CEF), dozens of parts of the engine have been added/modified/removed, and countless features have been added, tweaked, or repaired. With each new element that we change or add, it opens the possibility of breaking something previously added or fixed. To properly test that everything works as expected, we’ve made exhaustive checklists for every piece of the game, each with a countless number of tests to perform/check.

As expected, this approach has resulted in a ton of bugs reported. Luckily (so far), most of them are small, and we’ve nearly been able to keep up with the testers and fix them as fast as they are being reported. Since our last blog post on March 4th, over 100 bugs have been fixed, although most of them are pretty small ones.

Obviously I’m not going list all of them here. You can view the github commits if you’d like to see the individual things we’ve fixed. I will, however, list some of the more important ones.

Significant Bug Fixes

Fix forge skybox clipping

Previously, you could only swap skyboxes. However, this resulted in a problem: clipping. For example, the guardian skybox is small, and the location of the trees would often clip into any map you used it on. You can now completely control the position, and rotation of the skybox. The position can be set as default or moved around with the map modifier object. This allows you to make cool maps like this

.

CEF Backend Replacement

CEF, which is what we use for our new UI screens, has had some fixes applied to increase performance and prevent crashes. The CEF request handling backend was ripped out and replaced as it had numerous issues with threading which were causing crashes.

Scoreboard Overhaul/Optimization

The CEF scoreboard was written quite a long time ago when CEF was first brought into ED, and it was an extremely CPU-intensive screen. It rebuilt the entire DOM every time it received an update from the game. In addition, the C++ function that builds the json for the screen layer to use was also extrememly expensive.

Both the javascript in the screen layer and the game function that builds this information have been completely reworked to only send and update the necessary information, instead of completely re-fetching and rebuilding it. This has resulted in a very big performance increase from the CEF process. During a full lobby, the CEF .exe CPU usage is less that half of what it used to be. Here she is in all her glory 

Expanded global render object geometry

If you’ve seen any of our previous gameplay videos, you’ve probably noticed that often times, there is flickering going on, particularly on the ammo counters of the AR or BR. It turns out that there’s 1024 slots in memory for object geometry and 8196 slots in memory for all other geometry. We noticed that the object geometry was filling up but the other arrays were not. By shrinking the memory of other unused geometry arrays and giving more to the object geometry, the issue seems to be resolved without any negative consequences.  

Player Size

During our last post, we received an overwhelmingly positive response regarding the ability to change player sizes as a trait. While what we had implemented at the time was cool, it was something we had kind of thrown in at the last minute, and it wasn’t done ‘properly’. For example, the collisions, physics model, animations, everything about it was relatively broken. We never intended it to generate so much hype, and we quickly realized that proper player sizing implementation had true potential. So, we fixed it. We fixed it all. 

Consider what used to happen when you were a really large player in a smaller room/area:

Obviously, this was pretty damn terrible. 

Physics Model Scaling

The player’s physics model is now fixed and automatically being scaled at runtime according to his size. For those of you who don’t understand the significance of this: collisions, shadows, damage, animations, speed, pretty much everything is being appropriately scaled based on player size. This introduces an entire realm of gameplay. Games can be actually played in spaces like this one with a near-identical experience they would have playing as a normally sized player.

You can also still customize player speed, gravity, etc. through the gametype options if you want a specific or more precise customization. A large number of additional player sizes have been added to the list in the gametype UI that you can choose from. There are over 20 sizes to choose from ranging from 10% to 3000%.

In Part 2 of this post, the map called ‘Catwalk’ is being played at 50% size. Without me telling you this, you probably wouldn’t be able to tell because the physics is scaled so well. Here is a video showing a wide variety of fixes related to player scaling:

A video showing collision damage from a massively scaled spartan:

Another giant spartan walking on some warthogs. Note: This one’s movement/animation is a bit outdated.

Now What?

We’re going to hammer out this regression testing and release this bitch. We have quite a few checklists to go through yet, so we cannot accurately give a release date, but the harder our testers work, the faster this gets released. We will only be fixing high-priority bugs and will defer some minor or cosmetic ones to a future patch in an effort to expedite the rest of 0.6′s bug fixing. 

We know you’ve all been waiting for 0.6 for a long time; some patiently, some not so patiently. It’s just as hard of a wait for us as it is for you. Trust me when I tell you that it will be worth it, and the end is very very close.

I don’t plan on writing another blog post before release. Hopefully the next time you hear from me will be in-game. You’ll find me in the official BTB playlist, sucking as usual. 

Sincerely, 

RabidSquabbit