next »

[mobilelast]

Despite the slow start, this week ended up pretty productive. I started designing and implementing a new audio background which has no direct effect on the gameplay, but which definitely adds mood.

Below is an audio clip from the ship selection, player introduction, countdown and battle. I’ve found it useful to sometimes only listen to the game without any visual distractions. Audience ambience needs more variation and some elements are clearly out of balance, but I’d call this a good start. Audio already reacts to the game events: players and destroyed ships are cheered, boring gameplay gets booed, mishaps cause laughter etc.

https://soundcloud.com/ludovic_petunia/atp-audioclip-2872022

Most of the ambiences and effects are taken (and usually further modified) from two asset packs: Ultimate Sound FX Bundle and Universal Sound FX. As variety is the key for a vivid audio background and most sounds have to have several variations to randomly choose from, those two fit to my needs.

Some sounds I recorded myself. Announcements are inspired by the train station scene of “Les Vacances de Monsieur Hulot”, and, of course, you can’t have a proper space game without organ music. I haven’t really been playing for ages, so it was fun to improvise.

Beside this audio thing, I’ve made lots of miscellaneous fixes, improvements and balancing as well as taken some time to experiment with Unity’s baked lighting and multi-scene workflow. Both are pretty unknown stuff to me, but they should be the best way to make arena stands fancier. So lots more about that later.

[mobilelast]

Recently I’ve been mostly doing smallish things that don’t deserve their own devlog entries. So here’s a little overview of the miscellaneous incoming fixes and improvements.

- Leaving battles and other screens when there’s only AI players left has been awkward. From now on, force exit is no longer needed, but any button (keyboard or controller) should do the trick.
- AI doesn’t shoot all over anymore when it’s rushing into its target. This odd behavior was caused by multiple factors that were hard to find.
- Cannons get weaker as the shields are on. Not only does this suit the (still unpublished) lore, but it also forces the player to choose between attack and defense.
- Cutters are less powerful than they were before. On the other hand, AI is now quite able to use them to defend itself against projectiles.

- Non-homing missiles are now little more efficient than homing ones. Efficiency increases as missiles accelerate, so shots from a long distance are encouraged.

[mobilelast]

I've been experimenting with Unity's baked lighting, which sure is a slow and confusing task. There’s still lots to do and learn, so more news will follow in the near future.

As this devlog has been quite non-visual, I just want to share this small example of the new arena lighting. Doesn't it look moody? Not something you would expect from a sci-fi game, and definitely not something I was after.

[mobilelast]

Allright, time for part two of my lighting adventures. As my so-called workflow consists mainly of trials and errors, explaining it is quite hard. But I’ll try to give a shallow explanation.

As I implied in a previous post, I found stadiums to be a good candidate for baked lighting since they are pretty much the only static parts in the game. Stadiums come in three sizes, and each one of them must have two variations: one with lights on (used during ship selection and results screens) and one only lit by the sun (used during the battle). Below are some images of the current models, lights on and off.







Before the actual lighting, I was forced to do some serious refactoring. My lights and light settings were all over the place, and some directional lights were already on baked mode; I have no idea how they were even working. So for starters, I corrected the light types, got rid of some obsolete light sources and renamed all objects appropriately in order to utilize Unity’s light explorer.

The stadium models took some refining also. I try to stick with the WW1-style, and 1910s stadiums were rough places. But still, to meet even the most rudimentary safety standards, I was forced to add handrails as well as green lights to show the exit. And of course I had to add the lights themselves to the ceiling and inside the boxes.

As far as I know (and correct me if I’m wrong), Unity can only bake one set of light maps per scene. This forced me to abandon the earlier stadium prefabs and start using a multi-scene workflow. It’s a good time for practicing: if there were others working with the project, the multi-scene approach would be practically mandatory. I created six new scenes: light and dark variations for each three arenas. These can now be loaded additively when the background arena is needed in other scenes.

