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!
Second: Petri tweaked the camera angle a bit. It’s not exactly isometric (or axonometric), as it has perspective projection, but the world is now rotated 45 degrees around the vertical axis. This makes it possible to move the camera a bit closer by default, which brings out the detail in our models, making everything look great. But don’t trust just my word for it, see the screenshot down below.
After the vacation, we have introduced a bunch of new monsters, restructured the whole game – acts are gone – and rewritten artificial intelligence. But more about this later!
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.
That’s one big troll. Look at it! It totally fills 2×2 grids.
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.