We Have Updated the Aimlabs Creators Studio!

As part of our on-going efforts to continue to evolve and improve Aimlabs and the tools that power Aimlabs. We’ve worked with some of the top creators in the aim training space to add a number of new features to the Creators Studio that will provide task designers with even more control over bot movement control, spawn behaviors, in-behavior conditions, and more!

We’ve also introduced more control over the tasks, such as FOV lock, the ability to disable cosmetics or override health bar size, and changes to the floating start position!

If you’re curious to see how some of these changes might apply as a player, check out our New Creator Studio Features Showcase playlist!

Here is the full list of whats new:

Velocity Controls and Transitions

This is comprised of two important additions, “Velocity Controls” for bot movements, and “Transitions,” referring to the act of either going from one bot profile to another, or from one movement behavior to another.

Velocity Controls – Three new settings have been added to control “velocity” (meaing acceleration and deceleration.) The current Dir Change Speed value was kept to maintain backwards compatibility but we added a specific value for acceleration rate and deceleration rate (both expressed in m/s^2) and a max terminal velocity. These settings allow for a much better control of how targets can move when changing directions and is a significant step up from the current “dir change speed.”

Both options are shown and there is a new system in place to choose which one is prioritized, so they don’t clash. By default, it uses the old “dir change speed,” with the new settings being at a default value of “0,” if you change these values, then the new system takes over.

Transitions – Regarding “bot switch condition,” which is a spawner modifier that allows you to go from one bot profile to another based on a specific condition chosen by the creator (ie time, bot health, etc,) the addition here is the new inherit speed option which goes from 0% to 100% and determines how much of the previous bot’s speed gets translated to the new bot based on it’s acceleration parameters. This makes the changing of bots way more seamless since the new bot basically carries the momentum of the previous one, making it less obvious that it’s actually 2 (or more) different bots, and making it seem like it’s actually just one.

Juking and Fakeouts

This is a feature that allows bots to “pretend” they are changing directions to throw off players. This is useful for more complex movement patterns and to better replicate movement techniques found in real games. In practice in a task, the bot slows down or will do a small stutter motion to simulate a direction change, but instead of turning to the opposite direction it keeps going in its original direction.

This works by first giving the scenario creator the ability to choose a specific likelihood of this happening with the Fakeout Chance (%) option, and then being able to select how long the duration of the fakeout should be between a min/max value in seconds. The min speed of the fakeout in % and also a cooldown for this happening, which is also in min/max seconds to prevent the juking to happen too often if desired.

On Spawn Behaviors

This is comprised of two features that share that they happen, or they affect something when the target first spawns. They are “Spawn At Full Speed” and “First Direction Change Interval.”

Spawn At Full Speed – Previously, if a bot did not have instant acceleration enabled (meaning it needed to accelerate to reach full speed when changing directions,) it also affected how it behaved on spawn. Newly spawned targets begin almost static and must accelerate up to their desired speed. This created an issue where players can “farm” fresh spawns, since they are significantly easier to eliminate compared to bots that are already in motion.

To address this, a new option called Spawn At Full Speed was added. It’s a toggle that is turned off by default to preserve backwards compatibility. When enabled, newly spawned targets immediately move at their maximum potential speed, making them much harder to eliminate.

First Direction Change Interval – This feature allows you to override the normal strafe timing parameters of movement behaviors (“strafer” for horizontal movement, “vertical” for vertical movement, and “forward/back” for the Z axis) specifically on spawn. It lets the creator control when the very first strafe happens after a target spawns. This first direction change can occur earlier or later than it normally would based on the standard strafe timing settings. Once this initial interval is completed, the target returns to its regular strafing parameters.

In the editor, this is implemented through a new First Direction Change Interval option within the strafing settings. It is set to 0 seconds by default, which effectively disables it. The creator can then choose a specific value in seconds to determine exactly when the first direction change should occur.

In-Behavior Conditions

In-behavior conditions, called Conditional Overrides in the editor, are a new option added to the three main movement behaviors (“strafer” for horizontal movement, “vertical” for vertical movement, and “forward/back” for the Z axis). They allow creators to introduce new behaviors dynamically to a specific bot based on chosen conditions, such as time alive or distance to the player, without relying on bot switch conditions. Unlike bot switch conditions, which are applied at the spawner level and replace the original bot entirely, conditional overrides modify behavior directly on the existing bot.

In the editor, this is handled through an “Overrides” list that is set to 0 by default. The creator can increase this number depending on how many overrides they want to add. For each override, they can drag and drop a behavior into the new Conditional Overrides slot and define the condition that will trigger it.

By default, when the condition is met, the new behavior fully replaces the original one. However, there are additional options available. If the Additive option is enabled, the new behavior will work alongside the original instead of replacing it. There is also a Toggleable option, which allows the behavior to turn off if the condition is no longer met. For example, if a behavior activates when the bot is within 5 meters of the player, it will trigger at that distance and autoically deactive once the bot moves further than 5 meters, reverting to the original behavior.

This feature also includes the Inherit Speed option mentioned in the Transitions section above, and it functions in the same way.

Lookahead and Wall Avoidance

