Posted by on January 30th, 2015

Hello everyone! We’re back from PAX South and back to more frequent updates!

It was a blast getting to meet people at PAX South and the game played really well for everyone who stopped by the booth. We noticed a few nagging issues during the event that we wanted to get a patch out for and that’s what you’ll find in this update.

Now that we have the first phase of multiplayer out, we’ll be shifting back into more content creation. We can’t wait to get you even more things to do in TUG!

Check out the list below for all the fixes and additions you can expect in this update. If you run into any issues not mentioned below, feel free to let us know on our forums or contact us [email protected]

If you feel the urge, send any best wishes, cyber hugs or well meanings to me on the twitters @X_Nekochu_X

Have fun and keep surviving out there on TUG!



  • Torches now have a limited number of uses to light a Fire Pit or Furnace
  • Gourd torch has been adjusted to work as a light source but not a fire based torch
  • Adjustments made to the stalker spawn and the player’s starting position
  • Crude tool repair recipe has been adjusted to work similar to the bronze tool repairs
  • Bamboo Shaft can now be used in any recipe that formerly only used the Wood Shaft
  • Small rocks no longer affect terrain
  • Removed spacing check on growing items; still have a radius check to plant the initial seed


  • The Esc key will now close the Inventory menu
  • Terrain should finish generation until before the loading bar fills
  • The sword applies a run speed buff again
  • Creative Mode UI was not disabling when the UI Toggle was used
  • Lua errors when a Client is in motion when a Server shuts down
  • Thrown and stuck spears not saving
  • Objects not being cleaned up properly when stacks were merged in the backpack
  • Damage States for weapons/tools not showing up
  • Gourd Torches making fire sounds
  • Layers of voxels were generating too many times below ground
  • Dropping a stack of seeds would consume a full stack of seeds for one plant
  • Damage taken when starving was interrupting the eat animation
  • Crude/Bronze Hoe were held too close to the head in first person view
  • Fixed known bug where cells were not being saved in certain situations
  • Addressed some saving corruption issues
  • Proper sounds now play when you eat something
  • Crude/Bronze Hoe now takes durability damage when farming
  • Cached physics collision meshes are cleaned up with each new engine release to a player, which fixes certain items having offset physics and graphics meshes
  • Tools and weapons now take damage from attacking other players
  • Removed the “reload assets” key (default F5). Lua scripts can now be reloaded by leaving the game and reloading it. This also addresses some occasional graphics glitches that could sometimes be experienced
  • Various minor fixes to the engine and gameplay have been addressed

Known Issues

  • If you are unable to change your brush/block size, tap the Caps Lock key once.
  • Any recipe crafted using the Bamboo Shaft in place of the wood shaft does not reflect the bamboo wood in the final result
  • Cabbage trap never opens after growing to full size and does not trap anything
  • Clients lose stamina while walking with a Sword in hand
  • When full screen the gems on the volume slider bars cannot be grabbed with the mouse cursor
  • Large items can get stuck in the player’s head when placed near a wall or in a low ceiling area
Posted by on December 23rd, 2014

I kept trying to think of super awesome fun ways to start this post, but i’m a loss for words… so… “boop”. We have officially finalized our deal with our investor/friend/partner/dudes, and we are on our way to making some awesome! It’s been a really tough past few months, but we have been hanging in there and getting stuff done… understandably, its hard to see any of the stuff getting done, since its only going out to indev in ultra early access (OMG IT’S SO BROKEN!), but we are going to be whipping up some sweet sweet video sneak peek action for you guys super soon… because Cambo’s back and that dude is being put to work.

Other cool news, I am now the CEO of Nerd Kingdom, so that is kinda a big deal too. This doesn’t really change anything for us, it just means I get this sweet new title in the company and all kinds of crazy anxiety inducing legal responsibilities. Also, we get to start to bring on MORE people to join this kingdom of nerds, which also is pretty great (hi Josh).


Multiplayer will be coming to indev just after the holidays, and we are REALLY going to need you help tearing it to shreds getting it ready for official release, so breaking things is encouraged. A chunk of us are actually going to be doing some work through the holidays on game breaking bugs, so we can have it ready for everyone just into the new year. As usual, post your bugs to the review section… *cough*…. wait… I mean, the bugs forums or [email protected]. But if you wanna earn some super rad brownie points?  Re-create the bugs several times and send the process to us so we know how to target it. Wanna earn ACTUAL BROWNIES! (disclaimer, no actual brownies) record footage of the bug in action and send it to us for review.


In other news, we somehow managed to score a booth at PAX South, so a few of us will be there showcasing some multiplayer action in TUG (do what you will with that in comments below… we need more T shirt ideas). The next 6 months as a whole are going to have some pretty rad things coming online and we are anxious for you to help us break that stuff too.

