Smasher's Engine

Somewhere along the way, people seem to have gotten the idea that videogames need engines. But I remember a time before this idea.

I was a kid, and my family had one of the early home computers: the Commodore 64. On these systems, people usually programmed games directly, with no concept of an engine. What is a game engine?

These early home videogames were computer programs. I suppose you could refer to computer programs as engines. That would mean these videogame programs were themselves game engines. This makes some sense: You run them, and they make the game go. But I don't think that's what people mean with the game engine idea.

The idea of a game engine, so far as I can tell, is that much of a game's programming can be generalized—it can be used to support multiple games. We call this shared foundation a game engine.

This idea has evolved, and we now have many vendors publishing game engine products. And people are making great games with these engines. Life is good.

But I think it's bad when this idea steps too far—when people start thinking a game needs a game engine.

In this idea space, if you can't find an existing engine that suits your needs, there's only one other option: Make your own game engine.

This sounds similar to "programming your game directly," but I think it's a drastically different mindset. Here, you are no longer programming a mere game, but a far more formidable beast: a game engine.

You might start thinking of your game and your engine as two separate things. You may even take the worst path: Try to build your engine first, and then start on your game once the engine is complete.

I'm not just theorizing here. I've spent years roaming such tortured hell paths of engine building. Heed my grizzled warning.

Perhaps the lesson is that I should use some existing engine. But third-party engines have never appealed to me. I want to explore the videogame medium. I don't want an engine between me and this medium.

In Smasher, I'm exploring the nature of a certain kind of real-time, maneuvering action. To do this in a deep and pioneering way, I can't use someone else's generic game movement system—I need direct access to the calculus.

Likewise, I need to handle my own collision detection, artificial intelligence, and graphics rendering. These are intimately connected with the player's action experience—I need raw access.

The concepts listed above—movement, collision, intelligence, and rendering—are generalized game concepts. And so it's tempting, in our modern times, to think of their collective implementation as a game engine.

But this is not allowed here. The game engine mindset is banished from the Smasher development kingdom. For Smasher, I choose a different mindset: There is no engine.

I'm not programming a generalized movement system, or collision system, or any other generic game functionality—that's game engine thinking. Here, everything is specific to Smasher. What's a game engine?

A neat result emerges from this process: All the game's functionality is bespoke. Everything that happens is hand-crafted for the game. You can feel this! Entering Smasher becomes entering a unique space.

All of this is further enhanced by another rule: Game assets are banished from the Smasher development kingdom.^*

I'm not drawing graphics in a pixel editor, or recording sounds with a microphone. That would produce image and sound files, referred to as game assets (to distinguish them from source code).

In Smasher, everything emerges from the same process: computer programming. The graphics and sound are procedural—I program them. They boil down to source code, just like Smasher's movement and collisions. It's all the same stuff. What's a game asset?

So here we are: Smasher has no engine, and has no assets. Life is good.

But how do I present Smasher to the public? When asked, "what engine does Smasher use?", how should I answer? I'm not sure the public is ready for "there is no engine."^†

So I answer in the way that our modern time understands: "I made my own engine."

Except I want to sell the game, so this becomes: "I made my own engine, and it's fucking awesome."

And then I talk about all the neat features of Smasher's engine—how it can support ten-thousand monsters at once, all chasing you, with a variety of intelligences, using time-swept collision detection for high speeds, and running smoothly on a 240hz monitor.

Or I talk about the motion-blur used for easier action parsing. Or 4K monitor support. Or the slick level editor. Or how the game fits into around eight megabytes of disk space.

Engine bragging leans towards the technical side of a game's implementation. But these technical details only matter to the degree they support the player's game experience.

And so my engine's proudest feature is that it is bespoke: Every line of code is created specifically for Smasher's experience.

We'll talk more about what it's like to play Smasher in future posts.

^* Be sure to tell me when I've gone mad with power.

^† Unless I can somehow trick them into reading a bunch of my philosophical rambling.

Wishlist Smasher on Steam

Subscribe with RSS

Previous:
A Ludic Medium

Next:
Smasher's Avatar

Contents: Smasher Devlog