Last Wednesday, we were invited to demo Powargrid at the monthly Dutch Game Garden networking lunch. It's a fun event where you can showcase your game and chat with fellow game developers!
We've been there a couple times before, and it's always fun to showcase our game! This time, we mostly had a chat with a few fellow devs, visited Game Drive (who helped us market our game) at their new office and left with plenty of food for thought about how to present our game, for example on our Steam store page.
That's us talking to Bram from Game Drive, and Bas from Abbey Games who gave us some good advice. Once again I am reminded we are not big dudes :p
Thanks again to DGG for inviting us, and to those present for the fun atmosphere, pleasant conversation and new insights!
Quick! How much is 3 times 28? Or in Powargrid terms: do you have enough juice to double charge this tower?
We realized, again as we were watching people play our game, that we make you do a lot of mental math. Now, Powargrid is not supposed to be easy, but it's definitely not meant to be a chore! Last time I heard, computers were pretty good at math, so let us help you out by having them do some for you :)
Yep, the tool tip now tells you how much a double charge will cost, and it'll light up in red if you don't have enough. You're welcome, and sorry it took this long!
Hi, Michiel here! After watching a few videos of people playing Powargrid, I noticed that they were often looking for a place they could place a certain building, moving the mouse around until they found a good spot where they could afford to build it. I've been working on this game so long, I mostly just know without even thinking about it -- so that was a good wakeup call that something could be improved there.
I'm now trying out a little visual aid, by highlighting the tiles you can build on and "lowlighting" (is that a word? de-emphasizing!) invalid tiles.
For me, it's REALLY weird to change anything to the core visuals after staring at them for years -- but I think this is going to be an improvement!
I've just set the new build live on Steam, so everyone should be receiving the new version shortly. Tell us what you think!
Welcome to part 4 of our series about the AI scripting interface, that lets you program your own Powargrid AI in Lua!
This time, I'd like to talk about some of the implementation details of our AI scripting framework. If you just want to write your own AI, you don't need to know about any of this! Still, I'm sure some folks will find it interesting :)
Our game is made in Unity, which gave us several options to embed a scripting language. We went with MoonSharp, for a few reasons:
Playing against someone else's AI means running their code on your computer. We have to ensure that it's safe to do so: we don't want an AI to give someone else access to your computer, to delete your files, or in fact even look at them. That's why the AI scripts run in a secure environment, called a sandbox.
The sandbox strictly limits the files an AI script can access: you can use the "require" function to load additional modules, but you can only load Lua files, and only from two places: the AI's own directory, and the Shared directory that contains utility modules you may want to share between different AIs, like our ailib module.
We also limit the built-in Lua modules you can use. For example, you can have math, string and table, but not os, the interface to the operating system.
Threading and command queue
We had several requirements for the AI framework:
To make that happen, each AI script gets its own Lua interpreter and runs in a separate thread.
Multithreading is hard, especially when you're trying to share data between threads - so we don't, or at least, we share the absolute minimum.
When it's the AI's turn, the framework takes a snapshot of the current game state: how much power does each player have, what buildings are on the board, how many charges does each weapon have, etc.
If the AI calls a function that just returns information about the game state, this is answered based on the snapshot. Since Powargrid is a turn based game, nothing can change until the current player makes a move.
When an AI calls a function to change the game — for example, placing a building — the AI thread enqueues this command and on the next frame, the AI framework, running on the main thread, picks up the command, tries to execute the action, puts the result (whether it was built or not) on the response queue, and takes a new snapshot. The AI thread that was blocking on the response queue picks up the response and returns that to the Lua script as the result of the "build" command, and the AI can continue.
Tomorrow, October 5th, we're launching Powargrid after more than 5 years of working on it. We've talked about that process before here on the blog, but today I found myself just mulling over the idea of making things.
Because, strange as it may sound, I'm really excited by the fact that we've made something that wouldn't have existed if we hadn't made it. Obvious? Yes. But that doesn't make it any less true for me :). If all goes well, starting tomorrow, people will buy, play and enjoy our game. And that's just amazing.
Anyway, we're really looking forward to the launch tomorrow. We're also very curious (and a little terrified) to hear what people think about it. We'll share any reviews, let's plays and other coverage through our Twitter account (@weefreestudio).
- Willem -
PS: just in case you haven't seen our Steam store page yet, here's a link :)
Welcome to part 3 in the series on our AI scripting framework! See part 1 for the introduction and part 2 for a short description of the debugging tools.
This time, we'll look into the functions you can use to interact with the game. The technical term for this is the "API": the Application Programming Interface. Or in this case, maybe it's an AI Programming Interface!
The API defines the functions your code can call do to get information about the current game, and to perform game actions like building things and charging weapons.
Your AI script has access to two global objects with useful functions: Game and Debug. Debug just lets you write stuff to the console. The Game object is what lets you see and manipulate the game grid. It has functions to look at the current game state, like GetMyPower(), GetPiece(x, y), GetHitPoints(x, y), and functions to take actions: Build(piece, x, y, direction) and Charge(x, y).
Of course, those are very low level functions, and to make your life easier, we include several modules with useful functions, including an A* pathfinding implementation for navigating the grid. These are written in Lua, so you can look at the source code and copy/modify/reuse whatever you like! In ailib.lua, you'll find higher level function like ailib.findPieces(pieceType, player),ailib.canHitFrom(tile, withTower, withCannon, cannonDirection) and ailib.getBuildCost(pieceType, tile).
There are many ways to figure out where to go on the grid and how to get there, but you'll probably want some sort of pathfinding algorithm, and A* is great! It's my favourite algorithm. My wife thinks it's strange that I even HAVE a favourite algorithm, but hey, that's what she gets for marrying a nerd :)
If you want to know more about pathfinding in general and how we used it to create the built-in skirmish AI, check out this blog post: http://www.powargrid.com/blog/powargrid-ai-part-1-intro-and-pathfinding.
Documentation and example AI
You can find the descriptions for the Game and Debug modules, as well as the Lua utility modules, in the API documentation. If you're not sure how to use a particular function, see how the Daft Wullie example AI uses them. Still stuck? Ask us on the forum or our Steam community hub, we're happy to help!
In the next installment we'll take a look under the hood of the AI framework.
The previous post introduced the Lua scripting framework that lets you program your own Powargrid AI. Now, I'd like to show you the debugging tools we're providing you with. Nobody said this was going to be easy, but we're not sending you in without a little help!
You can edit your AI in whatever text editor you like. I like Sublime Text, but the choice is yours! Just get yourself something that has a bit more features than plain ol' Notepad :)
It's the most basic method of debugging, but it's never let me down: print stuff to the screen. Your AI can write messages to the AI debug console, which is visible if you've checked the "Enable dev tools" box in the Add-ons menu. Simple "print" statements will go there. If you want to get fancy, you can use the Debug.info, Debug.warning and Debug.error functions to write text in different colors according to how urgent a message is.
Another important feature is the reload button: you can edit and reload your AI scripts whenever you want, and the changes will take effect on the next turn.
We use the MoonSharp Lua interpreter to run user AI scripts. It comes with a pretty decent debugger, which runs in your browser. To open the debugger, hit the "Open debugger" button in the AI console. Your browser should open automatically - if not, just browse to http://127.0.0.1:2705/. The debugger will pause your script at the start of the turn() function, and you can step through the code, set breakpoints and watch variables.
Now how do you actually interact with the game? Build stuff and blow things up? We'll cover that in the next post!
We recently added a feature to Powargrid we are very excited about: a framework/interface that allows you to program your own AI to pit against yourself, your friends, and other AIs!
User AIs are written in the Lua programming language, a very popular programming language for scripting and modding games. Famous examples include Civilization V and World of Warcraft.
Add-ons (just user AIs for now, but maybe we'll add custom maps later!) are loaded from the Addons directory, but you have to enable this first. To enable add-ons, go to the Settings menu, select Add-ons, and check the "Enable add-ons" box. This lets you run AIs you've put in the add-ons directory. If you want to write your own AI, also check the "Enable dev tools" box. This enables the debugging console in skirmish games with user AIs.
There's a button to open the directory in a file browser; it's located at .../path/to/Powargrid/Add-ons/AI. Inside you'll find a directory containing "Daft Wullie", our example AI. It's named after a Discworld character, because we are both huge Terry Pratchett fans :)
The next posts will discuss the debugging tools we've included to help you write your own AI, the functions you have available to do so, and a bit about the technology behind the user AI framework, for those that like to take a look under the hood. Stay tuned!
Do you like The Daily Blobbie? Now you can make your own!
Yes, Mr. Swap, they can! Just go to The Blobbie Meme Maker, pick your blobbie picture, and enter your text! Comes with buttons for easy sharing! We're looking forward to seeing what you can come up with. We'll feature our favourites on our Twitter feed :)
It's no secret that we've been building this game for a long time. For over five years in fact. And during that time, we've had to learn loads of new things. One of those things was learn how to draw characters that were acceptable for Powargrid. Since I was well aware of my artistic limitations, I decided that the main characters would be blobbies. Blobbies with one eye to be exact, so drawing them (without taking forever) would lie within the realm of the possible for me. The first iterations of Commander Grak looked like this:
I was thinking along the lines of amoeba, and I also figured that I'd need variability in form to be able to convey emotions. But this didn't work well enough, so eventually we settled for a more defined (though not more solid) shape. Turns out that you can convey a lot of information about how a blobbie feels with just an eye, a mouth and an eyebrow.
Once we got to that shape, I thought it was just a matter of drawing a picture for every dialogue node. How naive of me! Over time, as I drew hundreds of blobbie pictures, I actually got better at it. Or, to be more precise, I learned a couple of things. First off, we humans are really, really good at detecting where someone is looking. We notice the tiniest fractions when it comes to how the iris and pupil are placed compared to the white of an eye.
I also found that dialogue pictures work best if the blobbie is looking straight at you, except when there is a good reason to look some place else. Down if they're ashamed or up if they're exasperated for instance. In the earlier pictures I made, I wasn't very precise in these placements, so it felt like the blobbies were telling you things without really being interested in you. And even though this would probably be in character for most of the blobbies you'll encounter in Powargrid, it works counter to drawing the player into the story. So this had to change.
Second, what I realised early on for the body shapes is something I didn't realise for the mouths and especially the eyes until a lot later. I purposely started out with eyes that weren't perfect spheres. That just didn't feel right for the blobbies. And that is still true. Using perfect spheres makes them lose a bit of their organic-ness. But making the shapes much smoother than I did looks much better. So the mouths and especially in the later drawings are better than in he earlier ones.
In all, the differences are subtle, until you look closely. Once you see it, the difference is glaringly obvious. Or perhaps I'm developing a rudimentary artist's eye ;). Some examples:
This was especially true for the first mission of the campaign; eventually it stood out to me like a sore thumb. And that mission is the first thing people see of the blobbies, and often of Powargrid (there are also people who dive straight into skirmish battles, but most play at least part of the campaign first). So this had to change. And today, finally, I got around to remaking those pictures. And I'm happy with the result! Here's the first thing you see when you start the first mission of the campaign:
I mean, I know I'm still no Michaelangelo, but that's part of the limitations I have to work with :). But the new Commander Grak image offers much more connection when you're reading the dialogues, and that's what I'm aiming for.
And there is one more thing I'd like to share. We decided quite some time ago to separate the blobbies from the backgrounds. The reason for that was so that we could change the backgrounds without redoing all the pictures. And the backgrounds have become much better over time. In hindsight, we probably should have made the blobbies themselves modular as well. That way, we could have built up each blobbie from a base body shape, paraphernalia such as hats and decorations, an eye and a mouth. In which case I would have just had to improve the base ingredients and every blobbie picture would have become better. But as I said at the start of this post, we've had to learn a lot. Apparently this was one of the things on my list.
Happy gaming :)
We're Michiel and Willem. Hi!