This article is for the indie game developers in our readers. I'm going to share what I've learned over a period of approximately two years about hosting a website for a game. I would have loved to read this about a year ago, it would have saved me a lot of work. Maybe the past me can read it due to a strange time loop phenomenon.

Ever since I released the first alpha of Driftmoon, I had a nagging suspicion about the performance of our website. Will it hold under stress? What if Driftmoon is featured on the front page of a big website, and we get a hundred thousand users all at once? If the website doesn't cope with the load, the publicity would be useless! Thousands of dollars and euros would be lost! Not to mention all the countless individual minds deprived of refreshing themselves in the world of Driftmoon!

That's where I started. I had a virtual PHP server, with Wordpress running the website and phpBB running our forum. The server was barely coping with the current load, with slowdowns every now and then. My first thought was to buy a bigger hosting plan - and doing that would have saved me a lot of time. But the trick here is that I don't know if there will ever be a huge spike of traffic to my website, or even how big a spike! I could buy the costliest hosting plan there is, and still be under capacity when the the game is featured on a big site.

Another point is that since the website will usually run at a very low volume, only to spike out when someone notices us, there's no need to run an expensive service all the time. The costs would quickly outrun any of the money I get from selling the game!

So I started tuning my Wordpress installation. I used every caching trick and plugin I could think of. I spent weeks improving the efficiency, even putting together a simple content delivery network - I offloaded most of the static content like images and files to Amazon Cloudfront. But still I knew if enough users came at once, the main server simply couldn't cope with it.

At that point I was actually thinking of making the whole site out of static webpages. Those would be cheap to host on any server, and they would be extremely fast to server. But in the end I decided that updating the site would be too much work with a static site, besides I needed to have dynamic content like the forums and blog comments.

Then I decided to give cloud hosting a chance. I moved away from my cheap host to the Amazon EC2 cloud where you can get micro instances for cheap. In theory you could make a sort of autobalancing system that would add more virtual hosts as needed, dynamically increasing the power of the website, but also at the same time increasing costs. After trying for about half a year I was still no closer, because configuring all the Linux subsystems by hand was taking more and more time. I decided that I'm a game developer, not a sysadmin, and started looking elsewhere.

In the end I decided to use Google App Engine, because it promises to run a simple site for cheap, and automatically scale upwards when traffic spikes. No Linux administration needed! I wrote a little bit about that earlier, but I didn't want to get too much into the details in case there was still more to learn about it. The jump into App Engine seemed massive, not only was there no useful blog software like Wordpress available, there was no forum software either. But the lure of the cheap and scalable webhosting was too strong.

It actually took the better part of two weeks to rewrite the parts of Wordpress I needed to run on App Engine. And I'm still putting finishing touches to my new forum that I wrote based on phpBB.

And how is App Engine working for us? Extremely well. Right now I pay a flat minimum fee of $9 per month. App Engine has a generous quota of one free server instance, and my well oiled blog engine uses about 1% of that instance at normal (orange line). Sometimes bigger traffic spikes actually fire up more instances that run for a while to service the users - and that costs $0.04/ Hour / instance. But as you can see in the graph, the billed instances stays at about 1 instance, they're practically giving me extra capacity for free.

I won't say there aren't any downsides to using App Engine, such as the need to write your own software because there aren't enough existing ones, or some of the changes they're making to the platform all the time, but it seems to be well suited for our current usage. Whatever your choice is, just keep in mind that your game could be the next Minecraft, and you don't want to be caught with a lousy server when people start flocking to your site. So don't be afraid to spread the word about Driftmoon, this site should now be able to handle millions of users rushing in at once!

Ps. I've actually even given a little thought about possibly releasing our forum software some day, if there's demand for it.

I decided the first level needs to have a shield available, so I took D'Lokh's idea, and twisted it a bit.

"After losing all of his arrows in a campaign against the short-lived Spikey empire, Hogpuff the Brave ordered a shield that would magically repel all arrows back to their origin. Unfortunately the magic only works 3 times out of 10, but that didn't stop Hogpuff from carrying it around as a handy mirror, in case his hair ever needed adjusting."

Can you spot The Biggish Book of Monsters?

Just wanted to let you know that our friends at RPGWatch are giving away two copies of Driftmoon in celebration of the site's fifth birthday. Congratulations RPGWatch!

Have you ever gotten lost in a dark dungeon, and don't know which way you came in? Presenting the Light Boots! Now you can always see where you came from, and where you've been already.

The Halloween enhancement isn't actually the boots, it's the monster you get the boots from. But I don't want to spoil it, you'll have to wait and see...

We've finished creating the new monster types, and right now I'm adding them to the game. We wanted to give the Driftmoon combat a little more variety, so we've tried to think of monster types that would create interesting situations when combined with the game world or with other monsters. The Ticker is one of the new ones you'll get to meet, along with the crab colony at the end of the video.

From Hogpuff's Biggish Book of Monsters:

It's been a little while since we stopped to look back, and evaluated the current stage of Driftmoon, so I decided to ask myself a few difficult questions.

