This topic contains 10 replies, has 4 voices, and was last updated by 
Diffrenzy
2 years, 6 months ago.
-
Posts
-
So I have recently prototyped an addictive little arcade game in a Clickteam Fusion, and I want to now turn it into a coded project. Obviously monkey/blitz is my first choice! Id love to use mx2, just because from my small amount of time with it, it seems fast, clean and bloody nice!
My aim of course (being an addictive arcade game) is to get this game on iOS and Android.
What is the timeline for the iOS/Android components of mx2? I see they are actively in development and Android is available already (in some fashion). The iOS sounds like it is progressing too. So are we talking 2-3 weeks? a month? 2 months? 6 months?
I am deciding between monkey1 and monkey2 here, and I don’t mind using an unstable monkey2 iOS/Android compile. I dont mind starting the project knowing mobile will come later, but I was wondering how long.
What would everyone recommend mx1 or mx2? Your advice would be appreciated.
Selfishly I would say use Monkey2 so any bugs or omissions you find will be pushed to Mark and hopefully make everything better for the rest of us.
Mark pumped out Android rather quickly (seemed that way to me) but only he can say when iOS is coming…
I say DO IT !
iOS support is already up and running!
It’s still very immature (as is android) but you can generate xcode projects that run.
There are some limits:
- armv6 only – no arm64 support yet.
- It can only generate code for real devices, not the simulator.
- No touch support yet beyond mouse emulation (ditto android).
- Likely to be many bugs!
Interesting. I am tempted!
Do you plan to support armv7s, arm64, simulator builds in the near or distant future?
What is the state of 3rd party native module support for these platforms? For example I would want to integrate the Appodeal SDK (which already has an official monkey1 Module). I am sure that wrapping it would be fairly straightforward, but does mx2 provide limitations for these platforms?
What is the state of mx2 for stuff like app life cycle and hooking into platform specific events? Monkey1 had targets that we could customise, does mx2 have magic here, or any info on plans for this?
Do you plan to support armv7s, arm64, simulator builds in the near or distant future?
arm64=near future, simulator=later…
What is the state of 3rd party native module support for these platforms?
Non existant.
It’s early days for mobile and it sounds to me like your after something more complete. My primary goal is to get games running well on mobile and work with the community to get the crapware/monetization side of things going and that could be a while off yet.
Ok good to know. It does sound like it is very nearly ready for at least a hacky experience to releasable game, but maybe just not quite enough for non desktop.
I think for now I will probably use mx2 to write small helper tools like packing some XML/JSON data and such. The mx2 UI looks nice for this to get stuff knocked up quick. It will be a good opportunity to get used to the new language.
I would be happy writing 3rd party modules for mx2, had a ton of experience doing this in mx1 and other languages. It does need some foundation API’s for the modules to sit in though, so I will be patient to see how that pans out.
Do you plan for mx2 to automate the nightmare hell of various modules requiring specific changes to the project files?
> Do you plan for mx2 to automate the nightmare hell of various modules requiring specific changes to the project files?
Not sure what you mean here, which project files?
Well in monkey1 it was often required to create a custom target to get a module working. Maybe it would be hooking into a custom OS event that hadnt been wrapped by mojo yet. Sometimes it required special ordering of imports or declarations. I found it was alright to maintain this on a per app basis but when trying to package this up into modules, it became a bit hacky.
So for example advertising/crapware provider wants its SDK integrated. We might have to add a framework to the iOS project. We might also have to init the SDK at a very specific point before mx2/mojox as sometimes they can just be a bit picky.
Another example could be we want to integrate a custom intent/url handler so we can have our game launched from elsewhere. This might require that we have to integrate a hook into the apps delegate and modify something like the projects info.plist
I was just wondering if you have any plans here for mx2 magic to make this easier?
The basic plan is move all the ugly/target specific stuff out of modules and into the target project.
There will still need to be modules to ‘talk’ to the target project of course, but I’m not going down the road of supporting manifest file tweaks, or importing bizarro ‘subproject’ libraries (now deprecated of course) like I tried to do with mx1. It never really worked, and it definitely never ended!
This time around, the approach will consist mainly of leaving it up to users to come up with their own ‘target project templates’ for various SDKs that they will hopefully share around. Such a template would consist of, for example, a ‘raw’ android project with the following changes:
Done!
Well, not quite, we still need an mx2 module to ‘talk’ to the crapware code, and in the case of android I plan to do a simple c++->java translator, with JNI on the c++/mx2/module side and a simple relection based java interpreter on the java/target project side. For ios, things are even easier here as it’s all c++.
This approach is more monolithic than what I tried to do with mx1, but IMO that mostly failed as admob (esp. the latest ‘upgrade or else’ version) ended up mostly ‘baked in’ to the android project anyway and, more importantly IMO, anyone who wanted to use something else was in for a world of hurt because they *couldn’t* just follow the instructions ala appodeal setup above, they had to deal with a rats nest of code in several different places and a bunch of nasty hooks that may or may not do what they need.
Note that there will always be some simple SDKs where it will be possible to just #import and that’s it – stuff that only needs to import a lib or something. But for SDKs that require 5 pages of ‘do this to your project, do that to your manifest, add this to your gradle build file…’ etc etc, nah, not going there again.
I think this approach will work well for 99% of users:
** Much easier to create a new project.
** Everything is ‘target project IDE’ friendly, so mucyh easier to tweak *anything*.
** Don’t happen to worry about tweaks in the native IDE getting overwritten.
** Much easier to implement a new SDK.
** SDK code gets direct access to Activity class, app delegate (eventually – app delegate is currently in SDL2 but I think it should be moved to a target project source file).
Where it gets a bit dicey of course is if you want a ‘googleplay+appodeal’ project, in which case you will need to roll your own if there isn’t one already. But the mx2 modules wont need to be rewritten and it will only involve starting with a googleplay project and following the SDK setup instructions for appodeal on top. It’s just something I can live with for the vast amount of simplification it provides.
It sounds solid. Its not as plug-and-play as one could hope for, but as you pointed out this is not realistic for all scenarios anyway.
Have you considered having a target manager, similar to the module manager? This could aid in the adoption of these targets and assist module makers. You could link up a module to a specific target in its json definition. You could have the possibility for ted to suggest: “You are building a project for the first time and you are using X module. Would you like to automatically download and use the associated target?”
12Have you considered having a target manager, similar to the module manager?+1 on this, great idea.
You must be logged in to reply to this topic.