Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Druidstone: The Secret of the Menhir Forest - turn-based isometric RPG from Grimrock devs

---

Arcane
Joined
Dec 19, 2015
Messages
1,724
Location
Italy
What is this? :prosper:
I just wanted another Grimrock, fuck :negative:
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
Next time there's a new game from well-known developers, please state that in the thread title so my eyes don't skip over it as another indie shovelware. Thank you.
 

Keye_

Educated
Joined
Dec 5, 2016
Messages
78
So is this supposed to be a roguelike/rogue-lite? Or what am I supposed to understand under 'procedurally generated'?
A story-driven roguelike? I'm not getting my hopes up.
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
http://druidstone-game.com/druidstone-art-pipeline

Druidstone Art Pipeline

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.

Mainly the art pipeline in Druidstone revolves around Blender, a 3d-software that is open source and free for anybody to use. Pipelines are usually heavily built around the main software that is used most or that has some advanced features that are essential to the production. In our case we needed a software where you can rig (make a digital skeleton to a character and controls to move the system) and animate objects. There are many all-arounder 3d-tools available, but as they are highly complicated and specialized tools, they are also very expensive. We ended up trying Blender, and I must admit, I was a bit skeptical at first as it seemed to have a learning curve more steep than I was used to in other softwares. But in the end we got the hang of it and managed to push a test character all the way through our new Blender based pipeline.

So what are the steps an art pipeline usually involves? It can be broken into a couple main sections: concept design, modeling, texturing, rigging and animation. All these steps are art forms in themselves and bigger studios have full teams dedicated to them. But as an indie developer you have to have profounding understanding in all of them. Luckily we have Jyri in the team doing the rigging and animations, because that is definitely my weak point.

Basic flow of Druidstone art pipeline.





Concept art is the initial design phase of pretty much any asset that goes into game. In this case we first decide and plan what kind of enemy we need, what abilities and features it should have and how it sits in the gameplay and story. Then I usually pick up Photoshop and draw/paint the concept. Concepts can be made in numerous ways – I think majority of my concepts are just doodles on post it notes. The amount of iterations what it takes to nail down a concept can vary greatly if the subject it very abstract or curious. Drawing a concept is a great way of going through different ideas and you get more tangible vision of the subject than for example in written description. Sometimes when I have a clear vision, I may skip the whole concept stage and wing it straight in 3d. That’s pretty rare and happens usually with weird organic monsters that are best blocked out in 3d. That’s the awesome part of being indie, I don’t have to approve designs on long meetings with bunch of producers


dark_knight_high_res_model-300x115.jpg


After the concept is done, it’s time to transfer that idea into three dimensions. I use variety of tools to do that, but mostly my tool of choice is Zbrush and Blender combined. At first the character is modelled in high resolution. That means that it’s highly detailed and is made up of sometimes millions of polygons (polygons are triangles in 3d-space that make a surface when combined. They are the backbone of every 3d-object). After the high resolution model is done, a low resolution version of the same model is made. That low resolution model has a lot less polygons in it for the game engine to be able to run it in real time 60 fps. The high resolution data is then “baked” into the low resolution model so that it looks like it has all the details, but only fraction of the polygons.



When the game model is finished it still needs textures to illustrate the different surface properties. But before textures can be applied, the model is UV mapped. That means the model is skinned and pealed into 2d-space. Think of it like skinning a hide from an animal that is then stretched to a floor. When the 2d- and 3d-data match, a texture can be painted on 2d-image that is then projected to corresponding places on the 3d-model. Nowadays you can paint directly on 3d-model, but usually the unwrapping is still needed. I use Allegorithmic’s Substance Painter and Designer on pretty much every object that goes to Druidstone. Substance tools use a PBR (physically based rendering) based workflow and we use tweaked version of “older” diffuse and specular workflow, but with little tweaking, I’ve got a pretty good marriage of the two going on despite the differences.

Now that the model and texturing is done, it’s time to give the character life by animating it. In a nutshell a skeleton is made then the bones are assigned to correct areas of the mesh, then control points are created that can move the skeleton around, but that is a blog post of its own. When the animations are done, the model and animations are exported in .FBX file format that the game engine in turn converts into files that it handles. That’s when things get a bit technical and maybe Petri will shed some light on the matter on some other blog post.

