I don’t want to start the discussion again whether design or technology should be law when developing a game. I posted my thoughts in the post The rise and fall of game projects so don’t worry. You won’t find a theoretical discussion about game development ethics dos and dont’s.

What I want to show here is a guy (I’m sorry if it’s a team and I don’t know) named Johan Peitz. If you love good games you should check out his site Free Lunch Design. This guy is awesome and in my opinion the only guy out there who understood what’s all about game development. Check out his site. His game Icy Tower is an award-winning blockbuster he wrote. What did this guy do? He takes game engines like allegro and concentrates on what he can do best. Developing games. And hell yeah he is a real game developer. Alex the Allegator, Harold’s Hills or the incredible Happyland Adventures are only few to mention here. This games are so addicting.

But he also understands to try new ways for his games. Check out Frog Hunt. Senseless? Yes and No. Both answers are right. There are only two possibilities. You understood the sense or you didn’t.

Why so much advertising for guy I don’t know? Because he is at moment the only one who deserves the title game developer. Instead of sticking with game engines, trying to bring groundbreaking graphics or new rendering techniques to public he is programming games with only one thing in mind. Play!!! And damn yeah you play the games and they are fun.

If you still haven’t visited his site you should now do and if you are an amateur game developer or want to be one you should consider what he did. Concentrating on gameplay. As long as you don’t work for id Software which is the only game company where we expect the technical progress to be law you should do it like Johan Peitz where design is not only law but maybe (and thank god for this) the only word this guy has in mind. Many commercial and professional game studios should take him as example for great game design.

The idea of my failed game project still rumbles through my mind. Also the idea of ION Storm of running a team which concentrates on design is very interesting to me. Ok, I'm a programmer, Ok I love developing on a game engine, but how would it be having a game engine already done and setting up two or three separate teams working on their own games? It would be an interesting experiment setting all this up to get it started. A fact that we shouldn't loose out of focus is that this would be only an experiment. That means that of course fun should be the main push. I thought of this now for over three weeks and would love to realize some experiment like this. I already wrote in my blog "The rise and fall of game projects" about the failure of my game project, but expanded my thoughts as you soon will notice here.

What exactly would we achieve with this experiment? First of all it would be a simulation of what ION Storm faced that days. We would see if Romero's idea of running a company with design as law would succeed when changing some factors. I must admit it's difficult for me to write those lines. As a software developer technology is always law for me, but the basic idea of ION Storm was so great I think and I also think that yes ION Storm would have succeeded but I won't start a discussion of what things should had have to be different. Back to our project, another interesting point would be to see which team pushes the used engine most. That would indicate how teams handle technology and how design. And that's exactly the point what we would like to find out. How would a team handle a given technology and how would this look like compared to the other teams. How much would the teams be influenced by the design documents and how would they implement it into the final game.

Let us think about it how things would be set up.

The core team

What we would need first would be a core team. I call it core team since this team would be responsible for the engine. Yes I know I said above we would use an already ready-to-use engine, but there are always tasks to be done so let's say we would recruit two or three coders which are responsible for bug-fixing, creating the main tools like editors etc. The core team should also be a support team for questions coming from the game teams. The core team would also set up the project management tools, the issue trackers and so on.

The game teams

The game teams would consist of the graphic artists for textures, sprites anything graphic related. Also some guys for sound and music would be great. The game teams need a storybook (design document for the game they want to produce). Depending on how extensive the game shall be at the end some coders would also be necessary. They will create the actual game and if necessary some additional tools. Every game team should have a project manager. This guy can be either a team member mentioned above or a separate person. He holds the team together and dedicates his time on keeping the project alive. He is the interface between the sub teams of developers, mappers, artists. By extending those "administrative" tasks to a project manager a game team can concentrate on their actual work. Creating the game.

In fact we could have 1-n game teams. That would just be fine. But it would only work if the game teams would be complete teams. The funny thing is that the teams would be really separate teams. No communication would be allowed between the game teams only between the members of the same game team since they should concentrate on their own work.

General rules

• Game teams start simultaneous to develop their game
• Tools must be set up before development starts so that the game teams can fully concentrate on their project
• Every team has a fixed period to finish the game project. the period will be specified by all the teams before starting the development. This period will be the deadline
• Every team may develop a game they want to, as long as it is what their design document specifies. If the design document is about Pac-Man and your result is Donkey Kong than you failed so the project managers are given full creativity to create something they like

