We just uploaded a new alpha version for you to play with! The big change is the completely redesigned second campaign mission, "All His Base". Some players found the old version to be quite confusing, and it was a bit of a slog to play through. It should now be clearer, and a lot more fun to play. Plus, we think it's rather pretty! What do you think?

We also added a couple of achievements, and the dialog text now "fades in" over time. You can make change the speed in the settings menu, by the way.

What happens often in game design / game creation is that something looks quite simple on the surface, but turns out to be much more complex once you get down to the details. Or it IS simple, but will take a lot more work to get done than you anticipated beforehand. Both these issues can dramatically increase the time you need to create your game, and they make it easy to bite off more than you can chew. I recently read an article from Chris DeLeon (a.k.a. HobbyGameDev) in which he touched on this subject. Since we've encountered our fair share of these time-consumers in building Powargrid, even though it's a relatively simple game compared to the big titles out there, I thought it could be illustrative to walk through a couple of examples here.

We've seen the 'takes much more time than we thought'-effect most often in creating missions for the campaign. The main reason for which is that we're not willing to compromise the simplicity and elegance of the basic game rules for the sake of the campaign. One of the key characteristics of Powargrid is that the gameplay is complex even though the basic rules can be explained in two and a half minutes. We also consider that one of the game's strengths, so we're careful not to break that. For other games, the reasons unexpected things crop up will usually be different. But they'll be there nonetheless.

Using the Powargrid mechanics and our AI, it's quite easy to set up a skirmish-like mission where both you and your opponent get some power plants and then battle it out. And to be sure, a number of missions in the campaign are just that. But using nothing but that setup doesn't give players the excellent experience we're hoping to provide. So we want to make more interesting missions, but that also means they become more complex to design and build. On top of that, a lot of the earlier missions in the campaign also function as tutorials, which also places extra demands on mission design.

In building the mission we're currently working on, quite a few unforeseen things cropped up. And while the time loss is annoying, it does give me some good examples for this post :). The basic idea for the mission is simple; destroy five factories that belong to the yellow blobbies.

When I drew the concept for this mission, I naively thought that this would be one of the straightforward ones. Turns out I was wrong. It quickly became clear that just having a few extra buildings to blow up wasn't fun enough. It adds a bit of an extra element because destroying a factory opens up a big chunk of the game grid at once. And while that rewards you for carefully timing a factory's destruction, it wasn't enough. On top of that, if all other buildings need power plants to run, it's not exactly logical that factories (which usually are pretty energy-intensive) magically power themselves. Luckily, both problems could be solved by simply placing a power plant next to each factory, which in turn uses up all the power that power plant produces. That wasn't very complicated or time consuming yet, but it did set the stage for more complications.

In the original design I gave the AI two power plants, just like the player. But with these extra yellow power plants the AI gained 50 power per turn to use against the player each time a factory was destroyed. This added an element of danger to the mission, which was certainly fun to play against, but it also meant that balancing the mission became an issue. The mission could quickly become too challenging, especially for players who don't read dialogues and thus might remain unaware of the AI's power boost until it's too late.

After a number of iterations, we settled on a combination of four adjustments:

• Giving the AI only one power plant (other than the ones powering factories) versus the player's two.
  
• Having the player start in a hard to reach location.
  
• Painting the player's buildings yellow so the AI can 'think' that there is no enemy nearby for the first couple of turns.
  
• And giving the AI a good defensive base close to where the player starts.

At this point we've already moved quite far from the simple and straightforward mission we started out with. But we do have a solid mission that's fun to play.

Do factories conduct power? An easy question, since all buildings in Powargrid conduct power, so why not factories? Well, we found that it looks strange when the AI builds in a spot that only touches a factory. As a player you get the feeling that the AI is cheating when it does that. Michiel had to do some retooling on a basic level for the buildings to add the possibility to not conduct power. This is not complex or hard to do, but it is another one of those things that we did not foresee in the mission concept, yet do take extra time.

In some missions, you know beforehand that getting the dialogues right will involve more work than 'just' writing them and then slapping on some triggers so they get displayed at the right moment. When I started writing the dialogues for this mission, I thought they'd be pretty straightforward. Some mission explanation, some background, some banter and an explanation for each of the five factories. Easy enough, right?

