Building the Tactical Foundation

STARTING WITH THE FOUNDATION

One of the first decisions was to keep the game's content data-driven.

Weapons, actions, buildings, maps and game rules should not require a new hard-coded implementation every time we add something.

Instead, systems describe their behaviour through shared data and contracts that can be consumed by the editor, client and server.

That work is not particularly visible in a screenshot, but it matters a lot at this stage.

FLANKED is going to contain many interacting systems.

If adding a weapon, map element or gameplay rule requires rewriting several unrelated parts of the project, iteration will become increasingly difficult.

The first weeks were therefore as much about building a structure we could continue working with as they were about adding visible features.

GETTING A SOLDIER ON THE FIELD

The next objective was straightforward:

put a soldier in the world and make the basic interaction feel like a game.

FLANKED uses a top-down perspective, so movement, aiming and combat immediately create different constraints from a traditional first-person shooter.

We worked through the first versions of:

movement,

stances,

aiming,

weapons,

projectiles,

damage,

grenades,

and character animation.

Characters also began using the animation work that will eventually need to cover standing, crouching, prone movement and the different weapon classes used by the game.

The first implementation does not represent final animation quality.

At this stage the objective was to establish the complete gameplay loop before polishing each part individually.

MAKING THE SERVER AUTHORITATIVE

Multiplayer combat cannot rely entirely on what each client claims happened.

The server needs to own the important state.

FLANKED therefore uses an authoritative server architecture.

The client is responsible for presentation and player input, while the server validates and maintains the state that matters to gameplay.

That includes things such as:

player state,

movement-related information,

combat events,

projectiles,

and the evolving state of the match.

This architecture creates more work early in development than building everything locally on one client.

But it gives us the foundation we need for multiplayer, bots and eventually vehicles to operate inside the same simulation.

BUILDING THE FIRST BATTLEFIELD

Once a soldier could move and fight, we needed somewhere meaningful to do it.

That led directly to the map and editor work.

The editor began supporting the placement and configuration of terrain and gameplay objects rather than forcing levels to exist as fixed scenes.

We could start assembling:

terrain,

buildings,

vegetation,

main bases,

objectives,

and other gameplay elements.

This quickly became one of the most important tools in the project.

A tactical game depends heavily on distances, routes and positioning.

Being able to change those things quickly and immediately test the result is much more useful than treating maps as static content that only changes occasionally.

OBJECTIVES, TICKETS AND AN ACTUAL MATCH

A battlefield still needs rules.

During August we added the first strategic layer around the combat itself.

Teams received tickets.

Capture points began defining objectives on the map.

A main base provided an initial deployment area.

Those systems turned the prototype from a place where soldiers could shoot each other into the beginning of an actual match.

Tickets are particularly important because they connect individual losses to the state of the team.

Dying is no longer only a local event.

Repeated losses contribute to the larger battle.

The exact balance will continue to change, but getting that relationship into the game early gives us something much more useful to test.

BOTS ENTER THE SAME BATTLE

AI soldiers were added early rather than being treated as something to solve after the multiplayer systems were finished.

That was deliberate.

Bots need to interact with the same systems as human players.

They move through the same maps.

They fight the same enemies.

They participate in the same objectives.

And eventually they need to understand the same squad orders and tactical information.

The first AI behaviour was necessarily simple.

The important milestone was getting AI-controlled soldiers into the actual simulation rather than building a separate demonstration that would later need to be integrated into the game.

FROM SOLDIERS TO SQUADS

Once multiple soldiers existed on the battlefield, organisation became the next problem.

The first squad systems began to appear during this period.

That gives the game a level between the individual soldier and the whole team.

Instead of treating every unit as independent, squads can provide a shared tactical context:

who belongs together,

who is leading,

what the group has been asked to do,

and where it is operating.

This work is still evolving, but introducing squads early is important because many future systems depend on them.

Orders.

Spawn behaviour.

Forward positions.

Command.

AI coordination.

Even the tactical map becomes much more useful once the battlefield contains meaningful groups rather than a collection of unrelated units.

THE TACTICAL MAP STARTED BECOMING A TOOL

The strategic view also began taking shape.

The map needs to provide more than a miniature version of the battlefield.

It needs to communicate what is happening across the match.

Objectives.

Teams.

Squads.

Orders.

Eventually, reported enemies, vehicles, logistics and forward positions.

During this first period, the important step was connecting that higher-level view to the same battlefield being simulated below it.

That gives us a place where future command systems can grow instead of creating a completely separate interface later.

TOOLS MATTER AS MUCH AS FEATURES

One lesson from these first weeks was how quickly development changes once the tools become usable.

Without an editor, adding another map element is a programming task.

With one, it becomes a level-design task.

Without structured gameplay data, adjusting content means changing code.

With it, iteration becomes much faster.

This is why some of the work during August may not immediately look like a new gameplay feature.

Editor improvements, validation, shared data definitions and networking infrastructure are not as visible as a new weapon or a vehicle.

But they determine how quickly those visible features can be built afterwards.

WHERE WE ENDED AUGUST

By August 31, FLANKED was still an early prototype.

But the important pieces were beginning to connect.

We had:

a map editor;

terrain and imported environment assets;

player and AI-controlled soldiers;

top-down movement and combat;

weapons and grenades;

an authoritative multiplayer server;

main bases;

capture objectives;

tickets;

ammunition and health-related gameplay elements;

the beginning of squads;

and a tactical overview of the battle.

None of those systems should be considered finished.

The point of this first phase was not polish.

It was to establish enough of the complete game that future systems could be tested in context rather than in isolation.

NEXT

The next stage is about making those systems interact more deeply.

Squads need stronger behaviour.

Battlefield information needs to respect visibility.

The tactical map needs clearer symbology.

Forward positions and logistics need to become part of the match.

Vehicles need to enter a battlefield that was designed to support them rather than being added as an afterthought.

And all of that needs to remain understandable from both the soldier's perspective and the command layer above it.

The first weeks were about proving that the pieces could exist together.

Now the work is making them depend on each other.