Happy Friday everyone!
I apologize for the delayed update as I was out with the flu last week. It is good to feel alive again! Getting back on topic, our engine team is cranking away on the Eternus engine and tools. Our gameplay team is improving our building methods, islands and more. Art team has been hard at work creating new assets for TUG. You can some images and video examples below.
Meanwhile, @x_nekochu_x is hiding away in the sound booth working on sound production stuff. I have been nagging him a lot to let me help out with sound effects. There’s just something extremely fun about making sound effects. For example, breaking things… many things.
We also updated our website and relocated our blog to the main site. You may find a few older posts with broken links and images but there is not much we can do to fix them.
The community questions have been finalized and we hope to have more details in the future. If you missed out, don’t worry! We can do another in the near future. We apologize for some of the TBD answers as those are still in discussion.
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!
Hey everyone! I hope everyone is having splendid week.
We are still hammering away on the engine and tools so there are not many visuals to show yet. However, we do want to keep you all updated with more goods so I will be sharing videos from our tech demo Fridays. Until then, here are a few WIP shots of some of our new tools.
[Biome Tool Graph]
[Biome Generated #1]
[Biome Generated #2]
[Early rough video of our floating island with sample of edges]
[8 blend target]
In a previous blog, we answered many of the planning and lore questions from the community. Today, we’ll focus on the TUGv2 and engine remake questions.
The Engine Remake
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!
Hey everybody! Cambo here and Happy Friday!
I’ll go ahead and update everyone since Ino is lost in the world of Zelda today. The team has been very busy the past month working on our engine tools and gameplay features, and core experiences. I will personally be working on having more frequent blog posts, dev updates, and videos when they are available. I am aiming for at least twice a month and video snippets from our demo Fridays. Importantly, I hope to shift our blog posts to our website in the future.
In the last blog, we mentioned that we would take note of the QA document that was compiled from the community. I got to work and nagged the team leads to answer them, nagging is what I do best. You can find the questions here. Thanks for organizing and bringing this to our attention @Rawr! The leads answered most of the questions but we will wrap up the rest over the next couple blog posts as we have more concrete answers. Get ready for the wall of text!
Radial Menu UI prototype
Have a great weekend and don’t forget to follow the leads!
Engine Programmer Lead @JoshuaBrookover
Gameplay Lead @Scriptslol
Our adventure into gameplay prototyping has begun, with big steps towards making our development environment much more seamless and flexible. The benefits to having a small team of brilliant minds, is that we are constantly forced to looking at ways to make our lives, and the lives of our users, easier. We have to find ways of making things accessible, faster, and easier to understand, and while that can take more time than just smashing a system into an engine, the results are exponential, and keep everyone excited.
In the coming weeks, we will continue to take note of the QA document the community has been compiling, and aligning our internal leads to address them as appropriate. Without question, it will result in more and more questions, so we are discussing how best to address this. We get a lot of live feedback from everyone involved in our discord channel, and please know it’s invaluable
As an update on our investor presentation, it went fantastic. Everyone is pleased, and excited about our progress. It’s always been a chore, to focus on the idea that we ARE making a game, but not understanding how important all of the technology and tools are, in being sure we can make it, and the community everything it has the potential to be. The investors, and many new opportunities, are seeing what is now being accomplished and it’s very exciting.
The members of the community that have been messing about with our current build of the engine, has been leading into a lot of interesting discussion, and strong insights into our approach. Much of the thinking has made it clear we are on the right track, which is an empowering sentiment when working on something this ambitious.
On that note, we will be clearing out mods from devotus from previous mod jams, to start prepping to get another version of the engine out in the coming months to a larger community, and start our own mod jams as a studio, with members of the community, to start focussing on more aspects of process and communication. Its understood that no dates creates a lot of frustration, but we have to put stability first, especially since we know there are a lot of high expectations, and locking down hard dates right now, have the potential to set everyone up for failure.
The QA will be a smart step forward, get everyone on the same page about what is happening, shed some light into general milestones, features, mythos, etc. And from all the pieces missing in the QA, we will have an opportunity to define the angles that we need to work to communicate better.
As always, thank you for all the support, your near endless patience, and confidence in what we are doing. Not one decision gets made for us, that doesn’t have us asking “what would the community think”, or “how would our community use this”. And this thinking is producing some really neat solutions, that are exciting enough to keep us working hard.
Expect another update from us in a couple of weeks, as next week is a big rush for us on dev goals, where we can lock down a schedule for the QA session, share some video, and get out some general milestones and feature lists for our first public release of TUGv2.
Procedural Maze Generation