Dev Diary 4: Prototype Animal Form Videos

Today I finished up adding the animal forms for the first three units into the prototype for A Druid’s Duel. If you read through the last entry, you’ll recall that there are four main units, and each one can temporarily take on an animal form to give them alternate abilities for a single turn. Take a look at the three videos I put together that demonstrate the animal forms and how they can be used in the game.

Soldier and Wolf Forms

In this video I show the soldier unit and its animal form, the wolf. The wolf is used to cover great distances, capturing land but not attacking. This is great for slipping past the enemy lines, setting up a foothold, or simply running away.

Archer and Eagle Forms

In this video I show the archer unit and its animal form, the eagle. The eagle is a clever and formidable form, giving the archer powerful abilities. The eagle can cover great distances, even over gaps and obstacles, to strike enemies or gain a foothold in remote corners of the map.

Knight and Bear Forms

In this video I show the knight unit and its animal form, the bear. The bear is a powerful juggernaut, able to move and attack multiple times during its turn. From clearing out swarms of enemy druids or just capturing more spaces or relics, the bear is an effective wrecking machine.

Dev Diary 3: The Evolution of Druid Units

One of the main themes to explore with the design of A Druid’s Duel is how dynamic boards can present new challenges to experienced players who all have access to the same resources. That means the game rules and resources available to the player need to remain the same regardless of the board or map layout. In support of exploring this primary theme, I’ve chosen to limit the number of unit types to something manageable over a relatively small game board. The pieces available to each player are also identical to their opponents, as in chess, so the difference in how they are utilized is one of the few indicators of a player’s true tactical skill.

The first issue is in allowing the map to change during gameplay. There is already an option each player has to build bridges over open spaces each and every turn. It costs Mana, but otherwise is a solid option (see the previous post and video for a look at the game board). Previously, I had also planned on the player being able to acquire power-up items that would allow them to change the land spaces and obstacles (trees, shrubs, etc) a few times per game. But in adding a second ranged class, the Waywalker, I feel I have opened up a better way for the player to directly manipulate the map layout. Possibly every single turn! The Waywalker’s entire purpose is to add or remove both land spaces and obstacles, while not being able to directly attack anyone. This is far more interesting and means that the entire game is played with the druids on the board, not by a combination of board pieces and quasi-direct actions the player takes like some omniscient overlord.

Druid Waywalker

Druid Waywalker – has the ability to alter the game map in dramatic ways.

On top of allowing for a good way to manipulate the map during the game, I was also concerned the base units were a little stale. In playtesting the prototype with only the barest of units (what are currently called soldier, archer, and knight), I found they produced longer games, often with a certain amount of time in the mid-game that was very much a stalemate, where lots of inexpensive weaker units are replenished onto the board. The animal forms will speed this up, as well as add some great thematic elements. Even with one animal form implemented (the bear), gameplay has quickened dramatically, while simultaneously forcing a player to be more conscious of how they spend Mana each turn. I found myself not just blindly throwing a bunch of soldier druids down, but really considering how the super-powerful bear could help bring an end to the game or if needed, get me out of a jam.

With the introduction of the animal forms and the Waywalker class, the game now boasts eight classes. While the animal forms are temporary, they have different abilities, and so I’m counting them as a whole class here :)

The doubling of unit types once again begs me to consider something I had tossed out a while ago – allowing permanent unit promotion.

In early designs, I had wanted to limit players to only being able to actually place soldiers. Then, during their turn, they would be able to upgrade any soldier unit into an archer or a knight. This would add an element of trade-off decision making to each turn, as the player would choose to make use of the soldiers or upgrade them into more specialized classes. The upgrades would be permanent and only available to soldiers. That means a soldier would become an archer or a knight. And that archers and knights would be stuck in that form until victory or defeat.

Original Units

Only soldiers could be placed but they could be promoted into a ranged archer or a more powerful knight.

With the waywalker and animal units added, and a distinction between a melee combatant and a ranged unit, the Promotion Option would be organized like this:

The Promotion Option

All units stem from either a soldier or an archer. Animal forms are temporary while units are permanent.

Players can only place soldiers or knights onto the board. Then, spending Mana (everything has a cost!), they can choose to promote some of them already in play, either temporarily with animal forms or permanently with other unit classes. You could not, for instance, get a knight from an archer. Only a soldier can become a knight.

