Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1402811 Posts in 68130 Topics- by 61759 Members - Latest Member: Sterrnyyy

October 01, 2022, 06:52:00 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsAvaruustaistelupeli (ATP) - a space combat game
Pages: 1 2 [3]
Print
Author Topic: Avaruustaistelupeli (ATP) - a space combat game  (Read 5573 times)
mobilelast
Level 1
*


View Profile WWW
« Reply #40 on: July 29, 2022, 12:25:10 AM »

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.
Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
mobilelast
Level 1
*


View Profile WWW
« Reply #41 on: August 06, 2022, 02:54:54 AM »

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.

Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
mobilelast
Level 1
*


View Profile WWW
« Reply #42 on: August 16, 2022, 05:07:41 AM »

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.
Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
mobilelast
Level 1
*


View Profile WWW
« Reply #43 on: September 02, 2022, 02:31:08 AM »

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.
Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
mobilelast
Level 1
*


View Profile WWW
« Reply #44 on: September 17, 2022, 07:07:33 AM »

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.

Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
mobilelast
Level 1
*


View Profile WWW
« Reply #45 on: September 27, 2022, 12:24:53 PM »

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.
Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
Pages: 1 2 [3]
Print
Jump to:  

Theme orange-lt created by panic