But then I realized there was a catch. The best moment to explain what each factory does is when it stops working, which happens either when it's destroyed (duh) or when its power plant is destroyed. But these situations are different enough that, in my opinion, they can't be covered by the same dialogue without making the writing too contrived.
What happens if multiple factories are destroyed at the same time? The simple thing is having the dialogues pop up one after the other, but that makes the dialogues feel disconnected. The way-too-much work option is to write a separate dialogue for each possible combination of factories.
And what if a factory is the last factory to be destroyed? That calls for yet another different dialogue for each factory. And that's before differentiating between whether or not the yellow blobbies still has power plants up when you blow up the last factory.
And...

So much for 'easy enough'. We tried multiple approaches to find a spot where dialogues feel right and the amount of work is less than ludicrous :). As an example, having the dialogues trigger at set moments during the mission, irrespective of whether or not a factory is still in operation, felt way too tacked on. On the other end of the spectrum, writing dialogues for every possible scenario is out of the question because of the sheer number of possibilities. Eventually we settled for a dynamic system that triggers whenever a factory is destroyed and can also handle multiple destroyed factories at once. Unfortunately that does take some retooling of our dialogue system (and thus more time), but by now I think it's clear that's not an uncommon price to pay. This is now at the top of our to do list.

There are a couple of things in this mission our AI is ill equipped to deal with. Since this blog post is already very long, I'll mention one. Our AI has a defense routine which usually works fine, but which is inefficient for power plants not at the edge of the game grid. The AI builds a lot of power lines to claim territory, even though a single power line in a strategic spot would also do the trick. The simple fix (or perhaps workaround would be a better word) in this case was to add power lines in those strategic spots. But if that hadn't been possible or if we'd wanted a more basic and universal solution, we'd have had to (re)write a large amount of AI code. So even though we got off light there, this could easily have been another big issue we hadn't foreseen when we first designed this mission*.

So even though Powargrid is a relatively simple game (to learn, though not to master) with a small number of clearly defined rules, we still run into many issues that complicate design and take up a lot of time. And what I've shared here is only what we encountered in one of the fifteen missions for the campaign. And the complexities and time sinks multiply quickly the bigger and more elaborate your game becomes. so in my opinion, Chris' advice to start with a modest first project is very good indeed!

-Willem-

PS; I shall now spam the obligatory links:

• Play the Powargrid alpha here.
• We'd love your support on Steam Greenlight.

* And we're not done yet with this mission. Among other things, we still need to decide whether the AI needs to defend the factories in a more active manner. But luckily, that's a simple thing and implementing it will hardly take any time at all, I'm sure ;).

Michiel told you about the development of our Skirmish AI here and here. In this post, I'll take a look from a higher vantage point. Climbing an actual space elevator would help me do that, but with a distinct lack of such devices on this little planet of ours, I'll have take that look in a non-literal way.

In "The Science of Discworld", Terry Pratchett, Ian Stewart and Jack Cohen used the space elevator* as an analogy for any process or technology that lifts a system to a new level of operation. So in that vein, the printing press, the internet and RNA are all space elevators. Being big Pratchett fans, this added use for the term space elevator stuck with Michiel and me.

So why is our Skirmish AI a space elevator in that sense? It started out as a nice first experiment in building an AI that could play Powargrid at a basic level. But since working on an AI is fun**, we happily kept adding bits of logic to it. And at one point the Skirmish AI became a computer opponent that was no longer trivial to beat, which was cool. It was at this point that we developed what you could call a Powargrid sub-hobby: watching AI versus AI matches on a skirmish map. This is also what inspired us to have an AI battle as the background for the main menu in Powargrid.

Before we got to the point where the Skirmish AI became good, we'd been working on the first three missions of the campaign. Each of those missions had a simple AI to take care of the enemy turns, so they were playable in a rudimentary way. But with our new best friend the Skirmish AI, I could suddenly drop an actual opponent into any level I designed. So I could simply think of an interesting layout for the game grid, combine it with a setup for the player and enemy bases that I thought would provide a nice challenge and then immediately test it.

