Hi Everyone,

This is the final part of my 3-part blog. If you haven’t already seen them, check out my previous two posts about the team and QA testing.

Since I specialise in gameplay, for the last part of this development blog I would like to share my personal goals for gameplay changes upcoming this year and what I will be focusing on and pushing for as an individual on the team. I’ll mostly be referring to gameplay changes in the rest of the post as per update 4.4.0 (which was unfortunately part of our larger update that was reverted from the live servers for the time being).

The things that I am going to be working on personally are:

1. Weapons and Game Balance
   
2. Clarity and Visual Improvements
   
3. Sound/Audio & General Competitive Viability

Starting off, I am pleased to say that we’ve received a lot of feedback regarding the new weapon values and weapon feel, though the testing period was very short. We’re currently going over internally how to fix some of the more major problems impacting gameplay right now, bugs and general issues alike.

I’ve identified a problem with the bullet drop changes which sort of mess up the formulas and calculations I made when implementing them. While it was absolutely the intention to increase the skill ceiling of landing a long-range shot past 200m, it was never the intention for bullet drop channels to affect under 100m combat, or for the drop to feel so immediate.

Currently, our bullet physics apply the drop rate immediately. This means that the bullet starts to drop the moment it leaves the barrel. Therefore, if an increased amount of multiplier to base bullet drop value is applied to a weapon, it will drop considerably before it even reaches a distance of 200m in flight. What should happen is that the bullet should only start dropping after a certain distance or amount of time travelled. We don’t plan to simulate real life 1:1 in our game. That’s not the kind of game we want TFE to be. But at the very least we can go for semi-realism for the sake of smoother gunplay. We’ll attempt to fix this or at least compensate for it while it remains an issue.

To fix this issue, it is likely that it will require a chunk of our programmers’ time, which we don’t have spare at this stage. In the meantime, I will take a look at this issue in more depth. In case I don’t find a better solution, we’ll lower the amount of bullet drop to compensate for this in a future update.

Our aim is to have more bandwidth for laser-accurate weapons in our game, so that we remove ‘RNG situations’ from close- to mid-quarters combat as much as possible, with the exception of a few weapons.

Obviously, greater bullet drop at distance makes longer shots more difficult; we certainly don’t want to make it easy to get kills with an assault rifle versus snipers who have spent a considerable amount of time running out of the general play area to support their team and spot the enemy from a mountain. That said, we don’t want to introduce random mechanics, such as bloom, and damage reduction at a distance, or to make it impossible to land shots at range by increasing the spread, since that would also affect close-range gunplay. It’d be lazy if done that way and I don’t want to do it like this, at least not extensively.

It’s up to the players to learn how far up they’ll need to aim to kill at various distances; it’s expected that some players will be able to adapt and get these kills, but there should be a considerably lower percentage of players with this ability following this change. I am compensating for this by allowing laser-accurate weapons with barely any spread in the game to reduce ‘luck’ in close- to mid-range gunplay and stay true to the easy-to-pick up but hard-to-master aspect of the game.

Look forward to higher accuracy for the effective range of your weapon. Your bullets will go closer to where you are pointing while aiming down the sights or through the scope, at the cost of recoil and other things.

Speaking of accuracy, there has been a bug with the grenade launchers which has been around for a long time: random inaccuracy and the grenade not spawning properly at the centre of the weapon. This is another issue that we’re going to be tackling as soon as there’s time allocated for it, since it’s a frustrating bug to deal with for our CQB players; I’ve raised the priority for getting this fixed.

The goal is for the grenade launchers to be deadly accurate and completely ‘skill-based’ with a slower projectile speed, more drop and a smaller kill radius to compensate for its near-perfect accuracy (don’t worry - everything within a few metres will still be an instant kill!). This goal will be met after fixing the above bugs. Afterwards, we will analyse the feedback and data to see if further adjustments are necessary.

Snipers are currently in a tough spot; some players absolutely love them, others absolutely hate them. And it doesn’t look like that’s going to change any time soon. One thing’s for sure, snipers aren’t going to be removed from the game. However, the snipers as is are currently clunky and we’re not happy with the usability of a sniper weapon in our game at the current stage, and there are some minor and lower priority plans to make them less clunky for players coming from other games. That has been our main feedback, after all. They should be more relatable if you are used to snipers in other FPS games. Making snipers easier to use at shorter ranges should be compensated with making them more punishing to use when a player misses their shot.

