1. REMORE: INFESTED KINGDOM
  2. News

REMORE: INFESTED KINGDOM News

[Lab] Surprised and Surrounded #2



Greetings, Survivors!

In our last Lab post, we shared the design intent behind the “Surprise”, “Out of Sight”, and “Surrounded” systems we're currently experimenting with.

However, since we focused on design intent and conclusion, it might be hard to imagine how that translates to the actual combat experience...

So today we're going to share a bit more details, along with the history of the experimentation that led to these systems.


[h3]First Experiment - Is “Surprised/Surrounded” actually fun??[/h3]
Our first experiment was to add Surprised and Surrounded "as is" to the existing Early Access version of the combat rules to see if they made it more fun or if they conflicted in any way.

The goal was to add these rules on top of a basic build for procedural map generation that we were already experimenting with, to see if they would "encourage field of view play (Surprised)" and also if they "add interest to battlefield manipulation (Surrounded)".

The reaction to this test was somewhat divided: the use of the Surprised and Surrounded system was fun as intended, but there were a number of existing rules and content that seemed out of place or in need of tweaking.



[h3]Positive[/h3]
  • There's more tension than before (due to Surprised) to stay out of sight, and a pretty strong sense of reward for getting a kill without raising any alarms.
  • Battlefield manipulation skills like Grappling Hooks and place swapping have more meaning due to the value of Surrounded and feels more enjoyable as a result.
  • It's more intuitive to know "How to do it Right" compared to before.




[h3]Negative[/h3]
  • The concepts of Caught and Surrounded clash, requiring battlefield manipulation to “escape capture” while also trying to set up Surrounded formations. It feels a bit too much.
  • Being caught off guard by an enemy you can't see now feels more negative than before.
  • Creating a Surrounded formation with freely deployable/retrievable barricades feels a bit heavy handed and forced.

At this point, we had an important choice to make: do we tear the existing combat system to shreds to fit our new concepts, or do we abandon Surprised/Surrounded because it doesn't fit with the existing rules?

It was at this point that we started thinking about the direction of our planning, including whether or not to remove the concept of “Caught". In the end we decided to rebuild the entire system around “Surprised/Surrounded".


[h3]Second Experiment - Rebuilding the Rules around Surprised/Surrounded[/h3]
In the second experimental version, the Caught rule was removed, and the concept of directional vision when recognized was also dropped - the intention was to focus the overall tactical play on Surprise-centric before recognition and Surrounded-centric after recognition.

First, we added a sort of "Scouting Item" to help you see where enemies are before entering a new room. We wanted to try implementing an item that could "Light Up the View Ahead" and then, if it worked out, add the concept of lighting the darkness with a "Torch/Lantern" or something along those lines.



We've also simplified the rules for Surrounded to allow for "multiple enemies" to be surrounded, as the original "Surrounded" only worked if there were a greater number of allies than enemies adjacent to them, which was a bit hard to recognize and only complicated the rules.

The new rules are that any enemy or ally that has "No Tiles to Move to" are considered Surrounded, regardless of the number of enemies/allies, which means that the Surrounded rule will work even in situations like the one shown below. The original idea for the Surrounded concept came from the rules of Go, and the goal was to modify the rules so that we could actually create situations like the "multiple stones at once" in Go.



Unfortunately, it still didn't have the feel of completeness that we were initially aiming for. The scouting item, while clearly effective, was not only cumbersome to use, but also had the problem of being useless if you lit up a room and it was empty...

Also, creating a Surrounded angle was often "impossible to create no matter what" depending on the enemy's post-alert movement. While the removal of the Caught rule definitely reduced the "punishing feel", the goal of enhancing the tactical feel of "so how do I play this game well?" was not achieved to the level we had hoped...

It was not easy to create Surrounded situations outside of setting up/recovering barricades, and the feedback from our first experiment that "the play itself feels heavy handed and forced" remained an issue.