What is Driftmoon?
It's a roleplaying game that my lovely wife Anne and I are making. It's a game for people who love to explore and find things, and who like to meet interesting characters. See the Driftmoon page. I think that this screenshot tells you something about the nature of the game:

When will it be ready?
I'm terrible at estimates, so I'll just tell you what's left for us to do. We've completed 6 major areas out of 8 (the current Alpha includes 4 of them). We've got a lot of content ready for the last two areas, so I think we're at about 80 percent completion for the game. So there's still a few months left before we can release it.

What are you working on right now?
The new monsters! Although Driftmoon is not an action RPG, we still want our combat to be as fun as possible. So we've been working hard on improving the fighting side of the game, and part of that is adding interesting monster types. We want to make some monsters that require a bit of thinking from the player. Some monsters might be relatively easy on themselves, but together with others they start requiring pretty clever strategies to deal with. And you can sometimes even use the new monsters against each other.

What is the vision behind the game?
The vision is to make a fun game, with our own personal touch! We want to make a game with intriguing characters, where you can explore and find new things. Above all, we wanted a place for us to pour all the stories floating around in our heads. So there are a lot of optional mini-stories in Driftmoon.

How long is it?
I believe the main adventure in Driftmoon will be about 10-20+ hours of high quality playtime when completed. After that you can continue playing with our mods, which are just one click away. Obviously a lot depends on your playing style, as with all roleplaying games. There are a lot of optional quests, and dialogues including a lot of back story that you can read if you want to. We made the decision early on that each minute of the game should matter, so there's nothing repetitive, and no empty content just for the sake of prolonging gaming-time.

What other games is playing Driftmoon like?
Of course Driftmoon is not a retro game, or a clone of any game, but it's possible to make some comparisons. The combat system in Driftmoon has similarities with Dragon Age. In it's core it's really a turn based system, but it runs in real time, and you can pause it. Talking with other characters is similar to Baldur's Gate or Fallout. And controlling your character works a lot like in Diablo, except you don't need click so many times in combat.

Why is Driftmoon top-down?
It's top-down because I tend to get lost in games with a first person view. The perspective also makes it very easy and intuitive to control your character. We can also make all of our characters from cleverly placed sprite sheets, so it's very easy to make new characters and monsters in the game. That is a big time-saver for modders, and it's left us a lot more possibility to fine-tune other aspects of the game. If you haven't had the chance to play any top-down games before, the perspective might feel a bit weird at first, especially when looking at the screenshots. But when you actually play Driftmoon, I promise you will get used to the viewpoint in a matter of minutes - that's what I've been told by some of our preorderers.

Here's how peanut for example has put it: “This looks great. I actually quite like the top-down perspective – the graphics style is strong and clear, and I think the perspective will make interacting with mouse much easier. No need to rotate the camera to select obscured objects.”

How does modding in Driftmoon work?
Driftmoon comes with the full tools used to make the game, and they will also be available in the demo version. So basically you can fiddle around with Driftmoon, and make your favorite changes to it. Or, you can implement that great game idea that's been floating around your head, waiting to get out. When making your mod, you get to use all of the Driftmoon content (including images and sounds) in any way you choose, or create your own. It's a complete roleplaying game building set! What's more, there's an automated mod distribution and installing system built into the game, so you don't have to worry about hosting your mod. And if you choose to ask money for your mod, we can arrange that as well.

What have people been saying about the game?
There have been no actual reviews yet, but the feedback we've received has been very positive. And Driftmoon has been nominated for the MindTrek Indie Award!

We also want to heartily thank all our preordered, the users of our forum, and the commenters of our blog for hanging with us along the way. Your support, feedback and ideas mean a lot to us!

If you want to support us, you can still preorder Driftmoon on a 20% discount!

By popular request, I will reveal you how we do pathfinding in Driftmoon. This might be interesting to you if you're making your own game and want to implement pathfinding, and also if you're making a Driftmoon mod. Pathfinding in Driftmoon has gone through a couple of iterations already, so I'll start at the beginning.

First of all, we use the A* search algorithm. That was pretty much the only thing that went right from the start. A* is easy to implement, and there are libraries available for it. All I needed to do was create some amount of location nodes, tell the algorithm where I want to go, and where I start, and that's it.

So how do we make the nodes? Driftmoon is a top-down game, so I figured we could make a grid. All of the examples I saw at the time were of grids. An automatically generated grid would be good, because modders would never have to worry about the pathfinding, it would just work. So I made a grid, and looped through all the points, and connected the ones which didn't have walls in between them. To make sure our AI could navigate small doors or cracks in dungeon walls, I had to make the grid pretty small. So I ended up with grids that amounted to about 10000*10000 points in them. You might spot the problem with that.

