Tài liệu MIDP Game API ppt

MIDP Game API Khanh Le Introduction  Game applications have proven to be one of the most popular uses for Java 2 Micro Edition, so a dedicated Game API is provided in Mobile Information Device Profile version 2.0 to facilitate game development.  This API provides several benefits to the game developer.  First, it simplifies game development and provides an environment that is more familiar to game developers.  Second, it reduces application size and complexity by performing operations that would otherwise be implemented by the application.  Third, because the API can be implemented using native code, it can also improve performance of the frequently used game routines.  As with the low-level user interface APIs, applications that use the Game API must be written carefully in order to ensure portability. Device characteristics such as screen size, color depth, and key availability must be accounted for by the developer if application portability is desired. The GameCanvas API  The Canvas class was designed for applications that are event-driven; that is, the user interface is updated in response to a user input, such as selecting an option or pressing a soft key.  However, game applications are generally time-driven and continue to run and update the display whether or not the user provides input.  To overcome this difference, the GameCanvas class provides a game-centric model for accessing the display and checking for key inputs The GameCanvas API  Game applications typically employ a single thread to run the game. This thread executes a main loop that repeatedly checks for user input, implements logic to update the state of the game, and then updates the user interface to reflect the new state. Unlike Canvas, the GameCanvas class provides methods that directly support this programming model. Key Polling  The GameCanvas class also provides the ability to poll the status of the keys instead of having to implement callback methods to process each key event.  Key polling allows all of the application's key handling logic to be coded together and executed at the appropriate point in the game loop. It also enables simultaneous key presses to be detected on devices that support them.  The getKeyStates method returns the key state in the form of an integer value in which each bit indicates whether a specific key is pressed or has been pressed since the last invocation of the getKeyStates method.  This latching behavior allows very quick key presses to be detected even if the game loop is running fairly slowly. If the current state of the keys is desired without the latching behavior, the getKeyStates method can be called twice. Key Polling  To determine whether or not a specific key is pressed, the integer value is AND-ed with one of the key polling constants defined in GameCanvas, as shown in the following example: int keyStates = getKeyStates(); if ((keyStates & UP_PRESSED) != 0) yPosition ; if ((keyStates & DOWN_PRESSED) != 0) yPosition++; if ((keyStates & FIRE_PRESSED) != 0) fireRocket(); Screen Buffer  Unlike Canvas (which shares screen resources with other applications), each GameCanvas object has its own dedicated screen buffer, which the developer can draw on at any time using a Graphics object. Graphics objects are obtained by calling method getGraphics. Multiple Graphics objects can be created if desired.  Changes to the screen buffer contents are limited to rendering calls made by the application, so the buffer can be updated incrementally instead of being completely rendered for each frame.  Synchronous methods are provided for flushing the contents of the buffer to the physical display, so continuous animations are much easier to implement than with the asynchronous repainting model of the Canvas class. The flushGraphics methods flush the contents of the buffer to the physical display, either for the entire buffer or for a specific region of the buffer. These methods do nothing if the GameCanvas is not currently shown. Layers  The Layer class is an abstract class that represents a basic visual entity that can be rendered on the screen. A Layer has defined rectangular bounds, and it can be either visible or invisible. A Layer can be rendered using any Graphics object by calling its paint method.  The game API defines two Layer subclasses: Sprite and TiledLayer. Unfortunately, class Layer cannot be directly subclassed by the developers, since this would compromise the ability to improve performance through the use of native code in the implementation of the Game API.  Subclasses of class Layer can be drawn at any time using the paint method. The Layer will be drawn on the Graphics object according to the current state information maintained by the Layer object (that is, position, visibility, and so forth.) The Layer object is drawn at its current position relative to the current origin of the Graphics object. Erasing the Layer is always the responsibility of the code outside the Layer class. Sprites  A Sprite is a basic visual element whose appearance is provided by one of several frames stored in an Image. The developer can control which frame is used to render the Sprite, thereby enabling animation effects. Several transforms such as flipping and rotation can also be applied to a Sprite to further vary its appearance. As with all Layer subclasses, a Sprite's location can be changed, and it can also be made visible or invisible. Frames  The raw frames used to render a Sprite are provided in a single Image object, which may be mutable or immutable. If more than one frame is used, they are packed into the Image as a series of equally-sized frames. The frames are defined when the Sprite is instantiated; they can also be updated by calling the setImage method.  The same set of frames may be stored in several different arrangements depending on what is most convenient for the game developer. The implementation automatically determines how the frames are arranged based on the dimensions of the frames and those of the Image. The width of the Image must be an integer multiple of the frame width, and the height of the Image must be an integer multiple of the frame height. [...]... Simple Game  Note that this code example is simplified to demonstrate the use of the game API; a real application would require additional code to appropriately handle application starting and pausing, game restarts, displaying the score, multiple levels, and so on  See SimpleGame project Mobile Game Development Process  There seems to be no one simple solution to developing a game  Because the games... brief You can have a game with long-term goals However, the game must still be able to be successfully played in short bursts and be interrupted at any time Allow the user to pause and resume the game at any time with little or no effect on the game' s progress Design  Catering to Your Audience     The audience for mobile games is not necessarily the same as that of console or PC games People do not... of the Graphics object For example, if a game uses the top of the screen to display the current score, the view window may be rendered at (0, 12) to provide space for the score layerMgr.paint(g, 0, 12); Collision Detection  Collision detection is a key feature of the Game API, enabling the developers to quickly and easily determine whether two elements of a game have collided or not  The collision... only when opaque pixels are touching false     Sample Code: A Simple Game how the APIs discussed in this chapter can be This example illustrates used to form a simple game The user controls a car that is always moving forward at a constant speed and can be turned 90 degrees clockwise or counterclockwise The object of the game is to drive around the track and collect as many coins as possible without... programming are just two of the overall elements involved in creating a completed game, with mobile gaming that is about 99% of it  But in traditional game development there are management concerns, work flow, tool creation, and a host of other issues  Asset Creation   In the game industry, an asset is defined as any element of the game that is plugged into the engine for the creation of content Usually... console or PC games People do not buy phones to play games Duplicating what is successful on consoles and PCs does not necessarily equate to a successful mobile game Once this market matures, we will be able to see a pattern in mobile gaming tastes It is entirely up to you Ultimately, the players will determine if they like it or not Development  The term "game development" encompasses a lot more than just... or PC title can have a development time of 18 to 36 months With a mobile game, it is often reduced to 1 to 3 months Design  Ideas come from anywhere The real value in a design is the implementation  Whether your game is fun or not is up for the players to decide  Catering to the Platform    Creating a design for a mobile game is totally unique The first thing to take into account is length of... are always contiguous; that is, if a Layer is removed, the indices of subsequent Layers will be adjusted to maintain continuity  The LayerManager class provides several features that control how the game' s Layers are rendered on the screen The size of the view window controls how large the user's view will be, and is usually fixed at a size that is appropriate for the device's screen LayerManager . MIDP Game API Khanh Le Introduction  Game applications have proven to be one of the most popular uses for Java 2 Micro Edition, so a dedicated Game. difference, the GameCanvas class provides a game- centric model for accessing the display and checking for key inputs The GameCanvas API  Game applications