1. Void Crew
  2. News

Void Crew News

Hutlihut - Space Log #3: Addressing FPS issues

[h2]Hello all Ectypes,[/h2]

Our “Space Log” is a channel for communicating more to the Void Crew community. We want to share what we do, challenges we experience and our plans for addressing these challenges.

We hear you, there are issues and bugs on the must-fix list, that we work hard to solve. Our message to you is: We are committed to both expanding the game experience, AND fixing the problems and bugs.

One of the annoying problems experienced is known as the FPS issue.

So in this space log we talk about moving platforms, physics, how it connects to the current FPS issue and how we are planning to solve it.
---
[h3]Problem - Refresh rate capped to 60fps (...sort of) [/h3]
When controlling the character or the ship, the refresh rate can appear to be capped to 60fps, but only when it comes to moving your character/ship. Other element movement, such as effects/animations or even camera movement when manning a gun can appear perfectly fine and render at the correct framerate.

…this is of course not ideal, but to understand why the game behaves in such a way and how we are going to solve it we will have to go over some technical details.

[h3]Background [Tech Talk] - Moving platforms [/h3]
To make it possible for a player to walk within a spaceship while it's flying around we have to utilize moving platforms.
  • First, the player needs to be registered to be in the moving platform: that is done by either the player center point being positioned within defined room zones or by the player ground collision detecting that it is grounded to a moving platform type (this is used if you are outside, standing on top of the ship).
  • Second, when a player is registered to be attached to a moving platform, instead of calculating their position and velocity in world space we do it in the moving platform's local space.
  • The effect of this is that no matter the velocity and position of the ship, the player can reliably move around the inside of the ship.

[h4]Physics and why refresh rate seems locked [/h4]
Static colliders are great!
…you can create complex shapes, throw them into the physics engine and after the engine figures out how they plug into its world boundary internals, you can expect really good performance with little headache.

However - static also means not moving, unlike our spaceship. This adds a performance penalty whenever we move the ship by any amount, which scales depending on how many colliders we have on the ship, and how many interactions they have. Even though we try to optimize the collider amount down as much as we can, we can only do so much, before walking in and on the ship becomes a janky mess.





This also forces us to work strictly with the physics engines update loop. Any update outside the loop will force an internal recalculation, which will completely tank the performance. The former applies not just to moving the complex bodies (spaceships), but also anything touching/overlapping them, since even a small object can affect the rigidbody properties of anything it touches. In other words, if you throw a pebble at a truck, the physics engine still needs to calculate its new velocity, however small, and change the truck's position, whatever fraction of an atom distance it may be.

An obvious solution for this would be to enable rigidbody position interpolation.

What it would allow us to do is to get an estimated position of rigidbodies in between physics engine ticks depending on when we sample for such a position. This is where the moving platforms again introduce another issue: since the ship and players are their own rigidbodies their position interpolations are also done separately in world space. Result of that basically makes the character shake and jitter violently.

So the end results of all of this?
…we had to simply stick the player and ship movement to the physics update which we set at 60Hz.


[h4]Floating point precision [/h4]
The last problem we face with our moving platforms is caused by floating point precision.

Players are primarily experiencing this issue as slowly drifting camera/character rotation, though other things may start to misbehave as well as you get further and further away from the world center.
Floating points (number data types used for basically anything physics/graphics related) lose their precision as you use very big numbers, very small fractions of a number, or as you simply do operations with them. Generally, as long as you don't go too extreme, it's a non issue. It much more easily becomes a problem if you expect to return to the original value by doing the inverse of any operation you did before.

