​What exactly does it take to draw one screenful of Powargrid? Quite a lot actually, which is why I've been working on making it faster. To make the game run smoothly, we would like to redraw the screen 60 times per second. A screen redraw is also called a "frame", so it's often referred to as "60 fps". Most monitors only update 60 times per second, so faster than that doesn't really buy you anything.

Simplifying a little (well... a lot), drawing the screen involves sending the geometry of everything in the scene to the graphics card, then telling it how to colour in the bits.

This involves your CPU repeatedly telling your graphics card, "take this can of paint and paint that wall." Now this is magic cartoon paint: you can have plain coloured paint, checkerboard paint, grass-and-flowers paint, and it can be dull paint, glossy paint, transparent paint, etc. In computer graphics, it's called a "material".

Each of these instructions to draw something using a particular material is a "draw call". Now, the graphics card is a very, very fast painter, but each draw call (changing paint cans) involves a noticeable amount of work. In short, it's much faster to paint many walls with the same paint (material) than it is to change cans for every wall.

In the beginning, we were painting every object on the screen with its own can of paint. That's not just each building - each building consists of at least four legs and a body. Even though all the legs of a building have the same colour, they still got their own can of paint, so we were quickly up to thousands of draw calls, making the game run quite slowly unless you had a fast CPU. In the meantime, the graphics card was sitting there, waiting for the CPU to hand it more paint cans.

The first step we took was to redo our models and make sure all the matching bits (like the legs) actually share a single material. Then, Unity can use dynamic batching to draw all the blue bits with the same paint can (one single draw call). Then, all the red bits get drawn in one go, etc. Big win!

However, then we wanted to use shadows, because shadows look neat. In our case, with a single light (the sun) casting shadows, everything needs to be drawn twice: once from the viewpoint of the sun, to know which parts of the scene are in shadow, and then from the viewpoint of the camera.
​Unfortunately, with dozens of buildings on the play field, all consisting of several pieces, rendering shadows for all those little bits meant it was still too slow. We couldn't just rely on Unity combining the draw calls for us. We needed to draw less things! We don't actually have to leave anything out, because graphics cards are so fast these days. We just need to draw bigger chunks at a time.

​So that's what we do now: we take all the bits that make up the game grid, and combine them into larger parts that share the same material. For example, all the powered red legs get combined into one big "everything that's bright red" object.

​When something changes (say, a building gets blown up) we quickly rebuild the combined mesh to take the changes into account. Some details were a bit tricky, and I was occasionally looking at "the ghost of buildings past" because something had been destroyed but was still in the combined mesh, or stuff would turn invisible for a fraction of a second as the mesh was rebuilt. However, in the end it was only about 200 lines of code, and the results are nothing to sneeze at:

​And that's just a simple scene, at the start of the first campaign mission. Without combining objects, the CPU had to make 574 draw calls, even though 733 were prevented by dynamic batching. With combining, the exact same scene takes only 179 draw calls!

So there you have it. Powargrid should run a whole lot smoother, with nice shadows, even if you don't have a very fast PC. Enjoy!

-- Michiel

As promised, here's a blog post about a little side project: Pirate Game. Arrrr!

Last summer, my son (five at the time) wanted to design a game together with me. I wasted no time in saying yes and we started immediately. He wanted the game to be about pirates and finding treasure. What I wanted was a game that could be played by my kids that was not entirely about luck and / or memory. In my experience many games for that age group use those two mechanics predominantly or even exclusively and I wanted something that at least feels like it has a little more strategy in it. But my daughter was three then and I wanted it to be possible for her to play as well. So the strategy had to be semi-optional. Or, in other words, doing sort of random stuff had to be a valid strategy even though it wasn't optimal.

What I settled on was to add freedom of movement to the game, which automatically adds some strategic considerations and meaningful choices. We made a square grid with water and islands. For every island, there is a card with either a treasure, a key, a shovel or nothing on it. Those cards are shuffled and distributed randomly around the islands. The players start in the corners and can sail their ships 1d6 tiles. Sailing around can be done in all eight directions, but accessing land is only possible in four directions (the diagonals are excluded).

