Speech Bubbles

Here is what it looks like:



Here is a version with moving camera angle:



They are implemented with curves and triangulation instead of as textures (images), so stuff like changing their color is very simple too:

Some design considerations and features

For this game, I want a simple control scheme that is playable with one-hand. It should be playable with either using a mouse only, using a keyboard only, or using a controller. The best way to accomplish this, in my opinion, is to keep the number of buttons low. Therefore, for gameplay, there will only be 2 buttons, an “Affirmative” button, and a “Back” button + directional controls - WASD/arrow keys on the keyboard, the cursor with a mouse. This doesn’t include things like menu keys or camera controls.

The “Affirmative” button does what you expect and the “Back” button “undoes” an action. For example, during combat, you can use it to undo movement if you misclicked or found a better position; or having second thoughts after having picked an ability, to “undo” that and select another ability:

Note that however, once you have “committed”, that is, actually used an ability on the target, you can no longer undo. For the obvious reasons - you shouldn’t have unlimited tries in case an ability missed, failed, or didn’t roll as high as damage as you wanted.

Another new feature is the “Survey Mode”: in this mode, if you mouse over a unit, you are shown their movement range and tiles that they can attack. (Blue - move range, Red - attackable range). What I plan to do in the future is that when you click on a unit in this mode, it will bring up a more detailed unit info screen that shows that unit’s capabilities.

The “Survey Mode” can be accessed by using the “Back” button when you don’t have an ability selected nor is a move undo possible. It can be exited by using the “Back” button again or by using the “Affirmative” button on the unit that is currently taking their turn.

An alternative design is to merge the “Survey Mode” functionality with regular combat and not have a separate mode. The problem is that there is a potential ambiguity: when you hover over a unit that is within your movement range, should the game stop displaying your movement range and display that units range instead? If that is so, then when you un-hover that unit, the game will display your movement range again instead of that units. I find this flickering annoying.

Another consideration is for consistency when the unit is grabbed/grabbing. When the grab selection menu is on, the Directional keys (think keyboard and not mouse)  will no longer be controlling which tile to select, but instead controls which grab option to pick. So the “Back” button is necessary to exit this grab selection menu and go back into surveying the battlefield. With a separate mode, then this control setup is the same regardless of whether the unit is a grab.

TECHNICAL STUFF BELOW:

Earlier this week, I was considering on how to implement save/load functionalities and stuff like how to automatically generate sliders that hooks to an object to tweek it’s values. This requires reflection - “the ability of a process to examine, introspect, and modify its own structure and behavior.” (wiki) But unfortunately, this is not a feature that is supported by C++, the programming language of choice for this game. So I had to hand implement this feature:

The ITERABLE_FIELDS macro hides a lot of ugliness, but the end result is fairly reasonable, at least in my opinion anyways.

END OF TECHNICAL STUFF

The next feature I am going to add is text bubbles, which will be displayed above a unit when they react to something. It’s something I felt that was missing in HRT compared to HR, and that it can add a lot of flavor to the game.

Grab System 101

Finally made enough progress on the grab system implementation and UI to make it functional enough. Here is an introduction on how it works.

Units may have certain abilities that can place an opponent into a grab. They might come in different flavors. For example, some may have higher chance to hit, but costs HP or MP. Some may be ranged and pull the victim into you. Shown here is a simple development ability with almost guaranteed chance to hit.

If the grab attempt is successful, then you get to choose which grab position to use. Unlikely HR and HRT, individual positions may have different statistical impact and certain positions may be more effective by default, or perhaps when targeted at weak points of the opponent. Aso unlike HRT, units have to learn different grab positions instead of having everything available at the start of the game.

A slight aside on the grab system. I decided to go with a 1 victim, 0 to M attacker(s) implementation. (M is a limit, currently is at 4) This means things like solo moves, 1:1, threesomes are possible, but a single attacker, 2 victims grab is not.

Also, unlike HRT, threesome+ moves are only usable when the quota for attackers are met. Meaning that you cannot use a threesome move with a single attacker. This is because the positions are often animated with the assumption that all the characters are present, and playing the same animation, but with missing characters just make it looks weird.

