1. An abstract Renderer interface that the game itself talks to
2. A concrete implementation of the Renderer interface that uses fixed-function OpenGL 1 (RendererGLES1)
3. Another implementation of Renderer that uses programmable OpenGL 2 (RendererGLES2)

Today I’d like to show you what I had to do to port the fixed-function version of the renderer to use the programmable pipeline in OpenGL ES 2.0.

More Power, More Responsibility

The good news about a programmable rendering pipeline is that it offers far greater power. With a fixed-function pipeline you can only do what the API lets you do. If the API supports bump mapping, you can do bump mapping. If the API supports fog, you can apply fog. But with a programmable pipeline, your engine can render anything that you can code. You’re in total control of how every vertex and pixel is displayed.

The bad news about a programmable pipeline is that it requires a lot more work. Fixed-function pipelines do a lot for you. Call glRotate(), for example, and OpenGL will set up a rotation matrix for you and concatenate it with the existing matrix. Request that a light be applied to your models and suddenly they’re glowing with the sunset. Not so in a programmable pipeline. If you want to see sunlight, you’ve got to code it. If you want transform matrices (and believe me, you do), you’ve got to program them.

So a programmable pipeline offers more power. But it also puts more responsibility on you, the programmer.

This is even more true in OpenGL ES 2.0—the rendering API that the iPad and later iPhones/iPod Touches use. All new versions of OpenGL add support for vertex and fragment programs. But the “ES” version of OpenGL 2.0—the mobile, stripped-down version—not only adds this support, it strips out support for anything else.

This is the hardest part about moving from a fixed function renderer to a programmable renderer on the iPhone/iPad. The move to shaders takes away some of the functionality that OpenGL ES 1.0 provided.

Changes from OpenGL ES 1.0 to OpenGL ES 2.0

The biggest changes that I encountered when moving Crush the Castle from version 1 to version 2 of OpenGL ES involved how vertex attributes are sent to the hardware, the self-management of matrices, and of course, programming the actual shaders. Here’s a list of all the changes I had to make to my fixed-function renderer. A lot of these might not make sense now, but I’ll talk about them all in more detail later.

• Implemented my own 4×4 matrix class with support for translation, rotation, scaling, and concatenation
• Implemented my own orthographic and perspective projection math
• Created a class to implement matrix stacks
• Replaced occasional calls to glColor4f() (used to apply a single color to all vertices in a draw call) with a vertex program “uniform” variable
• Got rid of glEnableClientState() calls
• Converted gl*Pointer() calls (like glVertexPointer() and glTexCoordPointer()) to glVertexAttribPointer() calls
• Added the loading, compiling, linking, validating, and using of vertex and fragment shaders

Some features stayed just the same.

• Texture creation, loading, and binding
• Alpha blending settings
• Vertex buffer object creation with glBufferData() and the like
• Setting the viewport with glViewport()
• glGetError()
• glClear(), glClearColor(), and the like
• glDrawArrays() and glDrawElements()

Now Crush the Castle does not use every feature in OpenGL ES 1. No doubt there are many other fixed-function features that I would have needed to convert if I had been using them. So mileage may vary. But these are the ones I had to convert, and next time I’ll go into more detail about what I had to do to convert each one.

Google’s recent interface changes may be noisy and toadying. But at least their search engine works. Bing’s doesn’t. Not well anyway.

Example. I needed to know how to insert newlines into a text document by using find and replace in Xcode. So I do a search in Bing:

“xcode find and replace newline”

Bing proceeds to tell me all sorts of interesting things about such diverse topics as finding, replacing, and newlines. Unfortunately, none of the results have anything to do with Xcode. In fact, they all seem to have a lot to do with Microsoft products. Fully half of the top six results are from Microsoft sites. Hmm.

So I begrudgingly drag myself back over to Google’s ugly mug and repeat my request. Google—as I don’t need to tell you—took me right where I needed to go.

I’m disappointed in Google’s front end designers for wanting to be like Bing’s front end designers. But Google’s back end programmers won’t let me leave.

Sorry Google. I’m back.

…

The solution to my find-and-replace-inserting-newlines problem turned out to be really weird, BTW. Big props to Michael Gracie for coming up with it.

I never guessed that I would leave Google not for another, superior search engine, but simply because Google had turned fickle and annoying.

After remaining essentially unchanged for over a decade, the Google interface started morphing a few months ago.