​For the kids, the advantages of moving diagonally aren't immediately obvious. Realising what the best way is to sail across the map, with the added constraint that you may have only a few tiles you can move, was the small piece of strategy I was looking for. There are other strategies, such as trying to block your opponent and not accessing land if you no longer need to, but those are a bit more difficult to find out :).

You win the game when you access the land tile where the treasure is, but only if you have a shovel and a key. If not, the treasure is still revealed, so everyone knows where to go to end the game. If you find a key while you already have one, it also stays in place so others can go and grab it. These mechanics also ensure that the game automatically works toward a conclusion. On the one hand this is seems quite obvious, but on the other this is a really important part of game design, especially when designing board games.

My son loved the game and so did my my daughter, who was able to play along with a little help. So I considered the game a success :).

​Then, late last year, after the busy weeks and moths of the Powargrid release, I decided I wanted to work on my programming skills. So I set off to program the basics of this game in Unity3D (working in C#). Since you need to name your project, the working title became Pirate Game. Which is not very imaginative, but gets the job done. Also, if I postpone the start of a project until I've thought of a name I think is good enough, it's quite probable I'm never going to start the project at all :P.

Building something that looked something like the board game we designed (or at least enough so that my family recognised it) didn't take very long. And not too long after that, I had a very basic playable game. But, as it goes with things like this, there is always something extra to add. At one point, I realized I wanted to do more than just practice programming. I decided to make Pirate Game into a small but full game. So I added things like a menu scene, settings, multiple map sizes, sounds and AI players. Eventually, I had a fully functional build of Pirate Game that I could share with my friends. Programming is fun, especially if you manage to finish something :).

Here are a few gameplay examples. The picture above shows the standard size of the playfield, which is the same size as the board game version was. But I also added some other sizes, as you can see below. The playfield itself is randomly generated every time you play. There is also a reload button in case you don't like the look of the generated map. There are a couple of restrictions to make sure the field is playable, but the map should be different every time you play.

I created the graphics myself, more with expedience than prize winning artwork in mind (but you probably already noticed that). Same for the sounds, but worse :P. But everything together does get the job done. So much so that my kids really love to play this digital version of Pirate Game. I even got a feature request from my son and his best friend: they want co-op mode.

So, of course, I'm going to add that. What's more, somewhere in the near future, Michiel and I will clean up Pirate Game some more and make it available on itch.io for 'pay what you want, starting at free'. Since we both have about a 1000 more things we want to do than we have time for, I'm not certain how many features we'll add, but we're thinking of the following:
- co-op mode (duh)
- better graphics
- better sound (we're already talking to a sound designer about this)
- improved visuals for the menu scene and other UI elements
- multiplayer over network
- improved map generation algorithm (islands don't branch at the moment for instance)
- correct scaling for all screen sizes

And, very importantly, we'll need to think of a name. Which may be the hardest part :). So if you have any suggestions, family friendly suggestions that is, don't hesitate to let us know!


- Willem -


PS; since this week, we also have a professional testing crew for Pirate Game:

:D

​Look what I found! The old 2D Java prototype still compiles and runs :-)
I dare to claim we've come quite a long way since then! We even named it :-P
At this rate, we'll be done... well, maybe even before the next century!

In the previous blog post, I wrote about ideas that (seem to) spontaneously jump into your head. Today, I'd like to take a look at how a more conscious way of generating ideas works. How it works for me, that is :).

Quite often, in gamedev as well as most other endeavours, you'll need an idea. Perhaps there's a problem to be solved, a story to be written or something you feel could be handled more elegantly. If this is the case, it's great if your unconsciousness hands you a nice idea. But much more often, you'll be applying your conscious mind to this. And my experience is that you can turn on idea generation quite easily. A lot of books have been written about this, and there are more than enough good ones to choose from. These are respectively the most practical and the funniest I've read:

There are many, many techniques to use. I can really recommend reading these books if you are in need of ideas / problem solving from time to time (and who isn't?). Here, I'll look at three ways of turning on or accelerating idea generation that I often use.

First and foremost is restriction. For me, there is no better way to get the ideas going. By placing restrictions on what a valid idea is for the situation you're exploring, you basically turn it into a puzzle. And once it's a puzzle, I find that I keep poking at it until I see how things can fit together.

Case in point: last summer, I was designing up a small board game with and for my son, who was five years old at the time. Great fun. But you do need to get the idea juices flowing, since you're acting on the desire to create something and not starting from a particle of raw inspiration that hit. Designing something completely out of the blue isn't possible for me, so I had my son pick what the game was to be about. The answer: pirates! A few more questions revealed that the game should be about hunting treasure more than swashbuckling or firing cannons. This was enough to get started, and less than an hour later we were playing version 1.0 :).

So to sum up. Think of a game for my son: stumped. Think of a game for my son about pirates, focused on finding a treasure: now we're talking. As an aside: the reason I picked this example is that I built a digital version of this game a while back. I think I'll be writing a blog post about that in the near future, but here's a screen shot as a little teaser (beware, programmer art!).

The second way of aiding idea generation I'd like to discuss here is looking around. How does what you see, what you read, what you hear, what you randomly encounter (etcetera) fit into what you're trying to do? It doesn't even matter if it's clear beforehand that no actual link does or even can exist between your inspiration and your problem. The main thing is to nudge your thoughts into a different groove. For more on this, read 'Consult an Oracle' in A Whack on the Side of the Head (by Roger von Oech).

As an example, I was looking for inspiration for challenge missions (more on those when we start posting about the next Powargrid update) and ended up using all kinds of inspiration to create concepts. Things that I turned into concepts: an earthquake, a waste incinerator, skiing, a Windows crash, a tank pit and taking the train to work.

To be fair, looking around you is a 'specialised' form of using restriction like I mentioned above, so perhaps this is more a subcategory of restriction than a category of its own. But that's a question of definition, and I'll stay away from that here :). The same is true for the last technique I'd like to discuss, themes, in which restriction is also a big component.

Picking a theme for something you're developing works brilliantly, even if the end result doesn't show it explicitly. The main reason for sticking to a theme is that this makes whatever you're creating more consistent, logical and easier to follow. A good example of this is ballroom dance (which I've done quite a bit). I think it's most often impossible to read the story in a ballroom dance, but strangely enough dances do look better if a story is being told. The story / theme brings a focus that really improves the performance.