And believe you me when I say that's a big step up from thinking of a mission in my head, sketching it out on paper and then asking Michiel to painstakingly code it into reality before testing whether the mission is actually any fun. This was certainly a new level of operation for mission design, so we feel that our Skirmish AI qualifies as a space elevator in the Pratchett-Stewart-Cohen sense of the word :).

Some of those missions are already in our playable alpha and others are lined up for use in later missions. And we have more mission concepts we think are fun to play, but we had to pick and choose in order to keep the campaign at an interesting length (and to be able to ever to finish this game ;).

For most missions, we do write a subclass for the AI, to handle specific aspects like Swap attacking the dam in 'Dam It' and Ford attacking the temple wall in 'Welcome to the Jungle'. An interesting case came up in 'Piece of Paradise', where you have two opponents in one team. Since team members can't damage each other's buildings, there is a possibility that one AI blocks the other. This takes the fun out of the mission, so we had to prevent that from happening. The best approach from a level design standpoint turned out to be simply have each AI leave a path for the other AI. I defined a this path but then found out that I couldn't feed a set of forbidden tiles into our pathfinder. So I called in Michiel's help and we ended up changing the Skirmish AI to accommodate these forbidden tiles. We usually shy away from changing the Skirmish AI, but it was clearly the best way to implement this. The change is also general enough that we may use it in more missions.

The reason we shy away from changing things in the Skirmish AI is that it may affect other missions. We're quite happy with the difficulty level of the campaign, and we wouldn't want to throw it off balance by further optimizations to the AI. By now, we only change the Skirmish AI if we're sure it won't get any meaner or if it behaves stupid or silly in a non-human way. We'll probably have to branch the Skirmish AI in the future, since there are certainly things we'd still like to improve. A really nice improvement would be to teach the AI to be smarter about claiming territory by making use of bottlenecks in the play field, but that's going to be a tough nut to crack.

The last thing I'd like to say about this subject (for now) is that we plan to create an interface through which you can build your own Powargrid AI. We think it's huge fun to do so. It's not too hard to build an AI that plays the game in a (semi) sensible manner and seeing it get better with every tweak keeps you hungry for more improvements. The only risk I see is that if others do build AIs for Powargrid, the time Michiel and I spend just watching AI battles will see a significant increase. Which would eat into Powargrid development time. But I think that's a risk we're willing to take ;).

Well, that was that. We hope you enjoyed our little series on AI building. I think we'll have more to say on this subject in the future. In the meantime, be sure to let us know if you'd like to know more!

- Willem -

* A space elevator is a really interesting concept that would make bringing stuff up into space orders of magnitude cheaper than it is now (in energy and likely also in money).
** We once participated in an AI building contest for Open TTD, where we built a very mean AI together with our good friends Otto and Marnix.

Just a quick test to see if this shows up both on Twitter and our new Facebook page. Also, have a picture of the mission we're currently working on!

Welcome back to our series (part 1 here) on building the Powargrid AI! Michiel here again, and this time I'll look at the general tactics the AI uses. Our generic AI quickly became known as the "skirmish" AI, since it should be able to play a nice game of Powargrid on the skirmish maps. No mess, no fuss - just you against them, in a no-holds-barred fight to the last power plant.

We also created several specialized AIs for the various campaign missions, and Willem will tell you more about those in the next part of the series.

I already mentioned the basic steps the AI goes through:

• defend its own power plants
• advance towards the opponent
• attack whatever is in its way
• finally, blow up the opponent's power plants

Every turn, it'll loop through these and decide what to do. There's a few simple knobs we can tweak to influence how aggressive or defensive it is. For example, a defensive AI will defend first, then, if it has any power left over, it will attack. An offensive AI will do things the other way around.

This core logic has stayed mostly unchanged, but we've tweaked the internals of each step over a period of several months, slowly making it smarter and meaner. At first, we had to give the AI a large head start (starting it off with more power plants than the player) but as it improved, we were having a hard time keeping up! Now,the AI will give you a good fight even if evenly matched. Three power plants against your two is hard, and we've not been able to beat the current version if you give it four power plants. There's a setting to give it five, if you're feeling particularly brave ;-)