How it works now, is that when a new attacker joins, he/she have an opportunity right there to change to a new position immediately, and everything then works out from there. (Doesn't work yet)

On each unit’s turn, if they are in a grab, instead of picking from regular abilities (like attack or move), they are restricted to pick a choose from a Grab Action. They kind of function just like regular abilities, but more specific to influence grabs. For example, the attacker gets to choose actions like “Dominate,” “Commit,” “Switch” whereas the victim gets to choose actions like “Escape”, “Reverse” and “Recover.”

A new concept introduced is “Advantage”. The idea is that Advantage determines (and restricts) what options are available to each participant and influences their success chance and effect. For example, Escaping chance for the victim may get lower and lower as the Advantage turns more against their favor. Conversely, if the victim gains enough Advantage over the aggressor, then the victim can easily Reverse the situation and turn it into their favour.

A note here is that Grab Actions are not set in stone and units can acquire different ones throughout their journey. And I totally want to make a grapple-focus character a thing. And it shall be quite effective in a one versus one situation, but with weakness against groups (because non-grabbed enemies can interrupt) and weak to enemies not susceptible to grabs (for example, slimes).

NOTE: the success chance on individual Grab Actions are a simple fixed value on the gif, but will be dynamically calculated when fully implemented. Models/animations are just placeholders.

Progress

Hope everybody had a good Thanksgiving! (if you celebrate it)

I been working on the new game and made lots of progress. Dungeon generation, path finding, UI, transition, just to name a few. Here is a quick gif to demonstrate the dungeon exploration + encounter/combat portion of the game.

The graphics/animations (or lack of) are just placeholders, my primary concern is to get a Minimum Viable Product up and running first.

Next step: the framework for the grab system. Stay tuned!

Why make a turn-based game?

“Turn based RPGMaker games and VNs are a dime a dozen, and is usually uninspired, why make another one?” 

On that, I wholeheartedly agree. But, I am not making another RPGMaker game, I am making a party based tactics game. Even though these two genres are both turn-based, the game plays out very differently. Most people would agree that games like XCOM, Final Fantasy Tactics, Divinity Original Sin I and II are vastly different experiences than generic JRPG #15235.

So while there are countless RPGMaker H-games and VNs, there are very few tactics H-games in comparison. I’ll be happy to go into the details on the key differences between the two genres in another post if people are interested in that from a game design point of view.

The big reason to make a turn-based game is that it will allow for far greater flexibility and choice in terms of H-content. Let me illustrate via an example. Let’s say you wanted to make a pure H-focused character that doesn’t get involved with physical combat at all. This cannot be done in HRT, because you need to knock down an opponent before you can use H-move on them. Reversing a H-move isn’t possible.

In contrast, consider a turn-based game. Perhaps you can start off by using a “Seduce” skill that brings both parties into a H-move. Perhaps it starts off by you being in the “disadvantaged” position. But, now, instead of only having the option to escape, now you get to choose what you wanted to do: Escape, at say, 70% chance, Reverse, at say, 30% chance, or Enjoy, which may do something like restoring health. Now it’s very obvious what your choices are and what the tradeoffs are, and you can make the appropriate decision.

But what about something like the escape system in HR. The issue with that is that it is potentially very confusing. “What is that red bar?” “Why does the progress reset when I press a button?” But more importantly, I am personally not a fan of Quick Time Events in general and I rather make an interesting turn based H system, that players can play at a pace they want ;) instead of gluing their eyeballs to a portion of the screen to not miss the QTE prompts.

Isn’t it better to completely finish up a game first before moving onto another? 

That is certainly good advice. And that was my original plan. HRT is in development for ~2 years now and content wise, I believe it is on par or exceeds most other H-games. So H-content wise, I consider it done. That is why there haven't been any new H-content for some patches now.

The truth is, I need a break from HRT. I am especially frustrated at HRT at the moment because of the “bodyMesh” loading problem that some people seem to have. I couldn’t reproduce the bug at all in my end. So imagine trying to brainstorm all the possible things that could cause it, come up with potential fixes, getting people to try the build with those fixes, only to find out it doesn’t solve the problem. Many times. (The solution is to upgrade windows/drivers)

I don’t expect everyone to agree with the decision but at least I hope this gives an understanding of where I am coming from. So I am going to take a break from HRT, focus on something else, and come back with a fresh perspective.

What if Heroine Rescue Team was a turn-based game?

Working on a new game! Like HRT, it is a party based and feature in-combat grabs. However, it wouldn’t be an action game but is turn-based instead. 

Here is a super duper early concept video of the gameplay:

Originally, I was aiming for a side-view camera like darkest dungeon. However, that limits the angle you can view the grabs at, so a grid + full 360 degrees camera is more preferable.

There was a lot of good ideas and suggestions for HRT, that I wanted to do, but simply takes too much time and resources to implement due to the high animation requirements or is simply unfit for an action game. For example, more options during grabs, having bondage playing a bigger role in combat, non-humanoid enemies, and so on. 

I feel like that if HRT were turn-based instead, those things would have been implemented by now. Working on a new game also gives me an opportunity to fix some of the things I consider as mistakes in HRT. For example, not being able to customize all your party members. 

What does this mean in the future? Well, for HRT, my original plan was to finish up the Ruins map and maybe add one more zone to the game. H-Content wise, I was pretty much finished with what I wanted to do. I was going to work on finishing up HRT and the new game at the same time, but that just isn’t working out. 

I was getting pretty frustrated at HRT chasing after the “stuck on bodyMesh.json loading screen” bug that I just couldn’t reproduce at my machine. (BTW, people that had this issue told me that upgrading your windows solves the issue.) The new game is also done in a new C++ engine that should have ~10X CPU performance improvement over the current electron-based engine. But that meant switching between different programming languages. That would be fine, if not for the fact that the new game uses blender 2.8+ but HRT relies on blender v2.7X. (The exporter doesn’t work for blender v2.8.) The problem is, blender 2.8 have a completely new UI - selecting items changed from right click to left click, a total reorganization of... everything. 

So, I decided to take a break on HRT and focus entirely on the new game instead. Again, the game is still super duper early - only about 2 weeks of actual development on the game at this moment. There is a barely “playable” demo on discord if you want to test it out and give feedback. In the near future, I will be posting progress updates on the new game.

It’s that exciting time again when you are dealing with something new and shiny. Meaning that nothing is set in stone! So if you have any questions or suggestions on the kind of things you want to see, getting those ideas in early will have a much higher chance to get them included!

I will probably be writing about the design considerations about the new game in the future, but this post is already long enough as it is, so that’s it for now.

Happy Halloween!

Patreon LINK.

This is a small bug fixing patch that fixes some bugs with v0.64.

There seems to be an issue with the game stuck at loading bodyMeshNAnim for some people. I spent the last two days looking into this issue and examined various saves/mods/etc and I wasn't able to replicate it here on my local machine. So still not sure what that is about.

Changelog:

 - fixed bug that cause NPCs (such as recruitables) to not appear in dungeon
- fixed a bug that cause the bgm music in town stacking with other bgms
- fixed a potential crush caused by AI trying to "weaponSwitch"
- only direction key input (WASD default) counts for button mashing now
-   this is so you can still control the camera via arrow keys in town without instantly ending animation