Hmmm... installing FB and SDL and the OHR is pretty tricky, but installing the ADK+NDK is really quite easy.
If we could make the OHRRPGCE a library to extend, and we didn't need to compile anything but Java, seems like expecting the user to install the ADK+NDK might not be that difficult of a requirement. Actually, the approach taken by the buildozer project is worth looking at. It is a tool for packaging python projects for Android or iOS. It can autmatically download the ADK+NDK, automatically download and compile python 2.7 from source, automatically download and install an assortment of dependency modules. That approach is definitely a brute-force method of solving the problem, but in spite of the tedious download times on the first run, it really works nicely, and is pretty simple. > * Server signs with the "OHRRPGCE.COM" key. (Something you guys maintain). I was about to say that it would have to be HamsterRepublic.com because ohrrpgce.com has been owned by web-sqatters for years, but when I went to check which web squatter currently held it, I was surprised to discover that they have *finally* let it lapse, so I just snapped it up. ohrrpgce.com is now mine :) On Fri, Jun 07, 2013 at 10:16:29AM -0400, Seth Hetu wrote: > Having a build server would certainly be helpful; ADK+NDK+FB+ohr/sdl > is not the easiest toolchain to install. You might want to consider > three options for signing: > * Server signs with the Debug ADK key. (Good for just "trying it out") > * Server signs with the "OHRRPGCE.COM" key. (Something you guys maintain). > * Server provides an unsigned APK, and you guys provide a small > utility for developers to sign unsigned APKs (with their own keys). > > -->Seth > > On Fri, Jun 7, 2013 at 5:52 AM, Ralph Versteegen <[email protected]> wrote: > > On 7 June 2013 04:18, Simon Bradley <[email protected]> wrote: > >> On Thu, Jun 6, 2013 at 4:44 PM, James Paige <[email protected]> > >> wrote: > >>> > >>> On Thu, Jun 06, 2013 at 04:16:32PM +0100, Simon Bradley wrote: > >>> > On Thu, Jun 6, 2013 at 3:22 PM, James Paige > >>> > <[email protected]> > >>> > wrote: > >>> > > >>> > On Thu, Jun 06, 2013 at 01:28:10PM +1200, Ralph Versteegen wrote: > >>> > > On 6 June 2013 02:19, James Paige <[email protected]> > >>> > wrote: > >>> > > > >>> > > > For people who don't have their own domain name, we can provide > >>> > a > >>> > > > namespace like com.hamsterrepublic.ohrrpgce.games.gamename but > >>> > I > >>> > would > >>> > > > also like to allow people to specify their own namespaces, so > >>> > for > >>> > your > >>> > > > own game, tmc, you might choose to use > >>> > > > com.castleparadox.tmc.foresttemple or maybe Mogri would want to > >>> > use > >>> > > > com.slimesalad.phantomtactics or Harlock might use > >>> > > > org.crithit.spellshard > >>> > > > >>> > > Is there any point to allowing customisation of namespace? I > >>> > think it > >>> > > just has to be unique, eg a com.hamsterrepublic.ohrrpgce.games. > >>> > > prefix. > >>> > > I see that the Android documentation says "To avoid conflicts > >>> > with > >>> > > other developers, you should use Internet domain ownership as the > >>> > > basis for your package names (in reverse)." > >>> > > >>> > Well, from a making-things-work perspective, no, there is no point > >>> > to > >>> > allowing people to specify their own namespaces, but from the > >>> > perspective of people signing their own games and uploading them to > >>> > the > >>> > google play store, I would like to give people that option, > >>> > especially > >>> > for people who are going to sell their games rather than post them > >>> > as > >>> > free apps. > >>> > > >>> > Someone can still sell their game with a name in the > >>> > com.hamsterrepublic.ohrrpgce.games.* namespace, but by doing so the > >>> > are > >>> > trusting me as the owner of that domain to behave honorably about > >>> > it :) > >>> > > >>> > The simplest way would presumably be to make the ohrrpgce a library > >>> > project and wrap it with the new namespace, I think: > >>> > > >>> > package com.newnamespace.myrpg; > >>> > > >>> > public class MainActivity extends com.ohrrpgce.games.OHRActivity > >>> > > >>> > etc. > >>> > > >>> > I believe that would work. That seems to be how these examples I am > >>> > looking at are set up. > >>> > > >>> > (I am actually working on an Android project right now for my day > >>> > job, but > >>> > it's been a while and I'm a bit rusty. And someone else has already > >>> > written it; I'm just changing it.) > >>> > > >>> > Cheers, > >>> > Simon > >>> > >>> Hmm... If that is the only way to change the namespace, then it sounds > >>> like having the Android SDK installed and recompiling the project would > >>> be required. Maybe it isn't worth it if it is that much trouble? > >>> > >>> Even though I want people to be able to customize the namespace of their > >>> game, I guess that should be a low-priority goal :) > > > > Don't forget that while allowing the user to select the namespace is > > low-priority, packaged .apks still need to have unique namespaces, > > otherwise Android will consider them all as the same program. > > > >> Ah, yes. Maybe not ideal. It might be possible to change it with something > >> like proguard instead, in the compiled version. > > > > There's an additional problem. It turns out that in addition to all > > the Java code, lots of the C code in the SDL port requires the > > namespace to be compiled in too. I have no idea how JNI works, but it > > appears that Java code like... > > > > package com.hamsterrepublic.ohrrpgce.game; > > class AudioThread > > { > > private native int nativeAudioInitJavaCallbacks(); > > > > requires an implemention provided by a C function named > > Java_com_hamsterrepublic_ohrrpgce_game_AudioThread_nativeAudioInitJavaCallbacks! > > > > However perhaps by using Simon's library suggestion we can use a > > separate namespace for all of the code compiled into the .so files, > > leaving just the xml metadata and compiled Java files to worry about. > > > > In order to edit the namespace in compiled Java code we would have to > > modify .dex files (targetting .class files instead would mean still > > having to convert them to .dex and requiring the NDK). Looking around > > a bit I see there are a couple projects like smali/baksmali > > (https://code.google.com/p/smali) for disassembling/reassembling a dex > > file. It sounds a whole lot simpler to just set up a web server which > > compiles the required java source files with desired on request :) > > > > Unless creating a single trivial java module which includes everything > > else is enough; in that case smali/baksmali could be practical, or > > even a small edit to the right offset in the file... > > _______________________________________________ > > Ohrrpgce mailing list > > [email protected] > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
