Arid Asyncronous Experiment: Part 1

Ever since Arid’s release, I’ve been exploring ways to implement a form of multiplayer to see if experiencing distant connections can lead to interesting gameplay. Distant connection, because a direct co-op multiplayer is both too clunky to develop and does not fit Arid’s core vision. 

This ‘distant connection’ then had to be some sort of asynchronous multiplayer, where players can ‘feel’ the presence of others, but not like in traditional MP games. Our first idea was to add a system of leaving notes for other players, similar to that of Dark Souls 3. In Dark Souls this works great, but in a deeply immersive hardcore survival game like Arid, reading other players' notes could be distracting and immersion breaking. Besides that, there is the issue of content moderation.

Having parked that idea, the next feature suggestion was a way to somehow let one player's experiences influence the game world encountered by others. The whole idea of having your own actions change the world & playthrough has been done again and again by many great developers, but the idea of having your game world being changed by the actions of others is different and could lead to interesting moments.

To make it more concrete, imagine a system where certain player actions in Arid (like lighting a fireplace, building a bed, collecting resources in certain areas) has effects in other worlds. Lighting fireplaces could for example lead to other players finding remnants of this fireplace, either visuals or items, in their world. Another example could be hunting; if one player spends a lot of time hunting animals in one area, other players could find more animal remains.

The challenging part here is finding the right balance between too much or too little change to Arid's core gameplay. For example, a player collecting all resources in a specific area resulting in fewer resources in that area for other players is too big of an impact on the core gameplay.

The Idea

A few months ago I wrote an article on Dredge. In this game, the entire atmosphere changes based on certain actions you take, which gave me a slightly creepy and eerie feeling - but not too much. It was a subtle yet consistent experience, which made me think: What if we add a mechanic to the game that changes parts of Arid's map slightly, but just enough to give players this 'eerie' feeling?

Arid is a game full of death and remnants of past explorers & settlers, inspired by the Atacama Desert. During our exploration and research into the atacama, we discovered many abandoned cemeteries from the Atacama's golden age of saltpeter mining. These cemeteries immediately gave me an eerie, dreadful feeling - Perfect for our experiment.

My idea is fairly simple. We have a system that collects player death stats in Arid and from those stats we get the area with the most player deaths. This area in game would then get effects to mimic this eerie, dreadful experience (think slight greyscale, sound effects, whispers, etc). This area however shifts based on where the most player deaths occur.

The reason I'm keeping it simple is to allow for easy experimentation but also easy expansion later on. In the future, we can also adjust the world by dropping for example more grave markers in the #1 death area, or put certain broken materials / furniture in that area.

To properly design this dread system, I went back to the basics. First thing to do was to establish the goals and problems that the feature tries to achieve / solve.

The Design

Goals

• Create a dynamic, atmospheric point of interest on the map that reflects collective player experience.
• Enhance world immersion by having the environment react to player actions (deaths).
• Provide a subtle, evolving environmental storytelling element.
• Lay a foundation for potential future mechanics (e.g., unique interactions or "note" systems within the dreadful area).

One important thing to mention here is that I originally intended on changing the experienced story based on player actions dynamically, hence goal #2. It does not fit the feature perfectly, but is still a key element to remember in the design of this feature.

Player Experience

• Players will notice one area on the map feeling significantly different – visually darker, more desolate, with e.g. unsettling sounds / visuals.
• The location of this dreadful area will shift over longer periods, reflecting where players are collectively struggling the most.
• The system primarily serves an atmospheric and environmental storytelling purpose. (Future extensions may add gameplay mechanics).

Technical Considerations

• Time Decay Algorithm: A simple percentage decay or a fixed reduction per update cycle.
• Server Update Interval: Balance responsiveness with performance and preventing "flapping", where the dread area constantly switches between the top 2 areas.
• Client Update Interval: How often the client checks for the active dread location. For experiment sake, we'll only do this on beginplay.
• Area Identification on Client: Robust method for determining which Area_ID the player is currently in (Possibly trigger volumes since Arid already utilizes those for area definition)
• Smooth Effect Transitions: Implement fading/interpolation for post-processing and audio. (FMOD)

Experimentation

Okay, enough design talk, let's move on to the actual experimentation.
For the backend,

Data flow / Server-side logic

1. When a player dies, the client sends a message to the server, containing area_id, timestamp and player_id

2. The server then receives the reports and stores them in a database table. For example: "area_death_counts = {"Mine_Entrance": 150, "CebollaUnaBase": 75}

3. The server calculates and assigns "Dread levels". This can happen on each death processed, but considering a potential production environment, I wanted a less taxing system. For now, we'll define a 'dread calculation task' that runs every 15 minutes. This task will:

   • Run a "decay" check, which reduces all death counts by 5% per hour to balance them out.
   • Sort the areas by their death counts in decending order
   • Assign dread level based on the highest death count area.

4. Then, when a player loads the game (on beginPlay), we load the Dread levels on the mentioned areas. This is done by making a GET request to the server.

I'm not too experienced with game client / server connections, but a simple API setup would work wonders for both building my skills and experimenting with this concept.

After some tinkering, I've managed to code a simple python API which should be able to handle all required functionality (and more!).

More to come later!