Do's and don'ts of the core team

the core team has to provide:

• the engine bins
• the development environment. That includes the header and library files needed to use the game engine
• code examples of the main engine features
• a complete sample application of the game engine
• a documentation of the game engines API
• project management tools. That includes a project management for each game team to schedule milestones, assign tasks, issues and a communication center like a wiki. All the game teams would have access to their own project management tools so that all game teams work under the same conditions
• the engine specific tools needed for the game engines specific file formats like importers/exporters for 3rd party tools, mapping tools or editors etc.

Do's and don'ts of the game team project managers

• the project managers are not allowed to communicate neither with other project managers nor with other game team members. They have to concentrate and push their own team
• the project managers have to meet with the basic team once a week. In those meetings they have to report in short about the current project progress, about the state of resources and about their project in general. This meetings can be held very short but are necessarily since the core team will use the information for the final statistics. Although you might find it more useful to concentrate on work those meetings are very important to detect later on mismanagement and or improve some time or project critical paths in the several project states

Do's and don'ts of the game team members

• the game team members are not allowed to communicate with members of other teams.
• if the game team members want to switch game team they have to contact first their own game team project manager and after that the project manager of the desired team.

Conclusion

The above notes are just some thoughts I made when reading the ION Storm story. My notes about the experiment are ideas how I would handle that stuff. Of course the ideas and thoughts above are few and incomplete but the that's the point. The experiment should only give some impulses and ideas. The rest is up to the project managers. To tell you the truth I will maybe start this experiment as soon as I have the time to build up a core team and get some project managers for the game teams. Maybe some parts of the notes above seem to lead to rivalry between the game teams but that's only for getting some competition between the teams to push them to their best ;)

Now what do you think? No no I don't mean why ION Storm failed. I would like to know your opinion about the experiment above. Would design really be law or would the game teams start mailing the core team about requests on new features? Would the games released by the teams be on the same technical stand or would they differ much? Would single game teams be able to push an engine to the limits or not and if they would be able, would they be able to push the engine driven by the design document wanting to have the game as it was written or driven by their ego to include the latest state-of-the-art features? Would an abrupt engine swap make thinks different or not? Would an exchange of game team members or even game team project managers make thinks more difficult? Would the project managers manage to handle their resources or not? Would they also achieve to complete their tasks keeping their team together?

So many interesting questions sadly no answers. You could expand that list till eternity, but you will only receive an answer if you try it out.

The idea of starting simultaneous teams to create something on their own (and I really mean on their own) is quite an interesting task especially when I thing of how different the results could be. If you have tried something like this please share your experience with me. I'm always interested in game programming projects since they are the only ones who do not fit within an usual project concept.

Thanks for reading this

So what is that title about? What is intelligent DLL design? When designing a game engine you have to take care of so many things. You have to think of inertial delay times, transmission delays, overheads, buffers and so much more....

Usually you design and develop your game engine, you test it and as soon as it's validated you compile it as a dll. This is in general a good idea because of so much advantages of a dll. Think of the faster cycle times, encapsulation, better design (we will change it to great design in this post) and so much more.

To use the game engine the game programmer would include the main header file of the game engine somewhere in his code and link to the static library when compiling the code. In Visual Basic you call this early binding. In C++ you call it binding on compile time.

I will show you here a more elegant and more efficient way to design a DLL. Instead of providing a "simple" source code for download, you can download the blueTec engine. This is a small 2d mini game engine which I've published on my project site G-Productions. This package contains some examples which will show you the implementation of this engine design. You can download the blueTec Engine directly at the end of this article. You need Dev-Cpp to compile this correctly. 

What is a game engine? In this article when we talk about a game engine we don't only mean the render stuff. A game engine does not only exist of those fun-making render calls and renderstates but also of those less-fun-making stuff like the sound and music api, like the script engine and the network module.... So if we talk about a game engine in this article we talk about all the stuff that makes the visual, the audio, the network game and much more. For simplicity we will use here pseudo code but you can download a complete working project with this article.

Imagine you have finished the development of your game engine and you want to provide it to a team of developers who will use it as base of game. Usually you would now create a DLL (dynamic link library) project, copy your header and source files into this and compile with a pre-processor directive like #define GAME_API __declspec(dllexport). What's wrong with this operation? Nothing! In fact this is ok for many projects but there are more intelligent ways.

