Its been quite a while since we have brought a build off of indev and into the main branch, so this update is a really big deal for us. We have gone through quite a lot in the past several months, and it feels great being able to hit this milestone with the engine getting the first phase of multiplayer running, and letting all of you guys enjoy TUG with your friends *cough*.
We moved new terrain into the main branch, and its faster than its ever been. With that, we also have got some non blocky blocks within the world for various interactions in survivor and a bit of an overhaul on controls in creative mode, to allow you to scroll through shapes. Its all still a bit crude, but it will help get things done. This is a big step for us, but its nowhere near the last… lots of big stuff is still on the way.
A big chunk of our team is on their way to PAX South today, and setting up to show off some progress to the gaming community, so this is a big deal for us. You can visit us at booth #1483. With this milestone, we are also pushing that price increase we have been talking about for some time. But, to allow some last minute backers/contributors/buyers/people, we are putting the game on sale at the $19.99 price point (which means its gonna sit at $10 for a while). Not sure if we are going to do a price increase again… but as we did in this case, we will share those thoughts as soon as we know… it will all just come down to how far we can push this project.
Below, you can check out a descriptive list of things we’ve fixed and still need fixing. You will see some more focus on features and content with the next few updates, and the occasional hot fixes. And If you come across any errors, crashes, or weird instances that just don’t seem right, feel free to let us know on our forums or contact us [email protected].
As always send all your cuddles to me on the twitters @inoritewtf and any potential nerd rage to @joshuabrookover, hes one of our new engineers… and he needs a good hazing. Also, gratz to Cobell who was moved up from PM to Producer on TUG! (get a twitter already… GOSH).
Fruit and Growables
Work In Progress
All the dust is finally starting to settle with our team setting up as the new “controllers” of the project and development has been keeping us pretty busy, but we are pretty psyched to be able to get this indev push of multiplayer out to you guys. Hooray, TUG with your friends!
This first phase is only survival mode, with creative to follow next week. And keep in mind, we still have a lot to do with networking alone, so expect some of the usual bug shenanigans (listed below). We really do need the help identifying issues with the game on many types of hardware, so please post those reports to the forums or send em over to [email protected] We will be watching and listening and pushing out fixes over the course of the next couple of weeks as they arise.
Also important to keep in mind, multiplayer in this iteration is still fairly early, so don’t expect crazy furry parties just yet. With more time and more tech, the experience and player count will improve. As to what that count is, we still cannot say… We are in new frontiers with the networking inside and such a heavy focus on physics AND voxels, so lots to see through development.
In addition to pushing out fixes for multiplayer next week, we are also gonna be pretty slammed getting ready for PAX S, so hang in there if we are not as speedy to get back or as active in the forums as usual.
That’s about it for now guys! Enjoy trolling your friends!
Don’t have InDev branch? Opt-in here
Note: Creative Mode is currently being reworked. While it is available in the menu, it will crash the game. It is our next priority.
The save system has been updated so any older save games will be not be valid.
Work In Progress
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.
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
Imagine the world frozen in a great crystalline winter. Every animal stilled midmovement, every leaf perfectly preserved, even the wind has been captured by this eerie stillness.
This is the world presented to a visual effects (VFX or simply, FX) artist with the vague mandate “fix it”. But where do you start?
FX should usually be one of two things:
obviously out of place
subtly blended with the world
Obvious FX are things like fire, spells, scifi beams, explosions; effects that are big, flashy, and “cool”. They are extremely fun to make and very easy to get feedback on because they either work or they don’t. End of story.
Subtle FX are ones that fit within the environment around the player & are most noticeable by their absence. For me, environmental FX are the most satisfying- even if they usually go unremarked. There’s a moment when the scene clicks and suddenly you know it’s time to move on to the next biome.
Since TUG is procedurally generated, the FX I make have to work anywhere. In past games, I might be able to set up an FX for specific angles, or distances. A far off waterfall could be done cheaply PC performance-wise in a game that limits the player’s movable area. In TUG that same effect needs to look as good up close as it does from far away while, but also be able to allow for a randomly generated number of them to appear in the same scene. Usually this works. Sometimes you get synchronized leaf drifting.
For the most part, FX in TUG are tied to objects – they come from a fixed source. Glowing spore softly drift from little mushrooms, will’o’wisps dance around the the deadly trap lures, leaves drop from their respective trees. But what about the more extreme biomes that can’t support lush plantlife?
We rely upon the wind. By creating small dummy objects with a transparent texture to attach the FX to, we can populate a biome with a cohesive effect that appears to come from everywhere and nowhere as once – just like a gusting wind blowing sand across the desert, snow eddies striking up suddenly in the mountains, or hazy fog drifting in the swamplands.
Nerd Kingdom is building our own engine and this brings with it some unique challenges. Every effect made so far is temporary. As our tech improves or is changed then so are the FX. I’ve already lost count of the number of times I’ve redone the wisp or fires as updates have come down the pipeline. Our engine is still very young compared to other games out there, which means there’s a lot of room for us to grow- especially in the FX department.
It’s exciting to think about what we can add next to improve how our game looks and feels. As more content gets added and new player mechanics come online, the variety & need for more effects ramps up too- turning TUG into an increasingly vibrant and living world for you to explore.
Jessica Nida (aka geekthumb) is the Senior Artist & FX Lead for Nerd Kingdom. She likes art, games, and making things explode in a ridiculous manner. When she’s not practicing aeromancy in TUG, she’s designing boardgames in her spare time or cooking enough food to feed a small army. She’s recently started kayaking in the hope of spotting the Lake Dallas Leviathan, which she did not totally just make up.