To be honest, I really like this idea. It takes a relatively small number of units (compared to other tactical games) and presents them in a tech-chainesque manner, with all the tradeoffs or gambits that come with it. It is also a unique element, something designers always strive for. Of course, this approach creates additional complexity in a game designed to be simplified and it’s possible players would find it cumbersome just to achieve so few unit types.

The alternative option, which I simply call the Flat Option, is how the protoype is currently designed and built. As I mentioned above, I had forgone the idea of unit promotion with only three types, as it just seemed to add complexity for no reason.

The Flat Option

All unit types are available all the time. Each has access to temporary animal abilities.

This option is intriguing in that it is straight-forward and simple. Each unit addition decision is easier, as you do not have to weigh the short-term use of a melee or ranged unit against long term access to powerful casting or powerful animal forms. You need an archer, you buy one. Need a better soldier? Buy a knight. Need fodder? Get some soldiers. Very easy.

In the end, it will be the players that help decide. The prototype is already walking down the Flat Option path (largely because it’s about 70% complete already) and the first round of playtesting will use it. However, I still have a strong attraction to the notion of unit promotion and will ultimately find a way to playtest that as well.

 

 

Dev Diary 2: Meet A Druid’s Duel

Today I have something special to share with you: a first look at the prototype of A Druid’s Duel. This is the first time anyone has seen not only the prototype, but essentially anything of the game. I’ve gotten a lot of questions about what the game is like, what do you do, what does it look like – all that. And I’m very excited to give you a small peak at this work in progress. I will be posting some additional artwork and game details over the next week.

A few caveats and then we’ll get right to it. First, this video shows the current status of a game prototype, intended to implement the core game mechanics of A Druid’s Duel. The completed prototype will be used to gather feedback regarding the gameplay balance and rules. That feedback will be used to solidify what the full version will be like. When those rules are combined with great artwork and moving sound, it will truly be something special. Even though that full version is a long way off, I am very happy with the state of things.

Given the rapid progress I’ve been able to make on the prototype, I am anticipating that playtesting with with it could begin mid-June. Keep an eye out for a call for players or drop me a line directly via any of the social media. I will be looking for several small groups of testers from the public to participate in playtesting and brainstorming sessions. It’s an exciting time and I am very much looking forward to seeing how players will help forge the final rules and features.

Final warning! This demo is rough. There are no animations. The artwork, sound, and music are all placeholders. But some of the basic framework is there and you can begin to see a game emerging. Watch the video and get ready to meet A Druid’s Duel.

Dev Diary 1: IsoManiac

I love isometric art. I always have. From old school games like Snake, Rattle, and Roll to Solstice to Final Fantasy Tactics to the immaculate Diablo series, I dig the look. Given that, you won’t be surprised to find out that A Druid’s Duel will be rendered in beautiful isometric perspective.

While visually appealing, isometric perspective adds complexity to the implementation if you go with traditional 2D techniques as opposed to 3D and tilting the camera angle. For the purposes of learning and moving the Druid’s prototype forward, I’ve decided to build a rough isometric engine with canvas and JavaScript. I don’t need much for animation and my game doesn’t care about the height factor. Therefore the isometric portion is primarily a visual thing. Before you go thinking I’m utterly crazy, there are a few existing engine options available. However, most are incomplete and only one real candidate was implemented in canvas/JS. Isogenic looks very solid and I’ve even downloaded the trial. But haven’t resorted to cracking it open. I haven’t needed to – yet.

Non-isometric tile-based canvas/JS engines seem like a dime-a-dozen now days. They’re all over the place and there are several complete packages that claim you don’t have to write any code to create a great game. I won’t get into that topic. Suffice to say, there are options that make rolling my own engine (of any kind) at least moderately questionable. I could try to hack Impact or Melon or any of those to support isometric tiles. I’m already using the wonderful Tiled application as my level editor and it outputs nicely to JSON.

Given all that, I still figured it was worth my time to understand how isometric engines are implemented. And there’s no better way to learn than to roll up the sleeves and get into it. I can get drawing working easily enough, but I have never tackled what for me has been the tricky part: translating clicks to the desired isometric tile or object. Without being able to select the right tile or object, there really is no point in the game looking nice in isometric glory.

Yesterday I finished the prep work and got a basic game shell up and running, complete with sound, localStorage, a very rudimentary animation cycle, and at least responding to input for different scenes. That left the troublesome next step: turning clicks into something useful. I know this has been solved an embarrassing number of times by others far older and wiser than me. When I closed up shop yesterday, I was struggling with where to go next. I could much more easily implement the prototype with square tiles. The game logic is identical and it’s more simple to implement. I went to sleep with that debate running through my head.

