Blogs - mobilelast

As mentioned earlier, expect numerous visual enhancements now that all graphical tools are running smoothly. Let's begin with one aspect that has particularly bothered me: the puffy clouds that were supposed to be thruster flames.

I created a basic half-sphere to serve as the model for the flame, allowing thrust power to be indicated simply by scaling it. The flame's appearance is achieved through a shader. Initially uncertain of the desired outcome, I experimented with smooth noises, Fresnel nodes, and other elements until I achieved a satisfactory result, especially when viewed from a distance.

And there you have it. While it may not be a contender for any beauty contests, at least the thrust direction is now clearer.

A closeup:

From a distance:

I’ve dreaded the transition of the project to a new device, fearing it would be a frustrating ordeal since I don’t store binaries to a version control. However, my computer's incessant noise finally spurred me to upgrade it. Much to my surprise, the process was completed in a mere 15 minutes or so.

The Unity upgrade from 2022.3.2f1 to 2022.3.21f1, on the other hand, didn’t go as smoothly. VFX graph effects exhibited numerous glitches, accompanied by "empty subgraph block" and "empty subgraph operator" errors, likely stemming from serialization issues. Fortunately I’m not that much into fancy effects, since I had to fix all of them manually. Despite this hiccup, overall functionality remained relatively smooth, although there may still be lingering undetected issues.

Now that I can effortlessly run Unity, Visual Studio, Blender, Substance Painter, and manage dozens of browser tabs simultaneously, expect some visual changes that I'll detail in upcoming posts.

How time flies...

As you might guess, I have distanced myself a little from ATP recently and delved into various other interests. These include all kinds of procedural stuff, water effects, volumetric lights and terrains, JPS-pathfinding, inverse kinematics, genetic algorithms, and more. I've also initiated a couple of new projects that I look forward to sharing more details about in the near future.

I'm finding myself a bit short on fresh ideas for ATP as well. My primary objective for this year is to polish the game as ready as it can be; while I'm open to any suggestions during this phase, my focus will predominantly be on refining existing elements. So I’m not quite done yet, but my posts will probably be more sporadic in the future.

But most importantly, I added a shockwave effect to enhance the ship's destruction:

During the last, unfortunately busy weeks, I’ve been continuing where I last left: improving the trigonometry behind the behavior and refactoring the logic. In the process, I also thoroughly tested almost all AI behaviors. A tedious job, but a boring person that I am, I found it rather interesting.

Here’s a little summary:

• I made improvements and optimizations to obstacles (meteors, team mates) and weapon dodging. At the same time, I fixed a bug related to collision layers, that caused the AI not to detect nor dodge incoming lasers properly. Funny, I hadn’t noticed that earlier.
• Combatants have handedness which dictates the direction they prefer in even situations.
• Fight-or-flight behavior in critical situations is more adjustable. Also, other characteristics are now less dependent on each other, which makes them easier to tweak in the future.
• There is some inexplicable wizardry going on in tractor and pressor beam handling. I have no idea what I’ve been after with it, but since the AI is already quite competent with beams, I decided not to mess with it too much.

Only the two most difficult things are still to be done: movement and plasma orb handling. More about those later.

And in order to avoid another tell-don’t-show -post, here’s an image that introduces the new tractor and pressor beams. Direction of the beam should now be clearly visible.

Programming NPC AI is rewarding once you get into it; you never get tired of losing your own creation. On the downside, developing and testing requires lots of hard debugging as well as complicated play/cheat modes that take time to set up. Therefore I usually concentrate on AI for longer periods at once. Such as the last two weeks.

In addition to countless tweaks and fixes, there are several new features and improvements. AI players …

• are more consistent when estimating enemies strengths and weaknesses.
• are better at keeping safe distance to ships with more close-combat power.
• can target vulnerable ships from a greater distance, not necessarily concentrate on the closest one anymore.
• are able to detect if their cockpit is exposed to enemies. If so, they try to turn around to cover it.
• dodge teammates better and can coordinate targets during the team play.
• don’t waste their most precious weapons on harmless targets during tournaments (assuming they can move or enemies are within the reach of their cannons).
• are aware when they’re surrounded by enemies, and will escape the situation accordingly. This will take some refining, since there’s a danger that they get too careful and waste all the time escaping.
• perform silly things due to numerous bugs. So nothing new there.

All AI skills and characteristics are configurable. According to my plans, the next version introduces nine opponents in three different tiers, each having their own personal fighting style. I still need a set of portraits, new player selection GUI and all kinds of visual things that are not my strength. Slowly but steadily...

What an interesting Unity-week... Certainly not the first controversial decision they make, but since it doesn't directly affect ATP, I'll see how things progress and perhaps return to the subject later.

Meanwhile, it’s time to once again introduce something completely meaningless with absolutely no effect on the gameplay: Mauno, the flying mediacube, who so far has entertained the audience with error screens and static, is now capable of showing videos. Its favorite subject are clips about the old ATP versions.

I haven’t figured out what Mauno’s displays are supposed to be. They’re really neither film projectors or TV screens; perhaps some kind of weird film-TV screens or something. But it doesn’t matter: as I’m after the early 1900’s style, I added a vignette film grain to the videos by loosely following the ideas presented in this great article.