After going through its main loop, there's some housekeeping to be done: maybe it should build another power plant, or build some substations to store any leftover power.

What to attack? Where to build a new power plant? Which weapons to charge? Those are all decisions the AI has to make. We've decided on a simple approach for all of these: make a list of things, then assign them a score based on how good they are.

For example, if we're figuring out which weapons to charge:

• Can it hit a power plant? +1000 points! Does that power plant only have one hitpoint left? Add another 1000!
• Is it in our way, according to our pathfinding? That's 150 points.
• Is it a weapon? Can it hit one of our power plants? 200 points. It can't? Still scary, 10 points.
• Anything else? Well OK, have 5 points for being the wrong colour.

Then, just sort everything by their total score, and work your way down the list, charging each weapon which has more than the minimum score (or we run out of power).

One of the moves in the game, overcharging your power plants, had us pondering for a while. Overcharge, in case you haven't played the game yet (why not? go ahead, I'll wait!), boosts a power plant's output, but also damages it each turn, and you can't turn it off, so it's a a choice not to make lightly.

The AI will use it in two cases: defensively, if it's about to lose a power plant, it'll overcharge it to get some extra juice out of it. Offensively, it will overcharge a power plant only if it has more power plants than the opponent, and it could reach a strategically valuable tile but doesn't quite have enough power to get there. Again, simple rules, but the AI still manages to surprise us with a sudden charge every now and then.

A* is great, but it is a deterministic algorithm: if you give it the same inputs, it'll give you the same results every time. In a game, this is generally not what you want. Especially in a grid based game, it's very obvious: even though "up, up, right" is equivalent to "right, up, up" and "up, right, up" in terms of getting where you want to go, the AI would have a fixed preference for one option.

To remedy that, we add a small random amount to every cost we calculate for A*. Not enough to make it choose a suboptimal path, but just random enough so that it'll make slightly different choices every time. And the effect is huge: if you look at the red and blue AIs fighting each other behind the main menu (tip: press F10 to hide the menu for a better look at the action), you'll notice that no two games are the same. In fact, we've been unable to predict which one will win, even though they are both running the same algorithms in every game they play! All because of a tiny, tiny bit of randomness.

The difference between the AI and a human is still quite visible, though. The AI is very good at math but lacks the high level overview a human player has. It doesn't see "obvious" moves where a single power line would block off and defend a large section of the board, for example. It also doesn't realize that if it had built a tower one tile away, it would be able to hit two targets at once. On the other hand, I regularly have it happen to me that I think it's left me an opening, I rush forward, and it turns out I don't have enough power to actually get there. Which it already knew, of course.

So after a while, we had built a pretty decent, generic AI - put it on the field and it'll come for you! However, the campaign missions need a bit more flavour than just having differently coloured pieces rushing at you headlong, so each campaign mission is additionally scripted to make your opponents more interesting. As you play the campaign, you may notice the first couple of moves are always the same. That's the first couple of turns of the mission script being run. You can't really call that AI - it's just us deciding what we want it to do, specifically.

In addition, the AI needs to know about mission objectives. For example, in the "Dam It!" mission, it'll only attack the dam, not your power plants. In "Welcome to the Jungle", the red blobbies are trying to blast their way into some ancient ruins, while trying to keep you out of their valley, and you'll have to learn some new tricks to make it there in time!

However, in later missions, once the game's afoot, we can generally just check for some specific conditions, and then just turn it over to the generic AI. This also allows us to quickly test out missions. After designing the initial layout of the grid, we can just throw in one or more AIs and quickly get a feel for how it'll play. Willem would like to tell you more about that process, so I'll leave that to him, in a future blog post!

Hi there! Michiel here, with the first post in a short series on the Powargrid AI (Artificial Intelligence) - the algorithms that control the computer players.

The AI is what you'll be playing against in the single player campaign and the skirmish mode.

In this first post, I'll give you a quick overview, and then wander off (if you'll pardon the pun) into pathfinding.

So what's the goal of an AI? At first glance, it seems simple enough - it should play Powargrid, and try to win! However, an AI that's mercilessly good is actually not what you want in a game. The ultimate goal is to make sure the player has fun playing against it!

