Design Diary – August 2022

Hi there! It’s been an interesting time since my last update in coding my hex-and-counter game, Arete: The Battles of Alexander the Great. I visited Gettysburg for the first time and, apart from being impressive and impactful for its history as you’d expect, it’s a fantastic town to hang out and spend some time in. Our guide, Eric, happened to be one of the hosts of The Gettysburg Podcast and incredibly knowledgeable. After that we visited New York, which is always a treat (especially hitting up Compleat Strategist) but then we caught COVID at the very end which put a damper on things. We were vaccinated and double-boosted, so I think this helped minimize the effects.

COVID also put a small bump in the road as far as working on my Alexander the Great game, but I got right back into it as soon as my energy came back. So here’s what I’ve been working on since then.

Save and Load Game

This was the biggest change because I had to restructure a ton of my code. I had a lot of global game variables (apologies to the developers who are cringing right now) which was bad practice anyway and I had to attach them all to a single game object that I could save and load. After hours of Find/Replace magic, I could save a game and come back to it later at the push of a button. Pretty cool. For now I’m only saving the player’s current game automatically as they play, but this also allows the ability to add save slots to let the player save multiple games if I go down that road later. Here’s a short vid showing it in action:

Finalize First Scenario: Chaeronea, 338 BC

Maybe not the final final, but after completing art for all the units involved and the necessary things like terrain features I could finally make the first scenario “official.” Of course changes might still happen and everything is fair game but felt good to have one scenario in the books.

Stacking Limits

After spending some time playing the game, I noticed that it was advantageous to bring my units closer to the middle to take advantage of the generous stacking limit of three counters per hex. I didn’t like this because it didn’t align with the idea of ancient phalanxes in lines across the battlefield.

After some thinking, two options jumped out at me. First, I could give both sides more counters to “fill” all the stacks. To do this, I could tweak the value of a step to represent fewer soldiers which consequently would require more counters to get to the number of soldiers in the battle. This option didn’t appeal to me because this game is digital and tablets are one of my main target devices. As such, I want this game to be pick-up-and-play so the last thing I want is to make the player have to move too many counters. It might be fun with stacks of physical counters but it would get tedious for a digital game.

The second option made much more sense: I could instead change the stacking limits so the player wouldn’t “clump” all their units together. I decided to rewrite my stacking code so I could play with different stacking parameters (counters, steps, strength, etc.). Finally, I’ve settled on using steps to limit stacking to a maximum of four per hex. This means that a full-strength phalanx (4 steps) in my game can’t stack with any other unit, while other units like some cavalry (2 steps) can stack with each other. After some playtesting this felt right. See the Chaeronea setup above to see what this looks like at start.

Return Fire and Improved Fire

I added animation to Ranged Fire projectiles as well as the ability to return fire for some units. I’m not 100% sure units in this game will have this ability but I wanted to allow for it just in case. When targeted by ranged attack, a unit with this ability gets to interrupt and conduct a ranged attack of their own on the attacking unit before the original attack resumes.

Player Resumes Play After AI Die Rolls

This one was more of a usability thing, but I had the AI’s dice rolls happen and play would then resume automatically. I thought this would be a good thing because it meant fewer clicks from the player, but this wasn’t giving enough time to process the result. I tried slowing down the rolls by adding a timed pause, but this proved to be ineffective as well, particularly in the case of combat where the player wants to assess the damage and what factors led to the result.

To remedy this, I pause play when the AI makes a die roll and display a button to let the player resume whenever they want.

User Interface Work

My prime target device is the iPad and other tablets, but the UI translates easily to desktop computers as well and will hopefully be releasing for those too. More challenging, however, is fitting the game onto a phone. This has seemed very doable with a few exceptions so I took some time to work on those. The toughest nut to crack was the crowded combat table which also shows the counters being attacked and modifiers, but I think I managed to do it with a combination of scrolling (see below) and having the whole thing be collapsible.

Bugs

Finally, I fixed several bugs that had to do with leaders, retreats (again), and the new stacking rules. With the first scenario completed, I installed the game on my wife’s iPad and discovered she has innate talents in playtesting and bug-finding. She also says the game is fun so that’s a good sign. A big thank you to her for taking the time to do that and to document the quirks she found.

That’s all to report for this round. I’m now busy researching and doing the artwork for the second scenario, Granicus. The mechanics to the game seem pretty solid at this point, but I still want to improve the AI, so I’m not sure what the next report will bring. Until then, happy gaming!