Dev Log #01

Hello~ This is the dev log for my solo indie game Grid Lost. I've been working on the game for 2 years and I think it's about time to let my "baby" see the light of the day. I'll keep my dev log short, cause 'too long and no one wants to read'. The 1st dev log will briefly cover the general setting (story, genre, and combat).

https://kakuseika.itch.io/gridlost

Notice: A new build is uploaded as a Google Drive link. Currently, there is a limit to the file size on itch.io and I'm working on getting it increased.

Story

The story takes place five years after the end of the Cold War. A fictional island nation the United Vaniber (UV), developed the most advanced information technology (the Grid network) and artificial intelligence (Daemons) that the world had ever seen. With these creations, the UV quickly rose through the ranks to become the most technologically advanced nation in the world. Because the UV refused to share its creation, a "hunt" to steal the Grid technology began. You play as an anonymous contractor working directly under the United Vaniber Intelligence. Your mission is to eliminate invaders and prevent the technology from leaking to foreign nations. 

The game takes place entirely inside the Grid network. In the digital world, anything is possible, like in Minecraft;  there is a lot of liberty to aesthetics.  For the 1st act, I chose a cyberpunk environment, which fits the sci-fi theme of the game. 

Genre

The genre is rouge-like deck-builder, similar to Slay The Spire. Players will start each run fresh and slowly build up their deck. The difference is that instead of choosing a playable character, you will choose up to 3 different Daemons. Each Daemon comes with its own set of card pools and relic pools. Abusing the synergies of cards and relics is the key to conquering your foes. To get Daemons, you need to pass the negotiation.

Unlike Shin Megami Tensei, which requires players to give the correct response (usually fixed) to the Demon's question or request; in Grid Lost, Daemon negotiation is a slightly more complicated and randomized mini-game. Due to the length of this dev log, I'll write about the negotiation mini-game in a separate dev log in the future.

To separate itself further from the pack, Grid Lost uses a unique combat system that I've not encountered in any other games in the same genre.

Combat

Instead of having separate turns for the enemy and player, both sides will act at the same turn. So how do I know who will go first? The initiative decides the order of actions. If yours is higher, you go first, and vice versa.

What'd happen if both are equal? A clash will happen where both sides are competing to gain the upper hand. 

For more information about the combat system, please stay tuned for the next dev log! Alternatively, you can try out the demo and see for yourself~

https://kakuseika.itch.io/gridlost

If there is any feedback, feel free to leave a comment and help me to make the gameplay better!

Wow, the visuals are amazing!
the aesthetics really go with the feeling of deckbuilding/ run based... as if you are trying to hack in and go deeper with your build

I look forward to hearing more about how it works!

Dev Log #02 Combat Pt 1

At the beginning of this project back in 2022, I had a very different idea for this project. It was supposed to be a memory-matching game with some rouge-like elements. Shortly after the start of the project, I temporarily worked at a game studio for 2 months. The studio was making a beat-em-up game, which got me thinking: "Maybe I should make a card game with mechanics inspired by action games." I didn't quite figure out how to mesh that idea with my memory-matching game, and thus, I completely scratched the memory-matching concept and redesigned the whole combat system.

Question 1: How the hell can I implement "frame data" from fighting games in a turn-based game?

Well, I can't. But, there is an alternative. To discuss the alternative, first, we need to understand what "frame data" does. In a fighting game, an attack consists of startup frames,  active frames, and recovery frames. 

Img by Dash Fight, https://dashfight.com/news/understanding-frame-data-in-super-smash-bros-ultimate-161

What we need to focus on here are the startup frames and recovery frames.  Startup frames determine how long it takes for your attack to become active.  Recovery frames show how long it takes for the character to return from an attack pose to an idle pose. The character cannot do anything until it returns to the idle pose. Hitting an enemy causes the enemy to start the on-hit animation, and it would take x amount of frames for the enemy to return to its idle state.

We need a system that tells the player who will act first and also a way to confirm whether the next attack will trigger earlier before the enemy's action. We have seen "this system" in turn-based RPGs, like Final Fantasy. Players can apply a debuff to slow down the enemy, which is like to confirm your next action will start before your enemy recovers. In other games, players' attacks can even delay the enemy's turn.

Img by Giant Bomb, https://www.giantbomb.com/conditional-turn-based-battle/3015-2432/

My solution is slightly different. I call it the Initiative Priority System. The side with higher initiative goes first.

          Initiative = card speed + speed mod

The card's speed value is like active frames; it shows how fast your action is. In my earliest prototype, a card had an enemy-delay mod and a self-delay mod, which simulated the enemy's on-hit recovery and the player's attack recovery. However, there was so much information on a card already, and having these two would only complicate the game further. Therefore, I combined these two values into a single value that I called speed mod. 

Playing a card adds speed mod.  Speed mod influences your initiative on the following turn. Note that the value does not stack (some cards bypass this rule with special passive effects). If you take a hit, then your speed mod decreases to 0.

