Planing to make a Monkey game

Monkey Forums/Monkey Programming/Planing to make a Monkey game

ziggy(Posted 2012) [#1]
Hello,
I'm going to make my first comercial Monkey game (hopefully I'll finish it) and I wanted to know of any advice you may have for me.

I want to release the game in as many platforms as possible (hence the usage of Jungle + Monkey) and I was wondering several things:

1.- Wich should be the recommended resolution for the game

2.- Can I make it horizontal 16:9 proportion and expect phones (iOS, Android and Windows Phone) to display the game in the proper orientation?

3.- Is there anything I should considere before getting my hands dirty in the job?


smilertoo(Posted 2012) [#2]
I was thinking of rendering to 1280x720 surface, then scaling it to whatever the platform uses.


Tibit(Posted 2012) [#3]
Here is my advice:

1. Make the game run independant of resolution
- Either use virtual resolution
- Scale the playing field (What I prefer)

It is very different playing on a iPhone compared to an iPad - now add XBOX, OUYA, FLASH/WEB and PC /w Win8 or Steam and well resolution is likley to take the least of your "can't sleep" time :)

Controls are where the real design challenge lies imo!

2. If a user starts a GAME that is upside-down or downside-left they tend to turn their device. Not optimal, but the user count you'll lose will likley be slim to none.

3. Yes! A lot in fact :)

-----------

I would suggest this:

1. Make a super simple game, start by taking in all the way. iOS for example is a BIG step to take even if the only thing you game do is to display a white screen while you touch and a black otherwise - the Monkey Code side of things are trivial, that is not going to be where you spend your time (unfortunatly) - so my suggestion is start even smaller than what you consider to be the smallest possible, and then make it slightly simpler than that :)

2. On iOS for example two of the most important things to get your game downloaded is not if the gameplay it any good but rather how the ICON looks and if the NAME of the game get people to search and click it. Tough having any kind of gameplay sure increases people's tendency to return.

3. The challenge of crossplatform (imo) is monetization - Monkey game logic is simple and awesome! You need to wrap or find wrapped libs if you go with ads. Allowing people to buy virtual things in your game is cool, but requires a more complex game and even more time outside monkey integrating. And I'm not even considering the paid model (tough I have heard it can work well on blackberry).


