Old Testament Adventures » Behind The Scenes

What Is An Ebenezer Anyway?

andygeers — Mon, 27 Jun 2011 16:00:16 +0000

As regular readers of this blog will know, the working title of my Christian video game is “Ebenezer”. But what exactly is an Ebenezer?

The modern person is most likely to assume that Ebenezer is the name of a person. Perhaps the only context we’ve encountered the word in is Charles Dickens’ “A Christmas Carol”, referring to the miserly Ebenezer Scrooge. But this is most certainly not the word’s origin.

People from an older generation may well have come across it in the great hymn by Augustus Montague Toplady: “A Sovereign Protector I have”. The third verse talks about “a new Ebenezer set up”. Now we’re getting closer – but if you’ve ever sung that hymn, you may well have sung it scratching your head and wondering what on earth it meant.

The Ebenezer was a stone set up by the people of Israel as a monument to remind them that “til now the Lord has helped us” – for that is what the word means in Hebrew: literally “stone of help”. It’s explained most clearly in 1 Samuel 7:12.

This concept – that our help comes from the God of the Bible – is the main theological undercurrent running through the whole of the narrative that my game is based upon. The story is full of weak people: Israel itself appears as a weak nation, surrounded by powerful enemies on every side, oppressed and lacking solid leadership; the king they seek to appoint, Saul, turns out to be weak-willed and overpowered by his fear of man; and to an outside observer witnessing the situation without the eyes of faith, the God of Israel himself appears, by implication, to be weak and unable to help his people.

But when the Spirit of God enters the situation, everything is transformed. God is mighty to deliver his people despite their weakness – indeed, often through their weakness. The days have long since passed when our enemy is the Philistines or the Ammonites; instead, our great enemy is sin. So long as we depend upon ourselves and human strength in the fight, we’ll find ourselves stretched beyond our capacity, and ultimately end up demoralised. But when we look to God for our help, in and through the death of the King he has appointed, Jesus Christ, there we find the help we need, and the power of his indwelling Spirit to change us.

The Lord has helped us til now – and so let’s have faith that he shall continue to do so every day of our lives.

Behind the Scenes: Script Writing

andygeers — Thu, 23 Jun 2011 16:00:22 +0000

One of the major tasks left to do on Ebenezer is to finish writing the final dialogue. At the moment I’ve written out the entire story in very broad brushstrokes: “Samuel talks to Saul about X, Y, Z…” but I don’t know what words will be used in each of these conversations. Thankfully I have a friend who is helping me get started on the process, and it’s fair to say that it’s in a lot better shape now than if I was attempting to write it myself!

Writing the script is quite an interesting process: it’s a lot like making a movie. There are so many choices that you could make. Obviously you could just tell the story straight, but then it would probably be really dull. The eventual goal for Ebenezer is that it will be a lot of fun and hopefully make you laugh, and at the same time that it will be moving and challenging and make you think about God in a new way too. That’s a tall order!

If you’ve ever played LucasArt’s adventure games like Monkey Island then you’ll know that as well as the main dialogue for all of the cutscenes and the main story itself, there’s also a vast quantity of optional dialogue that many players won’t ever actually hear. Things like the descriptions for elements of the scene that the player may or may not ever click on, plus numerous alternative dialogue options when you’re in conversations with people. All these things are hugely important for adding colour and depth to the experience, but they don’t make it easy or quick to make a game like this.

One of the biggest challenges is how to actually represent what is largely a non-linear script: things can happen in many different orders. Exactly how LucasArts used to represent these things is a closely guarded trade secret, but for now we’ve just taken the approach of writing little globs of script attached to a “trigger” event (e.g. “when you click on this, say:”)

This post is part of a series attempting to post every day in the run up to the Christian Game Developers Conference

Behind The Scenes: User Interface Design

andygeers — Wed, 15 Jun 2011 15:05:01 +0000

With the Christian Game Developers Conference mere weeks away, I’ve been doing some long overdue work on the user interface for Ebenezer, the Christian video game I’m developing, in the hopes of having something I can show off to people I meet there.

I’ve heard it said many times before that designing an interface for a touchscreen application is an entirely different ballgame from designing for a mouse and PC – this is the argument people like John Gruber put forward all the time for why you probably don’t want Flash applications on your iPhone as much as you think you do. But I have to say, I’d never really believed it with any conviction until I actually experienced how awful my own game was to play on an iPhone. Until recently I’ve been doing all of my testing within Unity on my laptop, using the mouse cursor to simulate a finger.

But it turns out this kind of testing can only take you so far. In particular, you just think about the fact that in real life your finger totally gets in the way! All those pretty labels I’d stuck up on the screen telling you what you were interacting with – it was all useless, because you simply couldn’t see them.

For now I’ve settled on an approach where the labels move out of the way as you drag your finger around the screen, so that hopefully you should always be more-or-less able to see what you’re pointing at. Press and hold on an item, and a selection of different ways to interact with it will pop up, or just touch briefly on an object to perform the default action.

I’m sure there’s still room for improvement, but for now it feels pretty good, and allows you to easily explore what’s in a scene.

Character Closeups