To clarify and solve the mystery once and for all, the Sniper class is not supposed to jump higher to get into unintended places in our level design. That’s a bug, not a feature. This will be fixed and the classes will be balanced. Our levels were not designed with that in mind; a lot of our players actually managed to get into some pretty crazy spots our designers hadn’t intended to be reachable and, while that’s cool to see, we simply can’t allow one class to be able to access these spots if we want to keep our game both casual and competitively viable. A spot in the playable area should be available to all classes or none.

Gunners use machine guns and their job is to suppress the enemy. In theory, they don’t need to be accurate. In theory, they should spray at close- to mid-ranges so that an enemy cannot peek or so that they need to reposition. In the longer term, there were plans for it in the form of stances. The changes to the weapon spread of the Gunner class were in relation to those plans which have now been pushed back.

Those stances were meant to be implemented in the near future to be able to emplace your weapon on any low cover or to use a bipod when laying down to have perfect spread accuracy and other smaller benefits, while running ‘n’ gunning without aiming down the sights would remain inaccurate.

That has backfired and the feedback we’ve received is that ‘gunners are unplayable now’. While I personally believe this is a drastic statement, for the time being we’ll slightly increase the ADS accuracy of the heavy weapons and increase the combat walking speed to be the same as the other classes. There are no plans to reduce the recoil or the hipfire spread, and the reasons for it are mentioned below.

In our original vision, the Gunner class was also not supposed to have Claymores as an extra option, so I plan on removing that access for now and I plan to monitor how it affects the gameplay loop.

The goal with the changes in 4.4.0+ with ADS (Aiming Down Sights) was to make ADS laser-accurate, while hipfire is more punishing at a distance, consistent across all weapons. Hipfire bullet spread should be generated more randomly, so that the player makes a decision whether or not to fire from the hip for point-blank battles, or to be scoped in at an angle you’re comfortable pushing or holding with ADS. I’ve made significant changes to the aiming speed on all weapons based on the class of weapon to simulate roughly the weight of the weapon, balanced with the range of its scope, too. This is purposeful; it adds consequence to being caught off-guard as a player.

The main idea for this change is to spice up gameplay on a competitive or higher-skill level than your average players, where decisions that you take significantly affect the outcome between losing or winning a gunfight. Players that run around mindlessly while hipfiring might not have a good time and, while I don’t intend to attack any specific playstyles, TFE is moving in the direction of both competitive viability and tactical, more cerebral gameplay to succeed on the battlefield.


Moving on from gunplay, we’ve got to talk about Visual Clarity.

Visual Clarity is an important aspect of any game. From both the feedback we’ve received from the community and our own experiences, we feel that there is more that we can do to improve it. For example, we see great potential in working on aspects of blending and the fading of visual effects. By working on these areas, we can improve the gameplay experience for both seasoned and new players.

One option which we previously explored was to change the colour parameters for the character; however, we feel that we can do more. For any future additions or changes to the uniforms or character models, additional changes should be made to our textures and materials in our stock levels. This is how we plan to add visual clarity to our game and lead by example; community level designers using stock assets will also benefit.

Take a look at the image above. In this scenario there are three soldiers with three different types of uniform. Can you tell the difference with one look?

For the next scenario, we’ve taken the same scene from above but reduced the contrast of the level lighting setup and cleaned up any additional material functions. Then, we brightened up and desaturated the background against which the character will be tested. On the spectrum of light and darkness, we're pushing the character out on a different point of the spectrum than the rest of the level materials/textures. It's a compositing technique, commonly used in art and design to make specific things stand out from the rest of the art piece.

(This is one of the many techniques we as game/level designers and the community map makers can use to achieve peripheral vision clarity, where now, no matter where you look in the scenario below, the enemy character models will be visible.)

Direct image slide comparison can be found here[imgsli.com].

The main goal with visual clarity is for the player model to be distinguishable from terrain and objects in the level, specifically when similar textures, tone of colour or contrast conflict occurs. Future changes to visual clarity need to take into account this ‘relative’ relationship between the elements.

At the moment, it spoils our players’ fun (mine, too) that the enemies can be on your screen without you being able to see them. While that may be realistic in a real combat encounter, that is not the gameplay we envisioned.

A player should be visible with a single glance at the surroundings; they should contrast the environment. This is for the sake of gameplay and we’ll sacrifice some of the realism and graphical quality to achieve that once more.

Try to spot the second character in the above scenario.

Direct image slide comparison can be found here[imgsli.com].

Now that I am taking over the gameplay design decisions on this front, I will be making sure personally that this issue is fixed. I will be cross-referencing all of our official stock levels and changing them as needed in the future to allow for the player to be seen with a glance in the most vital parts of gameplay. This means that I will be making some changes to the uniforms, materials and objects commonly used in our internal level design workflow, as well as in EDDIE, the public level design tool; in fact, that was the goal of having new characters being made, too – improved ease of use and flexibility.

