First of all apologies for the long break since the last blog update. Unfortunately the realities of game development, or really the crunch mode where we have been for the past months, has meant that we had to sacrifice updating the blog in order to concentrate fully on development. Now as we are gearing towards beta and finally the launch, we’d like to get to blogging more often… Well, let’s see how that goes!
Ok, that thing sorted out, let’s talk about today’s subject, which is randomness as a game design concept and how it affects Druidstone. Randomness can be found in many places and in many forms in a game. For example, are levels fixed or randomly generated (tried that, didn’t work for us)? Are combat values such as hit chance, damage, damage reduction and so on random numbers or fixed? Are enemies in levels randomized? What about loot drops and items? Is enemy AI based on random behavior or do they follow strict deterministic rules? Each of these questions can be answered independently, so you end up with a design space with a large number of different combinations, each with their own feel and effect on gameplay.
Even if it would be feasible to test every possible combination (it’s NOT), it’s not clear cut which particular combition is the best. So at this point it’s the job of the game developer to put the game designer hat on and apply some good game design principles… which usually really means making “intelligent guesses” based on the game designer’s preferences and experiences!
One interesting thought experiment is how far can you push on the extremes. What if everything was purely random? That would probably be a very chaotic experience, and a poor match for our goal of making a deeply tactical game. A more appropriate question in our case would be: what would a game without any random factors be like, where everything except the players input is basically predetermined? On the surface several games seem to be like that. For example, games like Into the Breach (an absolute masterpiece btw!), chess and Solitaire seem to have no randomness. But looking deeper even these games have randomness. In Into the Breach enemy moves seem to be randomly determined, which leads to surprising moments. In chess the decisions of the opponent, how he or she moves the pieces, while not necessary determined by a random process, provide unpredictability for the other player. In Solitaire the deck of cards is in a random order. The point of randomness in games is to produce unexpected events because unpredictability and being surprised is fun. I believe all games have some sort of randomness built in. If they don’t they cease to be games and become pure puzzles. In fact, a definition of a puzzle could be “a game without random elements” (this definition is problematic though: defining a game is even harder problem).
Ok, what does this all got to do with Druidstone? Hold on, we are getting there! For Druidstone the most important design decisions we have to make regarding randomness are:
1. Are the levels fixed or randomly generated?
2. Combat values (hit chance, damage, etc.): fixed or not?
3. Fixed or random loot?
4. Should enemies follow strict rules or be based on random numbers?
There are others but I think these are the most important ones, which have the biggest impact on gameplay.
Random level generation we have already scrapped and this has been covered in previous blog posts.
For the combat rules, we have actually tried both random and fixed variations. The initial design, following our initial gut feeling, was to make combat values, like damage and to-hit, randomly varying like in most RPGs. But once we tried constant values and set hit chance to always be 100%, the nature of the combat changed. Most importantly combat without random modifiers support planning and tactics better and using hero abilities in combos is more practical because you know the outcome of your actions. Druidstone does not have an initiative system, so you can activate your heroes in any order and interleave actions of your heroes any way you want. This combined with the no random numbers approach to combat rules turns the battles into sort of mini-puzzles, which we find more interesting than statistical approach. Using your limited resources and abilities becomes an integral part of solving these puzzles. For example, the thought process while playing could be “Ok, gee, there’s no way I can defeat that Dark Knight with high armor value… Hmm… maybe if Leonhard first charges and pushes him to Oiko’s range, then Oiko can teleport the Dark Knight on that trap, which explodes at the end of heroes round. But wait! To do that Aava needs to clear these critters first because they are blocking Oiko…” And so on. Written like this it may sound complicated, but with aids such as visualizing the outcome of attacks, enemy statistics being open information and being able to see enemy reaches, it becomes intuitive and natural.
I’ll leave the question on “fixed or random loot” for another blog post because explaining the design process of the items warrants a blog post of its own.
Finally should enemy behavior be deterministic or random? Currently enemy behavior in Druidstone is pretty much deterministic, because of the way how the AI is currently structured. And I actually think this is not ideal and we made a wrong decision somewhere along the way when designing enemy AI. Enemies should do unexpected things (the enemies are monsters, not robots following directives!) and ideally you’d have to react to and change your tactics based on what the enemies do. So this is something we are still going to fix. Fortunately the fix isn’t necessary that involved — adding randomness here and there to the decision making should do wonders. We look at board games for inspiration (more than computer games actually), and many co-op board games use cards to implement their enemy AI. So what we’re currently thinking is a system with a small random deck of monster actions per monster type. Each turn the enemy AI would draw a card for each monster and use that action or tactic this turn. Essentially we already have all those actions, it’s just a matter of making changes to the high level system which chooses when to use these actions. This could be the right ingredient we are missing to make the enemies even more interesting and varied.
This brings me to another great design tool for randomness: cards vs. pure random numbers. Both can be used to generate random values. A random number generator is pretty much like a die: every time you roll the die you get an independent random value. But a deck of cards has memory: as you draw cards the options will be gone until all the cards have been drawn, at which point you shuffle the cards to form a new deck. Most often this is exactly how you’d like randomness in games to work: you don’t want a long stream of misses or a long stream of hits, after all. For this reason, Druidstone is using virtual ‘card decks’ internally for many things.
So there you have it. What do you think? Are these kind of game design topics interesting or are we getting too detailed? Back to the grinder!
Oh, boy! What a week! The release of the first trailer video and opening the Steam store page while juggling with press releases and PR has meant that progress on the development front has been quite erratic this week. Nonetheless, these activities are really important, for what’s a good game worth if only a few people know about it? In this time and age, it’s not uncommon for even big games with big publishers to fight for their place in the spotlight, so for small indies like us getting the word through on the right channels is crucial for success.
That’s why we’d like to ask a little help from you. Please consider wishlisting our game in Steam and telling your friends about it. The Steam page also has a full description of the game along with new screenshots.
We are glad to announce that Druidstone has just reached alpha milestone! Alpha in our terminology means that the game can now be played from the beginning to the end and all major features have been implemented. Sure, there are some rough corners and the fat and variety is still missing (more equipment, abilities and the like) but the main campaign is now there. It’s always a special moment to play through a game in development for the first time, and our very own Juho has been fully occupied with that tasks for the past days. Luckily, he encountered only three crashes (which have been fixed already) and a game breaker which caused all equipped items to get lost in the middle of the campaign (oops!).
Next week we are going to regroup, go through the feedback gathered during the alpha test and form a battle plan how to get Druidstone to beta. We suspect the TODO-list is going to be rather hefty, but this is normal and nothing to worry about. 🙂
Hi! How are you, folks? Here’s a quick dev update before we head off to summer holidays!
The last update is already from February and quite a lot has happened since, as you’d expect. For instance, the guys have been cranking out new enemies at stellar speed and the enemy gallery is now up to whopping 37 enemy types, not counting variations. That’s a lot considering our art team consist only of our dynamic duo, Juho and Jyri who are modeling and animating all the monsters!
On the gameplay side we’ve been concentrating on building the length of the game in the form of new levels. Our current goal is to hit alpha, which is perhaps the second most important milestone for us (the most important, of course, is shipping the game). Alpha in our terminology means getting the game to a state where it can be played from start to finish without nothing major missing. The sooner we can hit alpha the better, because then we have more time to polish everything and make the game really great. We are not quite in alpha yet, as we need more playable levels to get there. That said, the first half of the game is pretty much in playable condition and the very last segment of the game is also done. Now we just have to fill in the gaps and then we can start adding new playable characters, side missions, secrets, new abilities and items, etc.
This is big! As you may have been able to read between the lines, the development process of Druidstone hasn’t been all roses and butterflies. What I mean is that there has been some uncertainty with the project which has made it hard to communicate clearly what the game is truly about. That’s because up until now we have been in pre-production mode where we still try ideas and see what works and what doesn’t. But now that has changed. We know exactly what we are doing now.
That means that many things in the game which we have mentioned in the initial blog posts have changed. Actually, so much that the game as it is now and how it will develop in the coming months does not resemble the one displayed in old blog posts that much. Sure, we still have the same basic premise, the same environments, the top-down view and tactical combat, but the spirit of the game has changed. Has evolved, if you will. What started as a procedurally generated RPG has transformed and will transform into a much more tightly focused game.
So what exactly has changed? Here are the main points:
- Procedural generation is gone. Long live the editor! Every map and every encounter will be handcrafted.
- Focus on deep and tactical combat system. We want to make the combat really challenging so that every action you make every turn is a careful choice. Like playing chess with fantasy characters.
- Focus on fun gameplay mechanics. We are not writing a book, not filming a movie, we are making a game, and gameplay is king.
- No fluff. We want to make a tightly focused game, the same design principle we had with Grimrock. No filler content. Less is more. Or as Antoine de Saint-Exupery puts it famously “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
Ho ho ho! Welcome to the Druidstone development MEGA-UPDATE! As they say, time flies when you’re having fun, but it’s still hard to believe three months(!) have passed since the last blog update. So what have been up to lately? Well, many things, glad you asked!
For instance, we now have a full fledged level editor, which allows us to make much more detailed levels. A year ago, when the game design was more heavily oriented towards procedurally generated content, we thought that we would not need a level editor at all. The levels were supposed to be mostly generated with some manually crafted rooms thrown in. But as development progressed, we felt the need to make more and more hand crafted locations and the need for a proper level editor arose. We will still keep adding new features to the editor, but as it is now, it’s ready for some prime time and we can start making new content with it.
Warning! From time to time we are going to post some very technical material in this blog. This is one of those posts. Read on at your own risk.
Modern games tend to create new game objects by compositing them from separate reusable components. This is a very powerful concept as complex behavior can be built from relatively simple building blocks. Components can be things such as models, lights, animations, sound emitters and gameplay related components such as health and item components, just to give you some examples. In this blog post I’ll talk about how we use components to build the game objects in Druidstone.
Summer vacations are over and we are working hard on Druidstone!
Before the summer vacation we had quite a productive week. Some of the contributions were already mentioned in the last blog update, but a couple of things did not quite make it to the blog post.
First: we implemented grass rendering. What a difference does it make! My desk is facing away from the window, and of course we keep the window blinds closed like proper geeks do. To calm my nerves and induce lucid dreams of childhood summers in the Finnish forests, I can just stare at the wind blowing through the Menhir forest. Aah, lovely, I can feel my blood pressure dropping!
Hullo fellow druidsters! It’s time for another Dev update. As always, we’ve been busy with the game getting a lot of stuff done. We’re giving a last push before the well earned summer vacation time, so it will be a bit more quiet in the Druidstone’s forest during July.
In the last Dev update, we told that we started working the game synopsis into a script and that we also split the game into acts. The acts will help pacing the game, but they can also help the development: We can focus on them one at a time as they are sort of isolated entities and each has its own theme going on. We’ll do a pass on all of them to get the basic structure of the game complete with the story and gameplay elements blocked in. After that it’s an iteration after iteration until the game is done. Past couple of weeks we’ve been working on Act 1 and it’s pretty much playable right through. Of course it still needs a lot of polishing and balancing but it’s already really fun to play. We get to meet new party members, monsters and at the end explore the smoke scented Blimmur cave.