A Text Based Game Engine

A Text Based Game Engine

Postby PyroDragn » Tue Feb 05, 2013 1:08 pm

What is a Game Engine?

I am writing this post to follow up last week's challenge to create a text based game engine. A few people in skype chat seemed to bemoan the idea of creating an engine versus creating a game; that is, they would rather have been tasked with creating a 'Game' rather than an 'Engine.' From my perspective they are essentially one and the same, with the engine actually being the easier aspect in this case.

There seemed to be a lack of consensus as to what a Game Engine actually is. One definition in the chat was that an engine is a tool used for game development. Now, while I accept that this is technically true, there is a difference between a an engine being used for game development, and an engine being designed as a game development tool. I'll try and explain the difference.

If I talked about a Physics Engine, I think most people would be able to agree on what that was. It's the part of the game which handles the physics. A Graphics Engine is the part that handles rendering the graphics. What is a Game Engine? It's the part of your code that handles running the game, or, basically everything that isn't content.

Every game has a game engine; Whether it's a complicated all-encompassing engine like the Unreal3 engine, or whether it's a simple subset of code to handle rendering and collision detection necessary for a game of Pong.

Used for Game Development, or Designed for Game Development:

As I said earlier, someone on Skype suggested the idea that a Game Engine is a tool for game development. However, I think that they were specifically concerning themselves with the premise that a game engine must be designed as a tool for this purpose. This, I would argue, is simply not the case.

Here I am going to talk about a physics engine because it is more concrete than something like a text-based game engine. Making a platformer (2D sidescrolling akin to original Mario games) requires a physics. When the player jumps, the character should be subject to gravity, and fall back to the ground.

There are two different ways this could be implemented:

1) Hardcode - when the character jumps his vertical velocity increases and he rises into the air. Then he slows down, until eventually it goes negative and he starts falling, until he reaches the ground and he stops.

2) Dedicated Physics - create a class that handles physics for all objects. This would apply gravity to objects, ensuring that they 'fall' correctly. Then you apply this to the character.

The difference between these two is absolutely nothing. They are both physics engines. They are both sections of code with regard to handling the physics aspect of the game. Neither of these, however, is specifically designed with the purpose of being used as a development tool. You could implement the second into a development tool - if you designed it as a self contained unit, and it could apply to any object identified as subject to gravity. But regardless of whether you do this or not, it is still a physics engine - it may not be a very easily implementable, or customizable one, but it is one.

When you're talking about a game engine, you talk about the code that handles the translation and implementation of the game. The Unreal3 engine is a game engine because it handles the running and processing of the game, not because it can be used to make a game easily. If it can be used to make a game easily then that is a bonus, but it is not a prerequisite.

In terms of a Text Based Adventure game engine, the code that would handle creating the window, displaying text, parsing input - this is the engine. The level design, story, lore, writing - this is all content, and the actual game design.

A game engine could be designed and refined as a game develops. If new functionality is required it is hardcoded into the game. Adding a new function is editing the engine. Implementing a new mechanic is also editing the engine. When you think about what your game can or cannot do, this is what your engine can or cannot do. If you design your game engine to be reuseable and editable for easy deployment and development then that is great, and can make your development easier. But again, being easy to use is not a requirement for a game engine, just being able to run a game is the primary purpose.

Differentiating Engine from Content

This is where I believe a lot of confusion arose, and is merely a question of implementation. Imagine a Text Adventure game where you start in a field, and you can go North from there. The first thing you do in your code therefore, is display the line "You are in a Field. There is a path going North." It seems straightforward. For argument's sake, in pseudocode this line is:

Code: Select all
DisplayMessage("You are in a Field. There is a path going North.")

Just in this one line, "DisplayMessage()" is part of the engine, "You are in a Field. There is a path going North" is content. If you wanted to change the content of the game - change the story - you would change the text of the message. You could start in a house, or a castle, or a submarine. The content of the story changes in that regard, but the process for displaying the content - the engine - remains the same.

Implemented a different way:

Code: Select all
 CurrentPosition = 1



Code: Select all
1:You are in a Field. There is a path going North.

In this example, the distinction between Engine and Content is clear. The engine finds your current position, loads the appropriate text from the content, and displays that text. The content file just contains the text for each appropriate position. People seem to think that this would be an example of an engine, whereas the first case is not, however they are functionally equivalent.

Creating a Game versus Creating an Engine.

When creating a game your first point of call is usually the engine.

If you're making a platformer, you need to make an engine where something can jump onto other things.

If you're making a tetris clone, you need to make an engine where blocks fall and stack onto eachother.

If you're making an FPS, you need to make an engine where the player can move in first person and shoot other things.

If you're making a Text Based Adventure, you need to make an engine which will display text and accept command line inputs.

This, was the crux of the weekly challenge as I saw it. You had to make an engine for a Text Based Adventure, this means that it had to display text, accept commands, and process commands appropriately.

Making a Text Based Game, would mean doing the above - and - writing a story, setting, designing a level, and basically implementing content. This is all superfluous to the programming aspect. Whether a game is any good will depend on the story, and the depth. Whether an engine is any good depends on the programming and implementation.


When you're making any game, you're making a game engine. I hope I've put my viewpoint across clearly; Looking back it seems like I ramble in parts. In essence, when you're programming functionality, you're programming the engine. When you're adding story/setting, you're adding content.
User avatar
Posts: 18
Joined: Thu Jan 31, 2013 1:50 am
Profession:: Project Designer

Re: A Text Based Game Engine

Postby Tyler (TJ) » Tue Feb 05, 2013 11:36 pm

Great article Pyro! Thank you for clearing that up for everyone. :)
User avatar
Tyler (TJ)
Posts: 34
Joined: Wed Jan 30, 2013 9:59 pm
Profession:: Programmer

Return to Programmers

Who is online

Users browsing this forum: No registered users and 1 guest