While A* is obviously a fast algorithm, it can't possibly cope with that amount of points in the graph. When my maps started getting bigger my AI churned about a minute looking for a new path. I had to reduce the amount of nodes in the pathfinding grid. So I tried it algorithmically. Make the grid sections bigger where there's nothing but open space, and smaller where there are gaps and doors. It worked, but it started taking minutes to create the grid when the map was saved in the editor. And I couldn't make the algorithm optimal, it still produced millions of nodes.

After all that, the AI works like this: It knows where it is (here), and where it wants to go (eg. go talk to the player, or go kill the player). For both the start and the end points, it looks for a way to the nearest pathfinding nodes. And then it looks for the optimal path between those nodes. Here are some of the optimizations it uses: If it sees the end point straight away, it doesn't bother with pathfinding at all. If it sees a clear path to a pathfinding node one step ahead, it will skip any unnecessary pathfinding points. I've tuned the A* algorithm to prefer routes with no dynamic obstacles, but the AI goes through the obstacles like a bulldozer if it can't find an alternate route. From the above you probably reasoned, that a lot of the times the AI simply has to decide whether there is a clear path from A to B. If your making your own game, the most straight forward way to do that might be to use the raytracer in your physics library, but in Driftmoon, we're using our own spatial hash maps.

An important matter to realize is that inside dungeons, often there simply isn't a path from where you are to where you want to go. In this case, the A* algorithm hammers through the entire set of pathfinding nodes, and this is obviously the slowest possible case. We need the ability to quickly check if we ever could get from A to B, or is it completely impossible. This is done by marking each pathfinding node with an area number. If the area numbers are different between the start and the end nodes, that means they are on areas that are not accessible to each other. So now the nonexisting path case is the fastest one, we just check whether the area numbers match. I'm setting the area numbers simply by doing a flood fill for each node when we start the level.

Now I was left with a pretty snappy pathfinding, but as I added more monsters and townspeople, I started noticing that it was bogging down the framerate when the AI wanted to do pathfinding. The problem was that when the player moved, a lot of the monsters might decide to start looking for a new path at the same time. So I implemented a pathfinding queue with priority numbers. The monsters nearest to the player get their pathfinding done first, and monsters very far from the player might not get pathfinding at all, or might get it less than the others. And if the monster's pathfinding wasn't complete yet, it fakes it by just going on a direct path.

So that's how pathfinding in Driftmoon works. I've spent many months making it. My advice to people making their own games is this, skip pathfinding altogether. Make the monsters zombies, robots, or green slimes that don't need pathfinding, and you've saved yourself many weeks of development time!

I've just been informed that Driftmoon has been nominated in the MindTrek Indie Games Awards!

The MindTrek jury writes:
Driftmoon [..] Competes in very difficult genre which has the most demanding but also most loyal users. Fascinating story offers possibility to prevail.

How right they are, roleplaying games are extremely demanding to make. When starting work on Driftmoon I had no idea it would take years to finish it. But now that it's nearly complete, I'm glad we decided to take the challenge!

So go on to the MindTrek page and check the other nominees!

Update: DIY Gamer has posted an article on the competition.

In our last Driftmoon alpha, there was little reason to use bows in combat, since (1) the arrows were limited, (2) you got the bow pretty late in the game, and (3) most of the monsters were far easier to defeat using melee weapons. We're changing that right now, bows will be much more useful from now on! I thought about a hundred very complex ways to make that happen, but finally I realized it's not nuclear physics. We simply needs some monsters that are easier to defeat using melee weapons such as swords, and some monsters that are easier to defeat using ranged attacks, such as bows.

We're now in the middle of weighing different alternatives that would make it convenient to react to the new varying enemy types. For example, now that I frequently want to change my weapon set, a button that changes between two weapon sets would come in handy. I could reserve the right mouse button for this purpose.

Another problem we've been thinking about is that some of the attack skills, such as the Retreat skill, should actually work outside combat. But you can only activate the skill while in combat because the skill buttons only show up when you're fighting someone!

So I'm thinking that we could turn the current quick item slots into two-purpose slots, meaning you could fill them with skills as well as items. We'd get rid of the current skills list that only appears in combat. I think this opens up a lot of possibilities for modding, with the player being able to activate skills out of combat. Since skills are just scripts, modders could make skills that make the player invisible before combat, or skills that make the player change into a werewolf shape - all without requiring the player to carry special items to do that.

The only problem that I see with the multipurpose slots, is that you'd get 10 slots less! Any ideas? Don't need more than 10 slots? Go Warcraft and add as many slots as the screen edges can take (but you'd loose visibility?)? Make the weapon set button, the right mouse button perhaps, switch to another set of 10 slots?

The code is only about 12000 lines, but I didn't have time to put it into separate files at the time. Unlike Bikez 2, which I released earlier, Wazzal is mostly in English! Bear in mind, that it is still one of my earlier projects, so I'm releasing the code on one condition: If you're ever thinking about hiring me, don't judge my coding skills by this.

PS. We're making more enemy types to Driftmoon. And let me tell you, it's hard work training new monsters! They ate through my hat, and one of them nearly got away with Anne, but I've managed to capture a good number of them into Driftmoon! I'll tell you more about the little critters later.