REMORE: INFESTED KINGDOM News

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

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

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

Hello, Fellow Survivors!

This week we'd like to share what we have in store for our next Live Update.

As we've mentioned in previous Dev Notes, most of the team is currently working on the new gameplay and narrative features for our next major overhaul.

However, we've heard of a lot of frustrations and bugs in both reviews and on Discord currently, so we felt that it was necessary to fix them.


[h3]Modifying Infested Patterns[/h3]

First, we're changing the way the Blister's "Bile Explosion" deals damage. It will no longer have the Ignore Armor attribute and will instead have Armor Damage added to its base damage.

Since the main gameplay intent of the Blister is to trigger an instant death on Collision, and knowing and utilizing this adds fun to the game, the initial intent was to have a strong penalty for "Direct Kills" when not using this method.

However, depending on how the enemies are coming at you and the general lay of the land, it can be difficult to trigger a collision death, so we decided that the penalty is a bit harsh. When the player reaches the "Monastery" map, which requires an understanding of the Blister, many players are still finding their feet so it’s quite difficult to pull off the collision conditions.

Additionally, we've received feedback that since the narrative of the Blister is literally a "spewing of digestive fluids," it would be more in keeping with the concept to have it do "more damage" to armor rather than completely ignore it.

We've changed the damage of the Blister so that it no longer "ignores armor," making defensive play a more viable option in certain situations.

Of course, the old damage is still there, but the “armor damage” is a new addition, and this additional damage ramps up quite a bit as the difficulty increases. So, on “Despair” difficulty, you still need to understand/exploit the collision conditions just as before.



There's also a change to the Skulker's (enemy that appears from mid-game) escape ability. The escape distance is reduced from 2 spaces to 1 space, and the diagonal escape will only check for the "diagonally behind" tile to be empty.

Actually, the diagonal escape condition in the original Skulker was overly complicated, so I think there was something inherently wrong with this design.

Due to the design intent of "2 spaces escape" and the idea that "2 spaces diagonally is too far", we made it so that Skulkers could only get away if they had a clear path of 2 tiles, even when they were attacked diagonally." (If you don’t get what we mean here…we understand your confusion!)

After the change, “the Skulker, when attacked diagonally, check to see if there is an escape route in the opposite diagonal direction", and flee by moving 1 space diagonally, like Edwin's "Side Step".

The straight-line escape pattern remains unchanged, except for the reduced number of spaces to move, so we expect to see fewer cases of "counterattack when you shouldn't have to" as a result.


[h3]Additions and Changes to Weapon Modifiers[/h3]

The existing weapon modifiers are all randomized, similar to a roguelike game. Since the game was basically balanced without weapon modifiers, the idea was to introduce some randomness into the modifiers that could be considered "additional".

However, with the limited opportunities to acquire weapons in the current linear structure, we noticed that many players felt the game was unfair when a modifier that was best suited for a two-handed weapon was attached to a one-handed weapon or an offensive modifier was attached to a shield, etc.

We've also found that players who acquire a weapon with a more complex set of usage requirements at an early stage, such as Blackthorn/Monastery, are often unable to learn and utilize the weapon's intended use.

For the fixed weapons drops that can be found in the campaign's weapon crates from the first stage, Blackthorn Village, to the Barracks, we're making sure that the modifier options are as "weapon-specific" as possible. We're also making sure that the early drops have modifiers that make them easier to use and stronger without penalty.

However, the “Recurring Nightmare” option will still have the same randomized selection for crate drops, as we want to give players a chance to experience combinations that are “unlikely to happen in the base campaign” through randomized options.

Also, even in the campaign, the weapon selection that Jaymes the Trader brings in or that Cultists drop will still be randomized.

In addition, we've added a total of five New Weapon Modifiers, which we'll save describing until we release the patch notes on the day of the actual live update so you can experience them in-game :)


[h3]Other UI changes[/h3]

In addition to the changes mentioned above, we're also making changes related to convenience that many of you have mentioned in your feedback.

First, to improve the problem of not being able to check the Keywords of "Weapon Attributes" we’ve added a feature. When you press the CTRL key, you can see the Keywords of Weapon Modifiers, and when you press the ALT key, you can see the basic description tooltip Keywords of Weapon Skills.

We're also adding the ability to open the Settings Menu with the ESC key, as many of you requested.

The original reason for the F10 shortcut was to minimize situations where ESC was pressed for other purposes (disabling a skill, closing the UI, etc.) and unintentionally opening the Settings Menu, and we're trying to have it both ways by temporarily disabling the ability to trigger the Settings Menu when there is “meaningful input” such as closing the UI.

