top of page

Stamina Prototype

Highlights
  • Quick prototyping

  • Gameplay adjustments

  • Interaction with stakeholders

Context

As an internal project, the stamina system needed to be rebuilt completely.

​

The original design was so realistic that it ended up just being a super-complicated calculator expressed just with a stamina bar. Users had no idea what was going on behind that bar and the stamina was depleting at unpredictable rates.

​

The main goal of the new system to be built was simple: we needed a simple stamina feature preventing trainees from running around the whole time.

​

Since this was an internal improvement, stakeholders wanted just a prototype to get an idea and see if it was worth it to get a project out of it.

​

I developed this prototype alone and delivered it in one sprint of two weeks.

Workflow

Since stakeholders asked for a quick prototype, I picked the fasted option and implemented the system using SQF scripts (instead of C++).

​

Even when designing a simple feature such as a stamina system, it's always important to do a reality check and seek inspiration from references. Therefore, I started picking examples from my vast gaming knowledge and quickly gathered some examples of stamina implementation, going from simple ones like The Elder Scrolls V: Skyrim to more complicated ones like Star Citizen.

After this quick investigation, I had a better understanding of the hidden tricky details lying within such a task. For example: what happens if the stamina is depleted and the user keeps the sprint key pressed? And if the character is sprinting into a wall? Do the characters stop sprinting instantly when the stamina depletes or do they slow down gradually? Detailed design questions like these were soon joined by questions with a higher scope, such as: what if the stakeholders would like to have this feature influenced by others (e.g. the carried weight)? And how will the users be able to tweak the default values to customize the feature?

​

With these questions in mind, I started scripting the feature​.

At the end of the first day, I had a stamina value printed on screen through debug messages and when the value was 0, the character wasn't able to sprint at full speed anymore. Just a super-basic stamina feature, without details. Since the wanted quality was prototype-level, to make the character run slower, I was just slowing down the character's animations (which also affect the movement speed in VBS), without touching the actual movement speed values directly, not to waste time messing with the engine.

​

I created a short video and sent it to the stakeholders to showcase the advancement.

Then I started adding details. E.g. when sprinting against a wall, since the character stopped the sprinting animation, the stamina was not depleting even if the user was keeping the sprint key pressed, I added a delay to the stamina recharge to prevent it from making the character quickly pass from running to sprinting in a loop when sprinting after the stamina depleted, etc.

​

One of the most interesting aspects I worked on was the functions to determine the stamina depletion rate. I provided 3 simple ones:

  • y = x

​

​

​

​

​​

​

​

​

​

  • y = x^2

​

​

​

​

​​

​

​

​

​

  • y = x^0.5

​

​

​

​

​

​

​

 

​​

As part of the documentation I was creating, I also included a video showing the different depletion rates graphically:

​

​

​

​

​

​

​

​

​

​

 

 

 

The reason why I was going through these details was that I was tasked to provide an estimate for the proper implementation at the end, and I needed to get a grasp on the effort required to polish the feature.

​​

As expected, when gathering feedback from stakeholders at the end of the first week, they were curious about how it would have been possible for the user to tweak the values and to expand the system to rely on other features.

The first question had an easy answer: configs! VBS can rely on user-facing configuration files that allow developers to expose data to the user to be changed.

The second question was easy to answer, but a bit more tricky to demonstrate. In fact, I split the scripts into functions in a modular way, but I didn't make any other system interact with them yet. I was asked to show how the system would have behaved when interacting with the inventory (i.e. the carried weight) and the health (i.e. the less health, the less stamina, or the faster the depletion).

​

I focused my second week on implementing these dependencies and asking to other departments and colleagues for estimates about aspects I was less competent with. For instance, I asked the front-end department how long it would have taken to implement a simple HUD element for the stamina.

​

At the end of the second week, the prototype and the estimate were ready. It was possible to tweak the feature through functions and add dependencies to the inventory system and to the health system, also influencing how heavy would have been the impact of each external system on stamina depletion.

​

The stakeholders were happy, but the internal development project this effort was part of was canceled from above, so the simple stamina didn't turn into a proper project in the end.

​

I archived all the work and refined the documentation in a way that it will be easy to resume from where I left off, in the hope that one day I or someone else will finally bring this feature to life.

​

Here is a video of the finished prototype.

yx.png
yx2.png
yx05.png
StaminaDecreaseFunctionsVideoThumbnail.png
StaminaVideoThumbnail.png
bottom of page