Open source projects – till death

by Dimi 8. February 2010 17:45

There are so many great projects out there and there are so many skilled persons keeping them alive. Sadly not everyone has the breath to work on his project until the end and that doesn’t matter. There are often more important things in life than games and development (really ;)).

I wont bother you again with the reasons why many projects fail like I did in the past. But what I notice again and again is that people start a cool software project and talk it to death. I was involved in a very cool discussion lately on www.gamedev.net on using STL in a game engine with performance issues. While I did some research on the above topic, I noticed that many developers (like me no pro) lead endless discussions on std::list<> vs. std::vector<>. Wow There was really a topic where a guy needed 9 months to develop his texture manager because he didn’t know which container to use. The discussion was held on a high level so not the integration was the problem but the performance and the accessibility. It was an quite interesting discussion and a very technical too but are we serious? I mean this guy lost 9 months on a texture manager how much time will he loose when he integrates a sprite manager?!? I met this guy again lately on ICQ and he told me he stopped the project due to missing motivation. I had the chance to discuss with him some minutes and he pointed out that he was focused on having a texture/material manager with good performance. Yeah, I stated, but was it worth loosing so much time on a texture manager? You usually load textures on level startup and don’t need to reload the levels while game play, so you could have used a std::vector<> container with sequential access and preventing of loading same textures more than once which would have costs him some days.

It was a very interesting discussion. People (non-pros) are often so focused on shaving of some seconds on routines that they loose the real focus —> the project. So it’s understandable if you loose your motivation. Saving some ms in this routine and some in another is good and you should also profile your code to detect weak points and application critical paths but please stop with endless discussions between vector and list. 3 frames more are a small advantage compared to 9 months of development and sure not worth.

My advice: stop talking and start coding. Do you think your game engine will get better if you talk about it? No one will be interested in if you used a vector or a list in your texture manager. No one will notice it and no one will ask for it. So stop enhancing the wrong parts of your engine.

Tags: ,

game development

Source code please

by Dimi 8. February 2010 17:27

Why do you visit forums? Ok the answer might depend on what you are interested in and on what you are looking for but let’s take me for example. I’m a software developer and when I visit a forum a try to exchange information with people who share the same interests and/or are involved in similar projects and/or try to find a solution for a specific problem. Now I noticed on many forums and blog posts that there are people who cannot evaluate their own skills. You often step over posts with the following title: “I’m new to game programming and I started developing my own game engine to produce a game like Doom3”.

Bump!

Bump!

Bump!

Ok there is nothing against a challenge but hey be serious. Do you really think you would be able to develop a first person shooter with latest features without ever drawn a single triangle on the screen? I usually avoid commenting such posts but here is one which made me go mad. On a forum a guy opened a new thread like the title above. He asked people to help him get started. One posted a link to beginner tutorials on OpenGL another posted beginner tutorials on DirectX, some other guys pointed him to a C++ reference and so on.

Now after some days this guy answered to all the comments that he doesn’t need tutorials but source code. Again people tried to help him with posting some code snippets on how to create a DirectX device or how to get started with OpenGL’s glut library. Now some days later I stepped over some blogs where I was looking for some tutorials myself. The same guy (I suppose it was the same since the username was the same and this username was so unique that it would hurt if someone else would use it) posted on a tutorial, which was fairly enhanced with explanations and pseudo-code, that he would need the source code for the example.

This was the point where I went mad. Why people think they could copy and paste tutorial code and build an game engine out of it. I like sites with source code very much but to help you learn a topic sites with pseudo-code are more than enough. You will never learn the essence of octree rendering if you copy and paste the source code of a tutorial into your own application. You should read carefully through the tutorial and work it out for yourself. I suppose only 5% of the tutorial codes are usable for your engine and a benefit is visible.

Think about it.

Tags: , ,

game development | development

Scripting in game development

by Dimi 13. November 2009 13:20

