I'll be honest with you: I was not a big fan of Grim Fandango. I found the new 3D user interface frustrating, as well as many of the puzzles being obscure and unsatisfying. Even Tim comments on this: "reading this again, I’ve realized that holy smokes--Some of them puzzles were nuts. Obscure. Mean, even." But that doesn't mean that I can't appreciate quite how monumental an occasion this is, as we the public get an inside glimpse into the mind and workflows of a man who lovingly crafted some of the most influential experiences of my childhood, such as the inimitable Day of the Tentacle.

I use that word "crafted" because that's exactly what this newly released document shows: true craftsmanship. We see the incredible attention to detail, the pacing of the narrative as it builds and as the puzzles get increasingly sophisticated, always coaxing the player along with them. As somebody whose spent the last few years trying to write my own adventure game, what struck me most about this document is the sheer simplicity of it - it's well established that it takes a great deal of clarity and hard work to boil down something so vast as Grim Fandango into such a simple representation that conveys so much information in such a succinct way.

This is an incredible boon to amateur adventure game developers like myself, to get an insight into the creative process like this. Techniques such as the puzzle flow diagram is an incredibly useful tool for visualising the flow of the narrative and how the puzzles build and relate to one another - simple as it is. This is exactly the kind of help I needed to give me some very welcome motivation. Tim Schafer, I thank you! This is truly a precious thing you have given us, when it probably seems so ordinary and everyday for you. Now, Ron, how's about doing the same thing for Monkey Island? :-)

Image by strangeaeons

1. They give us a sense of belonging

When talking about his new book "Tribes", marketing guru Seth Godin said this:

"Harley Davidson and Apple are titanic brands for the very same reason. They sell a chance to join a group that matters"

If you go to a web community conference like BarCamp or the Google Developer Day, you can't help but notice that 90% of the people there seem to have a MacBook on their laps. The message is loud and clear: "if you were really a part of our club, you'd have one too." It's the same thing that causes school kids everywhere to spend such large proportions of their income on brand name clothes - worshipping the right branding gods shows that you're a member of the tribe.

2. They cast a large shadow

Brands are held in awe - consumers flock to them, competitors fear them, employees find security under their wings; brands stand immovable and unshakeable, at least they like to think they do. I've long known my own idolatrous heart has been drawn to big brand companies when looking for work because of the prestige that working for one seems to convey. Buying your DVD player from Sony somehow feels safer than buying some unknown brand - you feel confident in the quality of your purchase, whether or not that's well-founded. As the saying goes, "nobody ever got fired for buying IBM."

3. They own their part of the world

Just like the idols of the ancient world were restricted in their field of influence, so it is with modern brand names. Where Demeter was in control of your crops succeeding or failing, so Microsoft dominates your office productivity; where Poseidon ruled the seas, so Google rules the world of the internet. To guarantee success across the board, the ancient pagans were forced to offer sacrifices to as many different gods as possible to make sure they covered their bases. After all, what if the one god you missed out ended up being the very one you ended up needing a favour from? Equally, it is not sufficient for the modern man to wear the right clothes if he does not not also own the right television or have the right job with a sufficiently well-recognised City firm.

The pressures of idolatry facing us today really aren't that different from those faced by the Israelites back in the Old Testament. They were eager to avoid standing out from the nations around them, for example when they begged Samuel to appoint for them a king, "that we also may be like all the nations"; they feared that limiting their worship to just one God, the Lord, might incur the disfavour of another to their detriment; they often sought to make alliances with other, more powerful nations by worshipping their gods.

The antidote: worship the all-powerful Creator

The Bible's antidote to their idolatry was to show how ridiculous it was in the face of God's amazing bigness:

"Hear the word that the Lord speaks to you...: Their idols are like scarecrows in a cucumber field, and they cannot speak; they have to be carried, for their cannot walk. Do not be afraid of them, for they cannot do evil, neither is it in them to do good... they are all the work of skilled men. But the Lord is the true God; he is the living God and the everlasting King. At his wrath the earth quakes, and the nations cannot endure his indignation... It is he who made the earth by his power, who established the world by his wisdom, and by his understanding stretched out the heavens. When he utters his voice, there is a tumult of waters in the heavens, and he makes the mist rise from the ends of the earth. He makes lightning for the rain, and he brings forth the wind from his storehouses."

Whereas their false gods were limited in their sphere of influence, the Lord made the whole world and has ultimate power and authority over every inch of it. At the end of the day, our modern brands are but the creation of human hands, who were themselves made by the one, true God. Our fear is often really just the fear of men - how foolish it looks when confronted with the almighty God?

So let us not fear the false gods of this age, but respond like the Thessalonians: who "turned to God from idols to serve the living and true God" - the one who made the earth by his power.

What is a Graphic Adventure?

But first, what do I mean by a graphic adventure, or Point & Click adventure game? The classic examples I’ve used in the past have been Monkey Island and Day of the Tentacle. The creator of Monkey Island, Ron Gilbert, described the graphic adventure in this way: “games in which the pace is slow and the reward is for thinking and figuring, rather than quick reflexes. The element that brings adventure games to life for me is the stories around which they are woven.” They’re games in which the characters and the story are the focus, and players move forwards by solving puzzles and interacting with those characters. So what is it about them that make them so great for teaching the Bible? Here are five reasons that I’ve come up with, but maybe you have more!

1. A Focus on Narrative

It hardly needs saying that a large chunk of the Bible is in the form of narrative, stories in which we see the character of God in the way that he interacts with his world and his people. Teaching such narrative involves two things: the events themselves – what is actually happening – and then the significance of those events. It’s not enough to know that David killed Goliath – what is the narrative teaching us about God’s character when this unarmed Israelite shepherd boy slays the mighty pagan warrior with a single shot of his sling? When I tell people I’m making a Bible-teaching Computer Game, their first instinct is to assume I’m making some kind of First Person Shooter, “David the Giant Slayer”, in which you run around with your sling shooting pebbles at people. But even if such a game could succeed in teaching people that there was a guy called David who killed another guy with a rock (which is a problem in itself, given the possibility that you might miss!) it would be very hard to explain the significance of those events in an FPS game. Contrast that with a graphic adventure, however, where your character could watch David kill Goliath, and then go and talk to him afterwards and ask all sorts of questions about why he was so angered by Goliath’s defiance of the armies of Israel and what the source of his courage was.

2. Stories Take You On a Journey

