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

Archive for the 'Unreal Engine' Category

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’s an example of quest text from Quest 1 (from a PDF):

image

To allow custom maps, and to make the design cleaner, quest specific logic should be an extension to HeroScribe XML.  Luckily someone added a simple LuaMachine plugin for UE4 that makes it really easy to do this.  So I started integrating that.

For example, I have HQBase-01-TheTrial_US.xml which has a corresponding HQBase-01-TheTrial_US.lua.  At this point, there are no modifications to the XML file.  When the game opens quest foo.xml, it looks for an optional corresponding foo.lua.  Here is a simplified example:

local HeroScribeQuest = {}

function HeroScribeQuest.special_treasure(id)
    if (id == "LetterF") then
        quest_print("The weapons on this weapons rack are chipped, rusted, and broken.  There is nothing here that the Heroes would want.")
        return true
    end
    print(id)
    return false
end

return HeroScribeQuest

special_treasure() is a callback from UE4, while print() is a call into UE4.  So this demonstrates two-way communication between UE4 and Lua.  If there’s no Lua file, no special_treasure() in the Lua file, or special_treasure() returns false, then the game draws a treasure card.

Typically when special_treasure() returns true, that means it also did something.  Typically that something is to display quest text using quest_print() which displays text using UMG.  And to give the hero an item (or gold).  For our first example, there is no item, so we just call quest_print():

image

special_treasure() takes argument id.  “LetterF” comes from standard HeroScribe XML test.xml.  When the game loads the XML, if it finds a letter in a room, it associates the room with that letter.  Then when a hero searches that room for treasure, the game passes that letter (eg “LetterF”) to special_treasure().  For testing, I used HeroScribe (Pem’s Fork) to add the letter F to the starting room:

image

This was all made possible (and easy) using the LuaMachine UE4 plugin.

https://www.unrealengine.com/marketplace/en-US/slug/luamachine
> Contrary to the other Unreal Engine 4 Lua plugins, this one does not try to expose the Unreal Engine 4 api, but completely hides it exposing to the user/scripter only the features the developer decided to include (via Blueprints or C++).
> Currently Windows 64bit, Mac, Linux 64bit (both Runtime and Editor) , Android, iOS (Runtime only) are supported.
> Scripts can be cooked in the build or loaded at runtime from the filesystem

As described in the above quote, LuaMachine is exactly what I was looking for!

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.

Next »