No this won’t be another of those Lua posts. I did some research to decide which scripting language I will integrate into a project. Of course the number one stop for me was the Lua website. Since everyone is talking about Lua when it comes to scripting it was clear that I had to check this out. Lua was also mentioned by Jonathan S. Harbour in his book Advanced 2D game programming(the DirectX.DevPak was published in this book so check it out) so I read carefully through that chapter and tried the examples. Lua is very good, I thought first. Using just the globals through my C++ application worked very well. After that I thought how it would be extend it to let the Lua scripts calculate NPC movement. This worked also very well. Everything was just fine. It took me some time to get it working with my application but it worked well. There was just one point which was not what I expected. In Lua it’s possible to pass parameters from C++ to the Lua functions and receive the function result back in C++. It’s also possible to access C++ functions through Lua. These have to be registered first but that’s no problem. It works vice versa. But integration is sometimes very time consuming. I accidently stepped over GameMonkeyand this scripting language changed everything. Why? Watch the example below:

   1: #include "gmThread.h" // game monkey script
   2:  
   3: int main(int argc, char* argv[])
   4: {
   5:   gmMachine machine;
   6:   machine.ExecuteString("print(`Hello world`);");
   7:   return 0;
   8: }

This is the simplest script ever. You just need to include the GameMonkey header files and you are done. Simple isn’t it? Further examples showed that it’s more simple to integrate into existing applications compared to Lua, and that’s an important point for me since I don’t want to loose too much time on integration. You will argue now that in most cases you do integration only once but if you take a closer look at GameMonkey and the examples shipped with the SDK you soon will realize that nearly everything is a bit easier than in Lua.

There is a simple explanation for this. If you read carefully the introduction on the GameMonkey website you will notice that the developers of GameMonkey worked intensively with Lua and decided to make some things better so GameMonkey was born. I’m currently way too busy with my game project and my daily job so maybe in near future some GameMonkey tutorials will follow up. Stay tuned.

Here are some useful resources:

Great articles on how to get started with GameMonkey on www.gamedev.net:

http://www.gamedev.net/reference/programming/features/gmscript1/

http://www.gamedev.net/reference/programming/features/gmscript2/

A comparison between JScript and GameMonkey:

http://www.chriscowherd.com/2006/08/microsoft-jscript-vs-gamemonkey.html

Tags: , ,

game development

We are hiring…

by Dimi 14. September 2009 10:37

As you may know, I’m close to finish my new game engine. As a by-product a small 2d sprite game engine was developed and since I’m only a developer I’m looking for some skilled people who want to contribute to this. If you are an experienced texture artist or someone who knows how to use Photoshop, Paint Shop Pro or other graphic applications please contact me. At current I have three design documents for 2d games. One of them maybe the most provocative one will be published online here on this blog to let it grow with comments and suggestions from YOU.

Another design document is at work covering a fully driven 3d game, but here is still work to be done on the engine. Branded from experiences while working on the blueEngine I won’t just form a team to get this finished. The engine is a spare time project of mine just to stay fit in C++ and DirectX development. There will be soon released  a features list on this. Just one thing to say: the engine is a complete shader driven engine.

Interested? Just comment here and I’ll contact you.

Tags: , ,

game development

Newton Game Dynamics with DirectX mesh files

by Dimi 12. August 2009 23:42

If you are a game developer and need a very powerful physics engine why not choose Newton? Newton Game Dynamics is a very scalable real time physics engine capable of most of today's must-haves for games. I started playing with Newton Game Dynamics while I was developing the blueEngine in early G-Productions days. It’s no secret that I started to develop a game engine again. This time a full shader driven engine but back to the topic.

I want to point out that I did not develop the source myself. Credits go to the team who released the Newton Game Dynamics SDK. I simply changed it to work with the DirectX objects so users have some help when integrating Newton into their DirectX game engine. Most of the code found here was taken directly from the NewtonSDK samples or from the DirectX SDK samples.

In this post we will learn how to use Newton with DirectX mesh files. You will see how easy it is to integrate Newton with a DirectX based game. I assume you are already familiar with C++, DirectX and have a basic knowledge how to use a compiler. If you don’t already have go and download the latest Newton version at Newton Game Dynamics. At the time this post was written the latest version was 2.07. I will still use the version 1.53 but the code is the same and we will talk about the differences. For simplicity reasons we will build upon the mesh tutorial shipped with the DirectX SDK.

1. Initialize Newton in our app

