Monday, March 12, 2007

Gears of Awards

Microsoft’s 360 action romp Gears Of War has picked up three awards at the annual Game Developers Choice Awards. The title won trophies for Best Technology and Best Visual Art, as well as Best Game at the event, held as part of the Games Developers Conference in San Francisco.

Capcom’s Okami and Nintendo’s Wii Sports were the other big winners, with two awards each. Both titles collected a prize in the Innovation category, with Okami also picking up a gong for Character Design and Wii Sports triumphing the Game Design category.

Guitar Hero 2 picked up the trophy for best audio – following on from the original Guitar Hero's win in the category last year – and Legend of Zelda: Twilight Princess won for Best Writing.

Creator of THQ’s Titan Quest Iron Lore Entertainment was recognised as Best New Studio.

Nintendo’s Shigeru Miyamoto was singled out for a Lifetime Achievement award.

http://www.developmag.com/news/26059/GDC-Gears-of-Awards

Global multiplayer mobile games for j2me platforms using GPRS connection

Mobile phones are no more used for just making calls and sending messages. It has become a valuable source for entertainment on the move. Creating multiplayer games for mobile using Bluetooth has not created a big craze with mobile gamers, so moving to a global multiplayer game using GPRS which says play from anywhere and with anybody around the world, is going to hit a big market on entertainment industry soon. This idea has just been implemented by some big manufacturers. The idea of going with their option for most multiplayer mobile game developers is a bit unimaginable, because of the cost they charge for each game to interact with their server. This article explains about how to create a great multiplayer game for mobile platform using GPRS.

Requirements:

1. A good web hosting server with a strong database server.

2. A GPRS service that allow http connections.

3. A finished game ready to go globally multiplayer.

4. A bit Server side scripting knowledge. This is all that are required to develop a global multiplayer mobile game using GPRS connection.

The game server:

The total concept of the game server is to build it like a router which gets data from any client and redirects to the right destination client. Our game server is going to do the same work.

Server client architecture:

The client SDK, which we are going to develop later, should first post a login username details and wait for the response of the server. The server should add the client details to the queue table and should respond back with a game Id which is unique for each game played. Then the client should wait for the opponents. Till then the client should post for the game status. Whether the game has started or still has to wait for another opponent. Now when the other client logs in, the server responds with the same game id. And the status of the game is changed to “started". Now for reference the game id and the details of the game like who played when and who started will be stored in a different table.

Now both the clients should be removed from queue table and taken to the pairs table which holds the game id and client ids. Now the server allots ip address like on a network. Both the clients should then get their ips from the server. Mobile Game Developers should write a routine which creates ips randomly. Ip here we call is not the actual one which we use in networking. It is similar to a GUID (16 byte value) so that we don’t have to check for uniqueness in the game. Once all these transactions are over, the clients start to exchange there usernames and details to display with whom the player is playing with. These transactions are handled in a different table where each entry represents a data transfer between clients. The details “who has sent to whom" and “what" will be stored there.

Once all transaction has been taken before the game, both the clients transfer the game data to the other client. In SMNA we use acknowledgment make sure the other client has read the previous transaction. Unless a client acknowledges the message the other client will wait for the next transaction to take place. This is to avoid loss of data. To make it a complete featured game server we need to implement a high score list on the server. This is all what we do in SMNA. In this server script we have developed separate url script for every requests and posts, so that the load on the server gets spread during the game.

The Multiplayer game SDK development:

Coming to the development of SDK, the developer has almost completed most part of the project. Now having it as SDK will be more useful in the future, so that any game can be made multiplayer easily. The SDK should contain classes and functions like this, login(userdetails), checkForOpponent(), getGameID(), getOpponentName(), getIP(), sendData(), readData(). All these functions should use http post and read the server’s response back and feed the game routine with the information. Additional features like posting high scores and adding communities and rooms are very essential for the game server to reach the large market.

SMNA:

J2me developers, a custom mobile game development company with a passion on multiplayer SDK development has developed a game server. The game server and SDK both are for sale. The game server is coded in PHP and J2ME. This is a cross platform game server, where people from a website or PC connected to internet can compete with a person playing on mobile. It has a good high score database and a community management system to review on the game.

http://www.smackall.com/viewresource.php?resource=10

Philips to bring virtual world to Life

A partnership between Philips and Rivers Run Red will enable virtual world Second Life to take advantage of its amBX ambient experience hardware. The amBX kit includes lights, rumble and fans all designed to add an extra dimension to on-screen action.

Philips has also been experimenting with Rivers Run Red itself to market the amBX products via virtual demonstrations in the world itself.

Most importantly now, however, Philips will be creating solutions for open source Second Life client software that will allow users, via an SDK, to create amBX experiences and scripts themselves.

"Second Life offers an entirely new market for amBX and we feel this is the start of a very special relationship," said Jo Cooke, chief marketing officer, Philips amBX.

“Second Life offers amBX an unparalleled opportunity to bring our revolutionary ambient intelligence technology to an expanding global market of many millions of tech and media savvy users who are not only hungry, but also open-minded for new online experiences."

http://www.developmag.com/news/26062/GDC-Philips-to-bring-virtual-world-to-Life

Anaglphs in Games / Automated Game Testing

HONOR AMONG THIEVES (released in 2004 for the PlayStation 2) included an innovative anaglyph 3D feature. With the red/cyan glasses included with the game, players could experience real-time stereographic visuals in most gameplay areas. Producing stereographic anaglyph images (AKA anaglyphs) is a fairly mature practice among photographers.

Even so, special problems arise when generating anaglyphs for consumer televisions, in real-time, and within a "free" camera system. This talk presents the pro forma methods for producing anaglyphs, as well as several tricks for producing effective stereographic effects within a video game.

Alexander Jihn:

Automated game play testing in casual games development, including research into operant conditioning and it's uses in the development of a released game title.

http://www.igda.org/seattle/reports/02_2007r.htm

Gears of War,' 'Okami' and 'Wii Sports' Lead the Recipients of the 7th Annual Game Developers Choice Awards

Epic Games and Microsoft Game Studios' Xbox 360 shooter Gears of War was the recipient of three honors including Best Game at the 7th annual Game Developers Choice Awards. The blockbuster hit game also received the awards for Technology and Visual Arts. Following close behind with two awards each were Clover Studios and Capcom Entertainment's Okami and Nintendo's Wii Sports. The ceremony, produced and hosted by the Game Developers Conference (GDC) and presented by the International Game Developers Association (IGDA), is the only peer-based, open nomination awards program in the industry where honors are bestowed to developers by developers. Recipients were announced tonight at the 2007 Game Developers Conference (GDC) in San Francisco.

"A Game Developers Choice Award is like no other award presented in our industry, as it is the only prize that gives the community the chance to appreciate and honor individual developers," said Jamil Moledina, Executive Director of the Game Developers Conference. "By celebrating our visionaries by name, we give the audience and the public at large a chance to give credit where credit is due."

Nominations were free of charge and open to all IGDA members, ensuring that the nominees reflect the international development community's opinions. The IGDA membership voted on the finalists.

The recipients for the 7th annual Game Developers Choice Awards are:

Best Game

Gears of War (Epic Games / Microsoft Game Studios)
- Cliff Bleszinski, Michael Capps, Rod Fergusson

Audio

Guitar Hero II (Harmonix Music Systems / RedOctane)
- Jeff Allen, Eric Brosius, Izzy Maxwell

Character Design

Okami (Clover Studio / Capcom Entertainment)
- Mari Shimazaki, Sawaki Takeyasu, Kenichirou Yoshimura

Game Design

Wii Sports (Nintendo)
- Keizo Ohta, Takayuki Shimamura, Yoshiaki Yamashita

Technology

Gears of War (Epic Games / Microsoft Game Studios)
- Michael Capps, Ray Davis, Tim Sweeney, Daniel Vogel

Visual Arts

Gears of War (Epic Games / Microsoft Game Studios)
- Jerry O'Flaherty, Chris Perna

Writing

The Legend of Zelda: Twilight Princess (Nintendo EAD / Nintendo)
- Kyogoku Aya, Nate Bihldorff, Mitsuhiro Takano

New Studio

Iron Lore Entertainment (Titan Quest)
- Paul Chieffo, Jeff Goodsill, Brian Sullivan

Recipients for the evening's special awards were:

Lifetime Achievement

Shigeru Miyamoto

First Penguin

Alexey Pajitnov

Maverick

Greg Costikyan

Community Contribution

George "The Fat Man" Sanger

"Once again, the Game Developers Choice Awards have shown that gaming greatness can be found within every type of game -- from the most hardcore of experiences, to those that have brought all new audiences into our industry's fan base," said Jason Della Rocca, Executive Director, IGDA. "Each year, I am humbled by what our members can do with this great art form."

http://www.igda.org/newsroom/press_030707.php

Friday, February 23, 2007

Adding an Icon to your SDL application

One of the most frustrating things for me about creating games using SDL and JEDI-SDL is that they do not behave like standard Delphi windowed applications. While they are actual Windows applications, they are just not VCL applications. The window that SDL creates is a fully fledged Windows window, only a lot of it's internals/messages are hidden inside SDL's framework. This of course means that they are smaller in size than most Delphi application, but also they are developed in a non visual way and do not have icons to represent them.

