I’m surprised this actually took THIS long to materialize, given the amount of money flowing through the Apple iPhone app store. A company called Reverb Communications uses a farm of interns who trawl the internet posting reviews and comments on applications by their clients.

It’s a brilliant strategy honestly, driven because of the “hit chart” mentality that the App Store has devolved into and fosters. The only way your app is going to be noticed among the other hundreds / thousands out there is to get it bubbled up through the ratings system.

I don’t condone outright lying about products to generate SEO traffic, but if it’s a good app that you’re trying to market and sell, then really it’s not very different from asking all your friends / coworkers to generate “noise” on the internet for you.

Update: Made a post about this over on Gamasutra as well

Update: Here’s another great blog entry over on pocketgamer.biz on the same topic!

In the beginning, Flash game development was incredibly profitable for games. The ad revenue system / profit model was the approach of choice for Flash game developers, mostly because of the internet success stories of games like Desktop Tower Defense.

Similar to the early “gold rush” days of the iPhone appstore, when the finger of the internet pointed at a particular site, the developer would land enough revenue to afford them the ability to leave their “day job” in order to focus on games.

It’s only been a short while later, and this revenue stream has all but evaporated for developers. There’s no need to go into the details, when they’re succinctly written about over at Lost Garden:

Flash Love Letter (Part I)
Flash Love Letter (Part II)

with that background, you might be throwing your hands up or sighing in despair. To coin a cliche, while one door has closed, another one has opened. It’s time that Flash game developers took some pride in their work and instead of being driven by the hit mechanics governing the current market, and get back to focusing on creating FUN games.

The ability to add support for microtransactions within your game, provides a pathway of opportunity to game developers who want to try to create some meaningful experiences and/or content.

According to the posted date on this YouTube clip, this was released Sept. 2008, so yeah I’m a “little late” to the party.

Who cares, the interview is still relevant today and kick’s ass. 37signals was the main company behind the famous web framework RubyonRails and the interview was an extremely interesting introspection on how the company runs itself productively. Their crew adapted to different work styles, and eventually created a work atmosphere that enabled their staff to work largely from remote locations but still productively create some excellent web-based software.

What are YOU doing at your office to take advantage of some of these workforce ideas?

The excellent team running GamerWok have graciously given me some occasional editorial space, and I put it to use with a commentary on the North American gamer being bombarded with microtransactional games.

Please give it a read and share your thoughts!

I was aiming to showcase a bit of comparison between the Asian model and the currently-evolving North American one.

Now that we’ve passed the black triangle test with some flying..blackness, let’s continue to work on printing text to the screen. There’s a few ways to go about this in Direct3D8.1, but we’re going to use a font object which is already included in the Common Framework for us: CD3DFont.

Add the object to our main class

The necessary header files are bundled with the Common Framework, but in case you get any compile errors you can find the definition in CD3DFont.h / CD3DFont.cpp.

class CMyD3DApplication : public CD3DApplication
{
    //snip!
	CD3DFont*	m_pd3dFont;
	//snip!
}

CMyD3DApplication()

During the constructor for the CMyD3DApplication class, we can create the font object. All we really need to get going is the font family we’re going to use (eg. Verdana, Helvetica, Georgia, etc) and the font size.

CMyD3DApplication::CMyD3DApplication()
{
   //snip!
	m_pd3dFont = new CD3DFont("Georgia", 14, D3DFONT_BOLD );
   //snip!

}

InitDeviceObjects

We just need the font object call its own creation function during our InitDeviceObjects function.

HRESULT CMyD3DApplication::InitDeviceObjects()
{
	//snip!
    m_pd3dFont->InitDeviceObjects( m_pd3dDevice );
    //snip!
    return S_OK;
}

RestoreDeviceObjects

We have to call a method here from the font object whenever the RestoreDeviceObjects function is called by the common framework.

HRESULT CMyD3DApplication::RestoreDeviceObjects()
{
    //snip!
	m_pd3dFont->RestoreDeviceObjects();
	//snip!
	return S_OK;
}

InvalidateDeviceObjects

HRESULT CMyD3DApplication::InvalidateDeviceObjects()
{
    //snip!
	m_pd3dFont->InvalidateDeviceObjects();
	//snip!

    return S_OK;
}

DeleteDeviceObjects

HRESULT CMyD3DApplication::DeleteDeviceObjects()
{
    //snip!
	m_pd3dFont->DeleteDeviceObjects();
    //snip!

    return S_OK;
}

FinalCleanup

HRESULT CMyD3DApplication::FinalCleanup()
{
    //snip!
	SAFE_DELETE( m_pd3dFont );
	//snip!

    return S_OK;
}

Render

After the necessary “paperwork” for the font object, we can now get to the nitty-gritty of using it in our codebase! It’s extremely simple to leverage for displaying text on your device.

CD3DFont::DrawText( FLOAT x,           //x position of the text
                    FLOAT y,           //y position of the text
                    DWORD dwColor,     //the color to draw the text
                    TCHAR* strText,    //the text itself
                    DWORD dwFlags=0L); //optional draw flags

Here’s how we use it:

HRESULT CMyD3DApplication::Render()
{
    // Clear the viewport
    m_pd3dDevice->Clear( 0L, NULL, D3DCLEAR_ZBUFFER | D3DCLEAR_TARGET, D3DCOLOR_ARGB( 0, 45, 50, 170 ), 1.0f, 0L );

    // Begin the scene
    if( SUCCEEDED( m_pd3dDevice->BeginScene() ) )
    {
        //snip!
		m_pd3dFont->DrawText( 2,  0, D3DCOLOR_ARGB(255,255,255,0), "Basic Font!" );
		//snip!

        // End the scene.
        m_pd3dDevice->EndScene();
    }

    return S_OK;
}

basic font in directx8.1

That’s it! If you have any questions or feedback, please leave them here or use our contact form.

Source Code:

basic-font-d3d81 (82)

We’re going through some of the basics of DirectX8.1 and game programming in general, and I know
you’re itching to get something resembling a real game going. We’re not quite there yet, but
we will be taking a major step by introducing “Sprites”.

While the definition is a bit blurry in some areas, a “Sprite” is something you can see on your screen which
has some kind of form or shape for your game: a single line is not a sprite, but a rectangle IS. A menu GUI
button is a sprite, your Mario or Zelda avatar is a sprite, etc.

here's a familiar sprite!

Note: Some game programmers tend to interchange the use of “sprite” and “model” when discussing
visual game objects…in most cases “sprite” is any 2D object in your game, while a “model” is a 3D entity

The DirectX8.1 SDK provides us with an easy-to-use sprite interface; ID3DXSprite. It is a quick and easy approach to getting sprite support in your games. This post will deal with creating and rendering a sprite to your display.

The ID3DXSprite interface relies on the creation of a texture object which contains the “visual candy” associated with the sprite. A Texture is any 2D drawing / artwork which is stored as a .gif, .jpg, .png, .tga or .bmp. Once you load a texture into the direct3d device, you can apply it in several ways. You can apply this 2D image onto a 3D object in your game or you can apply it to a 2D sprite.

Adding the necessary to the class definition…

class CMyD3DApplication : public CD3DApplication
{
	//snip!
	LPD3DXSPRITE m_pd3dSprite;      //our sprite object
	LPDIRECT3DTEXTURE8 m_pd3dTex;   //our texture object
        //snip!
};

InitDeviceObjects

Within InitDeviceObjects, we just need to create our sprite and texture objects with the help of the Direct3D device. Since we’re creating them here, they’ll be managed by the device and should survive any device resets and/or alt+tabbing. For this sample, we’re creating the ID3DXSprite object with the help of the Direct3D device. Once that’s done, we use the Direct3D device again to create and load our 2D texture image (contained in wazooinc.jpg).

HRESULT CMyD3DApplication::InitDeviceObjects()
{
   //snip!
  D3DXCreateSprite( m_pd3dDevice, &m_pd3dSprite );
  // Use D3DX to create a texture from a file based image
  if( FAILED( D3DXCreateTextureFromFile( m_pd3dDevice, "wazooinc.jpg", &m_pd3dTex ) ) )
    return E_FAIL;
   //snip!
   return S_OK;
}

DeleteDeviceObjects

As with our other Direct3D device objects, we need to make sure we properly cleanup our texture and sprite interfaces.

HRESULT CMyD3DApplication::DeleteDeviceObjects()
{
	//snip!
	SAFE_RELEASE( m_pd3dTex );
	SAFE_RELEASE( m_pd3dSprite );
        //snip!
        return S_OK;
}