To initialize Newton Game Dynamics you only need four functions. After having set the correct include and library paths within your application let’s start. The complete code for the physics stuff can be found in the physics.cpp and physics.h of the NewtonTutorial1 project which you can download here. Let’s take a look what those functions do.

   1:  
   2: DWORD           g_dwNumBytes;
   3: // our pointer to the Newtonworld. Here is all the action :)
   4: NewtonWorld*    nWorld;
   5:  
   6: //-----------------------------------------------------------------------------
   7: // PhysicsMemAlloc feeds the Newtonworld with all the memory needed 
   8: // PhysicsMemFree releases the memory again. These functions can 
   9: // easily be changed to meet the needs of your own memory manager so 
  10: // your game engine can easily take control of this.
  11: //-----------------------------------------------------------------------------
  12: void* PhysicsMemAlloc( int sizeInBytes )
  13: {
  14:     g_dwNumBytes += sizeInBytes;
  15:  
  16:     return malloc (sizeInBytes);
  17: }
  18:  
  19: void PhysicsMemFree( void *ptr, int sizeInBytes )
  20: {
  21:     g_dwNumBytes -= sizeInBytes;
  22:  
  23:     free (ptr);
  24: }
  25: //-----------------------------------------------------------------------------
  26: // InitPhysics is our main entry point. If we want physics we have 
  27: // to call the the function NewtonCreate. As parameters the memory 
  28: // allocation/deallocation methods are accepted. We also need to tell 
  29: // Newton how "big" our world is so the function accepts as parameters 
  30: // the bounding box of our world 
  31: //-----------------------------------------------------------------------------
  32: HRESULT InitPhysics(D3DXVECTOR3 vMin, D3DXVECTOR3 vMax)
  33: {
  34:     HRESULT hr= S_OK;
  35:  
  36:  
  37:     nWorld = NewtonCreate (PhysicsMemAlloc, PhysicsMemFree);
  38:  
  39:     NewtonSetWorldSize( nWorld, (float*)&vMin, (float*)&vMax );
  40:  
  41:     return hr;
  42: }
  43: //-----------------------------------------------------------------------------
  44: // Just release everything and destroy our physics world :(
  45: //-----------------------------------------------------------------------------
  46: void CleanUpPhysics()
  47: {
  48:     NewtonDestroyAllBodies( nWorld );
  49:     
  50:     NewtonDestroy (nWorld);
  51: }

As you can see the whole magic is within InitPhysics and CleanUpPhysics. The piece of code should be self-explanatory so I won’t go into detail. If you have questions please refer to the samples shipped with the NewtonSDK. Most of the code is explained there in detail.

2. Create a simple mesh

Now that we know how to set up our physics world let’s start with adding some action to our scene. Take a look at the class CD3DXMesh. This is a simple mesh class which creates box, sphere or cylinder meshes with the D3DX library. We will use this for starting. Let’s take a look into the method CD3DXMesh->Init

   1: if( m_type == BOX )
   2: {
   3:     hr = D3DXCreateBox(g_pd3dDevice, m_vecSize.x, 
   4:                                     m_vecSize.y, 
   5:                                     m_vecSize.z, 
   6:                                     &pMeshSys, NULL);
   7: }
   8: else if( m_type == SPHERE )
   9: {
  10:     hr = D3DXCreateSphere( g_pd3dDevice, 
  11:                             m_vecSize.x,
  12:                             50, 50,
  13:                             &pMeshSys, NULL);
  14: }
  15: else if( m_type == CYLINDER )
  16: {
  17:     hr = D3DXCreateCylinder( g_pd3dDevice, 
  18:                             m_vecSize.x, 
  19:                             m_vecSize.z, 
  20:                             m_vecSize.y, 
  21:                             50, 50, 
  22:                             &pMeshSys, NULL);
  23: }
  24: else
  25:     return E_FAIL;

As you can see depending on the parameter we are creating our desired mesh and saving it. The method Init does some cloning of the mesh to get it into the right format for texturing. Now where is all the physics? Here is the method in our file physics.cpp.

   1: HRESULT CreatePhysicsBody( CD3DXMesh* pMesh )
   2: {
   3:     NewtonCollision*     collision;
   4:     NewtonBody*            body;
   5:     D3DXVECTOR3            vSize;
   6:  
   7:     vSize = pMesh->GetSize();
   8:  
   9:     switch( pMesh->GetMeshType())
  10:     {
  11:     case BOX:
  12:         collision = NewtonCreateBox( nWorld, 
  13:                                     vSize.x, 
  14:                                     vSize.y, 
  15:                                     vSize.z, 
  16:                                     NULL );
  17:         body = CreateRigidBody( pMesh, collision );
  18:         break;
  19:     case SPHERE:
  20:         collision = NewtonCreateSphere( nWorld, 
  21:                                         vSize.x, 
  22:                                         vSize.x, 
  23:                                         vSize.x, 
  24:                                         NULL );
  25:         body = CreateRigidBody( pMesh, collision);
  26:         break;
  27:     default:
  28:         break;
  29:     };
  30:  
  31:     NewtonReleaseCollision( nWorld, collision );
  32:  
  33:     return S_OK;
  34: }