The pointer above shows my initiative. The one below shows the enemy's initiative. In the above case, I have a +2 speed mod from my last attack. The last attack was a successful hit, which reduced the enemy's speed mod to 0. In a way, one can say that I have a +2 frame advantage. Even though the default speed of my enemy's action is faster than mine by 1, because of the speed mod advantage, this turn I can act first.

An important aspect of combat is to manage your speed mod so you can act first and interrupt your enemy's action. If the enemy gets interrupted, it loses that action and moves on to the next. If done correctly, you can constantly interrupt your foe and completely deny its turns!

However, there is a problem... Players can see the enemy's intent. If so, wouldn't it be too easy for players to constantly interrupt the enemy's action and never worry about getting hit? Well, that's where the shield mechanics come in~ Since this section is already getting too long, I will talk about shield mechanics in the next post. Stay tuned!

Dev Log #03 Combat Pt 2

In many action games, enemies have an invisible variable that slowly builds up whenever they take damage. Once such a variable meets a certain threshold, enemies get interrupted. People call it stagger. In Dark Souls, it's akin to poise. In fighting games, this is something like the super armor. In my game, Grid Lost, this variable is the shield.

Shield

Shield works similarly to shield in Slay the Spire; it prevents incoming damage to HP. Additionally, in my game, the shield protects Daemons (both players' and enemies') from interruption. However, shields do not negate status effects. One thing that works differently from Slay the Spire is status effects such as overheat and parasites (think of them as burn and poison) do not damage shields; these effects do true damage, which ignores shields and directly damages HP.

So why create an additional damage type called true damage?

Uh... my preference? Ok, it's a little bit more complicated, but mostly my preference. There is a simple trick to empower players: LARGE NUMBERS!! Many cards can do hundreds of damage with the right amount of damage buff. However, this creates a problem since large numbers are harder to compute. 

If you're good at math, this is a non-issue. But even if you're good at math, doing that kind of calculation will become annoying and bothersome after an hour. I keep the shield value as small as possible and create a separate stat called shield damage, which is smaller than the regular damage. I could slap the shield damage variable onto every effect, but I want more varieties, hence, the introduction of true damage.

Status effects and passive effects 

In the game, there are two types of effects on a card: status effects and passive effects. Status effects work just like any other RPGs; they do DOT or increase/decrease characters' stats. Passive effects passively boost a card's potency or cause combo damage under certain conditions. 

For example, burst causes an explosion that damages adjacent Daemons if the attacked target has overload status effect. Burst does 2 shield damage to the explosion origin and its adjacent Daemons; this allows fast cards that do low shield damage into an absolute monstrous shield wrecker.

Some status effects do true damage, while others don't. Passive effects usually do non-true damage (for now, I've not added a true-damage passive effect. Maybe I will, maybe I won't). True damage sounds too good to be true, right? It does direct damage without concerning shields. 

BUUUUUUUUUUUUT, there is a drawback: true damage cannot interrupt. 

The intention of true damage is just a way to pressure your enemies when you cannot break their shield. Enemies are going to get stronger after each level, and players need tools to chip away at enemies' health. But remember, your foes can do the same things to you.

Now let's get back to the shield. How do players and enemies regenerate shields? Through cards?

NO. Yet another design that is different from traditional deck-builders. Grid Lost doesn't have a separate independent turn for players and enemies. If I had to play a card just to generate my shields, I would be wasting my turns desperately repairing my shields while letting enemies rain down hellfire upon me. HECK NO. On top of that, if I didn't have a card that gives shields, I would be at a severe disadvantage, especially in early games.

Image from https://steamcommunity.com/sharedfiles/filedetails/?id=2898759031

The solution to the problem is inspired by Chained Echoes. In Chained Echoes, there is an overdrive bar that increases/decreases depending on the action you take. While yellow, you get no beneficial effects. While green, you do more damage,  take less damage, and your skill costs less resource. While red, you take more damage.

In Grid Lost, this mechanic is called RAM level. Every card that you use has a RAM value. At RAM level 1 (green), you gain 5 shields every turn and you take 50% less damage. At RAM level 2 (yellow), you gain 2 shields every turn. At RAM level 3(red), you gain no shield and take 30% more damage, but you do 100% more damage. Make sure you time your actions correctly. Taking advantage of the benefits of each RAM level is the key to success.

Be careful! The worst case scenario is taking damage when both you and your enemy is at level 3, it's pretty easy to hit over 400 damage in this scenario. Most Daemons only have about 1000 health, THAT'S 40% OF HEALTH GOING BYEBYE YO! 

Dev Log #04: UI update

It's been a while since the last update. My health issues have hindered my development for the past few weeks. This post will be different from the usual. Instead of breaking down game mechanics, this post showcases some UI changes I implemented.

After receiving feedback about the lack of support for mouse control, I changed the UI to allow mouse interactions. Now, players can select items using the mouse instead of a keyboard.

Players can also click on the key prompt. I rarely use this feature, but maybe someone out there will find it useful.