Now users of programs always use the icon to recognise a program and if it just shows a blank white icon they need to actually read the text (when last did you read the description of any of the icons on your desktop?). So in a way this has become a big problem - especially as my biggest fans are my kids aged 4,7 and 9 - the smaller two just dont read english the way I do (They go to an Afrikaans school).

Now it is possible to set an icon to be displayed in the Task bar using:
Pascal Code:

SDL_WM_SetIcon( SDL_LoadBMP( 'Icon.bmp'),0);

And this should probably be done for all your applications as a matter of course, but this does not help a child find the game on the windows desktop as the icon is only set when the game is actually being run.

But it is possible to add an icon to your final distributable.

Using the delphi Image Editor create a new .res file. (A .res file is a resource file that can contain bitmaps, strings and icons). Add a new icon to the resource file. Name the icon the same as the executable to make it easier to remember. Draw a nice pretty piture for your icon. Save the .res file to the same directory as your project file.

In side the delphi project file add the following line
Pascal Code:

{$R .res}


And recompile your program. Suddenly your program will have an icon linked to it.

http://www.pascalgamedevelopment.com/viewarticle.php?a=58&p=1#article

Making 2D games with GLXtreem - Rendering

Introduction

The use of a Game Template is only of use once we start using it to create our games. This Tutorial is the first step toward the use of a template to create a game. The Game Template being used for this tutorial is my CairnsGames Game Template.

While this tutorial refers to GLXTreem used within Delphi, the basic structure and logic throughout the series of tutorials can be used for any language and any component set.

To use the source code in the Tutorial you will need to have the GLXTreem components set up and the template from ?_~Tutorial One: Writing 2D Games with GLXTreem?_T tutorial.

Deciding what is needed

Whenever a Development Template is used in a project, the items within the template that are required must be chosen. Any Development Template has functionality that isn?_Tt required by a specific project. At the start of the development process the various options must be made and the template needs to be modified enough to implement these options.

Some examples of decisions that need to be made are: do you need a high score system, will the game run in full screen or windowed mode.
Selecting your ?_~Story?_T
One of the greatest things about making a game is deciding why the game is happening. A story can be as simple as defining the rules of the game or as complex as a historical explanation for the game.

One game I made (Desperate Defence) had a long complex story but the game play was relatively simple.

In the peaceful Kingdom of Prokien life is sweet. The winters are mild and summers always bring bountiful harvests. But the neighbouring duke of Renkdass has sent his vicious armies to destroy the Kingdom.

The few soldiers of Prokien have defended the kingdom valiantly, but the enemy have relentlessly advanced razing town after town and pillaging each village as they passed. The King has retreated to his mountain fort with as many of his subjects as possible.

You have been left to defend the capital. A few loyal soldiers have been left with you. Daily you have had reports of the Duke?_Ts men advancing toward the capital. Your final line of defence is the meagre wall surrounding the King?_Ts Palace. The enemy have entered the capital and are surging toward the Palace.

You and the few men left must defend as long as possible!

The archers hiding behind the walls must shoot and kill as many enemy soldiers as possible before being killed. The Archers will shoot at wherever you click the mouse.

The story reads nicely but the actual game play of the game consisted of clicking on the screen where you wanted your archers to shoot.


Screen Drawing


So once you have your detailed story the first real rendering you?_Tll do to the screen is the introduction screen of the game.

In the Rendering function for the Introduction Game State the lines to draw the introduction is entered. If necessary a nice background picture can be included as well as any other images that you want to include to set the theme and feeling of the game. For Desperate Defence a nice grassy background with pretty trees surrounding the text box makes a nice introduction.

As indicated in ?_~Tutorial Two: Design of a Game Template?_T each Game State has its own Rendering Function. The introductions screen drawing then goes into the RenderIntro procedure.

Pascal Code:

Procedure Tform1.RenderInto(Sender : TObject; var Done: Boolean);
Begin
GLXDraw1.Clear;

// Instructions to display the Introduction of the Game
GLXDraw1.Begin2D;
GLXImageList1.Items[2].TileDraw(0,0,12,7,0);
// Do displays
WriteText('Header',130,10,GameTitle,0,1,0);
WriteText('Standard',100,60, 'In the peaceful Kingdom of Prokien life is sweet. The winters are',0.8,0.8,0.8);
WriteText('Standard',100,75, 'mild and summers always bring bountiful harvests. But the');
WriteText('Standard',100,90, 'neighbouring duke of Renkdass has sent his vicious armies to');
WriteText('Standard',100,105, 'destroy the Kingdom.');

WriteText('Standard',100,130, 'The few soldiers of Prokien have defended the kingdom valiantly,');
WriteText('Standard',100,145, 'but the enemy have relentlessly advanced razing town after town');
WriteText('Standard',100,160, 'and pillaging each village as they passed. The King has retreated');
WriteText('Standard',100,175, 'to his mountain fort with as many of his subjects as possible.');

WriteText('Standard',100,200, 'You have been left to defend the capital. A few loyal soldiers have');
WriteText('Standard',100,215, 'been left with you. Daily you have had reports of the Duke''s men');
WriteText('Standard',100,230, 'advancing toward the capital. Your final line of defence is the');
WriteText('Standard',100,245, 'meagre wall surrounding the King''s Palace. The enemy have entered');
WriteText('Standard',100,260, 'the capital and are surging toward the Palace.');

WriteText('Standard',100,285, 'You and the few men left must defend as long as possible!',1,1,0);

WriteText('Standard',100,310, 'The archers hiding behind the walls must shoot and kill as many');
WriteText('Standard',100,325, 'enemy soldiers as possible before being killed. The Archers will');
WriteText('Standard',100,340, 'shoot at wherever you click the mouse.');
// Add some pretty trees to make it look nice
GLXImageList1.Items[1].Draw(-10,10,0);
GLXImageList1.Items[1].Draw(-40,80,3);
GLXImageList1.Items[1].Draw(600,30,1);
GLXImageList1.Items[1].Draw(580,90,2);
GLXImageList1.Items[1].Draw(-30,140,3);
GLXImageList1.Items[1].Draw(-10,220,1);
GLXImageList1.Items[1].Draw(-20,310,2);
GLXImageList1.Items[1].Draw(550,140,0);
GLXImageList1.Items[1].Draw(570,200,1);
GLXImageList1.Items[1].Draw(560,270,1);
GLXDraw1.End2D;

GLXDraw1.Flip;
End;


Note that a second font is being used ?_" it was loaded into the GLXFont component in the LoadFonts procedure. Also some new images have been added to the Images.WGL file.

Fading an Image

Various special effects can be used to make a game look more professional. One of these is the fading in an out of an image. With GLXTreem its very easy to fade an image. The GLXDraw object has a property called UseColor. This property affects everything that is drawn to the GLXDraw screen. By changing the values sent to the UseColor procedure the screen can be faded in or out. By increasing the values toward 1 the image fades into view and by decreasing the values the image fades out.

Pascal Code:

GLXDraw1.UseColor(TC,TC,TC);
IntroImage.Draw(0,0,0);
GLXDraw1.UseColor(1,1,1);


Note that the WriteText method described in the previous tutorial defines its own Colours and will therefore overwrite the settings in UseColor.

Adding the Game Logic

By now the usefulness of a template can hopefully be seen. Each step of the way we have defined a set of default behaviour for the template and then we have added specific game functionality into the base.

Hopefully you can now take this base and add your own game logic. While this tutorial only covered the rendering of an introduction screen the same process can be used to render the game screen, the game over screen and the options screens.

This is the last in my series of making games with GLXTreem. From next month I will start a series of articles on using SDL and specifically my S2DL libraries in FreePascal and Delphi.

http://www.pascalgamedevelopment.com/viewarticle.php?a=38&p=3#article

Introduction to SDL Net using JEDI-SDL Part 1 - A Basic Client

This tutorial will give you a short introduction into using SDL Net in your applications. For those of you who don't know SDL Net is a cross platform network library that works on Windows, Linux, BeOS and MacOS X. JEDI-SDL is a project which converts the C++ header files for SDL, SDL Net to Pascal so it can be used in Delphi, Kylix, Free Pascal and GNU Pascal. The idea being is that you can write one set of source code which will compile on every platform.

In this tutorial we will cover how to connect to a remote computer (in this case a web server) as well as how to send and read data. The goal is to give you a feel on how a SDL Net application hangs together.

Getting the JEDI-SDL units

These units are available at http://sourceforge.net/projects/jedi-sdl. The current version is 0.5, version 1.0 is being worked on at the moment.
Once you have the units you will need to configure your compiler to use them. Visit the JEDI-SDL homepage for more details.

Initialising SDL Net

As with SDL before you can use the SDL Net API you need to initialise it. This is extremely simple, one single call to

SDLNet_Init;

does the job. Don't forget the when you finish you application to call

SDLNet_Quit;

to shut down SDL Net.

Connecting using TCP

For the purposes of this tutorial we are going to assume that you have a web server that you want to connect to (in this case www.google.com). Before we can actually connect to a remote system we need to obtain it's IP address. I'm not going to explain all the details of how networks work, so lets just say the IP address is a way of identifying a computer on a network.

SDL Net have a simple function to obtain the IP address of a named computer or "host".

SDLNet_ResolveHost

This takes three parameters, the first is of type TIPAddress, this record will be filled in if the call is successful. The second parameter is the name of the computer you want to connect to and the third is the port on which you want to talk to the remote system on. Ports are like communication channels, when writing systems you will be expecting to communicate on certain channels. For example the standard port used for HTTP requests is port 80, for FTP requests it is port 21. The function will return a 0 if successful. Here is some example code