[h3]Third Experiment - Systematizing “Out of Sight Preview”, “Moveable Objects”, and “Swapping Places”[/h3]
While the remaining issues were not insignificant, we felt that the Surprised/Surrounded itself had a lot of potential to be fun, so we set out to find a way to address the issues that were raised.

For scouting via “Surprised”, the idea was presented that instead of creating a separate scouting item, it would be nice to be able to “Sense the Presence” of enemies within a certain distance, even if they are out of sight, in the sense that you “Felt Their Presence.”

There's still no way to know which way the enemy is "Looking," so there's still a sense of Out of Sight, but if there's a large group of enemies across the room, it gives you a general idea on whether to scout accordingly or take a different route altogether to avoid risk.



For Surrounded, we also experimented with making Willam's Swap Places Skill, which was a Unique Perk for him, a common feature that all characters could use.

If "Battlefield Manipulation" is the basic fun of the game, then the ability to get out of the way of an ally or get between enemies should be available to everyone at the cost of TP, with the intention of fleshing out each character's quirks later in a more deeply tactical way.

Instead of removing the freely deployable/retrievable barricades, we've also been experimenting with a way to move pre-placed objects on the map by pushing/pulling them around. This was a feature that was requested a lot in Early Access, so we thought we'd give it a shot and see if it made sense.



And thankfully, the new features we added worked very well!

Depending on how you utilize the place swapping, you could create a Surrounded formation if you wanted to in almost any situation, and it added a lot of depth to the game as there were a lot of different possible outcomes rather than a “set answer.”

The ability to “See Enemies Out of Sight” also worked out better than expected. You can throw rocks from “Out of Sight” range to “Prevent” them from seeing you, and it has the side effect of reinforcing the emotional impact of the game, as you don't know exactly what's coming, but you can sense it.

Of course, the rules aren't 100% perfect yet: creating Surrounded situations using Place Swaps is quite challenging even for us Devs (just like Go is challenging in real life), and the Pushing/Pulling of objects was not as easy to utilize as we hoped (compared to Place Swapping at least).

However, the fact that the third experiment gave us confidence that we could use Surprised/Surrounded itself as a base system was a big win, and it's also encouraging to see that the feedback was much more positive compared to the second experiment.

We’re really excited for players to try out the Surprised and Surrounded systems in the future, as we’re hopeful that they’ll be as positive about these changes as we are!

Thanks as always, and we look forward to hearing your feedback!
REMORE

[Dev Note] Surprised and Surrounded!



Hello again, Survivors!

Last week, we talked about the direction we're taking with the redesign of the Combat Systems, and how we're keeping the "Design Intent" of the core fun elements but making them more engaging and proactive for players.

Today, I'd like to share how we’re realizing this goal, and some of the outcomes of our testing!


[h3]Utilizing "Enemy Sight" through "Surprise" and "Sight Evasion”[/h3]
As I mentioned in the last post, the first thing we tried was the “Surprise system.” We took the “Out of Sight Attack Bonus” that was previously only available as an effect for some weapons and instead made the base rule “If you attack an enemy from Out of Sight, you deal Double Damage.”

These are also some changes to the rules for enemy sight,
  • Enemies that have sounded the Alarm and become "Aware (Red Arrow)" change their field of view to Omnidirectional,
  • If you end your turn outside of the enemy's Line of Sight, you will not be attacked during the enemy's turn.


The field of view rule changes are due to feedback that it was too difficult to get out of the way of enemy attacks, with the goal of allowing players to use the field of view system to their advantage.

While many games in this genre have an "Attack Range" and give you a chance to stay out of harm's way, Remore's Infested have a very long movement range, making it very difficult to do this.

While we do provide a means of disabling enemies with "Shield Block", "Barricade", or "Injure/Stun", we decided it would be best to give players a way to use the basic system of "Out of Sight" to their advantage first.

This is the same intention as when we talked about the "Surprise System" earlier, where the "tactic of utilizing a skill or tool" is something that we want to deliver as additional tactical depth after players are comfortable with the basic system.



