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

Epic Campaign Reviewed

Another post about design (rather than code).

I did more research on the expansion order.  Let’s start with the obvious:

1) Basic: Original Quests, Kellar’s Keep, Witchlord
2) European: Against the Ogre Horde, Wizards of Morcar
3) North American (and Advanced): Dark Company (EU Advanced Quest), The Mage of the Mirror (Elf Quest), The Frozen Horror (Barbarian Quest)

The order is obvious within “1” and “2”.  Within “3”, the order is less obvious.  According to boardgamegeek.com, the quests were released Mirror then Frozen, but most people say Frozen is more difficult.  As for Dark Company, some say to put it before Mirror/Frozen, some say to put it after.  It’s hard to tell just by glancing at the quests, so I’ll have to do some mathematical analysis and/or play testing.

Another nuance is that the European version of the game has easier monster stats, eg every basic monster has only 1 body point.  So using NA monster stats in the EU expansions (including Dark Company) makes them more difficult.  Even with that caveat, Ogre and Morcar are less difficult than Mirror and Frozen.  For Dark Company, north-american.yeoldeinn.com links to a pseudo-official localized version with NA style monster stats for Dark Company’s unique monsters (Dark Warriors and Doomguard).

Thus far I’m still leaning towards the following order.  Dark Company is a big challenge with a big reward at the end.  Mirror you get Elf spells.  Frozen you get mercenaries.  So I’m tentatively sticking with that order, unless I see a reason to change it.

When everything else is done, I plan to playtest and balance the maps to make sure the difficulty increases gradually and hero advancement happens gradually.  The game will increase in difficulty faster than the heroes (non-literally) level up, plus it will become more complex as more options (items spells etc) are added.  And I’m hoping to make the game focus more on strategy/tactics within a particular quest (ie deemphasize cross-quest item hording).  I’m still going for authenticity and nostalgia, but the game needs tweaks, balance, and play testing.  This was true of the original game, and it’s especially true for merging NA and EU versions into a well structured video game epic campaign mode.

So here’s the order again:

1) Original Quests: 14 quests
2) Kellar’s Keep: 10 quests
3) Return of the Witch Lord: 10 quests
4) Against the Ogre Horde: 7 quests
5) Wizards of Morcar: 5 quests
6) Dark Company: one long 13-stage quest (4 boards)
7) The Mage of the Mirror (Elf Quests): 10 quests (3 solo, 5 group, one double)
8) The Frozen Horror (Barbarian Quests): 10 quests (3 solo, 5 group, one double)

At this point, I’m not planning to include any unofficial fan quests or semi-official quests from magazine etc in the primary Epic Campaign mode.  Although the game will support custom quests using the standard HeroScribe XML format.  And I may even add a random campaign mode (that’s separate from the standard epic campaign).  So far I am really just focusing on developing a polished version of the original 14 quests, because the expansions don’t just add new maps and art assets – they also add new content that requires me to implement (and debug) more code.  My main focus is on implementing the game (ie programming), but I occasionally take breaks to consider design issues (as seen in this post).

It’s turning out to be more work than I’d originally expected for a part-time hobby project, but I love HeroQuest and it’s a unique contribution to the HeroQuest community (fandom) (niche).  Plus the work is giving me great experience using Unreal Engine 4 (UE4) and with detailed game design issues like balancing and player experience (UI/UX).

To close, how many quests is the epic campaign in total?  If we count Dark Company as 4 quests, then it’s 14+10+10+7+5+4+10+10 = 70 quests.

The epic campaign is going to be my primary long-term focus.  Beyond that, I may also add a custom quest mode and a random quest campaign.

Image result for heroquest Image result for heroquest kellar's keep Image result for heroquest return of the withlord

Image result for heroquest the ogre horde Image result for heroquest wizard of morcar Image result for heroquest advanced quest dark company

Image result for heroquest mage of the mirror Image result for heroquest frozen horror

Treasure Card Code & UI

I continued to work on the treasure card code and the related user interface (UMG) for items.  I also fixed some corner cases that I found during testing, and I implemented other details related treasure and items.  For UI, the Character (items) screen is revamped.

For treasure card code…  The original game has 24 treasure cards – 11 are unique.  I added Potion of Speed (from EU version), so it’s 25 treasure cards, 12 unique.  Each of the 12 unique treasure cards requires code to be implemented.  There’s 2 hazards and 4 gold cards, so there’s really only 8 unique cards (in terms code behavior).  Gold and hazards are simple.  I’m saving the wandering monster card for last.

