Small Battles Closed Beta

As mentioned elsewhere, I’ve been working on Small Battles for the past couple of weeks. And after this latest round of improvements, I feel that it may be ready to go into more intensive testing.


So what is Small Battles again? It’s changed a bit in the details since I first announced it, but essentially it is a large scale tactical combat system that covers ancient, medieval, and renaissance warfare. The game is intended to allow the player to refight any of the great battles of history of the era in a compact turn-based format and features low unit density (10-15 units per side), hex grid battlefields, and fast battle resolution (typically 6-10 turns).

I’m looking for people to help with private Beta testing of the game, before I release the first version on Google Play. Essentially, this means that you get early access to the game (through Google Play) while it is still in a somewhat rough state (though hopefully not too rough). I’m looking for feedback on a number of things, such as the UI and feedback mechanisms, as well as the ever-present need to test the game on other hardware/OS combinations than my own. I particularly need players who are willing to go multiple rounds with the AI and describe how they took apart the AI to me, so that I can try to improve it.

The beta version focuses on the Ancient world and features three “tutorial” battles, as well as the two historical battles of Dertosa (215 BCE – Rome vs Carthage) and Bibracte (58 BCE – Rome vs Helveti).

If you’re wondering whether this relates in any way to Pirates and Traders 2, then yes – it does. Assuming that this turns out to be not awful, I intend to implement port battles in P&T2 using the same system. Just instead of Legions, Catapults, and Archers, you’ll be fighting with pirates, sharp-shooting buccaneers, and cannons.

If you’re interested in helping, contact me with your name and e-mail address (need the one you use as your Google ID on the device(s) you intend to test on), either on twitter (@MicaByteGames), PM on Facebook, or by e-mail (support at micabyte com).

March already?

Why does February only have 28 days? It has no business being that short – always feels the lack of those two extra days when I’m busy. Anyway – a little bit of the current status.

I’ve been trying to release new screenshots/graphics regularly each week, but this weekend just got too busy. I’ll try to resume with that this week or the next. Apart from that, the first few months this year have gone into heavy development.

Much of January was spent working on the code in Dwarf King. Most of the framework for the game is now in place, although there remain some parts that are still not fully developed. I’ll have to go back through some of the code there; but I don’t want to build a lot of functionality in there that I might then decide to throw away. At the moment, I’m pretty much waiting for some of the content for the game to be produced (i.e., maps, storylines, etc), while I work on other aspects.

An important milestone for Pirates and Traders 2 was reached, when I received the new in-game map. That required some re-work of the game engine as I ran into some unexpected performance issues, but most of those should be solved now. I love the new map (which I posted on FB), and work is now progressing on filling in the map data. Unlike the original game, the P&T2 map will be a grid map, so every space on the map needs to have data encoded (name, description – if it’s an interesting place, special features, etc). It’s a lot of work – unfortunately – but I think the result will be worth it.

Finally, I’ve been working on a major “rebuild” of the Small Battles combat engine. Combat is an important component of Dwarf King, and it is of course not irrelevant in Pirates and Traders 2 either. I experimented with a couple of different combat models, but I’ve now eventually – I hope – settled on the version I’m going to use. Assuming things work the way I want them to, it’ll be a simple turn-based combat system, played out on a hex grid. I’ve been putting the finishing touches to the new version in the past weeks, and assuming I soon get rid of the last bugs, I might do some alpha testing of that soon and integrating with the Pirates and Traders as well as Dwarf King engines.

Next Stops:

  • Finishing the Pirates and Traders 2 map data.
  • Integrating the combat engine into Dwarf King and P&T2.
  • Finish up the next Pirates and Traders update.

Now, back to working out the kinks in that battle engine.

Hot July

Well, at least here in Norway. Which is great, because it means lots of time out and about in the sun, playing with my sons. It does mean that I’m doing a good deal less programming than it if were rainy and dreary, but I’m not complaining. Even if the good weather means slower progress, there is always progress.

Most of my work on new games for the past month, has been focused on Small Battles. This is because I intend the Small Battles game engine to form the core of the land combat engine for most of my future games, so getting this right is important. Keeping this in mind, has caused me to make some important changes to the game engine. The original design called for simultaneous turns, but the initial play tests and my own experimentation convinced me that this kind of phased movement (first issue orders, then see the results) is a step too abstract for many. Consequently the turn sequence is now standard I Go, You Go turns. I also streamlined a few other  elements that needlessly complicated the rules, without adding any appreciable depth to the game. It’s still not as simple as I would ideally like it to be, but I think the new version is a lot more intuitive to play than the original.

Once I’m done testing it, and fixed some more bells and whistles to it, I’ll probably put it up on Google Play using the alpha test system.

In the meantime, I’m back to work on Dwarf King and Pirates and Traders 2. The former is getting a bunch of the graphics done at the moment, including some (in my completely biased opinion) really ace portraits. I’ve posted one on the facebook site, and more will come later. On Pirates and Traders 2, I’ve mostly been playing around with the map lately, ensuring that map elements display correctly. The next step will be to add actions and the status screen; or possibly to check out how big a map I can really use. I would really love to have a map including the Gulf of Mexico so that we can get places like Campeche on the game map, but there’s always the thing about app size. At those size, one can easily end up with a map that fills 15Mb all on its own – and Pirates and Traders is already a pretty big app to begin with.

I’m not completely done with vacation this summer yet, so if responses are a little slow during August, my apologies in advance. If you send me an e-mail and I don’t reply during the weekend, do feel free to ping me again.

Hope you all are enjoying the weather.

Summer Blues

The time before summer holidays is often a busy time, and so this year has proven as well. For the past few weeks I’ve been working on a variety of issues (including fixing a bug in Pirates and Traders), but my time has been pretty limited due to a number of reasons, mostly work related. Worse than the slow progress, though, is that my response time on bug reports has been pretty slow. My apologies if you’ve sent me a bug report, and haven’t got a timely reply, or posted a question on FB and suffered the same fate. It is, unfortunately, the sort of thing that happens when operating a one-person operation on a part-time basis.

Anyway, a few things have been happening during the past few weeks.

Pirates and Traders 2.6.7 was released, containing a new (infrequently) recurring mission that can earn the player a native banner. I think this was needed, since previously you could only earn the banner in two unique missions, and your chances of either of them succeeding was not very high. I’ve also started exploratory work on Pirates and Traders 2, and I hope to write a little bit about the ideas I want to implement in that game on the facebook page soon.

A lot of time has been devoted to Small Battles. I wasn’t really happy with the first alpha version of the game, so I’ve made some important changes to the game mechanics. Currently putting in some effort there, before I return to work on Dwarf King. Just received the first of (hopefully) many character portraits for the latter, so things have been happening on that front too, albeit at a slightly slower pace. In either case, I hope/expect to be able to devote more time to development over the next couple of months, as well as sharing some of my thoughts with respect to the projects I’m working on.


Command and Small Battles

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.

Gallic Cavalry 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.

Cretan Archer 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.

Talking of Small Battles

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.