Well, I promised to talk about the game mechanics, so I better deliver.

Small Battles is a pretty stylized game, mechanically. It has to be – with each side typically fielding 15 to 20 units. In most ancient battles, that will probably see the standard infantry unit averaging 2000 or 4000 troops. The battlefield will typically be a 5 x 6 grid, meaning that movement is strictly limited. Battles will tend to be over in somewhere between 10 to 15 turns.

The game system itself is a simultaneous turn-based system. Each turn, the player receives a number of command points. The number received is random and varies from turn to turn, but depends on the quality of the army and the ability of the commander. These command points can then be used to issue orders to individual or groups of units. The game provides essentially five ways to spend your commands: to attack, to maneuver, to inspire, to rally, and to issue special orders.

The attack order is pretty straightforward; it essentially orders your forces to attack their highest priority opponent. If a unit doesn’t receive an attack command, it won’t inflict any damage on the enemy even if attacked (they are assumed to be fighting defensively or so ineffectively as to have negligible effect on their opponents). Running out of commands enough to order all your units to attack is probably a bad idea.

The maneuver order is used to order your units to move. Although there will be major variations dependent on unit type, scale, and so on, in general, it is always easy to move units straight ahead, less easy to retreat, and very difficult to move laterally. There is also the option of “force-marching”, trading resilience and commands for speed. Useful, if you just have to seize that hill first. In general, troop redeployment is hard (i.e., expensive) as was the case for much of this period. Pulling off a Cannae or Ilippa is the kind of thing that will only be doable by the great commanders.

The inspire order is essentially a command that allows a player to bestow a combat bonus on an attacking unit. It costs – of course – additional commands – which you may not have that many of to begin with. The effectiveness is also not guaranteed – it depends heavily on the attributes of the leader, as well as the distance the unit is from him (the greater the distance, the less likely the unit is to gain any benefits). Where you place your general matters a great deal in this game.

The rally order is the mechanism that can be used to allow your units to recover some of their resilience and perhaps even attempt to rally routed units. Useful if you have enough units and commands to pull exhausted units out of the battle line, but difficult to use effectively.

The special orders are things like changing formations (e.g., from and to skirmish order), unique unit abilities and similar things that one would tend to use very rarely.

And that’s basically it.

The combat system is pretty straightforward in theory. Each unit gets a number of “dice” to hit its opponents. Differences between unit types, terrain and situation (outflanking, charging, etc) affect the to-hit number, and the number of hits are subtracted from the enemy’s resilience. When a unit’s resilience hits 0, it disintegrates, causing all nearby units to test their morale. The more damaged your army is, the more likely your army is to simply turn and run. Fans of Lost Battles will recognize the basic ideas, although the implementation is different (the older Conquerors and Kings actually has pretty similar mechanics, which arguably are closer to what I’m doing).

The trick with the game mechanics will be to hit that sweet spot where you have six things you absolutely must do, and (often) only three things you can do. Difficult; but that is what tweaking and testing is for. And – of course – adding just enough chrome to the units/game mechanics to make people feel that the system captures the essentials of period warfare.

In the next post, I’ll go over how I distinguish between the different types of units in the game.

I recently released the MicaByte “Game Library” as open-source.

I work almost entirely in Native Android. That’s mostly a convenience thing – the time I have for game development is very limited, and although I am a C++ programmer by trade I like Java as well. Java is not a perfect programming language (none of them are), but it is good at getting out of the way and letting you simply do work. And while there are very many things that I absolutely hate with the Android APIs, it shares many of the strengths (and weaknesses) of Java. One of the reasons I started doing Android games was because of how easy it was to move into – I literally spent 2 weekends to create the first version of “A Brief History of Rome” (not published incidentally).

There’s another reason why I prefer sticking to Android, and it’s my dirtly little secret: I hate GUI and graphics programming. It’s not that it is hard (though it can be, take a look in the fantastic libGDX code base to see how complicated it can get); it’s mostly that I’d rather spend what time I have actually working on the things that I find interesting: the game design, the game engine and the artificial intelligence. The GUI and graphics are the dreary chore that I need to do in order to do justice to the rest.

Unfortunately, pretty much every game library for Android (and I’ve looked at most) aims for cross-platform compatibility, and in the process essentially end up making the development of graphics and GUI for Android harder, rather than easier. They also tend to focus on full-screen arcade/action game functionality, which tends to be less than useful when you need impart lots of information and display large maps. If there is something better and easier than native Android for doing simple strategy games, then I certainly haven’t found it yet.

