Posted by on June 16th, 2017

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!

Leave a Comment

Posted by on June 2nd, 2017

Hello everyone and happy Friday!

Today we’re excited to share the progress we have made in the past few weeks. Development of Eternus 2 is making great strides as we are now starting to streamline how integration works for Art and Gameplay teams. For example, we can now directly bind to an Art authored UI layout instead of Programmer placeholders. Our radial menu is now implemented in is going through more polishing as we continue to test it. You can check out the building prototype and new radial menu in the video below.

Importantly, it’s been almost 1 year since Eternus 2 development started! We have learned a lot as a team and will continue to grow as we keep moving forward.



 


Have a great weekend!

-Cambo

5 Comments

Posted by on May 19th, 2017

Hi everyone!

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….”

Obviously we are not the first to do this. There are, however, benefits from a node programming system being used alongside Eternus that you don’t see many other places. First, all of our current prototypes, including VNP are all written in javascript/typescript. This allows for extreme extensibility and accessibility versus platforms written in lower level languages. Another aspect of node programming we wanted to tackle was large groups of functionality – trying to make large graphs manageable. To do this we completely redesigned how groups worked in the original library. Providing the ability to group nodes on the fly, and use those groups in multiple webs across a project. We hope this significantly cuts down on development time.

 

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.

Leave a Comment

Posted by on May 5th, 2017

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.

Marketing/Business

  1. With regards to the game’s business model:
    1. F2P was mentioned, although you last stated you were leaning away from this idea, are we any closer to a definitive business model and where is the “grey areas” currently?
      1. TBD
    2. What is TUG likely to cost (if F2P, how will you be making the money you need)
      1. TBD
    3. You mentioned the core engine was to be made available for developers to make their own games from, can you expand on that?
      1. Our goal initially is to provide access to the tools, documentation, tutorials and examples for devs to tie into our engine and develop their own mods and games.
    4. What is the plan for the kickstarter rewards? (Pets, mounts, wisps, etc…)
      1. TBD
  2. How do you plan to deal with the negative reviews and discussions on steam? Have you thought about removing the old steam page?
    1. We have had discussions about that, but at this point we are waiting to move the product further along before we make any adjustments to community discussions
  3. If you remain on Steam, but remove the original game listing, will you be handing out keys to all original players?
    1. TBD
  4. What are your current plans to draw in and maintain a large user base?
    1. The game we are developing we hope to be fun and engaging for users to play and as important is the platform we are creating for modders and developers to be a part of. A combination of both a great game and tools we believe will draw in and maintain users in large numbers.
  5. Do you have a community manager / QA member at NK? Do you have plans to get one on the timeline?
    1. As we are beginning to make efforts to refocus on our community we have moved resources to fill the roles for managing the community. They will be providing updates 2 times a week and participating in the forums as well.
    2. In regards to PR, stop saying “early next year” or “soon,” etc. Either give a timeframe or don’t talk about it yet/in that way.
      1. Noted
  6. How many people currently work at NK?
    1. 40+
    2. How many are from the original kickstart team?
      1. Our original team size was about 10 developers. From then till now we have grown a lot and 8 of the original guys are still here on the team, or actively collaborating from other projects they have joined.
    3. Do you have multiple development teams? What are they working on?
      1. Our full focus is on our single product and the development of the technologies to support it. The teams working towards this effort encompass
        1. Infrastructure / Tools / Engine / Gameplay / Data Sciences and Art

Data Science

  1. What kind of data is going to be gathered?
    1. Our focus on data is about how players play. We are looking at when and where do players go in the world, what things do they gather, etc.
    2. What will the data be used for?
      1. Gathering this data enables us to improve the experience for players based on a more scientific approach
    3. Will the data be anonymous.?
      1. Yes
    4. Who will have access to view this data? (Eg.. all, devs, or sold)
      1. Nerd Kingdom and developers will have access, as well as modders, and various academic institutions that are open to publishing findings publicly, but never without consent of players.
  2. Regarding inter-player activities and conflicts:
    1. What’s the plan for managing Griefing and the Kill-on-Sight attitude many have in survival games?
      1. TBD
    2. What’s the plan for managing harassment and other illegal activity?
      1. TBD
    3. If you’re running servers open to minors, will you have any special rules dealing with age differences among players?
      1. TBD
  3. What kind of in-game communication options/resources will players have?
    1. In game chat

Cambo

3 Comments

Posted by on April 14th, 2017

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.

 

 


image

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.

 

 


image

 

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.

image

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!

Leave a Comment

Posted by on March 31st, 2017

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.

 

image

[Biome Tool Graph]

 

image

[Animweb Graph]

 

image

