Same game logic on two separate graphic libraries

Question

What code philosophy/structure of abstraction/program design would allow a game to be used with both 2D and 3D graphics (separately) WITHOUT having to re-code the Game logic?

We're talking taking the same code, changing a minimum of things (for example, exchange filenames for 2D assets with filenames for 3D assets), and maybe plugging in a few specialisations of a base class per generics/templates.

To put it in a real context where it makes sense: imagine a LAN-multiplayer game where there is one top-notch, performance-hungry 3D client for the players with some really good gamer rigs, and a more humble 2D client for the old dusty boxes that someone found in their attic. But it's still the same game - the same events are registered (someone picked up a coin), the same Network protocol is used, the worlds are proportional, etc.

To put it in a MVC context: The Controllers are the exact same (pressing the "Up" key will set the players acceleration at 3.5 units/second), the Views are totally different (2D versus 3D), and the Model is the same except for anything directly related to graphics (a collision check for the environment is performed every 5 seconds, and it uses the same algorithm. Note that this would mean there IS a Z-coordinate for all the Game Objects in the 2D version, but it's just ignored or displayed to the user in another way, for example by a shadow that is displayed further left when the player is in the air).

What makes this such a fascinating topic is that it would FORCE the developer to have a very clear idea of how his data is structured and how control flows. Note that this does not imply using anything other than a graphics library like SDL, D3DX or OpenGL. No game engines!

Since this is a mostly theoretical question, I'll leave programming languages out of it, but if you want to give an example you can use any language you like, C++ if you want to go the whole hog, or even Brainfuck if you feel up to the challenge (Any concrete answers will be appreciated, as well as any abstract ones!).

Answer 1

I think that all (?) you would need would be a layer of abstraction wrapping your graphics library; you would need a new one for each library you would be using, and each one would need to have the exact same external API.

Think of localization of strings: instead of hard-coding the string "Inventory" into your game, you would instead call your (possibly custom-built) localization library, which would do some processes and return a proper string, depending on the context of the game.

In the same way, all calls to your graphics engine would be made through your wrapper around it.

In doing this, you limit/restrict what commands you can give your graphics engine. Here are some essential ones:

1. Draw (graphic object) at (location)
2. Modify (alpha, rotation, etc.) property of (graphic object)
3. Move (graphic object) to (location)
4. Build map of (level name/data structure)

And some others, which you will find as you work on your project.

If you are using a Strict-Typed Object-Oriented Language, you would call the above commands the interface that your wrappers will all implement. Preferably, these will be the only un-protected/public methods.

Now, create a new wrapper for each of your graphics libraries, and implement the API. When a command to draw __ at __ is given to you, you must use code to create the sprite or model, and draw it into your environment. This might require some trickery, such as storing each sprite in a hash to be re-accessible at another time by a given symbol.

As for building maps, the most efficient way would be to pre-build each map for each graphics engine before-hand and do a lookup. Alternatively you could store the map in your own custom data structure and then use your wrapper to build a map from that data structure.

Hope this helps gets you started =]

Answer 2

Building your game's architecture with a paradigm close enough to MVC to allow complete abstraction of the display code would likely be quite difficult for any large project. However, it seems like the biggest impediment to creating a game that supports both a 2D and 3D client would be designing a game in which both clients are equally capable.

It would be necessary to begin your game's design with the full intention of creating and supporting the two clients, and it would probably be safest to restrict all game functionality to what makes sense for the 2D client.

As an example pitfall, if you were not designing to a restricted functionality set you might create levels in which important information or objects were only visible from specific angles. While that would be fine for 3D clients that have 360 degree viewing freedom unless your 2D client explicitly supported a viewing angle that had visibility on each of those important objects, you would be impairing users of the client.

It would be best to set out a specific number of viewing angles for the 2D client (8 or 16 or such) and develop all content to fit within those constraints. Unfortunately if you have levels and objects that are designed to be viewable only from a specific set of angles, it can look quite odd from within a 3D client.

In my opinion it would be a poor choice attempt a game design allowing for 2D and 3D clients that are intended to have equal capabilities. I think it would be a better use of resources to design asymmetrical gameplay options, and allow each client to play to its strengths. For example if the 2D client were primarily focused on a strategic-level perspective on the game world, with the 3D client being used for tactical-level gameplay.

Answer 3

I think you've pretty much answered your own question:

To put it in an MVC context: The Controllers are the exact same (pressing the "Up" Key will set the players accelleration at 3.5 units/second), the Views are totally different (2D versus 3D), and the Model is the same except for anything directly related to graphics.

So, by providing an adequate abstraction between input, game logic, etc and graphics, you will have solved the problem.

This is basically the point of the MVC model, especially as it pertains to desktop and web applications: there can be multiple clients accessing and manipulating the same data (a web interface, mobile client, and desktop client for email, for example).

Answer 4

Keep it simple if you want it simple: - Write the game logic to move the objects. Don't store any data on them that is related to rendering. - Write renderers that are given a chance to look at the state of the game data and draw it.

You can use more or less complicated programming techniques for this. The only thing you need is a way to get to "extra" data you need to render for each game object. The simplest way is to have zero extra data required! If the game object is a "Wizard", draw a Wizard.

If you need more complicated methods, consider polymorphism, memento pattern, hash tables, void* pointers, etc. Don't over engineer it (most of these methods are over engineered).