The Game Library (though it hardly merits that name) is essentially a collection of utility functions and classes based on the native Android interface (not OpenGL) that I’m using in the development of Dwarf King and Small Battles. Most interesting for those who can get a little use out of this, perhaps, is the implementation of the SurfaceView and SurfaceRenderer, which builds pan, fling and pinch-zoom on the typical examples. When I have time to clean up something clean, I’ll put up an example Android app that shows how I use the classes in the android library in practice. The library is licensed under Apache License 2.0, which essentially means you can use any parts as you like, as long as you provide attribution.

Why open-source? Well, why not? All of the code in the library is either trivially simple, or stuff I picked up the ideas for around on the web. It’s not as if I’m doing anything terribly original or even – for that matter – very complicated. If others can benefit from looking at my code (or even improve it), that alone is worth the effort of cleaning it up and putting it online. Also – these days, open-source is in my DNA (I work with open-source software for a living).

The source code is available on GitHub; https://github.com/micabyte/android_game

It’s still pretty simple as I’m still cleaning up and adding a little code + I also need to create an example app that shows how it can all be made to comes together, but it’s a start. Enjoy.

So, for the past couple of weeks most of my time has been spent working on getting a playable alpha version of Small Battles ready and into the hands of the testers. It will be a while after that before the game itself is ready for release, but I want to start testing it as soon as possible, as I need to get three things right with it in addition to building something that works for historical battles: it needs to be simple, it needs to be fast, and it needs to be tough.

The Small Battles game engine is intended for use in resolving the battles that may take place in Dwarf King (and perhaps – in future – in Pirates and Traders 2). This is where the requirement for streamlined gameplay comes in – the battles have to resolve quickly enough that they don’t become the game, as is the case with e.g., Total War. At the same time, the battles have to be interesting enough to play that they don’t become a chore.

My personal favorite example of a game that manages this delicate balance is the battle engine in Conquest of the New World. With its simple 3×4 grid, it managed to boil battles down into a neat little tactical problem. Unlike most tactical battle games, where you can usually bring a third of the opponents army to the fight and still defeat them handily, Conquest’s system was simple enough that the AI could savage you if you did not bring the right force to the battle.

The thing that I felt was lacking in Conquest, was the feel of fighting a historical battle. However, there are several games that do attempt for more historical flavor within small grid form. “Conquerors and Kings” is one of the earliest I know of, though the finest example of a system that captures historical combat at this scale is without a doubt Lost Battles. If you have the slightest interest in ancient warfare, get that book.

Ironically, one of the first things I implemented back when I threw up my “indie development” site back in 2000 was a grid-based battle system (and I had an eye on Conquest even back then), so in some ways this is familiar territory. I’ve learned a lot since then, though.

Currently, the battle engine is up and running, and the game can be played either 1 v 1, 1 v AI or AI v AI (if a side receives no orders in a turn, the player takes over and issues orders). The AI is pretty simple, but it’s good enough to throw its forces at you. At the moment I’m experimenting with a 7×6 grid, though I’m strongly considering limiting it to a 5×6 grid (similar to Lost Battles).

I am currently waiting on the first batch of unit art before I post any more screenshots and let any testers at it. In the meantime, I’ll be working on making the user interface a little bit more friendly and implementing more of the combat factors. The latter is a tricky balance of adding enough to satisfy my innate urge for historical fidelity with the need for interface simplicity/transparency. Complexity is worthless if the player doesn’t understand what that complexity does.

Game development schedule for the next 1-2 weeks: implement the last pieces of Small Battles to get the alpha version running. Fix the bug in Pirates and Traders for xxhdpi devices (essentially the HTC DLX for now). And finish cleaning up the writing for the new adventure being added in Pirates and Traders.

Busy evenings ahead.

I have been enjoying working on the setting for “Dwarf King” with Ashton recently. It is interesting work, because having to build a game around Dwarves means that we have to figure out how their society fits into the game mechanics and the story setting. And it is hard work, because Dwarves sometimes seem like something of a “joke race” in fantasy. Once you think a little bit about how they live, many of the things which are “classically Dwarven” don’t really make much sense.