But on top of that I've found that a theme adds another set of restrictions to your thinking, thus further enhancing creativity. An example where this happened is the seventh mission in the Powargrid campaign, Piece of Paradise. Here, you fight against Zomg (of the evil religious greens) and Swap (of the yellow financial sector opportunists), who have formed an alliance. Combining their focusses quickly led me to televangelism as a theme. From there, it was a logical step to use Jesus He Knows Me from Genesis as inspiration:

It was fun to spoof a brilliant song. But this also brought inspiration beyond the song. Swap, for instance, at one point Swap tells Zomg that he's invented an even better money-maker:

"And I'm working on a thing called purgatory, where blobbie souls are cleansed of the good and altruistic thoughts they had in life. I know it's not in the book of Krak, but we can pretend it is and sell indulgences to blobbies, which pre-cleanse them. That'd bring in money like nothing else I can tell you!"

And there is a lot more in there. I'm really happy with how that mission turned out, and for a large part, that's due to picking a theme.

And that about wraps it up. To recap: adding restrictions = creativity on steroids. For me at least :).

I'll leave you with one more thought on how restrictions aid creativity. The thing is that restrictions most often aren't that restricting at all. Even after adding restrictions, the idea space you have to work with is still gargantuan. Going from 'design a game' to 'design a game about pirates' is a huge restriction in terms of the possible ideas that you can then no longer use. But there still are about a gazillion ways to design a pirate game. I visualise this as a way to stop mucking about in the local vicinity of the idea space, but to instead set out in a specific direction so you get to explore new terrain.

Anyway, I hope you enjoyed this two post foray into creativity. And if these posts were useful for you, I'd love to hear about it :).


- Willem -


PS; the Steam Summer Sale will still run for a few days (at the time of posting). Be sure to grab Powargrid at a discount if you haven't already!