At first the change was innocuous enough, maybe even an improvement. The main Google search page would hide all clutter—the nav bar, the extra links—unless the user moved the mouse over it. If you just jumped to the page, typed a query, and hit Return, you saw the most unobtrusive Google imaginable. Perfect.

On the annoying side, the slightest mouse movement would cause the clutter to fade back in. This had the unfortunate effect of making the clutter more conspicuous than it had been when it was static. I’ve said this to UI designers (including myself) for years, and I’ll say it again: A consistent bad thing is better than an inconsistent good thing. Clutter is bad, but if it doesn’t change, the user stops seeing it after a while. Getting rid of clutter entirely is good, but if it pops back in at unexpected times, that’s even worse.

So Google became mildly annoying.

A couple of weeks ago Google changed its search results page. They moved their filtering features to the left side of the page, pushing the search results out to the right. At first this felt weird and arbitrary, but soon I was enjoying the filtering links—like quickly focusing on a particular size of image. I got used to the new layout.

Today, this. Big, garish, noisy images filling my screen. Images that make it harder for my eye to parse the screen. Images that waste my retina-processing neuron cycles when I’m trying to focus on other thoughts. Images that take more bandwidth, that take time to download, and that therefore cause my search page to change while I’m in the middle of using it.

Now that’s annoying.

You know, I’m not against decoration. I don’t mind if some arbitrary webpage is full of colors and shapes.

But Google search is not just a webpage. It has become part of how human beings live. It is part of our brains. Any little change to it changes the way billions of people think and feel.

“So,” maybe Google is thinking, “if we have that kind of responsibility for how people’s brains work, maybe we should use our power to show calming, happy, warm images that will help to soothe and inspire them.”

No Google. That’s not your job. Your job is to take my brain from an initial question (“What was Mark Twain’s real name?”) to a set of potential answers. Your responsibility as a search engine is to do nothing but to help my neurons move along on their current course. Not to edit that course. Not to soothe it.

Less is more here. Less helps you do no harm. Less helps you do no evil.

Of course, the real reason that Google is making all these changes is nothing to do with their sense of responsibility. It’s everything to do with fighting back against Bing. Bing has been gaining market share at Google’s expense. Google figures Bing has got something they haven’t. They study the Bing site, figure out what that is. They take those ideas and apply them to Google.

And maybe it will work. Maybe people’s brains like the noise of imagery, the momentary distraction of a backlit castle. Maybe Bing has the right idea.

But as a Google user, all I can say is that a more Bing-ish Google is less of a Google. If Google has decided that Bing has what users want, why I don’t take Google’s recommendation and just move to Bing?

So that’s what I did a few moments ago. Homepage changed.

Goodbye Google. Thanks for all your help.

Instead we bought her a small, hard, painted plastic fox that she picked out specially. She adored it.

That night as she got ready for bed she debated whether to name it “Reddy” or “Redders.” But while thus occupied, she accidentally dropped the fox into the toilet—a toilet already in mid-flush.

We heard her heartbroken wail as she raced down the hall. Redders—Reddy—was gone.

Kathleen is only four. The mystery and terror of the commode—that strange, great, glimmering cavity that takes away parts of ourselves and sends them to some unknown hell or heaven—has not entirely left her. She cried a long time at the loss of her precious fox and the awful way he went.

It soon became clear, however, that Redders had not entirely passed into the great beyond. Evidence for the presence of his unsettled ghost came in the form of high waters at the next flushing. Redders was still with us, somewhere, somehow, and vividly expressing his unease.

As father of the family and man of the house, naturally it falls to me to take care of any little household operational problem that arises. So it was I who plunged the toilet in the hopes that Redder’s progress would be decisively advanced or reversed. The loo flowed a little better after that. I left the problem to sort itself out.

By the next evening the whole family could see that the problem had not sorted itself out. The toilet would no longer drain. Any further attempts to flush would only result in the most unseemly kind of spillage. Even plunging proved precarious. I put a sign on the loo—DO NOT USE—and looked without enthusiasm for the opportunity to probe further into the matter.

That opportunity came this morning. And I am here to tell you, now that the problem has resolved, that it really is remarkable the things you learn in the most unexpected places.

I am not very handy around the house. I’m handier around C++ and OpenGL. One of the nice things about working with computers is that I hardly ever cut my hands, crush my thumbs, drop heavy things on my toes, put out my eyes, or experience any of the other misfortunes that seem to occur when I interact with the physical world.