Adjusting shadow map resolutions was pretty time consuming at start, but I managed to figure out a straightforward workflow. I start by ramping up the lightmap resolution in lighting settings until the most visible and important geometry is accurate enough. Then I reduce the “scale in lightmap” -values (found in the MeshRenderer component) of the other models as low as possible within the required accuracy. With filtering on, the resolutions can be kept surprisingly low, which reduces the baking time. Below is the image of the light maps I’m currently using.



Another tricky task was to set up the light probes for the dynamic objects (there will be spectators at some point, after all). Unity’s own tools are quite bad especially for placing the probes in circular forms. I ended up making a helper editor script and placing probes procedurally. End result works surprisingly well. Image below shows the probe positions.



And here’s how they lit the placeholder spectators in light and dark arenas.



I’m already pretty pleased with the small arena, which was the first one I did; I still need to do the same things for medium and large stadiums. Luckily, most parts of the larger stadiums are just scaled (or pulled/pushed in Blender) versions of the small one, so they share the same textures and UV-mappings. This means that all arenas use the same materials, and there shouldn’t be much work left after the small stadium is perfected.

The real challenge is to animate the crowd. Regular skinned animation is way too slow for thousands of meshes, so all kinds of GPU trickery will be needed. More about it later.

[mobilelast]

The stadium is almost ready for the audience, but unfortunately large crowds have a negative effect on performance. This is mainly due to two reasons: having a skeleton hierarchy for each spectator results in a huge number of dynamic game objects, and Unity’s batching doesn’t support skinned meshes. These cause a massive CPU load to deal with.

Solution is to animate meshes on GPU (in shaders), and use the batchable MeshRenderer instead of its skinned variation. Unity doesn’t have a built-in tool for this, so I made one myself. I wrote a rough editor script that reads vertex positions of skinned mesh on each frame and stores them into a texture. A custom shader then repositions vertices in run-time by reading the positions from that texture.

As I used a shader graph and my baker utility class is very specialized for my needs, it is hard to share any useful code just yet. But if you’re interested, I found this article and this repository useful.

As a starting point, function AnimationClip.SampleAnimation sets the mesh into a proper pose at a given time, and SkinnedMeshRenderer.BakeMesh can be used to extract the mesh data at that moment. In the shader, the vertex index is stored in the built-in variable vertexID. An interesting finding is that if you store each keyframe on a separate texture row, bilinear filtering will automatically handle the animation blending (see the article linked above).

Resizing the texture to power-of-two (not necessarily required in desktop development) was a surprisingly complex job that required an external render texture (or I’ve just missed some too obvious utility function). Here’s what I’m doing for texture scaling (note the texture format that is needed for storing negative values with decent precision):

Code:

public static void ResizeTexture(Texture2D pTexture, int pWidth, int pHeight) {
    var rt = RenderTexture.GetTemporary(pWidth, pHeight, 0, RenderTextureFormat.ARGBHalf, RenderTextureReadWrite.Default);
    RenderTexture.active = rt;
    Graphics.Blit(pTexture, rt);
    pTexture.Reinitialize(pWidth, pHeight, TextureFormat.RGBAHalf, false);
    pTexture.filterMode = FilterMode.Bilinear;
    pTexture.ReadPixels(new Rect(0f, 0f, pWidth, pHeight), 0, 0);
    pTexture.Apply();
    RenderTexture.ReleaseTemporary(rt);
}

In the end, animation baking wasn’t nearly as complex as I feared, but resulted in some hilarious glitches. During the first attempts, models distorted heavily and made the audience look like a horde of lovecraftian monsters; unfortunately I didn't record a video of it. Of course there’s still lots to do. Instead of repeating identical gestures, each spectator needs individual variation, so blending of different animations at different speeds per individual is required; this will probably introduce some batching issues. I also need to bake normals and tangents and resolve smaller issues with camera frustum culling (probably related to AABB calculation). But at least I now have a solid base to build on, already able to run thousands of animated spectators without a noticeable FPS drop.



I could make a lengthy blog post about the subject. Perhaps I will at some point. Writing about the process seems to be slower than the actual implementation, so hopefully someone finds these helpful.

Besides the GPU magic I’ve also improved the background of the shipyard, experimented with GUI design and ACES tone mapping (I have to boost up all those baked lights…) etc. I’ll come back to those in the upcoming posts.

[mobilelast]

I had a little flu, so last week wasn’t very good for anything that requires thinking.

So, I did a few boring jobs that just had to be done: created larger arena models by scaling the smallest one, and completely re-organized the binaries, prefabs and materials in my project hierarchy; hopefully it will be easier to actually find something in the future. It was also a good time to refactor cameras and fool around with post-processing.

I’ve always thought that the appearance of the game needs deeper contrasts, and the emissive lights should be brought up more without interfering with the old, industrial look. I decided to switch the neutral tone mapping to ACES, as it should give better contrast and more room for adjustments. It tends to make the overall image darker, so I brightened up the lights and re-baked static shadows. I also added a secondary directional light to the battle scene in order to bring out the meteors and other areas shadowed by the sun (proper ambient lighting might do the same trick, but I wasn’t able to make it look as good). ACES boosts saturation, so I brought it down a little in a color grading. It is hard to see objectively if the changes are for the better or worse; I have to organize a game testing workshop to see if the brightness is OK and colors can be clearly seen.





The only problem I came across was that Unity’s post processing always sets alpha values to one. This prevents transparency, which in turn causes problems when rendering ships to GUI widgets by using render textures. A custom shader is probably needed.

This will naturally lead me into the next task: improving UI graphics. Admittedly, I only have a vague idea of what I’m after, but let’s see where it goes.

[mobilelast]

The game (and especially the screenshots) seem too dark. So although it is hard to get the brightness right objectively, I changed the ambient color to light gray and increased light intensities. I deliberately set the scene to be overly lit, as it is easier to reduce the brightness in post processing than increase it.

As lighting affects how the different material layers work, I had to adjust them a little. I spent a good while re-organizing materials in order to easily export textures from Substance and test them in Unity. And after a few curse words, I managed to bake brighter versions of all arenas.



I also improved and replaced many of the particle effects. New explosions and smoke are already looking quite neat. As I’ve never liked Unity’s particle system editor, I will probably be using only VFX graphs in the future.





Unfortunately my ambitious GUI experiments weren’t as successful. I have to take another approach and see where it goes.

But next I will have to fix some problems with the game controller handling in order to arrange testing workshops. More about those in the next post. Test sessions usually reveal a ton of gameplay-related bugs, so I can then put graphics aside for a while.

[mobilelast]

Controller issues are much more complex than I expected, I seem to find two new problems for every fixed one. Frustratingly, it seems that each time I update Unity’s input system to a newer version, something gets broken. Here’s a quick summary of things I’ve dealt with during the past two weeks.

Composite keyboard controls (WASD) stopped working when I updated Unity and its input system after the previous release (to Unity 2021.3.4f1 and input system 1.3.0, if I interpret the version history correctly). In case someone experiences the same, I had to set the control to “pass through” in order to make it work.


Similarly, the controller's shoulder (or bumper, whichever you prefer) buttons didn’t work anymore in battles. In GUI they do work. Pass through -trick didn’t work here, so finally I just downgraded the input system to 1.1.0, which fixed the issue.

Gamepad scrolling in the shipyard didn’t work after the latest ATP release either. Even downgrading the input system doesn’t fix this, which has left me clueless. It seems that my virtual mouse implementation (the code I posted almost a year ago) causes conflicts between the actual system mouse and events I send. This aborts dragging prematurely. I actually got the dragging work by creating a virtual mouse device instead of calling system mouse directly, but now I’m unable to use gamepad and mouse simultaneously, which makes this solution useless for me (Unity’s reference implementation has the same limitation). Enabling/disabling the virtual mouse depending on the last used device might work. I’ll try that at some point.

