Jake (theFlying3.14) here, Lead of Tool Development here at Nerd Kingdom. Several powerful systems have begun to come online in the Eternus engine recently. To support these systems we’ve designed several tool prototypes to aid designers in creating content. Today I’d like to share one of the more important systems that are being reused in multiple instances to provide a comprehensive functional experience going forward: the Visual Node Programing platform, or VNP.
VNP is a node programming platform that allows users to script functionality across different aspects of the game. The system is already being used in a few early tool prototypes: the biome tool, the animation web, and an AI behavior scripter. Future tools such as the material editor, shader creator, and quest editor are planned for VNP implementations.
Developed from the MIT licensed ThreeNodes.js – a WebGL shader tool – we heavily reworked the basic data structures and assumptions built into the library. Although there is still a lot we would like to do with it, what we’ve ended up with gives us great scalability.
The Visual Node Programming platform exists as an abstract application that we employ within each tool implementation, customizing it to fit the context. This means when you open biome tool, you will be greeted with a similar experience as the animation web. However, in reality, each tool might need to operate slightly differently. For example, the biome system reads the node graph from right to left, whereas the animation system reads “state strings” from left to right. To accommodate this each implementation of VNP has its own override of several fundamental objects: nodes, connections, workspaces. This allows great flexibility when developing and updating tools developed with VNP.
“So great another node programming tool….”
Over the past several months we have gotten to experiment with a few different approaches to VNP integration. The first approach we took was to build the node graph, save the data models needed specifically for the node graph (like node.x and node.y, etc), and then grab just the data we needed for the engine resource, and send it in one big packet. Of course, this worked until we started building big graphs. Once the save packet got too big to pass between the frontend to the backend we smartened up.
The animweb tool took a different approach: each time a node is connected to the graph, the system evaluates where it is and dynamically adds it to the resource. This resulted in live coding. Being able to edit a resource’s node graph and see it change immediately. It also resulted in a lot of edge cases that are still giving me nightmares. For example, deleting nodes or removing one connection from a node that’s still connected to another field become really tedious.
Our overall goal for user-facing tools is to create simple interfaces that developers at any skill level will be able to leverage. VNP provides a familiar interface for designers as similar platforms are used in engines like Unreal and Unity. While programming with nodes can easier than scripting, this is not our final destination. We decided to tackle VNP first to provide us with a clear functional foundation of what designers need. Since nodal programming lends itself to so many situations, we can provide a consistent feeling experience across the game development workflow. Then later we can develop more specialized tools to streamline certain common practices and make it easier for less experienced devs.
I hope you enjoyed this look at our Visual Node Programming platform, and I’m excited to get our tool suite ready for feedback from our awesome community.
Hey all! This is Northman from Nerd Kingdom here to share some AI bytes with you. Specifically I’d like to talk about Pathfinding and how it relates to TUG and our characters.
Pathfinding is the act of finding the best path between two points in the world. The key word there is “best”. The definition of best depends on the type of game you are making and the type of character you are trying to find a path for. I think a small thought experiment helps to clarify the set of problems pathfinding tries to solve:
Imagine a mountain goat and a human facing a mountain that extends as far to their left and right as their eyes can see. Directly in front of them is a door. On the door is a sign that reads: “Tunnel to the Other Side”. The human does not have any climbing gear and the mountain is far too steep to for the human to scale it without proper equipment. If both the human and the goat want to get to the other side of the mountain what do they do? The goat does not have hands to open doors nor the ability to read. However, the goat is a sure-footed climber and does not have any problem scaling the mountain so it goes on its goaty way over the top of the mountain. Conversely, the human does have hands and can read so they take the tunnel. The path the goat and the human found are both the best path they can muster by their definition of best even if they are both very different.
By Darklich14 (Own work) [CC BY 3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons
*Insert funny remark about goats here.*
“Ropes? We don’t need no stinkin’ ropes!”
So now that we have defined Pathfinding and talked about what “best” means we can look at what tools we have for finding paths. Most pathfinding techniques break up the world into spatial subsections (nodes) and store information about how those nodes are connected (edges). In Computer Science we call a set of nodes and edges a “graph”. Graphs are cool because they have been studied by mathematicians since the 18th century (check out the Seven Bridges of Königsberg). What this means to us is there are well known techniques, also known as algorithms, for dealing with graphs and finding best paths on them (see Pathfinding on Wikipedia). One of the most common algorithms used in games for pathfinding is A*. I won’t get into the details of A* in this post because it gets technical very quickly but the image below provides a good visual representation of a typical A* search.
By Subh83 (Own work) [CC BY 3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons
An illustration of an A* search. The initial red node indicates the starting position and the green node indicates the goal position. The gray polygon represents an obstacle. The goal is to find the shortest distance path from the starting node to the goal node while avoiding the obstacle.The path found is highlighted in green at the end of the animation.
We are currently exploring algorithms and graph representations for our world in TUG but so far we have implemented a navigational grid. In graph terms the grid is made up of nodes that all represent the same amount of space (one square meter) and each node has edges to its immediate neighboring nodes (grid cells): top left, top, top right, right, bottom right, bottom, bottom left, and left. These cells can be blocked by obstacles (shown in the image below in red) or open (shown in the image below in blue). This allows us to run A* searches to find best paths for our characters that avoid obstacles.
Blue Cells: Areas a character can navigate in.
Red Cells: Areas blocked by an object.
I hope you have enjoyed this introduction to pathfinding. Pathfinding is a large topic with many different techniques available depending on the pathfinding problem at hand. If you have any questions please feel free to email me at “northman at nerdkingdom dot com”. We are working hard to refine our pathfinding approaches for our characters and look forward to sharing more with you soon!
Have a great weekend!
Happy Friday! Cambo here to kick the weekend off by bringing back the dev tech blogs. We plan to keep them coming at least once a month as we make more progress on development. In regards to the Q&A, most of them are answered and I’ll be sure to post it in our next update blog. For now, here’s our infrastructure dude, Maylyon!
Hey everybody! Maylyon here with a new non-game related, non-engine related, non-tools related tech blog! Hint: this is your tune-out point if those are the topics you are looking for. 3 … 2 … 1 … Still here? Excellent!
After literally years of silence about Devotus, I wanted to follow-up with a snapshot of where Devotus is today. If your memory is a little rusty, Devotus will be our mod content distribution pipeline to help mod authors create and manage their home-brewed content and deliver it to end-users. To get context for this blog entry, you should definitely read those first two blogs. Without further ado, the “what has been happening?” (aka: “you guys still work on that thing?”).
In case you didn’t know, there were mods on Devotus’s developmental servers from a TUG v1 ModJam in early 2016. Don’t go rushing to find them now; they’re gone. They were sacrificed to the binary gods in order to make way for…
Suspend your understanding that the term “serverless” is a lie because there are always servers somewhere and play along for a bit. The old Devotus architecture was built on AWS EBS-backed EC2 instances running a mix of Node.js, C++, and MongoDB. It looked a little bit like this:
The primary detriments to this approach were:
1. Paying for these servers (even extremely small servers) when nobody was using them,
2. Scalability at each layer of the stack would incur even more financial cost and contribute to…
3. Complexity of the implementation.
Moving to this setup allows us to:
1. Greatly reduce the costs associated with Devotus (especially when nobody is using it),
2. Offload most of the scalability problem to AWS (less work = more naps),
3. Synergize our implementation with the other microservices we have been developing on the Infrastructure team.
Devotus now allows mod authors to create git repositories on GitLab in addition to GitHub. It’s actually been there for a while but wasn’t there in the last blog I wrote. By supporting GitLab and their awesome pricing model, Devotus allows a mod author to choose whether they want their mod’s git repository to be public or private at mod creation time. This choice does not apply to mod’s created on GitHub because their pricing model is less awesome (but still pretty awesome) and I’m cheap (see previous section for proof).
In the “bad old” days (read as “a month ago”), mod download count was just an unsigned integer. Download request comes in, number gets incremented by one. Commence spamming download of your own mod to falsely inflate its popularity! Everybody wins! … Except for the people who want to use the system.
Now, in the “brave new world” days, mod downloads are tracked per-user, per-version. This allows mod authors to track their mod’s popularity throughout its release history and allows end-users to trust that a mod’s popularity is probably because of an amazing mod author rather than a mod author’s amazing spam-bot.
That’s all I have for this installment. I (or somebody from my team) will be back with future Infrastructure updates as we get new and/or exciting things to share. In the meantime, be sure to jot down all those cool mod ideas you have kicking around in your brain into a little leather-bound notebook so that WHEN TUG v2 is launched and WHEN Devotus is client-facing, you will be ready!
Have a great weekend!
Up in the sky! It’s a bird! It’s a plane! No! It’s a flying dessert?
Hey folks! Time for another new face: Flying3.14 is the name, full stack is the game. I wandered in a few months ago and have been banging on things behind the scenes; recently, I’ve been focusing on the user experience of the new modding system that Maylon introduced us to last blog, Devotus.
Access to this new mod system comes in two parts: a web portal and the game launcher. This blog will be focusing on the development of the web portal which will facilitate mod creation, versioning, and multi-author management. We’ll go over how to create a mod with Devotus, upload the source to GitHub, how to tag that code as your first version, and download the mod for the first time!
To create a mod, users must have both a Nerd Kingdom and GitHub account. After providing some basic information about the mod, the front end sends the create request while the user is free to browse the rest of the portal. On the backend, Devotus is busy creating the GitHub repo and preparing the customizable marking page. After a few moments the mod is created, a push notification is sent to the user and the new mod is available from the My Mods page.
All mods are created with an empty git repository, just waiting for awesome code. To add source to your project you’ll need to clone the repo and commit as usual. If you are new to git or GitHub, here is a resource to get you started. Helpful links such as the mod’s GitHub page can be found on the Management page. Here you can edit the basic info entered earlier, add authors, add dependencies, add media, and publish updates.
As explained in the last blog, one of the common problems we wanted to solve was mods with multiple authors. The Authors tab within the Management page allows you to add multiple authors, and Devotus will do the footwork to make sure GitHub knows who can access the repository.
Once everyone is on board and pushed their code, the Versioning tab will help you tag your release. Updates are made simply by creating a tag on any commit in the master branch. You can do this by visiting the GitHub Tags & Releases page via a link located in the Versioning tab. The tag must be formatted like so: vX.X.X-release. In most cases Devotus will be listening for these tags and will automatically start building the new download package in the background. In the event a manual check of the tags needs to be made, a link is provided in the Versioning tab.
Once Devotus is finished creating the download package, the status in the Management portal will update, and a ‘Test Download’ link will be available. Wa-lah! A single .zip package that contains your mod! Soon the Launcher will be collecting these, installing and managing the updates automagically!
Each mod comes with a marketing page that can be customized using the Nerd Kingdom Page Editor. Share this page with players and followers on social media to give a detailed insight into what your mod provides. This tool is found on the Management page and runs off the same media and information provided throughout the portal. Change the look and feel through the theme menu, and add images or YouTube videos in the media manager. Entire new sections can be added containing multiple types of content including lists and tabs, allowing you to fully explain the features and usage of your mod. We believe by providing modders with an easily customizable interface to reach players, each mod’s presence can be a little larger than the typical profile page on a mod management service. To try out the Nerd Kingdom Page Editor head over to the ExampleMod page where you can fiddle to your heart’s desire.
The frontend is still a work in progress, but it demonstrates the direction modding is heading, and we are excited about all the opportunities that brings.
Maylyon here with a new blog! If you just rushed to your “Nerd Kingdom Trading Cards” deck and didn’t find me there, don’t fret; I joined the Kingdom in March and have been quietly working behind the scenes as the Lead Infrastructure Developer. (On a side note, if those cards don’t exist, we should change that … .)
One of the things that has impressed me the most since joining the company is the perseverance of the modding community. You guys have such amazing ideas for ways to enhance or improve the gameplay of TUG, but the journey from “concept” to “deployment” seems fraught with needless perils:
The last may be a lost cause, but the answer to most of the other questions right now seems to be “the forums”. The forums are a great tool for fostering discussion in the community, but they seem like a less-than-ideal fit for the challenges that face a modder. Towards that end, we are actively working on Devotus!
Devotus will be a mod content distribution pipeline that facilitates the creation and deployment of mod content by the mod authors for the end users. With Devotus, we hope to allow the modders to focus the majority of their efforts on creating amazing content that pushes the boundaries of what Eternus can handle and stop worrying about the nuts and bolts of deploying a mod. The rest of this blog will focus on answering, “What does Devotus provide?” The next tech blog will focus on answering, “How can I use Devotus to be awesome?”
The first step towards admitting that you have a modding problem is registering your mod with Devotus. When a mod is registered, a blank git repository is created on GitHub; this will be the main home for the mod content that you create. Utilizing a third party git repository site allows us to leverage a proven implementation without the development time and risks of building our own in-house solution. Git repositories on GitHub should help mitigate frustrations 1 – 3 above:
I am definitely not providing a comprehensive feature set list of GitHub; if you want more information, hit up their website or contact me at [email protected] and I’ll do my best to address your questions/concerns/loathing. A few items to note here are:
Another feature of registering your mod with Devotus is the creation of a GitHub IO page. This page is yours to brag about … er, explain … your mod to the community at large. I’ll let the next blog cover the features that are being worked to enable you to create page content highlighting your epicness; I just wanted to provide a teaser to hopefully pique your interest and incentivize you to read the next blog … .
The second step towards admitting that you have a modding problem is publishing mod content for end user consumption. When you tag your git repository with a release tag in the format “v<Major>.<Minor>.<Revision>-release” (e.g. “v1.1.2-release”), a GitHub webhook will push an update command to the Devotus server that will revise the mod information within Devotus and build a ZIP file of the mod repository contents. The intent here is that you will perform a trivial action (tagging your repository) and Devotus will take care of the legwork necessary for that content to be available for download by the end users.
One hurdle of publishing mod content that Devotus attempts to mitigate is mod dependency resolution. Mod authors can indicate that their mod depends on another mod, and Devotus will provide a single download package that contains all the files necessary to use the mod. This feature could be used to develop content that depends on a utility mod (such as Johny’s “CommonLib”) or to develop a mod collection with a single-click installation ( “DaBoom” that contains all of UFIOES’s mods, including “Thermobarics”). A limitation here is that the mod that satisfies the dependency must also be registered with Devotus.
The final step in admitting that you have a modding problem is sharing that problem with others! Tech is planned to incorporate a Devotus browser into the Nerd Kingdom Launcher to mitigate frustrations 4 – 5b above:
This tech is the biggest piece of the ultimate goal: getting a mod into the hands of users.
So that’s it for me rambling about Devotus and scratching the surface of what we are working towards. @TheCamboRambo suggested that blog readers enjoy pictures. The backend isn’t visually interesting, but I want to make the audience happy, so I’ll end with this:
In the meantime, check out the latest NK Cribs video from Josiah!
Greetings again! Nekochu here to tell you about something very important that is coming up in the next release. This is so important and will change your life so much, that if everything works as intended you won’t even notice it.
What am I talking about? Modular tools of course!
For this first stage of modular tools, we have revamped all the bronze age tools and weapons to work with modular crafting. You may notice that the bronze items look slightly different, but they are crafted and work exactly the same as the old tools you are used to.
You may ask, “How does this affect me?” Well, at first this shouldn’t affect you at all. All of the work in this release is behind the scenes and visually you won’t see the potential of modular tools.
Let’s talk about the future though; that is where this new system will really start to shine. Items that can act as the “head” of a tool can be swapped out to generate new tools and the stats of the produced item will be adjusted based on the components used.
Now you’re starting to see the bigger potential! Imagine a sword that incorporates the swiftness bonus from its handle and the extra damage stat from its blade! Or perhaps you want to use a unique head of a pick that you crafted on all your future pick crafts.
We’ve only scratched the surface of where we can go with this new system but for now it lies in wait under the surface of the bronze tools. The future will decide where it grows from there!
We are fixing a lot of bugs this week and hope to push a new update soon. In the meantime, check out the latest “In The Works” video for the artisan workbench and loom here.
To get the latest updates on Nerd Kingdom tech sent right to your e-mail, fill out the form below