KKSNetwork™

In a previous article, I have outlined the development of a single game. With much delay, the follow up of that article is finally up. Sorry about the delay
The difference between a single game and a game engine is the expandability of a game engine.

As you can see from last article, 1 game can be easily developed. You can anticipate what sort of actions the player can take on certain objects of the game, making the process simple, as you don’t need to consider with things that will not appear in your game (no s#!t).

However, what about a game engine, how would you know if the game you’re going to create, or someone else will create, will need the player, for example, to lick an object?

Before we get to all that, let’s back up and talk about a game engine.

First, what exactly is a game engine?

Note: For those who are tech-savvy enough to know about this, feel free to skip ahead. (If you are really that tech-savvy you might as well not read this article, there’s probably errors in them, although i try my best not to include any.)

A game engine is not a game. This is probably the most important concept of all. A game engine is like a fish in a fish tank. You can take the fish out of the fish tank and put it inside a better tank. The game engine itself is not the graphics we see on the screen; (although it includes components to render them, but that’s for another discussion) rather, it’s everything that makes those graphics work with each other.

A game engine is created because its creator is lazy. As you saw in the previous article: although creating a game is very simple, doing it over and over again can be annoying, especially when you have to copy and paste + modify a large amount of code. A game engine, on the other hand, will allow you to create a game without modifying or create the basic rules and game elements over and over again.

A game engine is like tools in your toolbox. A game engine usually has tools that simplifies certain game process, like physics, rules etc. These processes themselves can be very complicated and would be very inefficient if one were to code them everytime they create a game.

Now that you have a very very very basic understanding of a game engine, let’s talk about how to actually make one that’s text based. The code that’s going to be included in this article will be in Python, as it’s just awesome. Note: If you came here looking for high end graphic rendering codes, you have come to the wrong blog. I don’t even have an understanding of how rendering engines work, yet.

Defining Basic Game Elements

Every single game should have some sort of rules based on the laws of physics, even a text game. For example, the player shouldn’t be able to see without light in the current room in a text based game. These attributes should be defined in a Room object or a World object, depending the type of game you are developing.

These Rooms or Worlds should be connect with each other via a direction. In a text baseed game, the 6 basic direction you can have is north, east, south, west, up, and down. Some people decided that it’s a good idea to have an in and out direction, but for the purpose of this demo being simple, those won’t be included as it gets complicated real fast.

How are we suppose to tell the computer that these Rooms and Worlds are connected via these 6 directions? The simplest way is to connect them via an attribute in the object’s instance.

>>> class Room(object): pass

>>> room1 = Room()
>>> room2 = Room()
>>> room1.north = room2
>>> room2.south = room1
>>> print room1.north
<__main__.Room object at 0x012202D0>
>>> print room2
<__main__.Room object at 0x012202D0>
>>> room1 == room2.south
True
>>> room2 == room1.north
True
>>>

As you can probably see in the previous example. Doing this for 10 rooms can be disgusting. This is why a game engine comes in handy. You can simply define a function, or better yet, a method within an object, that will “connect” all these rooms with each other. It would save you a lot of work.

There’s also the Item class. This class stores the property as well as the methods of a certain Item. For example, we have a pen, which can be taken. So we might want to do something like this:

>>> class Item(object):
        def take(self):
            if self.takeable:
                # Move item to player's inventory
                print("Item moved to player's inventory")

>>> pen = Item()
>>> pen.takeable = True
>>> pen.take()
Item moved to player's inventory
>>>

Now that the final engine you create probably won’t need you to set takeable every time, it might just get it as a parameter for the object itself. But this is just a proof of concept.

Lastly, we have the Player object. This object should store the current location, the name, and other attributes that’s associated with the player.

Of course, you can always have other classes, like task, events, characters etc. You’ll find that as the number of features increases, it will become increasingly difficult to store all the properties associated with different classes. You’ll find that storing the data/creating the data with python code is a lot of work for not a lot of gains. This is why you should consider building your engine around a data storing methods. It could be your own format, SQLite that’s built into python, and/or XML documents.

The best idea is to design a parser for your preferred database format first before tackling the core engine itself. Even though I made an engine at first, I had to scrap it because it was not compatible with the XML parser I created, which is way more efficient for passing data around.

On that note, this concludes this article. I will try to write more on text games and other python projects in the future. If you are a python newbie, I’ll be writing an article in the near future (within 4 days) to give you some heads up. Also, more in depth on game design will be coming over the next couple of weeks.

If you happen to find a mistake in this article, feel free to correct me by commenting below. I would greatly appreciate it!

Lastly, some announcement about this blog: there’s going to some be big changes to this blog over the next few weeks. Details are being worked out right now. So subscribe with your RSS reader and stay tuned!

Related posts:

1. Designing a Text Adventure/RPG Game For the past month, I’ve been coding a text adventure...
2. An awesome book for learning python Learn Python for newbies and professionals, the easy way....

Related posts brought to you by Yet Another Related Posts Plugin.