Assuming your main game class of your game engine looks like this:

   1: class CEngine 

   2: {

   3: private:

   4:     // private stuff like the IDirect3DDevice9 or the OpenGL stuff go in here

   5: protected:

   6:     HRESULT    InitGraphics();

   7:     HRESULT    InitAudio();

   8:     HRESULT    InitInput();

   9:  

  10:     HRESULT    Destroy();

  11: public:

  12:     CEngine ( HINSTANCE );

  13:     ~CEngine ();

  14:  

  15:     HRESULT    InitEngine();

  16:     HRESULT    ShutdownEngine();

  17:  

  18:     HRESULT    MoveFrame( float );

  19:     HRESULT    BeginRender();

  20:     HRESULT    RenderFrame();

  21:     HRESULT    EndRender();

  22:  

  23:     HRESULT    PlaySound();

  24:     HRESULT    PlayMusic();

  25: };

Listing 1: the main engine class from the dll 

This class is the main exported class of your game engine and would usually look in line 1 like this:

class GAME_API CEngine

what tells the compiler that this class can be used from outside. You would now have to compile the dll (a static library is generated automatically which the developer team will use it to link to it) and provide the complete code/project to the developer team. Now imagine you would detect a bug or optimize some functions within your game engine or the developer team would detect a bug? You would have to fix the bug and the developer team would not be able to continue the work on that point where the bug occured. They would have to find a way around. Then you would have to send again the whole package and the team would have to replace the complete game engine again, all the header and source files, recompile with the new static library provided with the dll etc.

And here comes the cool thing. With our method these steps aren't necessary any more. So let's get to work guys.

1) Create a static library project

First of all create a new static library project like shown in the figure on the right. This static library is the base of our DLL design.

In Dev-Cpp the static libraries have the *.a extension. In Visual Studio or other compilers the static libraries have a *.lib extension. This is nearly the same, except of one point. You will be able to use Visual Studio generated static libraries with Dev-Cpp (in fact the MinGW compiler will use them since Dev-Cpp is only the IDE) but only if they are not so called short-symbol static libs.

Now after creating the project add two new header files like in the picture on the left and one source file. We will now take a closer look what the files contain. Let's start with the header file gameEngineDevice.h

   1: class CGameEngineDevice

   2: {

   3: protected:

   4:     HINSTANCE   m_hDll;

   5:     int         m_iWidth;

   6:     int         m_iHeight;

   7:     int         m_iBpp;

   8:     bool        m_bWindowed;

   9:     HWND        m_hWnd;

  10:  

  11: public:

  12:     CGameEngineDevice(){};

  13:     virtual ~CGameEngineDevice() = 0;

  14:     virtual HRESULT         InitEngine() = 0;

  15:     virtual HRESULT         ShutdownEngine() = 0;

  16:  

  17:     virtual HRESULT         MoveFrame( float ) = 0;

  18:     virtual HRESULT         BeginRender() = 0;

  19:     virtual HRESULT         RenderFrame() = 0;

  20:     virtual HRESULT         EndRender() = 0;

  21:  

  22:     virtual HRESULT         PlaySound() = 0;

  23:     virtual HRESULT         PlayMusic() = 0;

  24: };

  25:  

  26: typedef class CGameEngineDevice *LPENGINEDEVICE;

  27:  

  28: extern "C"

  29: {

  30:     HRESULT CreateEngineDevice( HINSTANCE hDll, CGameEngineDevice **pInterface );

  31:     typedef HRESULT (*CREATEENGINEDEVICE)(HINSTANCE hDll, CGameEngineDevice **pInterface );

  32:  

  33:     HRESULT RelaseEngineDevice( CGameEngineDevice **pInterface );

  34:     typedef HRESULT (*RELEASEENGINEDEVICE)(CGameEngineDevice **pInterface );

  35: }

Listing 2: class CGameEngineDevice from the file gameEngineDevice.h

What did we do here? Compare the class CGameEngineDevice with the original game engine class CGameEngine. What do you see? Yes you are right. All the public functions in our class CGameEngine are defined virtual. Below in line 28 we see an implementation of helper functions which we will need later.