Moreover, I had never unclogged a really serious stoppage before. It’s the sort of thing I remember my dad doing when I was growing up. And I helped sometimes. But I didn’t remember how he did it. I wasn’t sure I could figure it out.

I thought of asking him to come over—”Bring out the big guns,” as I put it to my wife. My dad lives a few miles down the road—it wouldn’t be the first time he has come to our rescue in household emergencies. But I’m nearly forty. I’m quite a big boy now. I figured this was something I needed to do myself. For my manhood, you know.

I had a vague notion of pouring Liquid Plumbr down the potty. I didn’t think Redders would appreciate that. Any acid that would dissolve a plastic fox would surely be a dire hazard in my ungainly hands, and any that wouldn’t was useless. Moreover, I harbored some hope of saving the fox and returning him to the one who loved him.

I will spare you the details of how I cleared the blockage. It involved quite a bit of splashing, not all of an entirely liquid sort. The plunger was no use. The flexible cleaning tool that I bought for the job offered little help. About six towels became involved at various points. A chorus of patent leather beetles appeared during Act II and scrambled around the stage. (I’ve always liked patent leather beetles. I like them less now that I know what they eat.) I had to unscrew the entire commode from the floor, tip it over, and look up into its—erm—bottom. On the bright side (so to speak) this did enable me to confirm that Redders was still there.

Other details I won’t mention involve carrying the entire commode out onto the back lawn and spraying it like it had never been sprayed before. After laying the potty on its side and blasting water into it for five or ten minutes, I looked once more into the bowl. There lay Redders, suddenly, surprisingly, thankfully liberated.

I looked for high fives from my wife and children—especially Kathleen—but they didn’t seem eager to approach me.

Redders received a good washing, beginning with a long bleach bath. Kathleen was at last reunited with her fox, her special fox. And he is no less special to her despite the places he’s been.

The whole exercise took perhaps an hour and a half. That gave me plenty of time to observe and reflect. As I said before I learned some surprising lessons: one about psychology, another about service, one about fatherhood, and the last about engineering.

1. You can get used to anything. In the early minutes of my expedition the smell, the splashing, and the slurping sounds when I— no, no, I must spare you the details. Anyway, I really thought I might throw up. But after half an hour or so I got used to the odor. I’m quite serious when I say that it almost became pleasant. And it seems to me that here is an analogy for life. There are things we do as adults that seem perfectly normal to us, but if the eight-year-old versions of ourselves saw those things they would go heaving into the bushes. Just as I got used to the smell of effluvia, we all get used to our lives. A human being can adapt to almost anything, for better and for worse. If you live in muck long enough you even begin to like it. I’ve seen this principle at work in relationships, for example. And in employment situations. And with people and their habits. Maybe you have to.
2. A dirty job isn’t so bad if it’s for someone you love. Tedium is tedium. Disgusting muck is disgusting muck. But serving someone else makes the tedium and muck far, far easier to bear.
3. Dads hate poo as much as you do. My dad always seems to dive into any job without fear or reticence. No doubt part of that courage came from growing up on an east Texas ranch where dirt and bruises and the excrement of livestock were part of the daily grind. But even though I’m a soft suburbanite who brushes Ritz crackers from his Perry Ellis shirts while tapping on his keyboard or delivering a lecture on memory allocation, my kids seem to see me in the same way. “It’s no big deal for dad to get covered in poo,” they say. “Grown men like to smear themselves in grime now and then.” Today I learned, and hope my kids learn, that dads don’t do hard, irksome, or disgusting jobs because they like it, or even because they’re indifferent to it. They do it because they have to.
4. The toilet is a marvelous invention. Really simple once you understand it. No electricity. Quite reliable. The physics of the thing—all gravity, seals, and siphons—is really a wonder when you come to see it. Every child should learn how a toilet works before they leave for college.

One final thought.  If you do decide, as I have, to teach your children about the mechanics of the crapper, I think it’s better to start with a diagram rather than a working demonstration.

Last time I talked about taking my existing iPhone OpenGL renderer and refactoring it into an abstraction layer. This leaves me with an abstract Renderer class that looks like this.

class Renderer
{
public:
	typedef unsigned int VertexBufferID;

