Greetings Ladies n Gents!
Cambo here, with another blog post to give you the inside scoop on what we are working on in the kingdom. Yesterday, we released a prototype video showcasing some triggers in action. They were created using Lua scripts from one of our code wizards, Anthony (@scriptslol). Triggers are a way to automate gameplay based on physical location in the world. We don’t want to dive into the technical details about triggers (you can thank us later). Let’s focus on the fun stuff that triggers can do for TUG instead.
Here are a few examples of us using triggers in TUG!
We introduced our plant trap prototype a few weeks back but there were some minor quirks due to our code rewrite for multiplayer support. The code is being reworked and we are real close to having it work in the next build.
This trigger activates a constant upwards impulse which can be used for many sweet things. The gif above shows how the object is constantly bouncing when it’s within the trigger box. That’s right! You can now have a mushroom trampoline bounce party with your buddies.
The fan prototype trigger activates a pushing force which can be adjusted within the Lua values. The image above demonstrates on how the force is used when jumping from one platform to another. Imaging this force being applied to magic spells, oh yea!
Pit trap you say? Yup! You can bet it has always been part of our ambitious goals to give players the ability to trap animals *cough* friends *cough* for resources. A damage over time effect is triggered once the player or object falls into the pit and well, you know the rest. Just don’t send us rage tweets when you accidentally fall into your own pit traps because you were stalking a cute cub.
What does this mean for modding?
These were completely scripted using Lua. Using the same tools, you can make your own trigger driven gameplay elements. It opens up a lot of possibilities, from firing world events to having doors.
Are you interested in seeing a tutorial on how to utilize triggers for your mods? If yes, let us know what would you like to see in a comment or tweet to us @nerdkingdom
Today’s blog is from our game designer, John, who will give a brief history about the industry’s modding community. You can always reach him on twitter @x_nekochu_x! Be sure to check out the Mod showcase video displaying some that are in the works and we can’t wait to see more.
Game modding has been around since the beginning of the game industry from items like bootlegged versions of pinball and arcade machines to its more modern counterparts of using tools provided by developers to the community. While bootlegs and chipset hacks can be considered mods, the more accepted version of modding that is known today has its roots firmly planted in the Wolfenstein and Doom games from Apogee and id.
The current form of modding had its humble beginnings with an idea of goodwill between an active community and the developers of a game. The accepted agreement came down to the developers of these games offering tools and resources to the community with the good faith that their modding efforts would extend the life of a game by offering new and unique content. In return, the developers’ only request was that this content would support the purchased copies of the game and not through freeware or any pirated versions that could hurt the revenue stream of the developers.
This sort of good will relationship allowed modding communities to flourish, as a community was more than willing to pay for and support good games. The idea was that there was the freedom to make adjustments and play a part in creating new content for a product that they already loved. Many designers now in the gaming industry can attribute their careers to this community involvement leading to their entrance into the gaming industry as professional developers.
Almost all modern games are built upon tools and editors created or used by developers to deliver game content similar to these early modding techniques. Typically, these tools are available via the game engine used by the developer such as Unreal, CryEngine, Unity, etc… Some of these tools are created by the developer to support an in-house engine or even as an extension to the tools already available to an existing engine. The modern modding community also delves into this realm by creating specific tools to aid with their own efforts to create content and make adjustments in existing games.
TUG finds itself at a unique crossroad in the modding community of today. TUG is being built on a new gaming engine, Eternus, that is still being developed in parallel to the game. The content of TUG is being driven by early community involvement and this involvement also directs the function and tools developed for the engine as well. As we actively develop the game, we are also involved with community feedback. This influences design of the final product, as well as the growth of the community around that product!
Throughout our development process we have always tried to remain active in the community as well as extending relationships to modders by creating tools that cater to their needs. This effort has brought us our first fruits of labor that we hope to share soon. By working with our modders, we will soon be offering content in an upcoming release that has been developed by our community members.
The slingshot will be one of our first weapons that has been created by mod community members and integrated into TUG. The efforts to make this happen have been a joint affair between NK team members and members of the modding community. This marks the beginning of our community relationships that we hope can grow and flourish over the course of TUG’s development.
So be on the lookout for this new ranged weapon! The slingshot adds the method by which other projectile weapons can be built and with your help we hope to offer many more mods into TUG in the near future!
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
Our wizard coders are slamming away to get multiplayer out for in-dev testing so we are focusing our on art direction for TUG! We are in luck as our Art Director, @inkmech, took some time to write a blog for all you lovely people!
Hi all! Inkmech here.
Today, we’re going to start a little series about the ongoing struggles of life changes to TUG’s art style! Our story begins a long long time ago, in a studio far far away. If you’ve been following TUG for a while now, then you’ll most definitely know, that we have had a lot of changes and progress on the engine side of things. Engine and code changes also affect art, and more importantly, what we can do with the art. Here is a video from a longtime community member that highlights some of the larger changes.
Lets begin with why these changes happen, and then talk about why we need to make more changes. Finally, see how the changes can resolve some of the issues. First off, our previous styles were not bad, and there are a lot of great assets. I would love to be able to retain some of the look and feel of them. However, a lot of our previous art, feels out of place and does not convey an overall aesthetic that is cohesive or tells a story. For example, our pine trees have great shape and play in their form, but the non-fruit bearing fruit trees are pretty plain and straight with realistic but lower resolution textures. We have numerous examples of these sort of conflicts, where engine limitations or waiting on a tech implementation left us with partially finished work or work that should have been removed. We have also made strides in tech that have caused some problems with the art direction. For example, we had to exaggerate normal maps to get a good read on the textures in our pre-new-terrain environments. As a result of the early exaggeration our new-terrain environments now have very pronounced normals maps that trends us toward realism.
So what do you do? How do you fix something that seems so all over the place? Our first step is to identify what works, for our world, and compare it to our inspirations. An important tip about looking at inspirations, is not to take from them, but to understand why they made the choices they did. This step gives you a hardy list of grievances that you then print out, roll up and use to hit the money people at the studio until they give you the time and funds you need to start making changes. Currently, we are in the process of putting ideas into stone, errr…. texture into voxels and finding what works best for our technology and end goals. We hope to bring a bit of nostalgia and fantasy into the current world of TUG. Most importantly, we want to tell the story of the world to you the moment you start exploring. In order to do this, we had to take a look back at the basics of design, but more on that next time! It’s time to finish this off so please enjoy some of the recent exploration pieces done to find our way!
Feel free to hit me with any questions on twitter @inkmech.
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.