When recording the VR preview (with OBS Studio), I kept getting Oculus Rift Sensor errors (which didn’t happen when I wasn’t recording). So the videos are a bit choppy, but it’s enough to get the idea. The drag-camera (and the more accurate scale) makes the VR experience a lot better, so I’ll be excited to add more VR mode interactions in the future.

I noticed the board/pieces in VR were too big, so I shrunk everything by 10x. Under map > Settings > World Settings > VR > World to Meters: changed from 100 to 1000. This looks/feels a lot more practical. To go a step further, I compared the Elf to the motion controller at 10x (real vs. virtual):

While my 10x wild guess was surprisingly close (to real world object physical size), I found that 9x is even closer:

In terms of the 80/20 rule (Pareto principle), 9x looks very accurate.

When playing the physical board game, we found that there are many times when… If Zargon doesn’t have an upcoming turn, then the optimal (and often obvious) move for the Heroes is often to do something tedious, which drags out the quest. So to solve the problem, we sort of fast forward through the Hero moves (when Zargon doesn’t have an upcoming turn or potential event/trap trigger).

For ex, when a room is empty and the player wants to reposition the heroes before we search for treasure. Or we want to reposition the heroes before opening a door. Or before opening a door, we want to (roll move, skip turns, repeat) until we roll a 12 (two sixes). Or when walking down an empty hallway (there’s no monsters, we already searched for traps), it’s gets tedious to have each Hero roll, move, end turn, repeat. In these scenarios, fast forwarding (compared to going through the motions) doesn’t change the decisions/outcome made by the player; it just makes these parts of the game less tedious.

When play-testing the video game port, I ran into the same concern. So I’ve added fast forwarding logic to make the experience smoother (less tedious). So far what I’ve implemented includes: ) FastForwardIsAllowed() – checks whether fast forward is allowed. Currently it just checks (are there any spawned monsters) and (is fast forward blocked by a special event, because certain quests have events that prevent fast forward). ) FastForwardIsAllowed() => Roll auto 6’s for move. Skips dice roll sequence (physics/animation). This simulates (move roll, end turn x4) until all 6’s is achieved. ) FastForwardIsAllowed() => Don’t gray out Move/Action. This simulates (end turn x4) to get back to the current Hero’s turn.

Implementing these two fast forward scenarios dramatically improves the experience.

Expansion maps starting with Kellar’s Keep and Witchlord have an alternate exit. Instead of the staircase, you can exit on the edge of the map through a wooden exit door. You can also enter the map via a metal entrance door.

I refactored the array bounds from (0-25,0-18) to (0-27,0-20) so that we can have a map border to let heroes enter/exit from map edge. This allows us to use the existing move (and path finding) logic. Later I will extend this with a special case such that walking through a wooden exit door exits the map (ends the quests).

I tweaked the atk/def UI such that the display is a little easier to read (and takes up less screen space). Previously the UI displayed each defense die and each attack die. Now it just displays the total attack, total defense, and resulting damage. For attack, that’s the number of skulls. For monster defense, that’s the number of black shields. For hero defense, that’s the number of white shields. Damage is max(attack – shield, 0).

HeroQuest has a lot of randomness from dice rolls and card drawing. It’s a core part of the fun, though it also makes the game heavily luck based.

I think it would be interesting to have a non-random mode where dice rolls and card draws are pre-determined. In that case, you win or lose entirely based on the choices you make (rather than on luck).

For the physical game, the dice rolls mesh well with the casual style of the game. But for a single player video game port where the levels are more like puzzles, I think the non-random mode is better. Non-randomness is also arguably better for a PvP competitive game (like Chess or Go, or an esport such StarCraft 2).

An authentic way to do a non-random mode is to make the results of each die roll sequence equivalent to the average (of infinity rolls). An atk def sequence is A attack dice followed by D defense dice. In that case, there’s 6^(A+D) possible rolls. We can iterate through each roll and add up the result.