As this wasn't enough, there were problems with the hardware as well. Crosshair jumped strangely when controlled by the gamepad's joystick, and I spent several hours adjusting dead zones, filtering noise etc. without effect. After a while, I started getting suspicious and tried another controller. Everything worked fine. https://gamepad-tester.com/ proves that the issue really is in the controller:


I don’t feel like fighting with controls right now, so I will probably just implement the common controller navigation to the menus (which was on my TODO list anyway), and use virtual mouse only in the shipyard (if I get it to work). Mouse is practically mandatory in the shipyard, so I won’t be prioritizing this very high.

But it’s not all work without fun. Our first spectator invited his brothers to cheer me up (or mock me, decide yourself). More about the crowd in the future posts.

[mobilelast]

More and more spectators are coming in. And although there’s still room for optimizations, I haven’t noticed a remarkable performance drop even with full stands. It is hard to describe the technical process without being boring, but I’ll try. I may also share the baking utility and shader at some point, if I find time to clean it up and replace the ugly hard-coded parts.

I started by modeling an extremely low-poly spectator in Blender, then creating several different suit textures for it in Substance; colors accurately match the men’s fashion during the 1910s. Women’s clothing from that era is much harder to model, so unfortunately women are only allowed in trousers and fake mustaches for now.


Next I imported the model into Mixamo, rigged it, and exported all sorts of animation clips that spectators might do.


In Unity I wrote a utility script that bakes clips into one sequence, and writes vertex positions and normals into textures. Extra variance is achieved by changing clip order. These textures are then given to the special shader that performs the mesh deforming in GPU.


Spectators may not look particularly handsome by themselves, but their strength is in numbers. Animation sequences and clothing textures can be joined freely in order to get an exponential number of combinations. It would be tedious to do this by hand, so I wrote another script that creates material for each cloth-animation-combination with varying tint and animation speed. Script also supports different models, allowing women, children, monsters or whatever I might model in the future. But that’s not my main priority right now. Here’s the current situation:





Besides this, I hosted test sessions during the last week. Those will be the subject of the next post. So something about the gameplay itself, for a change.

[mobilelast]

A delayed summary of our testing session on 28.10. There were surprisingly few issues, and AI-opponents were much more stable-minded and less suicidal than before. I collected some of the cooperative battles in a video.




Of course, there’s always room for improvement.

• Missile flame particles had distracting gaps, which can be constantly seen in videos. I managed to fix this by feeding the missile's world coordinates to both “Spawn Over Distance” and “Initialize Particle Strip” components in the VFX graph. Not sure if this is a proper way, though.
• Mine explosions caused a huge shock wave that threw ships around the arena and probably broke the collision detection (time 2:48 in video above). This was probably because of a typo: the explosion force was ten times too strong. But some kind of gravitation weapon might be a nice feature…
• Stalemate buoy appearance caused a confusing leap in camera focusing. Now the viewport should be tweened properly.

We also fought a grand, eight-ship tournament with two humans and two AI pilots. Here’s an uncut video of the tournament to demonstrate the game flow and different ship designs. You can skip the ship selection parts from bookmarks.

[mobilelast]

Some of the computer opponent’s stupidities have been bothering me for a long time. Although AI performs rather well in micro-level (aims quite accurately and even has some creativity with special modules), it completely lacks strategic thinking by taking stupid risks and wasting ammunition in harmless situations. The real challenge is, that AI should be less aggressive and suicidal, but not too careful. Otherwise battles tend to end up in a situation where AI refuses to do anything.

I made some improvements to make things better:

• AI is now better at calculating its close-combat strength relative to opponents, and taking advantage of it. It knows to keep the distance to stronger ships and rush towards weaker ones.
• Bonus objects aren’t prioritized as high as before. AI is less eager to reach them when the win is already on hand.
• AI has had a tendency to shoot bonus objects with cannons for no reason. I thought I had fixed this multiple times, but it always kept coming back. The final (hopefully) fix required a bigger refactoring to the AI architecture.