As you may see, we have much more detail in the characters than can be actually seen in the standard game view. That leaves us with the option of doing special camera zooms on the characters when for example the player does some cool special move. Also having the details in the models gives them that extra something. It’s like in the Lord of the Rings movie, when Weta studio made the props and armor pieces, they were riddled with minute details no one would see, but it was worth it and helped to make the world more believable.

Here’s how the Dark Knight looks in the game.

 

hilfazer

Scholar
Joined
Jan 26, 2016
Messages
224
Or what am I supposed to understand under 'procedurally generated'?
It means the game will take little disk space and there's a possibility it will have large amount of content.
I couldn't care less about first thing and second one is under question mark.
It would be more useful to know if the game is also randomly generated.
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
http://druidstone-game.com/dev-update-1

Dev update #1

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.

Anyway, I spent several weeks testing party-based gameplay in a separate development branch, tackling the technical issues one by one and testing gameplay in practice. There are still some issues left, especially related to the story and how its told, but we are confident now that we can tackle them. So party-based gameplay is definitely a go!

Large object support. Multiple playable chars led naturally to another big refactoring in the codebase that I’ve been thinking about recently. Up until now objects in Druidstone were limited to 1 square in size. That limitation is now gone, so we can have, for example, 2×1 square doorways, 2×2 stairways, etc. Also more importantly we can now have some truly huge monsters! In fact, Juho made a new bad-ass huge monster which we’ll save for a future blog post *evil grin*

Script writing. Janne Sundqvist, our part-time writer was also here last week and split our initial synopsis into act structure and began working on the script of the game. The script is going to be our holy book and it’s going have all the encounter and character dialogues which really helps the game to come alive. These onsite visits are really great because we can throw around ideas quickly, test them in practice and make sure everyone is on the same page about the vision of the game. Hopefully we can have another session with Janne soon!

Animation rework. In the meanwhile Jyri has been going through all the animations of Leonhard, our man in green. The initial rig, particularly the cloak has proven out to be inflexible for the sort of maneuvers we’d like Leonhard to do, so unfortunately Jyri had to modify the rig, which meant he had to go through all the 54 animation files which Leonhard currently uses and reanimate the cloak. That’s a lot of work! But it was better to make the tweaks now rather than later, because the number of animation files surely grows a lot bigger as we add new features to the game.

In other news we unfortunately lost several days of dev time due to bad luck. We had to replace two gfx cards which died recently and several team members have also suffered from illnesses and had to take some time off. I’m still recovering from Norovirus myself, which I can report to be a nasty, nasty bugger!

Ok, that’s all for now. Until next time!
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
http://druidstone-game.com/jussi-joins-team

Jussi joins the team!

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!



Thank you, Petri!

So, I have been programming and developing software professionally for nearly 20 years. The last 10+ years I spent developing procurement related software. As challenging it was, I felt I needed a change. I mentioned this to Petri, who invited me to pair program with him for a day. We got quite a bit done that day, and here we are!

The first week has been quite humbling. There is so much to learn! During the first couple of days I felt I am never going to be productive in this environment, but towards the end of the week, I was already more comfortable. Live coding with the Shinobi game engine is such a great experience. Need to experiment something quickly? Just write a few lines of code in the text editor, press a hotkey and you are ready to test your experiment directly in the game. No long build times, no need to wait. You just keep the game running the whole day and update it live with new code and assets.

The downside is that the feedback loop for the entire product – the game – is a lot longer than in the enterprise world. We don’t get to ship versions all the time and tune the game based on real feedback. That’s where you, dear blog readers, can help us. So keep those comments coming, we read them all!

I am pretty amazed by what these guys have accomplished in such a short time. The game is already fun to play, and there is a lot of good stuff coming up.

-Jussi
 

Jack Dandy

Arcane
Joined
Feb 10, 2013
Messages
3,039
Location
Israel
Divinity: Original Sin 2
Ahhh- I am looking forward to these updates.
I really enjoyed following Grimrock in it's development stages.
 