After successfully creating a mesh and applying the physics properties we call this method so Newton Game Dynamics is able to do something useful with the data provided. Watch the lines 9-29. They are nearly identical with our DirectX function above for creating the graphical object. You see how easy it is? NewtonCreateSphere and NewtonCreateBox are methods of the Newton Game Dynamics library which create the collision shape of the desired body. Of course same sizes should be used like the graphical object so that it looks realistic.

The method CreateRigidBody is the important call in this code. Let’s take a look what it does:

   1: NewtonBody*    CreateRigidBody( CD3DXMesh* pObject, NewtonCollision* collision )
   2: {
   3:     D3DXVECTOR3 minBox;
   4:     D3DXVECTOR3 maxBox;
   5:     D3DXVECTOR3 origin;
   6:     D3DXVECTOR3 inertia;
   7:     NewtonBody* body;
   8:     float mass;
   9:  
  10:     mass = pObject->GetMass();
  11:  
  12:     body = NewtonCreateBody (nWorld, collision);
  13:  
  14:     NewtonBodySetDestructorCallback (body, PhysicsBodyDestructor);
  15:  
  16:     NewtonBodySetUserData (body, pObject);
  17:  
  18:     D3DXMATRIX matrix = pObject->GetMatrix();
  19:     NewtonBodySetMatrix (body, (float*)&matrix);
  20:  
  21:     NewtonConvexCollisionCalculateInertialMatrix (collision, 
  22:                                 (float*)&inertia, (float*)&origin);    
  23:  
  24:     NewtonBodySetMassMatrix (body, mass, mass * inertia.x, 
  25:                                             mass * inertia.y, 
  26:                                             mass * inertia.z);
  27:  
  28:     NewtonBodySetCentreOfMass (body, (float*)&origin);
  29:  
  30:     NewtonBodySetForceAndTorqueCallback (body, PhysicsApplyForceAndTorque);
  31:  
  32:     NewtonBodySetTransformCallback (body, PhysicsSetTransform);
  33:  
  34:     return body;
  35: }

Very simple. It creates the rigid body in physics world and sets the various parameters like mass, matrices and callbacks. As you see there are three callbacks set. These callbacks control the behavior of the physic bodies. Let’s take a closer look.

PhysicsBodyDestructor:

   1: void PhysicsBodyDestructor ( const NewtonBody* body )
   2: {
   3:     CD3DXMesh* primitive;
   4:  
   5:     primitive = (CD3DXMesh*) NewtonBodyGetUserData (body);
   6:     SAFE_DELETE( primitive );
   7: }

This method is called to destroy our object.

PhysicsSetTransform:

   1: void PhysicsSetTransform( const NewtonBody* body, const float* matrix )
   2: {
   3:     CD3DXMesh* primitive;
   4:     D3DXMATRIX mat;
   5:     memcpy(mat.m, matrix, sizeof(float)*16);
   6:  
   7:     // get the graphic object form the rigid body
   8:     primitive = (CD3DXMesh*) NewtonBodyGetUserData (body);
   9:  
  10:     // set the transformation matrix for this rigid body
  11:     primitive->SetMatrix ( mat );
  12: }

This method is called every time to set the new matrix to our models. Every time the matrix of the body changes (transformation, translation etc.) this function is called to update the matrix so that the graphical part knows what happened and is able to render the transformed graphical object.

PhysicsApplyForceAndTorque

   1: void PhysicsApplyForceAndTorque (const NewtonBody* body)
   2: {
   3:     float mass;
   4:     float Ixx;
   5:     float Iyy;
   6:     float Izz;
   7:  
   8:     NewtonBodyGetMassMatrix (body, &mass, &Ixx, &Iyy, &Izz);
   9:     D3DXVECTOR3 force (0.0f, mass * NEWTON_GRAVITY, 0.0f);
  10:     NewtonBodySetForce (body, (float*)&force);
  11: }

