Blender Renders

Simple renders done in blender to get a feel how the head looks like when viewed with lighting.

Merry Christmas!

Here is another poll if you got some time during the holidays.

Out of the following 3 head models, which one do you like the most?

Vote Here: https://www.patreon.com/posts/32601657

A:

B:

C:

A, B, or C?

Vote HERE.

I am working on a new female base model + rig. Out of curiosity, which of the 3 following faces (body + hair are the same) do you like the most?

A:

B:

C:

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.