Speaking of new characters, a while back we shared work-in-progress new character model shots; you might be surprised to find out that we've shelved these characters. This was done because the source content did not meet our technical standards. We're looking into new options and opportunities for new characters and animations; in the meantime, we'll continue using our existing characters, making the best out of what we've got by applying contrast and colorology theory as mentioned above.

Unfortunately, our current characters are stuck with one huge problem in terms of fundamentals of game design as part of the model: the fact that they wear a mask (with the void underneath it!)

To shed some light on why this is a significant factor: when a character wears a mask, it takes your brain a significantly longer time to react to the information on your screen that you are looking at a person and not an object in the environment. The best course of action in terms of first-person shooter design is for characters to have unobstructed faces and eyes; that way, when a player scans the environment, they’ll be able to tell apart an inanimate object from a player character without confusion almost immediately, without the delay of second guessing. So, when we do introduce any new characters, or end up modifying our existing ones, this will be a major goal: to avoid having fully masked characters in our game. We might opt in for half-masks, for example.

A part of the texture and material adjustments, we will be adding a hint of another colour to the uniforms of our characters. This small change will make a difference; adding even slight hints of another colour to the mix will affect how our eyes perceive the tone and colour of the characters against the environment. During this process, we’ll naturally be fixing any problematic darker tones or shadows within the game that we can find, as demonstrated in the above screenshots.

Currently, TFE renders both the player and the level geometry on the same “layer” or “pass” meaning that any effects we add to the level also apply to the player character and this can be problematic in achieving the desired results. To combat this, we’ll be looking into experimenting with modifying the shaders and splitting the rendering pipeline for the player character, which will decouple some parts of the relative factors in visual clarity management mentioned above.

This is where you, the players and the testers, will need to guide us in finding the issues; we can only find so many of those blending-in spots ourselves. We’ll need the guidance of our testers to QA test once we release new adjustments to the level, visual clarity, and characters.


Moving onto the last subject mentioned: the sound design and the footsteps.

There is no question about it: when you try our game for the first time, you’re greeted with the displeasure of being both blind and deaf, very strongly speaking. Visual clarity redesign will fix the ‘blind’ part of the equation for good gameplay feel and sense; however, that leaves us with sound.

Sound is a very important part of gameplay clarity: mainly footsteps and anything that affects the position of the player, the enemies, and the friendlies. On our development team, we’ve never had nor currently have anyone that is experienced with sound design. As an individual, I know what the sound should feel like in a first-person shooter and how it works as part of the sound system in Unreal Engine, but I don’t have the practical experience in this field to implement and reach our goals and vision for this at the moment. Should we find a Sound Designer and a specialist in this field, we’ll bump up the priority on this subject and discipline but until we can find one to work with us, in terms of gameplay balance, this is last on our list of priorities currently, though in relative terms it should be much higher on the list.

After I am done with the gunplay rebalance, I will be moving to work on Clarity for a long time, without really looking at anything else. Until we have a sound designer that can manipulate the sound to be close to what we envision it to be in Task Force Elite, we’ll need to figure this part out ourselves, which means a lot of experimentation and likely mistakes are to be expected as part of the learning process.

Therefore, I will mostly be focused around balancing our current audio and sound effects instead of adding anything new to the table, making sure their attenuation is reasonable. That is to say I will research and learn how to get our current audio to have hopefully better directional output, along with making sure the footsteps are heard and are very distinguishable between the various surfaces. Our level design should include more surfaces than just barely audible sand in objective spaces, so that’s something for us to take a look at too.

In terms of sound effects of weapons, right now when you get shot at it is very hard to tell exactly where you are getting shot from and that’s against our vision of gameplay clarity. So this will most likely be the second priority to adjust after getting the footsteps right. To introduce and solidify the walking mechanic and increase the tactical usefulness of stealth, the footsteps should be audible almost at all times when a player is close by and not walking. And although not realistic, when a player shoots, you should be able to pinpoint their location: both the direction and distance. The direction might actually be easier to work with; however, the distance might be tougher to implement accurately to the gameplay vision.


And there you have it. These are my goals in written form as part of dedicating my free time to the project and using most of my experience and knowledge on the subject of first person shooters and game design. Both in directing the gameplay and feel of Task Force Elite and helping with the hands-on implementation of the items needed to succeed in our vision. In terms of the gameplay vision that we had when we started this project, it was largely competitively focused, and a lot of the upcoming changes might feel wrong, misunderstood, or at times threatening to what parts of the community might like about the current state of the game.