One of the common objections to the idea of Christian computer games is the assumption that nobody other than Christians would ever want to play them. Looking at some of the games already out there, I’m inclined to agree! But one of the brilliant things about telling a story is that it lets you take your player on a journey – from disinterest to curiosity, from unbelief to faith in Jesus Christ, or from faith to ever more wholehearted living. Every great story involves a character changing in some way, learning from their mistakes and ultimately overcoming adversity. It’s exactly the same with great Bible teaching – it should never be a merely intellectual exercise, the imparting of knowledge without changing the way you think and behave. At the start of Monkey Island, Guybrush Threepwood had no idea what was involved in being a pirate, but by the end he’d learnt how to swashbuckle with the best of them. The whole point of a Graphic Adventure is to take the player on a journey, and that makes them an ideal medium for teaching the Bible.

3. Puzzles Make You Think

It probably sounds tautological to say that puzzles make you think, but that makes them fantastic as a way to help people apply what they’re learning from the Bible. Suppose you’ve been hearing a sermon about the sovereignty of God – how he is completely in control of events. The exact question your Bible teacher is wanting you to start asking yourself during the week is “how should I act in this situation if God is sovereign?” The puzzles in an adventure game can encourage you to do just that – find a way forward given the premise of the game, in this case that God is sovereign. Figuring out what those puzzles might be and thinking of suitable solutions for them is the tricky bit, but my experience so far is that when it’s done well it can be a really powerful tool for application.

4. They’re Fun To Play Together

When I was a kid, before the days of the Internet and multiplayer gaming, I used to invite one of my friends round to play on the computer with me, and inevitably one of us would be pretty bored for most of the time, as we sat there watching the other person playing. As other people have noted, most games give you a certain sense of satisfaction simply from interacting with them – steering your car, firing your gun, jumping between platforms. That means that gaming is really not a spectator sport – it’s boring for the person watching who is not getting that constant stream of satisfying feedback. By contrast, virtually all of the adventure games I played as a kid were played together with somebody else, without being the least bit boring for the one ‘observing’. That’s because the emphasis is far less on the basic interactions of gameplay – there is little thrill in instructing your character to pick up an inventory item. The reward comes from solving puzzles and making progress – something that can be shared equally by both the person doing the pointing and clicking, and the person by their side giving the ideas. Some people have highlighted this style of gameplay as a downside of adventure games – and it certainly does mean a certain amount of patience is required, meaning these games are not for everybody – but I think it’s the key to making them fun to play together. Parents might enjoy playing a Bible-teaching adventure game together with their child as a shared experience, or two siblings could enjoy it together.

5. People Grow to Love Them

This final point is a result of all that has gone before – rich stories with vibrant characters, taking you on a journey as you think through puzzles, perhaps in a shared experience with another person – all of these factors mean that people grow to really love adventure games. When I talk to people who’ve played Monkey Island, their eyes suddenly light up and their whole body language exudes an enthusiasm that I don’t often see when talking about computer games. Like a good novel or a beloved movie, great adventure games seem to capture a space in people’s hearts. Imagine if people were being made to feel that way about a game based on a Bible story – what a fantastic positive memory to leave people with.

So there you have it, my top five reasons why adventure games would work brilliantly as a way to teach the Bible. It’s my hope and prayer that my own Bible-teaching computer game will be able to put these ideas into practice and help people to learn how fantastic God’s word really is!

I've had one of those rare weekends of having pretty much nothing to do whatsoever - praise the Lord for a very welcome break! It gave me a chance to do a bit of coding just for fun, and after discovering a brilliant website called Wordle I decided to make a mashup with Bible Gateway. The result: The Wordle of God. Whilst it's basically just a lot of fun, I think it also has potential as a really useful tool for getting an overall feel for a Bible passage and what the dominant themes are.

In the absence of something more profound to post, I thought it would be a fun little exercise to post a bit about the books, websites and places I've been enjoying over the last few weeks. For the uninitiated, my life is essentially one big routine, so this is a bit of a reflection of how I spend my days!

Morning Commute

I live in the East End of London and work near Tottenham Court Road in the West, so I basically have two choices for how to get there each morning:

1. Central Line from Mile End to Tottenham Court Road - this is definitely the quickest route to work, taking about half an hour for me door to door. The downside is that the Central Line is absolutely rammed at half eight in the morning, such that you'll probably have to wait for several trains to pass, and then once you do squeeze on you may not always have much room to get a book out and read it
2. District Line to Embankment and then Northern Line to Tottenham Court Road - ah, much nicer! You can probably get a seat for much of the journey, making reading much easier. Shame it takes more like 45 minutes, though.

As for what I read: the morning is my time for reading a good Christian book to help my hard heart to meditate on God's character. At the moment I'm reading the excellent Knowing God by Jim Packer - it's one of those books I'd recommend every Christian to make a habit of reading regularly. I last read it about five or six years ago, and am finding it every bit as edifying the second time around.

My general criteria for my morning book is that the author should write in points short enough to read in their entirety before reaching your destination, but ideally with a bit of time left over to chew on what you've read and take it in properly.

Before Starting Work

1. Twitter - it doesn't take a minute to update your status once a day, and keep your Facebook friends up to date on the latest goings on in your life
2. Various comics - at the moment I love reading Pearls Before Swine and F Minus
3. Remember the Milk - I've only just discovered this fantastic website, but it's great for helping overcome that sometimes overwhelming feeling that you've got so much personal admin to do and no chance of remembering all of it
4. Google Mail - I resisted for ages, but having gotten the Google Mail bug I now use this exclusively for all my mail, forsaking my previous approach of downloading all of my mail onto my main computer on a regular basis and only having unread messages available through webmail.

Lunch Time

1. Russell Square Gardens - a bit of a walk from my office, but a beautiful little spot to sit and eat your lunch, read a book or have a quick pray

View Larger Map
2. The Covent Garden Talks - every Thursday lunchtime a bunch of Christians meet together on Endell Street to hear the Bible explained in way that's really accessible to non-Christians. It's a great resource to invite colleagues to, and to equip us to server God in the workplace.
3. Google Reader - my 'sit-at-my-desk' lunch option is to go on Google Reader. I follow quite a lot of blogs, mostly programming ones. My current favourite is Jeff Atwood's Coding Horror.

Banana Time

My whole family has a weird tendency to get the jitters just before dinner if we don't get some sugar in us, so I make a point of eating one of the bananas my company freely provide us with at around 4.45pm. It makes a nice opportunity for a little break, where I often visit Hacker News for some thought provoking discussions.

Commute Home

The Central Line is much quieter at the time I go home, so I virtually always use it. In the evenings I tend to go for a secular book, and have just finished an excellent book called Dreaming in Code by Scott Rosenberg. It's a very well written discussion of what makes software so incredibly hard to write, following the story of OSAF, the creators of the Chandler Project. I shall probably post some more at some point about some of the idea it's given me for how to move forward with my Bible-teaching computer games project.