Drawing the sprite

Finally we get to the meat and potatoes of using sprites…drawing them! Because of the way they’re designed, there is a set process to rendering with ID3DXSprite.

• call ID3DXSprite::Begin()
• render the sprite using ID3DXSprite::Draw()
• finish by calling ID3DXSprite::End()

We have some begin/end blocks, in order to help batch together multiple sprite objects (should we need to). The Draw() method is by far the most interesting. Take a look at the code for a sample.

HRESULT CMyD3DApplication::Render()
{
    // Clear the viewport
    m_pd3dDevice->Clear( 0L, NULL, D3DCLEAR_ZBUFFER | D3DCLEAR_TARGET, D3DCOLOR_ARGB( 0, 45, 50, 170 ), 1.0f, 0L );

    // Begin the scene
    if( SUCCEEDED( m_pd3dDevice->BeginScene() ) )
    {
                //snip!

		m_pd3dSprite->Begin();                      // enter sprite drawing

		 // draw the sprite
		D3DXVECTOR2 position(25.0f, 50.0f);      // position at (25, 50)
		m_pd3dSprite->Draw(m_pd3dTex,          // our texture image
			NULL,                                        //
			NULL,
			NULL,
			0.0f,                                       // the rotation of our sprite
			&position,                                  // the position of our sprite on screen
			D3DCOLOR_XRGB(255, 255, 255)); //the color of our sprite

		m_pd3dSprite->End();                         // end our sprite drawing

                //snip!

        // End the scene.
        m_pd3dDevice->EndScene();
    }

    return S_OK;
}

basic sprite final output

That’s it for drawing sprites! It’s definitely starting to get exciting!

Source Code:

basic-sprite-d3d81 (76)

Leave any feedback or comments here, or feel free to use the contact form.

The Common Framework that ships with the DirectX9 SDK is a great starting point for learning about DirectX programming. It’s lightweight and gives you a good container for either prototyping or a possible infrastructure for shipping code.

Note: Only the DirectX9.0 / 9.0a and 9.0b versions of the SDK were released with the Common Framework. Starting with DirectX9.0c, the framework was rebranded / rewritten into the DXUT.

Only when you better understand what’s going on (and more importantly) where you need to plug your game code into will you see some progress in your projects. After analyzing the common framework setup, the lifecycle is actually broken down into 2 subcycles:

• application lifecycle
• direct3d lifecycle

Create

This is the very first method used to kick the entire framework lifecycle off. This should more or less be the only function you need to call in your WinMain entry point.

CMyD3DApplication g_d3dApp;
INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR, INT )
{

    if( FAILED( g_d3dApp.Create( hInst ) ) )
        return 0;

    return g_d3dApp.Run();
}

OneTimeSceneInit

After the framework begins its lower level registration and creation work with the Windows operating system itself, it provides you an opportunity to plug some object creation code in here. This function is only called once by the framework, so -
Do

• create your large data structures here
• load any game object that stays in memory during the entire game

Don’t

• touch any Direct3D specific component

ConfirmDevice (optional)

This is an optional hook for you to implement during the initialization phase of your direct3d device. It can be used to make sure the direct3d device chosen by the common framework supports the features of the Direct3D API that you want to use during your game.

InitDeviceObjects

After the OneTimeSceneInit function finishes up, the common framework goes back into its cave and handles the process of creating and initializing your Direct3D device. Once this is done, you’re now given the opportunity to create and initialize any Direct3D specific interface right here. So creating your vertex and index buffers, texture objects, and even any font objects among other things. This is only called once during the lifecycle.

RestoreDeviceObjects

After your Direct3D specific objects have initialized themselves, the framework calls RestoreDeviceObjects to “reset” them. This is where our “lifecycle” design starts to take effect, because this function is called at serveral other times:

• during InitDeviceObjects
• you alt+tab away from your game
• you resize the window
• you minimize / maximize the window

So here you might seriously consider resetting any Camera and/or projection and view matrices, as well as resetting any Direct3D device object that might be affected.

FrameMove

With our game application code and directx components ready to rumble, it’s time to kick your project into full gear. You don’t need to understand (or interface) with the main Windows message loop, but at this stage, your application is now in a constant loop. This method is called for the purpose of doing any non-direct3D updating tasks. Most commonly, this is the function in which you process any input from the player, as well as updating game objects, do any AI calculations, collision detection and any sound / music effects.

