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!
TUG Multiplayer is in the works and we are getting really close to testing phase one. Today, Dr. Clark (Doc) explains in detail about our challenges and solutions. Don’t forget to follow him on Twitter @CoreyClarkPhD and nerd out!
One of the things we had to do for the new Multiplayer release of TUG was develop techniques that could be used to synchronize player and object movements across clients and server. These algorithms must be robust to handle the ever-changing time for transmission (lag) and loss of data that occurs between client and server. There is not a “one size fit all” technique that can be used, as each game’s environment, objects and genre present their own challenges. For example in TUG, there are 3 different types of objects that needed to be synchronized (3D Rigid Body Physics Objects, Remote Players and Local Player) and each required a different algorithm. In this blog series I am going to cover a few of these techniques while discussing some of the pros and cons each technique provided.
Another commonality between all techniques I will discuss is the need for security. In all cases we have to keep the server authoritative to provide a way to ensure that data being sent from each client is valid to curve cheating.*
*Fun fact: While we have made sure that the server has the ability to verify any request made by a client (digging, building, crafting, etc), we are not actually enforcing that at the moment, so … hack away.
3D Rigid Body Physics Objects
All of the physical objects in TUG that a player can interact with are controlled through our 3D Rigid Body Physics Engine. So when you find yourself in the middle of a pumpkin grove and a spontaneous game of “pumpkin soccer” erupts (true story), all of the pumpkins are physics enabled game objects that must be synchronized between the server and all connected clients.
The challenges for TUG was to find a way that allowed the following:
We ended up having the server perform all physics calculations for all objects currently being simulated and using common technique in game development called Dead Reckoning to update the objects on each client. Essentially the server sends a steady stream of updates (position, rotation, velocity, acceleration, etc.) for all currently active* physics enabled objects to each client. The clients then use this information to update and move all active physics objects.
*After a given amount of time a physic object will be set to “sleep” and no longer be updated until something applies a force to it, this allows us to keep the overall processing of physics objects to a minimum and save precious CPU cycles.
This technique requires two different parts:
When the client gets an updated packet from the server, it now needs to correct the clients data to match that of the server. If we were to just set the values sent by server to those of the clients, you would see the objects on each client snap (teleport) to new values and would give you that oh so sickening feeling of lag induced rage.
To prevent this we calculate the difference of the new object data from server and current object data on client. We now know how much position and rotation need to be applied to the object to catch it up to current state on the server. We add a piece of that difference over several frames while also updating the objects velocity and acceleration to that of the server. The image below gives a visual of how that process looks (only showing a position update)
Once the client has caught up to the last know state of the server, it continues to move the object on a client with its last know velocity and acceleration. If the updates from server are quick enough, then the changes in an object’s velocity and acceleration are small enough that continuing to move the object with its last known state will minimize the difference between the client’s state and the new state provided by the server on the next update.
If a users connection gets “laggy”, then the prediction will be incorrect, but the client will still use a smooth interpolation to get client’s objects back to the correct state.
If you have ever lost your connection to an online game and your player continues to move, but you have no control, then that game is using Dead Reckoning as well. There are issues where people have used this to cheat on a game to pass through walls. Essentially moving towards an object then cutting your internet connection, the player would continue moving passing right through the wall due to the dead reckoning algorithm since the game is no longer getting updates on position from the server. TUG will not be susceptible to this, but that leads us into the next algorithm that is used to visualize other players in the world on your local client. I will get to that in the next post.
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!)
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.
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
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:
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”
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:
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!
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;
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!