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.
To our surprise, there has been some heated discussion about Druidstone being procedural. We didn’t really expect that but in hindsight it’s easy to see that we should have communicated more clearly what it means when we say Druidstone has procedurally generated content. Otherwise it’s way too easy to get the wrong idea.
So let’s talk about proceduralism in Druidstone. Procedural games can be roughly split in the following categories:
1. Fully procedural games like Minecraft, Dwarf Fortress and No Man’s Sky, which generate the whole world procedurally. Most of them have sandbox type of gameplay.
2. Procedural games with some predefined content. For example, most roguelikes have special rooms that are handmade (often called “vaults” in roguelike jargon).
3. Games with handmade, predefined content in randomized order. E.g. FTL has designed encounters but their order is randomized and Binding of Isaac has handmade rooms whose order is also randomized.
So, which category does Druidstone fall into? Druidstone has a story that unfolds as your progress in the game, so option 1 would not work. Telling a predefined story in a fully procedural generated world would be almost impossible. Technically options 2 and 3 would both work but in the end we picked option 3 because it just fits better into the game design and is just so much easier to accomplish.
Ladies and gentlemen, we’re pleased to announce that we have a new team member! Jussi Sammaltupa is joining the Ctrl Alt Ninja team as a programmer, essentially doubling the coding performance of the team. Personally I’ve programmed solo for so long that it’s refreshing to get to do team work and work together on those really hard coding problems that appear from time to time. Without further ado, I’ll leave the keyboard to Jussi so he can say hi. Welcome aboard Jussi!
Welcome back, friend! It’s time for the first Druidstone development update! The last two weeks have been extremely busy and productive and we have made some big changes to the game. Let’s get started with the biggest of them!
Party-based gameplay. Yes, there will be multiple playable characters in Druidstone! This is something we have been talking about internally every now and then, but until now we weren’t sure how this would work exactly. The upsides to having a party of characters are obvious, like more varied and more tactical battles, and as big fans of the good old Gold Box games we have always wanted to get this feature in. But there are also many implications to level design, death mechanics and how the story is told. For example, the levels need to be more spacious (wider doorways, etc.). What happens if a party member dies? What happens if the main character dies? Is there even a main character (are all characters equally important to the story?) Is there inter-party dialogue (yes, please!)? How does the dialogue scripts work if a party member is dead? These are just a few of the issues that need to be carefully thought about.
This is the first post of our of behind the scenes series, where we take a closer look how games are made and what happens under the hood of a game engine.
In game industry art pipeline is the process where an art asset is designed and produced in certain ways and tools so that it is compatible with the game engine and design. I’ll be walking you through the art pipeline we have created for Druidstone and show how the Dark Knight, one of the enemies facing the player was created.
DISCLAIMER: this blog post is from a time when Druidstone was still in preproduction. Almost everything in the game design has changed since then. For example, all the levels are now hand-crafted (procedural generation is gone), the main character is no longer a druid, and there are multiple playable characters. We are keeping this blog post here for historical reasons. To get a better impression what the game is about, please read the About page and later blog posts.
All is dark. Your mind is floating in the endless reaches of the great void. Barely visible, mist and dim fading stars in the far distance are the only things you can discern. Then, suddenly something in the darkness stirs… “Your time has not yet come” a deep resonating voice booms. A bright light flashes so intensely that it pierces your mind!
You hear the rustling of autumn leaves. You open your eyes and see an ancient pillar of stone covered in pulsating runes. You are standing in the center of a stone circle in the middle of a clearing somewhere in the Menhir Forest. A woman with skin of purest white steps forward and smiles at you. Her eyes glow blue, like distant galaxies. “What took you so long?”
Welcome to the Druidstone dev blog! This blog is about the development of a fantasy roleplaying game called “Druidstone: The Secret of the Menhir Forest” which we have been working on since fall 2016.