My AI code is divided into three parts that can be executed simultaneously: movement, cannons and special functions. The division is clear and works well, but better cooperation between the components is needed. For instance, the bonus object issue was because the AI first aimed cannons, but then tried to attract the bonus with a tractor beam. The latter behavior re-positioned the crosshair, which made cannons shoot in the wrong place. Luckily, shooting only takes one frame, so it was enough to tell secondary modules to hold on until the cannons are done. Once again, I consider this fixed. Expect to hear more about similar issues in the future.

I found it hard to visualize this subject, so here’s an unrelated picture of a drunken spectator about to fall down the stairs:

[mobilelast]

Because of the recurring problems with the virtual mouse, I updated most of the menus to be browsed with a controller; I omitted shipyard, since it practically requires a mouse anyway. uGUI’s automatic navigation covers most of the situations, but tends to fail in some places. Fortunately the menus are simple, and explicit navigation can be used to fix those situations. Still, disappearing selections and unstable navigation can be expected in the near future, but as everything ought to work with a mouse, none of those problems should be critical.

I will be updating the user interface’s graphics once I further refine the looks. As uGUI’s default color/sprite transitions won't suffice for my needs, I’ll be using callbacks (UnityEngine.EventSystems.IXxxHandler) to change the visual states of the widgets. At some point I will probably try Unity’s animation system for the transitions just to learn more about it.

Here’s an animation of the current gamepad usage. Player selection screen is quite cumbersome, but as I'm lacking a vision of how it should work, I probably don’t have time to re-implement it to the next version.


And oh, the problem with dysfunctional shoulder-buttons I complained several weeks ago was solved by calling

Code:

InputSystem.settings.SetInternalFeatureFlag("DISABLE_SHORTCUT_SUPPORT", true);

during the startup (this was mentioned in input system’s release notes). So if you happen to fight with non-responding buttons, this workaround might work.

[mobilelast]

There has been a minor issue that ship paralyzation (game over when all the energy sources are lost) isn’t clear enough. Besides a small info text, only a power-down voice has indicated it.

So I added this fancy lighting effect, boosted with a distorted sound of electrical failure. Hopefully they make paralyzation clearer.


Doing such an effect was surprisingly tiresome for the eyes. Luckily for the players, it usually appears shortly from a distance.


Besides this, I have extensively tested the game solo by relying solely on the gamepad. Apart from some minor issues, the controller navigation seems to be pretty flawless; must-have features for the next release start getting ready.

[mobilelast]

I’ve almost run out of trivial improvements, and all unfinished features seem rather large. I take this as a sign to start wrapping the version 0.5.2 up, and continue other tasks in the next release. I should probably learn to make releases more often. It’s just that my methods are quite experimental and ineffective, so definition-of-done can be rather unclear. I also spend too much time on small bugs, which causes me to miss many of the more important ones. More frequent test sessions would certainly help with this.

But let me summarize the current situation:

• GUI and controller navigation works rather well, although 0.5.2 will probably have some minor issues still.
• I’ve refactored GUI widget objects/code, and cleaned up their appearance a little. Graphics will be finalized later; now I should be able to concentrate on them instead of constantly tweaking the functionality.
• Multiplayer selection screen is usable yet cumbersome. I will redesign the layout for 0.5.3.
• AI has already improved a lot since 0.5.1, but personalized opponents are not ready. Each one will have a portrait that, with my graphical skills, takes most of the time.
• I have a vague idea of how to improve the tutorial. It may even make it to 0.5.2.
• The game currently takes 1.5 gigabytes of disk space (0.5GB compressed). It isn’t all that much nowadays, but almost half of it consists of light and shadow maps that, honestly, don’t even make things look that much better. I’ll rebake those; very low resolution should suffice for darker scenes.
  

Away from home, without access to my dev machine, I won’t be jamming the thread with GIFs this time.

Have a happy whatever you’re celebrating! And if nothing, be happy anyways.

[mobilelast]

While suffering from a nasty flu, I had time to further experiment with baked lighting. Light and shadow textures are deceptively large, and my aim was to reduce the build size from the current 1.5GB.