This method simply applies gravity force to the rigid body.

Note: All the methods of the Newton Game Dynamics library accept float pointers for accessing data. If you use your own vector or matrix class make sure you include a float* casting to your vector/matrix class. If you store your members in an array of floats for example float m[3] you could simply pass &vec.m[0] to Newton. If you use the DirectX D3DXVECTOR3 and/or D3DXMATRIX classes make sure you cast the parameter with a float pointer like

   1: D3DXVECTOR3 vecForce;
   2: NewtonBodySetForce( body, (float*)&vecForce);

For detailed reference refer to the DirectX SDK documentation.

That’s all. We simply have to do a call to update the physics world with the current passed time and voila we have some action. What did we do here? We just created with DirectX internal functions some basic meshes to render and create rigid bodies out of them to simulate physics. The result should look like this:

 

3. Using DirectX mesh for level geometry

What did we learn so far? We learned how easily it is to integrate Newton to any type of DirectX based game engine and we learned how easy it is to create rigid bodies with simple primitives using the DirectX D3DX library. Now we want to go a step further. The DirectX mesh file (x mesh) is maybe not the preferred mesh format a developer would choose but it’s easy to handle since D3DX ships with nearly any helper method you could imagine of, what makes work easier. For this example we will choose the x mesh as level geometry and add some more complex meshes to the scene to see if Newton Game Dynamics can handle this.

For this tutorial a new mesh class is used to load meshes from files. For now we will take a look what happens while initializing the mesh object:

   1: m_iNumTriangles = m_pMesh->GetNumFaces();
   2: m_iNumVertices = m_pMesh->GetNumVertices();
   3:  
   4: m_pVerts = new D3DXVECTOR3[m_iNumVertices * sizeof(D3DXVECTOR3)];
   5: m_pIndices = new WORD[m_iNumTriangles * sizeof(WORD) * 3];
   6:  
   7: MeshVertex2* pVertexBuffer = NULL;
   8: hr = m_pMesh->LockVertexBuffer( 0, (void**) &pVertexBuffer );
   9: if( FAILED(hr) )
  10:     return E_FAIL;
  11:  
  12: for( int iCol = 0; iCol < m_iNumVertices; iCol+=4)
  13: {
  14:     m_pVerts[iCol] = pVertexBuffer->vPos;
  15:        pVertexBuffer++;
  16:        m_pVerts[iCol+1] = pVertexBuffer->vPos;
  17:        pVertexBuffer++;
  18:        m_pVerts[iCol+2] = pVertexBuffer->vPos;
  19:        pVertexBuffer++;
  20:        m_pVerts[iCol+3] = pVertexBuffer->vPos;
  21:        pVertexBuffer++;
  22: }
  23: hr = m_pMesh->UnlockVertexBuffer();
  24: if( FAILED(hr) )
  25:     return E_FAIL;
  26:  
  27: WORD* pIndexBuffer=NULL;
  28: hr = m_pMesh->LockIndexBuffer( D3DLOCK_READONLY , (void**)&pIndexBuffer ); 
  29: if( FAILED( hr ))
  30:     return E_FAIL;
  31:  
  32: for( int i = 0; i < m_iNumTriangles*3; i++)
  33: {
  34:     m_pIndices[i] = pIndexBuffer[i];
  35: }
  36: hr = m_pMesh->UnlockIndexBuffer();
  37: if( FAILED( hr ))
  38:     return E_FAIL;

This should be nothing new for you. After loading your mesh and doing things with it you want to do like optimization and stuff simply load the vertices and indices separate into buffers. We are doing this only once in our example after loading the mesh from file and preparing it for the application. Therefore it is no problem to lock the vertex- and index buffer of the mesh since it’s only done once. Why did we do the things above? you should ask now. Well simply because we will pass this data to Newton Game Dynamics. You will see that this work will pay off later.

Now we are loading a big mesh file (the castle model of the example was taken from the samples of DelEd editor) and want it to behave as our static geometry. Why this? First of all it’s good to go this way since we can now simulate exact collisions with all other objects of the game. Second is we can write a player controller and control it via physics (an example of a character controller ships with Newton Game Dynamics) what means that we don’t have to calculate collisions between player and level geometry separately but let Newton Game Dynamics do this for us. And the third reason is simply because we want to be cool and implement it that way to point out how important the two reasons above are ;)

Now that we loaded the our big mesh we have to tell Newton Game Dynamics to use our vertices and indices to build our world. This is done in the method CreateLevelCollision

   1: HRESULT    CreateLevelCollision( D3DXVECTOR3* vVertexArray, int vertcount, 
   2:                         WORD* vIndexArray, int indexcount, D3DXMATRIX matLevel )
   3: {
   4:     HRESULT hr=S_OK;
   5:     NewtonCollision*    collision;
   6:     D3DXVECTOR3            vArray[3];
   7:     NewtonBody*         m_levelBody;
   8:     int                 m_nLevelID;
   9:  
  10:     collision = NewtonCreateTreeCollision( nWorld, 0);
  11:  
  12:     NewtonTreeCollisionBeginBuild( collision );
  13:  
  14:     for( int i = 0; i < indexcount; i+=3)
  15:     {
  16:         WORD d1 = vIndexArray[i];
  17:         WORD d2 = vIndexArray[i+1];
  18:         WORD d3 = vIndexArray[i+2];
  19:         
  20:         vArray[0] = vVertexArray[d1];
  21:         vArray[1] = vVertexArray[d2];
  22:         vArray[2] = vVertexArray[d3];
  23:         
  24:         D3DXVECTOR3 e0 = vArray[1] - vArray[0];
  25:         D3DXVECTOR3 e1 = vArray[2] - vArray[0];    
  26:         
  27:         NewtonTreeCollisionAddFace( collision, 
  28:                                         3, 
  29:                                         (float*)vArray[0], 
  30:                                         sizeof(D3DXVECTOR3), 
  31:                                         i+1);
  32:     }
  33:  
  34:     NewtonTreeCollisionEndBuild( collision, 1);
  35:     m_levelBody = NewtonCreateBody( nWorld, collision);
  36:     
  37:     NewtonReleaseCollision ( nWorld, collision);
  38:     NewtonBodySetMatrix( m_levelBody, matLevel);
  39:  
  40:     D3DXVECTOR3 boxP0;
  41:     D3DXVECTOR3 boxP1;
  42:     NewtonCollisionCalculateAABB (collision, matLevel, &boxP0.x, &boxP1.x);
  43:  
  44:     boxP0.x -= 10.0f;
  45:     boxP0.y -= 10.0f;
  46:     boxP0.z -= 10.0f;
  47:     boxP1.x += 10.0f;
  48:     boxP1.y += 100.0f;
  49:     boxP1.z += 10.0f;
  50:  
  51:     // if this mesh is used for level geometry we could increase the 
  52:     // NewtonWorld size by the bounding box of the level geometry. Above some 
  53:     // padding was added. I think a good idea is to add more padding to y since 
  54:     // we might be "outdoor" and might want to let some boxes fall down ;)
  55:     NewtonSetWorldSize ( nWorld, (float*)&boxP0, (float*)&boxP1);
  56:     
  57:     return hr;
  58: }

Wow damn nice function. This is the bread and butter of our game. In line 10 you see that we build an empty collision object. After that we tell Newton that we want to add the polygons to the collision tree. So now we loop through our vertices and the the faces via NewtonTreeCollisionAddFace. On finish we call NewtonTreeCollisionEndBuild, note the second parameter. We passed 1 here telling Newton to optimize our collision tree. After passing our complete mesh geometry to Newton we create the body set the matrix and calculate the bounding box. We did that in order to re-set the world size. Note that we added some padding to the world to make sure even objects at borders behave as they should. That’s all, no callbacks are needed this time since this is our (static) world and we don’t want it to move around ;)

We should test this stuff we did until now but let’s go a step further. Do you have only boxes, spheres and cylinders in your game? No you don’t. I bet 80% of the meshes are of complex geometry. What if you want to have collisions with the real shape they are rendered? Newton Game Dynamics helps us out. Take a look here:

   1: HRESULT CreateComplexPhysicsBody( CMesh *pMesh )
   2: {
   3:     HRESULT hr = S_OK;
   4:     NewtonCollision*     collision;
   5:     NewtonBody*            body;
   6:     float                 Ixx, Iyy, Izz;
   7:     D3DXMATRIX            mat;
   8:  
   9:     mat = pMesh->GetMatrix();
  10:  
  11:     collision = NewtonCreateConvexHull (nWorld, 
  12:                                 pMesh->GetNumVertices(), 
  13:                                 (float*)pMesh->GetVerts(), 
  14:                                 pMesh->GetVertexSize(), 
  15:                                 NULL);
  16:     body = CreateRigidBody( pMesh, collision );
  17:  
  18:     NewtonReleaseCollision( nWorld, collision );
  19:  
  20:     return hr;
  21: }

Sick. Just pass your mesh object to this method. What happens then? Remember the vertex and index buffers which we calculated when initializing the mesh and which we used after that to build level geometry? Just use them here once again to pass the detailed geometry of your graphical object so Newton can build the collision geometry out of it. The method NewtonCreateConvexHull does all the work for us. After having build the collision geometry we continue to create the body like in the examples above where all the callbacks and properties are set. Nothing new here.

So what will the result be? Let’s watch the video:

As you can see it’s quite easy to implement Newton Game Dynamics into your game engine project. The good thing is that Newton accepts the matrix and vertex parameters in major row order what makes it possible for OpenGL and DirectX game engine to use Newton Game Dynamics. There is also a documentation available which ships with the download and there are a couple of great samples and tutorials which are included with the SDK. The forums at www.newtondynamics.com is visited very frequently and should be the place to start. The website has also a new wiki which makes the package complete. I can recommend Newton Game Dynamics. The integration of Newton in any engine is more than easy and developers reach fast and very good results and most important of all: you don’t loose too much time. We could start a discussion whether to use Newton methods for computing a bounding box or use the DirectX integrated functions but that's more than philosophic since the result (in my tests) was the same.

But that’s not all. The Newton Game Dynamics SDK ships with some great methods for ragdoll and more. Check out there website for a full feature list. Thanks for reading this.

Please note: As stated above the source on how to use Newton was taken mainly from the samples which ship with the NewtonSDK. Also the mesh classes contain portions of the DirectX SDK. I just put these together to work. The code is of course not best practice but good enough for the examples above.

Downloads

NewtonTutorial1.zip (4,71 mb)

NewtonTutorial2.zip (5,47 mb)

Tags: , ,

game development

It’s all about game design

by Dimi 25. May 2009 22:30

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.

Tags: ,

game development

Shit happens – the game

by Dimi 25. May 2009 21:56

Some things never change, and as a passionate developer my big love are still games. No not playing them, but developing them. I was cleaning up my harddrive today (I should do this more often) and found a very old project I wanted to start some years ago with my class mates. We did some basic project management and ended up with a design document for a game which we found very cool. So some of the graphic artists put together this very basic screens for a teaser which I’m releasing here. OK the younger guys reading this blog will now be laughing because they are used to Quake 15, Doom 21 and Duke Nukem Never graphics and this is a simple but cool 2d game but that’s ok. Try to develop your own game and you will see what I’m talking about.

Now I found a very basic framework for this game and while browsing the project folder the feeling of then came up in me and I decided that it’s time to get this finished. I will put things together the next days and try to see what I have, what I need and what I’ll get and will try to finish this. Are you excited in a 2d game of an old-school game developer who will use Dev-Cpp and DirectX as API for the complete game? Then watch the video below and tell me what you think.

You are a passionated game developer, graphic artist, sound specialist or simply love contributing anything to a game then contact me. It will be a pleasure to get this done…

[mediaplayer:urban.flv]

Tags: ,

games | game development

Dev-Cpp vs Visual Studio 2008

by Dimi 25. May 2009 21:26

Hopefully this article won't get too polemic. I made some decisions about the future of some of my projects and most important of the art of software developing I want to continue.

I've worked for since the start of 1999 with the Dev-Cpp IDE which uses the MinGW compiler. The reason for this is that I didn't want to spend so much money on Visual Studio to get a C++ compiler. This was OK for me that time. Soon I noticed that it's not so easy to get everything compiled with the MinGW compiler. This compiler accepts only strict ANSII C++ so it was quite difficult to use some libraries available on the www. To get things done with MinGW compiler you had to download either a MinGW version of libraries or create them yourself. This was also OK for since most libs I was using were available for MinGW too. Problems began when I decided to develop on DirectX. I installed the DirectX SDK and got even on the simplest example application a bunch full of errors. So I put my ass down to get it work with MinGW. It was an nearly endless task and I won't go deeper into it. You can read the whole article here. When I got it finished I wanted to use some sound in my application. I decided to use the ogg vorbis format since I think it's still the greatest alternative to mp3. Again nor libs for MinGW and again some nights working on a DevPak. Community contacted me on my game site G-Productions wanting me to get the audiere audio library working with MinGW, others wanted the NVidia CG Toolkit to use with MinGW. At one point it was fun creating all this DevPaks. You can learn so much about compiler differences when working on this.

Again it was great fun the whole time, and it was OK for me having to spend some extra time on creating DevPaks first, to use them. Another great thing on the MinGW compiler was that code execution times are great compared to the code Visual C++ 6.0 created. You can read more about execution times in my previous article here. Now things changed since the .NET framework and I made some tests with the Microsoft Visual C++ Express Edition. The only thing I can say is WOW. If we compare the code execution times Microsoft made a big step forward. I had the chance to also test the Microsoft Visual C++ 9.0 pro edition and I'm thrilled. As a game programmer one of the most important things is (or should be) the code execution times. MS VC++ 9.0 rocks.

At some point I'm also glad not having to create a DevPak any more to develop something. Things get more difficult with the latest DirectX releases and I'm not sure if a conversion to a DevPak would be possible with the final release of DirectX 10. MS changed so many things in there.

What about the XNA framework? Maybe managed code is the future... Maybe the use of the XNA framework makes game development a very easy task but I will still use C++. Writing your own loaders, your own functions using the DX classes allows you more flexibility and I'm one of those old-school programmers who likes to know what his code does ;). No doubt, using the XNA framework saves you a lot of time and headache but you should decide for yourself what’s the best for your game. 

So what did you learn reading all this ideas and thoughts? I can highly recommend using the new Visual Studio. The performance on execution time is incredible. If you still use Dev-Cpp you most probably won't be able to use DirectX 10 but don't nail me on that, it's only speculation. If you come to the point where you want to use DirectX 10 you most probably won't have an alternative to MS VC++. Hey don't come with the "Dev-Cpp is free" paroles. You can get MS VC++ 9.0 for free (the Express Edition) ;)

Tags: , ,

game development

DirectX.DevPak distributed with book

by Dimi 25. May 2009 15:48

Last year I received an email from Jonathan Harbour, asking me if he is allowed to distribute the DirectX.DevPak with his new book Advanced 2D game development. Of course I agreed but soon forgot about it.

Recently a friend of mine contacted me telling me that he had found the DirectX.DevPak on a CD included in a book. I must admit I do not own this book but hey... most important is that I'm famous now ;) Just joking. Head over to Amazon and watch the reviews. It seems that this is quite a good book with quite interesting topics like 2D and 3D rendering, animation, input and audio control, physics, threading and scripting using the LUA script engine. I'm looking forward to get this book (sadly no signed book reached me :( ) but the content promises a lot and the current user ratings tend to be very positive.

Here’s what professionals in the game industry have to say about this author’s work:

Barry Caudill, Executive Producer of Civlization Revolutions at Firaxis Games: “I like your style of writing and I appreciate how you dig down and explain things.” “A book like this is invaluable.” “Very well written and applicable to what we do at Firaxis.” “Very impressed.” “I enjoyed myself immensely while working through the book.” “Keep up the great work.”*

John Romero, Lead Designer of Gauntlet Dark Legacy at Midway, co-founder of id Software, Designer of Doom and Quake: “I just got your book and it’s exactly what I needed!” “For the last several years, I’ve been so busy with game design and directing large teams that I never had the time to actually code.” “I really needed the concise info contained in your book.” “I just wanted to say thanks for writing an essential book for game coding.”**

* Referring to Beginning Game Programming. ** Referring to Pocket PC Game Programming

Tags: , ,

DevPak | game development

Team blue - the experiment

by Dimi 1. July 2008 21:33

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

team_hierarchy 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

gameteam 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

Tags: , ,

game development

Powered by BlogEngine.NET 1.6.0.0
Theme adopted by Dimi with portions of Mads Kristensen and portions of Rtur.net

RecentPosts