Hello everyone! The name is Duane and I am the Animation Director here at Nerd Kingdom.
During my lengthy career in game development, I have certainly been here before. Well, not really here, as here is a bit different. However, in some aspects, it is almost entirely the same. The outstanding difference is the Eternus Game Engine currently under development at Nerd Kingdom. Built from the ground up, Eternus holds the promise of a groundbreaking game development engine and tools upon which its flagship product will be developed. So, it’s deja vu all over again…or is it?
The first time I heard the term “virtual reality” was when I began my career in 1994 as a Lead Animator at Virtual World Entertainment (VWE). The Chicago game studio made two products, a first-person shooter (FPS) “walking tank” game called Battletech and a “hovercraft racing” title called Red Planet.
Each product was built from the ground up on a proprietary game engine, completely unique to the requirements of gameplay for a multiplayer FPS and space-based racing title respectively. Each engine included its own set of development tools and export processes, designed and built with essential integration toward the support of an efficient iterative creative process. Nothing was borrowed or modded, and middleware was non-existent. All of it was brand new, completely from scratch. (Ok, truth be told, some code between Battletech and Red Planet was recycled. But, I’m trying to make a point here.)
Fresh out of college, I was the studio’s first and only Lead Animator and it fell to me to collaborate with a newly hired Junior Programmer to design, test, and implement an integrated LOD Texturing tool. The sky was the limit and… “What the hell is an LOD anyway?”
So, there I was, tasked with one of the most important art tools for Battletech’s and Red Planet’s CG art development. Not because I was particularly suited for the role, but because I was “the new guy” and no one else wanted the job.
If you’ve ever wanted to make games for a living and knew nothing about the process, I knew exactly what you did when I began my career. Lucky for me, this first challenge was a remarkable Art Tools design experience and quite an education.
Trial by fire, I learned how to make LODs by hand expeditiously, a method of reducing an object or character’s total number of polygons while maintaining its shape and silhouette. I made four Levels of Detail (LOD) for each of the 20+ Mechs (aka “walking tanks”) and 12+ VTOL (“vertical take-off and landing”) racing craft. That’s 128 LODs plus the original 32+ models.
Then, I learned about creating UV Maps followed by applying textures via Planar Projection mapping for the many texture groups within a single model. At the time, Planar Projection mapping was all that this tool would provide.
The number of texture groups per model was exponential. I had to rotate and place each Planar Projection, an intermediate object represented by a 3D Plane, over every single polygon group or group of facets (aka “face group”). It was meticulous work. But then, that’s why we were developing the LOD Texturing tool in the first place, to expedite this laborious process. Ultimately, our efforts allowed Artists to texture any 3D model and all of its LODs based solely on the original models UV textures. It was a profound success and increased my passion for making games and inventing game development technologies, in general.
By the way, is it really work if you love what you do for a living? For me personally, animating for games is truly a dream come true. I remember when a Tippett Studios’ VP at Siggraph once said, “These guys will work for nothing and do it all night long. They love it! They’re gamers and artist.” I thought, “Holy sh*t, she knows our secret!” But, it’s true. Game developers will work long after their salaries have exhausted a full day’s work. We are habitual over-achievers with a relentless work ethic. Like some kind of digital junkie, looking forward to that next first moment of realized innovation in VR immersion. It’s addictive! That’s why most of look the way we do…trying to score that next (top-selling) digital hit. Thank God mobile game development offers the same euphoric affects at smaller doses. And, with the recent debates over VR/AR/MR, virtual reality, augmented reality, and mixed reality respectively, the digital chug-wagon continues.
I remember when I was in college, learning Alias|Wavefront software on a Thompson Digital Image machine back in the early 90’s. No one knew what they were doing. The teachers that were teaching the 3D Art and Animation curriculum at Columbia College Chicago had no clue what 3D was or even how to teach it. Every student dove into the manuals and surpassed their instructors before the end of the second week, too impatient to watch some “old dude” struggle to understand the poorly written tutorials.
Anyway, I digress, back to the topic at hand.
Other things that haven’t changed in game development for decades? How ’bout the division of labor across three main groups – Programmers, Designers, and Artists. At VWE, I learned about five disparate teams the studio employed in their game development process – Owner/Managers, Programmers, Designers, Artists/Animators, and Testers. And that right there was the pecking order by status and salary. How little has changed in the industry as a whole.
Each of these teams worked in silos as focused but independent specialists prior to pre-production and were brought together as one homogenized unit as the pre-production “vertical slice” neared completion. No, “vertical slice” has nothing to do with bread or ninja skills – Google it.
Over the years, the terminology for “development meetings with prioritized schedules or milestones” mutated into words like Sprint, Scrum, Agile, and Agile/Scrum. Call it what you like, it has been the same process since the dawn of game development. In its most basic form, it goes something like this – create a series of meetings based on a prioritized schedule of milestones around the topics of concepts/game ideas, dev, design, art, scope, and schedules. Then, build and test the plethora of advancing software. This is usually followed by cycles of wash/rinse/repeat. Critical to the successful development of this cycle is smart, honest decisions by talented and experienced key team members…and yadda, yadda, yadda – it’s boring stuff, but absolutely necessary.
Another enduring oddity in game development is something called “studio culture”. Here’s a checklist of things that, in my experience, have existed in every studio I’ve ever worked for:
⦁ Very smart, technical/analytical problem-solving academics who love games and are “kids at heart”
⦁ A fascination with technology trends, games, movies & music, art & animation, and science fiction/fantasy.
⦁ Communal eating spaces/kitchens with free drinks – a game developer’s divine right.
⦁ Tattoos, piercings, long hair. Occasional bad hygene? Perhaps.
⦁ Action figures
⦁ Nerf guns
⦁ Darkened work space that are quiet, but at times rowdy on a good day (aka productive day).
⦁ Flexible 8 hour work schedules
⦁ Casual clothes – bare feet (aka sandle or flip-flops), bare legs (aka shorts), baseball caps, and enigmatic t-shirts.
⦁ The mention of manga/anime, Weird Al (Yankovic) for some reason, and anything sci-fi…most likely a Star Wars reference.
And then, there’s the “proximity task”. Happens all the time in game development. It can usually fall to the person who is simply absent at the wrong time during a formal team meeting. But when it’s an informal discussion, simply sitting at your desk near one can get you saddled with a task that no one wants. Like today, for example, when I was asked to write this blog. Happy reading!
By the way, if you’ve made it this far into the article, then bless you for your unwarranted attention. You are a saint! Take heed, I’m almost done.
One last thing that is ever present in this industry are the abundant proprietary processes developed and never shared by the multitude of game developers the world over. With most new games and especially with innovative immersive AR/VR experiences on new hardware, a new engine, SDK, and game product are under simultaneous development. In my experience, the lineage of this simultaneous development started on PC, followed by the original Xbox console, then Xbox 360, Kinect, HoloLens, and Magic Leap.
And now, finally, “Back to Eternus”. Sounds like a great sci-fi epic, doesn’t it?
Here at Nerd Kingdom, I ran into an old friend of mine not mentioned above, good ol’ Mister Frame Rate. “How have you been, Old Chum? It’s been awhile. Wife and kids? Goooood.” Ever the divisive arbiter of quality graphics versus render speed, Frame Rate could often be an allusive collaborator. But last week, he sauntered up to me with a drink, “Here, knock this back. Oh, I forgot. You don’t drink. (Chug! Slurp.) Let’s talk, shall we?”
So, after closing time, there we were, old Frame Rate and I, talkin’ ’bout the Good Ol’ Days and the mischief he put me through as a Director of Animation under fire for the largest memory footprint that character animation had ever occupied in VWE’s history. Now, I can’t say that I remember those days with as rosy a resplendent recall, but I do remember the relief I felt when we were able to solve the issue with a technical art solution, an animation export tool, that we could all agree upon.
Allow me to blather on in detail about this very familiar topic. In the early days of game development, when you would export a character animation for a game, whether authored in Maya, 3D Studio Max, or some other CG software of choice, the animation asset was exported as a linear keyframe for every frame of motion exhibited by each joint or node in a character’s skeletal hierarchy, regardless if its value changed or not, for the duration of the motion.
Well, as we research a popular export format, it is creating a similar result – a keyframe on every frame. And so, it’s not surprising that discussions about frame rates and reducing file sizes have stirred this air of frame rate nostalgia. Suffice it to say, there is a lot of keyframe data that can be filtered and omitted from animation assets that will reduce the size of every animation file, thereby reducing its memory footprint, load times, and in turn increase frame rate.
The last time I helped solve this puzzle, we decided upon a proprietary export tool that would allow the Technical Animator or Animator to provide an overall attribute value, as well as an attribute value per joint (per axis) to influence the total number of keyframes that would be generated along a curve. These attribute values would then generate a range of results, interpreting the motion (based on angle deviation) as “a keyframe every frame” to “a reduced or filtered key set based on the degree of change (by angle deviation) along a curve” to “omitting keyframes completely”.
Said differently, the algorithm inspected the curve and re-created it as a slimmer version of itself (in bits). Where there were more changes in value, more keyframes were exported or maintained along that portion of the curve. Where there were fewer changes in value, the placement of keyframes was farther apart. Whatever solution is devised for Eternus, we are certain to surpass the current state of our technology as of this writing. And, I can’t wait to revisit that feeling of overwhelming accomplishment when the motion in-game is identical at less than half its original file size.
Oh, the nostalgia for innovative thinking. All of it, in pursuit of making great gaming experiences with Eternus that will entertain and occupy the masses. I guess you can go home again.
All that’s old is new again – for the first time. May you enjoy playing our product in its many pre-launch versions. And may the God of Shipped Titles smile upon us as we run head-long into the many game development cycles of deja vu and repeated timelines. Wash. Rinse. Repeat. Game.
Have a wonderful weekend!
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!
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
Ahoy! Just wanted to give you guys a quick update on what has been going on this month, and some things to expect coming into next month.
We have a big investor milestone meeting coming up on the 19th, and all of our time has been focussed on getting all the systems we shared with you, via youtube, stable and clean. Of course, those systems are not fully fleshed out game features just yet, but it’s a strong foundation built on the engine that is allowing us to expand out on things with gusto.
Into the coming months, we will be focussing on what is defined as a “minimally viable product”, that is to say, “what does this game experience feel like, with polish, for a short play session”. So while it may not be perfectly balanced, we need to demonstrate polished animations, some competency with enemy AI, and strong visuals (particle effects, graphics, etc). This also means a grasp on what the actual UX is in a 3d space, which revolves around the process a person gets from a keystroke, or series of keystroke, from a selection to an action.
Working through these things over the next few months gives us an opportunity to start being more open, again, with some of our thinking, and intentions, with design. While we do not expect EVERYONE to approve of all our choices, the product is too early on to allow for any design by committee. We will be responsible for creating the foundation of what the experience is, and leave opportunities for systems to be modified and expanded upon. And this is much of the reason we are so focussed on tools and our own development pipeline. The more clean and streamlined that is, the easier it would be for any of you to do, as well.
Some of you in the community have brought up the possibility of a QA, and that is a pretty solid idea. We love getting a chance to talk to all of you, and answer questions. If nothing else, we can always say that we pride ourselves on transparency, even on topics that are taboo and perpetuate chaos and confusion… (web based cookie clicker FTP clone, anyone?) But first, we are gonna get the current build into the hands of a few of you, and have some footing to get both technical, and experience driven question from all of you. So expect us to start taking in questions in a couple weeks time.
That is pretty much it for the time being, but if you have any questions, you are always able to reach out to any of us, and you will hear back from us.
To get the latest updates on Nerd Kingdom tech sent right to your e-mail, fill out the form below