	enum PrimitiveType	// Mirrors OpenGL ES Values.
	{
		PT_Points		= 0x0000,
		PT_Lines		= 0x0001,
		PT_LineLoop		= 0x0002,
		PT_LineStrip		= 0x0003,
		PT_Triangles		= 0x0004,
		PT_TriangleStrip 	= 0x0005,
		PT_TriangleFan		= 0x0006
	};

	enum MatrixIdentifier
	{
		MAT_ModelView,
		MAT_Projection,
		MAT_Texture
	};

	virtual ~Renderer() {}

	virtual Vector2D GetViewportDimensions() const = 0;
	virtual void SetViewport( const Rectanglei& viewport ) = 0;

	virtual SmartPtr< Texture > CreateTexture(
		const std::string& strFilename,
		Color colorKey = 0,
		bool keepAround = true ) = 0;
		// REQUIRES( strFilename.length() > 0 );
		// PROMISES( result != 0 );

	virtual void ApplyTexture( Texture* pTexture ) = 0;
		// Use null to turn off texturing.

	virtual VertexBufferID CreateVertexBuffer(
		const std::vector< Vector2f >& vecVertices ) = 0;
	virtual VertexBufferID CreateVertexBuffer(
		const Vector2f* arrVertices,
		size_t nElements ) = 0;
		// nElements counts the number of Vector2fs in the array.

	virtual void DeleteVertexBuffer( VertexBufferID& idVertexBuffer ) = 0;
		// Deletes the buffer and sets the ID to 0.

	virtual void BindTextureID( unsigned int idTexture ) = 0;
	virtual void SetGeometryPointer( Vector2f* arrVertices ) = 0;
	virtual void SetGeometryVertexBuffer( VertexBufferID idVertexBuffer ) = 0;
	virtual void DrawGeometry( PrimitiveType primitiveType,
                                          int nVertices,
                                          int offset = 0 ) = 0;
	virtual void SetAlphaBlending( bool alphaBlend ) = 0;

	virtual void BeginVertices( PrimitiveType primitiveType ) = 0;
	virtual void AddVertex( float x, float y, float u = 0, float v = 0 ) = 0;
	virtual void EndVertices() = 0;

	// Matrix functions
	//
	virtual void SetOrthoProjection(Number left,
					Number right,
					Number top,
					Number bottom,
					Number zNear,
					Number zFar ) = 0;

	virtual void SetMatrixToIdentity(
                                   MatrixIdentifier whichMatrix = MAT_ModelView ) = 0;
	virtual void PushMatrix( MatrixIdentifier whichMatrix = MAT_ModelView ) = 0;
	virtual void PopMatrix( MatrixIdentifier whichMatrix = MAT_ModelView ) = 0;

	virtual void Rotate( Number angleDegrees,
			     MatrixIdentifier whichMatrix = MAT_ModelView ) = 0;
	virtual void Translate( const Vector2< Number >& translation,
				MatrixIdentifier whichMatrix = MAT_ModelView ) = 0;
	virtual void Scale( const Vector2< Number >& scale,
			    MatrixIdentifier whichMatrix = MAT_ModelView ) = 0;

	// Material color transform functions
	//
	virtual void PushColor() = 0;
	virtual void PopColor() = 0;
	virtual void SetColor( Color color ) = 0;
	virtual Color GetColor() const = 0;
	virtual void MultiplyColor( Color color ) = 0;

	virtual void ReportErrors() = 0;

	virtual Vector2D DrawText( const std::string& text,
				  Font* pFont,
				  const Vector2D& textULCorner,
				  const Vector2D& fontScale,
				  const Vector2D& spacingScale,
				  Color color = Color::White,
				  bool calculateMetricsOnly = false ) = 0;
		// REQUIRES( pFont != 0 );
		// REQUIRES( pFont->GetTexture() != 0 );

	FRESH_DECLARE_CLASS_ABSTRACT( Renderer )
};

Look at all those “= 0″‘s after each method. This is a pure abstract class, merely an interface. It’s the RendererGLES1 class that inherits from and implements this interface.

What I did next was to create a second renderer implementation called RendererGLES2. This renderer also derives from Renderer and also implements all its functions. But whereas RendererGLES1 calls OpenGL 1 functions in its implementations, RendererGLES2, naturally, uses OpenGL ES 2.

Next time I’ll show you how I implemented the OpenGL ES 2 version of the renderer, stripping out GL 1-specific functions and adding programmable shaders.

When my daughter wants the iPad she asks for “the huge iPod.” That’s about right. Inside and out, the iPad is basically an exploding iPod.