That is very understandable, and I would like you all to be vocal about it, if that’s the case, and provide feedback to us on that matter. To further avoid this issue, with any changes we make we’ll try to make sure to explain the reasoning behind it, as to avoid any misunderstanding and for you the community to understand our thought process a bit more.

While most of us certainly don’t have the spare time to spend on writing huge development blogs and announcements such as this one (this one took far too long, and took away a bit from development time), I hope that this will change in the future, with the addition of a technical writer to our team who can write up new announcements and posts, without taking away large amount of time from the development of the game.

Thank you very much for reading, playing, and supporting our game. I hope the information I shared is going to provide some clarity on what the team is currently going through and what we plan to be working on next, and sheds light on how we will handle it to bring the project closer to completion.

As a reminder, you can contact us and ask us any questions on Discord via our official Red Spear Studios Discord server: https://discord.gg/redspear

Best wishes to everyone and for the project,

Signing out!
See you in-game.

Lucas ‘Demonic’ Musial
(part-time) Lead Game Designer at Red Spear Studios
(full-time) Technical Level Designer at Kythera AI

Hi Everyone,

This is Part 2 of a 3-part blog. If you haven’t read Part 1 yet, I recommend reading it first! You can find it here.

I have a vision for Quality Assurance. I want to build a task force for internal gameplay testing before an update reaches the live servers. To this end, I have requested a better Internal Testing Environment. It will also help other team members in creating their own QA teams.

Up until now, our outdated QA systems meant that whenever we wanted to test a newer version of the game, the live servers had to go down. This was and is unacceptable and I would like to apologise. I hope it never happens again.

Due to that limitation, we had limited opportunities to test the updates before they reached you, the community. Even when we did perform tests, we found only 1/10th of the issues that were reported to us after the released update (TFE 4.4). It’s crucial for us to be able to test with more players first and on a wider range of machines, before releasing it to the public.

The team goal is to have an entirely separate master server for the testing environment and update that testing environment more often, with an automated process to pull and build from our project source so that any of us on the team and selected individuals can simply jump on in their own time to test changes and provide feedback internally. This will be especially helpful for our team, since members work different hours across multiple time zones from around the world.

For me personally, the goal for the Testing Environment is to build a flexible team of community testers that I know will be able to provide very good critical and constructive feedback on the changes being brought forward for discussion. This will be a layer of QA testing before it reaches the public. I already have a list of a dozen or so individuals who would be suitable for such a task, who would potentially help me to reproduce gameplay issues and to provide feedback during the rougher stages, and I’ve already spoken about this with a few of our pre-alpha supporters in the past. I want to make this team a reality; it’s the first major request from the Design Team to the new Programming Team.

If you’d like to volunteer your time, you think you’re a suitable candidate to have access to our internal test branches and would like to work with me by providing us with vital feedback in the pre-alpha stage of an update, send me a PM on Discord. I’ll take a look and evaluate your application. Should you ever want to make this your career and enter into the video game industry, do please tell us and we will consider taking your cooperation a step further in the future.

Join our official Discord server here[discord.gg]!

The format of the QA process should be in this order:

• Live Game
  
• PTR (Public Test Realm)
  - a downloadable and publicly accessible wider test branch to stress test the servers
  
• ITR (Internal Test Realm)
  - a standalone limited-access Testing Environment for selected individuals
  
• PIE (Play in Editor)
  - what we use to test basic functionalities before pushing changes, often providing different results than standalone servers

One could argue that in its current state, TFE has the same function as the PTR. This will change after full release.

Since Early Access is essentially our PTR, as some of our communities have mentioned, as TFE grows and as we expand our target audience, Early Access will become the Live Game, and our experiments will need to be tested first in ITR, followed by PTR.

Therefore, the testing environment will be a vital piece of the puzzle to get absolutely right, that is if we want to increase and maintain/restore the quality of our updates, and be able to test our full builds more vigorously and robustly before they go onto the Live Game servers.

A rough outlook shows that we’ve got about half a year of work on the updated Unreal Engine version done. The progress is not lost; we have simply reverted the Live Game back to Unreal Engine 4.23 (TFE 4.3.1) so that we do not cut off the playability of our game.

With that revert done, once we have a fully functional Testing Environment, we’ll be able to properly test the updates on the version of the codebase and Unreal Engine (4.25, 4.27+). These tests will hopefully allow us to catch any crashes or common issues for our programmers.

In theory, this will let us continue to upgrade to newer versions without affecting the live playability of the game. We will also have a wider spectrum for testing large builds, such as the 4.4 build.

Right now, the priority is to be able to compile and build the latest version of TFE builds on newer versions of Unreal Engine: to be able to play a few maps in a row without crashes!

-Demonic