[Biome Generated #1]

 

image

[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.

TUGv2

  1. Can you give an overview of the new TUG in a couple of short paragraphs, as if to new potential customers? What’s the “elevator pitch” description of the game?
    1. The game takes place in procedurally generated worlds filled with floating islands that are enriched with resources, populated with diverse cultures and held together by a deeply rooted narrative.
    2. Players slowly discover the beginnings of their universe through interactions and relationships developed within the game as well as uncovering the history of their own purpose for being.
    3. Through a series of relationships and a string of choices our players determine their friends, their enemies and their eventual place with their creators.
  2. With regards to features:
    1. Will we see any of the Kickstarter stretch goals being developed?
      1. Yes, without question, however timing is subject to the most impact it will have in early development for the community to experience.
    2. It’s been mentioned that manipulation of voxels in v2 will differ from that of v1? How much so, and what will the new system be like?
      1. Voxel manipulation will be available in our creative mode. During gameplay the focus shifts more to surviving within the world and building up a home world using prefab objects. Though, this may change to be more robust, once we have fully developed the game, and advanced some concepts of usability. Still, this is largely TBD
    3. What other features are likely to change from v1 (crafting, combat, building etc.)?
      1. Generally speaking, each feature has undergone revisions to create a more simplified / optimized approach to how they worked and to improve the user experience. We have done our best to keep the player in the game and not in the menus.
    4. What are the initial focuses of TUGs use of AI?
      1. AI plays a vital role in the experience players will have. Our focus on AI is one that feels alive with respect to how creatures behave in the wild, how companions seek to help the player as they build their worlds, and how enemies respond to our actions during combat. At each interaction we a setting a goal that keeps the player immersed in the world and the event that they are a part of.
    5. Are there any features which investors have decided on?
      1. Investors have played a supportive role in our goals and vision. They have allowed us the freedom to design and develop the game based on our recommendation for what works best for the world of TUG.
    6. How much input will the community get on new and current features? How will Nerd Kingdom receive this input?
      1. TBD, we will be leveraging a lot of contribution from the community from our exposed tools, as a medium to allow us to understand real insights from play, and reward those that assist in experimentation. This is a large motivational factor in why we have been pushing harder on ease of use for tools, and platform.
  3. With regards to modding:
    1. Can we add more complicated custom models to build with, e.g., a statue/non-voxel based?
      1. You will have the ability to add custom models of all shapes and sizes. Though to work best with the game there will be a list of guidelines for those that want to add their own custom content.
    2. This Update showed off lots of what NK has been working on over the last year; is there anything you’d like to give an extra highlight or detail on?
      1. As excited as we are about the game we’re building on top of a great set of technologies, we are super excited about being able to develop the tools and pipeline that will empower our users with the ability to quickly and easily mod everything that we do.
    3. Are there any plans to help push community driven development?
      1. Along with the tools to support and broaden community development we also have in the works a platform that simplifies and organizes everything for a community to be built around.
    4. Are weekly or monthly builds planned? (like minecraft snapshots)
      1. TBD
  4. Will there be documentation/tutorials/guidance for new players, or will that mostly be left to player-made tutorials/wikis?
    1. We have planned out to support players with
      1.  In game tutorials
    2. We have planned out to support developers with
      1. Documentation
      2. Tutorials (written/video)

The Engine Remake

  1. There is a lot to be said about what the engine does, and can do, but i’ll let Josh speak more to that in an update early next year
    1. When is early next year?
      1. TBD
    2. Could you please get into specifics i.e. how the engine handles voxels, networking, memory management, mesh and collision mesh construction etc.
      1.  TBD, can be addressed with engine writeup
    3. If possible some statistics on before and after measures.
      1. TBD, can share this information with sentiment of community in a write-up on our data and research, with a post-mortem on what we have learned, and will be applying as we develop the game further.
  2. At a time when updates were starting to become a regular thing (0.8.9), a decision was made to remake the engine. Why?
    1. During development of TUG we reached a point where there were several opportunities to create a new game engine which could be supported by a full suite of tools for modding and game development. Recognizing the scope of our plans for providing a platform for players and creators we took the chance and are now beginning to use the tools and tech that drove us to depart from the old and get started with the new. It was a big decision then and one that will continue to be what supports all of our adventures moving forward.
  3. With regards to hardware specs:
    1. What are the expected hardware requirements of TUG at release?
      1. TBD, actively testing and working towards lowest specs possible, but as we have stated for years, it’s a balancing act
  4. What are the new capabilities of the engine, that the old one could not do?
      1. TBD, but can offer a write-up from tech team in an upcoming update with some samples of work, and capabilities.
    1.  How easy will it be to modify the engine going forwards, both from a developer and a modders perspective?
      1. TBD, with recent implementations of the development pipeline, we have made modding and development significantly faster. Which impacts our ability to create content, and the ability of others within the community.

Have a great weekend!

@Cambo

Leave a Comment

Next Page »

Follow Us!

Stay up to date!

To get the latest updates on Nerd Kingdom tech sent right to your e-mail, fill out the form below