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!



  1. Sounds interesting. I’m looking forward to see more screenshot and details of the game.

  2. You should have ‘grass rendering’ as your #1 selling point 🙂 Maybe rename whole game Grass – Life 3.

    I’ll let myself out ;0

  3. I know Petri is a big proponent of Lua (I used to be one too), but damn, how do you guys manage to pick up all those runtime bugs without static analysis and quality intellisense. It’s amazing!

    • Nice comment. I think it boils down to:

      1. Interactive / live coding
      2. Small, senior team

      Let me try break these down.

      We can do hot code loading while the game is running. If the code you load from the editor is called by the render loop, you can see the results in a fraction of a second.

      This makes it very easy and efficient to do very small changes, and verify the results in a real live environment every few lines of code you write. When you make changes in very small batches, you can’t make that big mistakes either. The cost of mistakes is also very low, as you can change & verify the code in seconds. This also reduces the value of unit testing / test driven development (TDD). I’ve noticed that when working with languages that have a good read-evaluate-print-loop (REPL), you don’t get as much value from TDD and unit testing as you do with slow compile & execute loop. What I have seen so far, this seems to apply in Druidstone as well.

      And we do have intellisense, just without types. Here conventions help, but if you’re still unsure, you can check in seconds with the live coding environment or using the tooling to e.g. navigate to the function in question.

      The downside is of course that static typing breaks down. Making changes to your basic types and still keeping the game in a running state sounds like mission impossible. I am myself a fan of static typing. A strong one that actually helps you, like my favorite language F#, and not a weak one that just makes you, the programmer, serve the whims of the compiler. But I think that in this case, the benefits of dynamic typing actually exceed the cost. But I do miss the refactoring support typing provides.

      Having a small team of seniors also helps. There’s only two of us programmers: we know the code pretty well, and we can communicate the changes we make very effectively as we sit in the same room. Seniority means that we don’t do that many “simple” mistakes that would be caught by static typing and analysis, but instead we make difficult and complex logic bugs that would not be caught by the compiler and analysis anyway 😉 During the three months I’ve been here, I’ve seen only a handful of bugs that would have been prevented by static typing.

      The future will tell how well this actually works out. But I’m confident so far. 🙂

      • Thank you for the reply, Jussi!

        I didn’t get a notification so I almost missed it. I’m yet to be exposed to this live coding thing. People say it’s amazing and I can see why. I just have no direct experience with it. Yeah, small team helps a ton! We also have just two coders on our team (including myself) and so communication and understanding of what does what is easy. And essential!

        For me, Lua is a love-hate thing. 🙂 It can get so frustrating at times, yet it’s so straightforward and powerful at others! For instance Petri’s article about object decomposition, the style of coding in Druidstone, that demonstrates how neat and useful Lua can be.

        As for the intellisense, you say that you have that. I reckon you’re using some advanced IDE for that? Very few programs can provide useful intellisense for Lua.

  4. I just found out about this project. Excellent, now I have a game to look forward to! Turn-based combat is absolutely my favorite, although real-time play suited well for Grimrock games.

    As I play almost exclusively only single-player games, I hope Druidstone will have an interesting story to follow, but also that you can progress your character(s)/group composition in multiple playable archetypes to increase replay value. Completing LOG2 several times with different party builds was very fun even with the later iterations, when the island, monsters, and puzzles were very familiar.

Leave a Reply

Your email address will not be published.