One difference, though, is the graphics hardware. Older iPhones and iPod Touches used simpler graphics hardware that’s built on OpenGL ES 1.1. That’s the platform I built Crush the Castle on. The iPad uses a more modern graphics pipeline that’s built on OpenGL ES 2.0. From a programmer’s perspective, the big difference here is programmable shaders.

So my first job in bringing Crush the Castle to the iPad is upgrading the renderer from a fixed function, OpenGL ES 1.1-style system to a programmable, OpenGL ES 2.0-style system. If you’ve ever been interested in learning graphics programming with shaders, follow along with me and perhaps we can learn together.

In the articles that follow I’ll talk about iPhone/iPod Touch/iPad development. But much of what I do would apply to anyone working with OpenGL on any platform—PC, Mac, PS3, whatever. I’ll talk about OpenGL “ES”—the trimmed down, mobile version of OpenGL. But in practice, Crush the Castle runs on non-”ES” versions of OpenGL, so the “ES” is immaterial. I’m also working in C++. If you’re working in a different language, like Java, C#, or Objective-C, you’ll have to read between the lines a bit. But I’m mostly dealing in terms of design patterns that aren’t specific to any particular language, so the leap shouldn’t be too far.

Creating an Abstraction Layer

The first step in bringing Crush the Castle into the world of OpenGL 2 was refactoring my fixed-function renderer to use vertex and pixel shaders. In Crush the Castle, all rendering is handled through a class called—naturally enough—Renderer. This class offers functionality for setting up transforms, creating and setting vertex buffers, setting textures, handling render state (like whether alpha blending is turned on, for example), and of course initiating the actual rendering.

In this initial phase I wanted to keep the interface to the Renderer class as unchanged as possible. I wanted client code—the game code that asks for rendering to be done—to remain untouched wherever possible.

Moreover, I wanted to keep the current fixed function renderer completely intact. After all, Crush the Castle isn’t leaving the iPhone—it’s just gaining new platforms. So my Renderer class should support both OpenGL 1 and OpenGL 2, When you run the game it will ask the hardware whether GL 2 is available. If it is, it will use it. If it isn’t, the game will fall back to GL 1.

The first thing I did was to refactor my Renderer into an abstraction layer. An abstraction layer is a design pattern in which a single class “stands in” for one or more other classes that do the actual work. The “stand in” class is abstract in the technical sense. Although it declares functions, it doesn’t actually implement them. In Java terms, it’s an interface. The “working” classes derive from the abstract class, so they have the same interface. But they actually implement this interface.

The advantage of this setup is that user code can talk to the abstract interface class without bothering about how it’s actually being implemented. The implementation class in the background can even change—so there’s really no telling what it is, from the user’s perspective.

For Crush the Castle what I’ve done is to turn my Renderer class into an abstract interface. I then moved the Renderer implementation into a second, “behind the scenes” class—RendererGLES1. Just to give you a snippet of how this works, the two classes look something like this.

In Renderer.h:

class Renderer
{
public:
    // ...
    virtual void Clear() = 0;
    // ...
};

In RendererGLES1.h:

class RendererGLES1 : public Renderer
{
public:
    // ...
    virtual void Clear()
    {
        glClear();
    }
};

And now my user code looks something like this.

void main()
{
    Renderer* pRenderer = new RendererGLES1();
    // ...
    pRenderer->Clear();
}

In practice, the process of converting my existing, concrete, OpenGL 1-based Renderer class into an abstraction layer with a concrete class in the background was a matter of simple refactoring.

1. First, I copied my Renderer’s implementation files (Renderer.h and Renderer.cpp) to two new files called RendererGLES1.h and RendererGLES1.cpp.
2. Next, I gutted the original Renderer files. I stripped almost all the function implementations from Renderer.cpp. I got rid of most member variables from the Renderer class declaration. I converted almost all the method declarations into pure virtual functions.
3. With the original renderer gutted, I now made new renderer—RendererGLES1—inherit from Renderer. RendererGLES1 implemented all the functions that Renderer had implemented.
4. Finally, in the place where I previously had made a new Renderer, I now made a new RendererGLES1. But I kept all the pointers and references to Renderer the same. The game thought it was talking to a Renderer, but through the magic of virtual functions, it was actually talking to a RendererGLES2.

