Mobile Game: User interface

User Interface
This blog entry shall cover the user interface component of the racing simulation game that my team is developing as Galactic Games first foray into mobile games development.

As noted in my previous blog posts, the game we are developing is a port of an existing racing simulator for the PC platform. My team is porting the game to the Windows Mobile platform as an offering for both Pocket PC and Smartphone devices.

Input
The PC version of the game allows the player to control the game via a joystick or keyboard combination. Menu selection and navigation can be achieved via the joystick (if connected) or mouse.

For the mobile game port, the game input method is via hardware keys that are found on all Windows Mobile devices, as part of the platform hardware specification. Six buttons are required (left, right, forward, reverse, brake, accelerator) and the actual configuration of the buttons can be assigned by the user from default. The user may use control menu selection and navigation via the touch screen and/or hardware buttons. We will simplify the game menus from 6 main menus and 32 submenus down to 3 menus, 12 submenus for the mobile game version. With a simplifcation of the menus, the number of game options and configurable items will also be reduced in line with an overall simplifcation of the game.

Display
For the PC version, the game runs in full-screen mode at the highest resolution that the PC the game is running on can sustain. For most PC's this equates to a resolution of 800x600 or higher.

The highest resolution Windows Mobile platform available is 640x480, with the bulk of devices being 320x240. To cater for the lower screen resolution, the game engine programmers have been instructed to modify the engine to check the device resolution and scale the graphics to suit. The game will run in full-screen mode, with the option of being presented in landscape or portrait format.

Sound
For the Windows Mobile version of the game, all existing sounds will be carried over as both WAVE and MP3 formats are supported. In most cases, the sounds will be converted from stereo to mono, in order to reduce their size and reduce demand on the CPU during playback.

Mobile Game: System design - The game character(s)

The Game character(s)
Short entry this time around, not much to discuss in regards to game character because the game under discussion is a racing car simulation!

Throughout the game the user plays as Rick Johnstone, Formula 1 car racing champion. Rick won the world champsionship 3 years ago, but subsequently had a serious racing accident and was forced onto the sidelines for the past 2 years.

Rick is now on the comeback and hopes to win another world champsionship. The player gets to race as Rick in a number of races located around the world during Rick's bid to become world champion for a second time...

Mobile Game: System design - The game world

Introduction
Greetings, in this blog post I'm following on from my series of posts on my development teams progress in designing our first mobile device game. In this post, it is my intention to discuss system design of the game world.

Game World
The game world for the car racing simulator can be broken down into the following elements:

• Key locations: Famous car racing circuits located throughout the world
• Scale: As close to 1:1 mapping between real world racing circuits and the reconstructed game versions.
• Objects: The world will contains as many object as possible to simulate a real racing circuit as possible taking into account the reduced memory and display capability of mobile devices. Objects can include: Spectator grandstands, Overhead billboards, Track markings and so on. The level of detail and textures used needs to be scaled for the mobile device.
• Day or night: All races will be conducted in a daytime setting.
• Redering: The game shall utilize a 3-dimensional rendering engine.
• Camera: The camera view will be in a fixed position slightly above and behind the race car driver position. We have elected to keep the camera in a fixed position to keep processing during scene rendering as low as possible.
• Game engine: The game enginer programmer in the development team is responsible for porting the game engine used in the PC version of the product to the Windows Mobile platform. The engine is a custom in-house developed platform written in C++ for DirectX.
• Game lighting: A simplistic 3d lighting model using basic DirectX effects shall be used as complex effects are not support on the Windows Mobile DirectX implementation.

Mobile Game: System design - Game overview

Introduction
In my previous blog post (Mobile game system design platform) I outlined the decision my design team had made on selecting Microsoft Windows Mobile as the target platform for the companies first mobile computer game. This blog entry is a follow on post in which I intend to provide an overview of the game that we intend to produce.