Our internal evaluation of the “Surprise” and “Out of sight” systems is pretty positive. We decided that 2x damage was too much and reduced the damage bonus to 150%, but the end result is that it still feels tactical, with a "kill as many enemies as you need, grab some supplies, and get out of there fast" feel to it.

However, we still had a deeper issue to handle: "Catching/Caught".


[h3]Weighing the Pros and Cons of the "Caught” system.[/h3]
Up until the Early Access version, "Caught" was a key part of the combat system. It was a way to pose a real threat by making it harder to ignore a swarm of enemies by having them raise an alarm, and it was a key way to increase the value of battlefield maneuvering skills like pushing and pulling that we see as a hallmark of the game.

However, for those not yet familiar with the game, we've found that it often feels like a fairly harsh punishment to have a large number of enemies immediately swarm and grab your allies when you're caught in their Line of Sight, even though it's still your turn. Especially in the case of “Blisters”, depending on where you're caught, the difficulty of getting past them without taking damage can be rough.

Also, in the original Early Access version, when an enemy was facing "Diagonally," they could grab two allies in that direction at the same time. We received a lot of feedback that it was hard to understand "Who" was caught and “Why.”



So, we asked ourselves, "Can we achieve the design intent of “Caught”, which is to intimidate and increase the value of battlefield manipulation skills, in a different way than the seemingly punishing system of “Capture/Caught?”

In fact, in the case of feeling “Intimidation”, the "Sight Evasion" system above makes it easier to create this by simply increasing the number of enemies that appear, even without catching the player.

Traditionally, given the difficulty of escape from capture, we've tried to make sure that our level design doesn't have more than a certain number of enemies that have the ability to catch an ally at once, if possible.

On the other hand, with the concept of Line of Sight evasion, it's now possible to outrun 8-10 enemies in a dangerous spot without taking any damage, as long as you give them room to escape. Of course, once an enemy spot you, they'll continue to track you, so it can be dangerous to simply run away.

We felt that this experience of having a large number of enemies creeping up on you unless you take them all out, was closer to the feel of the board game Zombicide that we were originally inspired by, so in the end, it was closer to what we originally wanted to do.



So now, if we can find a way to address our second goal, "Increase the Value of Battlefield Manipulation Skills," we've concluded that removing the “Catching/Caught” mechanics can lower the barrier to entry, with no loss of both thematic and tactical value.

After some thought, we've decided to go the route we're currently on, which is to base the game on a system that allows you to "Surround" enemies.


[h3]Surrounding Encourages Battlefield Manipulation Gameplay[/h3]
Here's a quick summary of how the new "Surrounding system" we're experimenting with works.
  • Enemies with “No Available Tiles to Move to” are “Surrounded.”
  • Enemies that are “Surrounded” are dealt Double Damage.

In other words, surrounding an enemy, whether by taking advantage of walls and doors, direct movement of friendly characters, placing barriers, or any other means, gives the player a clear advantage.



With this system in place, combat is guided as follows.
  • Tactical Points (TP) are used for battlefield manipulation such as moving, pushing, and pulling to surround the enemy.
  • Weapon Points (WP) are best used against enemies when surprised or surrounded to maximize damage.

It was hoped that this aspect of play would help separate the roles of TP/WP and also create a much more tactically diverse set of situations than just “'trying to avoid being Caught.” And, thankfully, we've found that this is exactly the outcome!

Of course, as always, these positive results didn't come so easily - there was a lot of experimentation, including tweaking the surrounding conditions, the foundation of the battlefield manipulation techniques to create the “Surrounded” condition, and also the enemy placement and level design fundamentals, and this prototyping continues today.

However, since this post is already quite long with just what I've said so far, I'll save my experimental attempts to get the Surrounded System working as intended for the next post.

Rethinking all of our designs for accessibility while maintaining the core fun of the game was no small feat, but after a lot of thought and experimentation, we're happy to report that we're able to put “Surprise,” “Sight Avoidance,” and “Surround” on solid new footing.

We'll be back in the next post with more details on our experiments and what game elements will be changing as a result!

As always, thanks for being here with us on this journey!

Until next time.