Stay tuned for Part 3 of Demonic’s development blog.

Hi Everyone,

My name is Lucas [Demonic]. I’m an ex-competitive FPS player. I was, officially, Lead Level Designer from 2019 to early 2021, though since I've been mostly supporting the project from behind the scenes. I have done a lot for this project over the past 5 years (wow, it’s been this long already?), way before early access was released and before the company was even formed. Basically, though you may not have heard of me, I am one of the core members from the very start of the project, one who had an impact on the decisions and gameplay vision of TFE — pre-alpha, alpha and early access.

Before RSS and before TFE, my dream has always been to build a spiritual successor to the old titles we know and love. That was my sole original purpose for pursuing a career in the video game development industry. I was going to build a team and build this dream game myself after acquiring the necessary education, knowledge and experience to do it right, to do it properly. If TFE didn’t exist I would have remained dedicated to this vision. The spiritual successor would be made regardless.

Life is full of surprises and a start was made when an opportunity to work on a project now known as Task Force Elite (maybe you’ve heard of it?) arrived on my doorstep sometime back in 2018. In terms of my own development, it started as a hobby and a great learning experience. Later, it was a part-time job during my video game development studies. Afterwards, it was a full-time job in 2019, before returning to being a hobby near the end of 2020.

Even if the core members from the early days were to step away from working directly on the project, we still feel responsible for leading and for supervising the vision of what the game is supposed to be, what it’s supposed to feel like. So, until we can be fully replaced (can AI be trained to be Demonic?), we will stick around, forever pillars of the project. Profit is not our aim. It never was.

Luis [Psycho] has selected me to continue the vision, to supervise and to mentor new members. With support from Luis and others, I will be functioning as Lead Game Designer at RSS, and will continue to supervise the design contributions to the project.

That said, I can only do so much for this project in a short amount of time. My contribution will be seen and noticed mostly in the long term, as I too have professional commitments during the weekdays which I love and enjoy, and I simply choose to help out and support TFE during my free time strictly on the weekends.


With that introduction out of the way, I would like to share what we’re currently working on.

Due to the decision to revert the TFE patch from 4.4 back to 4.3, we’ve got our hands full with identifying what and where things went wrong, while incrementally adding stuff into an older and more stable version of the game, whilst also onboarding new team members, trialling potential contributors with most of that taking place on weekends.

Here’s what the team has been up to:
‣ At the start of the year, I worked on porting the weapon and gunplay changes from Unreal Engine 4.25 (TFE 4.4) back to Unreal Engine 4.23 (TFE 4.3.1). It took longer than expected due to the fact that unreal assets are not backwards compatible and my time has been occupied by mentorship, supervision, and a large part of writing this blog and announcement. The reason for going back and applying these changes to the older version is so that while we’re waiting for a stable build of a newer TFE engine version, we can continue to collect feedback on the gunplay balancing, as well as to have enough testing time during multiplayer scenarios to gather data. I am currently collaborating with other designers on fixing visual clarity issues and adjusting gameplay bit by bit. More details on this in the next parts of the blog.

‣ Seth is currently focusing on learning the codebase, debugging and building the game from the source while fixing things he finds along the way with Jake; the goal is to release a new version of TFE on a newer version of Unreal Engine. After learning the code base, which will take some time, the plan is for Seth to start working on the game code directly. Since our goal is to find more C++ developers for the future, we’ll have more opportunities to work on new features and mechanics. Seth is improving our internal code documentation and workflows so that new developers in the future have a shorter and more comfortable onboarding process. Seth is crucial and we’re very glad to have him on board!

‣ The Jake, despite officially stepping away from the project back in 2021 due to his own professional commitments, has been supporting and helping us with all sorts of technical questions and issues and we greatly appreciate his time and efforts in the process of onboarding new team members. (Thank you so much for your continued support!) Recently, he’s taken steps to bring TFE to a newer version of Unreal Engine, working on it directly with Seth.

‣ Daniel, as mentioned in his post last month, will be looking at the roadmap and plotting a path for us to take, given the recent changes to the team. All the while, he will be collecting feedback from the community, organising it and presenting to the dev team for added efficiency. (Daniel’s determination and passion for the project is contagious!)

‣ Luis is tirelessly working on business opportunities for RSS to grow. This task is no easy one; his goal is to ensure viability and longevity for the project. The future of TFE is one where it supports itself financially without our own finite personal financial investments.

‣ Edwin is managing our servers. He keeps them running as smoothly as they can.

‣ Matias is another of our core members from the beginning of the project, responsible for upholding the original vision of the game. He is currently unavailable to help us out with the game directly due to professional commitments. That is about to change, as we have plans to onboard him to contribute directly in the near future, starting out as a Junior Gameplay Developer, though he also can contribute by supervising other core concepts of the project. We look forward to having him back when the time is right.

