Sector 4 Underground
Building Sector 4: Years of FPS Experiments, One Reusable System, and a 30-Minute Vertical Slice
Sector 4 did not begin with the idea of making a horror game.
It actually began years earlier, with a much more basic question:
How can I build a first-person game without rebuilding the entire first-person system every time?
Over the years, I experimented with different FPS controllers, weapons, character rigs, aiming systems, interaction systems, animation setups, procedural animation ideas, camera systems, and other pieces of technology that are usually required to make a first-person game feel convincing.
Some experiments worked.
Some were abandoned.
Some became useful later.
And some taught me exactly what I did not want to do.
Eventually, all of those experiments started converging into a simpler idea: instead of trying to build a physically perfect first-person character, I could build a system that creates the perception of a complete first-person character without requiring an unnecessarily complicated animation and rigging pipeline.
Sector 4 became the experiment where I finally put that idea into practice.
The Problem I Was Trying to Solve
Creating an FPS looks deceptively simple.
You need a camera.
You need a character.
You need a weapon.
You need an animation for holding it.
Then you need animations for firing, reloading, aiming, switching weapons, moving, sprinting, crouching, interacting, and potentially dozens of other actions.
Once multiple weapons are introduced, the animation problem grows very quickly.
An assault rifle has one set of requirements.
A shotgun has another.
A pistol has another.
If you want several different weapons, you can quickly end up creating and maintaining a large number of animations and character configurations.
Then there is the question of the actual character.
Should the camera be attached directly to the character's head?
Should the arms be part of the complete character model?
Should the weapon be attached to the hand?
How should the arms move when the camera moves?
What happens when the player looks up?
What happens when the player looks down?
What happens when the player aims?
What happens when the player switches weapons?
And if the player model uses a conventional full-body animation system, how much additional work is required to make the first-person view look right?
For a small solo-developed project, I eventually came to the conclusion that I did not want to solve all of those problems in the most complicated way possible.
I Was Not Trying to Build a Perfect Human Rig
One of the biggest lessons I learned from my previous FPS experiments was that the player does not need to see the underlying trick.
The player only needs to believe what they are seeing.
This distinction became extremely important to the way I approached Sector 4.
I did not want to build an elaborate procedural animation system just to make a weapon look like it was being held by a perfectly simulated human body.
I also did not want to build a complete character rig with the camera physically attached to the head bone and then spend enormous amounts of time compensating for all of the problems that approach creates in first-person view.
Instead, I wanted to reproduce the feel of those systems.
The result is a system that uses relatively simple components working together:
- Inverse Kinematics
- Tweening
- Weapon-specific animations
- Reusable animation sets
- Controlled camera movement
- Separate first-person visual meshes
- Selective visibility of the left and right hand
- A unified weapon framework
None of these ideas individually are revolutionary.
The important part was how I combined them into a workflow that I could actually reuse.
The Trick: Mimic the Result Instead of Simulating Everything
The fundamental idea behind my FPS system is simple:
I don't necessarily need to simulate the complete physical process if I can reproduce the visual result convincingly.
This philosophy allowed me to simplify several parts of the system.
Instead of building a full procedural animation solution for every possible weapon interaction, I could use existing animations and manipulate the presentation around them.
Instead of making a complete character body responsible for every first-person visual, I could use a dedicated first-person model.
Instead of creating completely independent animation systems for every weapon, I could reuse animation patterns between different weapon classes.
The player sees the final result.
The player does not see how many shortcuts are underneath it.
The First-Person Model
One of the most useful decisions I made was to treat the first-person visual model as its own presentation layer.
The model is not simply the player's complete third-person character with a camera attached to its head.
It is designed specifically for what the player needs to see.
This gives me much more control over the visual result.
The system can selectively show or hide the appropriate hand meshes depending on the weapon and the current state.
Instead of requiring a completely different character model for every weapon configuration, the same underlying first-person setup can be reused.
This is particularly useful when dealing with weapons that have different handling requirements.
Left Hand and Right Hand Presentation
One of the simpler but more useful tricks in the system is controlling which hand meshes are visible.
Different weapons naturally require different hand positions and different visual relationships between the weapon and the player's body.
Rather than building an enormous number of specialized first-person models, I can manipulate the presentation of the existing model.
The system can show and hide the appropriate hand components depending on what the player is holding.
This gives me a surprising amount of flexibility without creating a huge amount of additional content.
It is a good example of the overall philosophy of the project:
Use a small number of reusable components to create many different visual results.
IK Instead of Endless Animations
Inverse Kinematics became another important part of the solution.
Rather than animating every possible position of the hands manually, IK allows the hands to be positioned relative to targets.
This means that the hands can follow the weapon and maintain a believable relationship with it without requiring a completely unique animation for every possible configuration.
IK does not need to solve every movement.
It simply solves the parts where it provides the most value.
This is an important distinction.
I did not want to replace conventional animation with a giant procedural animation system.
I wanted to use procedural positioning where it was useful and conventional animation where it was already sufficient.
Tweening
Tweening is another relatively simple technology that became surprisingly useful.
Small controlled movements can make a first-person weapon feel much more alive.
Weapon movement, transitions, recoil-like motion, positioning changes, and other visual effects can be created through controlled interpolation instead of requiring a new animation for every tiny movement.
This allows the weapon presentation to respond dynamically while keeping the underlying system relatively simple.
Again, the goal is not physical simulation.
The goal is perception.
If the weapon moves correctly, the player perceives weight and responsiveness.
Reusing Animations
Another major part of the system is animation reuse.
I did not want to create a completely independent animation library for every weapon.
Instead, I created a system where animations could be reused across weapon classes whenever they made sense.
This is particularly important for a solo project.
Animation production can become one of the largest content bottlenecks in an FPS.
If every new weapon requires a completely new set of animations, adding content becomes increasingly expensive.
By designing the system around reuse, I can introduce different weapons while keeping the animation workload manageable.
Three Main Weapon Classes
For the current Sector 4 vertical slice, I use three major weapon classes:
- SMG
- Shotgun
- Assault Rifle
These weapons are different enough to provide different combat experiences, but they can still operate through the same broader weapon architecture.
The underlying system knows how weapons behave.
The individual weapon configuration determines the characteristics that make one weapon different from another.
This means I can keep the gameplay code unified instead of creating completely separate systems for every weapon.
The Goal Was a Unified FPS System
This is probably the most important technical goal behind Sector 4.
I did not want three weapon systems.
I wanted one weapon system capable of representing three weapons.
I did not want three different interaction implementations.
I wanted one interaction system.
I did not want a special implementation for every new FPS prototype.
I wanted a reusable foundation.
This is why Sector 4 is more than just another game prototype for me.
It is a demonstration that the systems I spent years experimenting with can actually work together inside a real playable environment.
The FPS Essential Pack
For the visual assets, I used the FPS Essential Pack available for free on itch.io.
The important distinction is that I used the pack for its visual assets, not its underlying code.
I did not take the pack's gameplay architecture and build Sector 4 around it.
Instead, I wrote my own systems and integrated the visual assets into my own framework.
This was intentional.
I wanted the project to demonstrate my own engineering work rather than simply demonstrating that I could assemble an existing FPS controller package.
Why I Did Not Use Its Code
Using a ready-made controller can be useful for prototyping, but it would not have answered the question I was trying to solve.
I wanted to know whether I could create a reusable FPS architecture myself.
I wanted control over how weapons behave.
I wanted control over the interaction system.
I wanted control over the player equipment.
I wanted control over the animation presentation.
I wanted control over how new weapon classes could be introduced.
Most importantly, I wanted the systems to be mine so that I could take them into future projects.
The visual asset pack gave me a useful starting point for presentation, while the gameplay architecture remained my own implementation.
Years of Experiments Behind a Small Game
One of the strange things about Sector 4 is that the game itself is relatively compact.
But the technology behind it represents years of experimentation.
I built different FPS controllers.
I experimented with weapon handling.
I tested different ways of presenting first-person arms.
I experimented with animations.
I considered procedural animation approaches.
I experimented with interaction systems.
I built different approaches to aiming and weapon switching.
Some of those experiments were useful.
Others were abandoned.
But each one contributed something to the eventual system.
Sector 4 is essentially where those experiments finally meet each other.
Why I Avoided Full Procedural Animation
Procedural animation is extremely powerful.
There are situations where it is absolutely the right solution.
But I came to the conclusion that it was not necessary for what I wanted to achieve with this project.
A fully procedural FPS animation system can become a project of its own.
You start with hand placement.
Then you need weapon alignment.
Then recoil.
Then movement offsets.
Then aiming.
Then sprinting.
Then transitions.
Then weapon switching.
Then animation blending.
Then edge cases.
Eventually, the system can become more complicated than the game you originally wanted to build.
For a solo developer, that can be dangerous.
You can spend months building a technology that technically solves a problem that the player never knew existed.
I wanted to avoid that trap.
Good Enough Is Sometimes Better Engineering
This does not mean I believe simpler systems are always better.
It means the system should be proportional to the problem.
If the player cannot tell whether the hand movement came from a procedural solver or a carefully controlled animation and IK setup, then building the procedural solver may not provide enough value to justify its complexity.
For Sector 4, I chose the simpler solution.
I wanted to spend my time building the actual game rather than building an animation research project.
AI as an Engineering Assistant
Artificial intelligence also became part of the development process.
But not in the way that some people might assume.
I did not use AI to generate Sector 4 as a complete game.
I did not ask an AI to create the entire FPS architecture and then paste the result into Unity.
Instead, I used AI primarily as an architectural assistant and productivity tool.
It helped me think through architecture, refactoring, system organization, implementation approaches, debugging, and repetitive development tasks.
It helped reduce development time.
It helped me explore alternatives faster.
It helped me refactor code and identify places where a system could be made cleaner.
But the responsibility for the architecture remained with me.
AI Reduced Friction, Not Ownership
This distinction matters to me.
Using AI did not eliminate the engineering process.
It reduced the amount of friction between an idea and an implementation.
I still had to decide what the system should do.
I still had to decide how different systems should communicate.
I still had to test the implementation inside Unity.
I still had to determine whether the result actually worked.
I still had to refactor systems when the original design was no longer appropriate.
AI became another tool in the development environment.
It accelerated parts of the process without replacing the actual design decisions.
Sector 4 as a Vertical Slice
The most important purpose of Sector 4 is not to represent an enormous complete horror game.
It is a vertical slice.
The idea is to demonstrate what the final system and gameplay experience can look like when all of the individual components are combined into a coherent scenario.
The current target is a compact experience that can demonstrate the concept in approximately 30 minutes of gameplay.
That limitation is intentional.
I do not need a ten-hour campaign to prove that the underlying system works.
I need a concentrated section of the game where the player can experience the major mechanics and understand how they interact.
The Opening
The player wakes up inside the underground facility.
The facility is in a state of maintenance and failure.
Systems are offline.
Infrastructure is damaged.
The environment is dark.
The player has to figure out what is happening and, more importantly, how to move forward.
At first, the environment can feel almost safe because many of its systems are inactive.
But that safety is deceptive.
Bringing Auxiliary Power Online
One of the first major objectives is bringing the auxiliary power system online.
This is important because the facility's infrastructure depends on power.
Without it, important systems remain inaccessible.
The player must explore the facility and restore the auxiliary power.
Once that happens, new systems become available and the player's route through the facility changes.
Power restoration is therefore both a gameplay objective and a major environmental event.
The Keypad and the Code
After restoring the necessary power, the player can access a keypad-controlled area.
The required code is not simply handed to the player.
The player must find it somewhere within the level.
This creates a small exploration puzzle inside the larger scenario.
The player has to pay attention to the environment and remember what they have discovered.
Once the code is found, the keypad provides access to the next major section of the facility.
The Main Hub
Eventually, the player reaches the main hub of the facility.
The hub acts as an important navigation point and connects several major areas.
From here, the player can access different sections of the underground complex, including the medical corridor, security areas, and the hazardous corridor.
This makes the hub more than just a decorative room.
It becomes the central point from which the player understands the structure of the facility.
The Medical Corridor
The medical section provides another part of the facility's story and gameplay environment.
Medical equipment, abandoned infrastructure, and the remains of the people who once worked in the facility contribute to the environmental storytelling.
The area also reinforces the idea that Sector 4 was once a functioning place with its own workers, procedures, and daily operations.
Now those systems have been left behind.
The Security Section
The security section provides another perspective on the facility.
CCTV systems, security infrastructure, access controls, and surveillance equipment allow the player to see how the facility was monitored before everything went wrong.
The player can interact with parts of this infrastructure and use it to understand the environment.
Security systems also contribute to the feeling that the player is exploring a place that was designed to control movement and contain something.
The Hazardous Corridor
The hazardous corridor is one of the sections where the player's equipment becomes especially important.
The player needs to use a gas mask and manage its filters while moving through the contaminated area.
This creates another resource-management problem.
The gas mask allows the player to enter an otherwise dangerous environment, but its filters are not an infinite resource.
Just like flashlight batteries, the filters introduce another reason for the player to pay attention to their equipment.
Gas Mask and Filters
The gas mask system is part of the broader philosophy of Sector 4's equipment design.
Equipment should solve problems, but equipment should not completely eliminate the problems.
The gas mask allows the player to enter hazardous environments.
The flashlight allows the player to see in darkness.
Night vision allows the player to navigate without conventional light.
Weapons allow the player to fight.
But each tool has limitations.
The gas mask requires filters.
The flashlight requires batteries.
Ammunition is limited.
This keeps the player engaged with the environment rather than turning every tool into an unlimited solution.
Sometimes Darkness Is Safer
One of the ideas I particularly wanted to explore in Sector 4 is the relationship between power and danger.
Normally, restoring power should make a facility safer.
You can see better.
Systems come online.
Doors open.
The environment becomes functional again.
In Sector 4, it can have the opposite effect.
The darkness can actually be safer.
While parts of the facility remain inactive, some of the creatures are contained or dormant.
When power is restored, systems activate and the creatures can break free.
This creates a deliberate contradiction.
The player needs the power to progress.
But restoring the power also makes the facility more dangerous.
When the Lights Come Back On
Power restoration becomes a turning point.
The player may expect the facility to become safer when the lights return.
Instead, the player begins to discover movement around them.
Creatures emerge from previously inaccessible areas.
Some can break through from ceilings and other parts of the environment.
The facility effectively wakes up.
This idea takes direct inspiration from the feeling of Dead Space, where the environment itself can become part of the threat.
The player has restored the infrastructure they need.
They have also activated the world around them.
And now the things inside the facility know that someone is there.
The Creatures of Sector 4
The current vertical slice focuses on several classes of hostile creatures.
- Crawler
- Creeper
- Walker
- Giant
Each creature contributes a different type of threat to the environment.
The intention is not simply to create a large number of enemy types.
Instead, the enemies should create different situations that force the player to react differently.
A smaller creature can create pressure in tight spaces.
A larger creature can turn an otherwise familiar corridor into a serious threat.
The combination of different enemy types makes movement through the facility less predictable.
Creatures Coming From the Environment
One of the visual ideas behind the creature encounters is that they should feel connected to the facility rather than simply appearing from nowhere.
Creatures can break free from ceilings and other areas of the environment when the facility becomes active.
This makes the building itself part of the encounter.
The player is not just fighting enemies that happen to be placed in a room.
The player is moving through a facility that contains things that were never supposed to be released.
Limited Ammunition
Weapons are powerful, but ammunition is limited.
This is another deliberate survival-horror decision.
If ammunition were effectively unlimited, the player could solve every problem by shooting it.
Instead, the player has to consider whether an encounter is worth the ammunition.
Sometimes the best decision is to fight.
Sometimes the best decision is to move.
Sometimes avoiding an enemy is simply more valuable than killing it.
This creates a relationship between exploration and combat where the player is constantly evaluating the cost of engagement.
The Weapon Classes
The current vertical slice contains three primary weapon classes:
SMG
The SMG provides a fast-firing weapon for situations where the player needs to react quickly and deal with threats at closer ranges.
Shotgun
The shotgun provides a very different combat experience, especially in close quarters. Its role becomes particularly important when enemies get too close for comfort.
Assault Rifle
The assault rifle provides a more versatile weapon for general combat and longer engagements.
These weapons are all built on the same unified weapon architecture, while their behavior and presentation are configured differently.
Why Three Weapons Are Enough for the Vertical Slice
I deliberately did not try to fill the game with dozens of weapons.
The purpose of the vertical slice is to demonstrate the system, not to create an enormous arsenal.
Three distinct weapon classes are enough to demonstrate that the architecture can support different weapon behaviors and presentations.
If the system can support these weapons cleanly, additional weapons become a content problem rather than an architectural problem.
That is exactly what I wanted to achieve.
Radio Messages From the Dead
The facility is not only filled with enemies.
It is also filled with traces of the people who were here before the player.
The player can discover fallen soldiers and listen to their radio communications.
These recordings provide fragments of what happened inside the facility.
There is no living character standing beside the player explaining the entire story.
Instead, the player finds pieces of the story left behind by people who did not make it out.
This helps maintain the feeling of isolation.
Workers' Logs
Workers' logs can also be found throughout the facility, sometimes alongside the bodies of the people who wrote them.
These logs provide another layer of environmental storytelling.
They can reveal what the facility was like before the disaster, what the workers experienced, and how the situation deteriorated.
The player is therefore reconstructing the history of Sector 4 from fragments.
The facility does not directly tell its story.
The player has to find it.
The Russian PA System
One of the atmospheric elements I particularly wanted to include is the facility's public-address system.
A Russian female voice repeatedly broadcasts announcements throughout the facility.
She is attempting to communicate that the facility is under lockdown.
The announcements are in Russian, reinforcing the Soviet identity of the underground complex.
For a player who does not understand Russian, the sound itself becomes part of the atmosphere while subtitles or contextual information can provide the meaning.
The important part is that this voice has been playing for a long time.
She is still announcing the lockdown.
The facility is still repeating the same warning.
And there is no one left to listen to it.
A Voice That Nobody Is Listening To
This is one of the small details that represents what I want Sector 4 to feel like.
The PA system is doing exactly what it was designed to do.
It is broadcasting an emergency message.
It is warning people to remain inside.
It is announcing the lockdown.
But years later, the system is still repeating the same message in an almost empty facility.
The voice does not know that the people who were supposed to hear it are gone.
The player is the only person walking through those corridors.
And yet the announcement continues.
Again.
And again.
And again.
That kind of environmental detail is much more interesting to me than simply putting a text box on the screen saying that the facility is abandoned.
My Direct Inspirations
Sector 4 has several direct inspirations.
One of the most important is Underhell, the Half-Life 2 modification created by mxthe.
Underhell had a strong influence on the kind of atmosphere I wanted to achieve: an underground environment, military context, horror, exploration, and a feeling that the player is moving through a place where something has gone very wrong.
It is one of the projects that stayed with me for a long time.
Its influence on Sector 4 is particularly important because it represents the kind of experience that originally made me interested in combining FPS gameplay with environmental horror.
I also want to acknowledge the passing of mxthe, whose work on Underhell was a direct inspiration for this project.
Metro
The Metro series was another major influence.
In particular, Metro Redux and Metro Exodus influenced the way I think about the player's equipment and the physicality of surviving inside a hostile environment.
The backpack system in Metro Exodus was particularly interesting to me because it made equipment feel like part of the character's physical existence rather than simply a menu.
That philosophy influenced how I approached equipment and survival mechanics in Sector 4.
The player has tools because they need them.
The flashlight has batteries.
The gas mask has filters.
The weapon has ammunition.
The environment creates situations where those resources matter.
Sector 4 Is Not Trying to Be Metro or Underhell
These projects are inspirations, not templates.
I am not trying to recreate Metro or Underhell.
Instead, I am taking elements that influenced me and combining them with my own FPS architecture, environment design, and gameplay systems.
Sector 4 is ultimately an experiment in seeing what I can create using the systems I have developed over the years.
The Vertical Slice Philosophy
One of the biggest decisions I made with Sector 4 was to keep the playable experience compact.
I wanted the project to communicate its entire idea quickly.
The player should be able to experience the core loop without needing to play through a ten-hour campaign.
Within approximately thirty minutes, the player should experience:
- Entering the abandoned facility
- Exploring the underground environment
- Using the flashlight
- Managing flashlight batteries
- Using night vision
- Finding objectives
- Restoring auxiliary power
- Using a keypad
- Finding an access code
- Reaching the main hub
- Exploring different facility corridors
- Using the gas mask
- Managing gas mask filters
- Finding and using weapons
- Fighting zombies and creatures
- Encountering different enemy types
- Discovering radio messages
- Finding workers' logs
- Experiencing the Russian PA system
- Restoring power throughout the facility
- Reaching the main elevator
That is enough to demonstrate the identity of the game.
The Next Chapter
The current vertical slice ends before another major part of the game begins.
The player's eventual mission is to reach the upper level of the facility.
That area introduces a different kind of threat.
Instead of fighting only the creatures that inhabit the underground facility, the player eventually encounters human NPC enemies with their own AI.
This is planned as the next chapter of the game.
The contrast is intentional.
The underground section focuses heavily on isolation, darkness, creatures, infrastructure failure, and survival.
The upper level begins to introduce another dimension of the conflict and changes the nature of the player's encounters.
The vertical slice therefore establishes the foundation before expanding into that next chapter.
Why I Stopped at the Vertical Slice
A common problem with personal game projects is that they can grow indefinitely.
You build a prototype.
Then you add another level.
Then another enemy.
Then another weapon.
Then another mechanic.
Eventually, you have a large unfinished project that demonstrates a lot of individual systems but never produces a coherent experience.
I wanted Sector 4 to be different.
The vertical slice gives the project a boundary.
Instead of asking whether I can build an entire horror game, I can ask whether I can make one concentrated section that communicates what the game is.
That is a much more useful engineering and design problem.
What Sector 4 Proves
For me, the biggest achievement of Sector 4 is not any single feature.
It is the fact that all of these systems can coexist inside one playable environment.
The FPS controller works.
The weapons work.
The animation system works.
The IK system works.
The weapon architecture works.
The interaction system works.
The enemy systems work.
The power systems work.
The objectives work.
The flashlight works.
The battery system works.
The gas mask and filters work.
The CCTV system works.
The checkpoint system works.
The environmental interactions work.
The facility can change state.
And all of those systems can contribute to the same gameplay experience.
The Real Project Behind the Game
In that sense, Sector 4 is actually two projects at the same time.
The first is the game itself.
The abandoned facility, the creatures, the weapons, the objectives, the atmosphere, and the story.
The second is the technology underneath it.
The reusable FPS framework that I spent years developing and experimenting with.
Sector 4 is where those two projects meet.
From Experiments to a Formula
After years of experimenting, I think I finally found a formula that works for the kind of FPS games I want to build.
It is not a universal formula for FPS development.
It is simply the formula that works for me.
Build the player system once.
Build the interaction system once.
Build the weapon architecture once.
Create reusable animation patterns.
Use IK where it provides value.
Use tweening where it provides value.
Reuse visual components.
Keep the architecture unified.
Avoid unnecessary procedural complexity.
Then build the actual game around those systems.
This approach allows me to spend more time designing the experience and less time rebuilding the same technical foundation.
Why This Matters for Future Projects
The real value of the work will become apparent in future FPS projects.
If I want to create another first-person game, I should not have to start from zero.
I should already have the foundation for:
- Player movement
- First-person presentation
- Weapon handling
- Weapon switching
- IK-based hand positioning
- Interaction
- Equipment
- Damage
- Objectives
- Basic enemy interactions
- Resource management
The next game should therefore be primarily a design problem rather than a technology-rebuilding problem.
Sector 4 as an Experiment
That is ultimately what Sector 4 is for me.
It is an experiment.
An experiment to see whether years of small FPS prototypes, discarded systems, animation experiments, architectural decisions, and gameplay mechanics can finally become one coherent game.
It is an experiment in building an FPS without unnecessarily complicated animation technology.
It is an experiment in creating a convincing first-person presentation using IK, tweening, reusable animations, and carefully controlled visual meshes.
It is an experiment in using AI as an engineering assistant without handing over the architecture of the project.
It is an experiment in making a small vertical slice instead of endlessly expanding a prototype.
And most importantly, it is an experiment in proving that the system I spent years building can actually produce a game.
The Result
Sector 4 is not the final form of the FPS framework.
It is the first serious demonstration of it.
The project shows how a relatively small collection of reusable systems can be combined to create a complete playable scenario.
A player can enter the facility.
Explore it.
Restore power.
Find access codes.
Use keypads.
Navigate through security and medical areas.
Put on a gas mask.
Manage filters.
Manage flashlight batteries.
Use night vision.
Choose between different weapons.
Fight different types of creatures.
Listen to the last messages of soldiers.
Discover the logs of workers who never left.
Listen to a Russian PA system endlessly announcing a lockdown.
Restore power to the facility.
And eventually reach the elevator leading toward the next chapter.
All of that happens inside a relatively compact vertical slice.
What I Learned
The biggest lesson I took from Sector 4 is that good engineering is not always about building the most sophisticated system.
Sometimes it is about finding the smallest system that produces the required result.
I spent years thinking about how to make first-person systems more advanced.
Eventually, I started thinking about how to make them more reusable.
That change in perspective made a significant difference.
I stopped asking:
How can I simulate everything?
And started asking:
What does the player actually need to experience?
That question led me toward the combination of IK, tweening, reusable animations, controlled first-person meshes, and a unified weapon architecture that became the foundation of Sector 4.
Looking Forward
The current Sector 4 vertical slice is only one possible demonstration of the system.
The next chapter can expand the game beyond the underground creature encounters and introduce human enemies, more advanced AI, and a different type of conflict.
But regardless of where the game goes from here, the most important part of the project has already been achieved.
I now have a practical FPS foundation that I can continue improving and reuse in future projects.
Sector 4 gave that foundation a place to prove itself.
Final Thoughts
For years, I kept making FPS systems.
Controllers.
Weapons.
Animations.
Interactions.
Experiments.
Prototypes.
Some were abandoned.
Some were rewritten.
Some were almost good enough.
Eventually, those experiments stopped being isolated prototypes and started becoming a system.
Sector 4 is where I finally put that system into a real game.
It is a small vertical slice, designed to be experienced in roughly thirty minutes.
It is a dark underground facility that is slowly coming back to life.
It is a game where restoring the power you need can also release the things you were safer without.
It is a game where your flashlight battery can run out.
Where ammunition is limited.
Where a gas mask needs filters.
Where a dead soldier's radio can still speak.
Where a worker's final log can still be found beside their body.
Where a Russian woman's voice continues announcing a lockdown to a facility where almost nobody is left to hear her.
And somewhere above all of this is the next chapter.
For now, though, the elevator is waiting.
The power is coming back.
The facility is waking up.
And something inside Sector 4 has started hunting.