Pem's Code Blog

One of the big missing pieces to make the game truly playable (instead of just a prototype) is quest specific game logic.  Quests are defined by HeroScribe XML, which lacks quest text (including specific game rules).  Here

mepem37 :: 2019/05/26 (Sunday, May 26, 2019) :: HeroQuest, Unreal Engine :: No Comments »

Most of the basic functionality is there, but it’s missing:
1) Ability to complete a quest, carry on to the next quest, maintain state cross-quest, save/load progress, related menu system.
2) Quest-specific logic.  I plan to implement a scripting interface as an extension to HeroScribe XML.
3) Quest-specific monsters, monster spells
4) AI has much room for improvement.
5) Sound effects.

So it

mepem37 :: 2019/04/18 (Thursday, April 18, 2019) :: HeroQuest, Unreal Engine :: No Comments »

I made some time (during the holiday weekend) to work on VR mode.

I added dragging drag camera based on this tutorial: https://www.youtube.com/watch?v=XgGGBQc6fVM&feature=youtu.be -> https://imgur.com/a/L2Ild

I also added prototype motion controller input support.

mepem37 :: 2018/11/24 (Saturday, November 24, 2018) :: HeroQuest, Unreal Engine :: No Comments »

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.

mepem37 :: 2018/11/23 (Friday, November 23, 2018) :: HeroQuest, Unreal Engine :: No Comments »

There are many times when

mepem37 :: 2018/09/16 (Sunday, September 16, 2018) :: HeroQuest, Unreal Engine :: No Comments »

Expansion maps starting with Kellar

mepem37 :: 2018/09/01 (Saturday, September 1, 2018) :: HeroQuest, Unreal Engine :: No Comments »

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

mepem37 :: 2018/09/01 (Saturday, September 1, 2018) :: HeroQuest, Unreal Engine :: No Comments »

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.

Consider the following (11 means atk roll 1, def roll 1) (where 123 is skull, 45 is white shield, 6 is black shield):

11 12 13 14 15 16
21 22 23 24 25 26
31 32 33 34 35 36
41 42 43 44 45 46
51 52 53 54 55 56
61 62 63 64 65 66

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.

mepem37 :: 2018/09/01 (Saturday, September 1, 2018) :: HeroQuest, Unreal Engine :: No Comments »

Here

mepem37 :: 2018/05/27 (Sunday, May 27, 2018) :: HeroQuest, Unreal Engine :: No Comments »

Justin implemented spells a while back, but this is my first time posting it in a video.

mepem37 :: 2018/05/24 (Thursday, May 24, 2018) :: HeroQuest, Unreal Engine :: No Comments »