In our case that would be taking the players local position/rotation, using the ships position/rotation to calculate the players world position/rotation, move the player in world space and adjusting their new position due to any forces/collisions, and use the inverse of the ship position/rotation inverse to recalculate the new local position. All of this can cause the local position/rotation to drift by just enough to be noticeable. For example, an offset rotation of 0.005 degrees and physics tickrate of 60Hz (it's what we use) would result in 0.3 degree turn per second which is plenty high to be very noticeable.
[h3]Solution - …in the works [/h3]
To solve all the listed problems with the ship and characters we will do something we already do with carryables: using separate physics scenes/environments.



What happens in the game at the moment is that all carryables, as long as they are on the ship, are being simulated in a completely separate ship simulation scene, separated from the main game scene. This was originally done to allow us to use the existing physics engine for all carryable movements, and moving the character simulation there is the obvious next step.

To make this work as best as possible there are multiple types of behaviors we need to support within different physics scenes:
  • Everything relating to character locomotion, this includes both moving the character and doing wall/ground collision detection.
  • Interaction logic - allowing terminals, physical buttons and carryables to be interacted with both in main and physics scenes.
  • External movement modifiers, making sure we can modify players position/velocity relative to the main scenes world space position.

Once support for everything is added we can:
  • Use ship and character movement interpolation (fixes the character/ship movement being capped at 60Hz)
  • Drastically reduce the moving ships internal element complexity (more overall performance)
    - All those elements can live as static colliders exclusively in the ship simulation scene
  • Minimize floating point errors (no more camera drift)
    - Simplification of calculation since all movements are done within the local space
    - Staying at the center of the world reduces distance based errors.

---
We hope to have above FPS issues fixed for Update 3 (released planned for Q1 next year), but up until then... Happy holidays and Metem Preserve You!

//Kristijonas (Lead Engineer) and Hutlihut Games Crew





Community First - Update 2 - Holiday Special!

Our Community First Update 2 with a special layer of Holiday mood is dropping this Thursday (14th of Dec 2023)!

Here’s a sneak preview of what’s to come:

[h2]Community First[/h2]



METEM’s Ectype Resource Department has been hard at work with local Ectypes (aka Players) to increase the chance of success on their Pilgrimages, and presents a series of initiatives on how you can best the HOLLOW. METEM Command takes your struggle seriously, and approves of several must-have-requests, including (but not limited to):

  • Engineering Role
    The Engineering Perk Tree now sees a separate branch for using Enhancements - Extend Duration, or Buff the Enhancement Effect even higher! (Unfortunately, tampering with the Enhancement Interface also comes with increased risk now. Fumbling an Enhancement will put it into a temporary Failure state. Engineer-Ectypes, however, can recover from the Failure state, while grumbling contemptuously to themselves, obviously.
  • Void Jump Revamp
    The Void Jump has been split into two parts. Leaving (read: Escaping) the current Sector & Planning where to go next. While inside the Void Jump Tunnel, take as much time as you need to Repair Defects, Recycle Stuff and Blame each other for what went wrong. You have all the time in the world… Unless of course you get Interdicted!
    Dev Note: The Void Jump Revamp is the first step towards enabling longer Pilgrimages.
  • New Astral Map Interface
    The Astral Map interface has been updated to accomodate the new Void Jump procedure. When in an Objective it provides a helpful recap of the current Objective, and allows Player to plot a Vector to leave the current Sector. Inside the Void Jump Tunnel, the Astral Map gives a more immersive overview of the Upcoming Objectives, as well as any side-objectives that might have appeared.
  • Ship System Upgrader MkI
    A new Epic Carryable that can be used to upgrade an installed Ship System Module to a higher tier! This includes any system, pre-installed or the ones made from Animus Crates! The Ship System Upgrade can only be found as loot during a Pilgrimage, so make sure you stay in METEM’s good graces.
  • … and more!


[h2]More Content[/h2]



The HOLLOW are escalating as well, this time bringing several new enemy down upon us! One generates shields to nearby HOLLOWS, while another one … well making the Void Jump a safe space for players tempted the HOLLOW to make an enemy which interdicts players while jumping!


[h2]Holiday Special[/h2]



Praise the season! Especially since we don’t really have those in space. Either way, Ectypes should be reminded of the Holiday spirit of the Progenitors, and therefore the METEM Party Committee’s request for a decoration budget has been approved. Including Hats.

A word of Caution: A mysterious REMNANT Freighter filled with dubious Presents has been sighted roaming METEM’s domain. If you detect him during your travels, you should jump to his location if at all possible. The madman is clearly delusional, and taking him out should be our number one priority… Also, you might earn some awesome cosmetics for doing so.

This is our first Seasonal Event! You'll find a special Optional Objective temporarily added to the Pilgrimages. Completing this Objective (on any difficulty) will net you a Seasonal "Festive Lootbox" containing time limited cosmetics.



[h2]What else?[/h2]

This is a pretty big update, if we may say so ourselves … but, you’ll just have to wait until the drop!

Join our Discord for more news, and don’t forget to tune in on Thursday to read the full changelog.

Hutlihut - Space Log #2: The Making of Temperance

Hello fellow Ectypes!

This our second “Space Log”, one of our channels in communicating to the Void Crew community.
We want to both share what we are doing, challenges we experience and what we are working on.

...a part of this is also giving more in-depths look into our different roles in the team.
In this spacelog it is our talented Artist Kristoffer sharing his perspectives in working on the Solar Systems of Void Crew.

So, we hope you enjoy it, our second Space Log:

---
I'm Kristoffer, Senior 3D Artist working on Void Crew. I have been a part of Hutlihut Games for about two years. When I joined, there was quite a lot established - like the Frigate and the Destroyer, Characters, but also a rough version of the first Solar Systems we encounter: Temperance.

In this Spacelog, I will share my perspectives on how this was expanded, and some of the different (visual) elements of Void Crew came to be, starting this: The Making of Temperance.




A part of our vision was to have up to 4 different Solar Systems (biomes), but due to time limitations for Early Access launch, we ended up focusing our energy into 3 Solar Systems:
  • Temperance,
  • Vigilance
  • and Bravery.

Each sector should have its own clear identity, both in its space elements (asteroids, suns, planets, vfx and so on) but also in its color scheme.

Everything starts with an idea, which is put into text in design documents. From thereon, we start with references and mood boards.

My task was to give the Solar Systems a clearer identity, clearer color scheme and come up with unique space objects for each Solar System.

What is a mood board? It's a visual representation of pictures and references from existing pictures. This can be real pictures from the world around us, cities, nature, oceans, weather etc. But it can also be from other games, movies and TV-series, comics, art or whatever conveys the visual imprint you are trying to achieve.

"Blocky Ice" Mood Board

We started with an asset bundle of somewhat generic asteroids to begin with. But...this made our first 2 Solar Systems a bit samey, and not stand sufficiently enough out against one another.
...to take steps towards addressing this, we started with mood boards and ideas to look at together (our creative director Daniel, game designer Laurids and other artist Anders).

[h2]Some of the mood boards we used for inspiration[/h2]

"Frozen in Ice" Mood Board

"Ice and Snow" Mood Board

"Ice Asteroid Fields" Mood Board

[h2]And some shading, materials and color palettes[/h2]




Even though we had a lot of things we really wanted put in there (...like creatures frozen in gigantic ice blocks etc. etc.), we also had to approach it from a production point of view.

Meaning... we had to put all those ideas and dicide what could be done, within our time scope.
And, in addition to consider performance, to avoid doing things that were too performance costly.
...plus make sure things that were doable in regards to collision work and the like.
We ended up choosing what we called "Iceblock Asteroids".

First step
In Blender, I started by modeling some of these Iceblock asteroids.
Once established, I could use that work to create even more iceblock asteroids by combining, twisting, turning, scaling and merging together.
This to create more shape variations and different sizes.

Here are some screenshots from blender:



Second step
Next thing is to give the assets some textures, representing our icy theme for Temperance.
...this is also why I posted an image of grey shaded asteroids (because up untill that point, this was basically what I was looking at).
So into Substance Painter they went (one of our texture creation softwares we use at Hutlihut Games).



Stuff like BG planets and ice stalagmites was also created for making a more varied palette of level design.



Third step
Once we created all the elements/assets we wanted into Temperance, we could go into Unity and start creating the different sectors themselves. In close alignment with our game designer Laurids, we co-created these levels/sectors, that you as Void Crew players get to experience.

A lot of trial and error goes into this: setting up a sector, each with as much of its own identity as possible with the assets at hand, with all the gameplay logic that goes in and the missions for the different sectors in mind.

Testing ingame -> adjusting -> testing ingame -> adjusting etc!



Things like the spacey background consists of different layers of 3D geometry planes with nebula & space clouds, fog and other space-like elements applied as textures.



On top of all that, we have different effects:
  • non static icy clouds,
  • space derbris clusters,
  • small space particles,
  • and so forth.


And of course, each sector has its own source of light:
- a sun, with its own identity and other planets around it. This to give greater impression of being in a specific Solar System.




Making a first encounter environment in a game is not without its own set of challenges.
Temperance sets the tone of the other biomes you unlock, as you as player progress through the game.

[h3]Working in huge sizes, large distances, etc[/h3]
We have to fake the feeling of being in space. Everything is in relation to a human sized character, but we cannot have real space travel distances, real size relations to planets, asteroids, suns and all the gigantic things in space.

...so instead, everything we build have to be battle tested, to give the illusion of space objects being gigantic compared to the pov of the player and the player ship. Meaning, you have to be able to travel from one end of the map to the other, without spending days in travel time,
(...well after all, light travel speed is a whole other element in the game compared to pace of missions).

Large scale assets require high resolution to be believable. So, standing next to a mountain sized asteroid can’t be with a pixelated surface. The flipside of many large resolution textures are performance cost. To address this, we have different layers of details and maps (to prevent the immersive breaking experience). Noooot something we could nail on the first try ;-)

[h3]Make different biomes stand out from each other[/h3]
Even though we had an array of different ice type assets to build from, one can quickly start to repeat the patterns of level building.

So we have worked on how to find ways of making each sector have it’s own feel and identity (even though there is of course still, a red lining between them and repetitiveness in the reuse of assets).

[h3]Making/building points of interest[/h3]
A huge iceblock asteroid in center of the sector surrounded by smaller asteroids could be one solution. A top and a bottom layer of asteroids combined with icy stalagmites, encapsulating the players in the middle could be another.

[h3]Randomness[/h3]
Coming up with systems and tools to put in randomness of enemies and players spawning points, wreck spawning and so forth, without spawning dead in the middle of a huge asteroid was also something we had a bit back and forth in doing.

[h3]Sense of direction[/h3]
We also ended up putting in color gradients in background of our Solar Systems, because we often ended up losing our sense of direction when the background felt the same turning 360 degrees around one self ingame. So having some sort of background indication of what is front and back, north and south or something similar added a clearer overview of where we came from and where we were going.



Generally speaking, our main challenge was finding and setting the tone of a space and sci fi co-op journey. We knew we had to make ONE Solar System work first, before working on more Solar Systems.

Making them feel alive with VFX and particles, putting foreground, middleground and background elements in, in the right order to give the feeling of vastness. Temperance was the Solar System to pave the way for the others that came after, and for the ones we want to create in the future.

Thanks for reading my thoughts and experiences, ectypes. If you want to know more, we often share small art sneak peeks on our Discord server!

---
Please continue to provide us with your feedback, it is an important part of us keep improving Void Crew.

Wish you all lots of aaalways be scooping co-op fun,
// Kristoffer (Senior 3D Artist) and Hutlihut Games Crew

---




Void Crew - Patch (0.23.2)



[h3]Build 0.23.2 is live, which fixes the following issues:[/h3]

  • Cannot insert carriables into sockets (several issues). Read more about the issues and solution in our recent "Hutlihut - Space Log #1: Carryable rework".
  • Patterns get unapplied when launching a mission or going back to the main menu

Thanks again to our community for helping us iron these out!
The journey continues ... (including more bugfixing ...)

Dev Stream #5 - Highlights

Hello, my ectypes!

As every Friday (every 2 weeks, that is!), we bring you the 10 minute highlight video with the best moments from our Dev Stream.

This week we decided to be greedy, and focus on constructing as many scoops as possible and maximizing loot. Just to see how far we could go. It was super fun, hope you enjoy watching it!

[previewyoutube][/previewyoutube]

If you'd prefer to watch the full stream, that's also available on your Youtube channel:
https://www.youtube.com/watch?v=BnFNGiisqJY