MicroWarsConcept

Concept sketch by Alicia Guardeño.

A small but big but small game

OK, it is about time to officially introduce you to the side project I have been working for the last 4 months, even if some glimpses have been shown here and there (in which case, you will be getting a lot of new info anyway!). You know we folks developing games often say that our personal projects are “special”. Almost every of them. Let’s say then that one feels extra-special here. Probably it’s worth mentioning that I have been passionate about strategy games for as long as I can recall; both classic PC strategy games like Seven Kingdoms and the Age of Empires saga, or SRPG-like, couch-friendly games such as Disgaea and Fire Emblem are among my most treasured gaming memories. It shouldn’t be a surprise then that I have been looking forward to creating my own thing for a long time. What’s that if not utterly fascinating.

For a long time I have wondered about how my first approach to the feeling of commanding an army (approaching this in a broad sense) could be. However, the huge complexity which involves the development of a strategy game —design-wise, but also from a technical point of view— has kept this idea locked in that special place where we destinate our romantic but unachievable desires. Not anymore, though! A few prototypes and several games later I might not have the experience to bring this project to a successful conclusion on my own yet, but I have nevertheless teamed up with a bunch of other great creators (some of them more experienced than I am, some others just venturing for the first time in this game-creation thingy) to bring MicroWars to life, a TBS-game with shabby minions that can not die and mighty heroes that can (and will), in what we want to be an inspiring pocket-ode about power struggles and backstabbing. As a formative project, we’re not going too far from the boundaries of the genre, which can be seen as a self-imposed constraint.

As stated, it’s been more than 4 months of work already, mostly moonlighting after our full-time work schedules, and even if the intended “micro” essence that we pursued regarding the scope might have gone a bit bigger, we are getting closer to something playable. And, anyway, it is indeed a convenient time to start what we would love to be a recurring dev blog, hopefully as useful to ourselves as it could be to any other developer trying to reach a similar goal. While we build that blog (Tumblr? TIGForum thread?), this introduction will do. MicroWars (just a codename yet) is a turn-based strategy game in the fashion of Advance Wars in which the units can’t die. Two “armies” comprised of a powerful Hero + a bunch of Minions fight in a 2D, tiled battlefield, and only one hero can emerge victorious. The minions are just the pawns in the heroes’ game, so it’s in their best interest that this fight ends as soon as smoothly as possible… and so will they act. Loosely inspired by a dark fantasy mood, the heroes (AKA, the players) can merge their same type units into a more powerful version, sacrificing terrain control in favor of deadlier fighters. However, units still can’t die. In a spiritual, gloomy world fueled by a mysterious energy, “dead” units are gameplay-wise just temporary KOed, and their energy can be as well translated into “mana” to be directly used by the hero, triggering powerful skills. With immortal units, the point is not to destroy your opponent’s army, but to take it from him, finally claiming his very energy for your side.

MicroWars in a nutshell

It’s more direct references are the Heroes of Might and Magic saga (powerful heroes that lead other units in battle, modifying their attributes), Total War Saga/Warhammer (troops have some sort of “moreale” and can change sides); AOE II & other RTS (terrain affects movement), Joanne D’Arc (game feel, evolving units), Enchanted Arms (chess-like tiled scenario, geometrically interesting areas of effect), Disgaea (I pretend to drag inspiration from this game’s skills) and obviously Advance Wars/Fire Emblem (gameplay strictly in turns, rich world, money (here, energy) as the only resource). It is also my personal attempt of gathering everything I love on RTS (real-time strategy games), packing it in a casual format compatible with short gameplay sessions. Again, we are not trying MicroWars to be a never-seen-before experience, but rather to take a few well-known ideas and pack it in an unusual and lightweight format, which several gameplay twists and an all round nice finish.

Building the game

Obviously, all those features need a framework to be implemented. For now please take this section as a brief introduction discussing how and why we are taking certain decisions. But fear not: we plan to disclose detailed info and share everything we have learned at many technical levels across many more posts to come. To start with, it is worth noting that MicroWars is being developed on Unity. As you may know, Unity has nothing like a built-in Tile editor at the moment (though said tools have been shown and should be available soon-ish), which put us in a rather uncomfortable position when it comes to level design. As many other teams did before us, we decided to move forward with Tiled, a free, marvellous, platform agnostic tool that allows you to import your own tileset, create orthographic or isometric maps and basically get your job done comfortably, making use of other useful functions such as auto tile. In order to connect Tiled’s .tmx maps with actual Unity scenes we are using another great tool, Tiled2Unity by Sean Barton, that takes that .tmx map and returns a prefab that you can use almost directly. But it hasn’t been that easy, though. Following Seanba’s default export we ended up with a XML map comprised of huuuuundreds of GameObjects, more concretely an object (or more) per tile. That might be okay for small maps, but even in a game like ours, we were exposing our work to ulterior optimization problems.

In order to solve that, we designed a custom grid system in which each tile has a position and set of properties, as well as each unit does. The new ready-to-export XML stores the information in the same format, but that’s pretty much where their similarities end. Objects were created through a custom spawner coded directly in the Unity project, and thus the game board becomes a bidimensional array instead of a bunch of objects. More elegant, way more optimized, and rock solid (once it’s properly done, of course). This implementation decision has another foundational side effect: a huge impact on how the units move. In this case, we took advantage of a “simple” A*-based pathfinding system (read that “A star“), that calculates what’s the movement capability of each unit, considers what’s the movement cost of a given tile (since some terrains are more expensive in term of movement than others) and return an area in which the unit can move. These systems were designed and implemented to a large degree by Alicia Guardeño, my good friend and talented artist/programmer, and certainly her experience helped the project avoid some pitfalls that were ready for a less experienced developer to fall into.

Last, but not least, we had to program a Turn Manager that, erhm, managed our up to then anarchic units. It’s interesting to mention that each unit doesn’t only have a “Movement” value, they have also a “Speed” value that determinates the order in which they get into the fray. Moreover, this stat will be affected down the road by skills and also by the heroic aura too, so the implementation just has to be perfect. For now, a system that detects units by tag, orders by speed and re-order/updates units per turn is working like a charm. We’ll see how it will change with the new units entering the battlefield…

What is still to come

In few words, a freakin’ lot. At the moment, I’m working on a parser that will allow our other designer to modify unit stats in Unity via CSV files; I hope that the experience I’m getting thanks to the parser included in my almost-finished Kindle Clippings Manager (hopefully I’ll tell you about that one soon) helps with the task. Once that’s done, and more units implemented, the real thing will start. I can foresee a painful balancing process here, and a lot of work will be required to add skills that feel good to use, if not even necessary in the case of advance players. There’s a really a challenge ahead, and I can’t wait to get there. Anyhow, this will be done when it’s done, it will be free too, and hopefully it will be challenging and fun. In the meantime, please enjoy a gif showing the current status, featuring placeholder graphics and low-fi feel.

 

MenuTest

Chat with the team

Eduardo Garabito (@dazedword) – Design, Code, Project Coordination.

Alicia Guardeño (@firenz) – Art, Code.

Sam Fiunte (@CanetheSutter) – Design, Testing.

Víctor Ojuel (@VictorOjuel) – Writing, World Building.

Pablo Ruiz (@thefingerspit) – Sound, Music.