‣ Franek is responsible for helping our newest community map makers bring their first maps from zero to completion. He works on documentation for TFE and RSS. Franek will also be in charge of our social media accounts and will prepare and release announcements and future blogs to the community.

‣ Matt has joined us recently, as a contributor and partner who also helps out the project during his valuable spare time. We really appreciate having another experienced designer joining our team. He's currently hotfixing many of our assets that are used across our levels, improving the performance, visual clarity and overall quality on an older version of the project. We plan to bring his changes and all of his contributions to the next following updates as soon as possible.

We do also have cool stuff happening in the background involving other members of the team that we are not ready to talk about yet, and if those items are proven to be successful they’ll be revealed sometime over the course of the year, bit by bit.


As briefly mentioned, potential new team members are also taking part in trials to work directly on the game: C++ developers and new designers alike. They will be vital for reworking and polishing levels to raise the bar and take TFE to the next level. They will have our full support to ensure their work is in keeping with our vision.

An area for improvement for us internally is documentation of the project and workflows. Only recently has it become clear just how important documentation is for new members to be onboarded, and it’s for this reason that the onboarding process takes much longer for us than is usual in the industry. It is a mistake we will learn from and it will help us with TFE in the long term.

-Demonic

Stay tuned for Part 2 of Demonic’s development blog post due next week.

Dear Friends,

I would like to be open with you about the future of Task Force Elite as a game and the future of Red Spear Studios as a team. I want to provide clarity on some speculations and false information floating around about what is going on behind the scenes at RSS.

As many of you are aware, there have been changes and challenges the past year, within our team and regarding TFE as a project. There has, unfortunately, been a failure to deliver on promises to you, the community, as well as a lack of communication and game service issues.

We have a vision and we are moving forwards. We will build on what we have started, we will complete TFE and we will grow together, as a community and as a video game studio.

I would like to inform you first and foremost that Luis [Psycho] will be handing organisational and day-to-day operation duties to me as the new Managing Director. Luis will remain our CEO. Luis' vision, passion and expertise remain crucial for us, and he will continue to work on the commercial side of the studio by securing projects, IP licences and funding to grow the business and its products.

I, Daniel [YP], have been selected by the team to lead as the new Managing Director, with Seth [IcIshoot] as second in command, as our CTO. We have the whole team's fullest support. Both Seth and I are now dedicated full-time to lead the project, taking special care to improve communication and ensure steady development.

I have started my new assignment by reviewing our existing roadmap. This roadmap was planned with a different approach to roles and tasks for new team members. A lot has changed, so a new perspective is necessary.

It is important to make clear that our core team is currently composed of hobbyists dedicating their spare time to a collective vision. During 2022 we hired multiple people on a paid basis, to perform specific scope tasks within the project, as we currently continue to do so. An important takeaway is that both Seth and I have gone into full time leading the studio. The remaining team members work variable hours and contribute to the project through sheer will, determination and passion. Even if one team member can contribute only a little in a given week, progress is progress.

However, putting a hard deadline on this kind of working environment has detrimental effects in the long term — for the team, for the project and for the community. Together as a team we have concluded that we cannot provide public release dates for updates moving forwards.

Unfortunately, one of the events that had the most impact in our progress was that our Lead C++ Developer, who joined us in May 2022, had to step down for personal reasons last November. Currently, Seth will be overseeing decision-making and C++ development until further notice.

We have a budget for additional hires, but we have been unable to find the talent at an affordable cost. We are also looking to add more Unreal Engine C++ developers to our team to share the responsibilities for a healthier working environment which will increase productivity and allow us to develop TFE faster and to implement the features we desire.

On behalf of the team, I apologise for the lacking standard of communication of the past.

With our new structure, and with your patience, understanding and continued support, I believe we will overcome these obstacles and deliver the game we all want.

Daniel [YP]
Managing Director
Red Spear Studios

Stay tuned to the TFE Development Blog to catch up on the latest TFE-related news, announcements and stories.

Hi everyone! We are happy to finally release the Update 4.4. We are sorry for the delay, but we faced some significant technical challenges after submitting the shipping build to Steam. Fortunately that is now resolved, in the most part, and the update is now ready to be tested by all of you.

We understand that there will be bugs and other issues that we may have missed during QA testing, and we request all your support by reporting any and all issues you may find as well as feedback about the improvements we've made.

We have some known issues that we need to report, the main one being:

- Map vote system is unoperational. We request servers hosts to keep map voting option off. We're working on this issue.

