Category Archives: gamedev

In a point and click adventure game there are many rooms in which the actor’s distance to the ‘camera’ is more or less the same everywhere he goes.
But there might be rooms where perspective is important. Think long hallways, large outside areas, huge room, weird camera angles, etc.
Look at the picture below. These are a few examples of area’s where the actor can move closer to and further away from the camera:

When you play these games (Day of the Tentacle, Indiana Jones and the Fate of Atlantis, and Monkey Island II) these areas feel very natural. How the actor scales and moves depending on the location feels just right (most of the time).

Finally I had the time to finish this blog post (which I started writing quite a while back). This time it’s about adding gameplay logic to the game using Lua.
In an earlier post I explained how we separate our game code into several layers, namely the game framework, the game engine and the game(logic) itself.
Using the framework and the engine, we can build different games, since all artwork and gameplay logic is separated from these two parts. I explained earlier how the game assets (e.g. sprites) and room definitions are loaded into the engine and Jaap talked about loading the dialogue (see here), but we haven’t talked about where we define the gameplay logic, which actually makes the game the game.

Gameplay logic
So what happens when the player chooses to ‘pick up matches‘ for example? Where is that gameplay logic defined? What language is used? How is this separated from the engine? How do these parts communicate?

Wow this has been really some time off the game. We’ve actually run to the point of doing nothing for months, because after finishing a basic game engine – and being quite content with being able to make a prototype game to test its neat features – we’re quite daunted by the fact that we somehow have to start making lots and lots of graphics, sounds, etc and therefore have to start working on the more boring stuff of building a good tool for putting in these game assets, which should prevent pulling out hairs every time you want to test e.g. changing a parallax layer or a few altered pixels in a sprite sheet.

Anyway for the interactive dialogue, which this post is about, this tool should not be necessary, since the input format should be easy enough to edit and understand without needing a separate tool. Check out the previous two posts on this topic for some context on this.

Finally I have some time to write the follow up post on pathfinding part 1. Back then I went through the basic concepts of how to define the walkable area and the algorithms used to find the shortest path.
In this post I’ll dive in to the details, showing an example I created. Alongside this I’ll show several code snippets taken from our engine code.

Having extended the holiday slumber for way too long, let’s continue with interactive dialogue.

This time I’ll go through an input (YAML) file that shows all of the currently available interactive dialogue features, which I’ll try to explain in detail.

In the next (and last) post on this topic I’ll show you the layout of classes that make up our dialogue model & dialogue engine and finally an embarrassing parsing function that parses the input file and maps its contents onto the dialogue model.

Here’s a thing: point and click adventure games actually don’t offer that much in the area of gameplay, at least: when you look at the number of things the player can control.

For example, in other games like e.g. an RPG, a player can fight enemies using dozens of different strategies, choosing from hundreds of spells and abilities, buy or trade items, talk to people, etc; in Mario you can control jumping and running in the minutest detail and in most sports games the available controls try to mimic the real thing as closely as possible.

However, in a ‘typical’ point and click adventure game, the gist of things you can do are: walk around, pick up stuff, use stuff with stuff and talk with NPCs.

Of these things, walking around and talking to NPCs take up about 3/4 of the gameplay while working with objects (in your inventory) maybe only 1/4. More importantly, in general the player can only click on things to trigger a possible action, meaning that it is very well possible that certain clicks result in nothing happening. Also by emphasizing the word trigger, I mean that if successful the player can lean back and watch a result, without needing to be alert for any quick reaction.

What I am trying to say here is that since adventure games do not offer a great number of (“real-time”) controls to players, they need to excel in story and atmosphere. Those two things make why we love adventure games and why they seem to appeal a bit in the same way as a good book. Interactive dialogue discussed in this post, plays a big role in bringing the story, setting the atmosphere and giving the player part of the controls.

In this post, and following posts, I’d like to go into what interactive dialogue entails: what requirements we defined for it and how I went about implementing the underlying dialogue engine.

