Posted by on September 18th, 2014

Today’s blog is written by one of our wizard coder, Scripts, and his experiences on adding physics into TUG.

Hello, this is Anthony “Scripts” Hernandez and I’m excited to share some of my personal insight and work I’ve done on the game, TUG! Let’s first start out with a little bit about me; I’m new in the industry but very familiar with the scenery. Developing and researching new technology has always been a focus of mine and when I heard there was a company called “Nerd Kingdom” whose sole purpose was to combine the finesse of cutting edge Engineering, Sociology, Technology and Science I was a little bit in disbelief.


“There exists a Kingdom of Nerds that seeks the Holy Game?! I accept this Quest!”



Quest: Welcome to the Kingdom!

In my interview with some of the programming team I remember that it very quickly stopped being a ‘normal’ interview and instead an exchange of ideas in a very classical Programmer’s way where the ideas and the concepts expressed had brought more clarity to the table than the normal “Hello, I’m Bob… and I do things… Very well, in Java”

My first quest was to build my computer! THEN, work on Physics! Which reminds me, I’ll also never forget my first day because it was on Halloween and there was a lot of food and costumes so I was confused if they were welcoming or if it was like this all the time. Thank goodness I caught on to the date quicker than my potential statement of “Thank you, thank you, you really didn’t have to do any of this…”

Quest: The shot heard around the world

During my first couple of months working on physics I had to become quickly familiar with the physics engine; Bullet. Though the initial implementation was very simple there was a lot of tiny issues that started to become bigger after some iteration. There were three primary areas of concern:

  1. The character controller felt and acted poorly
  2. Moving bodies had to use convex shapes
  3. Performance / scalability

Getting the controller to feel right was one of those things that seems like it shouldn’t be too hard to do. But, when one fix breaks another aspect and fixing that breaks something else there comes a point of just accepting the way it is. Even though most of the programmers had dived into the system, we never got it to act the way we wanted it to.

Creating collision shapes to work with Bullet was a very simple process. However, it was very difficult to have accurate collisions on an object with motion. For instance, a tree feels like a tree then it starts to fall over and it takes on the shape of a boulder! There was no straight forward way to provide a means for both our artists and modding community to import their objects and have them reliability represented.

Finally, there was the issue of Performance and Scalability. Bullet had the advantage of just… Well, just working. From the moment we got Bullet integrated and online to the moment we realized it wasn’t flexible enough it always ‘reliably’ worked. Though, when we started to stress test and experiment with more GameObjects and multiplayer considerations we found that the volume of information that would be required for Bullet to process would simply become too much.

Quest: Choose Wisely

At this point we knew that we needed to either make our own Physics Engine that was tied more closely into the voxel system or look into a higher end Physics Engine.

I’ve written a Physics Engine before so an in-house solution was doable. This issue really boiled down to the availability of time.

After doing research and writing up pros and cons lists the physics engine, Havok, started to look very good. Its performance was phenomenal and the demos felt very good for both body movement and character control.

When the team was nearing a decision, Ino asked me a very simple question that needed a very clear answer:

“What does Havok do for us that Bullet can’t do for us?”

Well, in programmer’s terms there’s a lot. But, I didn’t want to go to my safe place and just start spouting buzzwords. So, when looking at our decision of “Havok or Bullet” this is how it can be summed up:

“Bullet is a very powerful mechanical arm that’s built by the community and can help make a wonderful car A, B or C. We need to build a Spaceship. Havok provides all the parts needed for us to assemble the most precise and tuned mechanical arm possible just for that purpose”

Ino: “Okay!”

A Physics What???


From Apples to Engines. A Physics Tale.

Quest: Fetch me some Cheese from the Moon!

With the green light given to start planning for Havok integration I spent a lot of time reading the documentation and references available for the Havok SDK. I quickly put together a roadmap of development that would first replicate our current functionality as well as developing for the future. We needed a system that could handle any new asset that a modder might want to add as well as being able to effectively scale with more players.

Here are some new pieces of tech that have been developed:

Blind Assets Pipeline

In a traditional game development environment there would be a set number of items in a given level or a default set of items available in the world. Which, might limit user shapes to simple convex hulls that cover their custom shape or just primitives; Boxes, Spheres, Cylinders and planes.

One of the things our physics implementation has to handle is any type of user generated content with a reasonable level of collision detail when it’s in motion and near mesh-shape collision when the shape is static (unmoveable). With one more caveat; It had to be simple to do and crash tolerant!

Right now when a model is being loaded into the game engine, physics breaks that renderable mesh into 3 categories:

  • Precision Shape
  • Performance Shape
  • Balanced Shape

For now the engine uses a built in rule set that has any shape in the game world to use its precision shape when static and balanced when moving around. The performance shape is a very inaccurate convex hull built around the mesh which makes it perfect for fast moving objects such as projectiles and debris.