We are going to release the changelog and patch notes soon. For this update, it represents 6 months of work, and its quite extensive.

Also we're almost ready to release the Website & Forum as well as a preview for the maps and map overhauls coming in the next update.

Important information for Servers Hosts

Server admins have to start the server now not with steam but have to start the C:\Program Files (x86)\Steam\steamapps\common\TaskForceEliteDedicatedServer\CommunityTool\ServerManager.exe

If you start it by steam you wont see your server in the game lobbie


Thank you for your continuous support.
RSS Team

We would like to invite you to participate today in our AMA, to take place in 30 minutes (July 31 at 4pm Central European Time / 3pm UK / 10am EST) in our official discord channel: https://discord.gg/redspear


The following are estimated times for release. The features mentioned per version can be changed without prior notice on the course of development, but remains our goals for each version.

The planned versions and release dates:

Version 4.4 ― October 2022
Version 4.5 ― November 2022
Version 4.6 ― December 2022
Version 5 Beta ― January 2023


― Version 4.4 ――――――――――――――――――
- Upgraded engine version to 4.25
- Multiple bug fixes as reported by community
- Performance Optimizations
- Delivering custom maps more efficiently
- Reducing custom map sizes greatly by increasing default game installation files
- Improved and further developed community platform in web
- Improved sound design in stock maps

― Version 4.5 ――――――――――――――――――
- New Unique Experimental Gamemode - We hope to become mainstream on public servers (not competitive)
- Directional sound and sound oclusion improvements

― Version 4.6 ――――――――――――――――――
- Steam Workshops integration for Custom Maps
- In-game store for cosmetics
- Overhauling Team Conquer game mode
- Steam Achievements API integration
- Trading XP for cosmetics
- Additional content for unlock
- Improving AI behaviors for bots
- Adding new map vote full screen at end of round
- Improved scoreboards

― Version 5 Beta ――――――――――――――――――
- New Matchmaking system
- Early access rank and stats record on profile and full stats reset on full launch
- Improved inventory system
- Integration with voice system for in-game voice chat
- Ranking system overhaul
- New Leaderboard system
- Additional API features open to community
- Improving game scalability. Goal is to achieve 32-player servers
- Profiling and optimizing netcode further
- New Tutorial system for new players
- Killcam: show killer perspective for 3 seconds (3rd person view) to dead player. Does not repeat the shot (for official servers for new arrived players up to rank 10) - Additional data points for advanced stats
- Flagball game mode (post-launch as season special)
- Adding best custom maps done during Early Access into game default for best user experience at full launch


― Version 4.4 ――――――――――――――――――
- Improving gun values and handling. Slightly higher time to kill
- Total Character redesign
- Dynamic PSP timers and penalties
- Tweaking scopes FOV
- Improving utilities bounce physics
- Flash utility improvement
- Re-adding red Smoke grenade (keeping white as option)
- Character Movement improvement with and without ADS
- Multiple polish features on character movement and mechanics
- Improving auto-attach to ladder angle
- Adding quality of life option to opt for press-key to attach ladder
- Removing top of ladder animation
- Attaching to ladder wont reset player point of view
- Adding new graphical configuration to reduce greatly any red-dot ghosting
- Improving performance options on settings to have better impact on player experience
- Adding battletag feature: Toggle between full nick, battletag or triangle
- Fixing scopes seeing through smoke
- Adding Raining mechanic blueprint

― Version 4.5 ――――――――――――――――――
- Slope movement speed adjustment based on angle
- Adding knockdown animation when explosion happens within close radius
- Improving transitions between crouch and standing and from prone to standing
- Swimming and diving mechanics with fatigue
- Adding destructible props