Our plan was to throw a simple "placeholder" AI together, then figure out how to do it properly. What actually happened was that we just kept improving that initial prototype. We'd sit back with a beer and figure out what rules, tactics, patterns and heuristics we'd been using when playing ourselves, then try to teach them to the computer.

The basic behaviours are pretty simple:

• defend your own power plants
• advance towards the opponent
• attack whatever is in your way
• finally, blow up their power plants

Before you can shoot something, though, you need to get in range, and that's what I want to talk about in this first post: pathfinding.

Pathfinding is figuring out how to get from A to B. In Powargrid, A is usually wherever your buildings are, and B is the spots where you can shoot at those juicy, juicy powerplants of your opponent. People are great at pathfinding - we can take one look at a game board and see exactly where to go thanks to our massively parallel visual system.

Unfortunately, a computer is basically looking at the board through a tube that's one tile across. Suddenly, just figuring out where to go is hard - try it!

The granddaddy of pathfinding is an algorithm called A* (A-star). It's one of my favourite algorithms! I'll try (and fail) to be brief, since there's loads of good reading already available online. Amit Patel of Red Blob Games has an awesome series on pathfinding in general and A* in particular. It's a must read for anyone in game dev, and there's much more great stuff there!

I'll try to sum up A* in a few sentences, though, and how it applies to Powargrid.

A* works on any grid - it just needs to be told which points are connected to which others. In Powargrid, that's just the tiles of the playfield and their neighbours.

To find a path, you give it a list of tiles you want to go, and which tiles to start from. If we're trying to attack another player, we can start from any tile we already built on, and we're looking to reach any tile from which we can shoot at their power plants.

Then, for every tile it currently knows, A* looks at its neighbours and estimates how far each might be from the goal. In our case, that estimate is easy! It's just how many tiles the target is away, horizontally and vertically (this is called the Manhattan distance because it's like measuring distance in city blocks). It then continues finding a path by looking at the best estimates first, which makes it much faster than just looking at everything. And it still guarantees you it'll find the shortest possible path!

However, you can't always take the shortest path. In Powargrid, enemy pieces will block the way, and the grid is not always a neat rectangle.

To find the best path, you tell A* the cost of traveling from one tile to another. This is where the wonderful versatility of the algorithm comes from: you can make up any cost you like, and define what the "best path" actually means.

In Powargrid, we tell A* your own tiles are cheap - you already own them! Empty tiles are a little more expensive, since you'll have to spend power to actually build something on them. Tiles occupied by an opponent are much more expensive, because you'll have to build and charge weapons to blast through them. The costs are 1 point for your own tiles, 3 for empty tiles, and 20 for enemy tiles. That means the AI will make a 7 tile detour if it can avoid going through one of your buildings.

These simple rules will make the AI build around your buildings, unless the path gets too long. Then it'll just plop down a tower and shoot you inna face.

Defending also uses pathfinding, but the other way around: the AI knows how much power you'll have next turn, and figures out where you'll be able to go. If that includes places where it would like you not to be, it'll claim those tiles itself.

That "short detour into pathfinding" I had in mind actually turned out rather longer than I expected. I'll end part 1 here, and continue the story in the next part. See you soon!

The Powargrid campaign contains quite a lot of dialogue, so it's about time for a blog post about that. Nearly all of the dialogues were written by me (Willem), but Michiel and I have discussed them a lot. Part of that discussion is about language and wording, but we often also talk about the amount of dialogue in there. Michiel is worried that there may be too much dialogue for (as far as I know) two reasons. First off, there are lots of players who don't read dialogues and don't want to be bothered by them either. Secondly, writing dialogue takes time and building a good game is already such an incredible amount of work that we should be reluctant to add to that.

