Cross Platform Game Engine Series - Introduction

Introduction

Video games are very complex projects that combine design, art, and programming that take a lot of work and effort to create. Now, imagine if you had to rewrite a lot of code to render graphics, manage scenes, save and load games, and many other features common to all games every time you wanted to create a new game.

This is why game developers make and use game engines. A game engine handles the vast majority of common things that games need to do so that game developers can focus on making a great game.

But what if a game engine isn't available for the platform the developer wants to work on? Say like the PlayStation Vita? Well, they are going to have to make their own engine. This is what this blog series is about – designing and building an engine for the PlayStation Vita.

Design Goals

 

So what would our ideal PlayStation Vita Engine look like? Well our ideal engine would be:

• Data Driven

A data driven game engine is the theory of separating game logic from engine logic completely. This is often done by having the engine use scripts or data located outside of the engine somewhere – allowing the same engine to be used to make just about any game imaginable.

A more in-depth example along with other resources can be found in this stack exchange answer.

• Cross Platform

Although the target for this blog series is a PlayStation Vita engine – it is easier to design a game engine to be cross platform in the beginning than to try and port the engine to a different platform later.

The platforms our engine will try to target are: Android, iOS, Windows, Mac, Ouya, Windows 8 Metro Apps, and of course the PlayStation Vita. These platforms are all open platforms that have low barriers of entry to developers.

Now that the design goals of the engine are clear there is just one last topic to discuss before getting to work on the engine.

Programming For End Users:

Unlike most software projects – the end users of a game engine will have to be able to see and interact with at least some of the code of the game engine in order to get the full use out of it. This means that more so than in other projects – the code behind a game engine needs to be consistent, clean, clear, and able to guide end-users on the ‘right way’ of doing things.

I will get into more specifics on how to accomplish this in later blog posts – but for right now that means that in general the game engine should:

• Don't Let Code Crash

The end users of all applications have vastly difference experience levels – but when those users will be interacting with your code on some level it can be dangerous. For that reason any code exposed to the end user should, as much as possible, be crash proof.

The end user passed in some nonsense valid to one of your functions? Your code should either – 1) Make sure the code doesn’t compile in the first place OR 2) Fail gracefully and inform the user about the error with as many helpful hints as to how to fix the problem as possible.
 

• Hide Complexity From The User

If the end user doesn’t have any reason for mucking around with a given piece of code, then that piece of code should be effectively invisible to the end-user.

 

• Keep IntelliSense In Mind

Most end users are probably going to want to use code IntelliSense when interacting with the game engine. This means that all engine code needs to be sure to use documentation comments with tags. A good list of the available documentation tags is available from Microsoft.

 

• Keep Documentation In Mind

Good documentation is a must for any game engine – and while IntelliSense is great it doesn’t help users unless they are already digging into code. Fortunately, if the engine has proper documentation comments, tools such as Doxygen can speed up the process of creating documentation.

Conclusion

So far, I have only touched on broad design goals and some general coding principles, but these broad goals and principles will guide how the various systems of the game engine are designed and implemented.

This blog series will continue next week with Cross Platform Game Engine Series – Basic Objects where I will discuss the basic objects that are needed before the game engine can really start to take shape.