How to get your (Completed) game on Android & OUYA

[jcenterprises]

Thanks. Also, for Ouya's free features policy, can I upload a separate demo of my game along with the paid version, or will I have to upload the full version but use a textbox to block the player from the rest of the game until they paid and use that script in the wiki to unblock the rest of the game after payment?

[Bob the Hamster]

Thanks. Also, for Ouya's free features policy, can I upload a separate demo of my game along with the paid version, or will I have to upload the full version but use a textbox to block the player from the rest of the game until they paid and use that script in the wiki to unblock the rest of the game after payment?

On OUYA you are supposed to just upload a single version of your game, with the full version "locked" somehow and unlocked by an in-app purchase.

Like I say, I still haven't figured out how to support in-app purchases. The API for purchases is Java-based, and I have very little experience working with Java (and in this case I need to interface Java->C->FreeBasic->Plotscripting)

[Meowskivich]

This thread has become far more popular than I thought it would have been. ._.

[FyreWulff]

Thanks. Also, for Ouya's free features policy, can I upload a separate demo of my game along with the paid version, or will I have to upload the full version but use a textbox to block the player from the rest of the game until they paid and use that script in the wiki to unblock the rest of the game after payment?

On OUYA you are supposed to just upload a single version of your game, with the full version "locked" somehow and unlocked by an in-app purchase.

Like I say, I still haven't figured out how to support in-app purchases. The API for purchases is Java-based, and I have very little experience working with Java (and in this case I need to interface Java->C->FreeBasic->Plotscripting)

It's a lot of work on the backend but I would guess a logical way would be 3 things:

A menu in custom that lets you set up an IAP menu
Each item can be named, and input whatever else is needed to hook the IAP item into the store.

Then give an option "if IAP purchases SET TAG # to ON" or a plotscript variable that the person can check to see if an IAP item has been purchased


so for most people who'd want to do the basic unlock full version it'd be something like

Custom -> Distribute Game -> Configure In App Purchases

Item 1:
Name: Purchase Full Version
Purchased String: -undefined-
Set Tag 55 to ON (HasBoughtFullGame)
Set Tag 56 to ON (HidePurchaseMenu)


Then you'd go add a menu option called IAP Prompter, selecting it would pop up the prompt for the platform targeted. They can then check the purchased tag to hide the buy option after purchasing so it looks all nice and clean. And makes it available to those that don't want to plotscript.

Just an idea.

I think even without current IAP support you probably need to start thinking about a platform variable people can read to set up automagically used optimizations for touch.

[Bob the Hamster]

Yep, I will probably be doing something very similar to that. The hard part for me is the Java interfacing. I have some testing code right now that gets as far as sending the OUYA payment server a purchaseable product codename and getting back full-name and price, but I still have a long way to go.

I think even without current IAP support you probably need to start thinking about a platform variable people can read to set up automagically used optimizations for touch.

Actually, this is already in the nightly wip builds. There are three new commands

Code: Select all

running on desktop
running on mobile
running on console

They return true/false. "running on console" currently only returns true on OUYA, and "running on mobile" returns true on all non-ouya android phones and tablets. It will also return true on iOS whenever we have that port working. "running on desktop" returns true on everything else (that is to say, everything that we can expect to have a keyboard)

I recommend using these as sparingly as possible, since debugging code that has platform-specific behavior is a lot more work, but they are there for those who need them.

[Gizmog]

A sneak peek of things to come?



I also found a trivial bug! In Edit Text Boxes -> Box Appearance, if you select Text Color with the enter key and then choose a different color from the resulting palette, when you exit the palette screen the numerical representation of Text Color will still be that of the old color, until you exit and reenter the menu, or change any value on the screen. This was in Beelzebufo though, may've been fixed in nightlies.

[Bob the Hamster]

Haha! Fortunately, the in-app-purchaseing systems cannot be called non-interactively. It always pops up an OS-level confirmation window to ask if you really do wish to purchase the "Make it Rain $1.00" product in the app "Habla No Ingles IV EX Plus Championship Edition by TheGiz, Inc."

[Chronoboy]

Can you release the current version of Wandering Hamster to the play store to give us an idea of how an RPG would run? Wouldn't mind seeing framerate, music, and sound effects first hand on my devices. This way, we can also report our devices, performance, and any bugs we might notice.

On another note, I am going to try the Android build instructions soon when I find time. I am thinking a very useful purpose for a community Linux server(as mentioned in another thread), would be to have a persistent AndroOHR build environment anyone here can try out to see how their own demos or games might work on Android or OUYA. I'd make it as simple as running a single script with your .RPG file as an argument. This will allow anyone to use the service to build an APK. The script will copy or link the RPG file into the build directory and run the required build commands as per the wiki documentation. This will also allow James to focus on more important things than building APKs for completed games

[Bob the Hamster]

Can you release the current version of Wandering Hamster to the play store to give us an idea of how an RPG would run? Wouldn't mind seeing framerate, music, and sound effects first hand on my devices. This way, we can also report our devices, performance, and any bugs we might notice.