Gerry Quinn(Posted 2012) [#4]
Questions are a bit too general IMO. I don't think you can really have a recommended resolution as such, you have to design it so that it looks okay at whatever resolution you are targeting. Fortunately mojo makes scaling really easy. But it's up to you to decide whether you want to make it big and scale everything down, or make exact bitmaps for devices in a particular resolution range.

Thin fonts and lines are probably the main problems when you scale down IMO (just my opinion, and I don't claim to be very experienced in this regard), so you might want to decide on the basis of whether your game uses a lot of these.

Aspect ratios can vary - again you can choose whether to stretch the same layout or adapt it to the aspect ratio. With Android you can instruct it to adopt portrait or lanscape configuration for your app: I would imagine all mobile platforms are the same.


Xaron(Posted 2012) [#5]
I always use 480x320. Well yes I know that sounds old school where devices have 1280x720 today but I did a test with an image with that resolution (1280x720) and scaled it down to 480x270 to scale it up again on the device. There was almost no difference, only slightly one.

Oh, and I can recommend a real good IDE, check out JungleIDE. ;)


Xaron(Posted 2012) [#6]
Here is my resolution test, btw:

http://www.codeknitters.com/dl/resolutiontest/html5/MonkeyGame.html

And the APK for Android:

http://www.codeknitters.com/dl/resolutiontest/test.apk

Just press the mouse button or touch on the device to switch between the real 1280x720 image and the scaled up one. The differences are noticable of course but not that significant that the lower one wouldn't be enough for games.


ziggy(Posted 2012) [#7]
But, as instance, using a 16:9 scalable resolution is a good idea. I don't want the game to look deformed if possible.

I know this questions are very "vage" but that's the kind of questions you have before writing a single line of code. Thanks anyway.


benmc(Posted 2012) [#8]
I'm actually with Xaron and start at 480x320.

However, if I'm doing pixel art for the game, and I turn off mojo image filtering, it's almost as if no resolution is lost, and it's not blurry because it's just pixels.

For non pixel-art games, I too am still developing at 480x320 and scaling up in MOST cases.

However, due to the "longer" screens, like iPhone 5, I'm now making big changes in my most recent game because I really don't want my games to stretch to a long width, but proportionally. Plus, I don't just want to stretch, I want to show MORE game area on the left and right on the longer screens.

It's more work, but worth it. I'm basically scaling to the Height, and then showing separate backgrounds, and rendering more area depending on the screen's width.


Xaron(Posted 2012) [#9]
I don't stretch at all but just have black bars or use some "fill" images. Stretching is evil, I agree.


ziggy(Posted 2012) [#10]
Thanks to everybody!

I'll keep on investigating on the resolution side of things. If I don't get it wrong, keeping a 16:9 aspect ratio is the way to go, and then, scale up/down depending on device. In other areas I've worked scaling down usualy looks better than scaling up, so I might try to go with 1280x720 and see if it is not too much for the devices VRam.

Monkey is a joy to work with.


TheRedFox(Posted 2012) [#11]
Guess you can have a config menu with some stretching options (like on my TV set :-) )


ziggy(Posted 2012) [#12]
@TheRedFox: I don't like giving this option to users if I can avoid it, as it would mean support several screen ratios. I'll investigate to see if I can automatically put black borders on 16:10 devices such as the iPhone 5.


CodeGit(Posted 2012) [#13]
Another option is getting Ignition and using virtual screens. Works well for me. IE All the scaling is handled automatically inside the engine.


ziggy(Posted 2012) [#14]
I may take a look to ignition, but I'm not sure if I'll use my own framework (I did one for blitzMax wich I've used a lot so I maybe will port this, not sure yet). Is there any demo for Ignition or something that allows me to test it before?


Volker(Posted 2012) [#15]
"You can download a sample of the docs and bananas:
http://www.playniax.com/download/sample.zip
You can NOT compile the bananas without getting errors because you are missing the framework and data files but it is to give you an impression of the framework. "


siread(Posted 2012) [#16]
You may run into problems on a lot of low-end Android devices (even iPhone 3GS) if you are scaling down large images (full screen images 1280x720, for example). I ended up shipping two lots of art assets in my game so that any devices equivalent to or below 640x480 uses one set of low-res art, and anything higher uses a hi-res set. That way it looks sharp on iPad, retina etc.

I guess it will depend on the game you are making though. If you are using simple tilesets rather than large images, then you can probably get away with scaling down.


silentshark(Posted 2012) [#17]
@ziggy, also check out the easy-to-use AutoFit module for Monkey (search for it). I've used a couple of times before and it does what it says on the tin.

There's the virtual resolution thing for Diddy as well to help with this exact problem.

Interesting to read about the resolutions people have been using. For what it's worth, I've targetted 800x480 - which runs perfect on things like the Galaxy S2, but gives black borders on some devices (e.g. Ipad). Interesting that developing for 480x320 then scaling up works effectively.


Gerry Quinn(Posted 2012) [#18]
With a lot of games, especially puzzle type games that have panels of buttons etc., you can tweak the layout a bit to spread things out on a larger device, so it looks like it's using the space.


dragon(Posted 2012) [#19]
You may run into problems on a lot of low-end Android devices (even iPhone 3GS) if you are scaling down large images (full screen images 1280x720, for example). I ended up shipping two lots of art assets in my game so that any devices equivalent to or below 640x480 uses one set of low-res art, and anything higher uses a hi-res set. That way it looks sharp on iPad, retina etc.



interesting theory...
i tested with 4000 images scaled down to 16x16

16x16 px ~35fps
32x32 px ~30fps
64x64 px ~18fps
128x128 px ~11fps
256x256 px ~10fps
512x512 px ~9fps
1024x1024 px ~9fps

now i test with 4000 images scaled up to 64x64

8x8 px ~18fps
16x16 px ~18fps
32x32 px ~18fps
64x64 px ~18fps
(128x128 px ~12fps) < for comparison

all was tested with a applied transformation,
so calculations are the same.


as you can see scaling up or down make NO difference how fast your app is,
but tile size (input) and drawing size (output) are both important!

drawing 16x16 is generally faster than 128x128,
so using small tiles for small screens is much better


but you should tend always to scale down (few percent) - because this is interpolation

scale up is extrapolation = evil
yes, best way is to have 2 images
and small screens tend to have slow gpu
big screen resolutions MUST have better gpu


interesting is also:
usind large image 1024x1024, but drawing rect 16x16 is fast like drawing pure image with 16x16


dragon(Posted 2012) [#20]
research from my side for screen WIDTH:

here are only few devices with 640 px - but most with 480 px or 320 px
here are also no devices above 1280 px (only ipad) - but most with 800 px, 960 px, 1024 px, 1280px

if you have a screen width 320, 400, 480, 640 - use virtual size 512 or 480 px
if you have a screen width 800, 854, 960, 1024, 1280+ - use virtual size 1024 or 960 px

so in most cases the image is scaled DOWN or is unchanged
only for 640 or above 1024/1280 it is scaled UP


Volker(Posted 2012) [#21]
Thanks for you researches dragon. Good to know.


Chroma(Posted 2013) [#22]
"I want to release the game in as many platforms as possible (hence the usage of Jungle + Monkey) and I was wondering several things:"

Did you create the Jungle IDE and how does it make more platforms possible?


MikeHart(Posted 2013) [#23]
I think all available frameworks support a virtual resolution somehow. To avoid stretching you need to see if it supports letterbox scaling. Or build something similar to avoid stretching.
Working with a virtual resolution is the best when you target multi resolutions with the same app. Or, your content is so flexible, that you can place it dynamically.


ziggy(Posted 2013) [#24]
@FlyingMonkey: Yes, I did create Jungle Ide and it does nothing special to provide more targets. I was meaning that the choice of Jungle Ide + Monkey instead of using, let's say, BLIde+BlitzMax or IDEaL + Blitz3D, or VisualStudio + XNA or the like, was due my intentions of supporting as much targets as possible.

I've based all the game on 1280x720 and my framework handles virtual resolutions atuomatically. I'm ust going to add letterboxing very soon, to avoid the game getting deformed.

I get it working on Android, XNA, Desktop, HTML5 (fast!), and Flash. I'm adding windows 8 soon. But I'm far from a decent playable game at the moment as I'm building the framework and the game at the same time, and it's time consuming, but I'm very happy to see how it's going. I may release the framework as an open source game's framework at some point.