Thank you,
REMORE

[Patch Note] 0.12.3 Build



Greetings Survivors!

We hope you are all having a swell infested day!
On today’s Patch Note 0.12.3 build we have the following changes,

[h3][Updates][/h3]
  1. The game engine version has been upgraded. [Unity 2019.4.40 -> Unity 2022.3.15]
  2. All modifiers of weapons obtained from item boxes till the campaign “Barracks” map will be fixed stat.
    • The purpose is to minimize the randomness of weapons acquired early on being given overly complex modifiers or completely useless modifiers.
    • The modifiers of weapons obtained from cultists and sold by Trader James are randomly assigned as before.
    • Does not apply in “Recurring Nightmare” mode.


  3. (User Feedback) “Ignore Armor” has been removed from the damage attribute of “Blister” skill “Bile Explosion”, and “Armor Damage” has been added instead.
    • This change was made to accommodate the feedback that “it doesn’t feel intuitive to ignore armor” and to prevent characters whose health has been greatly reduced in the previous battle from dying too quickly at the beginning of the next battle.
    • However, playing while “Blocking” the damage from the Blister with a shield may reduce tactility, and instead, a certain amount of “Armor Damage” is added.
    • Actual damage depending on Difficulty Level is as follows.
      • VENGEANCE: 4 Fixed Damage, Ignore Armor -> 4 Fixed Damage, 2 Armor Damage
      • SUFFERING: 5 Fixed Damage, Ignore Armor -> 5 Fixed Damage, 2 Armor Damage
      • DESPAIR: 6 Fixed Damage, Ignore Armor -> 6 Fixed Damage, 3 Armor Damage
  4. (User Feedback) The number of escape spaces for “Skulker’s” skill “Retreat” is changed from 2 to 1, and when attacking diagonally, the Skulker will flee in exactly the diagonal direction.
    • Previously, the method was to “find a straight path in the diagonal direction and move 2 spaces, but we made changes to prevent the problem of “not running away even though there is a path” due to the overly complicated rules.
  5. 5 New Weapon Modifiers have been added.
    • Clean Kill: If Target HP is 1 after Attacking with this Weapon, Execute Target
    • Reinforce Strength: Spend an additional 2 TP and Apply 1 Stack of Reinforced Strength when Attacking with this Weapon
    • Fortify: Apply Immobile to Self but Increase Weapon Armor Damage by 5 when Attacking with this Weapon
    • Blood for Blood: Recover 4 HP if HP is at 50% or below when Counterattacking with this Weapon
    • Head to Head: Increase Critical Rate to Target by 25 while Caught by Target when Attacking with this Weapon
      • Reinforce Strength / Fortify modifiers only appears on Recurring Nightmare.
  6. (User Feedback) The interaction order of interactive objects has been modified from the existing sprite position-based method to a tile-based priority decision method.
    • The purpose is to solve the problem of making it inconvenient to interact with the desired object in situations such as an item falling on an open door.
    • Basically, it works according to the priority of (Drop Item > Grave > Defense Wall > Door > Item Box).
  7. (User Feedback) A feature will be added so that the “Preferences” menu can be opened using the ESC shortcut key.
    • The original shortcut was set to F10 because there were many cases where the settings menu unintentionally opened when pressing ESC repeatedly for other purposes (cancelling skill use, closing the UI, etc.).
    • Instead of changing the menu shortcut back to ESC, we changed the configuration menu so that it does not open for a certain period of time when there is a “significant” ESC input (such as closing the UI).
    • You can still open the Preferences menu using the existing shortcut key (F10).
  8. (User Feedback) When you press the Ctrl key in the Weapon Tooltip, you can now check the keywords of the weapon modifiers. The basic description and tooltip keyword for the weapon can be viewed using the (left) Alt key.

  9. In the Menu and Save Data list on the Title Screen, you can move using the W/S or arrow keys and confirm it with Space / Enter key.

  10. (User Feedback) When displaying a Skill Tooltip, showing expected range in the grid UI has been removed.
    • It has been removed as it overlaps with the range display UI in the Skill Tooltip.