At this point I was able to test the game to make sure that the refactoring had broken nothing. So far so good. But what—you may be asking—had I really gained? Hadn’t I just made more trouble for myself by turning one perfectly good class into an unwieldy and essentially redundant pair?

The benefit of this work came in the next step, which was to implement my OpenGL ES 2.0-based renderer. But I’m out of time today, so—more on that next time!

Once upon a time my morning cappuccino would have me turning up my face and closing my eyes in a prayer of thanksgiving. Now I wait for a rapture that never comes. I stare into the froth of a caramel macchiato wondering where all the marvel went. I tweak the recipe—a little less foam, a little more sweet—but nothing ever brings me back to how it used to be.

It’s not just the coffee. The spring—princess of seasons—has lost the magic it once had. Who can be unmoved by a field of Texas wildflowers? Yet the spiders and mosquitoes and the early rising heat make me wish it was midwinter again.

Yesterday’s delights fade too soon. Still, today is not without its charms. My son is becoming a man, growing from child into peer and friend. In the evenings my daughters and I tumble into Wonderland (as told by Lewis Carroll—I’ll have nothing to do with the film). Every day I learn a thousand things both in my studies and through my teaching. I enjoy every day.

So old delights fade as new delights arrive. I’m sure that’s how it should be.

In college, my wife and I loved Jeremy Brett’s Sherlock Holmes. Recently we tried watching the old episodes. They were still fun, but a little tired. I can’t quite manage to completely forget the solutions to all Sherlock’s problems.

Although we can’t resurrect our love of Holmes, we have discovered a new love—Nodame Cantabile, an anime series about musicians in college.

It seems that joys have a way of rolling around.

This realization has led me to a resolution. Don’t try to regain the pleasures of the past. Enjoy the pleasures of the moment.

Tomorrow they’ll have faded too.

The gospel is perennially uncool. Any story that points to the gospel runs the risk of inheriting its uncoolness. A Christian yarn may end up sounding like a sermon. It may come across as moralizing, over-hopeful, or lacking the secular sheen that modern readers demand. A story designed to draw people to the gospel may end up repelling them instead.

How can a Christian writer craft a story that appeals to the culture while pointing beyond it?

The Moral Proverb

The simplest way for Christians to tell edifying, appealing stories is to talk about how people do and should live. Most successful stories—secular and otherwise—are moral fables.

As Robert McKee explains in his scriptwriting masterpiece Story, all the films we love have an essentially moral message. Great and successful movies—from Casablanca to Star Wars to The Godfather—teach us how to live and how not to.

Pixar’s most lucrative film to date is Finding Nemo. The moral core of the movie is easy to spot. The question that it asks is “When is it right to seek control and when to let go?” The protagonist, Marlin, is terrified of life and seeks to control his son Nemo. His traveling companion Dory has no control—she constantly forgets the past. She embraces her lack of control and approaches every minute as a new, usually delightful, adventure. The story of how Marlin learns to trust Fate and give up control is the driving force behind the story. Since both children and parents struggle with this question, the film appealed to both.

For the Christian writer, the moral proverb offers a good way to tell a story that helps people think through questions of morality and wisdom without violating social norms about how we talk about religion and ethics.

The book of Proverbs provides a model for this kind of story. A proverb like “The borrower is the lender’s slave,” isn’t a weird religious idea. It’s good plain common sense. So we can follow the example of Proverbs by telling stories that portray the best way to live.

Explicit Conversion

The trouble with Moral Proverbs is that they don’t go far enough. The essence of the Christian message is that try as we might, human beings simply don’t do good. Proverbs can help improve behavior. They can steer us away from the most damaging mistakes. They can help us recognize our inability to do good. But they do not make us good. If all the world needed was a little more ethical education, Jesus didn’t need to die on a cross. The gospel begins with the idea that moral education is not enough—that Jesus himself is the key to living the human life well.

This leads us to the second way that Christian writers can frame their stories. A story that shows a character hitting bottom, recognizing her sinfulness, accepting Christ’s death and resurrection, and experiencing life transformation portrays the gospel explicitly.

The only place in a modern bookstore where you’ll find this kind of story in abundance is in the Christian fiction section. That’s a pity, because the Christians who shop in this section are precisely the people who least benefit from these kinds of stories.

Yet some of the greatest novels of all time are explicit gospels. Dostoyevsky’s The Brothers Karamazov. Tolstoy’s Anna Karenina. In each of these tales we watch one of the main characters undergo a conversion. John Bunyan’s Pilgrim’s Progress is another familiar example, though here again mainly Christians read it.

Christian writers yearn to portray the gospel explicitly in their stories. The gospel is, after all, the deepest and truest solution to every human life. It is the ultimate resolution to every plot. But secular publishers, reviewers, and readers will tend to see a novel with an explicit gospel as idiosyncratic and sectarian, no matter how superb the rest of the storytelling is. So an explicit gospel is rarely a good option for authors wanting to tell their stories to a broad audience.

The Metaphorical/Allegorical Gospel

C. S. Lewis’s The Lion, the Witch, and the Wardrobe offers an oft-discussed option for portraying the gospel in a socially acceptable way. Throughout the Narnia series, Lewis portrayed Jesus as Aslan the Lion. Although it was easy enough to perceive that Aslan was Jesus, the distinction made the story more oblique, less jarring, and more intriguing.

All the elements of the gospel are present in the series—particularly in its first book. Satan is there as the White Witch. Sinners are represented by Edmund. God the Father is described as “The Emperor Over the Sea.” The cross appears as the Stone Table. Lewis tells the gospel, but he tells it allegorically. This has the effect both of veiling it—making it harder to reject outright—and of illuminating it, giving us a fresh perspective on the Christian story.

Although many admire what Lewis did, metaphorical and allegorical retellings of the gospel are uncommon in fiction literature. Perhaps Lewis did his job so well that few others feel the need to retread that ground.

Tight-Lipped Conversion

One of the most generally useful ways of portraying the gospel in a secular story is to show the beginning and the end of a conversion without showing the middle. In this kind of story, we see a character hitting bottom. Later we see them transformed and whole. We are not told explicitly what happened between their collapse and their renewal, but we are given hints that they experienced Christian conversion.

Take for example this imaginary novel. One of the secondary characters—we’ll call him Ryan—is a professional louse. He’s rude and selfish, a drunk and a womanizer. Through the first half of the novel we watch Ryan deteriorate. Every time we see him he is worse off than before. By the midpoint of the book he is unshaven, unkempt, basically homeless after his last girlfriend booted him out, and constantly drunk. Then, for a few chapters, Ryan disappears. None of the other characters know what happened to him and no one particularly cares.

Suddenly Ryan shows up again, and he’s different. He’s still badly shaven but at least somebody washed him. He doesn’t reek of bourbon. But the big difference lies in his eyes, his face. As we hear him speak it’s with a different voice—now humble, helpful, not without wit but far more reserved.

The other characters mutter for a chapter or so about the transformed Ryan. Finally someone comes around to asking him what happened. “I finally found someone who loved me enough to kick me in the seat.” Then we notice that the gold chains that use to decorate his neck have been replaced with a simple cross.

In one sense, a tight-lipped conversion like Ryan’s is a reduction of the gospel. It draws back from an explicit portrayal of Christian faith. But this sacrifice of explicitness is offered in exchange for accessibility. Secular readers may not receive the full gospel but they do get a story they can understand and enjoy. Although the gospel itself remains hidden, the pattern of moral destitution and recovery that characterizes the sincere Christian believer is clearly portrayed.

Tight-lipped conversions serve as an invitation to an inspiring—if vague—hope. Ryan’s cross is a clue that you can ignore or pursue. You may ignore it now, but if you ever find yourself in a dark place like Ryan’s, maybe you’ll investigate further.

Prefiguration Stories

The gospel is a rich and complex story with many different parts and ideas. We cannot understand what Christ did on the cross without grasping these underlying ideas. Sin, holiness, righteousness, love, covenant, forgiveness, atonement, sacrifice, redemption—all of these elements are fundamental to the gospel story.

The Old Testament does not explain the gospel, but it does prefigure it. The Hebrew Scriptures portrayed each of these fundamental elements so that the gospel would make sense when Christ enacted it.

In the same way, modern writers can prefigure the gospel in the minds of their readers by portraying certain elements in clear, vivid terms. A novel that clearly portrays the horror of sin, for example, paves the way for its readers to grasp why God demands retribution for sin.

A wonderful and perhaps surprising example of a prefiguration story is The Lord of the Rings by Catholic author J. R. R. Tolkien. Tolkien’s novel prefigures the gospel in many different ways, but one of the most obvious is in his portrayal of the hero Frodo.