andygeers — Thu, 02 Jun 2011 12:16:33 +0000

Here’s a little sneak preview of what I’m experimenting with at the moment: character closeups.

The characters are absolutely central to the whole experience of a game like Ebenezer, so I really want to be able to show them up close and personal whilst they’re talking.

Closeups present some interesting challenges:

Obviously there’s the need to animate everything, so they don’t feel horribly static.
Then there’s decisions to be made about background images – ideally it gives you some rough indication of where in the scene they’re standing and what’s actually behind them, but in a 2D scene that’s not always that easy
There’s also the issue of viewing angle – if you always show every character from the front, the viewer can end up feeling very disoriented trying to work out which way the camera is supposed to be pointing now.

Behind the Scenes: Path Finding

andygeers — Wed, 09 Feb 2011 14:14:35 +0000

In these Behind the Scenes blog posts, I’m attempting to give a bit of an insight into what goes into developing an Old Testament adventure game. This week I’m going to talk a bit about path finding – how I figure out how to move a character from A to B via a sensible route.

Let’s start with our basic scene, as per last week:

The first stage is that I have to mark the scene up with various “areas” that the player is allowed to walk in:

The white rectangle in the middle is the ‘active’ area; the yellow rectangles are directly neighbouring areas; the cyan rectangles are other areas that can’t be directly reached from the active area; and the pink rectangles are exits from the scene that the player can click on. Between each area you’ll notice a red line: these are “gates” and show the points where the player is allowed to pass from one area to the next. For convenience I’ve numbered the areas 1 through 6, and we’ll use the notation “x-y” to refer to gates if they’re between area x and area y (e.g. 1-2 is the gate from area 1 to area 2).

When the game first fires up, we need to calculate a cost matrix that specifies the shortest distance between any two gates, and (where applicable) which other gate you would first have to pass through in order to get from one to the other. I could explain how to calculate this, but I suspect I’d only bore you, so just take it for granted that it’s easy enough. You’d end up with a matrix that looked a little like this:

		To
		1-2	1-4	1-6	3-4	4-5
From	1-2	0.0	2.0	2.5	7.0 (via 1-4)	7.0 (via 1-4)
	1-4		0.0	2.0	5.0	5.0
	1-6			0.0	7.0 (via 1-4)	7.0 (via 1-4)
	3-4				0.0	2.5
	4-5					0.0

The next stage happens at the point where a route is required between two specific points. You begin by finding out which area the starting point and the destination point are in. Let’s say we want to walk between area 6 and area 5. We then test each gate in the first area against each gate in the second area (easy in this case because each area only contains a single gate) and look them up in the cost matrix to work out which is going to be the shortest route. In this example, we’d notice that the best route is going to be from Gate 1-6 to Gate 4-5 (both shown in green below), with a cost of 7.0, and we’re going to want to go via Gate 1-4 (shown in orange).

So that tells you the basic shape that the route is going to take. But exactly which point along each gate should we use? Our instinct might be to walk to the middle of each gate before continuing to the next one, but that might result in very inefficient routes that might look like so:

Sure it gets the job done, but it looks a bit cumbersome and unnatural. We can do better with a simple alteration: at each step, we’ll draw a line from our current position to the place we’re trying to get to. If that line directly crosses the gate we’re aiming for, then use that intersection point; if it doesn’t cross the gate, then we’ll use whichever end of the gate it comes closest to. That allows you to “cut the corner” and take a more obvious direct route:

And that’s it – job done!

Behind the Scenes: The Perils of Camera Panning

andygeers — Wed, 02 Feb 2011 14:43:42 +0000

Here’s a little insight into the kind of hard work that goes into make an Old Testament adventure game like Ebenezer. Today’s challege: camera panning.

A typical environment might look like this (this is the first scene – Kish and Saul’s farm at Gibeah):

But this environment is much wider than the screen of an iPhone, so the player will only see a tiny segment of this at any one point in time:

The aim then is to automatically pan the camera back and forth so that the player’s character remains visible on screen at all times. Roughly speaking, you want to wait until the player enters some fixed boundary around the edge to give yourself a bit of a headstart, rather than waiting until the player actually leaves the screen. Since the player was probably walking somewhere, you probably want to scroll a fair distance too, to let them see where they’re going. If all you did was maintain a fixed distance from the edge of the screen you’d feel very claustrophobic. So, once the camera starts to pan, I make it carry on moving until the player ends up about a third of the way from the opposite edge of the screen:

So far so good. But then we hit a snag: walking isn’t the only way that the player might end up too close to the edge of the screen. It can also happily naturally when the camera begins to zoom in on the scene. The last thing you want in this situation is for the camera to suddenly whizz off to one side – in this situation you really do just want to do the bare minimum to maintain a certain distance from the edge of the screen. The key is to make the code that looks after zooming the camera a bit smarter about which point it zooms in on – rather than always zooming in on the centre of the screen, it can pan as it zooms to keep the player’s position constant. As long as this adjustment is made before the main camera panning algorithm runs you should be fine:

It turns out to be a fairly simple solution in the end, but imagine a hundred such little decisions and you begin to see why developing a game takes a long time.