Videos are rendered to texture by using Unity’s VideoPlayer-component, which is surprisingly straightforward to use. There are some potential compatibility issues with certain platforms. Importing video clips by using VD8 encoding should maximize compatibility, but I have to do some testing on this, especially on Linux.

Beside numerous bugs, Avaruustaistelupeli is filled with weird game-overs that are logical under the hood, but the logic is hard to figure out. Lots of them can only be detected by carefully watching videos of the battles. I have already added some statistics to clarify things, but obviously it is not enough.

A very common mishap happens when players launch projectiles at high rate. Projectiles often collide and explode upon the ship that launched them, which causes heavy collateral damage to modules in their vicinity. Explosions near the cockpit may end the battle abruptly.

Players are now given an opportunity to make projectiles trigger only when they leave the ship’s bounding area. Untriggered ones won’t explode on collisions, only disappear. A dust cloud with a loud clang indicates the collision and lessens confusion on vanishing projectiles. The new mode should make the fighting more careless. As AI pilots are already rather careful with projectiles, this doesn’t affect their behavior.

Another similar case are mishaps with energy overflow, but I’m pretty clueless what to do with them. Experimenting with the subject has already taken too much time, so, in order to keep a steadier posting rate, I will probably do something else first.

As I expected, there has been little time for ATP this summer. Besides the normal boring vacation and day-job things, I took my precious time to prototype a new concept that I will tell more about in the future (once I figure out what I’m actually doing). It has nothing to do with ATP, but lots to do with Unity's SRP-features and other advanced, new, poorly documented stuff.

Although not practicing any serious development, I did try to make the game moodier and more lively, adding funny little details with no gameplay value whatsoever. For instance there are now dozens of 1910's t-model spaceships flying behind menus; spectators have to arrive somehow. As you can see, their ships are much more maneuverable than the ships used in battles. Arena also has lots more parking space than one would believe

Animations are done by using Unity’s new splines-library. There is one entrance for each side of the arena, totaling six. To save time, I created several alternative splines for one entrance (within SplineContainer-object), and copied the bunch to five others. Ships select their route randomly, and they are animated by evaluating along the selected spline in the code. To introduce more diversity, I incorporated individual variations using Perlin noise and curve tangents.

I found the spline editor GUI to be somewhat awkward to use, and (unlike the spline node visualization implies) Unity seems to ignore the spline object’s world transform. As spline containers for each entrance differ by rotation, I had to do the transforming manually in this manner (feel free to comment if I’ve missed something):

var root = objectWhereTheSplineContainerResides.transform;
var position = root.TransformPoint(spline.EvaluatePosition(time));
var forward = root.TransformDirection(spline.EvaluateTangent(time));

But that’s enough cosmetics for now; there are some real features I need to implement too. AI is already somewhat able to operate shredders, but it still has plenty of tricks to learn. Some improvements to gameplay mechanics are also on my TODO list. So in the following posts, I’ll be returning to the more meaningful stuff.

There, I added a brand new module type, the Shredder. It’s the first new module for over a year, so re-learning modeling and texturing process was quite a job. Softwares tends to change drastically in that time, but as my Substance license only covers the 2021 version, I was able to proceed with the old version; I like to consider myself lucky.

Shredders deal massive damage to all objects within their reach. They are efficient when ramming into enemy ships, and can also clear obstacles from the way. My goal is to make them emphasize movement: the ship's body can now be used as a weapon, and one must also be ready to escape the enemy blades. Other movement-related modifications and additions are also under way. Mines should also be more useful now, as they seem like a feasible way to battle against the shredders. Here’s a clip about shredders in action:

Functionality itself was pretty straightforward to implement, basically an overlap cast and damage to nearest enemy or neutral objects. With a little twist, of course: blades don’t stop immediately, but decelerate over time, which makes them potentially dangerous even when detached.

The only thing left is the hardest part: AI. As shredders require advanced movement handling, I will probably implement that as a part of the larger AI overhaul in the near future.

I updated Unity to the latest LTS version 2022.3, and was pleasantly surprised how few issues there were.

• Console warnings started appearing here and there, but none of them seem to affect the functionality. These kinds of messages are common after major Unity updates; they are usually fixed in the following versions.
• Some prefabs have changed in strange ways. For instance, a few disabled gameobjects became enabled and vice versa. Easy to fix, but sometimes hard to detect.
• Colors seem clearer and deeper at some points, perhaps due to changes in post processing algorithms.
• Force fields (that use custom shaders) became much brighter than before, and didn’t look correct anymore. I rewrote the whole shader, and now they look better than before. Other shaders haven’t changed.

The newest URP should support LOD crossfade, but I ended up having nothing but an error “Instancing: Property 'unity_LODFade' shares the same constant buffer offset with 'unity_RenderingLayer'. Ignoring.” Probably a compilation problem; maybe I should update Visual Studio as well.

My interest in LOD transitions is related to a new module type which I will tell more about in the near future. Time to re-learn Blender after a short break.