NeoFPS in 2024

Over recent years I’ve seen NeoFPS go from an idea to a substantial framework used in many game dev projects. The NeoFPS community has grown along with it, and I’ve had the pleasure to talk to a huge number of developers of varying experience and ambition.

One of my design goals for NeoFPS was to make it highly modular and customizable. The feedback I receive about this has been hugely positive, and helping developers map the features of NeoFPS to their own specific vision has been hugely rewarding. It has also highlighted a number of areas where the architecture can be improved. Additionally, my own work on creating an AI solution for NeoFPS has revealed a number of potential changes I could make.

With this in mind, I’d like to go over my plans for a significant upgrade of NeoFPS and start a conversation on what form that should take.

What Is The Plan?

For some time I have been talking in the community about delivering a major upgrade for NeoFPS, simply referring to it as “1.2”. The discussion has centered around 2 main points:

  1. Refactoring and improving the core functionality of NeoFPS to make it easier to use, more robust, and to set the foundations for future features.
  2. Adding a high quality combat AI solution that is designed to meet the needs of modern FPS games.

Up to this point, the discussion has been around both of these being released at the same time, with 2 new assets being the outcome:

  • A “core” NeoFPS asset with the architectural improvements of 1.2 and rough feature parity with the current asset. This would be available free for existing owners of NeoFPS.
  • An “ultimate edition” style NeoFPS asset with the addition of the AI and some other potential features (such as including full body animations for the AI and player character). This would be an inexpensive paid upgrade for existing NeoFPS owners (upgrading from the core edition would be the price difference between them).

Due to the amount of work required for both these areas of development, I have now decided that it makes the most sense to prioritise getting the upgraded core asset in developers hands as soon as possible. This prevents development of the AI from blocking the progress of NeoFPS as a whole, and enables you to move ahead with your FPS projects with the confidence that you’re working on a stable foundation.

Update vs Upgrade

An upgrade is different from an update in that it is essentially a new asset. It has a new store entry, and owning the original does not automatically grant you ownership of the upgrade. Publishers are able to set different pricing for users based on the other assets they own. In the case of NeoFPS, the price will be free for people that own the original NeoFPS asset, but you will still need to go through the asset store checkout process to gain access to it.

You might now be thinking that if it’s free, why should it be a new asset?

That is a symbolic choice I’ve made based on the scale of the changes involved. In the past I have endeavoured to make each of my NeoFPS updates as easy to apply as possible. The goal has been for you to be able to simply download and import the update via the package manager and carry on. Obviously there are exceptions to this, and I include notes on which changes may impact your projects for each update.

With this 1.2 upgrade, the changes are more substantial and there is going to be work required on the part of the user to transition your projects over. How much work is acceptable in upgrading your projects is the main thing that I want to open up for discussion from this point.

What is Coming In 1.2?

Firstly, I should talk about the improvements that are definitely coming in this upgrade. Some of the major changes include:

  • Replacing the NeoFPS input setup with a both-in-one solution for input manager vs input system. You will no longer need to use an extension package and swap input handlers on your weapons and character.
  • Refactoring the save system with new unity API features to make it cleaner and more robust and to streamline instantiation. I will also be looking at switching to addressables for better future proofing and control of your data.
  • A new wizards system that’s easier for me to extend with new features like attachments, dual wield, etc. Also many more wizards to make getting objects set up easier.
  • An improved project setup system for things like layer management and generated constants. The goals here are more flexibility and easier to manage for you all, though the extent of this needs discussing as below.
  • A large scale reorganisation of the asset so that scripts and demo files are easier to find and maintain. This includes better assembly definition use, and renaming some scripts to be more intuitive. I’ll be trying to make it much more obvious which scripts are meant to go on which objects. These changes will also make SRP support much cleaner in the future.
  • Reworked / extended demo weapon models and animations. The aim here is to add all the animations required to demo the newer NeoFPS features, and also to provide blender source files that you can use as a starting point for your own custom weapons.

Alongside those changes, there will be a huge number of smaller tweaks and fixes. The above is not a comprehensive list. If there is a feature that I haven’t mentioned here which you are expecting from previous discussions with me then feel free to reach out on the discord.

I’d also like to include new demo weapons such as bows and arrows, and tools such as stim packs and flashlights. These will probably be the parts that have the biggest impact on the launch date though, so I don’t want to commit to too much here. Whatever I can get done in a reasonable time frame I will.

What Is Still To Be Decided?

Where I want to get feedback and start a dialogue is in looking at some larger changes that bring both a huge benefit, but also add a lot more friction when upgrading existing projects. I need to decide which of these to include in 1.2 and I’d love the input of NeoFPS users to ensure I get this right. There is a tricky balance between minimising disruption and maximising this opportunity to make fundamental, positive changes.