LESS T_T

Arcane
Joined
Oct 5, 2012
Messages
13,582
Codex 2014
http://druidstone-game.com/about-proceduralism

About proceduralism

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.

What that means in practice is that the world of Druidstone is split into areas that are “randomly” connected. An area could be almost anything, a room in a dungeon, a forest meadow, a graveyard, an encounter with a NPC, you name it. Internally we call them all “rooms” even though they may not resemble a real room at all. Basically each room is a handcrafted mini-level in itself, and can have enemies, traps, NPCs, etc. Rooms are picked from a large pool of rooms, so that there are more rooms than fits into a single playthrough.

Technically each room is defined by a piece of Lua code, so the system has a lot of flexibility. With Lua it’s easy to have some randomly varying content in the rooms as well, if we want to. For example, the enemies or items in the room may be randomly determined. We try to keep the rooms relatively small to maximize the potential of surprising room combinations.



The rooms are essentially 2D grids (tactical battles are just so much better on a grid), so it’s only natural that the rooms themselves are connected on a grid. We really like our grids! :cool:

In addition to these randomly chosen rooms there are special key encounter rooms that can only appear in predetermined points in the game. The key encounters usually advance the story but they may also be some cool moments or bad-ass boss fights.

So there you have it! If you have any questions, please don’t hesitate to ask in the comments section. Until next time!
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
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.

Well, that's nice! Maybe next month they'll announce that the game isn't procedurally generated anymore and the Codex will be really happy.
 

LESS T_T

Arcane
Joined
Oct 5, 2012
Messages
13,582
Codex 2014
http://druidstone-game.com/dev-update-2

Dev update #2

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.

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.

We’ve also done a major overhaul to GUI (that’s the Graphical User Interface) to make it work with the newly introduced party concept. The coders have been also hard at work making the GUI scalable and functional in every way. The GUI most probably will go through many changes and iterations in the future, but that’s business as usual. We’ve also tweaked the main character/s quite a bit. Well, number one: we’ve done two more main characters alongside our Druid. And two: As we added “cinematic” cameras to the game (a zoom or pan to frame a character that is doing something interesting), the characters need to hold up the closeups, so they needed an extra layer of detail as they were initially designed to be only looked at from top down perspective. Though it was a lot of work, it really helps bring the party members alive and show their different characteristics. Don’t worry, we’ll introduce the new party members in some other post.

Like stated on the last Dev update, the new party concept spawned various issues related to the dying mechanism and reincarnation concept, so there’s been a lot of thought and work put on them. Most of the problems concerned characters involved in story elements, but we’re drawing close to a solution that we’re happy with. We’ll cover that in a later post in more detail as it’s still work in progress and too big subject to discuss here in detail.

That highlights some of the things we’ve been up to lately. We’re off to summer vacation, see you back in August! Cheers!
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
Well, number one: we’ve done two more main characters alongside our Druid. And two: As we added “cinematic” cameras to the game (a zoom or pan to frame a character that is doing something interesting), the characters need to hold up the closeups, so they needed an extra layer of detail as they were initially designed to be only looked at from top down perspective. Though it was a lot of work, it really helps bring the party members alive and show their different characteristics. Don’t worry, we’ll introduce the new party members in some other post.

Like stated on the last Dev update, the new party concept spawned various issues related to the dying mechanism and reincarnation concept, so there’s been a lot of thought and work put on them. Most of the problems concerned characters involved in story elements, but we’re drawing close to a solution that we’re happy with. We’ll cover that in a later post in more detail as it’s still work in progress and too big subject to discuss here in detail.

tfw when what started out as a procedurally generated roguelike is iterated within weeks into a story-driven party-based RPG with cinematic closeups
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
http://druidstone-game.com/dev-update-3

Dev update #3

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!

Cheers,
Jussi


And now it's actually pseudo-isometric too.
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,225
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
Druidstone takes a side in the OO wars: http://druidstone-game.com/object-decomposition-druidstone

Object decomposition in Druidstone

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.

Preface
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.

