Hi all,
Regret to announce yet another delay for 0.2. Pushing it back to early 2024, as these short-term deadlines clearly aren't working out.
What is taking so long?
Development right now is very much in the stage of reimplementing old features after switching-out the core of the game. There's been quite a few features built up over time and the core changes have been big enough that these reimplementations effectively become rewrites.
The main problem with my deadline predications is that these rewrites often reveal long-term beneficial core changes. From there I can choose to either make the core changes, or continue reimplementing without them, to get the update ready in time. I am, of course, picking the long-term over the hacky short-term every time. The core changes then bring about more reimplementations for already reimplemented features, becoming a sort of improvement loop.
The game's been in this loop of improvement for a few months now and is just starting to show signs of running out of improvements.
There's not a whole lot to show since last progress update, aside from the benefits of the reimplementation rewrites.
Part repositioning
Parts repositioning now supports reorientating
It should also be a little less unpredictable now with compartment changes.
Sloped return rollers
The track rewrite allows return rollers to be slanted. This one was long overdue!
Multiple paint jobs
The plan is to move away from the placeholder hologram models to fully textured physical parts. Not only will this keep more in theme with the game's theme, it'll also be necessary once vehicles can be opened up and have open turrets etc. One issue will be the added complexity of the textures cluttering the interior and making it hard to find what you'd like to edit.
Having the whole vehicle painted with a single paint job was an issue with the new internals. Internal parts were being painted with the external camouflage, which wasn't helping the aforementioned 'difficult to find' problem...
The planned fix is to keep the colour coding, only it'll now be applied to the paint job of the internal.
Vehicles now support multiple paint jobs at once, assigned to each part individually. This allows internal parts groups to be colour coded via their assigned paint job. Control over paint job assignment wont be accessible to the player initially, except through editing design files.
Paint job tinting
Paint job hue shifting has been replaced with colour tinting, with control over the red, green and blue channels. This can later be expanded to a colour hex code and colour wheel.
Undo/redo rewrite
Again, a reimplementation which turned into a rewrite. There's nothing worse than an unreliable history system, so this was a big one planned for the refinement period. The whole system has been revised and should be much more reliable in V0.2.
Belt collision models
Due to the new select and edit focus of the designer, track belts must now be selected to edit them. A dedicated model of the belt is required to detect when the player's pointer is over the belt. Due to the generated nature of the track belt, this model needs to be generated as well.
This model generation also happened to be the main task required for the biggest potential game optimization on the list.
Games most commonly render tracks by dragging a texture over a stationary belt model to create the illusion of a moving belt. This, as an option, could give back dozens of frames per second compared to Sprocket's current technique.
The current processor intensive parts being:
- Moving each segment in the track, every frame. Though this is actually done quite quickly thanks to some data orientated programming, which CPUs love.
- A box each segment takes up in the world is calculated every frame (with expensive maths), used to tell whether a segment is on screen and should be rendered. This is multi-threaded well but is another punch to PCs with lower end CPUs. It'd obviously be far more efficient to calculate a single box of all segments, though unfortunately, it's an engine constraint.
- Finally, the cost to render each triangle on each segment, up to 400 per segment at the highest quality. Hence why track belts in Sprocket currently make up about half of all triangles used to render a vehicle.
Those pretty tracks have a price!
This stationary belt model, on the other hand, calculates a single box in the world to know when on screen, has the triangles of a single high quality segment and the moving of the segment texture is done entirely on the GPU! Physics costs stay the same.
So this option should give those with lower end GPUs a significant boost. While higher end GPUs can benefit from far away vehicle tracks being rendered with this technique, instead of completely disabling them as currently done.
This optimization will come as soon as 0.2 is stable.
Again, sorry for any disappointment and thank you for your continued patience!
Ok - back to work
- Hamish