February 2026 Devlog

Welcome to the second entry in the series of Panzer Vor devlogs! In this post I will cover all major updates to the game that were done in February.

Last month I focused on getting the game to a stable condition, removing most of the bugs that were present mostly in the multiplayer mode. I also worked on figuring out a couple of annoying issues that would fall under the 'quality of life' umbrella. There were also some major optimizations, allowing you to run the game on any potato: Russet, Yukon, Red - you name it!

Multiplayer overview

Panzer Vor is built on a multiplayer stack that allows you to connect to the central server or host a game yourself. This means that some machines are servers/hosts and some are clients. The systems are split between some that are required to run on a dedicated server and some that are only required if you are actually playing the game. This way I can have a dedicated server without unnecessary overhead, while also achieving great performance without client-side overhead. Here is how it is implemented in the scene entry script:

This code takes care of initializing all possible game modes, including single-player (which is pretty much host without internet connection).

You can also notice that the [c]context [/c]dependency is injected into the constructors of all the systems. I will cover the code architecture of the game another time to explain this in more detail.

The challenges

This system allows me to eliminate most of the bugs without a need to build the app and test it in the client-server mode every time. However, it is not foolproof and a lot of multiplayer bugs accumulated over time, so I sat down to fix them.

The main issue is that I don't have clear visibility into what information might have been left out and will not exist in the client mode. While server or host can see everything just like a single-player, client gets only limited visibility of everything I can sync. This is good to prevent cheating, since I only send information that I want that client to see, but introduces challenges where I need to figure out correct authority and replication strategy.

As an example, when you select tank(s), their path is shown on the map. This allows player to see where specific tanks are going. I found this insight very useful when controlling a large amount of squads! However, when testing in multiplayer, I realized that I explicitly didn't share this information over the network, since that would allow everyone else to access this information in some way. While not critical for matches with your friends (you would need to know which chunk of memory to examine with external tools), if I want to make ranked matches of some sort with dedicated servers, this cannot be allowed. Luckily, the multiplayer stack allows me to specify 'interest' in certain data, so the handler for navigation only shares that information with input authority client, which is the player managing those tanks. Even allies don't know where you are going!

Multiplayer plans

This is how I see multiplayer will be utilized in Panzer Vor with Public Beta release and onward. This can change any time, but I am committed to providing a free experience for anyone to play with their friends.

Here are the modes that are already implemented with Panzer Vor's networking stack:

• Single-player: the default mode for playing against bots or progressing through the story.

• Private Matches: games hosted by you or your friends where you can invite each other into a private lobby, choose any map and game configuration and enjoy the time together. Games run on the computer of the one who created the lobby.

• Unranked Matches: matchmaking games where you can play with or against other players alone or in a group of 3. These games will likely be hosted on one randomly chosen computer, possibly with quality/trust score of players for smoother games.

• Ranked Matches: matchmaking games where you are competing against other players alone or in a group of 3. This would have to be hosted by me, and considering current server prices, might be an expensive endeavour. However, I can always distribute servers for private events for those willing to host. As much as I would like to have a ranked progression in the game, this really depends on potential costs and if I can cover that.

Quality of life and UX improvements

As much as I want to keep adding features, there comes a time when polish is required. The following things were changed during the new UX pass.

Better tank mode toggles

Old left-right toggles were replaced with regular clickable toggle making it much simpler to control. Keyboard shortcuts are also available now!

Reposition plane

The tank reposition action was changed to be activated when holding Ctrl (for control!) which would also show the navigation mesh. This is especially useful when controlling different tank types since light, medium and heavy tanks can reach different areas on the map.

Better unit behaviour

One of the challenges of making an RTS is that players don't have direct control over their units. So any undesirable behaviour was really frustrating to see. I implemented the following changes:

• Tanks aim at the turret if body is obstructed. Before tanks would just stare at the target that was obstructed by a hill.

• You can now manually specify target for each tank. By default, tanks pick the closes target to them that is in clear view. The manual override is active until target is unspotted.

• Paths are more simplified reducing the possibility that a tank would turn around to get a previous target point.

• Tanks can shoot in advance now and are much more accurate when shooting moving targets.

Performance optimizations

As I mentioned in the last post, the 'Spot System' AKA Fog of War is the most complex and resource-intensive system. This is especially true when there are a lot of tanks on the battlefield. While before the raycast was done in Unity job, making it extremely fast, the processing of the raycast result was done on the main thread making this process very resource-intensive. The algorithm has to figure out if the ray is obstructed, calculate the bushes/trees in the way, see if target tank shot a projectile recently, include spot index, distance and possible buffs/debuffs. And that is for every tank to every other tank on the enemy team!

In February, I move all of that process into a job as well while accessing the memory by a direct pointer to avoid overhead of C# get/set.

Before, spot result process called when the job is complete.

Now, 'process job' is Burst compiled and scheduled after raycast job is complete.

This improved performance by 10x!

Sound system

One of the additions I made was the sound system. This was necessary in order to record a trailer for YouTube and Steam. If you haven't seen it, you should go watch it! [dynamiclink href="https://www.youtube.com/embed/XAdU7EsiVKA?si=tPynvGjYL9-3ItlL"]

Other updates

There were also lots and lots of bugfixes and marginal improvements:

• Make camera movement really fast while pressing the Shift key.

• Assign icons for all abilities

• Update Unity Engine to 6.3.8

• Improve economy by making the base income and maintenance cost change when the round progresses. This allows players to choose more and more aggressive setups further into the round.

---

Follow Panzer Vor on Twitter! https://x.com/playpanzervor

Feel free to also follow me https://x.com/madebynoxc

Panzer Vor Discord: https://discord.gg/gyjSbBD

Wishlist the game if you still haven't!

-noxc