[h3][Bug Fix][/h3]
  1. When a miss occurs while having armor, the color of the floating text has been changed to display the armor damage color (white).

  2. Fixed an issue where the maximum health lost due to hunger was restored when Save-Quit-Load.

  3. In the “Recovering State”, only the recovery amount of tactical action power (TP) should be reduced by 4, but the randomness in which the maximum value of tactical action power was also reduced by 4 has been corrected.

  4. Fixed an issue where the skill effect range display UI appeared when a counterattack occurred with a “Two-Handed Sword” type weapon.

  5. Fixed an issue where the expiration date of the “Apple” obtained from the Hideout for the first time after starting a New Game did not decrease.


Thank you,
REMORE

[Dev Note] Rethinking the Battle System



Hello again, Survivors!

In our recent Lab posts, we've been talking about ways to create a wide variety of maps at limited cost, mainly focusing on map modularity and procedural generation.

Today, I'd like to move from maps to systems and talk about how we're reworking the Combat System, the backbone of the game.


[h3]Core Design Intention of the Current Combat System[/h3]
The main intent of the Combat System is to emphasize the tactics in "Tactics RPG" within the framework of a “Medieval Creature Apocalypse" narrative theme. Every system created is our answer to the question “How can we achieve that?”

Based on the Early Access version, here are the key elements of the combat system and the design intent behind each.
  • If an Ally is spotted in an Enemy's "Line of Sight," an "Alarm" will sound, and nearby enemies will immediately swarm.
    • Move carefully to avoid being caught by monsters (Theme)
    • How you start the battle in terms of the terrain and enemy/ally positions can make a big difference in the outcome (Tactics)
  • Enemies can use “Catch” to impede movement when adjacent to an Ally.
    • Create psychological pressure in facing hordes of monsters (Theme)
    • Increase the importance of "battlefield maneuvering" skills such as pushing/pulling with TP (Tactics)
  • Both Allies and Enemies can deal high damage, so you'll need to deal as much damage as possible to eliminate Enemies within your Turn.
    • Increase the "Threat" of monsters, giving a sense of urgency to defeat them (Theme)
    • Use WP/TP, resource allocation and battlefield manipulation to make it fun to find opportunities to maximize player firepower (Tactics)

There are additional elements such as "avoiding overlapping features between weapons/tools", "giving all enemies clear strengths/weaknesses in their abilities", and "creating unintentional encounters through view restrictions such as walls and doors", but these are the three most important parts of the game’s combat.

While the base system puts quite a bit of pressure and constraint on the player, we decided that the excitement of breaking out of that constraint and unleashing a lot of damage through the “Battlefield Escape/Manipulation” technique was a key element of the game's combat system’s fun factor.

However, in Early Access, we found that the "Designed Learning Curve” was too steep as we mentioned in our previous Dev Note while talking about linearity.

For example, after finishing the Tutorial, the second stage, "Monastery," already requires you to have a solid grasp of the basic systems and your character's counter skills in order to progress successfully.



While many people have commented on the fun of getting their head around this progression, and we're confident in it, we've found that most players (even those who are already familiar with similar genres) don't yet have a good grasp of the underlying systems by the Monastery stage.

As a result, we saw a lot of players abandoning the game at this stage.

So, our redesign challenge for combat content was "How do we keep the fun factor, but make it so that players feel like they're learning the system as they play?"


[h3]Redesign Principles and Challenges[/h3]
Revisiting the underlying system with a view to redesigning the learning curve raised a new issue. This is that many of the foundational elements of fun are designed to call on the player to react to a punishing situation, rather than to present them with a situation they can take advantage of.

For example, in the case of the first foundation, the Sight System, there's no way for the player to use it in a way that makes it useful to them - the only thing that's immediately recognizable is the punishing situation, the fact that "if you get caught, enemies will come."