I initially wrote C++ UE4 code to do that using TArray. It worked great with 2 or 3 dice, but started to get slow around 8 or 9 dice. Suppose 9 dice took 2 sec, then 10 dice => 12 sec, 11 dice => 72 sec, 12 dice => 72*6/60 = 7.2 min. In that case, we’d need a pre-computed table of values. If we allow up to 10 attack dice and up to 10 defense dice, for both hero and monster defense (white or black shield), then lookup table would be 10*10*2 = 200 entries.

However, even generating the lookup table offline would take a long time. If 12 dice takes ~7 min, then 20 dice would take 7*6^8/60/24/365 = 22.37 years. Or 16 dice would take 7*6^4/60/24 = 6.3 days. Or 14 dice would take 7*6^2/60 = 4.2 hours. The most attack a monster has is 6 dice. The most defense a hero has is plate mail + helmet + shield + rock skin = 7 dice, or 8 dice if we allow Dark Company’s Ring of Brilliance. So 6+8 = 14 dice total.

I won’t get deep into for this this post, but I notice a pattern. We could skip rows 2 3 5 because (2 3) is a copy of (1) and (5) is a copy of (4). So I suspect there’s a way to optimize the algorithm so that it’s faster than 6^N.

A less authentic way to remove the randomness is to redo the hero/monster stats such that they are designed for simpler non-randomness.

Overall I like the non-randomness idea, but it strays far enough away from authentic HeroQuest that maybe I should save it for a HeroQuest-inspired game, or it can be an enhancement to consider later (a stretch goal after everything else is implemented). In that case, we could have a default authentic mode that uses dice… And a non-random (non-luck) challenge mode without dice.

Non-random mode could also be used for a multiplayer PvP variation. A non-random PvP mode sounds really cool (a turn-based esport).

Anyway, given the limited resources I have to work on a part-time hobby game project, this post is probably just theoretical ramblings. Most likely, for the foreseeable future, I will continue to focus on the dice rolling version.

Justin implemented spells a while back, but this is my first time posting it in a video. UMG menu system for selecting a spell. Each of the 12 hero spells (original quest book) is implemented.

Other recent changes:
* More fixes related to opening doors, the move system, and path-finding.
* UMG menu system now skips disabled (grayed out) buttons.
* When there’s no monster’s spawned, Move rolls auto 6’s. I think of this as “fast forwarding” because the player could skip turns and keep rerolling until they get 6’s.

With hero Body HUD I ran into a good use for shared_ptr. At first there was a bug when displaying a dead hero’s health. When any figure dies (hero or monster), the corresponding HqSpaceOccupant is deleted, which deletes the pointer to the HqFigure (HqHero or HqMonster). We still had another pointer to the HqHero for the HUD, but it was now pointing a deleted object, so the HUD displayed –35 (instead of 0) Body. I fixed this by using using shared_ptr. I suppose a messier way to do it would’ve been to have HqSpaceOccupant dtor conditionally skip deleting its figure when the figure is a hero (HqHero). The video lets heroes die to show the bug fix.

The video also shows the latest Move system with mouse input and arrow key input. For debugging, the hero rolls 255, which is why there’s so many red squares (otherwise the game only displays valid Move spaces).

The current turn order system (including the Body HUD) lets you (in code as there’s no UI for it yet) use any order for the heroes. The HUD assumes four heroes, though I don’t think it would be much work to make it N heroes.

I did some additional basic steps to support VR. Previously we had two cameras – the main spring-arm camera that follows an invisible pawn, and a fixed birds eye camera (for orthographic projection). I added a third camera for VR.

With the third camera, we’re able to look around and see the motion controllers… I think for VR, the camera control code will be separate from the main camera. No auto camera moving. Isn’t attached (via spring arm) to an invisible pawn, so panning etc will also be different.

Brass Tactics is one reference for how motion controller camera movement can work. Hold down (a) grip button(s) to drag the camera/world.