Unit 20 -Assessment 3 : Developing a Blackjack game for mobile & web
Task 1) Mobile Gaming
Show how this game can be converted into a mobile game to work on either a iPhone (5/6) or a high spec Android phone (using 5 inch display min).
The HCI needs that a Android / iPhone game game has against a Windows game.
- Sprite / room re size to fit a display - Layout and look of the game
- In order for the game to be accurately ported across to a phone and for it to retain it's graphical layout, consideration must be given to how the game will fit onto a smaller sized screen. As the game HUD must make sense to the player, and for each individual element to be retained, the room, sprites and objects need to be sympathetically spaced in order to accurately retain the games larger WIndows PC counterpart. When building for the mobile game, I will need to consider the available screen size and resolution.
- Consideration of appropriate music file formats
- If developing for an Android phone, I need to consider what file formats are accepatble on the device. Choosing the wrong file format could create a lesser experience for the player, or worse still break the game entirely.
- The way that a user interacts with the game (HCI)
- This is a vital consideration when considering how the user will play the game. Things that I need to take into account include whether the user will touch, tap or flick the screen to play. From an initial estimation, the user will have a choice of four buttons that they will have to interact with - 'Hit', 'Stick', 'Start' and 'Restart'. As the Windows PC counterpart requires the user to click on these with a mouse, the answer will be to use virtual, invisible keys. These should create the same effects from touching them with fingers as they would from clicking them with a mouse. A foreseeable problem is having them appear on screen out of sync with the graphics due to how the game has been resized and displayed. By this I mean that the user should tap a clear graphic cue on screen and the virtual key should ideally be directly overlaid on the top of this. If it is off centre or askew, the registration of the key tap may not be immediate.
Specifications of the test Android phone that I intend to work with:
Samsung Galaxy S II GT-i9100
Screen size: 93.8x55.3mm
Screen resolution: 480x800
CPU: Dual-core 1.2 GHz Cortex-A9
GPU: Mali-400
Operating system: Android OS, v4.1 (Jelly Bean)
For the purposes of this task, the above phone should be more than adequate. The screen size is of a good standard and the CPU / GPU should be easily able to handle the graphics and sound.
However in terms of predicting problems, I estimate the following:
On screen graphics elements such as the player icons may need to be removed in order to create less clutter. I will have to see how it looks onscreen, but this is certainly a possibility.
Sound file formats may need to be researched - if the MP3 format I intend to use turns out to be wrong, I will need to find another.
Game Maker GML coding to address the issue of the difference in screen size.
Re sizing the screen or room to fit an application's display
I will almost certainly need to resize the game room from it's Windows PC size of 1024 x 600 to well under half that (I estimate 480 x 300 pixels). The same goes for all instances of sprites and objects - they will need to be significantly smaller. However, I have discovered that there is a GML command that may do much of the repositioning work for me:
The Draw GUI EventThe Draw GUI event in Game Maker falls under the category of Draw Events and is for the use of drawing Graphical User Interface elements that are not affected by the viewing scale or position. This means that with one instance of the Draw GUI event, all of the elements that you need for your HUD can be drawn without you having to base all their positioning on the position within the room.
Example - If I draw a health bar on a scrolling platform game, it will remain in the same place on screen even when the screen scrolls in the view port. It's position is set independently to the other objects in the room. It will move with the view.
There are a number of things that the developer must also bear in mind:
- Depth ordering is maintained between different instances - some instances will still appear above others.
- Additionally the objects HUD elements will drawn will not be dependent on the view position either. The co ordinates of the drawn instances will not change even when views are active. The top left hand corner is always set to 0,0 regardless of what application the Game Maker game is appearing on.
- The default width and height are 1:1 with the application surface. This event will, by default, draw 1:1 with the application surface size, which is normally the size of the room or the view port.
This means that when you have Aspect Ratio Correction on in the Global Game Settings the GUI is not going to be drawn over the black bars that "letterbox" the game.
This behavior can be switched off using the function:
display_set_gui_maximise
You can also lock the GUI event to a specific size which will then be scaled to fit the display or application surface dimensions automatically by using the function:
display_set_gui_maximise - .The Draw GUI Begin event will draw for all instances first, then the standard Draw GUI will draw for all instances over that, and finally the Draw GUI End event is triggered.
Re sizing the sprites to fit an application's display
The secret to this lies in the initializing of the Draw GUI event. Without a certain GML command, the HUD elements and sprites will not scale in relation to the view port. The way that we can get the elements to re size is by adding this in the Draw GUI create event:
display_set_gui_size(x_resolution,y_resolution);
Here I have written x_resolution and y_resolution as if they are global variables. The values of these variables would be the x resolution and y resolution of the room view for example 640 x 360.
To reiterate the difference:
The view is how many pixels it takes up in your game (screen resolution).
The port is how large the available playing area is on screen.
Altering controls for how the game plays on a given platform.
The target application for a game may require a different user interface to a Windows PC. Windows PC games use mouse and keyboard commands as this is the standard for navigating around the screen and interaction. Touchscreen devices use a different method - as user input commands are carried out via thumbs and fingers, invisible virtual keys will need to be put into place. Upon touching these virtual keys, similar inputs and interactions can be carried out as they would with mouse and keyboard.
Virtual keys can be created in game maker with the following code syntax:
virtual_key_add(x, y, w, h, keycode);
Argument Description
x The x coordinate (left side) of the virtual key on the screen
y The y coordinate (top side) of the virtual key on the screen
w The width of the virtual key
h The height of the virtual key
keycode Which keyboard key event should be triggered by touching this area
In short, the virtual key command allows the user to map various areas of the screen to keyboard events.
Interestingly, from a developer point of view, virtual keys can also be used to show, hide and delete variables. Game Maker automatically removes these keys when changing rooms.
The position of virtual keys is related to the screen position rather than the room position, so the x/y values are absolute on the screen.
Virtual keys and any sprites associated with them can be defined in the Draw GUI event of an object.
Example:
global.Left = virtual_key_add(32, 32, 64, 64, vk_left);
This will create a 32 x 32 square positioned on x 64, y 64 on screen. On pressing it, the player will go left.
The first step towards building an Android game on Game Maker is to download and install the Android Development Kit (called Android SDK). It is also a requirement that the user installs the Android NDK (Native Development Kit).Example:
global.Left = virtual_key_add(32, 32, 64, 64, vk_left);
This will create a 32 x 32 square positioned on x 64, y 64 on screen. On pressing it, the player will go left.
Game Maker and Android
Before the developer can begin to build and test a game, it is advised that they take certain steps to make sure Game Maker and the Android device can communicate correctly. Game Maker works with by default with Android 2.3, and above which covers most of the devices that are in use at the moment.
Before the developer can begin to build and test a game, it is advised that they take certain steps to make sure Game Maker and the Android device can communicate correctly. Game Maker works with by default with Android 2.3, and above which covers most of the devices that are in use at the moment.
Finally, the user will also have to install the JDK (Java Development kit) since this is the scripting language that enables Android and Game Maker to communicate. After installing all of these development kits, we can turn to setting up a device for Android.
Installing the Android SDK
- Run the Android SDK installer. The developer will be asked to install the Android SDK to the path "C:\Program Files (x86)\Android\android-sdk". It is strongly recommended that the developer chooses something with no spaces in the path, such as C:\android-sdk\, as the default path can cause problems with the actual Android updater program itself.
- Once the developer has successfully installed the Android SDK they will be given the option to start the Android SDK Manager. They must do this, as it will install additional tools and device specific functions. When it starts they should select only Android SDK Platform Tools, Android 2.1 (API 7), Android 2.2 (API 8), Android 3.2 (API 13), Android 4.0.3 (API 15), as well as the most recent version of Android (selected automatically by default by the manager). They should not just select everything to be installed, as this will a) needlessly waste their bandwidth and HDD space, and b) might cause conflict errors during builds.
- It should be noted that after installing these files the Android Download Manager may inform the developer that there are other files to be installed and that they should close and prelaunch the SDK Manager.
- It is advised the developer checks the revision details and confirms that they don't already have the selected update installed. They should also set the PATH variable to allow them to run the command line tools.
Upon successful installation, the Android SDK should look like this:
Setting up Game Maker for Android use
Once the Android SDK is correctly installed, launch Game Maker Studio and do the following:
- Enter your License Key
- Create a new Project
- Select File > Preferences > Web Server
- Web Server Port: This is set to 51268 to 51280 by default. There is no need to change this unless these ports are already in use
- IP Allowed List: Enter your local IP address range in the format xxx.xxx.xxx.0/24. For example: 192.168.1.0/24
Device Setup For Android
It is essential that the Android device (or devices) that the developer is using with GameMaker: Studio are configured to work properly with the software. Below are the steps to follow to ensure that there are no problems:
Enable USB Debugging
On the user's Android device, browse to Settings > Applications > Development and enable USB Debugging.
Connecting the device
Connect the Android device to the PC via the data cable.
The device drivers should be installed automatically at this stage (if they aren't already), but if they are not, the developer should refer to the device manufacturer's support information to locate and install the correct ADB drivers. It is very important the developer gets ADB drivers, not the standard consumer ones.
Note: The ADB driver stands for 'Android Debug Bridge'. It is a command line tool that allows the user to communicate with an Android device or emulator. It is a client-server program that consists of 3 components :
- A client, which runs on a development machine.
- A server, which runs as a background process on the development machine.
- A daemon, which runs as a background process on each emulator or device instance.
Now test the phone driver to confirm if it's correct.
If the developer has already set up the PATH variable as mentioned above, simply Windows Key and R to open a new Run window and type "cmd" (no quotes) and hit enter, then type "adb devices"
Go to the Android install folder and then the "platform-tools" folder inside it (e.g., C:\android-sdk\platform-tools) and then hold down the shift key and then right-click in some empty space and choose "Open a command window here". In the new command window, type "adb devices" (without the quotes).
After installing all of these applications on your PC that runs Game Maker, we can now turn to that particular program itself.
On Game Maker, take the following final steps to prepare development for Android:
- Open File > Preferences > Android
- Make sure Android device is connected to PC via USB cable
- The screen should look like the following screenshot:
The first 3 fields should have filled themselves in automatically.
The next step is to create the private Keystore by click the 'Keystore' tab, which can be seen on the left in the screenshots. The Keystore is a file that will be used to 'sign in' all Android devices. Is is advisable that the user fills in this file correctly and then backs it up by making a copy. The Keystore file will require the following information:
- Name - this is the filename of the Keystore (note : Not your name or the company name!)
- Password - your security password for the Keystore file which must be at least six characters long.
- Alias - this is the name of the "user" for this Keystore and can differ from the Name field above.
- Password - the same password as written in the Password field two above. This is a long-time Android SDK bug.
The right-hand side is optional and has no relation inside GameMaker: Studio, but it is recommended to fill it in anyway.
- Common Name - this would normally be the developer's name
- Organisational Unit - the department within the company that the developer is in
- Organisation - the name of the developer's company
- Location - the name of the town or city where the developer is based
- Country - the two letter code for the country where the user is based.
Once you are happy, click 'Generate' for Game Maker to generate your Keystore file.
Testing the game
Once the developer has completed these steps, it is a simple process to test a Game Maker game on an Android device. The first step in this process is to make certain that the Android device is connected to the development PC running Game Maker, either by USB cable or WiFi.
To connect via a USB data cable
- Make sure that the all of the above steps have been taken and the device is connected by a USB data cable.
- Click the green play arrow at the top of the Game Maker window to compile your game.
- Once the compile is complete, the game should appear on the Android device as designed.
To run via a WiFi connection
To test the game on an Android device with a WiFi connection, the developer will need to make sure the YoYo games runner is installed on the device. According to the YoYo games online documentation, this can only be achieved via a data cable connection. This means that the developer must follow the 3 steps data cable connection at least once before any WiFi connections will work. The runner is basically a small program that can interpret data that is sent to it via wireless connection. With success, the Android device can then run the game.
Once the runner is installed and working:
- Make sure that GameMaker: Studio is correctly configured
- Click the Green play button at the top of the main GameMaker:Studio window to compile your game
- When compiled, tap the YoYo Games Runner on the device and you will get the "connecting" window. Your game will now run as normal, unless this is the first time you are running the WiFi mode, in which case the user should also follow the next steps too:
- When the YoYo Games Runner starts up there is button marked Settings. Tap that button to open a new screen with two further options.
- You should set the GM:Studio IP Address to the one that your computer is currently using. If your network supports name resolution you can use the PC's name and avoid issues with the IP changing later.
- You should set the GM:Studio Port Number to match the one that you setup in GamneMaker: Studio Basic Setup (this is 51268 by default)
How I implemented these factors into my game
The addition of virtual keys was a simple task. I just added this into the 'Create event' in the 'obj_controller' instance of my room. 'obj_controller' is an ever present object that is there when the room first loads. That way, when the room loads, the virtual keys instantly appear within it, meaning the player can interact straight away. Here is a screenshot:
As you can see, I added in vk_left to the keycode. I also made sure to add this second key command into the bulk of the game code. For example, where an event was triggered by using mb_left (left mouse button), I made sure to tell the game that I wanted the same event to be triggered if a virtual key was pressed.
In terms of sound, my initial instinct was correct. MP3's are the most appropriate file format for an Android phone.
In terms of resizing, you can see how the game HUD is quite spacious anyway, with an emphasis on the cards and scores, rather than large superfluous graphic elements. With this in mind, you can see from these screenshots how the game will translate from PC monitor screen to mobile phone:
 |
| Original screen layout on a Windows PC |
 |
Blackjack game as it would appear on an Android phone
I found that the sprites for the 'Stick' and 'Hit' buttons needed to be bigger, and as such I needed to increase the size of the virtual keys. This is so people's thumbs and fingers could trigger the events easily without having to fumble around on the screen.
Task 2) Web Gaming
Creating a game for play in a web browser rather than a mobile is a significantly easier task.
To achieve this the developer will need the Professional Edition of Gamemaker Studio. From here, the developer should change the “Target” from “Windows” to “HTML5”.
In order to create my game for the web, I followed these simple steps:
- I firstly right clicked on the GameMaker Studio icon
- I then clicked Properties > Shortcuts > Open File Location
- I click Apps and then pick Gamemaker Studio: Education (Professional Edition)
- I click “Target” then change “Windows” to “HTML5”
- I then click the “Create Target Executable” button
- This should bring up a “Save Folder”. It makes sense to create a folder with a relevant, sensible name such as "web_game".
In this newly created folder the developer is given three files - HTML5GAME, FAVICON and Index (a similar file structure to a website). These folders hold the complete game and provide the option to open it in a web browser. By right-clicking “Index”, the developer is given several options but the option needed to open up the game on different web browsers is “Open with”.
By clicking this the developer is given the option to open their game with a different web browser. These browsers include Internet Explorer, Google Chrome and Firefox.
Pros and cons of browsers in conjunction with Game Maker games
I ran some small tests to decide what browser I should develop for and discovered a number of pros and cons:
I ran some small tests to decide what browser I should develop for and discovered a number of pros and cons:
Internet Explorer
This browser is somewhat antiquated and not really designed for use with Game Maker games. The developer can expect to encounter the following:
- Scripts only being allowed to run via the user clicking 'Allow blocked content'.
- A black background outside of the game area.
- A warning message that advises the user of problems with files colours etc.
- Poor graphics quality when the game is running. Sprite displays are noticeably worse.
- Sounds encounter problems as Game Maker uses Web Audio. This is not a format that IE can easily interpret or understand, leading to problems.
All of this severely diminishes the user experience of playing the game. I have discovered that Google Chrome is better in some respects and just as bad in others
Google Chrome
- Scripts only being allowed to run via the user clicking past a Javascript alert
- A black background outside of the game area.
- A warning message that advises the user of problems with files colours etc.
However....
- Unlike IE, Chrome is better at running games and the speed it processes the scripts at is far faster. This is because Chrome and Firefox are designed with web games in mind.
- Accepts MP3 files as a sound format. This is a lesser quality than other file formats such as WAV, but will work nonetheless. Google Chrome can play back WAV formats, but a plug-in is required. MP3s are more commonly supported across browsers, making them a good choice.
Firefox
- Scripts only being allowed to run via the user clicking past a Javascript alert
- A black background outside of the game area.
However, unlike Chrome and Internet Explorer:
- The game displays much larger, so is visually more eye catching
- The game runs the best due to Firefox being designed with web based games in mind.
I felt that Firefox offered the best choice as a web browser platform, so I will attempt to
develop a finished version of the game for that. As it will be mouse driven, their is no need to
input virtual keys.
develop a finished version of the game for that. As it will be mouse driven, their is no need to
input virtual keys.
Task 3) Publishing the game onto both platforms
Although my game is buggy and unfinished, this is how I intend to publish the game on both mobile and web:
Game published on Web:
To publish my game onto a web platform, I will select the highlighted button within GameMaker. This ‘Create an application’ tool will allow me to create an application that, when opened, will run my game through Firefox.
The above mock up screenshot shows how I expect my game to look running through Firefox on my Mac.
Game published on Android:
To publish my game onto an Android device, I will use the same ‘Create an application’ tool that I would use to publish my web based game. I must make absolutely sure that I have connected my Android device via USB cable. All being well, the game will upload onto the Android phone.
No comments:
Post a Comment