Of course, to help players "take advantage" of this, we've given them a Two-handed Axe as a default weapon, which gives a "high critical chance when attacking from out of sight," and a Pebble Pouch as the first Tool, which "allows players to lure enemies away and open up a vantage point," as the Tutorial demonstrates.

However, based on our observations of Early Access play patterns, we found that many players were unable to understand and utilize the intent of this content.

Our conclusion was that the contextual meaning of the Skill (the difference between enemies being aware and unaware, the meaning of the out-of-sight condition itself, the value of the critical hit increase, the relative value of the horizontal slash, and so on) needed to be fully understood in order to be able to use it effectively, and until all of these factors were understood, "Enemy Vision" felt more like a punishing situation than a tactical tool.

While we observed a small percentage of players utilizing “Ambush Chop” as intended once they passed the Monastery and moved onto the Tavern stage, we found that many players either didn't understand the intent of “Pebble Pouch” or found it too difficult to utilize.



While the basic intent is to create favorable terrain and have enemies come to us instead of us having to spend TP, the tactical play that comes from taking advantage of this requires a much deeper understanding of the game's overall systems and context than just “Shooting from the Hip".

Of course, we don't think it's a bad design direction to utilize these elements to add tactical depth to the game - that's the whole point of designing a game to be fun, and we want to give players as much of that "depth" as possible.

The problem is, however, that it's unrealistic to expect players to understand and utilize all of these elements from the very beginning of a game, so we need to come up with a new answer to the question of how much fun we should have in the beginning.

Because we don't think that simply making something "less difficult" while keeping the same system/content design as before automatically makes it "more fun".


[h3]How We're Improving Core Design Intent[/h3]
After thinking about these issues, our new direction is to maintain the design intent of each core element but add or change new elements that players can actively utilize.

For example, in the case of the "Ambush Chop" skill in the example above, we're testing a way to make it a powerful damage bonus to your first attack against an unaware enemy in the base system, rather than tied to a specific weapon or skill.

If this is implemented on top of the base system and communicated through tutorials, I think the end result will be that the first Key Element, the “Sight System”, will be recognized as something that can be actively utilized, not just as a punishment (an alert device for swarming enemies).



By making the Two-handed Axe's "Ambush Chop" skill more "Situation Specific," either by changing it to a different effect or by making the damage of the attack more powerful compared to other weapon skills, the intent would be communicated through the underlying system and better utilized by those with a deeper understanding of the game.

Along those lines, we're also experimenting with a different direction for the second core element, "Catch/Caught" which could be more proactive, but that's another story that requires quite a bit of explanation, so I'll save that for next week's "Lab" post.

In fact, this week's plan was originally to be a follow-up to last week's Lab post, with a detailed explanation of the combat system changes we're testing and the results of our experiments.

However, as we were writing it, we realized that our intentions wouldn't be conveyed if we didn't first share some context on "why we’ve made these decisions," so for now, we're simply giving you some context on the combat system rethinking in a "Dev Note" format.

We'll be back next week with a more detailed look at our test results!

Thank you,
REMORE

[Lab] Creating Procedural Maps!



Greetings once again, Survivors!

Today we're back with another Lab post to talk about how we're prototyping the new re-vamped version!

We've talked about map diversity, character diversity, and a re-vamped meta-game system as goals for our redesign, and today we're going to talk about the first of these, a Procedural Random Map Generation System that we're testing as a means of map diversity.


[h3]Design Goals and Uses for Random Maps[/h3]
With the reorganization, we're separating tactical stages into two broad categories: primary locations for story progression (hereon referred to as "Story Maps") and secondary locations for collecting resources (hereon referred to as "Resource Maps”) ...

Story maps will still be manually designed similar to the current EA version maps, while Resource maps will use a randomized map system that will allow for an endless variety of compositions.

To do this, the first goal was to answer the question, "Is it possible to randomly generate a room's interior?"

This is because our combat system is largely based around the idea of encountering enemies while uncovering a "view blocked by walls and doors," and we needed a procedural generation structure that would work for this design.



