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.

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 #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.

Thank you for your feedback. I'm currently working on fixing the game. I saw your comment about a 1-hit kill and enemy not instanced. I was playing my latest build (which I downloaded from the Itch app). The enemies didn't die in one hit and spawned properly, so I was curious about that bug report. If you don't mind, would you try updating the game and see if it works now? v 0.1.0 should have fixed that problem. 

Also, could you elaborate on "a lot of management of contracts / mandatory phases that break the player’s involvement"? I don't completely understand this part.

You mentioned you are stuck in the first-person view, could you elaborate on the scenario, and how it happened?

When you say "keys from across the keyboard", would you let me know which keys so I can change the input setting?

https://kakuseika.itch.io/gridlost

Grid Lost is a sci-fi, rouge-like, deck-builder made in Unreal Engine 5. You play as a special agent who operates under a fictional nation called United Vaniber. Your task is to dive into the Grid network and deter foreign invaders attempting to steal the Grid technology and threatening your nation's sovereignty.

The game features a Slay The Spire-like map where you explore and complete various room events. A unique combat system that is unlike any other deck-builder. Every card has a speed value that affects the order of turn actions; manage your speed, interrupt your foes, and dictate the flow of combat. There are tons of cards and relics to choose from to create a build that fits you!

If you like or dislike the game please leave feedback (combat, visual, UI, difficulty... anything)! It will help me to improve the game! 

https://kakuseika.itch.io/gridlost

Grid Lost is a sci-fi, rouge-like, deck-builder made in Unreal Engine 5. You play as a special agent who operates under a fictional nation called United Vaniber. Your task is to dive into the Grid network and deter foreign invaders attempting to steal the Grid technology and threatening your nation's sovereignty.

The game features a Slay The Spire-like map where you explore and complete various room events. A unique combat system that is unlike any other deck-builder. Every card has a speed value that affects the order of turn actions; manage your speed, interrupt your foes, and dictate the flow of combat. There are tons of cards and relics to choose from to create a build that fits you!

If you like or dislike the game please leave feedback (combat, visual, UI, difficulty... anything)! It will help me to improve the game!

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 #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!

So simple yet so addicting. I thought I got the perfect run, nearly endless supply of mana, then got cocky and overlooked how much of a threat taunt enemies are...

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!

I really like the game idea, art style, and music. While playing it, I'm constantly thinking about card games. It might be interesting to have some card management (or dice management in this case) in the game. 

Thank you. I agree the movement is an issue.  Unfortunately, didn't come up a better solution during the Jam

One of the most unique ideas I've seen. Playing as a frog is brilliant. 

One of the most unique ideas I've seen. Playing as a frog is brilliant. 

Ye. I wasn't able to solve the gimbal lock and some rotation problem in UE4, so I broke up the movement and rotation into separate game mechanics

The art is amazing. Great tutorial levels to teach all the important mechanics. As for game levels, I wish there were more alternative routes,  so I wouldn't have to wait for the RNG to be in my favor. It's entertaining to see AI getting trapped or even sunk, but getting trapped due to poor RNG can be a little frustrating. 

Inkless is a 3D puzzle game in a Sci-Fi world. You play as a dice, an inkless dice. Collect ink scattered around the map to progress. To collect ink, make sure the correct side is touching the ink. Use the mechanisms in the level to change your movement direction and orientation. Explore an abandoned facility. And remember: "Don't be INKLESS."

Link: https://steadjojo.itch.io/inkless

The simplistic art style, love it! Nice choice of music, kinda reminds me of a Lego Build's journey. But the control feels confusing sometimes (partially due to the isometric camera ).

Interesting but maybe too ambitious for a 48-hr game. I'm not sure whether I'm progressing because I am regularly teleported to different areas.  There should be some kind of reference to prevent players from getting lost. Traps should look more deadly! I didn't know it was a spike until I walked into one.  And the background, middle ground, and foreground should be more distinguishable. 

Cool and very trippy~~~~. The crosshair needs more contrast and BIGGER!!!!!!!

Got it, my misunderstanding of the rule. 

Cool art. The different dice ability is interesting. However, there are a few issues:

1. Damage adjustment. Red dice, the first ability, should do a bit more damage. Instead of a 6-hit kill, I suggest buffing it to a 2-hit kill or at least a 3-hit kill. Currently, enemies take too much damage to die, which negatively affects the pacing for a beginner level. Should you decide to buff the red dice, you should also increase the yellow dice damage to showcase its power. 
2. RNG, green dice & yellow dice. I like the idea of teleporting dice and an explosion dice that turns you into a rocket man. However, movement options should be persistent, especially when I need to get over a large gap.
3. Tutorial. For example, (for blue dice) shorten the spike distance. I can drop one ice, jump on it, and get to the next platform. Also, the duration of the ice can be longer. Ideally, there needs to be a visual cue that tells players when the ice will melt and disappear so players can react. But it's a 48-hr marathon, who has that kind of time, right. So the easiest way is to prolong the duration of the ice cube.

Interesting concept. There is a bug with the square pattern. 

3 6 

5 6

1 2

so 3 + 6 + 6 + 5 = 20, but the game doesn't count that as the correct combination. Do "1" and "2" interfere with the final result?

Wow, great ideas and mechanics design. I wish that I could hold onto a piece of tile, similar to some Tetris games.

Create all the art within 48 hrs? Respect. However, I think the city-building game that you are aiming for might be too big for a 48-hr jam. Need more rules. Currently, I can place any tiles beside any other tiles without restrictions and limitations. There is a lot of potential, and I'm interested in what this game will become in the future.

Wow! Really interesting concept! I like the idea that the top side of the dice determines what weapon I can use. The weapon recoil is fun. Shooting a laser and seeing myself get yeeted to the other side never gets old. Melee enemies are the biggest challenge. I often find myself getting cornered by them. They add a new layer of decision-making since they impose a larger threat to players. But getting trapped without a way to fight back can be frustrating.

Maybe 1 or 2 seconds of I-frame after getting hit (changing collision profile to something that ignores enemy collision)? For a physics-based game, this is probably not the best idea. And it will be weird seeing players passing through enemies. Another idea is to change melee enemies to short-ranged ranged enemies (like a shotgunner). Poker cards have a unique bending melee attack. Maybe instead of melee, it generates a gust of wind at its "stomach" that propel players? Adding a longer cooldown to melee attacks may also help. While in cd, the card will stand still instead of moving toward the player.

Thank you for your feedback. Because I had played the game so many times, I completely overlooked the potential of people getting lost because of the control change. Adding an arrow is an excellent suggestion! The implementation of the "Hiding Wall" was kinda rushed. The camera is a big challenge that requires more time to tune. In short term, I think I'll change the "hidden" material and increase the line trace range to cover more area.