AbsentLog
patreon
ABSENT LOG Dev Update 11/15/2024
🕑 Added 2024-11-16 03:56:01 +0000 UTC
This month, we're gonna get a bit more technical than usual.
Being that the holidays are coming up, it's going to be a bit harder to get a lot of pure content knocked out quickly, and to tackle big development items that are considered heavy time sinks. so we decided to tackle 2 big things, firstly, start getting the backlog of concepts made into game-ready assets, and to fully plan out and start developing how our save system and campaign progression will work, as we near completion of our first level.
WHAT IS THE PLAN FOR A SAVE GAME SYSTEM?
Originally, we were intending to have a manual save, where you could pause and save at any interval you wanted. We had set this up and it came with pros and cons. Pros was that it was convenient to save at any time, and load fairly seamlessly. It was straightforward to use, however due to the number of systems interacting with each other at any given time, it's not entirely reliable to snapshot everything happening in game. There isn't much control we had when it comes to saving enemy positions, what action an enemy is doing, player specific actions at that time, and depending on the scenario, loading a save from this could break several things, like being caught in a running loop, resetting stats, and other general headaches. This is not to say that it's inherently a bad system, but it needs a specific kind of setup both from the game play side and the technical data saving side.
We talked more about having a mixture of a predefined auto save state, and a save location instead. This would give us more control of what's being saved, less unpredictability when loading, and more accuracy overall on what is happening in the game level when a save game occurs. We started to think, outside of the technical implementation, how this could be introduced to fit the gameplay and the world structure. Exploration and investigation is a key aspect of ALOG, and you will oftentimes be traversing back and forth between various levels as your progress and more areas become available. With that, we thought that using a save station would be an ideal way to help create a “mental map” of an area, outside of an actual map.
Tekka had a brilliant idea, of an in game world explanation for save points being actual safe rooms:
“We could have a Sahmar Whisper Shrine act as the actual save station itself located in a room or a protected corner. We can even justify this in the fiction by determining that Peris (the antagonist), being an AI, is not permitted to witness religious observances around these shrines. So she doesn't have much influence in these locations. TW could use these shrines to her advantage to find respite from “unsafe” areas.”
We knew immediately this was a solid direction to go in. We are still exploring the visual aspect of this, we already have an asset built for a shrine, but we are exploring other ways to interact with safe rooms and save points, like performing prayers, or “waking up from a dream/sleep” upon loading the game into a safe room. For now, we have a clear idea on how we want to handle this functionality.
(An image cap of one of our meeting notes for save games)
WHAT IS THE CURRENT FUNCTIONALITY OF SAVE GAMES?
Currently, save games are fully functional in grabbing all player data, such as health, items, ammo, weapons, outfit, and saving and loading those items. We have fixed numerous bad reference bugs that caused data to become corrupted on loading, and it works smoothly now. Next step is to start saving world persistence, such as not respawning an item that's been picked up, or not respawning an enemy that is already dead
We have also implemented save game features into our first level and campaign structure. So as of now it is a baseline functioning save system for the campaign.
HOW IS CAMPAIGN FLOW BEING HANDLED?
(An image cap of one of our meeting notes for Campaign Flow.)
This one is a bit more obtuse, but given that ALOG is a nonlinear campaign, with multiple explorable levels that can be freely traveled between each other, a good way we have found to address this is by breaking down the story and objectives into a simple set of checklists.
We have planned about 7 levels in total, and we have separated them into 3 sections, “HEAVEN, PURGATORY, and HELL”
This moniker is purely for reference purposes and is not related to story themes at all.
Hell, where you start off in, will be levels such as Hangar/Flight bay, Engineering, Industrial, Resource Processing, etc…
Purgatory, will be sections like RnD, Logistics, Storage, Medical, Residential
Heaven would be areas like Computer core, Bridge/Administration, and Overlande.
Each deck or “level” has a checklist of booleans that need to be set to true (a boolean is a TRUE or FALSE statement in programming language, it is essentially a switch.)
If a level has several bools that need to be passed, we can set each bool as an “objective”
Example:
Level 5: MEDICAL,
Bool 1: Reset Security alarm
Bool 2: Get Acess Card
Bool 3: Get to John Smith’s Office
Etc…
Once all the bools for Medical are all set to TRUE, it sets a main level bool for Medical as true. Meaning that the level “Medical”, is now complete.
We also plan on having a section near the end, to act as a sort of “point of no return”. Here the player will be given the options to go back and explore more of the ship, wrap up anything they missed before they head into the final stretch of the campaign. At this point, everything up to the final 2 decks should be freely accessible, and the player can move to these sections as they please.
For the entire progression of the game, we will have a MASTER BOOLEAN list, that check if each level has been completed,
Example:
MEDICAL: DONE
ENGINEERING: DONE
RESIDENTIAL: DONE
COMPUTER CORE: NOT DONE.
As you progress through the game, you are performing actions and checking off these booleans, this is how we will gauge player progression through the campaign, as opposed to Level 1, level 2, etc…
And finally, once every bool in the MASTER BOOLEAN list is checked off, that results in a completed campaign.
On the engine side, this is a solid and super simple method we can use to reference things for completed objectives, completed levels, completed cutscenes, and completed puzzles. This also makes saving your progression simpler as we simply need to save and load what booleans in this list are complete, and then just load what is there.
COMPLETED GAME ASSETS:
Below are some of the recently completed game assets from our backlog that will be implemented in-game, these are mostly intractable items, so they will also need a bit more setup than simply being imported.
----
(WIP) Suit Station
Since alternative suits are purely cosmetic, the ability to change suits will most likely be simplified as a select option within the inventory menu, as opposed to a special station you need to go to, however for suit upgrades and tuning, we wanted to have a specialized location in game that would allow you to do this. An idea we are floating around is to have a “tuning” system as opposed to a flat upgrade system.
Instead of increasing the values of armor rating, shield recharge rate, etc, you would instead unlock tuning points as you progress, that allow you to allocate the number you have to what you’d like. This would give you much more freedom in changing your build on the fly. If you wanted to spend everything into high armor, you can, or if you wanted more stealth viability, you could do that, or have an evened out generalist approach. Weapons wouldn't work the same, rather would work on a mod system, but also for TW herself it wouldn't make much sense as she wouldn't need to unlock parts of her cybernetics she already has. So we are still brainstorming an approach for that area specifically, or if we even need something.
Whisper Shrine
This was actually our first attempt at a high poly low poly workflow and it turned out not too bad, there is a lot of organic sculpted detail that was pretty difficult to do entirely by hand crafting the low poly geometry. The process was fairly simple and we were able to add additional height details in the texturing process.
This shrine will serve as a visual representation of a save point. 
Ritual Herbs & Invocation Scales
Crewman PDA
This item will serve as a main intractable item that will host either audio or text logs. These were standard-issue to the ship’s crew. Within these you'll discover insights about the crew, the nature of the ship and their assignment, their final moments, or general thoughts or clues.
PCDD
This is a sort of loot item, it will typically house schematics for replicable items, such as ammo, weapons, alt suits, equipment, etc…
An idea we are considering is that instead of buying nonsensical items like guns and ammo from a public store with money, you would use a resource like scrap or resin, and bring that to a replicator to construct said item for you. Scrap would be a more valuable resource as it can be more easily organized and sparse. 5 scrap makes a med stim, 10 scrap could make specific ammo, 30 scrap could replicate a specific gun, 50 scrap could replicate an alt outfit, 80 could replicate a tuning point etc…
CDB
Comments
Brain Box
In total about 4 years, but we rebooted development to refocus alot of our core mechanics about a year ago!
Hunter Halverson
Those models look really nice. How long has this game been in development?
ObsidianGrey
Love this! Thanks for the update!