Also, when there are multiple interactable objects on a tile, such as Weapons and Infested body parts dropping on an open door, we're making it easier to interact with the desired object. For now, interacting with the “Item on the tile” will be prioritized, but if there are multiple drops, a selection menu will be displayed.

We've also fixed a few other identified inconveniences and bugs, such as fixing the color of floating text and fixing text, and we'll be releasing more details in the patch notes later.

The above updates are currently in full QA and are expected to be available to the public as early as next week and no later than three weeks from now.

More detailed patch notes will be available at the time of the live update, and starting next week, we'll be back with a "Lab" segment to show you how the long-term overhaul is progressing.

Thank you,
REMORE

Hello again, Survivors!

Last week, we introduced the narrative direction we were going for and mentioned the main issue being the time required for development.

Today, let’s look at the specific problems we encountered and the direction we are currently considering.


[h3]Reasons for abandoning the “Choice” approach and the current direction[/h3]
Last week, we discussed a quest design example from the Tavern, presenting players with the choice of whether to take the Innkeeper's medicine, who had guided them on their journey, to cure an ally's illness.

When we initially prepared this design, we believed that incorporating such narrative elements would provide clear motivation for the player to visit the Tavern, creating a diverse experience based on player preferences and situations. We also thought that, compared to CRPGs, the number of required scenarios would be reduced.

However, just looking at the case of the Tavern, there were exceptions that needed handling beyond our intended design. The innkeeper could die before reaching the medicine, or players might choose to abandon the search for the medicine and leave the Tavern. Additionally, opinions emerged like what happens when the innkeeper dies, and players return to the ailing wife.



The originally estimated time for map design, which was around 1.5 to 2 months, ended up taking close to 4 months. Considering that we need to handle increasingly complex stories as we progress, it became clear that even with an additional year, we could only create three more maps.

In other words, unless we stretched development out to 4-5 more years, we were in a situation where we must significantly reduce the volume of the game.

However, since we didn't plan for this time frame from the beginning, if we reduce the volume of the story to fit the realistic development timeline, it becomes an ironic situation where, due to the direction chosen to enhance narrative value, we end up lowering the overall narrative value.

Furthermore, there were more frequent conflicts between “game elements for storytelling” and “game elements for tactical gameplay” than anticipated. For instance, to facilitate normal NPC conversations, there were many situations where we had to teleport all party members to a specific location, which became a tactical issue as it turned into an “exploit.”



In the Early Access version, we have used this in some sections, but we tried to minimize situations where it can impact combat. However, in this version, achieving good storytelling without feeling like it's being “overused” was challenging.

Recent cases like Baldur’s Gate 3 have addressed all these possibilities in a highly polished manner, creating true freedom of choice. As someone who briefly attempted a similar approach, I genuinely commend their efforts.

However, the conclusion for our team was that it was not a scale of work we could handle. The final decision was to focus solely on “tactical aspects,” resulting in the current Early Access version you’re playing.


[h3]Attempts within the Early Access version:[/h3]
In the new version, all elements of choice within the game have been removed, and the experience from the start to the end of a tactical session is filled solely with elements meant to convey “tactical aspects.”

Events like rescuing the NPC Aldris in the Monastery map exist, but they serve as a reward after reaching a specific point or a trigger for enemies. Others provide excitement such as the surprise appearance of the Cultists in the early stages.



Of course, even within this direction, we attempted to express our narrative theme within reasonable limits.

When tackling the theme of “human nature” without being too grandiose, the aim was to portray the reactions of real people in our world to the events that were unfolding.

Characters like Willam, Edwin, and Diurmuid initially meet with suspicion, but as they go through the journey, their relationships evolve. In the final chapter of Early Access, Stag Manor, dialogue supporting each other's uncertainties emerges, expressing the growing understanding of each other's differences.



However, conveying the desired narrative experience only through text, without more aesthetic direction or supporting mechanics, made it challenging to create the experience we wanted to.

The situations the player encountered on each map, the thoughts of NPCs and player characters about the events, relationships, and personal stories—all of these were conveyed through text, and the result was not where we wanted it to be.

If the narrative is reorganized once again in the future, I would like to first clarify the principle that "the fun of the gameplay is key".

If the expression of the theme and narrative does not harm the overall design of the mechanism that expresses strategy/tactics, it will reduce the probability of "excessively expensive issues" or "narrative and tactics conflicting" again.

We’re curious if this kind of "Archive’’ post is interesting to you as players. Since the direction we will choose is closely related to the project's history so far, we plan to gradually introduce more past attempts as we go.

Given the various discussions within the team, selecting the right topics every week isn't easy, but we just want to show our thoughts as a development team as honestly as possible.

Again, sharing your thoughts through comments on Discord or any other way you like, would be immensely helpful to us! :)

We'll be back next week with another topic.
Until then, see you soon Survivors!
REMORE