For developers who have modified NeoFPS scripts and assets (besides the settings and managers assets available through the hub) there will always be an impact. There is no way for me to predict the depth and breadth of this, and in those cases I advise developers to leverage version control to the maximum in recreating their changes. I’m also happy to help with pointing people in the right direction on the discord.

For those people who have created new content instead of modifying the provided examples there are a range of options. In the simplest case I can aim for a fairly streamlined process. This would look like:

  1. Back up your project (always, preferably with version control)
  2. Delete the NeoFPS folder and all its contents
  3. Import the new upgraded NeoFPS
  4. Use version control or a backup to recreate your NeoFPS settings
  5. Possibly import an upgrade package and run a simple tool which upgrades your prefabs

At the other end of the scale, the changes could potentially require you to rebuild prefabs, swap components, check and re-apply inspector changes in multiple places.

The following are the main large scale changes that I could make if demand is high enough (click to expand / collapse):

This would mean moving the shared functionality of raising and lowering the weapons, managing their selection state and also their stance out of the weapon classes and into the inventory wieldable class.


Code would be unified in a single place instead of duplicated across all the weapon types, making it easier to maintain and extend. It also means that any use cases for the weapons that don’t involve being in a player character inventory (eg AI, turrets, mounted weapons, secondary fire modes, dart traps, etc) wouldn’t have all the overhead of this useless functionality.


Stance management should be unaffected as none of that is exposed to the inspector. Selection and deselection animations, timing and audio would need reapplying to all of your weapons though.

This would mean merging the swappable and non-swappable inventories into a single wieldable type on the weapons, but it would also mean moving the quick-slot index properties for specific weapons into the character’s inventory.


The main benefit is that there are currently 3 versions of the character inventory, 2 inventory HUDs, 2 wieldables, 2 quick-use items, 2 instant use consumables. People frequently get the wrong combination of wieldables, etc for their character’s inventory type. With this change each of those would become 1, making it easier to maintain, quicker and easier to add new features, and more intuitive to explain and use.


It’s easy to guess the category of a weapon based on the behaviours attached, but it’s impossible to guess the desired quick slot. Instead you would have to specify the valid inventory IDs for each slot in the inventory of the character. This means all quick-switch inventories and stacked inventories would need re-setting up, and would be less flexible for adding or quickly swapping new weapons (unless you reuse IDs).

Generated constants let you specify enumerations for things like weapon categories or surface materials from the inspector. They then generate a script that lets you reference these enumerations in code and display them in component inspectors.


The big disadvantage of generated constants is that they store values by index, meaning that if you reorder them then potentially all prefabs and assets that reference them can be affected. That also means that when I want to add a new one for a demo or feature then it will conflict with the new ones you have added to your project. This will fix that conflict and make future updates of NeoFPS easier and safer to apply.


Replacing them is a big job and will require reworking a number of systems that reference them. This will push the update back slightly (at least a week) and have a bigger impact on upgrading, with more potential breakage for people that have added custom crosshairs, surfaces, character audio, etc.

NeoFPS currently has a desired layer setup for your projects that it applies via the NeoFPS Hub. It also has scripts that specify different masks for different purposes such as bullet blockers and character collisions. This change would stop those masks being hard coded and make it easier to adapt the layer setup to your needs.


NeoFPS as it stands uses a lot of layers (only 5 left over for your own uses). With the introduction of the SRPs Unity has made a lot of rendering features dependent on layers, making them even more valuable. Currently, if you want to use NeoFPS with a non-standard layer setup then you have to modify one of its scripts and change the layer mask settings on all of your weapons and characters. This change would make that much easier to manage. It would also replace the layer mask inspector properties with a new type which allows you to pick between the preset or a custom layer mask (all old prefabs will be set to a custom layer mask, but new ones will use the preset by default). Changing the layers in the NeoFPS hub will then mean that any prefabs using a preset will continue working as intended without intervention.


This is a very complicated thing to change on my end and will push the update back at least 2 weeks. There is also more potential for bugs due to its complexity. People wanting to switch an old NeoFPS project to use a new layer setup (the default will match the existing setup) will still have to manually update their prefabs to the new layer masks.

The NeoFPS demos use a menu system for displaying options, picking save games and levels, and showing popups such as keypads in game. This UI was not intentionally meant to be reused outside of the demos, but of course having everything there means that most people who develop a NeoFPS project use this by default. I would like to replace this system with a new one that is more flexible and easier to use.


The new system would be more intuitively laid out and easier to expand, both in the editor and in code. It would also remove the requirement to use the demo UI styles system, which makes it more complicated than necessary to drastically change the look of your menus and UI.


Any game UIs would need rebuilding in the new system. I would likely include the old system and its examples as an extension package, so people that did not want to adopt the new system did not have to, but I can’t be sure it would be that simple.