First I switched the lighting mode to "Baked Indirect" since I really didn't make any use of baked shadows. This alone dropped space requirements by a couple of hundred megabytes. Encouraged by this, I completely removed light maps from all dark arenas (small, medium and large; used during the battle), and increased ambient luminance instead. As you can see, the difference is practically nonexistent. The build size, on the other hand, went under 1GB.



Now there’s only one scene (lit arena behind the GUI) with baked textures. This speeds up the lighting process significantly, as I don’t have to deal with the other three anymore. Here are some images of the lit arena.







I sent the current dev version to several test players for quick feedback. Some bugs were found and fixed, but otherwise the game seems rather stable. GPU load has been increased somewhat, but it seems that 2GB NVIDIA GeForce MX150 is very capable of running the game, so nothing serious there.

[mobilelast]

I cleaned up my hard drive and bumped into a set of old ATP clips from early 2019 to late 2021. It took some time to get them in order, but I managed to edit a clumsy little history video with some extraneous organ music.





It was fun to look back and see how the graphics have evolved. I started as a complete beginner, long relying on placeholder cubes and spheres only. And though I’m still far from a pro, I’ve learned a lot. I’ve also managed to stay faithful to the game’s core idea; apart from a few renamed and abandoned module types, the ships from 2019 are fully compatible with the upcoming version.

In due course these clips will make good content for the floating media cube “Mauno”. I just have to be careful with video format compatibility between platforms.

[mobilelast]

I’ve had a busy week with ATP and, unfortunately, outside it. I organized two testing sessions with different sets of players; a typical social evening with beer, pizza and occasional gaming. Here’s a couple of videos and other things about the first one (which was held on 21.1.; don’t mind the erroneous date in videos). I’ll cover the other one in the near future.









The game seems to be coming together fine: no crashes or other oddities. All four gamepads were identified and handled successfully, and the new controller browsing is much smoother than virtual mouse. But of course, there’s always room for improvements.

“More stats, the better.” Statistics in the tournament ending screen seemed interesting, and more was wanted. I added cannon hit count and accuracy as well as the number of modules that were lost because of energy overflow; the last one hopefully clarifies the concept of energy also. I’ve tried to keep all stats on screen at once for all the players to read, but I probably have to rethink that as more stuff is added.


Ships were often overdrawn and hidden by crosshairs especially when shown from a distance. I added a setting to adjust the crosshair opacity; on a dark background, translucent crosshairs remain distinguishable, but interfere less.


Some testers hoped for random surprises such as black holes and other gravitational trickery, but some others weren’t keen on any extra chaos. These take a bit more thinking, and require a clear graphical representation also.

Preselected ship collections (similar to tournament fleets) could be user friendly in co-op-games, as now it is hard to find well balanced ships. Then again, my ship selection is cluttered with dozens of dev/test ships that are useless in battles, so this may not be a problem with others.

Smaller improvements to graphics and AI were noticed and suggested also. I will try to fix those in the next release during the spring.

[mobilelast]

Damn, it’s hard to get anything written when you keep finding new issues all the time. But here’s a sentence or two about small improvements I made right after the first test session.

I did some GPU profiling (which you should be doing constantly!) and noticed that one render line took almost two thirds of the processing time. The bad guy turned out to be the smoke under the arena, purely cosmetic, embarrassingly unoptimized. The effect uses lit particles, a relatively new feature in URP that looks nice in motion, but seems to be heavy for the GPU. I made the particles much fewer and larger, which improved the performance without any perceptible quality loss (image on the left below). Lower quality settings now use unlit particles (center), and it is also possible to turn off the smoke completely.



In very old computers, the difference between lit and unlit particles isn’t actually that big; GPU and translucency seem to be the bottleneck here. Without the smoke, everything works fine even on very old laptops.

I also noticed that another background particle effect, scrap, looked like crap as it was drawn on top of the smoke. I dropped its “Visual Effect” component’s “Order in Layer” -value (under “Additional Settings”) below the smoke, and now it blends in well.