Man, reading back on this post a few times, its kinda wacky… welp, I’m tired and excited and I’m gonna let it slide (DON’T YOU DARE SILENCE ME, LEFTY!)

As usual for high fives get me on the twitters @inoritewtf

General nerd ragery @brennanpriest42

Updates on the stuffs @theuntitledgame

Also, all our CTO wants for xmas is more followers… and maybe to grow a beard as grand as my own… @CoreyClarkPHD



– ino (El Jeffe)

CEO – Nerd Kingdom
(MAN my linkedin is gonna look sweet now!)


Posted by on September 25th, 2014

So we have good news and we have bad news… I suppose its best to format good, then bad then good, in this situation. I fully recommend reading this post at length, so there is no miscommunication on the topic and we see, clearly, everything that is going on.

Good news: We have had consistent stable growth in sales and play time over the past 4 months. With more and more people now noticing the game, and our attention to feedback and play behaviors, things are starting to REALLY look amazing. New terrain is coming online, we had a leak from Azzy (here), lots to do in order to improve it. But, finally, we are free from those blasted sharp angle blocks. Networking is also on its way shortly, and this will be the first time we actually have networking running with a “traditional survival”.

The modding API is looking fantastic, with more and more members from the Minecraft modding community coming over to support us, and more YouTubers now taking notice and sharing the project as well. To those of you that have been helping us push TUG, thank you so much; you know who you are. To those who will not cover TUG because we can’t pay you for coverage… well… something else.

We have been able to REALLY build a lot with the funds we raised from investors, and we have been able to make some RAD content in that process with all the support from our backers and new members of the community. It’s neat to be able to build stuff and share it with you guys and have a platform to talk and interact with one another.

The not so good news: A round of funding, that was to come in, to sustain us clear through the end of this year (January) was held back by an investor. The deal that would have gone through would have lost us all control and ownership and we are not huge fans of being owned by investors like this. Sadly, we need to cut off a few limbs to be able to ensure this does not happen.

With this, we are now on a path to growth to fully support a small team with no outside investor support. And this means we have to cut our team in half… its the hardest thing we have ever had to do, but it’s what we all collectively have agreed is the best move for us, and you, our community. We certainly have had people come and go from this project for many reasons, but this core group is all family… and its heartbreaking.

With these changes, it also means that we will be a few months late on delivering all our promises by January, as we stated we would with the kickstarter goals. I apologize for that on behalf of the team and I am holding myself accountable for NOT having done more diligence on our financial partners to know this was coming. Its a funny situation, whether you do well, or REALLY well, can make the difference of supportive or tyrannical investors. Another important note, to others out there who do raise funds for games and tech… never take money from people who don’t understand games and tech.

The other good news: There are a few large publishers (not scary ones), that may want to give us access to more resources. This would allow us to make the game and tech bigger and better than we could have imagined before. We cannot discuss who they are just yet, but ironically in this situation, it really would mean a chance at ACTUAL freedom and independence. And before we do accept whatever offer from any of them, we will reach out to you, our community, to share what is going on and get some feedback to create dialog around this topic. It could end up that what is put on the table simply is not in our, or your best interests. But we want to make this project everything it can be, so its worth reviewing everything we can.

Still, it is also quite possible that this push with multiplayer, in survival, and new terrain may be able to give us a large enough jump in growth, from revenue, that we can bring our team back fast, and possibly even staff up a bit more. Unlike other games that sell SUPER fast and drop down, our steady growth really has given us amazing opportunities to really understand what we do, and what others do, that impact how the game plays and is perceived.

In closing, please DO note, that this is not us going down… quite the opposite. Its us making the sacrifice needed, now, so that we DON’T go the path of other kickstarters before us. We are doing what it takes to press on, self sustain and do what we have been telling you all since we first started on this together, well over a year ago. This is what we have to do in order to stay independent and free to do what we want to do.

We will be implementing a price hike to $20 on the game when we have Multiplayer and new terrain online in survival, which will be SOMETIME by the end of next month. And with this continued growth and exposure, we will continue to build the game, engine and tools for the modding community. The game will run and look better and better with more time and we are excited to keep working on it.

If you have any questions or comments on the topic, or are generally concerned, you can ask me on twitter @inoritewtf, or on the following reddit post (here) or email me, personally [email protected] and I will do my best to reply to everyone with valid inquiries or thoughts.

Posted by on September 25th, 2014

Zach, wizard coder, took some time off to write about the Integrated CEGUI for today’s Dev Blog. We want TUG to be completely moddable and that includes giving modders the ability to create their own UI. 

You may have noticed a phrase in the latest patch notes “Integrated CEGUI”. For those that do not know, CEGUI is an open source framework for user interface that we have decided to use so we can present modders with an easy way to make changes to TUG’s UI. In an upcoming patch we will be pushing out the beginnings of moddable UI. One of the reasons we picked CEGUI is because of it’s exposure to Lua, each CEGUI element can be created, modified and destroyed directly through CEGUI’s own Lua interface, which you can access in any TUG script. In addition to CEGUI’s Lua interface, I have also written some short Lua wrapper classes to help with some of the more abstract or mundane tasks. If you’re a programmer, that means you can create your own custom UI elements and tie them to just about anything you have script access to. For those that are more interested in the art side of things, we haven’t forgotten about you. CEGUI comes with it’s own layout editor and we were careful to maintain its functionality during the integration process.


In the above image you can see TUG’s Survival UI layout in CEGUI’s editor. With this tool you can rearrange the UI elements to be anywhere on the canvas, and those changes will be reflected the next time you run TUG. But what if you want to make your own art? CEGUI has that covered too.


CEGUI’s editor also lets you modify imagesets, their name for a texture atlas. Using this tool you can load a .png that you created using your software and section it for easy access to your own UI images.

In both cases, layouts and imagesets, you are free to alter the assets that come with TUG or, if you’re feeling adveturous, create your own. At this time, the UI framework is only partially complete, so while we continue making modifications, there may be some UI elements that are locked from modification, including the Bag, Beltbar, and Equipped item slot. These elements will become available as soon as I can finish writing and testing the new inventory system.


This is just the first step in the UI overhaul, hopefully with much more to follow, including tutorials on best practices and how to get the most out of CEGUI via Lua script.

If you have any questions, feel free to contact me on twitter @Zachisalsoking

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!

Posted by on September 16th, 2014

Good news, everybody!

Another day another update. Finally coming out of the stone age… maybe we will be less a caveman simulation now *cough*. It’s our first step to advancing an age in TUG with crafting and a few additional bits, along with an adorable, and also very annoying little surprise.


As usual, don’t forget to share any bugs you run into, on the forums (here) follow us (here) and follow our progress on our trello (here)

*high five*

Patch Notes


  • Bronze weapons and tools

  • Surprise!

  • Metallurgy set with a Furnace, Bellows, Sandcast Mold, and Stone Anvil

  • New Ores that can be combined to make bronze

  • Updated textures to the predator


  • Ores set up to generate from certain rock materials

  • Material drops from terrain and trees adjusted to match new block digging sizes

  • Updates to the predator behavior, it now fears campfires and hunts other critters

  • New recipes added for all bronze tools and new tables (Bellows, Sandcast Mold & Stone Anvil)

  • Existing tables also received new recipes in line with the new age of tools

  • Repair and deconstructing recipes added for bronze tools

  • Rock heads for crude tools have a chance of dropping from terrain materials


  • You can now dig/place voxel blocks in two different size. You can now place/dig a 2x2x2 cube.  The 1 voxel cube size can still be used. Holding down the Shift key + scrolling with the mouse scroll wheel will shift between the sizes.

Eternus API

  • Modders now have the ability to register and create their own slash commands.  RegisterSlashCommand(“command”, “functionToCall”).  Arguments are passed over as a table.  See Survival:TargetInfoCommand function for an example!

  • New function on game objects NKIsInWorld(), a simple query to find out if a given object is in the world or not.  

Known Issues

  • Proving Grounds has been temporarily disabled.

  • Multiplayer has been temporarily disabled while we revamp that whole system.

  • Fruits have durability bars

  • When a fruit is held in your hand, the voxel ube outline for a tool appears.

  • Thrown (not dropped) spears stuck in the world aren’t saving properly

  • Critters don’t save their positions between game sessions

  • Critters love to get stuck on the terrain and other objects.

  • The location to harvest Critter bodies tend to be slightly lower near their feet. When looking at the correct spot, the menu pop up will appear.

  • Can place items (right click or Q) through voxels if you are too close to the voxel.

  • When (right-click) placing a Vine Fence, it places inside of the player.

  • The game can crash on exit.

  • Sometimes when resuming the game, the same sounds will play

  • Weapon/Tools placed in the environment return to full durability between game sessions

  • The shovel’s animation is not playing correctly. The shovel can still be used to dig.

  • When digging voxels, sometimes their collision will remain there.

  • Curved (partial-voxel) surfaces cannot be destroyed at certain angles.

  • Sometimes grass billboards can pop out of seemingly fully tilled dirt. This is due to an error with the blending; tilling each area around that billboard should remove the grass.

  • 3rd Person camera not fully functional; interactions are not working correctly; use only for viewing the seed.

  • The sprint key (Left Shift) cannot be rebound.

  • Can’t bind the Mouse 4 and Mouse 5 buttons
Next Page »