The Dark Ages
Let’s start with some attempts that don’t work. Back in the 90s when C++ was hot and object-oriented programming was still considered a good idea, somebody had a great idea: hey, let’s build game objects using inheritance! Base-classes would be something like Weapon, Enemy, Player, Light or Vehicle. So if you needed an enemy that had a weapon and carried a light source you would create a new class and inherit from the necessary base-classes. Your typical textbook OOP solution. Needless to say this quickly led to a huge mess and to an explosion with the number of different classes.

Ok, what if you don’t use inheritance and just make the different components of the object direct data members of your class? Nope, this still doesn’t work because you end up with a new class for every combination of components in your game. Fast forward ten years. What you really need is some sort of entity-component-system where the components are decoupled from objects and game objects are no longer classes. What you have instead are “entities” which are usually just numeric IDs and components which are linked to these entity ID. This way components are maximally decoupled.

Something like this:

struct ModelComponent
{
Vertex* vertices;
int* triangles;
};

struct LightComponent
{
Vec3 color;
float brightness;
};

ModelComponent models[MAX_ENTITY_ID];
LightComponent lights[MAX_ENTITY_ID];

This kind of component system is how many game engines work. This is also basically how my previous codebase powering Legend of Grimrock 2 was structured (although the components were written in Lua, not C++). However, there are some problems. Inter-component communication and dependencies are kind of hard. With the dark age inheritance model you could at least call the methods in the same class without a fuzz. Not so with a component-entity system. If component A wants to talk to component B, or just do a simple thing such as look up a value in the other component, first it has to know the entity ID and look up the other component using the entity ID before it can do anything. This has to be done for every component look up. And believe me, there are many, many of those look-ups in a game! If this sounds too slow or cumbersome you can start adding coupling between the components by storing direct references to other components in your components… and you’re back to square 1. This direct coupling is what you wanted to avoid in the first place.

Enter Lua
In Lua you just have a single data structure, the table, which is basically a nifty, optimized hash map. So can we do better in Lua? Well, glad you asked! Sure we can.

First let’s throw that useless object-oriented garbage away ([1] and [2]). Once you realize that you no longer have to couple data and functions all sorts of fascinating possibilities start to emerge. Since you can dynamically add and remove table fields, why not just stash data for all of your components of a game object in a single table? Accessing another component’s data becomes trivial since it’s sitting right next to you in the same data structure. Once you have this then you can just use free functions to operate on your components and you can pass those object data tables around from function to function. No need for entity IDs.

A simple example:


local t = {} -- create a new empty object

-- create some components for t
init_model(t)
init_light(t)

-- call a component function
fade_light(t, 10.0)

-- and here is the implementation for the components

function init_model(obj)
-- init state for model component
obj.model_var1 = ...
obj.model_var2 = ...
end

function init_light(obj)
obj.light_var1 = ...
obj.light_var2 = ...
end

function fade_light(obj, target_brightness, time)
-- do whatever fancy stuff is required to fade light's brightness to target value
end


This 80s style no-nonsense programming is pretty much how objects in Druidstone are coded. Really, really simple and also reasonably efficient. There are just a few things to keep in mind. Since all components store their data in the same table, you want to avoid clashes with field names. A simple naming convention by prefixing the component name works like a charm. Secondly, you can have just one instance of a component per object. E.g. you can’t have two model components in the same object (unless you implement the multi model stuff directly into your component).

I could argue that in practice allowing multiple components of the same type per object is not so good idea. It’s quite expensive and unneeded special case for most objects. In those rare cases when you really need this, it’s usually better to just have multiple objects and perhaps link them somehow. The component system in Grimrock 2 allowed arbitrary number of components per object, but the price was that every component was stored in a separate table and every component had to be named so that when you referred to an component in an object, you always had to specify the component name. This system was very flexible but also more complex, less efficient and harder to use.

All in all, we have been building Druidstone with this new system for a year now and we’re happy to report that no major kinks have been found so far and working with the codebase has been a joy.

I hope this article was an interesting read. Thanks for reading!

Petri

[1] Wikipedia OOP criticism

[2] What’s wrong with object-oriented programming
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom