Building AGS games FOR ANDROID from the editor

Started by monkey0506, Thu 30/10/2014 15:52:28

Previous topic - Next topic

monkey0506

Drawing so close to a working build process for Linux has got me thinking forward to building for Android as well. I actually started on a port of the ADT's jobb tool to C#. I couldn't find any existing libraries for creating/formatting disk space as a FAT partition though, so I'm working on porting the library that the jobb tool uses to C# as well.

This would add at least a few extra assemblies to the editor though. How does everyone feel about that? Is there a way that the editor could reference those extra assemblies only if they exist and Android is targeted for building?

Once that's out of the way, the game resources could then be packed into a single OBB file and the engine packed into the APK. Then the APK could have a prebuilt script to mount the OBB file as a drive and read the game from there. It's how I've gotten other AGS games (including large projects like Al Emmo) to run from a single APK.

Thoughts?

tzachs

Yes, you can load assemblies in runtime with reflection. See here:
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.load(v=vs.110).aspx
I haven't looked, but I assume this is how the plugin framework works.

I don't mind having extra assemblies myself, but loading the assemblies in runtime can give you another theoretical benefit: the ability to provide a generalized solution that other devs could plug into with all kinds of special deployers.
This would work like this: you provide a new Deployer interface and put it in Ags.Types. The interface would have whatever needed to deploy a game. For example, it could have a Deploy method, a IsSupportedOnCurrentPlatform property, a DisplayName property and a GetSettings method that will allow each deployer to provide platform unique settings which the editor could then show a UI for.

The deployer developer will reference the Types dll and implement the interface. It's similar to how the current plugin framework works. AGS will search in a specific folder for all assemblies that contain an implementation to the interface and put them all in a nice deploy menu.

It's just a random thought, it could be cool but I'm not sure it's worth the effort as opposed to simply tailoring a specific solution to every platform.

monkey0506

I was actually reading into this and it seems that the assemblies aren't loaded at run-time, but rather just-in-time when a call is made, and actually throws a FileNotFoundException if the assembly is missing. If that's true (and I haven't horribly mistaken what I was reading) then it would be sufficient for me to have a try/catch block inside the constructor for a BuildTargetAndroid class. I could work up a quick proof-of-concept for this to test it.

Edit: I realize I mucked up that subject line a bit. Fixed it.

Crimson Wizard

Quote from: tzachs on Fri 31/10/2014 03:15:22

I don't mind having extra assemblies myself, but loading the assemblies in runtime can give you another theoretical benefit: the ability to provide a generalized solution that other devs could plug into with all kinds of special deployers.
This would work like this: you provide a new Deployer interface and put it in Ags.Types. The interface would have whatever needed to deploy a game. For example, it could have a Deploy method, a IsSupportedOnCurrentPlatform property, a DisplayName property and a GetSettings method that will allow each deployer to provide platform unique settings which the editor could then show a UI for.

This is what I was suggesting myself few months ago.

monkey0506

As for the Deployer interface, it sounds a lot like what I am currently developing as the IBuildTarget interface in my personal fork, with the exception that I'm still relying on an Enum for the Settings pane to select which targets should get built. If I could rework to read the .Name of the IBuildTargets returned by BuildTargetInfo.GetRegisteredBuildTargets()*, then it would essentially be as generic as you've described. I've actually been trying to work out how to make it more generic, and I've been using a FlagsUIEditor to provide a drop-down box based on the values of the Enum (BuildTargetPlatform). I'll have to look and see how I can possibly manipulate that to simply concatenate the string values instead.

*Just as an additional note, I've added the BuildTargetInfo class so that the IBuildTargets can be added from the AGS.Editor assembly, but still referenced from AGS.Types.Settings. If there's a better way of doing that, then I'm all ears.

.M.M.

Sounds great! Just one thing -you mean creating the whole apk through AGS,including keystore etc.?

SMF spam blocked by CleanTalk