I implemented five potions – each potion has a different behavior.  Potion of Strength and Heroic Brew are used before attacking.  Potion of Strength just adds two combat dice to your attack.  Heroic Brew allows two attacks (instead of one).  Potion of speed is used before moving – to double your movement dice (eg 4 instead of 2).  Potion of Defense: when a monster is attacking a hero, if the monster rolls a skull and the hero has a Potion of Defense, then prompt the Hero to use it (or not).  Potion of Healing is similar – when a hero dies (eg from a monster attack or hazard), prompt the hero to use Potion of Healing (or not).

The mechanics (and UI) for spell cards will be similar.  There is also more to do for items.  For now, here’s screen shots and a video:

image image

HeroQuest game balancing notes

Most of my HeroQuest Unreal Engine posts focus on code (and UE4), but this one focuses on game design.

I had a great holiday break and I was able to playtest HeroQuest (physical version) and review some of the game balancing.  I still plan to make the video game version focus on the authenticity of nostalgia.  However, there are some balance issues, design exploits, and other design improvements I plan to use for the video game version.  The tweaks (and interpretations) do not stray far from the original – even the original is open to interpretation because some of the rules are ambiguous and there’s two versions of the game – European and American (and some rules are clarified in expansions).  I also suggest using theses fixes (improvements) when playing the physical board game.

Problems:

1) What order to play the expansions?

2) Treasure Grind.  NA end of each quest you can search each room four times and get potions that you save between quests.  You quickly become absurdly OP with infinite potions of healing.  Treasure Grind is also the most boring part of the game if you do it.  You play an actual quest 1+ hours, then you spend another 1+ hours doing treasure grind which is boring and lame and OP.

3) Too many one-time use items, and not enough permanent leveling up.  Especially in the basic expansions (Kellar’s Keep + With Lord).  Especially if you keep treasure card potions between quests.  This makes the game put too much emphasis on what you did in previous questions.

4) Basic Expansions (Kellar’s Keep + With Lord) too easy

5) Door Camping exploit.  Heroes can stand by door entrance with 6 defense hero using a crossbow.  If Zargon attacks through the door, he only gets max two attacks per turn max.  But heroes can attack diagonally through the door with longswords (and Wizard’s Staff).  If heroes figure out this exploit, it completely breaks the game.

6) Line of sight rules are vague and confusing.

7) Some of the rules can be interpretted in more than one way

8) Game slows down if heroes try to optimize play and literally roll dice for every move, and search every room no matter what

9) Wizard spells add a lot of fun to the game but he has so few that it encourages hording of spells.  Elf only gets 3 spells typically Earth.

10) Advanced Expansions (Elf + Barb) too hard (unless you horded one-time use items then it’s too easy)

11) Each quest should be balanced as its own game that assumes you’re at a certain level.  Then balance each quest to be a challenge based on that assumption, which overall gradually increasing difficulty (and complexity).  Again, we can keep some one-time use items for emergencies or to get through difficult quests.  But these should be rare.  Instead, we want heroes to "level up" gradually eg with artifacts that you can use once per quest.

12) The game only has one difficulty setting.

13) Chaos Spellcasters are rare and fun.  Optimized hero attacks will kill Zargon spellcasters first turn which ruins the fun.

14) Expansion quests add stuff…  What do you do with the new stuff when you move on to the next expansion?

Solutions:

1) Elf and Barb expansions are definitely meant to be played last after your heroes are already maxed out.  So a basic North American quest order is original, kellar’s keep, witchlord, elf, barbarian.  If you want to include European expansions, then do: original, kellar’s keep, witchlord, ogre horde, wizards of morcar, advanced heroquest’s dark company, elf, barbarian.  In summary I call this original, then basic expansions (kellar’s + witchlord), then European (ogre + morcar + dark), then advanced expansions (elf + barb).  References:

https://en.wikipedia.org/wiki/HeroQuest#History : release dates suggest: Basic Game (EU 1989), Kellar + Witch Lord (EU 1989), Ogre (EU 1990), Morcar (EU 1991), Elf + Barb (NA 1992)

http://aginsinn.yeoldeinn.com/faq.html : storyline suggests: Basic Game, Kellar’s Keep, Witch Lord, Ogre Horde, Morcar

https://boardgamegeek.com/thread/530070/which-order-should-we-play-expansions : random user claims dark company is harder

2 & 3 & 4) The (original, kellar’s keep, witchlord) are too easy and (elf, barb) are too hard.  Make everything in the armory cost double gold, so heroes "level up" slower.  Treasure you can only search each room once (not once per hero).  Treasure card potions can not be saved between quests because they are overpowered (OP).  I think these treasure rules are the most reasonable way to interpret the EU rulebook – I’d actually call the NA version a "bug".  The EU character sheet does not even have a space to write ”Potions & Other Items” – this was added to NA version.