One of the fun parts of adventure games is exploring locations: walking around them looking for clues or just for admiring the wonderful artwork (we’ll get to that, much much later…)

From walking around a small prison cell – looking for a way out – to chasing an elusive character hidden in a vast office building either takes a few footfalls in a single room or the equivalent of a marathon spread out over various locations.

So how do you implement this ‘walking around’?
How do you define which parts of the screen a character is allowed to walk? How do you handle mouse clicks outside of those areas? How do you find the shortest path a character could walk to its destination?

In this post, I describe the general approach on how I take on these issues. Searching on the web you can find many ways to deal with pathfinding in 2d games. As it goes, I also checked a couple out, until I figured out a solution that is both easy to implement and serves our purpose.

Let’s take a look at the simplest case of pathfinding to illustrate what’s basically involved:Disclaimer: Because we have no artist in our team (yet), all art is either programmer-art (all static backgrounds and sprites) or animated sprites we temporarily “borrowed” in fair use.

In our first post we covered the requirements of our game engine and in the second post we showed its basic design.

In this post we’d like to cover the underlying technologies that tie everything together and run the whole 2d point ‘n click experience.

Programming language
We stated that one of the main criteria for our game engine is to be able to run on multiple platforms. This requirement made us have a look at what programming language would make it easier for us to support this in a convenient way and at the same time be suitable for us based on our combined experience.
The following shows a list of languages that did not make it and the reason why:

Platform dependent language We want our codebase in one language. So no language per platform (Objective-c for iOS, Jave for Android, etc)

HTML5
We don’t want it to be HTML5. HTML5 might sound ideal for multi platform but it has several limitations so it’s a no go for us.

C / C++
We are not completely comfortable using c or c++. Although we know what it can do and that it can support all platforms, we think there are more convenient languages that should be able to offer what we need.

C#
Although C# is a great language, and using Xamarin you can target many platforms, we didn’t go for it. It’s too Microsofty.

So here we are, merrily developing a 2d point and click adventure game.
That’s all great, but how do you develop such a game? What do you actually make? And where do you start designing?

In this post, we’ll go into the essential bit of designing and building a game engine.

The game engine offers the building blocks and mechanics for the game to be built with. It takes care of things such as drawing everything on the screen, making sounds, handling user input, etc. The following quote describes the concept pretty well:

“Generally though, the concept of a game engine is fairly simple: it exists to abstract the (sometime platform-dependent) details of doing common game-related tasks, like rendering, physics, and input, so that developers (artists, designers, scripters and, yes, even other programmers) can focus on the details that make their games unique.” (www.gamecareerguide.com)

So it is important to separate the code & data of the game itself as much as possible from the game engine. Since there can be a fuzzy line between the game and the game engine, we like to show you how we’ve dealt with this by starting out with a general picture of the main components that are involved. Continue reading Design of a point and click adventure game engine→

Groebelsloot is made up of two guys: both software engineering drones by day – slaving away for our bosses – and starry-eyed wannabe game developers by night.
With this blog right here we want to share our ongoing experiences of building a classic 2d point and click adventure game, addressing technical details, story writing, puzzle design and whatever else is worth mentioning.

Why this kind of game? Growing up in the eighties and nineties we, like many of our friends, loved the classic adventure games: Maniac Mansion, Monkey Island, Indiana Jones, Legend of Kyrandia, Broken Sword, etc.
For a loooong time wanted to develop such a game ourselves, but because of a string of boring non-adventure game related silly live events, we never did.

Finally the stars have aligned and we got started.

In this first post we want to go into the basic setup and approach of our 2d point and click adventure game.
In subsequent posts we want to go into much technical detail describing how we went about the realization of the various aspects of game programming. Code examples will be provided as well.

We like to think that even though the game we are building may never be finished or published at all, we want to learn something along the way and like to share and discuss it all with whoever is interested.