And as always, the AI tends to abase its programmer more than it does the players. This time it wasted so many missiles on irrelevant obstacles that I had to command it to check if the trajectory was clear before shooting. The checking algorithm isn’t perfect, but certainly an improvement. The balancing seems like a constant challenge also: AI still tends to be either suicidally aggressive or overly passive.

Combats get sometimes too chaotic, which harms the gameplay by taking away the feel of control. A slight improvement was to increase cannon shooting interval from 1 to 1.5 seconds per cannon. This should emphasize accuracy and reduce the risk of tendonitis, hopefully also balance the overpowered close combat ship.

There have also been positive findings: the audience didn’t cause noticeable performance drop on any device, so I can let in even more spectators.

Next post will be about the second test session. With some new video footage.

EDIT: I brightened the images so you can actually see something.

[mobilelast]

Test session on 28.1.2023, three somewhat experienced players (including the developer), purpose to concentrate mainly on co-op-gaming. And this is what happened.

I prepared by temporarily removing all the test ships that cannot be battled with, making the ship selection much smoother. One participant had also done his homework and provided us with two highly suggestive ships, both completely worthless in battle.



Some usability issues were found in the player/controller selection and ship selection screens. In tournament mode, humans and AI players select their own ships, which is pretty straightforward, but in co-op and single-match battles, humans select AI ships also. Mouse users can pick a ship by just clicking, but gamepad users must first select an AI combatant with bumper buttons. There’s a help text to guide the users, but obviously the concept must be better communicated. The ship selection will be redone when I implement new AI opponents, but my intention is to keep the look and feel of old arcade game selections.



Once we made it through the menus and started playing, it became clear that the co-op opponent is too weak and probably needs a better default ship to stand against three humans. Translucent crosshair is definitely an improvement, though the energy bar still gets in the way; it was suggested that it could fade in as the energy consumption increases. It has to be visible enough to keep the players aware of the energy consumption, though. Some of the crosshair’s graphical elements seem unnecessary, so there’s still room to simplify it.





We ultimately ended up playing tournaments with an AI player to complete the quartet. This time there are two tournament videos: one with the best AI, and another with the worst one. In the latter, I successfully tried a very defensive approach to utilize some shallow strategic elements.





https://youtu.be/5PYu5bBHkeY

Low tempo isn’t a problem itself, it can even add suspense, but it can be boring to watch (just listen to the audience’s reactions). There was a suggestion that frustrated spectators would start throwing stuff at passive competitors thus damaging them and urging for action. An interesting idea, but I’m not sure I want to force the combatants to have a certain playing style.

These testers weren’t very interested in statistics, and gave zero appreciation to the information I had added since the previous session. But screw that, I’m going to add lots of them anyway. More varied statistics will actually serve a purpose with the mishaps and other unexpected events that regularly take place in the game.

So no spectacular failures this time. Lots of small adjustments, naturally, but those will be a story for another day.

[mobilelast]

My computer is starting to fall apart, which slows down things. Hopefully I get the version 0.5.2 out before I’m forced to get a new one. For the next release, there are plenty of small things going on that are harder to explain than fix. But fortunately something visual too.

I recently found a suitable asset to replace the previous placeholder lens flares: SRP Lens Flare, a free product in Unity’s asset store that is well worth advertising. With a little customization, I got pretty much what I was after, and now the sun and artificial lights look like they should.


There was also a glitch with the shadows. Hardly noticeable one, but irritating when found. Arena geometry that is never visible in the top-down view was culled from the battle camera by assigning it with a special layer. This geometry included the arena's outer walls. In Unity, only visible layers seem to cast shadows, which made sunlight leak to the arena (see left image below). Fixing was easy: just a change to the geometry's layer. But of course, larger shadows darkened the arena, which had to be compensated by increasing ambient light. Hopefully this doesn’t reintroduce the brightness balancing problems I used to have. Image on the right shows what the shadows should look like.


I also redesigned the crosshair and made it simpler, which I will tell more about in the future. And I created a Twitter-page! As I’ve never been much into social media, the next thing is to figure out what the heck I should do there...