To allow the heroes to "level up" in basic expansions, make artifacts reusable as spells.  Most you’d give to the Wizard.  “Spell” means it counts as an action, and Wizard with wand of magic can use two spells.  Kellar’s Keep Q3 you only get one magic dagger.  Q9 magic daggers count as a second scroll, so you end up with 4 random spell scrolls in Kellar’s Keep (make them unique) (use 8-sided die or randomly pick one of 8 monster cards to randomize which of the 8 scrolls you get each time).  This gives the heroes incremental permanent leveling up (instead of hording one-time use items).  Sacred water (Witchlord Q2) also counts as a spell (use once per quest) (in EU it’s treasure card).

Even Elixir of Life and Ring of Return are reusable once per quest.  This may seem OP, but it’s much less OP than hording potions of healing.  Not keeping treasure card potions (eg potion of healing) between quests also makes the expansion potions less overpriced.  Otherwise you end up hording a million potions of healing and if you optimize it then you’ll save them all for Elf + Barb expansions, so you’ll end up with like 40+ potions of healing, which turns the Elf + Barb expansions from too hard to absurdly easy.  Also, when you can’t horde treasure potions, 500 gold for a potion of restoration becomes reasonable.

4) Even after these changes, Kellar’s Keep and Witchlord are too easy, assuming you started with heroes who are already maxed out from the first quest book.  You can live with it and just say okay these are easier quests that gives players a chance to increase their skill.  Or you could manually add monsters to each room.

5) To solve door camping, don’t allow spells and ranged attacks or diagonal attacks through a door into a room.  When a hero enters a room, a one-way Zargon force field blocks the hero from leaving through the door until all monsters in the room are gone (veil of mist or dust of disappearance can allow a hero to pass through the force field).  This forces heroes to enter rooms.  Zargon should surround the door but not attack heroes through the door in most cases.  It’s always the heroes responsibility to progress the quest.  It’s not Zargon’s responsibility to charge out after the heroes.  If this causes a stalemate then you could make a rule like every 10 turns a random hero loses a body point, but this shouldn’t be necessary as long as heroes understand their goal is to progress, and Zargon is really just the non-competitive AI (computer).

6) For hallways, use line of sight.  For rooms, if you’re in a room you can "see" everything in the room (don’t use line of sight).

7) I won’t get into all of these since some of them are quest-specific.  But one example that isn’t is the Battle Axe.  Heroes can have two weapons (or three), but Battle Axe means no shield.  By the end of the original 14 quests, maxed out non-Wizard heroes will have crossbow + (broadsword or battle axe).  Actually, one hero will have spirit blade instead of a broadsword.  One hero will have Orc’s Bane, which is a slight bonus vs. Orcs (better than crossbow or broadsword but not as good as a Battle Axe).  If you give one Hero Battle Axe + Borin’s Armor, then all three heroes can have 5 defense.  But there’s other combinations.  Plate Mail is also an option but be careful because rolling a 1 sucks unless you start at the door entrance.

7) Witch Lord Q2, it has something lame happen which we ignore (potentially lose Orc’s Bane + Borin’s Armor forever is lame).

8) To make quests go faster, we allow time warping assuming that everywhere was searched for traps and that there’s nothing special.  Usually this makes the game faster, more fun, and streamlined.  The rare time it’s an issue is when you have to tell heroes "no you can’t warp" in which case they know something special is coming which can ruin the surprise.  Another concern is situations like Witch Lord Q2 where the revolving door is meant to separate the heroes, but time warping makes them not get separated.  This may be less of an issue for video game.

8) Missing special treasure is lame (especially for physical game).  To optimize this, a good player will do every room.  But then you never have the option to complete a quest early by going straight to the goal.  To simplify this, we just say you can’t end the quest until you’ve found all special treasure.  So when you try to leave, Zargon will tell you you can’t until you go back and get all special treasure.  Like "2", this also helps make each quest more of a game in itself rather than being based on how well you optimized previous quest results.

9 & 10) This is already addressed by previous items.  But to take it a step further…  When you start the Elf expansion, give all 12 original spells to the Wizard, and give all 8 Elf spells to the Elf.  This is more fun.  I don’t think it’s OP because the heroes need a boost.  It’s also a way to make the game gradually increase complexity and challenge.  More thoughts see “14”.