I don't want to do it with Wandering Hamster because it is incomplete, but I will get somebody's rpg ready for upload soon. I think Fyrewulf's Sword of Jade is likely to be ready to go first.

On another note, I am going to try the Android build instructions soon when I find time. I am thinking a very useful purpose for a community Linux server(as mentioned in another thread), would be to have a persistent AndroOHR build environment anyone here can try out to see how their own demos or games might work on Android or OUYA. I'd make it as simple as running a single script with your .RPG file as an argument. This will allow anyone to use the service to build an APK. The script will copy or link the RPG file into the build directory and run the required build commands as per the wiki documentation. This will also allow James to focus on more important things than building APKs for completed games

That is a pretty cool idea!

One thing to be wary of is that compiling anything is pretty processor intensive, so you will need to pick a hosting service that either puts no limits on CPU usage, or limits CPU usage in a graceful way. My own host that serves HamsterRepublic.com limits CPU usage by killing any process that goes over the limit. That is not so bad for a web server, but *terrible* for a compiling server.

EDIT: Oh! I almost forgot. I do think that before long I will be able to start uploading a debug build of the ohrrpgce game player apk, with no rpg file. You will have to sideload rpg files to test it, which is easy to do on some devices, and hard to do on others, but it will be good enough for testing for some people.

[Spoonweaver]

Tim-Tim "The Mighty Gnome" is now published on Ouya!

After being reviewed I got some feedback.

Some feedback from OUYA: The game is looking great! It made me feel nostalgic for old school games. I liked the music too! The only issue I noticed was a minor safe zone issue. The text for “Health and "Magic” is slightly cut off on the left side of the screen (see attached screenshot). If you have any questions, please refer to the Technical Guidelines of the Content Review for further information. (https://devs.ouya.tv/developers/docs/co ... guidelines) Everything else is good to go!

I was surprised to hear this about the hud, because I thought I had fixed the problem. But there seems to be a standard screen size that they suggest.
Here's the photo of the screen range they suggest if anyone is curious.

[Meowskivich]

what's the standard screen size, spoon?

[Chronoboy]

On another note, I am going to try the Android build instructions soon when I find time. I am thinking a very useful purpose for a community Linux server(as mentioned in another thread), would be to have a persistent AndroOHR build environment anyone here can try out to see how their own demos or games might work on Android or OUYA. I'd make it as simple as running a single script with your .RPG file as an argument. This will allow anyone to use the service to build an APK. The script will copy or link the RPG file into the build directory and run the required build commands as per the wiki documentation. This will also allow James to focus on more important things than building APKs for completed games

That is a pretty cool idea!

One thing to be wary of is that compiling anything is pretty processor intensive, so you will need to pick a hosting service that either puts no limits on CPU usage, or limits CPU usage in a graceful way. My own host that serves HamsterRepublic.com limits CPU usage by killing any process that goes over the limit. That is not so bad for a web server, but *terrible* for a compiling server.

The server will be a VPS, and I do not believe they kill programs for using too much CPU. On a Rackspace Cloud server, I compiled a few specialized programs, which Debian either didn't have or had a really old version of, and it was super fast. Besides, as I understand the majority of the compiling should only need to be done once, and that's compiling FreeBasic against the ARM toolchain, after that, it's just building the APK after compiling some Java sources into byte-code.

EDIT: Oh! I almost forgot. I do think that before long I will be able to start uploading a debug build of the ohrrpgce game player apk, with no rpg file. You will have to sideload rpg files to test it, which is easy to do on some devices, and hard to do on others, but it will be good enough for testing for some people.

Awesome! And sideloading is no issue for me, as I use this super handy FTP Server(which runs on both my S3 and Tablet):
https://play.google.com/store/apps/deta ... roid&hl=en

It doesn't require root access and gives full read/write access to the Internal Storage, on pre-4.0 phones this will be the SD Card, on newer handsets and mostly all modern Android tablets past Honeycomb will give access to the 8GB/16GB/32GB internal storage. I highly recommend it for wireless file transfers for any Android user. I've never used the cable to transfer files since, just connect to WiFi and connect via an FTP client, super simple. I was initially hoping for a sideloading solution, as it will make testing and debugging games much more easier.

[Spoonweaver]

what's the standard screen size, spoon?

it seems to start around pixel (18,10) and end on at the same margins at either side.
However, it seems james is fixing the problem soon so it might not be a future issue.

[TMC]

I am thinking a very useful purpose for a community Linux server(as mentioned in another thread), would be to have a persistent AndroOHR build environment

That was the fall-back plan. I think it could be possible to provide all tools needed to create an .apk in a small download if I write a simple utility to modify namespaces in compiled .dex files (see here). But I guess it would be nice to avoid having to do so.

It might still be desirable to only perform the Java and .dex compilation step on the server, and zip up everything into the .apk on the client, so that the potentiall large .RPG file doesn't have to be uploaded and redownloaded.

[Spoonweaver]

[game]Clam Digger[/game] will soon be on OUYA.

I've updated a few small things. The biggest change is the addition of a hud to count the number of mini cars that you've discovered in spaces you thought were empty. Perhaps less people will think the game is unbeatable now.

Oh, and a new version is also available here.