We still disagree on the second point. For now, I'll just keep on spewing out more concept-dialogue until all the missions are covered. The good news is that I have at least a rough outline for each mission now. We'll still have the occasional 'OMG, we're making a game, not writing a book' versus 'if you want me to write less, it will take me even more time' discussion, but I firmly believe this is one of the things that makes Powargrid a much better game in the end. As an aside: this is somewhat unusual, since Michiel and I usually find common ground quite quickly if we have a disagreement. Our discussions usually amount to something like this: 'I think X.' 'Oh, I think !X.' 'Ah, well I really think X.' 'OK, but can't we make it explode and then go for !X?' 'Sure, if it's a really satisfying explosion, !X it is.'

On the first point, that dialogue shouldn't get in the way of players who don't want to read it, we agreed from the outset. This led me to condensing the dialogues as much as possible, which actually led to them becoming better*. And that worked, since we've gotten quite a lot of positive feedback, but it wasn't enough. Luckily, the solution turned out to be simpler than we'd thought (and pretty obvious in hindsight). I'd already written the dialogues in such a way that the shortest route through them became somewhat clear from the text of the reply, but that was way too easy to miss. Michiel eventually suggested to add a little text balloon to the dialogues with '...' in the balloon that carries you more dialogue and 'X' in the balloon that gets you back into the game.

Another thing I've made sure of is that you can get out of most dialogues in one click, with the exceptions being mostly the dialogues that explain game mechanics or other important stuff like mission objectives. While the text balloons help to guide players through the dialogues they don't want to read, they do nothing to get them to read the few dialogues we do want them to read. So we added two different markers to the dialogues. One is a black and yellow border for dialogue nodes that are important to read and the other is highlighted text for the essential bits in those nodes. That way even people who don't like to read dialogue can't miss the game mechanics and the mission objectives. Or almost everybody. Our good friend Marnix would rather spend an hour cursing that 'this stupid WoW quest is broken!' than spend three minutes reading the quest text. Why would you even want to know you have to use your Gnomish demorphification ray on those froggified dwarves when you can brutally murder them (and then skin them) as they're happily croaking the song of their people?** But for others, those simple adjustments made quite the difference.

We also have future work planned on the dialogues, besides finishing and polishing them. We'd like to make sure that the choices you make in the campaign feel relevant. The missions in Powargrid don't lend themselves very well to branching storylines (and neither does our limited time for that matter), but we can make sure that dialogue choices made in one mission are referred to later in the campaign. The technical term here is the feeling of agency. For a good explanation on how this works in games, I recommend you watch this excellent episode of Extra Credits.

That just about sums up what I wanted to tell you about the dialogues in Powargrid. I could go into the storylines they weave, but that will have to wait for a future blog post.

-Willem-

* I feel a disclaimer is in order here: the dialogues beyond the fifth mission need some more work and mission 8, currently the last one playable in the demo, needs an extensive overhaul. I'm not one to be quickly satisfied with what I've written.
** Totally made-up WoW quest example. It's been a while since I last was in Azeroth :).

With Powargrid, we're aiming to create a game that is easy to learn and hard to master. We've tackled the easy to learn part by using as few game rules as we can and by keeping the number of building types as low as possible. We started out with only power lines, power plants and towers, but with only those, we didn't achieve the level of emergent complexity we were aiming for. So we added substations (formerly known as power storages) and lightning cannons to add a few extra possibilities and a lot of complexity in decision-making. Having as few buildings as possible has forced us to make sure our game mechanics work really well. And I must say that I'm very content with how they turned out.

However, a disadvantage of having only five building types lies in designing the campaign for Powargrid. An easy way to spice up a campaign is by introducing new units and such. That way each level or mission feels new and different. With this being a very limited option for us, we've had to find other ways of keeping things interesting. For instance by playing with the shape of the game grid and varying the starting setup for both the player and the AI. I'll look deeper into level design in a future blog post, but for now it's enough to know that this restriction has forced me to tap all the creativity I could muster.

So, does that mean we won't add any new buildings to Powargrid? Well, yes and no. We won't add any new buildings to the game as we're building it now (campaign, skirmish and multiplayer). However, we do have more than enough ideas for new types of buildings. So it's entirely possible that we'll add new buildings after we release the game. The buildings you can use should then be customizable per fight, so you can decide which buildings you and your opponent will have access to.

But for now, we'll leave it at the five buildings we have. Heck, this game is hard enough to finish even with only those ;).