We started by creating a rule that would generate "rooms" within a simple rectangular building. The assumption was that if we split each room into "walled areas" based on random values, and then applied a rule that would generate doors close to the center of each wall, we could create building shapes similar to those we currently have in EA.

We thought we could apply random value noise to the map, placing objects in locations where the density of that noise was above a certain value, and use an algorithm to remove any blockages from doors and walls. This could give a unique layout and experience each time.



We prototyped and tested this quickly, and the feedback we got was that if we could randomize the types and locations of enemies that appeared, it would be a pretty good "Resource map".

However, aside from gameplay, after reviewing the object placement in conjunction with artwork, we decided that this logic could not be used as is.


[h3]Placing "Plausible" Objects on a Random Map[/h3]
Currently in EA, there is a narrative behind each map, such as "the Grocery" or "the Small Village", and the placement of objects in each room is something that the art team works on to "represent" that setting.

For example, in the screenshot below, in the room you can see a counter where customers were greeted and served, so the long table placed in position C serves both a gameplay role as an obstacle and a narrative purpose to make it look like a grocery store.

This led to the addition of "a bench for guests to sit and wait" (B), "corpses of looters who had barricaded themselves against the Infested with tables, crates, etc." (D, E), and the addition of secondary objects for visual balance (A).



The question was, if the farming maps were to be randomly generated, would it be possible to achieve a believable placement of objects? If the maps were to have a strong narrative, like the Stag Manor or the Aldris rescue scenario in the Monastery, then they would be story maps, but even farming maps should at least look like believable locations.

The noise-filtered object placement we tested above didn't allow us to achieve this goal, so we decided it would be better to have fixed room modules from the start, rather than having to modularize the noise filter applied to the grocery store, the noise filter applied to a living area, etc.

To address this, we asked the art team to document “Object Placement Rules” based on the EA version. Whereas up until now, the artists had placed map objects according to their sense of narrative, the goal was for the “Random Map System” to allow the algorithm to mimic this choice.

Obviously, we couldn't program/automate "exactly" the way the art team had been placing objects, but we felt that we could make some generalizations, such as the art team's preference to "fill the top walls with objects so they don’t look bare”.

So, while we kept the existing "wall/door generation algorithm", we started creating rules to "backwards infer" how the art team placed objects to the level design.



It would be too complicated to write down all those rules in this note, so I'm going to focus on screenshots of the results of randomly simulating those principles of object placement.

Once the intermediate work up to this point was shared, the "non-art" team members thought, "Yeah, that's pretty good, I guess."

Since the spatial setting of the farming map was not going to take on a narratively significant shape, the idea was that if we could get the above object placement working generally, we could make it look "different" by creating variations such as "Grocery objects", "Living area objects", "Weapon storage objects", etc.

Using the results of these experiments, we created new generation rules and verified they worked, which resulted in a random map as seen below. Gameplay-wise, it was still fun to play and also respected the art team's object placement rules.



However, this was also rejected after a review with the art team. The reasoning was that a structure generated like this wouldn’t look like a "real house" - more precisely, it would make it difficult to tell the difference between a hallway and a room, so all spaces would feel the same.



This means that the blue part of the image above should be created as a separate tile set as “Hall (Living Room)”, and the green part should be created as “Room”, so that it is more clearly recognizable and diverse.

The solution to this problem was also discussed and a new rule was created and validated. However, these rules are still in the process of being implemented, so we'll have to wait to be able to share more details and screenshots till after they’re fully organized.


Since the game is set in buildings rather than underground dungeons, it's a daunting task to meld these narrative and artwork generation methods and gameplay with procedural random map generation rules.

In fact, we tried something similar about two years ago, and found that it wasn't easy, so we switched to a hand-crafted approach.

However, unlike two years ago when even the basic rules of the game were still undergoing changes, we now have a clear set of principles for "what patterns should be followed in level design to align with the combat system", so while it's taking some time, we feel it’s an achievable goal.

We’ll be back next week with another Lab, and we’ll show you some more progress on the procedural maps we talked about today, as well as some new things we're trying out in the combat system.

As always, thanks for sticking with us!
REMORE