An interesting point to note is that the Balanced Shape is a collection of what I like to call “Convex Nuggets” that approximate the render mesh for collisions while still being fairly high performance since it’s a collection of Performance Shapes. Another adventure for another time!

Micro Shifted Physics Worlds

One of the more technical and “behind the scenes” pieces of tech that we’ve implemented is the ability to have physics calculations only be carried out between -10,000 and 10,000 in the X, Y and Z axis. The reason we did this is because computers can store floating point numbers in two ways; doubles and floats. Think of both as being a seesaw… One seat represents whole numbers and the other, decimal places. If one seat goes to far up the other will be forced to go down. The closer a seat is to the ground the more inaccurate it becomes. doubles would use a plank twice as long as floats.

Inaccurate decimal values can cause very strange things to happen… For instance, when Havok first came online a lot of shapes would vibrate on their own or roll away in a huff if the player got to close.

By default the player spawns at <X: 50,000 Y: 10,000 Z: 50,000> when we spawned closer to the origin <2000, 1000, 2000> everything worked perfectly.

SO, the question is; “Do I still spawn really far away from the origin?” Yes! You still do! Internally, the Physics Engine, stores your position within the safe bounds of -10k and +10k. This means that physics calculations will almost always remind accurate and fast!

Terrain Simplification

One of the bigger optimizations that was made during this tech push was being able to simplify the collision shape of the generated terrain geometry. In the past we simply used the same generated terrain geometry for the collisions. With the intention of pushing our render distances and having larger areas of playable surfaces being active in multiplayer we needed to have a way to reduce the number of raw triangles used in the world.

The best optimization we can get is an entire cell being reduced to only two triangles. Whereas in the past that cell would have contained 1,200 – 2,000 triangles.

There is one large drawback to this system. It can either be very easy to calculate a new shape or it can take upwards to 18 seconds. Within that time the player might have already left the area or fallen through the unprepared area. Another issue is that an 18 second cell would be calculated then later destroyed and recalculated.

In theory, this system can provide a large overall boost in physics performance. However, the issues of preventing recalculation and long build times has kept this from being a standard feature shipped in the release build.

When new terrain comes out this feature will be made available and voluntary for our community to test out.

Active Landscape Instancing

When the implementation of Havok went into full swing there were some initial concerns that the number of GameObjects in the world was causing physics to run slow. To help combat this possible issue, especially since new terrain would allow for further draw distances. A solution needed to be implemented to handle this large volume.

The Active Landscape Instancing tech, or ALI, is the answer to that problem. As the world is populated with GameObjects anything that was placed by the terrain generator will flag objects to participate in ALI. This means that, say, 300 trees of the same type would reference a single real tree collision shape and all of the instances would use a simple box. When anything gets close enough they would use the reference shape as a stencil to check for collisions in their current location.

Though, that’s a very technical breakdown it’s very easy to conceptualize as one master object and many, weaker, copies with the same look and feel.

So far in the currently released terrain ALI has only provided a small boost in performance. Therefore this feature, too, has not yet been enabled by default. This is something that will become standard with new terrain to help accommodate larger draw distances.

Quest: Fishing For Possibilities…

I believe that collaboration and thinking outside of the box is an important step in innovation. One of the hottest topics that is not limited to just TUG but almost all of the up and coming procedurally generated games is the problem of Water. Naturally, voxels allow for 5 directions of water flow: North, South, East, West and straight Down. Having smooth surfaces increases this problem close to real world particle physics. Now, I’m not saying that we aren’t smart enough to implement that… I’m saying that we are smart enough NOT to do that. We want the game to be fun and engaging and having real-time particle flow being calculated would be insane!

So, we don’t want to just give you a static body of water that never moves or just no water at all! We want to bring a creative solution to the table that can meet half way between voxel simplicity and particle physics.

After drawing up some ideas and working with Havok’s support team we’ve come up with a set of designs that we want to start implementing after the new terrain engine has been implemented;

  • Sphere Assisted Flow Models
  • Water Table Bound Material Containers
  • High Flow Feelers, Low Flow Feelers
  • Liquidoid Shapes
  • Ball Pin Surface Influence

I don’t want to go into too much further detail because for one, they sound silly, and two these are just shots in the dark in an attempt to find a solution for a difficult problem. But, they all share the same theme of KISS… Keep It Sophisticated-ly Simple.

Well, it looks like that’s all we can do for now! I hope you found this post to be both enjoyable and insightful. I look forward to our future adventures and quest hunting together!

Don’t forget to follow me on Twitter @Scriptslol and don’t be a stranger, feel free to pick my brain or to find out the latest! I’ll be in the back KISSing… I mean, Uhh… Innovating… ?

Love you guys!