Render

Immidiately after FrameMove, the Render method is executed in which you’re given the opportunity to push all the graphics for the frame through the Direct3d device. In fact, you should only be talking to Direct3D in this function.

InvalidateDeviceObjects

This method is called when your direct3d device is about to lose focus. For example, the player is alt+tabbing to another application and/or they’ve minimized your game or the game is shutting down. You’re given an opportunity to free up some memory. Note that when the game regains the application focus,
RestoreDeviceObjects is called.

DeleteDeviceObjects

This method is called by the common framework when your game is shutting down or you’re changing the direct3d device alltogether. Anything depending on the direct3d basically.

FinalCleanup

This method is executed when the game is wrapping up execution. This method should be thought of as being paired with the “OneTimeSceneInit” function, so any game-specific object created at that point should be cleaned up here.

That’s it! If you have any questions or feedback, please leave them here or use our contact form.

The Common Framework that ships with the DirectX81 SDK is a great starting point for learning about DirectX programming. It’s lightweight and gives you a good container for either prototyping or a possible infrastructure for shipping code.

Only when you better understand what’s going on (and more importantly) where you need to plug your game code into will you see some progress in your projects. After analyzing the common framework setup, the lifecycle is actually broken down into 2 subcycles:

• application lifecycle
• direct3d lifecycle

Create

This is the very first method used to kick the entire framework lifecycle off. This should more or less be the only function you need to call in your WinMain entry point.

CMyD3DApplication g_d3dApp;
INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR, INT )
{

    if( FAILED( g_d3dApp.Create( hInst ) ) )
        return 0;

    return g_d3dApp.Run();
}

OneTimeSceneInit

After the framework begins its lower level registration and creation work with the Windows operating system itself, it provides you an opportunity to plug some object creation code in here. This function is only called once by the framework, so -
Do

• create your large data structures here
• load any game object that stays in memory during the entire game

Don’t

• touch any Direct3D specific component

ConfirmDevice (optional)

This is an optional hook for you to implement during the initialization phase of your direct3d device. It can be used to make sure the direct3d device chosen by the common framework supports the features of the Direct3D API that you want to use during your game.

InitDeviceObjects

After the OneTimeSceneInit function finishes up, the common framework goes back into its cave and handles the process of creating and initializing your Direct3D device. Once this is done, you’re now given the opportunity to create and initialize any Direct3D specific interface right here. So creating your vertex and index buffers, texture objects, and even any font objects among other things. This is only called once during the lifecycle.

RestoreDeviceObjects

After your Direct3D specific objects have initialized themselves, the framework calls RestoreDeviceObjects to “reset” them. This is where our “lifecycle” design starts to take effect, because this function is called at serveral other times:

• during InitDeviceObjects
• you alt+tab away from your game
• you resize the window
• you minimize / maximize the window

So here you might seriously consider resetting any Camera and/or projection and view matrices, as well as resetting any Direct3D device object that might be affected.

FrameMove

With our game application code and directx components ready to rumble, it’s time to kick your project into full gear. You don’t need to understand (or interface) with the main Windows message loop, but at this stage, your application is now in a constant loop. This method is called for the purpose of doing any non-direct3D updating tasks. Most commonly, this is the function in which you process any input from the player, as well as updating game objects, do any AI calculations, collision detection and any sound / music effects.

Render

Immidiately after FrameMove, the Render method is executed in which you’re given the opportunity to push all the graphics for the frame through the Direct3d device. In fact, you should only be talking to Direct3D in this function.

InvalidateDeviceObjects

This method is called when your direct3d device is about to lose focus. For example, the player is alt+tabbing to another application and/or they’ve minimized your game or the game is shutting down. You’re given an opportunity to free up some memory. Note that when the game regains the application focus, RestoreDeviceObjects is called.

DeleteDeviceObjects

This method is called by the common framework when your game is shutting down or you’re changing the direct3d device alltogether. Anything depending on the direct3d basically.

FinalCleanup

This method is executed when the game is wrapping up execution. This method should be thought of as being paired with the “OneTimeSceneInit” function, so any game-specific object created at that point should be cleaned up here.

That’s it! If you have any questions or feedback, please leave them here or use our contact form.