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

Archive for June, 2016 (2016/06)

Android Support

I packaged my game for Android.  Overall it was mostly painless – especially since I already had some experience with Android on my cross-platform (C++ GLES2 SDL2 CMake) project (in which I had to do everything “from scratch”).  UE4 did most of the work for me, but I still did run into a few Android-specific issues that I had to debug.

I followed the UE4 Android Quick Start ( https://docs.unrealengine.com/latest/INT/Platforms/Android/GettingStarted/index.html ).  My BlackBerry PRIV wasn’t getting recognized over (adb devices) so I focused on getting it to run on my Kindle Fire.  The Kindle Fire is insanely cheap (only $50) and it’s a good low-end GLES2 base Android (technically Fire OS) device to test for compatibility.

I had to package my XML files as part of the .pak file – otherwise even my Windows package would crash.  Instead of StaticLoadObject() I used ConstructorHelpers::FObjectFinder() – I didn’t verify it but I think this was required to mark the referenced uasset as used so that it will be included in the package.  I fixed a few C++ compiler errors that I got with the Android NDK compiler (that I hadn’t got with Visual Studio 2015).  I updated the splash screen.  I’m able to see my UE_LOG() messages over USB with (adb logcat) or (adb logcat -s UE4 -s Debug).

The final issue I ran into was that one of my textures was too big.  I posted a question late at night when I ran into the issue, and then the next night after work I figured it out and answered my own question ( https://answers.unrealengine.com/questions/443479/android-process-has-died.html ).  Most GLES2 devices (including my Kindle Fire) have a max texture size of 2048×2048, so I had to resize my game’s board texture size to 2048×1642.  Unfortunately, (adb logcat -s UE4 -s Debug) didn’t print any helpful error messages about this.  libEGL gave a message (E/libEGL (11423): called unimplemented OpenGL ES API), and I guessed the large texture was a likely reason.

I didn’t implement tablet-specific controls yet, but I did try connecting a bluetooth keyboard.  The keyboard works just like it does on Windows desktop except that for some reason the Esc key doesn’t work (weird!).  Tablet controls are of course on my TODO list.

I’m glad I tried this now rather than later because when new Android-specific errors arise, then it will be easier to debug.  I’ll close with some photos of the game running on my Kindle Fire:

IMG_20160630_0100283 IMG_20160630_0100570 IMG_20160630_0101010 IMG_20160630_0101172

Is Orc’s Bane Useful?

Interpreting Source Material
When porting content from one media to another (such as book/comic to movie) (or doing a remake), the source material gives a lot of guidance, but there are still plenty of decisions to make.  With HeroQuest, I’m leaning heavily towards making it authentic.  But it is a video game, and I’ve decided to have the program do rules and a campaign and AI (unlike the Tabletop Simulator version) – which means more design decisions to make.  With HeroQuest in particular (unlike other board games), there are plenty of holes in the rules.  Another nuance to HeroQuest is that the 1989 European version is slightly different than the 1990 American version (I’m leaning towards the American version but also using the European version as a reference).

Multiple Weapons?
The rules are ambiguous in regards to multiple weapons.  The European version has equipment cards and there’s no section marked “Weapons” on the European character sheet – some people interpret this to mean you can only have one copy of each weapon total.  The American version doesn’t have weapon cards and it’s character sheet says “Weapons” (plural).  There’s nothing in the American version to suggest you can’t have two Longswords (eg one for the Barbarian and one for the Elf) (or even two Longswords for just the Barbarian).

The Armory’s Battle Axe description says "You may not use a shield when using this weapon" – which I’ve interpreted to mean you’re allowed multiple weapons, you can use any one of your weapons for an attack, and if a Hero has a Battle Axe at all then he/she can’t have a shield.  With this interpretation, there isn’t any reason to have more than one melee weapon and one ranged weapon – so it might simplify the UI to just make that rule explicit.

  image

Orc’s Bane Math
This makes sense for the Armory Equipment, but when I considered the Artifact weapons I ran into an exception – the Orc’s Bane.

image image

I’m interpreting the text to mean you get two attacks, and the Orc gets a chance to defend against both attacks.  At first glance, it’s not obvious whether the Orc’s Bane is better than the Longsword when attacking an Orc.  An Orc has 1 Body and 2 Defense, so which is better – one attack with 3 attack dice, or two 2 attack dice attacks?  To answer this question, I wrote some code and did some simple probability math.

The code I wrote just iterates through all the possibilities for a single attack + defend.  With six sided dice rolling 2 attack + 2 defend, there’s 6^4 possible outcomes.  With 3 attack + 2 defend, there’s 6^5 possible outcomes.  Since the Orc only has 1 Body, there’s really only two types of outcomes – zero damage, or non-zero damage (which kills the Orc).

When doing one attack with the Orc’s Bane, there’s a 765/1296 = 59.028% chance of killing the Orc.  When doing one attack with the Longsword, there’s a 5832/7776 = 75% chance of killing the Orc.  But the Orc’s Bane gets two attacks.  So which is better – 59.028% twice or 75% once?

The simpler question is this – what are the odds we do the two Orc’s Bane attacks and the Orc is still alive (aka we “lose”)?  The odds of one Orc’s Bane attack failing are 1 – 59.028% = 40.972%.  The odds of two attacks failing are 40.972%^2 = 16.787% chance of losing => 83.2% chance of winning (of damaging the Orc).  So the Orc’s Bane is useful for attacking Orcs.

I’m aiming for authenticity but I also want to simplify the UI.  So a Hero can have one melee weapon, one ranged weapon, and one special weapon (eg Orc’s Bane).  For example, a Hero might have a Broadsword, a Crossbow, and the Orc’s Bane.

image image

Bad Weapon Choices Are Silly
To justify UI simplification, I’m assuming the player doesn’t want to make blatantly bad decisions like buying multiple Shortswords.  The Shortsword is really just a starting weapon for the Dwarf and the Elf, and there’s never any good reason to buy one (so yea – I love HeroQuest but some of the rules are a bit weird or ambiguous).

It’s not totally clear whether the Crossbow can attack one-square diagonally, but let’s assume it can because it the text says "you cannot fire at a monster that is adjacent to you" and elsewhere the game rules uses the word “adjacent” to mean orthogonal.  So if you buy a Battle Axe, then spending 350 Gold Coins on a Longsword just to attack diagonally doesn’t make sense because you could instead spend 350 Gold Coins on a Crossbow.

By assuming the player doesn’t want to use bad weapon choices, the UI can be simplified by letting the game automatically pick each Hero’s best melee, ranged, and special weapon – based on the Hero’s weapons list.  For example, if a Hero starts with a Shortsword and then buys a Battle Axe, the game will automatically pick the Battle Axe as the Hero’s melee weapon.

If a Hero’s weapons are (Shortsword, Longsword, Spirit Blade), then game will make set melee to Longsword and special to Spirit Blade.  If a Hero’s weapons are (Shortsword, Broadsword, Spirit Blade), then the game will set melee to Spirit Blade and disable special.

For the moment, I’m going with this – by default the game will automatically select weapons for the user as follows – melee, ranged, special, other, other.  However, the user can choose up to five weapon slots.  For HeroQuest, five slots is arguably too many – I can’t think of any situations off-hand where it would make sense to have more than three – such as Spirit Blade, Crossbow, Orc’s Bane.

image

HeroScribe support, Epic Campaign Plans

In my prior work post, I described HeroScribe as the “gold standard” for HeroQuest map editing.  It’s a great editor so I don’t want to spend cycles writing my own from scratch (unless there’s a good reason to), but I’d love to make some improvements to the HeroScribe editor.  I emailed the developer to ask permission to reference his project, whether he’s accepting feedback or code contributions, and whether he wants me to take over development of the project.  So far I haven’t gotten a reply.  The latest news post is dated 2014/12/03.  The earliest news post is dated 2002/06/19.  14 and a half years of updates – awesome dedication!

In my previous posts, I had been using a hand-written CSV file format for base game Quest-1.  But today I rewrote the map loader to instead take HeroScribe XML files as input.  As far as the quests go, here’s my development plan.  Start with just the base game (14 quests) (15 if we include EU’s tutorial quest The Maze).  That will keep me busy for a quite a while.

Then I’ll integrate the first two expansions as part of a three-quest-book campaign (Kellar’s Keep, Return of the Witchlord).  This isn’t a huge jump because there’s not a lot of new functionality in the two basic expansions.

Then I’ll integrate each of the advanced expansions as part of a single epic campaign mode.  For this I’ve chosen to include both US and EU advanced expansions in an order based on difficulty.  The full order is – base game, Kellar’s Keep, Return of the Witchlord, Against the Ogre Horde, Wizards of Morcar, Dark Company (single quest), Mage of the Mirror, Frozen Horror.

The epic campaign mode is a structured well-defined experience that challenges the players to play through each campaign in order as their heroes get stronger (they don’t literally have levels but they find items) and the quests get more difficult.  The US advanced campaigns are particularly difficult.  One of the tricks will be to try to conserve items from the earlier quests to help in the later quests.  For example, you can save up gold in the basic campaign and then use it to buy potions in the expansions.  Or if you get stuck on a particular quest in the Frozen Horror, you can hire a mercenary to help.

Assuming I eventually complete all of that development doing this as a part-time solo hobby project, I may even add some additional insane difficulty quests at the end of the epic campaign (after the Frozen Horror).

In addition to the epic campaign mode, I’ll also add some sort of separate free play mode that includes the option to load any custom map from HeroScribe.  And of course a player will have the option to create their own quest in HeroScribe and import it into the UE4 HeroQuest game, or use it with the physical board game (or heck – use it with the Tabletop Simulator version of HeroQuest).

Below are some side-by-side screen shots showing the first six quests in the base quest book (spoiler alert!).  Each row shows a scan of the original paper quest book, a screen shot of the quest in the HeroScribe editor, and a screen shot of the map loaded into the UE4 HeroQuest.

Each quest has a map and a quest-specific description.  HeroScribe XML files only contain the quest maps.  For the quest descriptions, I’ll need to add game logic code and extensions to the existing HeroScribe XML files.  For example, boss monsters have special stats that are currently not specified in the HeroScribe XML because the boss stats are part of the quest description (not the quest map).  Below is a scan showing quest 3’s quest map and quest text – notice the quest text specifies notes A, notes B, ULAG boss monsters stats, and wandering monster is Orc.

image image image
image image image
image image image
image image image
image image image
image image image
image

Diagonal Attacking with Walls and Blocks

A hero can attack diagonally if they use a certain weapon (eg long sword, staff).  This is simple – it’s just plus or minus one X, plus or minus one Y.  But we also need to account for walls and blocks – which can obstruct a diagonal melee attack.

Walls
Let’s start with walls.  Four sides are relevant when attacking diagonally.  In the case of attacking south-west, the relevant sides are – west, south, west then south, south then west.  Let’s consider the south-west attack visually:

image

To abstract this concept of “relevant walls” so it applies to each of the four possible diagonal attacks, we can say – xDir, yDir, xDir then yDir, yDir then xDir.  For south-west, the xDir is west and the yDir is south.  Each of these four sides has two possibilities – either the side is a wall or it isn’t.  That’s 2^4 = 16 possible scenarios.  Since that’s a small number, let’s visualize each of them for a south-west attack:

image

For the sake of discussion, I labeled each with a bit mask (the order is lsb-to-msb xDir, yDir, yDir-then-xDir, xDir-then-yDir).  Since HeroQuest walls are based on pre-defined rooms, some of these never happen on the standard HeroQuest board.  Expansions quests allow rooms to change, but even then I don’t think we ever see any of the one-bit scenarios (0001, 0010, 0100, 1000).  In any case, each of these 16 scenarios can be marked as 1 or 0 (valid or not valid):

0000: 1
0001: 1
0010: 1
0011: 0
0100: 1
0101: 0
0110: 1
0111: 0
1000: 1
1001: 1
1010: 0
1011: 0
1100: 0
1101: 0
1110: 0
1111: 0

Just for fun, consider the following pattern in the bits.  If there’s zero or one bits, then it’s valid.  If there’s three or four bits, then it’s invalid.  So that just leaves us with the two bit scenarios – (0011, 0101, 1010, 1100) are invalid, (0110, 1001) are valid.

Blocks
What about blocks?  In addition to walls on square sides, we can also have objects that block an entire square.  Blocks by themselves are simple for the case of one-square diagonal attacks.  Here’s a visualization:

image

If we only had blocks (no walls), then the only invalid attacks are 1xxx (target square is blocked) and 01×1 (diagonal line of sight with two corners).  1xxx never happens in HeroQuest because monsters can not occupy walls.  0111 can’t happen either; the Earth spell Pass through Rock allows a Hero to walk through walls, but the Hero can’t end his/her movement on a wall (or else the hero is trapped forever).  So if we only had blocks (no walls), then the only invalid attack to check for is 0101.

Walls and Blocks
However, we don’t only have blocks – we have both blocks and walls.  If I made a bit mask for the relevant combinations of 4 sides * 4 squares, we’d have 8 bits, which is 256 possible scenarios.  An array with 256 entries is not a lot to store in a lookup table.

An alternate way to look at the problem is this – we can map each relevant block to two relevant walls.  0001 block maps to 1001 walls.  0010 block maps to 0011 walls.  0100 block maps to 0110 walls.  1000 block maps to 1100 walls.  For example, block 1000 + wall 0010 => wall 1110 => invalid.

So far we’ve talked about south-west and about an abstract diagonal attack (with xDir, yDir).  Here’s a visualization of the four possible diagonal attacks.

image

Diagonal through two falling block traps
0101 blocks is an interesting case – attacking through two diagonal blocks.  It seems obvious that movement should be blocked by 0101 blocks (though in HeroQuest, only orthogonal movements are allowed anyway), but what about attacks?  Depending on the type of block and the type of attack, it might make some intuitive sense to allow the attack.  For example, what if the blockers are a falling block trap (which looks like a hill of rocks) and the attack is a crossbow?  It’s an interesting corner case.  My current opinion is that for simple and consistent rules, it should block the attack.  The HeroQuest falling block trap tile looks like this:

image

Diagonal Attack HeroQuest Rules
The Instruction Booklet (both American and European) specifically shows example scenarios of diagonal attacks.  This clarifies that diagonal attack through a door is valid and diagonal attack through two heroes is valid.  This is different than our 0101 block scenario because it’s heroes not blocks.  So blocks block differently than (heroes, monsters, furniture) in the 0101 scenario.

image image

Line of Sight
What I’ve discussed in this post is one-square diagonal attacks (or movements, though none of the figures in HeroQuest move diagonally).  This is a special case of a broader problem – it’s line of sight with a distance of one square (horizontal or diagonal).  HeroQuest also has ranged weapons and spells, but I’ll come to that in a later post.

Video
For now, I’ll close with screenshots and a video showing off valid/invalid detection of diagonal attacks.

Some additional features shown in this video are…  Action -> Attack -> sub-menu to select weapon.  This menu references the hero’s weapon(s), and each Hero can have multiple weapons (such as a longsword to attack diagonally).  Damaging a monster adds skulls.  If a monster’s body goes below zero, then the monster dies.  Mouse-over highlights a valid move or attack, left mouse down selects it (you can still move/attack orthogonally with arrow keys).  Orthographic birds eye view.

image image image image image image image