TMP provides a much better UI text quality than Unity UI’s solution.


Improved text quality and less coding work required for the people that want to switch to Unity’s recommended text solution for uGUI going forwards.


All custom UI and HUD prefabs would need their text components replacing with the text mesh pro equivalent and re-connecting.

Anything more involved than these changes, or any of these which I do not complete for the upgrade will not happen until a NeoFPS “sequel” is potentially created (see below).

If you have strong views on the above features then get in touch via the discord, or using the contact form on this site.

What Comes After 1.2

Immediately after 1.2 is submitted I will be balancing my time between 2 main tasks: tutorials and AI.

I have been holding off on creating new tutorials because changes were coming, but there are a number of features that deserve video and web based guides. The current review time for new assets is also around 2 months, so I want to be launching with updated tutorials already available.

For the AI, my focus will be on getting it to a well rounded state where verified customers can test it. It won’t come with its own animations for testing (there will be example packages for popular animation assets) and the documentation will be a bit rough and ready, but it should be a high quality solution. I will also be providing it under a license that allows verified customers to use it in their commercial projects. However, before it is released on the asset store it will not have the level of support you would expect from a full asset, and it might be subject to breaking changes at short notice. Whilst the AI is being tested I will be working on demos and supporting assets such as animations that are required to round it out into a proper deliverable. This is the time where I will be deciding how the AI will launch – as an extended NeoFPS or as a standalone asset (or both).

There is also the question of my longer term plan for asset publishing. There are a number of driving forces here:

  1. Some of the work that I’ve already complete for the AI would be an incredible benefit to NeoFPS as a whole. There are some genuinely exciting possibilities that have been unlocked by the work I’ve been doing lately, but the changes required to capitalise on them are far too large to be considered an upgrade. An example would be the new animation system I’ve developed (check out a preview). This allows you to quickly define character animation profiles without any need for complicated animator controllers (one of the most frequent cause of support requests on the discord) and makes it far easier to add animations on demand. This same system would map incredibly well to the firearms and full body system too. However, there is no way that I would be able to implement this with an easy conversion path for an existing NeoFPS project.
  2. The last year and a half of publishing on the store has been brutal. Due to various circumstances (the global economy, people returning to work post-covid, Unity PR and my own health and productivity) sales of NeoFPS have dropped considerably. At the same time, the asset itself has gone from strength to strength. I’ve added many of the more sought after features from the discord (SRP support, full body system, attachments). Despite that, 2023 sales were well under half the income of 2021 and nowhere near the level of a salary. I’m lucky that I have other sources of income that mean I am able to spend the majority of my time on NeoFPS, but the current situation will not be sustainable forever. There are a number of strategies that can boost success on the store, but one of the biggest is to build a portfolio of smaller assets and leverage the bundles system.
  3. There are a number of features in NeoFPS that can be applied to far more than FPS games. For example, developers have adapted the modular firearm system into a range of games including vehicular combat and even a jungle strike style isometric game. Having features like inventory, firearms or character controller separated out broadens the number of people that can use them. Nobody should have to buy a full FPS system just to access one part
  4. I need to work on my own game. The goal of NeoFPS was always to build the foundation for me to create my own games with. If I don’t commit the time to making some progress with this then NeoFPS has not met the goals I set for it.

Therefore, once the AI has been nailed down I will be looking to the future of NeoFPS. This means extending it with all the things I’ve learned over the last few years and building a game prototype to “dog-food” the next generation by building something complex and complete (art and content excluded). Hopefully in this time Unity will have found its new direction and provide a clearer view of how these assets should fit with its future growth and focus. At the moment there are a number of areas where Unity is in relative flux, such as ECS, rendering and multiplayer, which makes it harder to pick the correct path.

If you are waiting on a major feature from me such as a third person controller or multiplayer then it will not be happening before this point. What shape this next generation of assets takes, and what features they contain are not something I can commit to at this point. I have many many ideas, and would love to bring them all to market, but there are too many unknowns and there’s a limit to what one person can do.

To be clear, NeoFPS will still be under development. I will still be adding smaller features, creating demos and tutorials, and supporting the asset(s). The goal of 1.2, however is to provide a stable base that people can build their projects in with confidence. Any huge features that require fundamental changes to the architecture of the asset will be part of a new replacement offering at some point in the future.

Anyway, I hope that gave a decent overview of the situation and plan. I will be updating the roadmap and codecks to bring them inline with these plans over the next couple of days. Overall I’m very excited about where NeoFPS is going and can’t wait to bring all these ideas and plans to fruition. A huge thanks to everyone that’s supported NeoFPS and all the people building awesome projects with it. I’m looking forward to seeing how that develops over 2024 and beyond.

Share this post