Pascal Code:

var IPAddress: TIPAddress;
....
if SDLNet_ResolveHost(IPAddress,'www.google.com', 80) <> 0 then
begin
//raise an error
end;


In the example we are going to find out the IP address of www.google.com. Note that if you are using a proxy server this will not work, in which case if you have a web server running on your machine you could try 'localhost'.

Now that we have the IP Address we can try and open a socket to the remote machine. SDL Net provides the SDLNet_TCP_Open which will open a socket given a TIPAddress. We need to declare our socket as a PTCPSocket, if this is nil after the call SDL Net failed to open the socket.


Pascal Code:

var Socket: PTCPSocket;
Socket := SDLNet_TCP_Open(IPAddress);
if Socket = nil then
begin
// raise an error

end;


Sending and Receiving using TCP

Assuming we got this far we can now go ahead and send and receive data to the remote computer. In this case we are going to send a very simple HTTP request. I'm not going to go into the details of HTTP, but it is a text based system that will allow use to test the SDL Net DLL. In your system you would probably be sending binary data representing the objects in your game/system.

In order to send string information things get a bit tricky, we need to make use of the PChar support routines. Because SDL Net was designed to work with PChar's we need to convert the string data. Allot of more seasoned Pascal programmers would probably just Cast the string as a PChar (e.g. PChar(string)), I tried this and SDL Net does not like this work around, so we need to copy the string data into a PChar and then pass that into the appropriate function.

Sending data is very easy, we use the function SDLNet_TCP_Send to send data of a specific length. Rather than go into details here is the code that does the job.


Pascal Code:

function SendHTTPRequest(var Socket: PTCPSocket; Request: string): Boolean;
var Error, Len: UInt32;
cdata: array[0..255] of char;
begin
StrPCopy(cdata, Request+#13#10+#13#10);
Len := StrLen(cdata);
Error := SDLNet_TCP_Send(Socket, @cdata, Len);
Result := Error = Len;
end;


This function sends a very basic HTTP request. The two carrage returns added to the end of the Request are there so the Web Server knows that the command is complete.
In order to test our Socket we are going to request a web page from www.google.com . In HTTP 1.0 this is very easy

'GET HTTP://www.google.com/index.html HTTP/1.0'


will get the index page from google. So to make our request we send


Pascal Code:

if not SendHTTPRequest(Socket, 'GET HTTP://www.google.com/index.html HTTP/1.0') then
begin
// raise an error
end;


So we have send the request, now the interesting part starts. Reading data in can be tricky, there are a number of ways to read data in. One method is to call SDLNet_TCP_Recv and assume that your are going to get a response, the problem with that is that this function will just wait for a response. I have found that is the server does not respond this call does not return. Fortunately SDL Net provides us with a solution, there are a number of functions that allow us to check the state of a socket to see if there is any data waiting to be read.

In order to check the state of a socket we must use a function called SDLNet_CheckSockets. This function takes two parameters, and socketset and a timeout value. The SocketSet is an array of sockets which can be created and managed using the SDLNet_AllocSocketSet, SDLNet_FreeSocketSet and SDLNet_TCP_AddSocket functions. The timeout can be 0 if you want to do a quick check to see if there is any data, or any value in milliseconds. The function SDLNet_CheckSockets will return a value greater than 0 if any sockets in the Socket set have data waiting, we can then use the SDLNet_SocketReady function to check if our socket has data. Here is some sample code.


Pascal Code:

function CheckSocket(Socket: PTCPSocket): Boolean;
const MAX_TIMEOUT = 5000;
var SocketSet: PSDLNet_SocketSet;
begin
SocketSet := SDLNet_AllocSocketSet(1);
try
SDLNet_TCP_AddSocket(SocketSet, Socket);
Result := SDLNet_CheckSockets(SocketSet, MAX_TIMEOUT) > 0;
if Result then
begin
Result := SDLNet_SocketReady(PSDLNet_GenericSocket(Socket));
end;
finally
SDLNet_FreeSocketSet(SocketSet);
end;
end;


Now this function will return true if our socket has data waiting. I admit it's not the most optimised approach as each time the Socketset is Allocated and destroyed. In a real system you would create and socketset at start up and add each new socket to it. We will deal with that situation in part 2.

So now that we can detect if we have data it's time to read the data. The function SDLNet_TCP_Recv will do this for us. This function will read n bytes of data from the Socket into a buffer and returns the number of bytes read. Our problem in this example is that we don't know how mange bytes we are going to be reading. In a real system you would probably be sending data of a specific size you would know in advance how many bytes to read. In this case we will have to read one byte at a time until there is no more data. To do this we will write a new function based on the code in CheckSockets.


Pascal Code:

function ReadStringFromSocket(Socket: PTCPSocket): string;
const MAX_TIMEOUT = 5000;
var SocketSet: PSDLNet_SocketSet;
C: Char;
begin
Result := '';
SocketSet := SDLNet_AllocSocketSet(1);
try
SDLNet_TCP_AddSocket(SocketSet, Socket);
while True do
begin
if SDLNet_CheckSockets(SocketSet, MAX_TIMEOUT) > 0 then
begin
if not SDLNet_SocketReady(PSDLNet_GenericSocket(Socket)) then Exit;
if SDLNet_TCP_Recv(Socket, @C, 1) < 1 then Exit;
Result := Result + C;
end;
end;
finally
SDLNet_FreeSocketSet(SocketSet);
end;
end;


In this function we read from the socket one character at a time until there is no more data or the SDLNet_TCP_Recv function does not read 1 byte. As this is just an example we will overlook the fact that this is not a very optimal way to do things. As we have already mentioned it's better to read as much data in on go as possible, so having fixed length messages is the preferred method.

That should be it, we have made a request to www.google.com and we should have got a response. Now all we need to do is shut down the connection.

Closing the connection

Closing a TCP connection is easy, keep in mind that you will need to remove any Sockets from any SocketSets before removing them, otherwise you'd get some weird results and probably some access violations.

SDLNet_TCP_Close will close the Socket you pass in, also I always set the Socket to nil just in case.

Conclusion

We that's all there is to using SDL Net. In our next article we will look at writing a basic message server that will accept connections and send messages to all the connected clients.
The full source code for this tutorial can be found at here.

http://www.pascalgamedevelopment.com/viewarticle.php?a=20&p=1#article

Tuesday, February 20, 2007

Mobile Game Marketing

Greystripe's director of product management explores whether mobile games are sticking with marketers.

Advertisers are embracing mobile marketing, and many are moving even faster than when they adopted online advertising in the late 1990s. At the same time, analyst reports show that although the desire for mobile gaming is growing among consumers, they remain highly price sensitive. In this article, we'll explore how these factors suggest that advertising in mobile games is a huge opportunity and poised to explode over the next one to three years.

Advertising in mobile games around the world

Big brand names are already investing in mobile advergaming development, and the results have been worthy of some "high scores." For instance, Coca-Cola launched a mobile game in India called "Thumbs Up Everest--" a rock climbing adventure that included weekly prize giveaways and a top-score board. The results were impressive with more than 350,000 games downloaded each week. Advergaming also proved successful in creating pre-release buzz for Bollywood film "Jurm," where approximately 150,000 people downloaded the movie's puzzle game the first day, and volume approached 500,000 by the end of the week. Furthermore, the advergame for Jurm was a successful viral marketing tool, spreading from urban areas (where it was mostly advertised) to small towns by word of mouth, providing even more exposure for the movie.

Asia-Pacific countries lead the way for mobile game advertising opportunities, with 28 percent of consumers playing downloaded single-player mobile games at least once a week, according to Parks Associates' research. Europe and North America lag behind, with only 13 percent and eight percent, respectively, downloading mobile games, although far greater numbers play preloaded games.

Sparking Mobile Games through Advertising

Right now, there is a strong consumer desire for more fun and informational cell phone services. Recent Pew Research studies show that cell phone owners want to do more with mobile technology, and game playing ranks high on the list. Wider deployment of 3G networks, additional investment from game publishers, and more powerful devices will all improve the mobile gaming experience.

Despite all these factors, game downloads in Europe and North America have not been growing as a percentage of subscribers (about 13 and eight percent, respectively). Why the contradiction? A May 2006 M:Metrics report indicates price sensitivity is a major reason. Simply, lower price points are required to meet strong consumer demand and really ignite mobile gaming. And advertising sponsored mobile games can enable those lower prices.

Why are advertisers interested in mobile games? Demographics are certainly one reason. In the U.S., a May 2006 M:Metrics report indicates mobile games are downloaded at a rate of five million per month and, of the 16 million unique players, 35 percent are in the 18-34 male demographic that is so sought by advertisers. From trends in online gaming, we can expect to reach a more diverse group in the future. For example, women in their 30s and 40s account for a significant segment of game aficionados on the web, playing everything from solitaire and puzzles to casino and retro shoot-em-up classics.

Games are an ideal way to integrate mobile into an advertising campaign because they support larger and richer creatives than WAP pages. Games fill the whole screen and offer advertising without competition for user attention. Gaming is also attractive since it is a leisure time activity when users are more receptive to marketing messages. In a recent Mobile Entertainment Forum survey, 60 percent of respondents felt mobile games were "perfectly" or "very" suited for advertising. Additionally, around-game sponsorships are a cost-effective way to create positive brand associations without disrupting game play and without the cost of custom advergame development.

Mobile Game Ad Networks

Before mobile game advertising can really take off, some of advertisers' trepidations about this new market must first be allayed. Ad networks with reliable metrics, broad reach and sophisticated targeting will be a requirement. Advertisers will expect many of the same features they receive from online networks: self-service web interfaces, geotargeting for regional advertising, and impression capping. And critically important, reliable impression measurements are required. With these types of features, both large and small advertisers can tap mobile advertising with the same ease that they use Google AdSense and other online networks.

To be most effective, mobile game ad networks should support the creative formats and new actions that let advertisers tap the unique features of mobile devices. Mobile specific features such as click-to-call, location-based ads, opt-in for SMS and MMS, and consumer-to-consumer viral marketing will also drive the value of mobile ads. Looking to the future, advertising solutions should also provide a path to supporting emerging formats like mobile video.

M2M: Mobile-to-Mobile marketing

One of the most attractive opportunities for mobile ad networks is in Mobile-to-Mobile (M2M) marketing, which uses mobile-based advertising to drive sales of mobile ringtones, videos, wallpapers and games. These can be uniquely sold through mobile advertising since conversion can be immediate; there are anecdotal reports of click-through-rates over 50 percent.

M2M is precisely the strategy that GPShopper is employing to market its Slifter location-aware shopping application. Mobile advertisements placed through the Greystripe AdWrap network reach a wide game-playing audience and encourage them to download the free Slifter mobile application right there and then. To maximize effectiveness, the advertisements are targeted only at consumers using phones capable of running Java applications and wireless carriers that allow downloads.

Conclusion

As seen around the world, there is growing interest in mobile gaming and a great opportunity for in-game advertising. The key will be how advertisers take advantage of the technology available and where they invest their resources. Brands and advertisers can capitalize on the current sophisticated technology available, which is providing better reach, reliable metrics, and unique ways to engage mobile customers. Furthermore, they can leverage the momentum of gaming among a diverse and growing population that is more open to new forms of marketing. Let the games begin!

Jim Durrell is the director of product management at Greystripe and one of the inventors of Greystripe's AdWrap technology. Jim represents Greystripe in the Mobile Marketing Alliance, where he participates in the Ad Standards and Metrics committees. Prior to joining Greystripe, he was responsible for product management of location-based services at TruePosition, and before that accumulated more than ten years of telecommunications experience in management, sales, and engineering.

Mobile Application Developments

CRM SaaS vendors moving to mobile

Mobile CRM technology -- long hailed as the solution to keeping mmobile sales and field service staff connected and armed with up-to-date information, only to see disappointing returns -- is now grabbing the attention of Software as a Service (SaaS) vendors.

Last week, San Francisco-based Salesforce.com released new mobile functionality based on its acquisition of Sendia, a one-time partner and mobile application developer. That follows last month's release of eMobile from Entellium, a Seattle-based startup that is taking on established SaaS CRM vendors such as Salesforce.com and NetSuite. Entellium's release features a sliding menu that allows users to navigate the system with just a thumb -- similar to Apple's popular iPod.

SaaS (or on-demand) CRM, generally praised for its intuitive user interfaces and widespread user adoption, would seem to have an advantage when it comes to winning over a mobile salesforce that can be fickle when it comes to welcoming new technology.

"Yes and no," said Sheryl Kingstone, senior program manager with the Boston-based Yankee Group. "Primarily because Salesforce acquired Sendia, they have a leg-up in embedding into a mobile architecture."

Simplicity does matter in mobile CRM, she added. Because Entellium is relatively new, "they can start fresh instead of how the traditional CRM vendors just shoved their CRM onto the device to see if it works."

First Rate Financial, a Bellevue, Wa.-based mortgage lender, looked at both Entellium and Salesforce.com when it went shopping for a new CRM system five months ago. The company selected Entellium for its 24-hour support, price and adaptability, according to Mike Colagrossi, president and CEO. First Rate Financial also adapted Entellium to fit its 10-step sales process, which is similar to a traditional loan process.

Now, the mortgage company is leveraging the deployment on eMobile, connecting its mortgage sales team while they're on the road at open houses, CPA and real estate offices.

"From a manager's perspective, I don't bring a laptop in the field. It's just very clunky," Colagrossi said. "When we looked at Entellium and Salesforce, we had ideas of price point, versatility, and customizability. When we launched the mobile application, it pulled from modifications we did."

According to research from the Yankee Group, users of mobile CRM are warming to hosted applications. In a recent survey, more than 40% of mobile CRM users said they were interested in having a service provider manage their applications, while more than 70% said they were somewhat interested.

However, companies such as Antenna Software Inc., a Jersey City, N.J.-based mobile technology platform provider that focuses on sales and service, can offer a bit more.

"If a customer has Siebel and SAP and lots of databases they want to expose, that's where Antenna has the advantage," Kingstone said. "Most of the time, unless users just want accounts and contacts, they want to get into extra databases. If you just want account management and call logging, that's where Salesforce and Entellium have the advantage."

Yankee Group recommends that companies considering mobile deployments let business process frameworks that enable best practices drive the project; that the tools span multiple systems; and that firms make the deployment part of an overall application roadmap, such as CRM, SFA or service implementation, considering business cost, form factor and connectivity.

Tips on Developing an MMO Economy, Part I

Introduction

A lot of people e-mailed me about my other MMO related articles, and expressed their wish to do a follow up with an article about setting an MMO economy, and here you have it. But first a disclaimer:

This article is for your information only, and you should not trust everything you read here. Some advice might work for you, and some might not, therefore it is up to you to decide which, if any, methods you want to implement in your game. Many people complain about Eternal Lands economy, so please be advised that, although I do have years of experience in this field, I, like any other human, make mistakes.

Now that we are done with the disclaimer, let's focus on the real thing. In most MMOs, regardless of the genre and type (text only, browser-based, independent client), we have resources (items, money) coming in and going out of the game. Ideally, the ratio should be 1/1, that is, for every resource coming in the game, something of equal value must go out. Obviously, a perfect 1/1 balance is often impossible to achieve, but there are some tips that can help.

Tools to Use

The carpenter has the hammer, the navigator has the compass (or satellite-assisted navigation system), and the chef has the stove and pots. It is obvious that each profession requires, or can be facilitated by some tools. Designing an MMO economy is no different. Here are your tools:

1. An office suite such as OpenOffice, which is a free and a multi-platform alternative to Microsoft Office. A document editor is important for writing your design document and formulas. A spreadsheet can be useful for quickly testing formulas, and determining the ingredients price, experience gained and so on.
2. A program to draw diagrams and UMLs. Dia is a free, multiplatform program that is relatively easy to use. Making diagrams of how your economy is supposed to work can be very productive both for you and for those who work with you. Sometimes you can also show it to the players so that they will have a better idea on how the economy works.
3. A note-taking program. I am using Evernote , which is a shareware Windows program. The reason why a note taking program can help is because it just sits quietly in the system tray, waiting for you to use it. If you quickly come up with some idea while doing something else, you just click on it, write down whatever you need to remember, then return to what you were doing, knowing that the information will stay there, readily available when you need it.
4. A text (ASCII) editor. If you plan to store your economy-related files in a text format (such as XML), a document editor such as Word will not do, because such programs do not usually output a pure text file. I use Textpad , a Windows only shareware program. You can of course use Notepad, or various other free or commercial programs, but for me Textpad is the be-all-end-all text editor.
5. An 'in house' tool made by someone in your team that can digest economy related information, and give you a quick look on how one change in a formula affects another. While making such a program is by no means trivial, it can be very helpful in the long run. What this program would do depends on what kind of MMO you plan to make, and how much time your programmers have. One example of a task where it would help is determining how much time it would take a player to make a sword, if he does everything by himself (mining the ore, smelting it, molding the sword, etc.). The program would take into account factors like the time needed to harvest each ore, the time to smelt the ore, make the sword, let it cool. One other task could be to determine how many monsters of a certain type some player must kill in order to advance to some level. Or, perhaps, simulate a fight between two players where you manually introduce the data (skill, racial modifiers if any, weapons, armor). This way it is easier to test new weapons and armors.

In's and Out's

Before we start with the economy, we need to determine how the resources come in the game, and how they leave the game. Note that we will focus only on the items that actually enter and leave the game, not on the items that a player loses or gains. For example, if two players barter, they will both lose and gain some items, but no new item entered the game, and no old item exited the game. If a player drops an item when he dies, the item is still in the game; it can be picked by some other players. Please keep in mind that this list is not exhaustive and obviously, depending on the game mechanics, some methods of entry and exit will not apply. In the second part of the article, I will elaborate on some of them.

Points of Entry

1. Monster drops. Perhaps the most common, it includes both the normal drops (such as bones, meat, some gold coins) and the rare drops.
2. Collecting resources from the environment. Mining would be one example. Usually the resources are infinite, but a cap can sometimes be placed so only a limited quantity can be extracted per day, or perhaps per player.
3. Items made by players. Those items are usually made by combining two or more items.
4. Daily allowance. Some games give every player a certain number of resources every day or turn. The number of resources given to each player can be the same for everyone, or it can depend based on various factors such as experience, items the player has, virtual estate and so on.
5. Quests. Once a player completes a quest, there is usually some reward. This is not to say that the only possible reward is some money or some item.
6. NPCs. That is usually the case with the merchant NPCs, where the player sells or buys items. Generally, some item is lost and another item is gained.
7. Real life. A few games officially sell in-game items for real money. If a player sells gold to some other player for real money (gold farming), there is no new item entering the game; it is just transferred from a player to another. Therefore, if the game is properly designed, gold farming shouldn't be a big issue.
8. Contests. The contests are different than the Quests because they are usually a one time event with a limited number of winners. The prizes are often given directly by the developers/game masters by using 'artificial' means (some admin command). Sometimes players can organize contests, and give their own possessions as prizes, so no new item enters or leaves the game.
9. "Hand of God". This includes every item that artificially arrives in the game via an admin command, and is not a contest prize or bought for real money. Examples can include holidays (where the developers give gifts), a reward for finding a bug, an item meant for testing purposes, etc.

Points of Exit

1. Items used for mining/gathering resources. A player can be required to use some pickax each time they mine iron ore (the pickax breaks). Other items such as flowers can be mined without spending anything.
2. Items made by the player. Resources need to be spent in order to create items. Furthermore, you can make it so that sometimes the player loses the ingredients while failing to create the item.
3. Taxes. A virtual taxation system can be imposed in a game, where a player will have to pay a tax for each virtual estate they have, maintenance fees for the player based factories, salaries, etc.
4. Quests. Not all the quests will give you a reward in resources. Sometimes you will have to spend some money or items in a quest, in order to get something greater (experience, unlocking of a secret area, the possibility to start some other quest, etc.)
5. NPCs. No matter if you buy or sell something to an NPC, some item will exit the game. If you buy, the money will exit, if you sell the item you sell will exit. Other NPCs can charge you a fee to restore your health, give you a blessing, let you cross a bridge.
6. Broken items. Stuff breaks. We are talking about weapons, armors, ammo (if you can't reuse it after being fired). A 'natural disaster' system can be incorporated in the game as well, but more about it in the second part.
7. Natural decay. Some items have a limited life span: the food getting stale or items that are left unattended for a while being stolen by some virtual thief (that is, the server just destroying it).
8. Used items. A very common exit 'destination', it includes potions that are drunk, magic rings that are used, books that are read.
9. Fines. Sometimes, when a player is caught doing something wrong, part of the punishment depending on the circumstances can include an in-game items fine. You curse in a public channel, you need to pay 1000 gold coins, or else you get banned for a day. This can be a pretty effective deterrent, no one likes spending their hard earned money because they have a "dirty mouth".

Mobile Game Porting Methods

Introduction:

Mobile game porting is very important part of the mobile game development life cycle. This article describes the porting methods and trends in this field.

Mobile game market:

The mobile gaming market is growing very fast and it will capture the market of pc games soon. Day by day, game developers are increasing in this field because of the increasing mobile phone users all around the world.

Mobile Game Porting:

Why the term porting did come into mobile game development field? The main reason was the number of mobile phone models, mobile phone manufacturers and different languages for mobile device. A new developed mobile game’s market depends on the number of models covered as the target customers are huge when covering a large number of mobile models. The following are the types of ports which are usually undertaken by developers.

Type of porting:

• Platform porting
• Porting into different mobile phone models
• Localizations porting
• Different carriers porting

Platform porting

There are two main platforms for mobile devices which most developer concentrate are J2me and Brew. Most developer use J2ME as the number of models that support this platform is very high when compared to the other. Brew and Python come next in this list. If a developer wants to develop an applications or games and release it world wide then they will have to port it to other languages for covering all markets.

Porting into different mobile phone models

Mobile phone models are increasing day by day, and developers keep added them to their database for porting. Since customers who buy new mobile models buy more games, most of new models are the first target for developer.

Localizations porting

The term localizations porting mean changing the language in the application or game. For Example Chinese market which is considered the biggest market for mobile games, sell only Chinese ported models. Meaning, the text in the application or the game should be in their local language. Many other countries prefer such kind of localizations as the target customers prefer these languages.

Different carrier porting

There are different carriers each have a different terms and conditions to the mobile applications and mobile games. The carriers decide what devices it supports and what data services are offered to its subscribers. Carriers only support a specific platform like J2me or BREW. The most important choices to make at the beginning of the development process are on which mobile software platforms this game should run.

Methods of porting:

• Internal porting
• Outsource the mobile game porting

Internal Porting

If the developers do the porting then they have strong relationship with carriers and device manufacturers around the world for needed to ensure the availability of the necessary information. The global testing facilities are needed to be able to load applications onto the actual devices and test them. The frequencies and network protocols of wireless networks in various parts of the world often differ from a local network. In internal porting they will cover only some number of mobile models.

Outsource the mobile game porting

The main reasons for outsourcing the mobile game porting are given bellow:

1. It is highly reduce the cost of the products.
2. Porting into large number of mobile phone models.
3. Non Risky field.
4. Time management and quality control.
5. These works are doing by experts of this field.

For these benefits the mobile game developer’s or application developer’s products would be cover the hole world marketing very easily and quickly.

Thursday, February 15, 2007

Understanding and Negotiating Termination and Related Issues in Video Game Development Contracts

I have always viewed the video game development contract to be a little like a pre-nuptial agreement.

There certainly are major aspects of game dev terms and conditions that would never be found in a boy weds girl deal; but both are negotiated and signed when there is love in the air, expectations run high for great happiness and success, and the hardball positions taken by each side in the course of negotiating may be the first signs of chill in what has been a blissful but tempestuous courtship (or seduction!) leading to a walk down the aisle.

Like the basic pre-nup, it is the most sincere hope and expectation of both sides that once signed, the game dev contract can be tossed in the drawer and never referenced again (well, at least until royalty checks start to arrive).

However, not every marriage lasts, and not every game development contract leads to a hit – or even a completed project. At those times, the parties need to reexamine their earlier agreements and the rights of each party that may flow accordingly.

In the early pre-historic days of video games, as in 20 years or so ago, a game could be designed and programmed by one to three people in six to eight months at a cost of five or low low six figures. Developers and publishers traveled in the same circles, game publishers were making money hand-over-fist in an as-yet “undiscovered” industry, and publishers were still primarily privately held businesses. In such an environment, the risk of investing in development was low. When the game did not materialize in the form or time frame contemplated in the deal, the parties could rationalize and commiserate, share a drink, try to learn from the experience, and move on.

These days, with the capital cost of competing in the games business going through the roof, budgets for anticipated “AAA” franchise Xbox 360 and PlayStation 3 games equaling those for independent feature films, development requiring teams of upwards of 100 people working 18 months or longer on a single title, profits harder to come by in an increasingly competitive market, and game publishers primarily public companies (traded in Japan, Europe, or the United States) with the public markets' demands for profits and growth, it can be more difficult for a publisher to simply walk away when its developer expectations are not realized.

Just as a pre-nup contains the terms of a settlement in the event the marriage doesn't work, every game development contract contains termination language for when results do not equal expectations. Termination clauses are hotly negotiated because of financial baggage they carry. For the developer, a favorable termination clause can provide a critical nest egg while it transitions out of an abruptly cancelled project to find new work.

Because of the competitive nature of game development, and the careful screening process of publishers, it is not unusual to take six months or longer and a substantial investment in demos and preliminary design work, for a developer to find a new project. This dry period has the potential to drain a developer of its cash reserves, or even put the developer out of business.

For the publisher, paying a large settlement for a cancelled project is throwing good money after bad. Settlements paid to developers when games are cancelled directly impact the publisher's bottom line.

Publishers, as the financing entities of video games, typically issue the development contracts and control the drafting process. So it should not be unexpected to see first draft termination language that is far from generous for the developer. The “first draft” terms publishers offer are often far more onerous than those in other segments of the entertainment industry. For instance, unlike the movie business, it is an extreme rarity to find “pay or play” language in a game deal. It becomes the job of developer's counsel to improve the offer on the table. To do so, requires an understanding of the standard termination language alternatives that may be available.

Here's a publisher-friendly, but not atypical, termination clause taken from a hypothetical development contract. The clause includes six sections, each of which is set forth below, followed by analysis and commentary to assist in understanding the issues at play.

Section 1: Developer's Right to Terminate

BREACH AND TERMINATION

XX.1 In the event of a material breach of this Agreement by Publisher, Developer may terminate this Agreement by giving sixty (60) days prior written notice. Notwithstanding the foregoing, this Agreement will not terminate at the end of the notice period if Publisher has cured, or taken reasonable steps to cure, the breach about which it has been notified. Developer agrees that its sole remedy for failure by Publisher or its licensees to cure, or attempt to cure, any breach hereof, shall be a legal claim for damages, and Developer hereby waives all rights to seek injunctive and other forms of equitable relief.

Any analysis of a developer's right to terminate as a result of game publisher's material breach must start with consideration of the material obligations of the publisher that may be subject to breach. It is generally accepted that a “material breach” is any breach that goes to the heart of the agreement, or that is identified by the parties as being “material.”

The publisher's obligations that may be breached are limited by the terms of the contract. Publisher's representations and warranties in the first drafts of these deals are generally limited to publisher having the right and power to enter into the agreement, and to perform its obligations under the deal. These obligations may be as few as providing the intellectual property assets required if the game is based on a licensed character or property, reviewing and approving (or rejecting) developer's milestone submissions in its sole, unfettered, and subjective discretion, and paying for development milestones as and when they are approved. Once the game is completed, the publisher may be required to account and pay royalties as and when earned, and to provide audit rights as negotiated by the parties.

Default of any of these may or may not rise to the level of material breach. And if a default is not material, Developer's remedy is limited to an action for damages without the right to terminate the agreement. If I am developer's counsel, I want the agreement to provide that publisher's obligations to timely review milestones, give feedback, approvals, and make payment of all amounts owed to developer, are material obligations of publisher.

Termination for material breach frequently provides for a cure period before this extreme remedy can be invoked. Section XX.1, above, as it applies to the game publisher, provides for an unusually generous sixty days in which to commence or attempt (but not complete) the cure. Compare that to the cure period provided below for developer default. From the developer's perspective, a shorter and more definite cure period for publisher material breach is desirable.

Section XX.1 of our pro forma Termination section also provides that developer waives its right to seek injunctive and other forms of equitable relief in connection with any breach by publisher. This language is common in motion picture industry agreements. It serves as a sort of “insurance policy” to protect the producer from the risk of having distribution or exhibition of the finished project disrupted as a result of a dispute.

While we are sympathetic with the need for producers and game publishers to protect their investments, it is inappropriate for developers to waive their right to seek equitable relief in all circumstances. For example, I have represented a client who completed a game that was accepted by the game publisher and submitted to the hardware manufacturer for approval prior to manufacturing (this is the final step in the process to publish a game for the Nintendo, Sony, or Microsoft game console systems). My client was owed a substantial final payment. Despite repeated invoicing and requests, payment was not forthcoming.

Having waived the right to seek injunctive relief that could stop release of the game, as well as other forms of equitable relief, such as specific performance that could compel the final payment, our only alternative was to threaten litigation in the California Superior Court. Given the backlog, even if an action were to be commenced, it could delay recovery for an extended period of time – perhaps longer than the sales life of the game! Had the client been able to threaten and pursue injunctive relief, the pressure on the publisher may have led to quicker payment.

Another situation in which waiver of the right to pursue equitable remedies puts the game developer at a severe disadvantage may be when limited rights to developer proprietary tools and technology are granted to a publisher in connection with assignment of ownership of the underlying game. (Ref: This common circumstance was discussed by Alan J. Haus in his article, “Negotiating Ownership of Video Game Engines and Tools” that appeared in Los Angeles Lawyer, May 2005.)

If the publisher were to use these tools and technology in a manner that goes beyond the limited rights granted by the developer - for example, if the publisher were to incorporate the technology without consent into a sequel (a subsequent game using the same underlying property, game world, and/or characters) or a port (a version of the game designed to operate on a different hardware platform than developer's version) - developer's best remedy could be to enjoin release of the infringing sequel or port. Without such a right, developer's only remedy may be to sue for damages. And it may be extremely difficult to quantify developer's damages with any certainty in connection with such unauthorized expropriation.

Section 2: Publisher's Right to Terminate

XX.2 In addition to Publisher's other termination rights hereunder, Publisher may upon written notice to Developer terminate this Agreement as a result of a material breach of this Agreement by Developer, provided that Developer may cure such breach in fifteen (15) days from the date said notice is given except for termination by Publisher for material breach in connection with timely delivery of Work Product, in which case termination shall be deemed effective immediately. A material breach may include, but is not limited to, Developer's failure to finish the Game, Developer's ceasing to do business, Developer's failure to have the Work Product approved by Publisher, and/or Developer's failure to finish the Game on time or on budget as per the Milestone schedule. In the event of such termination, Publisher shall have no obligation to pay Developer any additional installments of the Fee, and Publisher shall be entitled to be paid back or to recover any and all payments made to Developer hereunder.

Publisher's termination rights differ markedly from developer's. Developer's cure period is limited to fifteen days rather than sixty, and developer has no right to commence but not complete a cure within that period. There is also a material breach by developer for which there is no cure period. Failure of the developer to timely deliver Work Product subjects the developer to immediate termination, presumably with notice but without the opportunity to remedy. The disparity in the publisher's termination rights is particularly disadvantageous to the developer because the factors constituting breach include elements outside of the developer's control.

The heart of every game development contract is an exchange of developer's services and work product for the compensation provided by publisher. Game development is undertaken in increments, called “milestones,” in which pre-determined work product content must be completed on or before designated calendar dates. Each milestone is then objectively compared by the publisher against: (i) the pre-agreed requirements for the applicable milestone, and (ii) the publisher's own subjective standards for quality. If a milestone is found to meet these objective requirements and subjective standards, it is approved and the resulting payment is processed. If it fails, even on publisher's subjective grounds, it can be rejected and developer must take all steps to remedy the failure to the publisher's satisfaction.

Game development requires close co-operation and support from many parties. The developer may rely on its publisher to provide certain elements of game content, hardware support, timely review, feedback, approval of milestones, and prompt payment of amounts due. If the game is based on licensed intellectual property, one or more third parties may reserve the right to review and approve material prepared by developer. For example, in a sports game based on a professional league, approvals may be required by the league, the players union, and by the sports celebrity or personality whose name and likeness appears on the package. If the game is being prepared to operate on a Nintendo, Microsoft or Sony hardware system, it will require review and approval of the applicable hardware manufacturer. All of the above may be out of the control of developer.

Delay in providing any of these materials or approvals (or payments!) can lead to delay in development of the game. Rejection of materials prepared and submitted in good faith by the developer can upset the development calendar set forth in the milestone schedule. And publisher business or operating considerations that are external to the development effort have been known to delay approval and payment of invoices that provide necessary cash flow to the developer.

But Section XX.2, as submitted, provides for immediate termination without any cure period in the event of any delay in timely delivery of milestones, without regard to the cause of such delay. Section XX.2 goes on to call out certain developer defaults that will be deemed to rise to the level of material breach.

The most significant issue to consider in describing a default as a material breach is that it escalates the potential remedy from an action for damages, and continuation of the agreement, to termination of the agreement. (Ref: IGDA Contract Walk-Through, Second Release (Sept. 25, 2003). For an example of pending litigation over termination of a development contract, see Spark Unlimited, Inc. v. Activision Publishing, Inc. , Los Angeles Superior Court Case No. BC338918.)

There may be defaults that truly “go to the heart of the agreement” and that can give rise to treatment as material breach. For example, as provided in XX.2, developer's failure to finish the Game, and developer's permanent ceasing to do business, may well rise to the level of material breach. However, XX.2 also identifies as material breach developer's failure to have the Work Product approved by publisher (a circumstance controlled in its entirety by the subjective determination of publisher), and/or developer's failure to finish the Game on time or on budget as per the Milestone schedule, whether or not the fault of developer. Finally, XX.2 provides that failure of developer to deliver any milestone on time, even if it is one hour late, is a material breach from which developer will have no opportunity to cure! It is difficult to accept, absent the language provided in XX.2, that such individual “garden variety” defaults would rise to the level of material breach. They certainly do not appear to “go to the heart of the contract.”

And publisher has a remedy for breach: its action for damages. In a contract action for breach of any of these “garden variety” provisions, if they were not called out as material in the agreement, publisher could be hard pressed to prove any actual damages when, for example, a milestone is one day or one week, or absent special circumstances, even one or more months late.

The final sentence of XX.2 provides a special remedy for publisher in the event the agreement is terminated as a result of material breach by developer. Given the economics of game development, which is a highly cash flow intensive and low profit margin business, being required to refund all amounts previously paid by publisher can amount to a prescription for bankruptcy for a developer. The money paid by publisher has been paid out in salaries, overhead, and equipment utilized by developer to meet its development obligations. Gross profit margins in the game development business are extremely low to non-existent.

If the defaults described in Section XX.2 were to be treated as simple breaches, and not material breach, publisher's remedy would be to seek contract damages. But any such action would permit developer to present its own evidence disputing liability. Treating defaults as material and providing for the extreme remedy of full reimbursement makes it tactically advantageous for the publisher to claim material breach. And as we will see below, there are other reasons why the availability of a broad category of material defaults may be advantageous to the publisher if and when it makes a strategic business decision to stop development of the game.

Section 3: Publisher's Right to “Terminate for Convenience”

XX.3 In addition to Publisher's other termination rights hereunder, Publisher may terminate this Agreement, or any platform under this Agreement, at any time prior to the Final Delivery Date, without cause, by providing Developer with written notice of such termination. In the event of such termination, Publisher shall have no obligation to pay Developer any additional installments of the Advance; provided, however, if Publisher has given written approval of a Milestone as set forth herein, then Publisher shall honor its payment obligations as per that Milestone. Further, in the event of such termination and in the event Publisher elects to have a third party complete the Game or Publisher completes the Game, Publisher shall have no obligation to pay Developer any additional or further amounts hereunder.

"Termination for Convenience” is a contract term and concept unique to the videogame industry. This permits a publisher, upon notice, to stop development of any game at any time under any circumstances; for example, if market conditions change, if the publisher decides to reallocate resources, if an executive change results in reappraisal of the project or work completed to date, or for any objective or subjective reason or for no reason at all.

For the developer, a termination for convenience can be unsettling, disruptive, and highly damaging. In performing its obligations under the development agreement, the developer has hired or retained staff, invested in equipment and technology, made commitments for facilities, assigned a material part of its work force to the project on an exclusive basis, refused other work or stopped pitching/soliciting for projects, and agreed contractually to the “key man” requirements provided in the development agreement so that its top people are exclusively on board for the project. Some development contracts provide that the developer will work exclusively for the publisher (and forsake all others!) during the duration of game development. Exercising the publisher's right to terminate for convenience in such a circumstance can jeopardize the continuation of the developer as a going concern.

Motion picture producers certainly enjoy the right to not produce, or to shut down a production if they are not satisfied with the way it is coming together. However, contracts for talent are often signed on a “pay or play” basis. Under such terms, the talent is paid the full fee whether or not it has provided services.

There is no “pay or play” concept in a typical videogame development deal. Termination for convenience provides for no compensation unless it is negotiated; and this can be among the most contentious issues in making these deals. Note that the pro-forma language in XX.3 above provides for minimal payment upon termination for convenience.

In considering how to handle the contract issue of publisher payments associated with termination for convenience, the developer needs to understand its cash flow and the realities of being left without a publisher after it has geared up to undertake the project.

At a minimum, the developer should insist that it be paid for all milestones delivered up to the point of publisher's notice (this is compensation for work performed), for all work performed in connection with the milestone then under development but not delivered (again, for work performed), the incremental and unavoidable costs of overhead incurred as a result of gearing up for the now-cancelled project (for example, equipment leases, additional office space that is now redundant, commissions to headhunters), plus an incremental payment to cover some period of overhead expenses while the company shuts down the terminated project and goes through its business development process to locate other work.

While not strictly a termination issue, the developer must also look at its staffing levels to decide whether layoffs are required.

A further issue has been raised by the pro-forma language. Once the publisher exercises its right to terminate for convenience, if it should decide to complete development of the game without the developer, there would be no further payment obligation, including royalties that could be earned, to the developer.

As provided in XX.3, the right to terminate for convenience can be exercised up until the Final Delivery Date of the game. Publisher may determine it would be economically advantageous to terminate the developer for convenience at a very late stage in order to get out from under a final payment and royalty obligation. Without the termination for convenience language, there may be a greater likelihood that such an action would be found to be acting in bad faith. A publisher who has its own financial pressures and considerations may regard late termination for convenience as an attractive alternative to paying the developer.

A final consideration when looking at termination for convenience is the risk that a publisher may attempt to wrap what is really termination for convenience into a termination for cause. This forces a re-examination of what constitutes developer's material breach.

Financial stakes may be high for a publisher. It may have determined it no longer wants the game for any number of subjective reasons. But in considering the cost of termination for convenience, where it will be required to make some sort of negotiated contractual payment (throwing “good money after bad” for a game that is cancelled), the publisher may look long and hard at developer's performance, its own subjective review of milestones, and try to find an instance that may rise to the level of material breach.

Using our pro-forma language above in Section XX.2, if developer were one day late or over budget in delivering any milestone, or if developer failed to have Work Product approved by publisher, such defaults may rise to the level of material breach and permit publisher to terminate the agreement with no cure period and no further payment obligation to developer. Taken to its farthest extreme, rather than making the required termination for convenience payment to developer, publisher's termination could be accompanied by a demand for refund of all amounts paid to developer to date. In effect, the publisher has taken advantage of favorable material breach language to mask what is really a termination for convenience.

Section 3.1: “Turn Around”

XX.3.1 In the event of termination under Section XX.3 and in the event Developer elects to complete the Game with or without a third party publisher and/or with or without different licensed content, Developer shall reimburse Publisher any and all of the amount paid to Developer up to the date of termination. In the event Developer completes the Game with a third party publisher, then reimbursement shall be made by Developer within thirty (30) days of commencement of such agreement with the third party publisher. Alternatively, if Developer completes the Game without a third party publisher, then Developer shall reimburse Publisher by paying Royalties to Publisher at a rate of 25% of Net Sales until all amounts paid up to the date of termination has been fully recouped.

Section XX3.1 brings the concept of “turn around” as used in the motion picture business, to videogames. Once the publisher decides it no longer wants the game and has stopped development, developer, who is at least as invested in the project as publisher, can have the opportunity to find it a new home.

The terms under which publisher is reimbursed for its investment in the game are highly negotiable. For so long as it is sitting on publisher's shelf, the game is just a sunk cost. There is no one better or more qualified than developer to complete the game. And there is no one more passionate than developer as an evangelist to promote the game to another publisher. Once a substitute publisher is identified, the terms under which the original publisher can recover all or a portion of its investment can be worked out. In this case, all but the most stubborn publisher recognizes that “half a loaf is better than none.”

Section 4: Publisher Termination After Completion

XX.4 In addition to Publisher's other termination rights hereunder, after approval of the final Work Product by Publisher, Licensor(s), and any Third Parties, Publisher may terminate this Agreement at any time for a breach of any of the representations, warranties, obligations, or indemnifications made, or agreed to, by Developer herein, or any material breach of this Agreement.

Be careful about language that permits publisher to terminate a development agreement in the event of any post-completion default, unless the survival clause provides that publisher's obligation to make all payments, account, pay royalties, and permit audits, survives termination of the agreement.

Developer should never be put in a position where it has performed, delivered a game that has been released and is on store shelves, and risks being cut off from contractually-mandated compensation because of a purported post delivery default.

Without this language, the publisher already has a remedy in the event of such default --- the action for damages. Nothing further should be required.

Section 5: Termination for Bankruptcy or Financial Failure

XX.5 In addition to Publisher's other termination rights hereunder, if a receiver, administrator, administrative receiver or manager shall be appointed or any distress or execution or other process shall be levied on or enforced (and not being discharged within 30 days) over the whole or any part of Developer's assets, or if Developer offers to make or makes any arrangement with or for the benefit of its creditors, or commits an act of bankruptcy, or if any petition to consider a resolution for the making of an administration order or to wind up or dissolve Developer shall be passed or presented, or if Developer ceases or threatens to cease to carry on business, or is unable to pay its debts as the fall due, or suffers any analogous proceedings under foreign law, then Publisher shall have the right to immediately terminate this Agreement upon written notice to Developer. If this Agreement is terminated pursuant to this Section XX.5, neither this Agreement nor any right or interest herein shall be deemed an asset in any insolvency, receivership, bankruptcy arrangement proceedings, and neither Developer, its receivers, representatives, trustees, agents, administrators, successors and/or assigns shall have any right to sell, exploit or in any way deal in any of the Game or Work Product. In the event this Agreement is terminated by Publisher hereunder, any and all Work Product created by Developer hereunder shall be immediately delivered to Publisher.

XX.5 provides for publisher's right of termination in the event of the standard financial failures of developer. Some consideration should be given to how to handle similar circumstances on the part of publisher.

Particularly when dealing with a smaller “tier two” or “tier three” company, developer may want to reserve its rights to terminate and to retain (or reacquire) ownership of Work Product in the event its publisher suffers an analogous financial setback.

Rumors of financial upheavals and consolidation are a fact of life in the games industry. Rights in the event of adverse financial circumstances should go both ways.

The second half of the pro-forma section reserves rights in the event of bankruptcy. This is very common language in game development agreements. However, we'll leave it to the bankruptcy experts as to whether it is enforceable. Institution of bankruptcy proceedings by or against either party to a game development transaction alters the landscape in a way that goes beyond the scope of this material.

Game developers' counsel has come to appreciate that termination provisions, like all contract language in game development deals, are driven by the generally commanding bargaining position enjoyed by game publishers.

This is not unlike our hypothetical pre-nup that can be driven by the side with the greatest assets.

But by careful negotiation and an understanding of the issues, developers' counsel can take steps to give his or her client a more even-handed agreement into which the parties may enter their relationship.

Once this contracting hurdle is passed, developer and publisher may focus on superior game development – the purpose of making the deal -- and work together hand-in-hand to make sure they can “live happily ever after!”

http://www.igda.org/articles/jcharne_termination.php

Friday, February 9, 2007

J2ME Developers and Programmers: The Mobile Game Industry Winners

If you think that current gaming technology is hot then, as they say, “you ain’t seen nothing yet.”

Wireless or mobile gaming is the future and the future is now. 2004 saw an explosion in mobile gaming technology which redefined the mobile phone as a gaming device. Handsets capable of displaying graphics equal in quality to the GameStations and GameCubes of the 1990’s were available everywhere, and game developers like Synergetix and It's Alive! were on everyone’s radar screen.

Now, just a year later, Real-time multiplayer games, some offering high-quality, 3D graphics, can be played over most telecom networks at prices that won’t put you in the poorhouse.

Never one to be too far behind the bleeding edge, even the Adult Entertainment industry is turning out PDA and cell phone-based games including gambling programs and a variety of role-based and action games where lots of sexy women end up losing their clothes. The graphics are, shall we say, stunning.

A peek under the technology hood

While the average gamer may be ignorant of the technology that is driving the wireless gaming industry, the geeks among us are very familiar with terms like J2ME, Symbian, and Brew; the development and distribution platforms upon which the wireless gaming industry has built its success.

J2ME (Java 2 Platform, Micro Edition) is a derivative of Sun Microcomputer’s JAVA development platform. J2ME is specifically designed to build applications that run on portable and wireless devices including cell phones and PDAs. It’s also finding wide acceptance among companies that develop applications for TV boxes and many of the new embedded devices which are flooding both the consumer and industrial markets.

BREW, another development language from QUALCOMM, provides a development platform that’s also suited for the wireless industry. BREW’s claim to fame is that fact that the developer can write device-independent applications which do not need to be recompiled for different phone manufacturers.

SYMBIAN is probably the most commonly used OS in the game-enabled wireless telephone market. Embraced by all major phone manufacturers, SYMBIAN supports J2ME, BREW, C++, and JAVA.

So, what does the future hold for this high-tech blockbuster that’s still in its infancy?

According to industry analysts Frost & Sullivan, the “global mobile game industry, which generated US$436.4 million in 2002, will balloon to US$9.34 billion by 2008.“ Asia is at the epicenter of the wireless gaming explosion where an estimated 500 million people are wireless Internet subscribers and two out of five are wireless gamers.

Some gaming fortune tellers predict that the convergence of GPS and wireless gaming technology will result in live-action and role playing games that will adapt themselves to the player’s physical location and include geographic-specific scenarios that change as the player moves to new locations.

Judging by the progress that’s been made in the last two years alone, the future of wireless gaming may be the most revenue and employment-generating technology of the 21st century.

Flash Opens New Windows and Opportunities For Game Designers

Flash is an interactive platform that has a powerful design and animation tool along with a dynamic scripting engine, bitmap rendering, as well as advanced video and audio playback. There are three main aspects: the player, the file format, and the authoring tool/IDE. Flash games can be developed for websites, interactive TV, as well as handheld devices. There is no need to adopt multiple programming languages to build games.

It is the universal tool that permits the development of multimedia driven complex games. Games means fast, furious, efficient with rich graphics.

Flash enables developers to build the most popular games for online gamers. It just needs to support:

• Rich engaging graphics.
• Smooth download of files from the net.
• A playback device that can interpret downloads.

There are three main areas: design, development, and hosting.

The first step is creation of graphics. One must use Fireworks as well as Freehand for this aspect. The tools are compatible and fireworks allows the addition of Java script to images.

The game development will be done in Flash by importing graphics created in Freehand and Fireworks. The graphics are then placed in Director the parent tool of Flash.

The next part, hosting, uses a Web server. Dreamweaver MX is the tool that will create Web pages to host the game.

And, finally Action Script is used to provide enhanced functionality.

Advantages:

• Integrates almost all features needed for developing a game. It is a great interactive tool.
• Can be used anywhere does not need additional software or plug ins.
• It is Mac friendly.
• Permits conversion from a full game to web version and vice versa.
• Low cost and free to distribute. Licenses for decoders MP3 and Sorensen Spark are included.
• Artists that can use flash easily are in plenty.
• Flash delivers broadcast quality images over the Internet.
• Permits embedding of game in power point for use in presentations.
• Plenty of information as well as guidelines can be accessed as well as understood by all –tutorials, articles, as well as blogs.
• The size of the game file remains small as the vector graphics and sound files are compressed.
• Learning Flash language is easy.
• Permits copy-paste to test components

There are traps one must be wary of and a few cons. Know the system well to maximize its use. There are plenty of tutorials inline that can be used as guides. Flash interface is ideally suited to both designer as well as developer, you can have fun while creating the game.

Flash is simple to use and a game can be developed in a few hours in a packaged form that can run on a PC, Mac, or Linux. One can make use of a browser or run the game as a stand alone.

Why Location is Key to Finding Video Game Tester Jobs

The job of a game tester seems elusive to some. They are not easy jobs to get if you do not know where to look. Each video game company does have game testers. Game testers are responsible for making sure that the video games are problem free and ready for the public. They are an essential part of the game development team.

One of the biggest challenges in getting a game tester job is location. The majority of game testing positions are for in-house, meaning the game tester works at the company office. There are very few companies that allow a person to work at home. The reason for this is that the communication between the tester and the programmer is on-going. They have to be able to discuss the problems so they can be worked out.

So, an important aspect of finding a game tester position is location. If a person does not live near any gaming companies then they are unlikely to find a job. There are, however, gaming companies located throughout the United States. The first thing a person should do is checkout if there are companies near them or where the closest company is located. Then they can apply to the company or companies that are within their location.

Becoming a game tester is not too difficult. Mainly it is about finding a company and then applying. Living near a gaming company can help increase your chances of landing a game tester job. There are a few resources online that can help you find a video game tester job for you.

Tablet PC Games

Tablet PC games include crossword puzzles, Microsoft Sudoku, and many war games that are more advanced in nature. News reports indicate that Microsoft is in the process of designing a Tablet PC game software development kit (SDK) and a new Tablet-PC-specific game, both meant to draw new developers and customers towards buying Tablet PCs. Another game that is being developed by Microsoft is the "Arc of fire."

The M4 release concentrated on Tablet PC-specific improvement, game-play development and incessant refactoring to develop performance. "Arcs of Fire" now runs in portrait and landscape modes, and re-sizes itself based on screen rotation. It also responds to system-wide power events, and can be held in suspended animation until the user restarts it. Gesture support has been added to AoF and the circle gesture to toggle sound, the square gesture to maximize or restore the game, and the star gesture to exit the game. Slate labyrinth is another tablet PC game that has a maze of roads, which are to be crossed.

Another popular tablet PC game is the Metroid, which does not have very good reviews on the Internet. Users of Metroid have complained about its awkward controls. There are many other puzzle games available on tablet PC's that can be downloaded from the Internet free of cost or as a shareware.

Any game that can be played on a normal computer can also be played on a tablet PC by properly downloading it or on a burn-and-share basis. Many companies also offer free games along with their software. Some of the software companies in the gaming industry are Valve Software, Id Software, Micropose and Lionhead studios. These are makers of some famous games such as Half Life, Doom, and Quake. The web sites of these companies offer these PC games for free or as shareware.

How to Write a Video Game Script

Writing a video game script offers a challenge that goes well beyond the normal realm of writing. But it is also something that can be tremendously rewarding in the scope of its creativity. Here are some guidelines and tips for writing a video game script.

Today’s video games are based in complex worlds and they tell stories. No longer does a player simply advance through repetitive screens slaying goblins and ghouls in a quest toward the goal. A player now expects to progress through a world where there is a rich history and a plethora of decisions to be made. This adds to the complexity of writing a video game script and it also adds to the richness of the creativity involved.

The first thing you need to think about is that writing a video game script is that it is not the same as writing a movie script. The two processes are similar and you do write a movie like script for your video game but that is only part of the process. There is a whole host of accompanying materials that you need to write for your game script. Here is an overview of what you need to write and why.

Write An Executive overview of the story in prose

This is the most important part of your game script and this is what will sink or float your script. This overview has to tell a compelling and unique story and it should tell the complete story from the opening scene of the game through the major steps all the way to the completion of the game. An overview like this can be almost any size and it would be very easy for this to be ten written pages or more. Remember that today’s video games are very complex and the stories can be very complex. This overview is also the most important part of the script. You would shop this to game developers to see if they are interested in developing it into a game.

Write a History and Background of the world

Video games are complete worlds and game designers need to know what the world is like and what kind of history it has. This will help the designers to visualize what the world will look like.

Create a Flowchart for the entire game

Your game is going to be very complex and there will be many decisions that the player will have to make and each decision opens up a whole new path for the player to take. Creating a flowchart is the best way to keep track of all the possible paths through the game.

Create sub-quests and write a prose overview of each quest

Sub quests can be simple or complex but each one is a story in itself and you must tell these stories.

Create character descriptions and bios for all the major characters in the game.

Game designers need a complete picture of the characters in the game. Many of the non-player characters you create will pop up time and time again. And their story is woven deeply into the fabric of your world. You need to describe this relationship in detail to the game designers.

Write interactions with non-player characters

Your game will probably involve interaction with non-player characters (NPC’s). You should write out the dialogue and flowchart the choices the game player can make. These interactions are often critical to the story and they can take the player on very different paths toward the conclusion of the game.

Write Cut scenes

Cut Scenes are short animations or movies that come before or after major plot points in your story. A cut scene should always be written to enhance or describe the story. A cut scene is also a reward given to the player for achieving a major milestone in game play.

Writing the actual storyboard script

This is the final step in the whole video game script writing process and it is the most detailed. You do this step last because you need all the supporting materials to understand and describe this correctly. This part is very similar to that of a movie script. You progress through each scene of your story and you detail all the necessary information. Here is an example:

Scene 1:

Location: A dark cathedral with stained glass windows. An NPC is kneeling before a stone casket in the center of the main room

Music: background music of an organ playing introduces the scene but subsides

Characters: Main player, NPC named Thomas, seven were creatures

Player Goal: Discover the location of the underground lair

Action: Player must initiate discussion with Thomas, upon first contact we activate cut scene (1) where Thomas morphs into a were-creature and summons his were-minions. Main character must battle the were-minions then re-initiate discussion with Thomas.

Flowchart: No decisions made at this point: If battle is completed Thomas reveals the entrance to the underground lair and player advances to that level. If player is defeated in battle revert to death cut scene (11) and move to try again screen.

Notes: Player is locked in the cathedral and there is no exit. The only viable way out is to initiate contact with Thomas. Random were-creatures can be activated if player explores cathedral before talking with NPC.

Scene End

When writing a video game script you have to remember that your primary audience is not the game player but the game developer and what the developer needs is a complete picture of what your game is about. This means that you are not just writing a story but you are creating a world complete with a tone, sounds, characters, story, plot, and subplots. To successfully communicate this to the developer you need to use a whole set of creative tools and this is where video game scripts depart from normal scripts and open up a whole realm of creative possibilities.