For instance, why would an underground race used to fighting goblins arm themselves with massive axes and warhammers? Both weapons would be highly impractical in constrained tunnels, and neither of them are particularly superior to other weapons against unarmored opponents. If the Dwarves of the deep tunnels had any military sense, they would be arming themselves with short swords to supplement pole arms and spears (a shieldwall of armored men presenting a hedge of spearpoints would make for a very difficult opponent in a narrow tunnel).

Fortunately, we do have the freedom to build our world how we feel like, and in this case, our Dwarves don’t fight much underground (although they still live there – underground based cities are good for protection). In this case, we have chosen to go for an (approximated) late iron-age level of technology and a Norse style of warfare. Obviously, the latter fits well with the common imagination of Dwarves, seeing as how many of the tropes are fetched from Norse roots in the first place.

In our world, then, the core of the Dwarf army, then, becomes the class of professional soldiers – paid for and maintained by the player (monarch) and nobles. These are heavily armored men; covered with in mail armor from head to foot, as illustrated in our concept image for a typical warrior to the right. Good mail armor is an excellent protection; it is not a coincidence that mail was used for almost two millennia, despite the significant cost of producing it. The armament is a mix of swords and battle axes (of both the one-handed and two-handed variety). In above ground fighting, battle axes clearly have their place, particularly as an effective anti-cavalry weapon (as the Normans and Franks discovered when they came up against them). Having that capability is convenient when your own forces have no effective cavalry component. Swords are a versatile weapon eminently suited to a well-armored soldier expecting to fight in a shield wall. Both weapons have their place in the hird of the Dwarf King.

The professional soldiers are supplemented by a small force of rangers and/or scouts. These are the Dwarfs who patrol the countryside surrounding the Dwarfheald for you, keeping an eye out for ogres and goblins and pesky elves sneaking around. Being reliant on mobility, they tend to wear little or no armor. Their primary weaponry is a crossbow; supplemented by a small light axe or sword.

Combined with the talents of your nobles, the warriors and the scouts form the core of the player’s force when going out on adventures and provides you with both devastating offensive force (warriors with two-handed axes are forced to sacrifice the protection of their shields), a powerful defensive component (well-armored warriors capable of forming a shieldwall ), as well as ranged support (crossbows).

If your Dwarves go to war, however, you’ll need to call out the levy. Given that we are dealing with a society that doesn’t practice slavery, the vast majority of your people will be peasants: farmers, miners, and craftsmen. These are not professional soldiers, and are consequently neither as well armed or well trained as your warrior core. In a more established Dwarfheald, a larger proportion of the levy might be able to afford or have inherited an old set of mail armor, but your people are refugees and the vast majority will have left such unessential weight behind as they fled. Consequently, the levy will generally be unarmored, with a helmet, shield, and long spear making up their main armament.

As a player, one of the decisions you will need to make is the balance between expensive professional warriors in your settlement and the extent to which you rely on the levy for safety, as well as the extent you spend resources on strengthening the levy (by purchasing/constructing better arms and armor) versus spending the fortifications of your home. Finally, when facing an external threat or a dangerous situation, whether to hide in your fortifications, march out to meet them with the full muster, or attempt to strike surgically with your elite forces.

With the announcements on Small Battles and Dwarf King done, I’d better talk a little bit about what will be happening with Pirates and Traders in 2013.

Most of my development effort this year will go to working on the two announced games. However, this does not mean that I will abandon Pirates and Traders, and I still have work planned on the game to be done during the year; fixing bugs (of course), as well as adding additional content to the game. The plan for the year is to do at least the following:

• Implement “Hunt for the Treasure Fleet”; a new multi-part storyline for the game, involving – strangely enough – the hunt for the Spanish Treasure Fleet. The majority of this story is written, and is planned for inclusion in version 2.6.0.
• Implement “Freedom or Death”; another new multi-part storyline for the game involving piracy, smuggling, and treachery.
• Add three new player backgrounds for P&T:Gold! players; the native, the escaped slave, and the indentured servant. The first two are a bit tricky, as the plan is for them to have some unique traits and items to fit their backgrounds.
• Add some new personal items and ship improvements to P&T:Gold!. I’ve had a couple of these planned for some time, but failed to find the time to test them properly.

Beyond that, I still have ideas for additional small story lines that I hope to cram in as and when I get time and a few new features/improvements that I would like to implement. Time is limited, though, so I know better than to promise anything like that at this time. We’ll see what happens.