Posts RSS Comments RSS Del.icio.us Digg Technorati Blinklist Furl reddit 105 Posts and 7 Comments till now
This wordpress theme is downloaded from wordpress themes website.

Archive for the 'HeroQuest' Category

HeroScribe Pem’s Fork update

When I was chatting (in our Discord channel) to Spiffy about working on the Lua code, I noticed that in Quest 3, to find Ulag’s position (left top), is kind of kludge.  HeroScribe GUi doesn’t show it, so you have to count the squares in the GUI and/or search the XML to figure it out.  So I added it in the GUI.  It’s a small update, but it’s a great example where updating HeroScribe GUI is useful for writing the Lua code.  This will be used in HQBase-03-LairoftheOrcWarlord_US.xml’s function monster_dies(left, top) to determine whether the spawned monster is Ulag, and also for monster_dies(left, top).

image

Contributions from Spiffy coming; Lua related

Spiffy has joined (he emailed me from this blog).  I created a Discord channel that we’ve been using, and also wrote some new user wiki doc in the project’s bitbucket on how to setup the project (build/run), and how to use the git/bicketbucket flow (ie he will work in a separate git branch, then create a bitbucket pull request).

It’s been a while since I did any updates on HeroQuest UE4 (distractions from day job and personal life), but Spiffy has inspired me to do some more work this past week (amidst COVID-19 WFH), and also to help him to ramp up on implementing Lua code for quest-specific game rules/logic.  My recent changes include.  Fix crash when UMD is not plugged in.  Improve Lua support for _on_exit().  And Spiffy will implement more Quest-specific game logic using Lua.

Spiffy

Quest-specific game logic using Lua

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

Preview of HeroQuest UE4 (Windows package)

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

VR drag camera, misc

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.

VR scale to real world objects (HeroQuest)

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):

IMG_20181123_1448324 image IMG_20181123_1452047

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

IMG_20181123_1507131 image image image

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

Fast Forward (Time Warp)

There are many times when

map bounds (wooden exit door)

Expansion maps starting with Kellar

UI tweak atk/def

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

Non-Random Mode Ramblings

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.

« Prev - Next »