Fast forward to 5 o’clock this morning and I had it. There are no shortage of isometric help articles online and I’ve found myself reading one in particular a few different times over the past decade. At least with iso games, nothing really changes. The state of the art in that realm has advanced as far as it’s gonna. But for someone like me, that gives enough help to make it feasible. I decided to visit this article again and implement the solution as it suggests.

First, I put the main problem in visual terms. Capturing a click is easy, but translating a diamond-shaped target out of a rectangular region poses a problem: they overlap. I tried to capture all the information I could think of as to what the logic should be.

The Problem Parts

As you can see, I highlighted the key components, including the ol’ distance formula. Yeah, it’s been awhile :)

Next, I converted the article’s pseudo-code into JavaScript in the click event handler. I ran into a few snags with how the overlapping rules worked in practice. You’ll note the article does not tell how to determine where on the mouse map is clicked, but eventually I used some more 8th grade geometry to solve it. By mid-morning I had it returning game world coordinates for the proper isometric tile clicked. I was pretty happy to get it working, let me tell you. I have literally never been beyond this point. Drawing, yes. Handling input?  Nope.

This left the seemingly easy task of displaying a cursor or some visual record of where the user clicked. This logic was crucial, as selecting a unit is great, but I need to visually translate the unit’s possible moves for the user, so that means I need a solid grasp on how this is determined.

I’m embarrassed to say this took way longer than it should have. I got in a problem-rut, where all I could think of when it wasn’t working was to keep trying the same lines of code in different ways, all to no avail. Bordering on table-flipping, I resorted to drawing the problem out, again. You can see it here:

Offsetting Rows Cause HeadachesAs you can see, the headache comes from the fact that, like during the tile drawing routines, you need to account for the variance in row width all the time. Some rows are shorter than others, and this offset needs to be handled for all drawing. Seems so obvious now. Drawing the problem helped, and I walked through the entire height and width of the game board to get the algorithm right. Then wrote the code. Then danced a happy dance of endless joy. As proof positive, feel free to watch this simple video of the working selection and drawing. It may not look like much, but I’ve gone off the edge of my experience map now.

http://www.youtube.com/watch?v=T79ftaJk53o

I’m very excited to get to placing units and moving them about with my new-found coordinate power.

Day three has been a really, really good day.

 

Now What?

Thoughtshelter Games now has a proper website. One with real content management and everything. Gosh, it’s like we’re developers or something!

It’s going to be a busy week. Er, month. Well, pretty much the entire summer will be hard work. There is so much to be done on A Druid’s Duel that it’s scarcely possible to start pulling one strand of that proverbial ball of yarn without immediately finding some other thread that needs attention. Which, of course, begs a plan. Yes, a plan.

Planning is one of my fortes, and I’m very much looking forward to nailing down the plan of attack. I can tell you the rough outline of the plan to bring Druids to life, and it goes something like this:

Build a web-based prototype.

I know web technologies already, so I’ll start there. I want it up and running quickly, so I’ll produce a prototype with canvas and JavaScript. The main purpose of this step is to take the paper prototypes I’ve been using to playtest game rules and mechanics to the next stage. Even an intentionally uncomplicated video game such as A Druid’s Duel has enough data tracking and number crunching to make a paper prototype cumbersome for all but the most basic of versions. Since it has graduated from raw inception to a more formal design, it’s time to get it working on-screen.

Then, playtest the bejezzus out of it.

The ultimate goal for this rough and rumble prototype is to refine the core gameplay down to a stable ruleset. Utilizing courageous playtesters will be key, as only real players can find and show the weaknesses in the design. So, we’ll play the shit out of the prototype, iterating on the core rules (unit types, unit promotion, map mutation, costs) until we’re satisfied that the base components won’t drastically change. We’ll have the full scope of what needs to get done and we can throw that up against the calendar and see what we’re looking at.

What then?

Those are the foreseeable and immediate roadmap steps. This should bring us to late summer. Then, of course, comes the primary development. I’ll shift to the Unity engine (seemingly the indie go-to) for the engine of choice. Unity allows for stronger cross-platform viability for the end product than writing a strictly JS-based game could. By then I’ll have also lined up music and produced some rudimentary sound effects. At this point I’ll be satisfied enough to bring in the real artist to bring the game up a notch while development gets into full swing.

Like I said, it’s a lot to do and you’re welcome to follow along. In fact, please do.

Now, let’s get to it.