― Version 4.6 ――――――――――――――――――
- Adding first person view for Spectator Mode
- Adding reticle scopes model options and customization
- Adding reticle to AK47 as an option
- Adding hold-to-use key to change to knife with special animation
- Third-person view camera at map start
- Revamping Night Vision (first we'll remove it in next update)
- Adding tracers (for night maps) as server option
- Improving HUD for Spectator Mode
- Additional weapons including silencers (tbd)

― Version 4.4 ――――――――――――――――――
- New Game Menus
- Polish to In-game minimap
- Polish to In-game tactical map
- Improving chat UI

― Version 4.5 ――――――――――――――――――
- Adding icon in server browser to show Free-to-Play servers
- Polish to In-game HUD
- Adding icon in server browser to show servers running custom maps
- Adding icon in server browser to show servers running maps with big file sizes



― Version 4.5 ――――――――――――――――――
- Adding Rope-down mechanic for Black Hawks
- Option to turn off vehicles in server-options for all maps in rotation
- Adding .50cal to Black Hawks and Humvees
- Adding destructible vehicles
- RPGs will destroy vehicles killing occupants
- New debris mechanic for destroyed vehicles

― Version 4.6 ――――――――――――――――――
- Adding Zodiac vehicle (attack fast boat) with .50cal



― Version 4.4 ――――――――――――――――――
- Overhaul of all stock maps
- Map lighting improvements
- New stock maps

― Version 4.5 ――――――――――――――――――
- FPS optimization of all stock maps



― Version 4.4 ――――――――――――――――――
- New minimap and tactical map auto-make feature for Eddie
- New assets including unique customs
- Upgraded version to 4.25
- Existing custom maps will have to repackage for new version

― Version 4.5 ――――――――――――――――――
- Design and Feature overhaul of Server - Windows Server Tool



― Post Launch ――――――――――――――――――
- Full coop system and official missions to be released as DLC post-launch

Patch notes:
-Night vision (press "N" by default or rebind)
-Change Loadout in dead screen-respawn phase/pre-match
-New reload mechanism
-Several small bugs fixes
-New map: Bank crash by Night (most voted by community) available in TKOTH, TDM, DM, CTF and Team Conquer
-Server browser server list now presented by desc order of population

Have fun!

Hot fix for Early Access 4.0
Full changelog:

• Fixed stats not showing correctly in profile page
  
• Fixed missing default spawn key for Indian outpost/checkpoint
  
• Added sounds for checkpoint ignition process
  
• Bravo checkpoint fix in Bank Crash Team Conquer
  
• Moved checkpoint A on Desert Valley Sunset - Team Conquer
  
• Moved spawn of TFE on Desert Valley Sunset - Team Conquer
  
• Added cover/buildings for TFE spawn at Desert Valley Sunset - Team Conquer
  
• Increased size of zones for all Checkpoints of Airbase
  
• Increased size of zones for all Checkpoints of Bank Crash
  
• Fixed Bravo checkpoint on Bank Crash

Important Note:
If you're having problems spawning at Checkpoints, please reset your key bindings in game options.

Early Access 4.0 is now out! As we get closer to the full game release, this new update introduces a new game mode: Team Conquer, as well as several improvements, content, tweaks and fixes to the game.

EDDIE, our upcoming custom map maker, based on Unreal Engine 4 platform, which is the most asked feature by the community, is now completed. We're currently working on the documentation, tutorials and file system clean up to reduce the HD Requirements for the tool. We've also completed the integration with our server manager tool, to create a seamless experience for map makers and server hosts. EDDIE will be subject of a separate release, first dropping to the map makers who have signup on our official forums, www.taskforceelite.com, up to March 15, as alpha testers for the tool. We will get in touch with the testers in the coming days, after we address any issues or bugs that may arise of this new update 4.0

We'll continue to polish and debug the game further in coming weeks, before we announce the date for the full game release. Thank you for your support.

The full changelog:
-New Game Mode: Team Conquer
-New map overhaul: Pharaoh (Team Conquer)
-Added Team Conquer support to multiple existing maps
-Added addition check for storage access to fix the - infinite access to storage
-Adjusted outpost spawn armour: reduced by half
-Increased time cooldown for spawning on outposts
-Updated personal profile stats from official to global
-Added delay after applying class change from storage
-Fixed E outpost display issue
-Game voices overhaul
-HUD TKOTH display bug fix (experimental)
-Abandoned Airbase zone setup overhaul (to attempt a fix on zone bug displaying wrong number of players inside)
-Replaced duplicated rank images for general classes
-Update to server tool to fix auto-crash and add Team Conquer

Team Conquer.
How it works?

-There is a new type of objective: Checkpoint.

a) Checkpoints work differently than the traditional Outposts. Checkpoints come in two forms: Spawnable and non-Spawnable. The icon for both is slightly different.

b) If you attempt to conquer a Checkpoint, you touch the flag pole but you need to make sure that there isn't enemies inside the zone of the checkpoint (yellow area on radar/map). If enemies are inside the zone, the progress bar to conquer the checkpoint is halted, and it resumes once you eliminate all enemies from the zone.

c) Some maps are using large zones while other maps are using small zones. This is experimental to better understand the game flow on both styles.

d) If your team holds all checkpoints, the timer starts counting, and after a certain period of time, if you continue to hold all checkpoints, you win immediately

e) If a team holds all checkpoints, and the timer is counting, but the enemy touches the flag pole of one of the checkpoints, the timer is halted. It only resets if the enemy succesfully conquer the checkpoint.

f) Bots will now attempt to conquer checkpoints and play for objectives

Have fun!