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

Archive for the 'Unreal Engine' Category

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’s more of a prototype than a complete game, but enough of it’s working that you can at least get a feel for it.

HeroQuest UE4 package 2019-04-18

The download (Win64.exe) is a self-extracting executable package built for Windows (64-bit).  I can post other platforms if someone requests it.  I’ve also included my modified HeroScribe package (HeroScribePem.exe) (HeroScribePem.jar requires Java) with XML map files (xml sub-folder).

If you have basic programming skills (or know someone) and are motivated to contribute, please contact me.  You don’t necessarily need to know UE4 or C++ (or Blueprints), but you’d need sufficient skill in OO programming (eg Java, C#, Python) (and are motivated to learn).

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.  It’s just a low-effort implementation that re-uses the existing UMG menus.  Later I’ll add something more VR friendly (spatial interactions).  Eg user can point-trigger a 3d icon to select an action.  Eg user can do things like spatially drag-and-drop Hero pieces for move, physically point-trigger on monsters/heroes to select targets, etc.

I’m posting this update because the video shows tangible progress on better VR support.

I also did some non-VR changes including:
* upgrade to 4.21
* multi-move is faster (less delays)
* when nothing is selected, space/enter does Back (faster menu navigation)
* update treasure card mesh to use tex v that’s better for pot of speed (UK png)
* back from atk was broken no UMG focus; fix in HqTurnMenuBp > Turn Menu Camera Enable
* fix action atk enter; HqTurnMenuBp > Key Down Helper > Action Attack Menu needed Return Node is Handled

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.

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…  If Zargon doesn’t have an upcoming turn, then rolling move dice for movement to position Heroes can get tedious (to the point of absurdity).  To solve the problem, we sort of fast forward through Hero moves (when Zargon doesn’t have an upcoming turn or potential event/trap trigger).

For ex, when a room is empty, the player may reposition the heroes before we search for treasure.  Or reposition the heroes before opening a door.  Or before opening a door, we could (roll move, skip turns, repeat) until we roll a 12 (two sixes), so we just say “auto 12”.  Or walking down an empty hallway (no monsters, we already searched for traps).  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.

An additional fast forward idea (I didn’t implement it yet) is:
) FastForwardIsAllowed() and there’s no traps (or unsearched squares) in the way => allow Move warp

image

map bounds (wooden exit door)

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

image

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’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).

image image image

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.

VR UMG menus

Here’s a couple screen shots showing the game menus in VR displayed on an actor (instead of screen space HUD).

I also fixed more corner cases related to Pass through Rock, movement, and UMG menus.

image image

Spell Menus (and more)

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.

Body HUD, misc

Another good week of progress (part-time):
* VR: a little more progress
* Move system: refactor / fix / enhance
* Hero Body HUD

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.

Next »