Games such as Slay the Spire allow the mouse to hover over certain keywords, making it easier for beginners to learn important game mechanics. I hesitated to code this because it was complicated, but it became apparent that whatever alternative solutions I came up with weren't good enough. FINE, I'll do it.

UE5 allows users to create custom rich text decorators, which react to the mouse-over event and construct tooltip widgets. However, C++ is required to code custom decorators, something I'm not good at. Another way to achieve a similar result using blueprints is to break down a sentence into individual words; each word is an independent widget wrapped inside a wrap box. The tricky bit is the language. Chinese, Japanese, Korean, etc, don't use white spaces to separate words like English. I had to code separated logic for different languages so the function could correctly parse the sentence.

The obvious drawback of this method is that long sentences can create too many widgets. To optimize, I use "//" to isolate parts that contain no keyword. For example, 

"//I have a banana.// 

He has an apple." (Apple is the keyword here.)

The first part of the text contains no keywords. A single text block will spawn to contain the substring "I have a banana". The second part has a keyword; so the function breaks down the sentence into 4 separate word widgets. 

In addition, I added widget pooling so the game would not garbage-collect and construct new widget components constantly. Unfortunately, even with optimization, my solution can't rival the C++ solution for its sheer efficiency.

I'm going to gradually update all the UI in the game to make them more PC -friendly. Next on the list are the combat widgets.

Map UI #05 update

Here are some updates I made to the map UI. Unlike other UI components, the map is a 3D object. Interacting with 3D objects is simple, Unreal blueprint has a node called Hit Result Under Cursor By Channel, which shoots out a line cast directly under the mouse position in the world space.

Players can freely scroll through the map using the keyboard or clickable arrow keys. I thought about using the mouse to scroll the map, for instance, placing the mouse at the edge would scroll the map in that direction. However, a smooth transition between map scrolling and node selection was challenging. When I played Metaphor, I never used my mouse on the world map to scroll for the same reason.

Hovering over a map node reveals information about the node, such as its name, modifiers, rewards, etc.

Mouse click starts the node event; of course, this wouldn't work on the node if it's unreachable (I couldn't possibly allow my players to skip town, no?).

Combat UI update

Here are some updates I made to the combat UI. I redesigned the layout of UI elements. Hovering on effect icons shows the corresponding effect's tooltip.

I used to have two separate UIs for enemy AI: one for showing intent, and the other one displaying the actual card information that would be used by the AI; now with the changes I implemented, aforementioned information can easily be accessible by hovering over the AI intent on the right side. 

Dev Log #06 Combat Pt 3

With the recent rework of the UI, I also reworked some game mechanics.

Withhold (Original design)

In the original concept, "withhold" allowed players to keep a selected card in hand for the next round. Card and effect synergies are crucial to the combat design. Unlike other card games, here, players' actions can be interrupted if a foe hits them without the protection of a shield. Seeing a great hand get wasted can be frustrating. "Withhold" was designed to handle this problem.

In addition to keeping cards, "withhold"  was an alternative option to reduce RAM usage. Recall that every card that players use costs RAM. I designed security-type cards to reduce RAM. Players will not always have a security-type card when needed, so a limited backup option should be in place to ease the difficulty of resource management.

There is a limit to how many times you can "withhold" (2 times). The limit resets after your hand is empty at the end of a round. Withheld cards cannot be removed from your hand at the end of a round. In other words, you cannot reset the limit at the end of the round when you withhold, since your hand isn't empty. Abusing "withhold" will result in players having too many cards; it may take several rounds to empty their hands.

Problem with the shield economy

Advantages that players/AIs built up at the early stage of a round can have a snowballing effect. Maintaining an interruption streak would stop the opponent from damaging shields (the enemy's shield is getting crushed all the time. Without the protection of a shield, they are interrupted and thus cannot hurt you); this created an edge in the shield economy, which made it harder for the opposing side to overturn the tide. 

Though it felt good to be the only one constantly throwing the jabs, the satisfaction of complete dominance over your foe would soon wear off, and what was left was boredom for the lack of challenge. The reverse situation could happen to the players; it would be irritating without measures to even the playing field.

Add additional features to "withhold" to solve the problem, but...

My first attempt to solve the problem was to add shields when withholding. However, there were two glaring problems: 1. If I already had an advantage with the shield economy, this would only worsen the issue; 2. I couldn't attack while withholding. Should the enemy attack, the shield I gain from withholding would easily get destroyed, which wouldn't help to level the playing field. 

Adjusting the amount of shield gain was the first thing I thought about. But obviously, this didn't solve the underlying design flaw. If too much, it would worsen problem 1. If too little, it would worsen problem 2.  The problem had been a bug in my head until recently.

Withhold -> Defense (reverse thinking, instead of addition, think subtraction)

Instead of adding the shield, why not reflect shield damage to the attacker? 

1. No more free shield with the press of a button. If the enemy didn't attack, the gap in shield economy would remain the same.

2. If the enemy attacked, reflected shield damage would help to reduce the gap. Note that the shield damage reflection is not 100%; I don't want the defense to be too overpowered.