Let's go to the file gameEngine.h. Here is the content:

   1: #include "gameEngineDevice.h"

   2:  

   3: class CGameEngine

   4: {

   5: private:

   6:     CGameEngineDevice    *m_pDevice;

   7:     HINSTANCE            m_hInst;

   8:     HMODULE              m_hDll;

   9: public:

  10:     CGameEngine( HINSTANCE hInst );

  11:     ~CGameEngine( void );

  12:     

  13:     void                Clear();

  14:  

  15:     HRESULT             CreateDevice( void );

  16:     LPENGINEDEVICE      GetDevice( void ) { return m_pDevice; }

  17:     HINSTANCE           GetModule( void ) { return m_hDll; }

  18:     void                Release( void );

  19: };

  20:  

  21: typedef class CGameEngine *LPGAME;

Listing 3: class CGameEngine from the file gameEngine.h

and here is a snapshot only of the most important function of the file gameEngine.cpp

   1: HRESULT CGameEngine::CreateDevice()

   2: {

   3:     HRESULT hr = S_OK;

   4:     char buffer[300];

   5:  

   6:     m_hDll = LoadLibraryEx("gameEngine.dll", NULL, 0);

   7:     if( !m_hDll )

   8:         return E_FAIL;

   9:  

  10:     CREATEENGINEDEVICE _CreateEngineDevice = 0;

  11:  

  12:     _CreateEngineDevice = (CREATEENGINEDEVICE)GetProcAddress( m_hDll, "CreateEngineDevice");

  13:     hr = _CreateEngineDevice( m_hDll, &m_pDevice );

  14:  

  15:     if( FAILED( hr ))

  16:     {

  17:         m_pDevice = NULL;

  18:         return E_FAIL;

  19:     }

  20:     return S_OK;

  21: }

Listing 4: code snippet from the file gameEngine.cpp

Wow, pretty much isn't it? Ok in short, the CreateDevice function is the bread and the butter of this project. LoadLibraryEx in line 6 loads the dynamic link library gameEngine.dll which will contain the game engine. In line 10 you see the the use of _CreateEngineDevice which was defined in the gameEngineDevice.h. The call of GetProcAddress retrieves the address of the exported function CreateEngineDevice from the specified dynamic-link library gameEngine.dll which was loaded before with the call LoadLibraryEx.

The static library project is finished. Save and compile to generate the static library file.

2. The DLL project

Now back to our dll project. The only thing you have to do here is to extend the main engine class CEngine. Take a look at listing 1 and replace the first line from class class CEngine to class CEngine : public CGameEngineDevice and to include the header file gameEngineDevice.h from our previously created static library project.

What did we do? The class CEngine inherits public from CGameEngineDevice. What does this mean for us? This means that all the functions which are declared virtual in the class CGameEngineDevice have to be implemented in the class CEngine.

One last thing is also to do. Remember the line 28 in listing 2. The extern "C" declaration? Where are those functions? Those have to be integrated within the dll so here we go with the code:

   1: extern "C"

   2: {

   3: HRESULT DLLIMPORT CreateEngineDevice( HINSTANCE hDll, CGameEngineDevice** pDevice )

   4: {

   5:     if( !*pDevice )

   6:     {

   7:         *pDevice = new CGameEngineDevice( hDll );

   8:         return S_OK;

   9:     }

  10:     return E_FAIL;

  11: }

  12:  

  13: HRESULT DLLIMPORT ReleaseEngineDevice( CGameEngineDevice** pDevice )

  14: {

  15:     if( !*pDevice )

  16:         return E_FAIL;

  17:  

  18:     delete *pDevice;

  19:     *pDevice = NULL;

  20:     return S_OK;

  21: }

  22: }

Listing 5: implementation of the wrapper functions for allowing the dynamic binding of the dll.

3. Using the dll in a game

How would you use the game engine in your game project?

1. include in your game project the file gameEngine.h of the static library project
2. define two new variables using the objects in our static library project (CGameEngine and CGameEngineDevice)
3. create an instance of CGameEngine and call the function CreateDevice() to create a valid game engine device
4. get a valid pointer into our CGameEngineDevice object using the call CGameEngine->GetDevice()

