These days there is a buzz about 3D and multi-player gaming. All the big telecom operators are quite bullish on 3D gaming and multi-player gaming. They are being touted as the next big thing. Before going into the technical details we will look at the emerging scenarios and market conditions driving 3D and multi-player gaming. As many of you might know, the telecom operators worldwide have invested huge amounts in making there telecom network 3G ready. 3G will revolutionize the data transfer speeds between the mobile phones. Applications like video on demand will be made possible by the arrival of 3G networks. 3D games and multi-player games will also become a reality with the advent of 3G. Already in countries where 3G has been launched, 3D games and multi-player games have become a reality. 3D games are heavy and demand high speed data transfer for the applications to be downloaded. This is being made possible by the launch of 3G services. Also as the data transfer speeds grow the problem of latency which has been a huge roadblock in the introduction of multi-player games will be removed. For massive multi-player games to become popular high bandwidth networks are needed which will be introduced as part of 3G rollout around the world. 3D Gaming We live in a 3 dimensional world. Thus our brains have been programmed for the 3D world. So it is only natural for us to demand a 3D environment in the games we play. As programmer your job is to delight consumers by giving them excellent 3D games. It is expected that 3D games will enable game developers to charge up to $10 per game. There are talks of even $ 25 charge for high end 3D games. Thus even from a financial point of view switch to 3D gaming makes sense for game developers. Before proceeding into 3D gaming using J2ME we should see the ecosystem required for 3D games. 3D Gaming Ecosystem · Mobile 3D Graphics API (JSR 184) enabled mobile handsets · Medium to High bandwidth networks for delivering content · Telecom operators interested in marketing 3D content · 3D graphic modeling tools for rapid game development
As we discussed earlier in detail Mobile 3D Graphics API (JSR 184) has been introduced to enable J2ME developers to develop 3D games. All the big phone manufacturers are bullish on introducing JSR 184 compatible handsets. In the list of mobile phones given in this book you could see the list of handsets supporting JSR 184. Thus the most important element of the 3D ecosystem is slowly taking shape. With the introduction of 3G networks data transfer speeds will take leap ahead. Users would be able to download 3D games with big file sizes. Telecom operators are also very bullish on 3D games. They want to market them as 3D games bring more revenue and more network usage. A win-win situation for network operators. JSR 184 enabled 3D modeling tools have also arrived in the market. Companies like Discreet and Swerve develop 3D modeling tools that are JSR 184 compatible. 3ds Max 7 by Discreet is a very high end 3D graphic modeling tool that is being used by big gaming houses and film studios for creating 3D content. This tool is also having support for developing content for the JSR 184. Thus you as 3D game developers could use 3ds Max 7 for the development of 3 dimensional objects which could be used in your games. Thus we find that the complete 3D gaming ecosystem is taking shape. The only word of caution while developing a 3D game is that 3D games are more complex. They compete head on with console games and are very expensive to develop. Technicals of 3D Gaming When you had read about Mobile 3D Graphics API (JSR 184) you must have thought how in the world will I program 3D objects using this API? Actually the fact of the matter is that we do not have to model all the objects in this API as a programmer. We can use 3ds Max 7 and export the objects to a M3G file. The M3G file for the 3D objects and environment will contain all the information needed to recreate that information. The JSR 184 allows us to create and animate 3D objects in two modes: · Immediate Mode · Retained Mode In the ‘immediate mode’, 3D content can be generated directly through programming. No 3D authoring tool is required. The only problem with this approach is that you would not be able to develop complex graphics using the immediate mode. The reason for not able to create complex graphics is that complex character, visualizations and animations are very difficult to model directly through programming. Thus this mode has limited utility on its own. For creating complex games we will have to use retained mode. Retained mode allows us to use the graphics which have been modeled through 3D modeling software. As discussed earlier the user can create some body of work in the 3D modeling softwares and then export it to a M3G file. From there you can load the graphics in your application and use 3D content. 3D Gaming Best Practice Try to do as much work as possible in the 3D modeling tools. It is very difficult to edit 3D artwork through direct programming. Perform only that work through code that is not possible to be accomplished in 3D modeling tools. While working on 3D applications do remember that 3D content files are very large. Even small files with 2 simple objects can take 20 kb, quite huge when you compare with the total application size in the early days of J2ME mobile programming. Therefore carefully plan the re-use of objects in your 3D game. Also limit the interactions between various elements. A technique called ‘scoping’ can be used. In scoping you can tell the 3D graphics implementation when objects are not going to interact with each other. This will save memory. Now we will see a code example of loading the content from an M3G file and using it from within the application. It is a very simple application. Suitable explanations wherever possible have been given inside that application. Code Example /******************************************************************************/ /** * Author : Saurabh Jain * Version : 1.0.0 * * Copyright (C) 2004 Superscape plc * This file is intended for use as a code example, and * may be used, modified, or distributed in source or * object code form, without restriction, as long as * this copyright notice is preserved. * The code and information is provided "as-is" without * warranty of any kind, either expressed or implied. */ /******************************************************************************/
import javax.microedition.midlet.MIDlet; import javax.microedition.midlet.MIDletStateChangeException; import javax.microedition.lcdui.*; import javax.microedition.m3g.*;
public class My3DWorld extends MIDlet implements CommandListener { // Variables. // Reference to the MIDlet's display private Display myDisplay = null;
// Reference to the current canvas. private CallbackCanvas myCanvas = null;
// A command which is used to exit from the MIDlet. private Command exitCommand = new Command("Exit", Command.ITEM, 1);
// Reference to the world which contains the My3D cells. private World myWorld = null;
// The root group, which is the one we rotate slowly. private Group rootGroup = null ; private Group rootGroup2 = null ; private Camera myCamera = null ;
private float angleX ; private float angleY ; private int time ;
Graphics3D myGraphics3D = Graphics3D.getInstance();
int viewport_x; int viewport_y; int viewport_width; int viewport_height;
public My3DWorld() { // Set up the user interface. myDisplay = Display.getDisplay(this); myCanvas = new CallbackCanvas(this); myCanvas.setCommandListener(this); myCanvas.addCommand(exitCommand); }
/** * This initializes the game state, and generates a M3G world programmatically. */ public void startApp() throws MIDletStateChangeException { // Catch excpetions here before they go too far. try { // Create a new M3G world by loading it from the M3G file myWorld = (World)Loader.load("/swerve.m3g")[0] ; setupAspectRatio() ;
// Attach to display myDisplay.setCurrent(myCanvas);
// Force a repaint so that we get the update loop started. myCanvas.repaint(); } catch(Exception e) { e.printStackTrace(); } } /** * On pause, simply shut everything down. */ public void pauseApp() { // Release resources. myWorld = null; } /** * On exit, simply shut everything down */ public void destroyApp(boolean unconditional) throws MIDletStateChangeException { // Release resources. myWorld = null; myCanvas = null; }
/** * MIDlet paint method. * * This is called back from the inner Canvas class. It renders the current state of the * cells, then updates them and schedules another update. */ public void paint(Graphics g) { if(myCanvas == null || myGraphics3D == null || myWorld == null) return;
if(g.getClipWidth() != viewport_width || g.getClipHeight() != viewport_height || g.getClipX() != viewport_x || g.getClipY() != viewport_y) { g.setColor(0x00); g.fillRect(0, 0, myCanvas.getWidth(), myCanvas.getHeight()); }
// Render the world to our Graphics (the screen) using the m3g class Graphics3D
// render the 3d scene myGraphics3D.bindTarget(g); myGraphics3D.setViewport(viewport_x, viewport_y, viewport_width, viewport_height); myGraphics3D.render(myWorld); myGraphics3D.releaseTarget(); }
/** * Make sure that the content is rendered with the correct aspect ratio. */ private void setupAspectRatio() { viewport_x = 0; viewport_y = 0; viewport_width = myCanvas.getWidth(); viewport_height = myCanvas.getHeight(); // Get the active camera for the world Camera cam = myWorld.getActiveCamera();
float[] params = new float[4]; int type = cam.getProjection(params); if(type != Camera.GENERIC) { //calculate window aspect ratio float waspect=viewport_width/viewport_height;
if (waspect<params[1]) { float height = viewport_width/params[1]; viewport_height=(int)height; viewport_y=(myCanvas.getHeight()-viewport_height)/2; } else { float width = viewport_height*params[1]; viewport_width=(int)width; viewport_x=(myCanvas.getWidth()-viewport_width)/2; } } } /** * Handle commands. * Currently, the only command enabled is "Exit" - this just * destroys the MIDlet immediately. */ public void commandAction(Command cmd, Displayable disp) { if (cmd == exitCommand) { try { destroyApp(false); notifyDestroyed(); } catch(Exception e) { e.printStackTrace(); } } } /** * Handles key presses. * This is called back from the inner Canvas class, and implements * the behavior of the various keys outlined in the class summary. */ public void keyPressed(int keyCode) { // Incrementing the time and animating the world based on the incremented time time += 50 ; myWorld.animate(time); myCanvas.repaint() ; }
/** * Inner Canvas-derived class for handling canvas events. */ private class CallbackCanvas extends Canvas { My3DWorld mymidlet;
/** * Construct a new canvas */ CallbackCanvas(My3DWorld midlet) { mymidlet = midlet; } /** * Initialize self. */ void init() { } /** * Cleanup and destroy. */ void destroy() { }
/** * Ask mymidlet to paint itself */ protected void paint(Graphics g) { mymidlet.paint(g); }
protected void keyPressed(int keyCode) { mymidlet.keyPressed(keyCode); } protected void keyRepeated(int keyCode) { mymidlet.keyPressed(keyCode); } } }
Thus we see that although using the 3D API is a little bit difficult but the use of 3D modeling tools and M3G files makes our task easier.
Multiplayer Gaming Multiplayer games are getting very popular these days. A Multiplayer game can be defined as any game which can be played simultaneously by more than one player and the actions of all the players affect the same gaming world. Within the ambit of this definition many kinds of multiplayer games can exist, namely: · Massive Multiplayer Games · Bluetooth Enabled Multiplayer Games · SMS/MMS Enabled Multiplayer Games
Massive multiplayer games are those multiplayer games where large numbers of players play simultaneously. 10000+ players playing a game is a normal thing for such games. Such games need huge servers for synchronizing the moves of different players. Such games could have PC, PDA and mobiles as the client machines. These games require specialized knowledge and great effort to build. We would be looking at some of the factors that have to be kept in mind while developing such games: · Low Latency · High Scalability · Fault tolerance · Computational Efficiency · Player authentication · Player access control · Subscription management · Security · Game administration and community management · Client side updates
Latency is the single most important factor that can make or break a game. For a game to be successful latency has to be in the order of a few milliseconds. The requirement of 3G and broadband is necessary due to the latency problem. Scalability is required for these games as when the game becomes successful the number of subscribers rise very fast. Therefore the application needs to be scalable to support large number of subscribers as well as a small number in the beginning. Massive multiplayer games involve both client side and server side programming and are thus very specialized kinds of applications. Therefore we will limit our discussion on them here. If you want to know more about them do visit website of Sun Microsystems. Multiplayer games can also be of another kind. They can enable peer to peer networking through bluetooth. In fact some such games have already arrived. These games enable a player to play the game in the multiplayer mode in a closed user group. This group has to be in physical proximity as bluetooth enables networking only over short distances. These games increase the fun element in the games as people generally want to enjoy in groups. Bluetooth enabled multiplayer games have some issues of there own. We will discuss some of those issues now. The primary issue is how the player will enable the multiplayer mode. We can provide the player with a menu option for inviting other players for the multiplayer mode. This can be enabled by providing him facility for searching bluetooth devices near his phone. You can use the DiscoveryAgent class for this purpose. Then you can use the L2CAP API for creating connections between devices. For multiplayer games we will have to create bi-directional connections. The device of the player that has invited others can become the server for the purpose of communication in our multiplayer game. The following is the pseudo code for opening a server and client connection respectively through the use of L2CAP protocol: try { L2CAPConnectionNotifier myServer = (L2CAPConnectionNotifier) Connector.open(“btl2cap://localhost:3B9FA89520078C301355AAA694238F06; name=L2CAPskj”); L2CAPConnection myCon = (L2CAPConnection)myServer.acceptAndOpen(); }
try { L2CAPConnection myClient = (L2CAPConnection) Connector.open(“btl2cap://0050CD00122B:1001;ReceiveMTU=512; TransmitMTU=512”); } After opening the connections we should start the game canvas for all the players. For a multiplayer game to be of any use synchronization of important game variables will have to be done. This can be made possible by synchronizing after a pre-determined interval. We will have to make provision for both receiving and sending of data. The latency for bluetooth connections is quite low but still we will have to factor scenarios which may arise in case the data is not synchronized on time. Therefore game action should be developed keeping in mind such problems that may arise. Another important point in synchronization will be screen movements. How will the screen movement be anchored? Will it be based on the players, any one player or a neutral variable? The impact of change in game lifecycle of one player on another player will also have to be kept in mind. For example in a two player game one player may loose a chance while the other player is still alive. In such situations we should make sure that the game does not stop for the other player. In fact you could see console games for some guidance. Generally consoles support 2 player gaming. They can be of help while thinking about multiplayer bluetooth enabled games. Lastly we will talk about the messaging enabled multiplayer games. Such games are very few and have not become popular because of the cost involved for the user every time a message is sent. Still we will shortly discuss this topic. Since messages take time to travel through the network we cannot have fast multiplayer games through them. Such games will have to be limited to the likes of a Chess or TicTacToe game. The good thing is that the SMS and MMS rates are falling. Also type’s games can be played in peer to peer mode over long distances. Some of the issues that you will encounter during the development of this kind of games are similar to bluetooth enabled multiplayer games. Some of the other differences are with regard to synchronization. The first issue is that you will encounter latency in the order of minutes. Thus only mind games are left within the domain of this kind of games. The other issue is that we will have to use either JSR 120 for SMS synchronization or JSR 205 for MMS synchronization. In both the cases it will be good to warn the players of the costs involved in sending messages. One good scenario where messaging can be incorporated is of challenging the other mobile phone users to beat the high score of the current player. When the people who had been challenged are able to pass that high score an SMS or MMS is returned back to the challenger with a new challenge for the original player. This way even action games could be made more entertaining by the use of messaging technology. |
Mobile Technology > Java ME (J2ME) > Book - Mobile Phone Programming using Java ME (J2ME) > UNIT V >