What is it that makes Frodo a hero? It’s not his strength, his prowess with a weapon. It’s not his wit, his cleverness or charm. It’s not even, precisely, his courage—though his courage is considerable. What makes Frodo such a remarkable hero is two qualities that are fundamentally Christian.

First, Frodo trusts that Fate as he understands it—the unnamed God who lovingly and sovereignly presides over Middle Earth—will snatch victory from the jaws of defeat. Although Frodo’s own efforts are feeble and basically foolhardy, he trusts that God will honor his obedience and the prayers of his friends by granting victory over the evil Sauron.

Frodo’s second heroic quality is his self-sacrifice. Frodo fully recognizes that although his quest may bring peace to Middle Earth, it will probably destroy him. Indeed, Frodo’s quest does destroy him—he returns as Frodo the Nine-Fingered, wounded and in some sense humiliated. He is haunted by his attachment to the Ring, cannot settle back into life in his old home the Shire, and ultimate abandons Middle Earth to travel to the Uttermost West—a symbol for the afterlife. Frodo accepts the mantle that Fate places upon him despite the terrible cost to himself. This is a Christian view of heroism. It is evocative on Christ’s own quest.

Christian stories can serve the gospel by vividly showing parts of it. Readers may not understand the gospel through a story like The Lord of the Rings, but they do begin to grasp and to love some of the values and ideas that feed into the grand gospel narrative.

Other Models?

Are there are models for how Christians can tell stories that honor the gospel without smacking readers in the face with it? I’m still searching for solutions to this tension. Please share your ideas!

I wrote this song years ago to cheer myself up. Maybe it’ll cheer you up too.

I appreciate your openness in talking about your ideas with me. I applaud your drive in moving forward and trying to get your ideas made.

But your questions have made me realize that I wasn’t clear enough in my first post. So let me be clear.

Never in a hundred million years will you ever sell your game idea to a company.

Game developers never, ever, ever, ever, ever buy game ideas. Game publishers never, ever, ever, ever, ever buy game ideas.

They never accept free game ideas. They will not even listen to your ideas.

You have no chance—Zero Percent—of ever selling any game idea to a game company. If you want to get your game idea made into a game, talking to game companies about it is a total waste of time and energy.

The brilliance of your idea has nothing to do with your chances of getting a company to make the idea. If your idea is mediocre you have a 0% chance of getting a company to make it. If your idea is the greatest game idea that mankind has ever seen, you still have a 0% chance of getting a company to make it.

Game companies do not buy ideas. They do not accept free ideas. You will never get a company to make your idea.

Okay, is that clear now?

You know, I don’t enjoy crushing people’s hopes. I know what a powerful, passionate feeling it is to have a game idea that you can see and hear and smell and taste. You know just how it would look and play. You can see the awesome boss monsters, the wrenching camera angles, the astounding visual effects. It seems so real. The vision in your mind feels so close to the games you play on your screen.

The only thing standing between you and making your game a reality is $20 million. If you only had eighty or so highly-trained, experienced game programmers, artists, and designers working 60 hours a week for three years, your game could get made and become a hit! If only a game company would fall in love with your idea as you and your friends have, you could see your vision become reality.

I know how that hope feels. It feels something like lovesickness. You can’t stand the thought of your awesome idea wasting away in the obscurity of a few shabby pencil drawings. It deserves better!

I know what that feels like. Like I said, I don’t enjoy crushing your hopes.

But false hopes will get you nowhere. And I’m here to tell you, as someone who has worked in the game industry for 15 years, that you will never, ever get a company to make your idea. That’s a false hope. Don’t waste your time on it.

But there is a way to get your game idea made into a game. Two ways, in fact.

1. Make it yourself.
2. Build a career in game development.

Making it yourself either means spending a ton of money (millions!) to hire other people to make it. Or it means gathering a group of friends to work on the game on an amateur basis. That will probably mean scaling down the quality and scope of your vision, but you can still make the essence of your idea.

Building a career in game development means spending 10-15 years working on other peoples’ games until you’ve gained enough power and respect to call the shots. If you can win that kind of respect you might be able to make your own game. But 10-15 years is a long, hard road to walk. And even if you walk it, you may never win the chance to call your own shots. I’ve made dozens of games since I started in 1995, yet it’s rare that I get to choose which game to make. The people with the money decide what gets made. That’s just the reality of the business.

So you can get your idea made. But it’s not going to be easy. And it’s not going to happen through talking to a company.

You can read more about your options for getting a game idea made in my previous post on this topic.