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).
What is it that it feels natural? And how do you implement this? Continue reading Scaling actors
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.
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?
Continue reading Adding gameplay logic using Lua
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.
Continue reading Interactive dialogue – part 3
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.
The source code is available on Github and you can use it any way you want. Continue reading Pathfinding in a 2D point and click adventure game – Part 2
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.
Now, let’s have a look at the example:
Continue reading Interactive dialogue – part 2
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.
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)
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.
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 what did we end up using?
*drum rolls, pigs screaming*
Continue reading Tech stack of a point and click adventure game