Game Overview
For our first mobile game, we have decided to do a port of an existing DirectX game that was developed approximately 2 years ago for the PC platform. The primary reason behind this decision is that we can utilize completed PC software and game assets, with the majority of the effort being modification of these components to suit the mobile platform. It is my opinion that the team has made a good choice because it allows us to developer a game for mobile device and gain experience doing so, without having to invest in a significant amount of time in a full game development cycle by using source code and assets from an existing game.

Here are the key details of the game in point form:

1. Type: Car racing simulation.
2. Environment: First person, 3-dimensional perspective.
3. Objectives: Win race (single race and career mode), Time trial and Obstacle course.
4. Playing style: Single player, local mode. Multi player via network (High speed networks only: i.e. 802.11 a/b/g or Bluethooth).
5. Input method: Hardware buttons on mobile device (4-way directional pad, plus 2 seperate user assignable buttons for accelerator and brake functions)

Mobile Game: System design - Platform selection

Introduction
Following on from my previous reflective blog entry that covered the development team's collective thoughts on mobile game development, I'm beginning a number of blog posts that cover system design of the game. The standard company process for system design is to create a system design document that is based on a modified template produced by Chris Taylor. I will attempt to cover the key points of that system design document here in this blog as a mirror of the team effort to produce the document.

Platform selection
Selection of device and programming platform is a major consideration for our team due to the fact that the company has specialized in development of games for PC's and consoles. The game and engine programmers in the team all have DirectX and Windows development experience.

In reaching a decision, the team has decided to propose that we develop our mobile game for the Microsoft Windows Mobile platform. It has been recognized that this is not the dominant platform, but the following considerations have made this the best choice for us at this point in time:

1. Windows Mobile platform supports DirectX[2]: We have a significant investment in DX development and can thus realize a reduced time-to-market for the game relative to the same development being performed on a different platform (learning curve, education, purchase of new toolsets, etc.).
2. Windows Mobile devices, in general, have a higher hardware specification than equivalent devices from Symbian aligned manufacturers[2]. This allows us to develop a richer gaming experience with either 2d or 3d scenes, with larger screens, more detail and colors.
3. Established marketplace: A number of online distribution channels (i.e. AvantGo) exist as a mechanism for publishing and selling the game. As a game company we already have a publisher for our products, but in the event that we wish to sell directly to the market it is reassuring to know that existing sales channels are available.

References
[1] Taylor Chris, Design Document Template, http://www.ihfsoft.com/designdocuments.htm
[2] Wilson Frank-Lee, Graphics with DirectX in Windows Mobile 5.0 Games, http://msdn2.microsoft.com/en-us/library/Aa454886.aspx

Mobile Game: Useful links

Useful links:
Short blog post this time around. I've collated a number of useful mobile game development links for reference. Team members, if you find other useful links, please add them to this blog post as a reply.

http://www.developer.com/java/j2me/article.php/3502741

http://www.igda.org/mobile/

http://www.oreillynet.com/pub/a/wireless/2002/11/14/game_dev.html

http://www.wirelesspronews.com/2003/0701.html

http://www.javaworld.com/javaworld/jw-11-2003/jw-1107-wireless.html

http://msdn2.microsoft.com/en-us/library/Aa454886.aspx

Mobile Game: Initial entry

Game design reflections

Introduction:
The team attended the Mobile Games developers conference yesterday. It was an interesting event and for the team, we learnt a lot about the nuances, traps and limitations of developing games for mobile devices. The positive part about mobile games development is the revenue potential, it would seem that the worldwide gaming audience for this platform is set to explode. Chauhan[1] predicts there are likely to be an audience of up to 220 million gamers worldwide. The remainder of this blog entry is an attempt to reflect upon the team's findings at the conference and also to document the decision making process behind our game development proposal to management.

Platform:
Whether the platform is Symbian or Microsoft based, there are some considerations that a game development team need to take in account when developing games for a mobile device. Members of the panel discussed these limitations and referenced an article by Fox[3] and Lam[4] as a basis for the points raised. Some of the crucial factors covered in the articles and expanded during the panel discussion were:

• Small amount of program memory (RAM) and storage memory (EPROM / FLASH)
• CPU with limited floating point performance.
• Display with typically 100 x 100 (small) through 320x 240 (large) pixels. Limited number of colors on base model devices.
• Limited or no sound capabilities.

Development on each platform also varies. For example:

• Symbian based phones from most manufacturers generally support J2ME (Java 2 mobile edition).
• Microsoft based devices can be programmed using C, C++ or a .NET based language (VB.NET or C# [managed C++ is not supported yet])

User interface:
Korhonen[5] was cited during the panel discussion for the study he produced that contains a number of game user usability heuristics that are essential to good mobile game development. I have repreated some of the more general game heuristics here for good measure and added a number of key mobility ones which are extremely useful to our team, given that we have no mobile game development experience:

Game usability:

• Screen layout is efficient and visually pleasing
• Device UI and game UI are used for their own purposes
• Indicators are visible
• The player understands the terminology
• Navigation is consistent, logical, and minimalist
• Control keys are consistent and follow standard conventions
• Game controls are convenient and flexible
• The game gives feedback on the player's actions
• The player cannot make irreversible errors
• The player does not have to memorize things unnecessarily
• The game contains help

Mobility:

• The game and play sessions can be started quickly
• The game accommodates with the surroundings
• Interruptions are handled reasonably

Game type:
Game types on mobile devices was also covered during the panel discussion. Obviously the platform plays a big factor in the type of games that can be realized (for example: Some platforms may have support fo 3d graphics), but in general, mobile game types can be categorized into three main groups according to Chauhan[1].

• Embedded games - Hard coded into the mobile (i.e. "Snake" in Nokia phones).
• SMS games - The games mode via SMS, sending test messages between games server & client. The cost of the games will increase when each SMS sent to server. (For example: Zork via SMS or a city tourist trail via SMS.)
• Browser games - Today's the most popular type, due to the games provide multimedia-rich and lower cost of gaming than SMS games. Using the mobile built-in net browser, playing the games online through games web site, or it can download for offline gaming.

Conclusion:
Overall, we learnt a lot from the Mobile Developers conference. This blog entry has been an attempt by me, as team leader, to chronicle the team's learnings from the conference. The team has been developing games for a while now, but not on mobile devices, thus we attended the conference with an open mind in order to learn "what it takes" to develop games, potential game types, typical audiences and revenue streams for mobile games. The next set of blog entries shall be based of the findings documented here and will reflect the system design of the first mobile game project step-by-step prior to submission to management for approval.

References:
[1] Mugdha Chauhan, Developing Java-Based Mobile Games, http://www.developer.com/java/j2me/article.php/3502741

[2] Attewell, J 2006, Mobile technologies and learning: A technology update and m-learning project, http://www.lsda.org.uk/files/PDF/041923RS.pdf

[3] Fox, David 2002, Developing Cutting-Edge Mobile Games, http://www.oreillynet.com/pub/a/wireless/2002/11/14/game_dev.html

[4] Lam, Jason 2003, Consideration for mobile games development, http://www.wirelesspronews.com/2003/0701.html

[5] Korhonen H., Koivisto E. M. I 2006, Playability heuristics for mobile games, September 2006 Proceedings of the 8th conference on Human-computer interaction with mobile devices and services MobileHCI '06, ACM International Conference Proceeding Series; Vol. 159

[6] Liljedal, A 2002, "Design Implications for Context Aware Mobile Games", Uppsala University, Sweden, http://www.tii.se/mobility/Files/Master%20Thesis.pdf.

Note:
To Ken - As we have used a previous student group NAD due to not having a large enough class to run our own, I have approached this differently to give it a unique feel. My scenario utilizes the supplied NAD document within the context of being a panel discussion held at a Mobile Games developers conference. The entries within the NAD comprising the opinions, statements and facts presented by participants and the audience during the themed panel discussion covering development of games on mobile devices.