This feature prevents bots from colliding with walls and other objects by giving them a lookahead distance (in meters,) so they can change direction before actually hitting something. This is a very useful behavior that was previously impossible to achieve in Creator Studio. Previously, when a bot ran into something with collision (ie another bot, a wall, a blocking object, the player, etc,) it will collide, bounce off, and then change direction. With Lookahead enabled, the bot is constantly scanning a set range ahead of itself, and if it detects an obstacle, it will strafe in the opposite direction to avoid the collision altogether.

In the editor, this appears as a field where the creator sets the Lookahead value in meters. It is set to “0” by default to preserve current behavior and ensure backwards compatibility.

There are also additional toggles that let the creator decide what the bot should treat as blocking. By default, these are all disabled, meaning the bot only avoids static level geometry such as walls. The creator can optionally enable: Detect bots as blocking so the bot avoids colliding with other bots, Detect player as blocking so it avoids colliding with the player and Detect blocking objects so itavoids special invisible gameplay blockers (such as the “blocking cube”.)

Absolute Strafe Timings

This feature applies to the main movement behaviors (Strafer, Vertical, and Forward/Back) and ensures that bots only change direction based on their defined strafe timings, not upon collision. This was previous impossible in Creator Studio, as bots always bounce back instantly when they collide with something.

The solution was to introduce a Change Dir on Collision option. It is enabled by default to match existing behavior and preserve backwards compatibility. If this option is disabled, the bot will only change direction when its strafe timing dictates it should. It will no longer instantly reverse direction upon collision.

For example, if a bot has a strafe timing of 4 seconds and hits a wall at the 2-second mark with the option turned on, the bot will immediately strafe back, ignoring the remaining 2 seconds of its timing. With the option turned off, the bot will remain against the wall for the remaining 2 seconds and only strafe back once the full 4-second interval has elapsed.

Gravity Controls

This feature allows creators to change and control the gravity of a scenario. Previously, gravity was a fixed value that could not be modified. This is especially useful for bounce scenarios, falling targets, or any setup that relies on vertical movement. In the editor, the new gravity settings are divided into two sections:

Level Gravity – In the Level Settings, we added a new Gravity field set to 9.81 by default to ensure backwards compatibility. This value controls the gravity applied to all physics-based elements, such as the player and physics objects, but not bots. Increasing or decreasing this value will make these elements fall faster or slower. Setting it to 0 disables gravity entirely, meaning everything affected by level gravity will remain static in the air.

There is also a new Player Gravity toggle in the Level Settings. It is turned on by default to match existing behavior, as there was previously no way to disable player gravity. If this toggle is turned off, only the player will no longer be affected by gravity, meaning the player can remain static in the air while other physics-based elements are still affected.

Bot Gravity – Bots handle gravity differently from level physics, so a separate solution was required. A new behavior called Custom Gravity was added under the Manuevers category. This allows creators to control gravity on a per-bot basis.

To match the default gravity of other elements, this value needs to be set to 19.62. Adjusting it higher or lower will make the bot fall faster or slower, and setting it to 0 will disable gravity entirely for that bot, causing it to remain static in the air.

Misc Additions:

FOV Lock

This feature allows creators to define a specific FOV range that can be used in a scenario. It has been heavily requested and is very important for competitive integrity, as well as for ensuring that tasks actually train the skill intended by the creator. Without this, players can use extreme FOV values to gain an unfair advantage. For example, a task designed around very small, far-away targets can be trivialized by lowering the FOV to effectively turn it into something closer to Gridshot.

In the editor, this is implemented through two fields in the Level Settings that define the minimum and maximum horizontal FOV allowed. If the creator wants to enforce a single specific value, they simply enter the same number in both fields.

In-game, players can still move the FOV slider freely, but the value will always be constrained within the range set by the creator. For example, if the minimum allowed FOV is 80 and the player moves the slider to 20, the game will still render as if 80 is selected, since that is the enforced minimum.

If a player loads into a scenario with an FOV outside the permitted range, their value will automatically adjust to fit within it. An indicator appears in the top right corner to inform the player that their settings were modified.

Cosmetic Features Lock

This consists of two separate additions: disabling cosmetic skins and overriding the health bar size:

Disable Cosmetic Skins – This is a toggle found in the bot settings that prevents certain bots from having skins applied. Bots are not always used as targets, sometimes they serve as triggers or visual indicators, and applying skins can interfere with that purpose. From a competitive standpoint, some skins may also provide a slight advantage.

In the editor, this appears as a toggle called Disable Cosmetic Skins. It is turned off by default to preserve backwards compatibility, meaning skins can be used normally. When enabled, the bot will ignore any target skin selected by the player and will instead appear as the default target shape and size.

Override Health Bar Size – This is useful in scenarios where targets with health bars are not meant to be spotted before the actual target model is visible on screen. If a player uses a large health bar size, they may gain an unfair advantage by seeing the health bar before the bot itself.

For bots with more than 1 HP, a new toggle called Override Health Bar Size is available. It is turned off by default, meaning the player’s own health bar size setting applies as usual. When enabled, a new field called Force Health Bar Size appears. It is set to -1 by default, which means it does not override anything. The creator can then choose a value between 0 and 5 (which is the same range available in normal gameplay settings.) Once set, that specific bot will always use the defined health bar size, regardless of the player’s personal settings.

Floating Start Position

This is the ability to make the player float without needing to place an object under the playerstartposition. This is solved by the Player Gravity setting explained in the Gravity section.

There you have it! We hope you enjoy the new changes and look forward to seeing your creations with it!