11) I came up with these when playtesting the physical board game.  For the video game release, I plan to do playtesting of each Quest to balance it even more.  Heroes gradually "level up".  Quests get harder at a slightly faster rate than the heroes level up, and complexity increases as the player gains skill.  So we’ll have two copies of each map.  The original and the rebalanced version.  The original is technically the NA quest maps (note EU quest maps for original + Kellar + With Lord are technically different).  For the video game release, the player can choose "original" (easy) maps if he/she really wants to play them for the nostalgia, but the default will be the "rebalanced" maps.  The rebalanced maps will be 90-99% the same.  The rebalanced quest maps will just add additional monsters (and maybe fix some quest-specific bugs).

12) The rebalanced quest maps won’t be insanely difficult.  So the video game release will have an option to play an advanced difficult mode.  I’ll revisit this later.  My current idea is to increase monster stats (Attack, Defense, Body, Mind, Move).  Even the highest difficulty will still be beatable (in fact I plan to play through each quest on the highest difficulty with no cheats!).  Monster difficulty stat bonuses will get bigger as the quests advance.

13) You can’t attack a spellcaster until there are no other monsters in the room (or if the monster is in the hallway then its line of sight)

14a) New Treasure Cards: only use for that quest book?

14b) Wizards of Morcar: 9 spells:

http://english.yeoldeinn.com/wizards-of-morcar.php
=> spells detection to Elf: treasure horde too dangerous for wizard, other two ok for Elf
=> spells protection to Wiz: invisibility helps wiz stray alive, wall of stone too, dispell instead of atk
=> spells darkness to Wiz: all three use instead of atk

Kellar’s Keep artifacts:
* Q2: magical throwing dagger x2… instead make it dagger x1 and scroll x1
* Q4: fire ring… instead ring only blocks one spell per quest
* Q6: magical throwing dagger x1, random spell scroll x3… instead do scroll x1, scroll x2
* Q7: elixir of life
=> total: daggers x3, scrolls x3, fire ring x1, elixir x1…  so instead of (daggers x3, scrolls x3), we can do (daggers x1, scrolls x4) which is 4/8 unique randomly chosen
=> basic exp artifacts count as wizard spells (everything except elixir x1)

Witch Lord
* Q1: dust of disappearance x2
* Q2: sacred water x1
* Q3: magic dagger x2
* Q4: ball of flame x1, fire of wrath x1
* Q6: lose all gold (???)
* Q7: rabit boots x1, pass through rock x1
* Q8: anti-poison quill x2, heal body x1, courage x1
* Q9: armband of healing x1, daggers x2,
=> wizard spells: ball x1, wrath x1, rock x1, heal x1, courage x1, sacred water x1
=> anyone: armband x1, boots x1, dust (reusable) x2, quill (reusable) x2
=> magic daggers x4: too many + OP => just ignore them

After Kellar + With Lord, Wizard has scrolls x9, dagger x1, fire ring x1, sacred water x1 => x12 total… which is perfectly fine bc that’s x21 spells and the Elf will get x8
We also have armband x1, boots x1, dust x2, quill x2, which can go to anyone, they aren’t wizard spells, they don’t count as an action
Wizards of Morcar has another x9 spells, Detection goes to Elf, so wiz x27, elf x11…  Or if we let Elf keep one elemental (eg Earth) then its Wiz x24, Elf x14
There may be additional spells (or spell-artifacts) in other expansions, so I can revisit these details

When the video game development is further along, I will do extensive play-testing to balance the quests.

I also may end up adding spells earlier (gradually) to gradually increase the fun.  We want the quests to gradually introduce new items to the heroes.  This makes the epic questing experience gradually become harder (and gradually introduce more options / more complexity).

The early quests should be easy even if the player does newbie mistakes like separating the heroes, but by the time you get to the later expansions, you’ll lose some quests unless you play better (even on the default difficulty).  Of course players can always restart the quest until they learn to play better.

Treasure Rules

The American rulebook states a room may be searched by all 4 Heroes:

image

The European rulebook does not state this, but it’s reasonable to infer that you can only search a room for treasure once.  The idea that each hero would find different treasure searching the same room is wonky.  I suspect that the European version intended this, then when it was ported to the American version they saw the rule was unclear, they saw the rule was unclear, they may have thought it meant infinite treasure searches, then they changed it without realizing the consequences.

Allowing all four heroes to search every room has some bad consequences:

1) If the players want to optimize their results, they’ll wait until the end of the quest and then do a painful treasure card grind that takes longer than the actual quest.  Searching each room for treasure four times can be slow due to wandering monsters.

