Description

Heroine Rumble is a 3D action rape or get raped fighting/H-wrestling/battlefuck/sexfight game currently under heavy development (for real). Choose your favorite character from a roster of sexy, unique heroines and guide her to victory! (Or watch her get dominated in the arena XD)

ヒロインランブル(Heroine Rumble) は現在開発中の、「凌辱バトル/エロレス/バトルファック」のゲームです!(嘘じゃないよ!) キャラクター選択画面からオリジナルのセクシーヒロインを選んで、彼女を勝利へと導こう!(それかアリーナでドミネートされる姿を眺めるのでも(笑)

Download HERE (v0.344). (4/11/2017)
Support/donate/get the newest version (v0.502) at Patreon!
Live Chat: Discord.
Browser version (0.5): Itch.io.

Monday, September 18, 2017

Outfits and the Plan Ahead

Been working on solving various animation problems arising from independent torso and leg movement. Should be able to wrap it up this week together with the first iteration of combat. But somewhat tired of working with barely presentable in-dev assets so the next step is to (re)introduce outfits and bring the general graphics quality to be on par with Heroine Rumble.

I am a little disappointed with Heroine Rumble's RNG-based outfit selection system. It is certainly better than nothing but leaves a lot to be desired. So instead, the next game will feature a fully functional inventory and equipment system. You will be able to pick and choose individual outfit pieces and wear whichever combo you like.

I plan to have at least the following "slots" for customization:
  • Torso/Top 
  • Arm/Hands 
  • Legging/Bottom 
  • Feet/Boot 
  • Skirt/Dress 
  • + 2-4 accessory/attachment slots for things like wings, hairband, etc. 

This require some changes to the underlying data structure + rendering system so its not a simple "copy and paste" job. But I don't foresee the base system, without the actual user inventory/equipment part, to take very long.

After the base outfit system is done + other touch-ups, I plan to start releasing playable "tech-demo" "not even alpha" "for enthusiast" builds for Patreons. Starting with something very simple, like here are X wandering enemies on the map, and you can fight them, but not much else. And build from there.

The current ETA for first such a build is early-mid October, and then likely monthly builds from there onwards. Again, the first couple builds are going to be very very rough tech demos and they are certainly "for enthusiasts" only.

Sunday, September 10, 2017

Combat, part III

The combat mechanics are almost finished now. There are still quite a few bugs and animation problems that need to be sorted out, but enough core systems are functional now to create an overview of how it works.
So like I mentioned before, the game will be based on Mount and Blade melee combat system. I like to start off by mimicking the functionality of other successful titles. This is because, well, those games probably did somethings right and and there are merits to their setup, even if it's not obvious at first.
First thing first is the camera. The camera is controlled via mouse movement as what you expect in a 3rd person camera game. A set of direction keys (WASD) controls the character movement. The character can run and walk (guard):
The core of the combat system is very simple. There is attack (left mouse button) and block (right mouse button). There are 3 different attack directions and 3 guard directions. To pick the direction of block, swipe the mouse towards that direction and then hitting the block key(right mouse button).
(Attacks works differently than what the following gif shows, it will always come from the same direction of block rather than be controlled by mouse movement)
The purpose of these directions is that blocks only work if you block the correct attack direction:
Some more "advanced" stuff: 
First, you can move during attack/block. 
Secondly, you may cancel an attack via guard before the attack is fully committed.  This can be used to "feint" your opponent but since online multiplayer is a long, long distance away its more of a "oh shit" thing:
Another concept is "parries." If you time the guard to be as close as possible as the time when the attack swing will connect, there is a greater chance of interrupting the swing. The idea is that there is a tradeoff between safety (guard as soon as possible) vs payoff (guard as late as possible, but possibly missing the block)
And putting everything together:
But who am I kidding, the player is so overpowered against the AI that you can simply do this:

Thursday, August 31, 2017

Combat System, part II



It was certainly a challenge to get the upper body and lower body independence to look believable. But it is mostly working now.

Here is a rather big gif file as demonstration: 



https://gfycat.com/GleamingScratchyLeopardseal for full gif. Warning: Large file.

Here is another view from different angle. Note that the actual hit system is not implemented yet.


Here is a more detailed explanation of the the combat system for those unfamiliar:

Controls: 

  • <DIR_KEYS> (WASD) -> movement 
  • <ATTACK_KEY> (mouse1) -> attack 
  • <GUARD_KEY> (mouse2) -> guard 

Movement: <DIR_KEYS>
  • 2 modes: walk and run 
  • when walking: unit is facing direction the unit is looking at (eg. camera), moves at slower speed than run 
  • when running: unit is facing the direction its moving towards, moves at faster speed than walk 

Guard <GUARD_KEY>
  • turns guard on 
  • running is disabled/ unit will only walk during guard 
  • direction of guard is based on the prev pressed direction key. So for example, <LEFT> + <GUARD> means to enter left-guard, or switch to left-guard from a different guard direction 
  • Guard persists even if <GUARD> key is let go 
  • Guard is canceled when player double taps a direction key (starting a run) 

Attack <ATTACK_KEY_DOWN>
  • prepares an attack, there is a minimal period of time (affected by weapon/stats/skill/perks/etc) before the actual attack swing is released 
  • if <ATTACK_KEY> is held down: 
    • the attack swing will only initiate when the <ATTACK_KEY> is let go 
    • charging longer than the required time will increase the amount of damage dealt, up to a limit 
  • if <ATTACK_KEY> is immediate released (eg. a click): 
    • the attack swing will immediate commence once the minimal required amount of time has passed 
  • direction of attack is inputed in a similar manner as guard 
  • an attack can be canceled with the <GUARD_KEY> before it is "released" 
  • Running Attacks is possible 
DETAILS
  • Blocks are only successful if the direction of block matches the direction of attack. So for example, a <UP_BLOCK> is ineffective against <RIGHT_ATTACK>. 
  • Successful blocks are not 100% guaranteed to interrupt/stop the opponent's swing, but will reduce the damage taken. 
  • Attacks have cleave by default, the swing is not stopped after hitting the first opponent but will continue on, possibility hitting multiple opponents with every swing 
  • No location differentiation (hitting head same as hitting leg)

Saturday, August 19, 2017

[Patreon] - v0.51




Patreon LINK.

"Might as well get this out of the way now.

This version fixed all the bugs that are reported so far, if I missed anything, please let me know.

A new feature added is the ability to change the game's speed. Some people felt that the game was too sluggish so now its possible to speed up the game. Up to 200% of the base speed. Default is 120%. (so ~20% faster than previous versions by default)

A few also wanted a hard mode of some sort after beating Story Mode. I tried but the current setup doesn't really allow me to easily add interesting encounters. And at this point I don't want to make major changes to the game.

Besides, since you can play the character in exhibition and team mode the game provides all tools available to create your own challenging encounter. As such, no changes to Story Mode are implemented."

Wednesday, August 16, 2017

Combat System


Added Inverse Kinematics to engine and implemented enough functionality for independent upper body and lower body movement.

Kind of tired of talking about tech so lets do something different this time.

As mentioned before, the next game will feature weaponry and directional attacks and guards. Eg, 4 attack directions - up/down/left/right and 4 block directions. A block is only successful if the block is in the same direction as the attack.

So here are the 4 blocks for a sword user, can you match them with the guard direction? (up/down/left/right)



Sunday, August 13, 2017

Models support



While waiting on the poll result to come in, I implemented the placement and removal of arbitrary models to the engine well. They allow for far greater detail than merely sticking to voxel cubes.

Working on getting girls on screen and towards something playable now.

As for the combat poll, the majority are in favor of independent attacks and movement. And some suggested that the movement freedom can be limited base on what kind of action the user is performing. Perhaps heavier attacks are more restrictive and/or stats should have a role.

A good idea certainly, but the tech wasn't quite there yet. (HR locks in movement during attacks). Basically what needs to done is to have separate action for upper body and lower body. That part is easy. The difficulty lies in "joining" them together.

The tech for "joining" the body parts together is inverse kinematics. Something I am actually very interested in implementing. It have other applications as well, such as placing hand more firmly on the different sized boobs rather than hover/clip :).

Anyways IK is the last piece of tech to implement before the shift towards content. It shouldn't take too long.

Thursday, August 3, 2017

A question about combat. (patreon poll open to everyone)

POLL HERE

Implemented collision handling across multiple chunks. The "seams" in between chunks were a PIA to handle but it seems to be working correctly now. Also added save/loading functionality for maps. And after sometime playing basically Minecraft-lite, made this:





Anyways, what this means is that the voxel terrain system is functional enough for me to start considering implementing/porting gameplay elements. And while I decided on the Mount & Blade directional attack/block system, I am undecided on whether or not characters should be able to move in any direction while using their melee attack.

So for example, in fighting games, and SoulBourne games, the characters can not control the movement during their swing; once they start their melee attack, their movement pattern is set from the start to the end.

In contrast, in Mount and Blade and say, shooters, attacking is independent of movement. So a character can move freely while attacking.

Which one do you prefer?