Evenings

Recently I've found my evenings to be pretty busy. I'm involved in a church called St. Helen's, Bishopsgate, where I help to lead a student Bible study group. This year we've been doing a Bible Overview, which has been absolutely fantastic. I'm a bit sad to part with my lovely group now that they'll all off for the summer :(

If you're ever in the City area on a Sunday night, do come along to our 6pm service!

Summary

Well there you have it - my life in a nutshell!

On 4th September 2005, in God’s great sovereign plan, I started work as a software engineer in the Digital IT department of the Trinity Mirror newspaper group, working on their online titles. It was a surprising move, in some ways: my passion has always been for computer graphics and games development, and it’s fair to say that web development had only ever been a sideline for me up until that point. My priority at the time, however, was to get a reasonable job that would enable me to still have a life outside of work so that I could get involved in a church where I’d be built up and equipped to serve Jesus in the long term, and Trinity Mirror seemed like it would offer that. In the event, it exceeded my expectations in every way, and any doubts I may have had quickly vanished. As a green young developer with little experience of the realities of programming in a real-world team it was a privilege to work with the very talented group of developers they had working for them, and I shall be forever grateful for the masses I learnt there about how to make great software, working on sites like Adzooks.co.uk and the rebranded Liverpool Echo and similar regional newspaper sites. They taught me the joys of agile methodologies like Extreme Programming and Scrum; they taught me the importance of actually talking to your customers and not just assuming that you know that they want or even that they know what they want; they taught me how (and how not) to write maintainable code (or at least why it matters!); they certainly taught me the utterly incomprehensible choice of a language that is Coldfusion; but above all they instilled in me a deep routed desire to avoid the cheap and easy hacks and implement the right solution in the right way.

So what changed?

For various reasons I’ve been getting increasingly itchy feet for some months now, wanting to move on from Trinity Mirror. Whilst it’s not appropriate to go into the details here of exactly why, I’d like to share with you the following lessons that I’ve learnt about myself through the perspective of my growing discontent:

1. I’m a sinner. My colleagues will have had no problems identifying my many flaws, although I suspect they might think nothing of that which I consider most serious: my lack of thankfulness to God. It’s a testament to the depths of human depravity that when there were so many absolutely awesome things about this job I still managed to grumble my way through my last few months.
2. Building something people want is way more interesting than exposing them to more advertising. Paul Graham is always going on about the fact that the best way to make wealth is to build something people want, but I’ve discovered through experience that it’s also the most satisfying kind of work I’ve ever done. I’ve only really just worked out why it was that working on Adzooks.co.uk was consistently the most interesting and enjoyable aspect of my job, and it’s this: when working on Adzooks, we were focussed on giving end users a more useful and more satisfying experience, often without any clear means of monetising it. The less satisfying projects were the exact reverse. There are some incredibly boring ways to make money out there, and also some awesome products with no strategy for making money whatsoever – but they’ll find a way some day. If I didn’t already, I certainly know now which of those I’d rather do for a living.
3. I work best when my productivity levels are easily seen (for better or for worse). This is really a corollary of number 1 – I’m a sinner, who is both lazy and proud, and my behaviour in the face of changing circumstances has revealed that ugly truth. The loss of a great manager who was always aware of what I was up to and gave frequent feedback; a growing team where the contributions of individuals is harder to spot; a form of Scrum where the perception is that as long as you deliver what you committed to at the start of a fortnight there’ll be no questions asked – all of these things slowly began to sever the connection between how hard I worked and my standing within the team. The standard set for me is to “obey in everything those who are your earthly masters, not by way of eye-service, as people-pleasers, but with sincerity of heart, fearing the Lord” (Colossians 3:22), and yet instead people-pleasing seems to so often be the driving motivation, with sincerity of heart barely getting a look in. It’s easy to work hard when people will praise you for it; it’s far, far harder to keep pressing on when the hope of the Lord Jesus’ commendation is the only motivation on offer. On judgement day I shall have no defence but to plead the blood of Jesus who died to defeat such sin – and praise God for such a hope! For one day, by his grace, this sinful nature of mine will be overcome, and I shall be free to serve him perfectly as I long to do. In the mean time, give me small teams! Give me feedback! Give me high visibility of my productivity.

Finally, do I have any parting words for my co-workers?

1. A huge “thank you” for everything. You’ve been great. It’s been marvellous fun. We’ve drunk a lot of tea.
2. Be the change you want to see in the codebase. Don’t just grumble about the state of legacy code, get on and refactor it. Live the dream! Make things just a little bit better every day, placing your mark on the world. Be a garlic programmer.
3. Never be content with mediocrity. You’re all smart, talented people. Yes, even you. Don’t settle for things the way they are – always be looking for ways to make things better. Read everything and anything you can get your hands on – you’ve got some great books on that shelf of yours! Question everything – why did that break? What could I have done differently to prevent it? What am I going to do differently to prevent it happening again? How will this change I’m about to make affect how hard this code is for other people to maintain?
4. Make plans for eternity. Jesus may seem like a humorous joke to you at the moment, but one day you will die, and on that day you will meet him as your judge. “Of this God has given assurance to all men by raising him from the dead.” (Acts 17:31) I know it seems unlikely, but if it’s true then it’s so profound that it changes everything – isn’t that worth spending a few hours of your life to at least look into it?

Farewell, Trinity Mirror!

The Importance of Feedback

I've been developing an engine to make 3D Point & Click adventure games for a few years now, and I have to admit that for much of that time I've been in a state of denial about how hard it would be to get content out of my 3D modelling package, Blender, and into my game. I'd only ever used pre-existing .X files for all my testing (good old Tiny.x!) and since Blender ships with a Python script for exporting DirectX files I wrongly assumed it be trivial to start creating my own when the need arose.

However, when I eventually tried it, it seemed to fail every time. The author was great at replying to my emails, and he was always able to diagnose some obvious flaw in the way my mesh was configured that was causing the exporter to stumble - "you've got a negative scaling factor", "your armature isn't parented to the mesh properly", "you're using envelopes instead of vertex groups for skinning", and so it went on. These things were obvious to the author, since he knew exactly how the exporter worked and what assumptions it made, but to someone like me who'd never delved into the source code, all I knew was that my mesh wasn't working properly and that I wasn't being given any feedback to help diagnose the problem.

There's a lesson in there: never let your software fail silently. If your user has ticked the "export animations" button, there's a good chance that they think their mesh contains some animations. So why not check that you agree? If their mesh doesn't contain any vertex groups that match bone names, and your code is built on the assumption that there are, it probably wouldn't hurt to tell them.

The Mystery of Someone Else's Code

Eventually I realised that I couldn't rely on the author debugging my meshes for me forever, and that I was going to have to get my hands dirty to figure out why my mesh wasn't working. I very quickly discovered what people have been telling me for years: it's far, far harder to read code than it is to write it. I wasn't helped by the fact that I'd never written a line of Python before in my life, nor did I have any knowledge of the Blender API. To be honest, I really rather enjoyed the challenge of figuring out this mysterious piece of code. Here are some of the tricks I used in my siege upon the citadel of mystery:

• Treat every line of code other than the one you're actually interested in as a black box that you don't need to understand. This was helped by the fact that the exporter was nicely broken up into lots of beautifully short functions, so to begin with I could ignore all of them except the entry point. I've seen plenty of people give up and go home because they wanted to understand a complex system in its entirety, and the challenge was just too great. Gradually, over time, strongholds began to fall as I captured functions into my empire of understanding
• Rewrite the code where necessary so that it documents itself. Many of the functions and variable names were either unenlightening or plain misleading. Here's an example: the exporter gives the user two buttons, "Export All", and "Export Selected"; which of those buttons do you think the 'SelectObjs' method belongs to? Well, for some unfathomable reason, that's the function that exports all objects. Rename it! I'm a strong believer in having plenty of comments, but I'm an even bigger advocate of the idea that the code itself is the best explanation of what the code does (it's certainly the easiest to keep up to date!) so it should be made as readable as possible by using sensible function and variable names. Got an argument called 'obj' which is always a 'Mesh' object? Rather than adding a comment to the code, why not rename it to 'mesh_obj' so that it comments itself? Conversely, if you have a variable called 'mesh_obj', make sure it doesn't sometimes contain an 'Armature' object!
• Liberal use of debug output - whilst you're in the process of understanding some code, don't be afraid to make it output all manner of superfluous debug information to help you get a feel for what values your variables hold at different points. Similarly, it's helpful to explicitly document what assumptions you think the code is making about the contents of its variables (in C++ I've started to use 'assert' for this a lot more than I used to). Sometimes I've even used this in cases where you think it can't possibly be necessary, and unearthed some really obscure bugs - for instance, if you're convinced (and relying upon the fact) that two expressions are equivalent (e.g. you think that parent_matrix * my_matrix = combined_matrix) then by outputting the two expressions you can get a very helpful clue when you realise that they're actually different.

Making it your own

Having started to understand the code a bit better, I gained the confidence to start making some improvements of my own. Here are some of my favourites:

• 'Why' not 'how' - the original version of the code contained a good dozen instances of this line: name.replace(".", "").replace(" ", "_"), to deal with the fact that object names inside a .X file can't have dots or spaces in them. Now, in some ways this seems harmless enough, but I wanted to factor it out into a method call anyway, just because I've got a strong dislike for 'copy and paste' coding. I could have named the method, "remove_dots_and_spaces" (a 'how it does it' name), but I've come to realise that a semantically descriptive name is much more useful, so I called it "make_x_compatible_name" (a 'why it does it' name). By doing that, it got the creative juices flowing, and I started thinking about what else might cause a name to break your .X file, and came across an example where using a reserved word (e.g. 'string' or 'integer') as a name caused it to break. Having a method factored out made it trivial to add some code to check for reserved words, and the change then immediately applied everywhere that method was used. Fantastic!
• Pythonesque-ness - I can't say for sure, but one got the impression reading this code that, like myself, the original author wasn't a native Python speaker. I had great fun and learnt all sorts of neat things by rewriting things to be as Pythonesque as possible. I think so far my favourite Python feature is list comprehensions - the ability to generate new lists based upon old lists in a single line of code, a sort of combination of map and filter all in one neat piece of syntactic sugar. In my view, rewriting the code to be more 'natural' Python makes it a lot more compact and readable - it allows the intent to show through more clearly without being distracted by the means.
• More robust error handling - I've added a great deal of code to the exporter that spots problems with how your mesh is configured and reports back to you. Hopefully that means it will be a lot more useful for real life work by real life people. One of my goals was to fix anything within the exporter that would require 'fiddling around' by the artist, since code in the exporter only needs to be written once whereas there are a lot of 3D assets to be made, and the exporter needs to be run again and again.

“Never again,” I told myself. From now on, let’s always pick the most important feature and prioritise that. Yet barely a few weeks had gone by when I found myself in the exact same situation, frittering away my time on an annoying piece of code that actually wasn’t all that important, whilst the real meat left untouched in some other part of the system. So I asked myself how it had happened. Where was the bug in my process? What it came down to is this: my granularity of features was too large. Sure, the most important thing that needs doing today is the Doodad Whatyajibbet, but is it really true that every single line of code I’m writing under the Whatyajibbet umbrella is really equally important? The answer, in my case, was a resounding no. Yesterday, the Doodad Whatyajibbet was my critical path, but now that 70% of it has been implemented, it’s the FlimFlam MegaDoowhat that’s standing in the way of real progress. Getting this wrong is a disaster for motivation in the long run, because you get into situations like mine were you've spent six months faffing and essentially have nothing to show for it. What's more, my days at home when I get to focus on my game are a precious resource that I really don't want to be wasting - good stewardship of this amazing gift God's given me demands that I use them wisely.

This is one of the things that agile methodologies like Scrum really help you with, if you do them well. You break your projects down into the smallest work units that make sense on their own, and then each sprint you pick the user stories that are going to give you the biggest return on investment.

So here’s my battle plan moving forward:

• Each day, pick the smallest work unit that’s standing in the way of progress
• Implement as little as you can to see the benefits you’re after
• Deprioritise mercilessly the things that won’t move me towards my goal

I Don’t Play Games to be Preached At

There are many people out there who consider the very concept of an explicitly Christian computer game to be fatally flawed. “Surely,” they say, “the whole reason I play games is to relax and have fun, not to learn, and certainly not to be preached at.” But to say that learning and having fun are mutually exclusive is simplistic in the extreme. Anyone who’s ever played LucasArts' classic adventure game “Day of the Tentacle” will remember the scene where one of your characters, Hoagie, gets stuck in a hotel 200 years in the past with America’s founding fathers. They’re all busy drafting the Constitution, and by talking with them you can learn all sorts of useless trivia. For instance, I learnt about George Washington’s penchant for chopping down cherry trees, about his wooden teeth, and about John Hancock writing his signature extraordinarily large in order to impress the ladies. Okay, so maybe it’s not all true, and teaching history probably wasn’t forefront in the minds of the designers, but the truth is that I did learn. What’s more, far from making me groan as though I was back in the schoolroom, it was tremendous fun and instilled an interest in that period that’s still with me to this day. I’m sure that we learn a massive amount by subconsciously soaking in information in this way from games and television and what have you, not to mention their cultural values. A Christian computer game that does this well could have a wide-reaching influence on a large number of people, with them genuinely enjoying playing it and without them feeling preached at.

Morality is Boring

An overreaction to the first problem, however, has lead some games designers to put less emphasis on Bible-teaching, worrying that it will feel preachy, and focus instead on promoting Christian values and morality. On the one hand, I don’t have a major problem with games like this, so long as they’re well made. After all, it’s probably better that our young people are playing something based on a Christian worldview than something that reinforces our culture’s distorted value system. On the other hand, they make me a little uneasy, since they just seem to be perpetuating one of the most pervasive fallacies about the Christian faith: that it’s first and foremost about rules and regulations, and being a “nice” person – and ultimately that’s pretty boring. The Bible, on the other hand, is clear that no amount of Christian morality will save you if it doesn’t flow out of a relationship with Jesus Christ. In the book of Colossians, for instance, Paul reminds his readers of the pre-eminence of Christ, the one in whom “all the fullness of God was pleased to dwell, and through him to reconcile to himself all things, whether on earth or in heaven, making peace by the blood of his cross” (Colossians 1:20). He shows how his ministry is shaped by seeking first and foremost to proclaim Christ (1:28), toiling and struggling to make sure that people are mature in their relationship with him. He goes on to warn of any alternative teachings based on “philosophy and empty deceit, according to human tradition…and not according to Christ” (2:8), and berates those who insist on asceticism and the worship of angels, but without holding fast to Jesus, the Head (2:18-19).

So you see, the goal of all authentic ministry is way more exciting than encouraging people to be more like Ned Flanders – it’s about introducing people to the person of Jesus Christ, and helping them get to know him better and better. A game that focuses on the awesome character of God is automatically going to be more engaging than one which just tells them how to behave.

Are You Worthy?

One of the main obstacles that stands in the way of people growing to know Jesus better, of course, is the sense that they have no need of knowing him better. Only people who know they can’t earn their own way into God’s good books are going to truly cry out for a saviour. My relationship with Jesus is constantly blighted by a sense that I don’t really need him – absurd as this is. It seems to me that this is one of the biggest danger areas in making a Christian computer game, since typically the aim of most games is precisely to earn your way to the finish line, proving your worthiness for all to see. That’s what the glamour of the High Score Table is all about, and it’s in direct conflict with the Christian message we’re wanting to promote. One Christian game even made it their official tagline: “Are you worthy?” It’s clear that a good deal of thought is going to have to be put into the game mechanics to make sure that our dependence on grace is not undermined, as well as other Biblical doctrines such as God’s sovereign control over the outcome of events.

Point & Click Bible Games

You may have guessed from my earlier reference to “Day of the Tentacle”, but I actually believe pretty strongly that a genre with great potential for solving some of these issues is the Point and Click Adventure Game. If you don’t have a clue what I mean by that, a good place to start would be the Monkey Island fansite The International House of Mojo, or the ScummVM project. These intensely story-driven games give the writers plenty of scope to teach in a more subtle way, as well as making it possible to feature a less-than-perfect lead character. LucasArts has a long tradition of rather weedy protagonists, like Guybrush Threepwood, Bernard Bernoulli, and (if your memory stretches that far back) the somewhat second-rate reporter Zak McKracken. Such down-to-earth characters allow you to easily convey the fact that there’s nothing remotely worthy about them, and to keep the spotlight firmly on God.

I’ll confess that I may be biased by the fact that I just really love adventure games, but I can see enough reasons to at least give it a try, and pray that God can use the results to bring glory to his name as people come to know his son more deeply.

I had a disturbing realisation the other day when I was asked to put together a code sample for a job application – I can’t think of a single piece of code I’ve written that I’m actually proud of. In fact, even ‘proud of’ is probably setting the bar a bit high – I can’t really think of many things I’ve written that I wouldn’t be ashamed of showing to a potential employer.

Now that, in itself, doesn’t actually worry me too much. In the context of applying for a job, I could talk at length about what’s wrong with how I’ve coded things and how I’d do it differently were I to start again – that kind of stuff actually makes for quite a good interview. I suspect that a large part of the reason I have so little code to be proud of at this stage in my professional development is simply that most of the things I’m programming I’m doing for the very first time – the first compiler you write, for instance, is bound to be a hopeless mess, because it’s often only in the coding of it that you figure out what on earth you’re doing. What’s more, as I learn the right way to code these things, my tolerance for ugly code diminishes – I often find myself flinching at little idioms I used to use with such abandon. It’s even been said that the very thing that distinguishes amateur coders from professionals is realising that everything you write sucks!

So the existence of shameful code doesn’t cause me to despair. Of more interest to me, and what this article is all about, is this: given my past experiences, why am I always so confident that my next piece of code will be different? What is it that means I’m always so blind to the probability that what I’m working on right now will prove to be equally ropey once I reach the end of it? It seems to me that it’s in the nature of computer programming that everything you ever write makes you learn something new. The result is that you’re constantly raising your standards and never completely happy with your previous coding efforts. Yet my heart seems to be several steps behind my head in realising this.

Refactoring your technical debt

In most programming projects, this constant growth means that you’re always left with something of a technical debt: pieces of code that could do with some attention to make them easier to understand, easier to test, easier to modify, and so on. It’s that piece of code in your most recent project that you know wasn’t quite “clean” enough for your liking, but which you didn’t have the time or energy to sort out at the time. You can usually get away with ignoring your technical debt in the short term – generally it doesn’t actually mean anything is broken, functionally speaking – but the cruft tends to accumulate and if you don’t give those areas of the code the attention they need, eventually it can lead to real problems.

People who are blindly optimistic about their abilities, like I seem to be, are likely to be content with the classic Waterfall Model of software development. This is the approach that assumes everything will go exactly according to plan – that everything will be perfectly designed in all its fullness, then perfectly implemented with no architectural flaws whatsoever, before being released to perfectly happy customers who are receiving everything they hoped for. Thankfully, most people these days seem to be realising that pretending this works doesn’t actually get you anywhere. Instead they’re embracing agile methodologies like Extreme Programming which are built upon an explicit acceptance of our human weaknesses – imperfectly knowledge, imperfect requirements, imperfect decisions – an assumption that happens to synthesise very happily with a Christian worldview that is only too aware of our sinful nature. One of their key tenets is the idea of Constant Refactoring. If you haven’t come across the term before, “Refactoring” describes the process of modifying the internal structure of your code and tidying up interfaces and so on, but without changing the observable behaviour. It’s about paying off your technical debt, little by little, until you have a code base you can be proud of. Agile methodologies embrace refactoring, because they know you’ll need to do it – they know you won’t be satisfied with the way you coded it the first time around, or even the second or the third. Of course, refactoring has to go hand in hand with repentance – a commitment to turn from your evil ways as a cowboy coder and start putting into practice all that you’re learning. Refactoring without repentance is a pointless exercise, since the chances are you’re just replacing one technical debt with another.

Refactoring the Christian life

But if it’s in the nature of computer programming that constant growth means you’re never completely happy with your previous coding efforts, how much more is this true of the Christian life? How often do you find yourself cruising along, thinking everything’s fine spiritually, only to look back on the last few weeks and notice some massive area of ungodliness that you’d overlooked: maybe some action of yours that really hurt someone without you even realising it, or maybe some persistent behaviour that you later realise has been a dreadful witness to your non-Christian friends. It’s part and parcel of the Christian life, for as Jim Packer says in "A Passion For Holiness", growing up as a Christian is really all about growing down – that as we grow we “end up seeing ourselves as less – less nice, less able, less wise, less good, less strong, less steady, less committed, less of a piece – than ever we thought we were. We stop kidding ourselves that we are persons of great importance to the world and to God. We settle for being insignificant and dispensable”.

As God sanctifies us and conforms us bit by bit to the image of his son, we find our consciences flinching at things that previously never bothered us. Our tolerance for sin in our lives should always be less than it used to be – so long as it continues to be greater than God’s. As in programming, repentance is a way of life for the Christian, not something that you do once when you first decide to follow Jesus. The difference, however, lies in how we must deal with our past failings. For whereas bad programming leaves us with a technical debt that I can solve myself with a bit of refactoring, bad living leads to a spiritual debt that nothing short of death can pay for. Writing bad code has no legal ramifications – although I’ve previously argued that there is a Christian imperative to write the best code we can out of love for our co-workers and our employers, I’ve not broken any laws by writing bad code. I don’t face a jail sentence or a hefty fine. But bad living, on the other hand, is a legal matter. Rejecting God’s rightful rule over my life and choosing my own path is tantamount to treason, and carries a penalty that I have no hope of paying myself. It takes the death of Jesus in my place as a substitute to set me free. For a proud programmer like me, becoming a Christian is an act of the utmost humility, as you admit to God that you are unable to offer anything towards your salvation, and that only the death of his son Jesus can pay off your debt. As Romans 6:23 puts it, “the wages of sin of death, but the free gift of God is eternal life in Christ Jesus our Lord”.

Thank God for the ultimate software architect, the Lord Jesus, who refactors my ugly past, pays off my spiritual debt and cleans up the rope in my life so that I can get on with daily repentance as I seek to follow in his footsteps.

When I relaunched geero.net a month or so ago, I did it under the slightly ambiguous subtitle of “Christian software development”. It’s true that I planned to talk about software which is explicitly Christian, particularly centring around my Bible-teaching computer games, but it is also my intention to talk about issues that affect Christians who are involved in software development, both professionally and as a hobby. But there are loads of brilliant programming resources out there written by people far smarter than me. So why does the internet need yet another coding blog, and why would I be arrogant enough to think that I can contribute anything unique? In fact, isn’t it a bit weird to a have a blog devoted to Christian software development in the first place? Isn’t being a programmer completely orthogonal to being a Christian?

Whilst the connection may not seem apparent at first glance, I think that being a Christian actually has quite a significant impact upon your computer programming. The Bible says that Jesus is interested in the everyday details of our lives, including our coding – and not just what we code, either, but the nitty gritty of how we code it. If he is the source of all our gifts and abilities, then it makes sense that he would be concerned with how we use those gifts, and it brings him glory when we use them well. To paraphrase Colossians 3:17, “whatever you do, in word or code, do everything in the name of the Lord Jesus, giving thanks to God the Father through him.”

One of the big themes of the New Testament is Jesus as King – the ruler of everyone and everything. As Abraham Kuyper once famously said, “There is not a square inch in the whole domain of our human existence over which Christ, who is Sovereign over all, does not cry: ‘Mine!’”. Nothing is outside of his rule, including our work and our coding. So what will it look like for us to bring our programming under the Lordship of Christ? It seems to me that there’s plenty of space for a blog that helps us think that through – I know I’ll certainly benefit from writing it!

Conduct in the Workplace

It seems obvious, but first and foremost, Christian programmers are Christians. That means that 99% of living under the lordship of Christ is exactly the same as if we were lawyers or secretaries or school teachers or acrobats. We’re called to be salt and light in the world, being a good witness to those around us, graciously speaking of Jesus when we can and commending him with our lives and our work. When speaking to slaves performing the most menial of tasks, Paul writes this:

“Whatever you do, work heartily, as for the Lord and not for men, knowing that from the Lord you will receive the inheritance as your reward. You are serving the Lord Christ” (Colossians 3:23-24)

It can be tremendously encouraging to know that Jesus cares about our work! Whether we’re professional programmers doing it for a living, or just a hobbyist hacking something together in our spare time, we’re to imagine Jesus as our real boss, calling the shots. We’re to work heartily, putting all of our effort into it, and not just when our manager is looking over our shoulder (“not by way of eye-service as people pleasers”).

This is an area where I constantly find myself falling short. It’s so easy to slack off and start browsing the net when nobody’s looking, or to start grumbling if we seem to be going through a phase full of bugfixing and maintenance instead of any exciting new development. But this can be a terrible witness – especially since grumbling is like gangrene and is so quick to spread amongst a team, with disastrous effects on morale (incidentally, if you do find yourself wading through a month full of boring bug fixes, it may be an indicator that the code you wrote last month was a load of old rope – bear it in mind!)

Writing Quality Code

As a general rule, programming under the Lordship of Christ is going to mean doing the best job we can. Even when you’re programming for fun, it still glorifies God when you make good use of the gifts he’s given you, honing your skills. When you’re doing it professionally, however, it’s absolutely vital to your witness to be writing good code. Bad code is a headache for everybody who has to maintain it, so you can really serve your colleagues by writing code that’s easy for them to understand and change, with good comments and unit tests, and so on. Even if you’re on a team of one, you can still show consideration for the poor soul who’ll have to maintain your code once you're gone!

But as in most fields, quality doesn’t just happen by accident. So how do we learn how to write good code? Firstly, I’d say that if you’re not in the habit of reading programming blogs (in your lunch hour, of course!) then I’d highly recommend adding a few to your favourite RSS reader. Some of my favourites are the Daily Worse Than Failure, and the joel reddit. These kinds of things can be great for exposing you to ideas that you wouldn’t have thought of on your own, and for keeping on top of the latest trends. Secondly, nothing beats getting your hands dirty for learning how to code better. The most valuable experiences for me have been when I’ve had to maintain some truly awful code left behind by my predecessors – it really teaches you the pain that you can cause through sloppy coding practices!

The Problem of Proud Programmers

I want to close by addressing one sin that I think programmers are probably particularly prone to, and that is pride. We all know the stereotype of the computer programmer, and great people skills aren’t part of it. But I wonder if part of the reason the stereotype is so often accurate is because of the kind of people who are attracted to computers. Other people are so inherently unpredictable, which some people find really hard to cope with, and computers can provide real solace for them. I find it much easier talking to my computer, where I can tell exactly how it’s going to respond to a given input. But I wonder if this means that programmers are especially likely to slip into pride. We’re used to exercising complete dominion over our CPU, bending it wherever our will determines – we are like gods among men! Except we’re not – Jesus is the king, and programming under his lordship being quick to acknowledge that. It’s why the Bible devotes so much space to the issue of pride, since it’s a particularly nasty form of idolatry that sets us up as rivals to the Lord Jesus. Yet it’s not a topic that you’ll find covered in many other programming blogs. There are certainly writers like Jerry Weinberg who talk about the practical benefits of “egoless programming”, but I think there’s a massive spiritual dimension to pride that means there’s real benefit to be had from a programmers' blog from a Christian perspective.

Programming under the Lordship of Christ won’t always be easy, but he’s promised to give us grace enough for each day as it comes, so let’s keep going in his strength as we spur one another on to love and good works.

Intro: A Broken Union

When I was an undergrad, our Christian Union had a thing called a Doctrinal Basis: eleven core truths that we shared with one another – essentially a way of clarifying what we meant by the word “Christian”, so that we could get on with doing the “Union” bit. Sadly, however, despite this we were greatly distracted by a disagreement between two groups within the CU. On the surface, the dispute revolved around the third article of the D.B.:

“The Bible, as originally given, is the inspired and infallible Word of God. It is the supreme authority in all matters of belief and behaviour.”

It’s the doctrine of the Authority of Scripture. One group – let’s call them Team Blue for convenience – accused the other – Team Red – of not living out the implications of this truth, whereas the Reds fervently denied any such thing. Both claimed to uphold the Bible as God’s definitive word. The issue was never really settled, and in my view the main reason it dragged on so long and caused so much heartache was an unacknowledged twelfth article of faith – a doctrine which the Blues held as fundamental, and which the Reds weren’t committed to at all. It all boiled down to the Centrality of Bible-Teaching.

How God Works

At its heart, it’s a doctrine about how God works in the world. What is the agent by which people become Christians and Christians mature in godliness? Just as it’s critical to know whether your car runs on diesel or unleaded fuel, it’s an issue that has profound implications for the way that we do ministry, and how we expend our energy – I wouldn’t want the engine of my Christian computer games project, for instance, to grind to a halt because I’d filled it with the wrong type of fuel and wasted my time! So how does God work? Team Red acknowledged that the Bible was God’s word, and that Christians should listen to what it says. Team Blue, however, went a step further – they believed that it is the Bible itself that is God’s agent for gospel growth. The Centrality of Bible-Teaching says that it’s as the Bible is opened, explained and applied that people are saved and that Christians grow in their faith. To the Blues, the Bible isn’t just a handy manual for life that they can fall back on when they get stuck, it’s the spiritual food that they gobble up day by day to grow and sustain them.

Since both groups claim to trust in the authority of the scriptures, it’s instructive to take a look firsthand at what the Bible says about itself. One passage that we could turn to is 1 Peter 1:23ff. Peter reminds his readers of how they became Christians, that “you have been born again, not of perishable seed but of imperishable, through the living and abiding word of God”. It was through hearing the word of God explained that these people were converted. He then exhorts them with the following words:

“Like newborn infants, long for the pure spiritual (lit. “wordy”) milk, that by it you may grow up to salvation” (1 Peter 2:2)

The picture of a newborn baby and its craving for milk is a wonderfully graphic one – one that’s all too familiar to many sleep-deprived parents! A malnourished baby without its milk would be severely stunted in its growth, and Peter is saying that Christians are equally dependent on the wordy milk of the scriptures if they’re to grow up to salvation. James says the same thing in his letter – (1:18 - “Of his own will he brought us forth through the word of truth”) as does Paul, e.g. in 1 Thessalonians 2:13:

“And we also thank God constantly for this, that when you received the word of God, which you heard from us, you accepted it not as the word of men but as what it really is, the word of God, which is at work in you believers” (emphasis mine)

It’s not just the New Testament, either. Isaiah 55:10-11 speaks of God’s word accomplishing his purposes like the rain watering the Earth, and Genesis 1 shows that even God’s work of creating the universe was carried out through his spoken word. So you see, within the Bible, the word of God isn’t an optional feature in people’s conversion and subsequent growth – it is the primary agent through which God works in his world. It may seem somewhat pitiful and weak, but the method he has chosen is the simple proclamation of his truth, whether that be through preaching from the pulpit, friends opening up the Bible together over coffee, a group getting together to discuss a passage of scripture, or any other way you can think of for getting the word of God into people.

Expository Preaching

It’s this conviction, that Christian conversion and growth comes about through the teaching of God’s word, the Bible, that leads to what’s known as “expository preaching”. At its simplest, expository preaching means starting with the text of the Bible and seeking to understand and explain what the original author of a particular passage was trying to get at – “to think God’s thoughts after him”. It usually means systematically working through a particular book of the Bible bit by bit over several weeks, so that everyone can follow the author’s train of thought, although thematic talks can still be done in an expository way. The main distinctive of expository preaching is that the Bible is not merely used as a repository of good sermon illustrations, or to lend weight to the preachers preconceived theories, but that it is allowed to govern the content and application of the teaching. The preacher’s job is not to come up with novel concepts to inspire his congregation, but simply to uncover the message God has already left for us in the Bible.

For some of you, the very word “preaching” probably conjures up all sorts of negative connotations of a droning voice sending you to sleep in the pews. But a belief that God works through his word can’t be used to excuse boring presentation. For the expository preacher, the priority will always be to get people to listen to and engage with what God’s saying in the Bible – Team Blue doesn’t treat Bible teaching like the incantation of some magic spell, as though the mere saying of the words is all that’s required to produce the desired results, totally bypassing the minds of the listener. No – we want to get people thinking about what they’re hearing, meditating on things, chewing over what they don’t agree with, trying to get to grips with how the logic works and how the author achieves his purpose. This leads to potential for all sorts of exciting and innovative ways to get people listening to God’s word.

Expository Coding

One such way is what I’ve dubbed “Expository Coding”. In my last article I explained my conviction that the very best use for my gifts as a games developer would be to make games that share the gospel of Christ with people. Combine that with a commitment to expository preaching, and you end up making Bible-teaching computer games. For sure, it’s a challenge to make them genuinely fun and engaging, and for sure, it’s a challenge to faithfully teach the Bible on its own terms – but what a glorious work to be involved in, as day by day God builds his kingdom through the teaching of his word.

Intro: Getting the diagnosis right

When I first started programming on the BBC Micro, what got me hooked was my insatiable urge to create. I’ve always loved seeing my code come to life on screen, especially in games. Like many other Christian software developers, I’ve often asked myself how I can best put these particular gifts God has given me to use for his kingdom. What is the most pressing need facing our world to which I can apply my gifts as a games developer?

One of the TV shows I used to love was Supernanny. Supernanny would swoop in to dysfunctional families with misbehaving kids, and witness all manner of tantrums and disobedience. She’d then offer advice to the parents on how to deal with the little terrors. The interesting thing was how often the root cause always seemed quite surprising, and how the behavioural issues turned out to be mere symptoms of a deeper problem: maybe a father shirking responsibility, or a mother unwilling to say ‘no’. If Supernanny had merely attempted to treat the symptoms, she wouldn’t have had such a dramatic effect.

How we understand the problem will control what shape our remedy takes. If we think that the biggest problem facing our culture is the excessive violence on our screens, we’re going to work hard at non-violent alternatives; if we think it’s a lack of moral standards, we’re going to want games that instil values such as caring for one another; if we think it’s ignorance of God’s law, we’ll make games that help people learn how they should behave. It’s not that each of those alternatives would have no value in their own right, but getting a right diagnosis is essential to bringing about lasting change.

The world’s big problem

So what does the Bible have to say? Just as Supernanny’s piercing gaze saw through all of the chaos to identify the real problem, so the Bible gives us a surprising diagnosis of our dysfunctional world. It claims that the biggest problem is not the breakdown in family values; it’s not the violence on our TV screens or declining standards in education; it’s not even global warming. As tragic as these things are, according to the Bible these are merely the side-effects of a much deeper malaise: a world under the wrath of God. As Romans 1:18ff explains:

“For the wrath of God is revealed from heaven against all ungodliness and unrighteousness of men, who by their unrighteousness suppress the truth… For although they knew God, they did not honour him as God or give thanks to him, but they became futile in their thinking, and their foolish hearts were darkened.”

Despite the beauty and wonder of the world around us clearly pointing to the existence of a mighty creator God, the apostle Paul is saying that the human race has an ingrained aversion to his authority: we’d much rather shut our eyes, pretending that he doesn’t exist, than acknowledge him for who he is and have to submit to his loving rule. We take the good things he has given us and exploit them thanklessly.

God doesn’t just sit idly by and watch our rejection of him – he’s far too loving for that. In the next few verses, three times we read that God “gave them up” to the passions of their hearts and minds to do what ought not to be done. Unnatural and unrestrained sexual relationships, malicious backbiting and disobedient children – these are not the root problem, but rather the outworking of a sinful race under the judgement of a holy God. It’s too late now to simply clean up our act – his righteous anger has become our most serious problem.

In the next chapter, Paul makes it clear that being a ‘religious’ person doesn’t let you off the hook either. God’s chosen people, the Israelites, stood a better chance than any of being in the right, and yet 2:13 says “it is not the hearers of the law who are righteous before God, but the doers of the law” (emphasis mine). Not one of us can claim to be perfect ‘doers’ of God’s law, and so we reach the obvious conclusion of 3:19b, that “every mouth may be stopped, and the whole world may be held accountable to God.” No excuses, no buts – we are all guilty before God, and there’s absolutely nothing we can do to acquit ourselves before him.

God’s big solution

If the big problem facing our world is God’s wrath, then ultimately the solution is going to have to originate with God. Only God can save us from his own righteous judgement. It’s into this context that the first few words of 3:21 speak with such joyful relief: “But now… God”. When there was nothing that we could do to justify ourselves, God himself has put forward a solution in the form of his son, Jesus. In dying on the cross, Jesus takes our sin upon himself, and with it God’s wrath. He is the propitiation that turns aside God’s anger, he is the justifier who takes away our guilt, he is the redemption that rescues us from slavery to sin. For all who believe in his name, Paul says, there is now no condemnation (8:1). It’s of this gospel message that Paul speaks in 1:16:

“I am not ashamed of the gospel, for it is the power of God for salvation to everyone who believes”

… and who can blame him! To our broken and fallen world, this is truly the best news imaginable! Many will choose not to accept it, many will be too proud to admit their need of God’s intervention, but for those who will believe it, the gospel is truly the wisdom of God and the power of God.

Conclusion: Preaching in word and code

People hearing and responding to this glorious gospel is the only hope for our world. Conviction of this naturally leads to a conviction in the priority of preaching this message. As Romans 10:14-15 puts it:

“But how are they to call on him in whom they have not believed? And how are they to believe in him of whom they have never heard? And how are they to hear without someone preaching? And how are they to preach unless they are sent? As it is written, ‘How beautiful are the feet of those who preach good news!’”

So despite not exactly being renowned for their personal hygiene, even programmers can have beautiful feet! The challenge is to figure out how to preach God’s word through code – can we make a genuinely entertaining game that proclaims this message in an engaging way? I’m gonna do my best to find out!

“Having gifts that differ according to the grace given to us, let us use them” (Romans 12:6). How will you use yours?]]> http://www.geero.net/2007/12/preach-it-coder.html http://www.geero.net/2007/12/preach-it-coder.html expository coding Fri, 21 Dec 2007 12:12:29 +0000
If there are broken links or you can't find the content you're looking for, please bear with me. I have tried to make sure as many of my external links as possible still work, but I may well have missed a few.
]]> http://www.geero.net/2007/11/and-now-for-something-complete.html http://www.geero.net/2007/11/and-now-for-something-complete.html Fri, 30 Nov 2007 13:01:25 +0000