2) More treasure cards means you get gold faster, which means characters max out their armory purchases too fast.  This makes the game less fun because part of the fun is “leveling up” the heroes.

3) More treasure cards means you end up with too many treasure potions.  It’s tedious writing these on the character sheet.  It makes the heroes invincible because you always have a bunch of healing potions in case of death.

Despite the flaws of the original HeroQuest, my HeroQuest simulator is all about nostalgia.  For that reason, I stick to the original rules as much as possible.  However, interpretation is required because there’s two versions of the official rules (American and European) (plus expansions clarify rules) (plus non-English versions may have slight rule variations and/or rules wording), and because some rules are not clear.  There’s also cases where I think of a rule as a “bug” (which is why I added the anti door camping rule).  When in doubt, I strive to stay faithful to the source material but lean towards interpreting the rules to improve the overall game experience.  For that reason, I’m going with (one treasure search per room).

Beyond this, I may add some conservative tweaks for the purpose of improving the overall experience.  Some ideas:

1) Start of Zargon’s turn any room with no monsters that hasn’t been searched for treasure spawns a treasure goblin.  This avoids the end of quest treasure grind and adds a little difficulty.

2) Basic expansion artifacts can be reused once per quest.  This gives heroes more opportunity to permanently “level up” instead of hording one-time-use potions and items.

3) When entering the Elf expansion, the Elf gets all 8 spell cards and the Wizard gets all 12 elemental spell cards.  The advanced expansions are hard (especially with less potions).  Plus this avoids the Elf spells not getting used – it’s no fun making the player pick 3 out of 8 elf spells and have to give up the elemental (typically Earth) spells.  Access to new stuff is a big part of what makes the expansions fun.

But I’ll come back to these ideas later after the implementation is further along and I’ve done more play testing.

Treasure Cards

In HeroQuest, the Hero’s turn is (Move then Action) or (Action then Move).  The six actions are – attack, spell, search traps, search doors, search treasure, disarm trap.  The latest I’m working on is search for treasure.  You can only search rooms for treasure (no corridors).  When you search a room for treasure, you either get special treasure or a random treasure card.  I implemented support for drawing a card from a treasure card deck.

OpenGL vs. UE4

My first thought with the deck was that if this were OpenGL then I might draw the entire deck in a single draw call.  Each card is only 24 verts (6 sides * 4 per verts side), so 24 cards is 24*24 = 576 verts.  I could use a single texture atlas for the draw call, and each card’s vert’s texture coordinates define which card it is.  I used SpriteSheetPacker to generate the texture atlas png (and uv txt) (my treasure card scans can be crammed in one or two 2048×2048 textures).

