If I want a game to run on all platforms
Monkey Forums/Monkey Programming/If I want a game to run on all platforms
| ||
| what are the rules? |
| ||
| Your question is too vague. |
| ||
| Rules? There are no rules!!* *there may be rules |
| ||
| I ment If I make a game for HTML5 for example will the code be suitable for all platforms. I understand that my quastion is vague. maybe there is no clear answer for that. |
| ||
| Hardcoal, it sounds like you're learning quite a lot quite quickly. If I were you I wouldn't worry about it too much. Make your game for HTML5 and then worry about other things later. |
| ||
| :) sure thing. good point. |
| ||
| Short answer, it depends on how you have coded it and your resources. It will probably run. But there are differences in the sound department, input and screen resolutions. |
| ||
| Well the whole point of Monkey I feel is that you should write the code once and it should work on all targets. Of course there are a few little hiccups like different sound formats, different graphics resolutions and different methods of inputs etc ;) |
| ||
| I see, so its 90% precents compatible minus few changes that must be handled |
| ||
| There's a difference between the code running on all platforms and the game working well on all platforms. Anything written in Monkey without messing with native implementation should run on every target but that doesn't mean that the game will be playable. The "rules" for creating something that works well across the platforms would be more about game design than technical points about Monkey code. I'd agree with therevills that display properties and input mechanisms are major concerns, but I'd also put performance limitations high on the list. Display - how will your game work on devices with various screen sizes and resolutions? Will your UI be usable or even readable? Will your graphics scale well? Input - touch-screen, keyboard, mouse, joypad. And not just that, but different types of touch-screen with differing capabilities. Performance - the performance characteristics differ wildly across the various targets. In fact, you don't even have to change target to see massive differences. If you want your game to work across a set of platforms then it needs to be designed to work on the slowest, whether that's a 1st gen Android phone or a netbook running Firefox. |
| ||
| 1. Consider different resolutions: I have three sizes of each image (except for backgrounds) and a function that decides which size to use based on the size of the screen. Basically it return an int between 1 and 3 and assign it to a global variable called res images.Load(res+"_img1.png") 'for images with different sizes
images.Load("bg.png") 'for images with 1 sizeand for backgrounds I do this to fill the screen: DrawImage bg, 0, 0, 0, dW/bg.Width(), dH/bg.Height() 'dW and dH is the DeviceWidth and DeviceHeight but as float variables 2. Consider different inputs: If you are only going to use mouse clicks then you have no problems TouchHit and TouchDown works on all platforms except for xbox (never tried it). But if you decided to use different inputs, then you will have to do a little bit more coding. In my case I used three different input systems. Keyboard, accelerometer, and virtual controller. I had to make a new class for the virtual controller and a class called game control and here is one of the functions inside this class: Method GoRight:Bool() If type=keyboard If KeyDown(KEY_RIGHT) Or KeyDown(KEY_D) Return True Else Return False End Elseif type=virtual If vc.MoveRight() 'vc is the virtual controller Return True Else Return False End #If TARGET<>"flash" 'Flash crashed with Accel events Elseif type=touch 'AccelW return AccelX or AccelY depending on the default orientation of the device If AccelW()>y+sensitivity Return True Else Return False End #End End End End and you need to put in mind some issues like: HTML5 and Flash does not support accelermeter and multitouch AccelX and AccelY differs based on the device default orientation. Your code might run on one target but not all and the performance experience differs too. I advice you to keep testing your code on all of your targets if you don't want to end up facing a bug for a specific target and you don't know what is causing the bug. My game runs on html5, flash, android, ios, glfw targets but older android phone like the HTC magic doesn't scale properly and take longer time to load and using acclerometer gives different experience too. HTML5 lags a lot but I am working on an atom powered netbook so that's expected. I almost forgot. Not all targets support the same sound formats. In fact, Not all browsers agree on a specific format they all run on for html5, so you will have to do a little more coding in javascript to change the sound format to fit the current running browser if you want to support them all. I am using mp3. It supports flash, android, ios, and glfw. |
| ||
| I have found the simple rule is... You most often want different games on different platforms. You would likley design differnt games for the iPad than you would if it were a Free Flash game, or a indy PC Game, or an Xbox Live game. Even if you are porting the "same" game logic wise, you are likley to want different controls entierly. And in many smaller games, the controls themselves are a big part of the game experience. |
| ||
| In the case of Windows Phone 7, there are rules that a game has to adhere to in order to be accepted on the market for Windows Phone 7 games. For example, if the user presses the "Back" button on the phone, your game has to bring up a menu that lets the user select what to do (continue or exit). This means you have to write a handler that intercepts the normal handling of the Back button being pressed, because its normal behaviour is to quit your game right away. This probably has to be added to your game in the generated C# code. I wasn't able to figure out how to do it. |
| ||
| Does any of the Touch functions work on HTML5? |
| ||
| The docs for TouchDown say: On devices with a mouse but no touch screen, TouchDown( 0 ) will instead return MouseDown( MOUSE_LEFT ). |
   |