Here is the sample code:

   1: int WINAPI WinMain (HINSTANCE hThisInstance,

   2:                     HINSTANCE hPrevInstance,

   3:                     LPSTR lpszArgument,

   4:                     int nFunsterStil)

   5:  

   6: {

   7:     HWND hwnd;

   8:     MSG messages;

   9:     WNDCLASSEX wincl;

  10:  

  11:     // our objects from the static library project

  12:     CGameEngine           *m_pEngine;

  13:     CGameEngineDevice     *m_pEngineDevice;

  14:  

  15:     // window dependent stuff goes in here

  16:  

  17:     if (!RegisterClassEx (&wincl))

  18:         return 0;

  19:  

  20:     hwnd = CreateWindowEx ( 0, szClassName, "Windows App", /* window init stuff here */ );

  21:  

  22:     ShowWindow (hwnd, nFunsterStil);

  23:  

  24:     /* we need to save the instance and the window handle because we need them for the engine */

  25:     g_hInst = hThisInstance;

  26:     g_hwnd = hwnd;

  27:  

  28:     m_pEngine = new CGameEngine( g_hInst );

  29:  

  30:     // some simple error handling

  31:     if( !m_pEngine )

  32:         // error handling

  33:  

  34:     // now with calling the CreateDevice function the dll symbol is dynamicaly

  35:     // loaded so it's a real dynamic binding

  36:     if (FAILED( m_pEngine->CreateDevice()))

  37:         // error handling

  38:  

  39:     // the created device is passed over to our engine pointer in order to work with

  40:     m_pEngineDevice = m_pEngine->GetDevice();

  41:  

  42:     if( m_pEngineDevice == NULL )

  43:         // error handling

  44:  

  45:     if( FAILED( m_pEngineDevice->InitEngine() ))

  46:         // error handling

  47:  

  48:     /* ... message que here ... */

  49:     return 0;

  50: }

Listing 6: How to use the game engine in a game project

Just for fun

Open the dll using the tool Dependency Walker which you can find here. This tool scans Windows modules like dll's, exe files and ocx files and builds a hierarchical tree of the dependency. The tool shows also the exportable functions and entry points of the dll.

If you open our blueTec.dll with this tool you will notice only two available/exportable functions: CreateEngineDevice and ReleaseEngineDevice (look at the picture on the right). These are the functions which we have implemented within our dll and declared in our static library. Nothing more nothing less and that's all we need.

Other dll's like shown on the second picture which are compiled with the usual dll design are just exporting the complete class and provide entry points to every single method and property. Do you see the difference?

Resume

Why did we do all that above and why did the author confuse us more than necessary. Where are the benefits and advantages and why should someone go the way above?

Quiet easy. Imagine the problems mentioned at start of this article with bugs and stuff like that.

• This way is a real dynamic implementation. Looking at the code snippets we see that the real game engine class is referenced from the dll itself. The application just receives a pointer at runtime. You could develop and test your complete application without even owning the dll because it is referenced at runtime. Something which wouldn't be possible with the usual method.
• The greatest advantage is that in case of a change, an optimization and/or a bug fix you would recompile the dll and send only the compiled dll to the developer team. The team would replace only one file instead of having to replace many single header and source files and recompile the current milestone with the new created static library which ships with the dll. You safe so much time.
• Another great benefit is that you don't have to provide your very secret code because you only deliver the static library project and the compiled dll. With the traditional way you would have to provide the complete source of the dll project.
• Another very important advantage is that you could develop a game engine using completely the DirectX API and name it gameEngineDX.dll and provide it to a game development team. While the development team is full in progress to create a game using your game engine you could develop a second game engine using the OpenGL API (gameEngineOGL.dll). This game engine should also inherit from the class CGameEngineDevice. Now it would be for the development team very easy to switch between the two render API's and the best is that the team could develop the complete game using only one dll without owning the second and won't have to rewrite any code when receiving the second dll, since the definition of the main game engine class is the same and ignores which API is used. The development team doesn't even need to have the DirectX-SDK installed since the complete game engine code is already compiled and delivered within the dll.

These points are the most important I think and so this article is at the end now. I hope I could provide a "different" look at game engine design or just call it dll programming. There are more ways to design a dll but you should always have in mind that the result should not only be a fast, scalable and efficient dll at runtime but also while development since the most time you and your team will sit in front of the code and if you are able to safe some time for the game developer and make his work more efficient you should spend the time for a good design of your game engine ;)

Downloads:

blueTec_sdk.rar (515,53 kb)