Graphics Grindstone

Noses have been down to the grindstone for awhile now. I saw a timestamp this morning on the swan model's export file that read "January 22nd 2021". So it's been like... over two years since the graphical experimenting began?

typical turn visual example of two ships not hitting eachother because they take turns

Steady Pacing

As with most self-guided learning, the process can be slow. You bump your knees on almost every corner and aren't always sure what parts of your wild imagination is feasible or even possible. Fortunately the learnings from banging knees have been both rewarding and enjoyable.

There are many considerations when deciding to support unit customization in a game. This customization problem amplifies beyond what I could have anticipated after also "bolting on" full graphical mod support. This is where the complex troubles started.

Stubbornness...

If I could settle for static units with fixed upgrades (like Starcraft), then this would be a cakewalk compared to the current gauntlet! Unfortunately, I cannot accept anything less than the flexible customization envisioned!

The tall order of what is meant by "flexible" is as follows:

✓ Player may customize colors for all ships, components, projectiles.
✓ Components should alter how a ship performs statistically.
✓ Components should alter how a ship "feels" visually, not reuse/recolor the same model.
✓ Components need to be visually attachable to the correct ship slot locations.
✓ Component and ship animations should synchronize when available.
✓ Weapon components should have glamorous camera angles and dramatic glitter.
(in-progress) Each component and ship should have a digital card representation for menus.
Every component should have dope destruction animations.
Player's should be able to easily mod components with simple file changes.
Player's should be able to easily mod/swap component animations with file changes.

(in-progress) Component's graphical prefab interfaces should be generic for each respective type, enabling predictable swapping logic at runtime.

✓ Armor.
✓ Engine.
(in-progress) Weapons.
Gyroscope.
Gizmo.
Characters?

Mostly done on my machine

I take some heart after looking at this list. It's been the same list for over two years now, and it is indeed getting shorter.

At this point, we can model a ship with some serious effort, then attach any existing weapons and engines to it (armor has to be 100% custom per ship due to the unique shapes). We've been able to do this on the serverside for awhile, but now the clientside can express these customizations visually with all it's animated glory!

Two mod systems

I need to be crystal clear about how this game is architected in order to explain why there are two modding systems. Steelpinion has a custom headless engine which is purely data oriented with solvers and publishable events. The modding mentioned in Article #9 is capable of editing behavior within the meat of this engine. That modding system is already done and we are "eating our own dogfood" there (meaning I am using it to build to game).

Another kind of modding unrelated to statistical balance is graphical mods. This is purely altering visual clientside assets usually swapping or overriding the originals. So when I talk about graphical mods being on the chopping block, you know precisely what kind of mods I speak of.

The Chopping Block

I decided to cut some two graphical mod support features due to limits in Unity's runtime. I badly want to allow players to just drop in models and animations to override runtime files, but this isn't going to work for the complex setup.

Since I can't perform shader compilation at runtime, nor reliably parse model data at runtime; this hampers my desires to make drop-in file based graphical replacements a reality.

Yes there are guides which show that sort of thing is possible. However, all those online tutorial cases are very simple. We have complex systems interacting here to achieve the aforementioned dynamic placement, animation synchronization, and in-game customizations.

So it'll take far too much time to build around the limits in unity runtime for drop-in file mods... At this point, I don't see any other way to easily achieve graphical mods without just flat exposing the clientside source.

Bottom of the barrel

3D Characters will make a return to the list, but are going to have to wait for other more critical functionality first. Sadly, it is just very time consuming to make stylized models representative of Mike's wonderful character concept art at my current skill level. Someday this too will be improved and tackled!

While its relatively easy to make shatter destruction animations for all the components. I was thinking I'd like to give it a little more thought first. Since intense flame can destroy components and is (I think) the primary way components break; it may make more sense to create a melting animation and a sabotaged animation.

I'll need to play the game more and mess around with it's niche side effects a bit more before deciding to make all these additional animations for components first. This too will come later on in the project.

What's Next

Not sure really what next month will bring. I suppose we are in a graphical update mode and will be for awhile now. Perhaps we'll be in some kind of cadence showing off new component graphics with a card explaining their unique effects.