Each card needs independent transformations (just simple translation and rotation), so I could do that similar to skeletal animation see ( https://www.opengl.org/wiki/Skeletal_Animation ).  My GLSL VS would just have (uniform mat4 Bone[24];) – one mat4 for each of 24 cards.  Each vert would have a boneIdx param that specifies which mat4 to use.

So to do this in UE4, I implemented a material that did rotation and translation.  However, I ran into a problem – it broke up the lighting.  I thought the issue might be that the normals so I tried doing VertexNormalWS > RotateAboutWorldAxis_cheap > output Normal to match what I output for Absolute World Position > RotateAboutWorldAxis_cheap > World Position Offset.  I read that inverse transpose of the model view matrix is not required for basic rotation, but I tried that anyway by implementing my own matrix math for rotations in material nodes (blueprints).

I did rotation experiments with a white sphere and it didn’t seem to work as I expected.  I may come back to this idea later, but I realized that for a reasonable authentic implementation of the HeroQuest, I don’t really need to render 24 cards with independent transformations.  So I moved on to a simpler implementation (at least for the short-term).

UE4 Implementation

Instead of 24 actors I have three actors – deck, card, and discard pile. I created a Blueprint actor "deckBp" which can resize (ie shrink when the player draws a card). In the level editor, I placed a deckBp for treasure deck main and for discard. The level Blueprint’s BeginPlay resizes these to 24 cards and 0 cards. My C++ code can reference treasure main deck and discard deck (pile) via the level Blueprint.

When the player draws a card, it shrinks the deck by one card then does a simple transformation lerp’ed over time in Tick(). Placing the treasure card draw destination relative to the camera doesn’t make sense because the player can move the camera, so the destination is to rotate the card 180 degrees and place it above the current turn player. The card sits there (so the player can read it) until the player clicks the card (or types space / enter / gamepad-A), then it lerp-translates to the discard pile (and the discard pile grows).  Here’s a video of it in action:

Gamepad Controls

I implemented gamepad controls which I tested on Windows desktop with an Xbox 360 Controller (USB).  Using this same control system, it’s also possible to control the game entirely with a keyboard (though I think keyboard + mouse is better).  This is in addition to the touch screen only interface (which I’m testing on an Android tablet).

The UMG menu uses D-Pad, A for select, B for back (also keyboard arrow keys, Enter / Space, Esc / Backspace).  The game view uses the following (each also has corresponding keyboard shortcuts).  Left Stick free camera (WASD), Left Stick button toggle view (V).  Right Stick rotate/zoom, Right Stick button toggle zoom vs. tilt (QE rotate, home/end zoom, PgUp/PgDn tilt).  D-Pad Move or Attack adjacent (arrow keys).  LT toggles card zoom (C).  RT toggles combobox (B).  LL RR cycles Attack targets (tab, shift+tab), A selects target (enter, space).  B for back (Esc).  Mouse wheel zoom.  Mouse or Touch can click UMG or highlight actors (to select move or action target).

Other controls I plan to add later…  More finger touch screen controls such as pinch zoom, two finger rotate, tilt, pan.  Fluid mouse control (maybe right-click) for rotate/tilt.  In the long-term I plan to implement a VR interface.

Below is a video where I showcase using an XBox 360 controller to control the game.  Most of the functionality is the same as (keyboard + mouse) but with gamepad controls.

Some changes that stand out…  Navigate UMG menus with D-Pad.  Character menu is updated (also bigger UMG widgets for touch screen) (work in progress).  In addition to using D-Pad to select orthogonal move/action, you can also select any move/action with (left bumper, right bumper) then A.

Image result for xbox 360 controllerButton layout of a wireless Xbox 360 controller

Search for Doors (dynamic textures)

Motivation

In HeroQuest, a hero can do one action per turn (move then action or action then move).  The choices for an action are – attack, spell, search for traps, search for secret doors, search for treasure, and disarm trap.  Three of the six actions are “search”.  If you’re in a room, search checks the current room.  If you’re in a corridor, search checks corridor line of sight.  This is similar to visibility in terms of ranged attacks and spells with the anti-door camping rule ( link ).  One key difference is that you can’t search when a monster is visible.

image

Search treasure only applies to rooms (there’s no treasure in corridors), and each hero can only search a room for treasure one time.  So one quirk of HeroQuest is that the players have to keep track of which heroes searched which rooms.  It also makes sense to remember which areas you searched for traps and secret doors – because otherwise you may end up forgetting to search an area or you may end up searching the same area repeatedly.

For the video game version of HeroQuest, it’s useful to allow the player to see where they’ve searched. 

Results

I decided to convey this information using a dynamic texture, so the implementation is similar to what I did for fog of war (see my previous post).

For my board material’s pixels, we start from the board texture, multiply by fog of war, then add search highlighting.

I added a UMG combobox in the bottom-right corner of the screen.  This let’s you select which search type you want highlighted on the board – none, trap, door, or treasure.

In the screen shots below, you can see the first room’s squares highlight in cyan when “door” is selected.  You can also see the secret doors revealed (I added lots of secret doors for testing).

I tested it on Windows desktop and on an Android tablet (Fire HD 6) with a relatively small screen.  The UMG combobox is a reasonable size even on tiny Android tablet.

No videos this post – just screen shots:

image image image

image image image

Fog of War

Motivation

In previous posts I’ve described my guiding design principle as “the nostalgia of authenticity”.  The physical board game does not visually represent fog of war, but I decided fog of war is a good idea (and also good experience to implement it).  Fog of war is inline with the general idea of making the game very similar to the physical board game, but it’s an enhancement that make sense for a video game version.  I think of it as part of the user interface – a way of communicating information about the game state to the player.

Unlike other games that have Fog of War (such as classic RTS Warcraft/StarCraft), HeroQuest fog of war only fogs out unvisited board squares on the actual board.  There’s no need to fog out miniatures (furniture, monsters/heroes), because when a square or miniature is revealed, it’s permanently revealed (until we get to the next quest).

Idea – Draw Batching

My first idea to try was to just use actor boxes like we do for highlighting movement and action squares.  Here’s a screen shot of my low effort gray-out-with-actors implementation.

image

Unfortunately it dropped the FPS to a crawl, which is kind of sad for drawing less than 26×19 simple one-color boxes.  I learned that apparently UE4 (as of 4.12) does not do automatic draw call batching – ie for each material, combine vertices from different actors into a single vertex buffer so that they can be drawn in a single draw call.  One issue with implementing automatic draw call batching is that when you aggregate vertex buffers, is that you have to consider culling because you may not want to just blindly put all vertices from the same material in the same vertex buffer – because the vertex locations for a particular material are not necessarily close to each other in world space.

UE4 has an instancing system, but apparently this doesn’t actually reduce draw calls – it just sorts the draw calls so that actors with the same material are drawn in order.  See ( https://answers.unrealengine.com/questions/127435/using-instanced-meshes-doesnt-reduce-draw-calls.html ).

Unity can do draw call batching ( https://docs.unity3d.com/Manual/DrawCallBatching.html ) with some caveats.  In addition to culling, transparency must be considered.

It would be nice to have the option to give each actor a group label for automatic draw call batching – because for my particular use case, putting my fog of war actors into a single vertex buffer makes sense.  Culling is unnecessary for 26×19 simple box actors, and there’s no transparency.  So dynamically generating a fog of war vertex buffer in C++ code was an option.

Idea – Dynamic Texture

However, once I started thinking about optimization, I realized a dynamic texture is also a good option.  One idea was to just dynamically edit the 2048×2048 board texture.  However, this apparently does not work with mip maps as of UE4 version 4.12.  It’s possible that I’m doing it wrong, but when I tried editing a dynamic texture in C++ code, it crashed when the texture has mip maps, and I read comments (not official doc) saying it’s not supported.

So I decided to instead let the 2048×2048 texture use mip maps, and I’ll create a second texture that’s 32×32 without mip maps.  Each pixel in the 26×19 subset of the texture is either fogged out or not.  A simple material can blend the two textures.

I considered how to do this using math in the material shader to convert the board static mesh’s input UV coordinates to map from the 2048×2048 texture to the 32×32 texture.  However, I later decided to instead just have two sets of texture coordinates in my board mesh – one for the 2048×2048 texture, and one for the 32×32 texture.

Creating a second UV channel in Maya

I had created my board.obj file by hand editing the text file.  However, Wavefront OBJ does not appear to support two UV channels per vertex.  So I figured out how to add a second UV Channel in Maya.  To do it in Maya, I did the following.

Import my board.obj.  Open a second window with UV –> UV Editor.  Put my main editor window and UV Editor window side by side.

Set the main editor to let me select individual vertices with main editor toolbar -> Select By Component Type, Select parm points components.  In the UV Editor, I used the Tweak UI Tool.

I didn’t want to edit my existing UV set.  Rather I wanted to create a second one.  So I did UV Editor –> Polygons –> Copy UVs to UV Set –> Copy into New UV Set.  Then UV Set –> select my second UV set.

Next I used my side-by-side window setup to manually select vertices in the main editor window, and then enter values in the UV Editor window for those vertices.  In the following screenshot, I entered values for the selected vertices.

image

When I did File –> Save Scene As –> Maya ASCII, I was able to see the UV files in my board.ma text file.  I was also able to see the values in my FBX file when I exported FBX as a text file.  Both files were more complex than my OBJ text file.

In UE4, I had to do a bit of tweaking.  UE4 board mesh settings.  Import rotation 90, 180, 180.  Destination Lightmap Index = 2, Lightmap Coordinate Index = 2, this is important since my mesh has two UV channels (plus the lightmap generated by UE4).  After doing some math and then some testing to tweak the values, I came up with a UV range of (-0.009, 1.007) to (0.822, 0.342).

Creating a third UV channel in Maya for the lightmap

I ended up getting an error related to the autogenerated lightmaps (in 4.12) – “object has wrapping uvs”.  So I ended up making a third UV channel in Maya.  For this third UV Channel, I did Polygons > Unfold, Layout > Prescale to Object, Spacing Presets 2048.

Back in UE4, just doing material editor –> Asset –> Reimport, was not enough (even if I unchecked Generate Lightmap UVs).  So I had to re-import my FBX file from UE4 Content, and uncheck Generate Lightmap UVs.  After import, I set Lightmap Coordinate Index = 2.

Result

Here’s the result using a test/debug 32×32 texture blended with the board:

image image image

Here’s fog of war with a subtle gray fog:

image image

Here’s fog of war with an extreme black fog with specular = 0:

image

Here’s full black fog with specular defaults to 0.5:

image

I’m leaning towards a more subtle gray fog as the default – I’m going for a good balance between making it look closer to the physical board game yet also effectively communicating the information (which rooms and corridor squares have been seen).

Another balance is between effectively communicating the information without making it visually loud in a way that strays (without good reason) from the goal of making it look-and-feel more like the physical board game.  Later I may add a non-default option for pitch black fog (and/or a sliding scale for varying degrees of fog of war darkness).

Here’s a video showing the effect:

Pathfinding with A* (A Star)

Labor Day weekend gave me an opportunity to implement pathfinding.  Here’s notes on some of what I read.  BFS (breadth first search) explores equally in all directions.  Dijkstra favors lower cost paths.  A* is modified Dijkstra optimized for a single dst (uses heuristic to search towards dst).  A* is the standard pathfinding for games (I also used it in college game projects ~12-14 years ago), so it’s easy to find pseudocode, articles, tutorials, and videos about it.  A* can be further optimized a number of ways – use more efficient data structures, bidirectionoal search, jump point search can optimize uniform cost grids (like HeroQuest).

My HeroQuest map is an array of 26×19 square spaces, but pathfinding works on nodes in a graph.  So before I implemented pathfinding, I added C++ code to generate the graph.  Each space has a list of 0 to 4 neighbor nodes that are valid moves.  The graph is for monster AI, so a hero is a blocker.  When a space is revealed for the first time, we generate neighbors for that space.  When a hero moves a space, we update neighbor list for src node, dst node, src’s neighbors, and dst’s neighbors.  Once I got that working, I moved on to actual pathfinding.

To keep things simple, I just implemented A*.  Two references I used were Vincent Cogne’s 2010 blog post ( http://bit.ly/2c6vTnF ) and wikipedia pseudocode ( http://bit.ly/2cimKrr ).

A* uses an open list and a closed list (open list means we will visit it later, closed list means we already visited it).  When a node is visited, its neighbors are added to the open list (unless it’s already in the open list or closed list).  Each node has an F, G, and H value.  The way A* searches towards the goal is that each iteration, we visit the node in the open list with the lowest F value.  F = G + H.  G is the lowest cost path we’ve found so far to the node.  When we visit a node, we update it’s G value and the parent node used to get that G value (unless the node already has a lower G value using a different parent) (parent node aka “came from” node).  H is a heuristic function to estimate the remaining cost to the goal.  For HeroQuest, I used the manhattan distance as my heuristic.  The heuristic function needs to be equal to or less than the actual cost (HeroQuest only allows orthogonal movement).

The following is a simple example that I used as a test case.  The numbers are just x, y, and the order that A* visited each node (in terms of the current node).  Overall it was pretty straightforward.

image

In the above example, the Orc searches for the hero with the lowest Body (eg Wizard), then he runs A* towards the wizard.  However, the Wizard is actually a blocking node, so A* never visits the Wizard’s node.  So we end our search when when the Orc is in range to attack the Wizard (ie the Oric is orthogonally adjacent to the Wizard without a wall blocking his attack).

Here’s a screen shot:

image

And here’s an example where no path was found:

image

Aside – I added the “Back” button to the UI as part of an effort to enable the interface to work without a keyboard (eg Android tablet mode) (I also enabled finger tapping to move or attack eg on an Android tablet).

Pathfinding is a fundamental building block for a HeroQuest Zargon AI that will be required to enable a single-player campaign mode.

I’ll close with a video that shows some examples of monster pathfinding to reach the Wizard:

Update: here’s a photo of pathfinding on my Android (technically Kindle Fire) tablet

IMG_20160906_2144484

Trying Out HTML5

I gave “File -> Package Project –> HTML5” a quick try with Unreal Engine.  This was a bit deja vu for me…  Because for one of my previous hobby projects I setup cross-platform (C++, SDL2, GLES2) on (Windows, OS X, Linux, Android, iOS, Emscripten) more “from scratch”…  And Unreal Engine also uses Emscripten for its HTML5 support.  I almost feel like I’m “cheating” letting Unreal Engine do most of the work for me, but the efficiency is good – because for this project I’m focused on building a game (rather than a game engine or graphics demos).  Plus my background with lower layers (GPU graphics, DirectX/OpenGL, cross-platform C++) makes me feel like I have a better idea of what Unreal Engine is doing “under the hood”.

I only had to fix one tiny error (replace std::abs() with FMath::Abs()) for the build to work on HTML5 (in addition to Windows + Android).  After building, I just ran HTML5LaunchHelper.exe, then opened a Chrome web browser pointing to ( http://localhost:8000//HeroQuest-HTML5-Shipping.html ).  UMG is working, and game logic appears to work (eg Move with arrow keys, End Turn)…  But the 3D actors are not displayed.  It’s not high on my priority list, but I’ll come back to HTML5 support later.

image image

« Previous PageNext Page »

Check out best marijuana drug testing website.