How Wadjet Eye updated AGS to release commercial games on iOS

Started by JanetC, Thu 28/05/2015 16:56:18

Previous topic - Next topic

JanetC

How to release an AGS game on iOS
---------------------------------

Hi, this is Janet from Wadjet Eye. I keep getting people asking how to release commercial AGS games on iOS, so I thought I'd write a full account, from start to finish. You can follow this (with reference to my fork of the engine) or you can just fork my fork (easier.)

Overview
--------

When I first released an AGS game on iOS, I based it on JJS's (Jochen Schleu's) brilliant port of 3.2.1. Over a couple of years the AGS project moved on but I was unable to take advantage of the updates due to my old code. I finally decided to take on the task of updating my port to the latest version (3.3.3), as well as adding new fixes to problems that have arisen as the iOS operating system has grown and changed. The biggest problems were that Apple now requires a 64-bit build in anything submitted to the App Store, and recent changes to iOS have made the engine unstable, crashing more frequently than I am happy with.

I decided to keep an account of the process, because people keep asking me what I did to get a version of AGS that can be published on the App Store. Jochen's version was aimed at people with jailbroken iPhones who wanted to put their existing PC AGS game collection on iOS. This wasn't ideal for Wadjet Eye as it didn't have the signings necessary for submission to the App Store, and also the controls were designed to be universal, so that any AGS game could be played, which ended up feeling kind of clunky for the Wadjet Eye style of interface (which is classic Lucasarts inspired.)

My version of this can be found at:

https://github.com/JanetGilbert/ags

Branch name: iOS

Feel free to fork it to your own account for your own use; AGS is open source after all!

Code Signing
------------

You need to go to the Apple Developer website to set up the code signing and profiles.

https://developer.apple.com/

Enroll in the Apple Developer program ($99 a year). You can't really avoid opening your wallet at this point; you can fuss about with jailbroken devices and old versions of XCode if you really like headaches and never want anyone else to play your game. :-)

Go to the "Member Center", and the "Certificates, Identifiers & Profiles" section.

Go to "Certificates", and make yourself  "Development/iOS and App store" and "Production/App Store and Ad Hoc" certificates.

Go to "Identifiers" and add an App ID for your game (eg com.wadjeteyegames.YourGame)

Go to "Devices" and add the UDIDs for all devices you will be testing on personally. You used to have to add all beta tester UDIDs here, but Apple has now added a service called "Testflight" that makes this unnecessary. The UDID is the string under "Identifier" for your device if you open Windows/Devices from the XCode menu.

Go to "Provisioning Profiles" and make "iOS App Development", "App Store" and "Ad Hoc" profiles.

Go back to XCode. Open the XCode/Preferences menu item. Go to "Accounts" and click the "+" sign in the bottom left to add your Apple ID. Any time you make a change in Apple Developer, you need to come back to this page, click the "View Details" button, and then the refresh arrow in the bottom left of the details page. The profiles should then refresh. If some seem to be missing, leave it a while and try again. I am honestly not sure why sometimes this doesn't work. Sometimes exiting XCode and re-trying seems to help. It's magic. If anything ever goes wrong with compiling your game that doesn't make sense, refresh, clean and rebuild. Solves 90% of all possible problems.

Create a Project
----------------

Duplicate the ags project and open it in XCode (open ags.xcodeproj)

Rename the project to your project name. Slow double click on the name of the project in the top-left (just above something that says something like 1 target, iOS SDK 8.2). Type in your project name (eg YourGame). If you can't see the game name, click on the icon in the top left that looks like a folder. Don't ever rename the game in any other way; XCode needs to rename a bunch of internal things that get really borked if you try to edit the .xcodeproj in a text editor. I found out the hard way!

Click on the name of the project in the top left. You should now have a pane which has a project and a target, hopefully both called YourGame.

There are two sections in the middle horizontal column of the screen, one labelled "Project" and one labelled "Target", which should both be named "YourGame." This section is called "General Target Settings"

The "Project" is the game project overall, and the "Target" is a subset of that. I use multiple Targets to make different versions of a game with different files included, all in one big project. I use this feature often when making Mac games for Steam/non-Steam, but I've never made more than one Target for an iOS game. Some things need to be set in *both* "Project" and "Target", so if something doesn't seem to be taking effect, check that it is the same in both "Project" and "Target."

General Target Settings
-----------------------

*** Project ***

** Project Info **

Set iOS Deployment Target to 5.1.1. You have to enter this in the box manually. This version is significant because it allows you to retain compatibility with the iPhone 3G, and also use 64-bit builds. If you don't care about compatibility with older devices, set it higher.

** Project Build Settings **

* Architectures tab *
Architectures: Set this to $(ARCHS_STANDARD_INCLUDING_64_BIT)
Valid architectures: Set this to arm64 armv7

* Code Signing tab *

Set the Debug Code Signing Identities to your Developer ID, and the Release code signing identities to your Distribution ID.

Set the Debug Provisioning Profiles to your Ad Hoc profile, and the Release Provisioning Profiles to your game's Provisioning Profile.

Remove "-gta" from Other Code Signing Flags/Debug. This allows the app to be deployed on Jailbroken devices, but prevents it compiling to be released on the App Store.

*** Targets ***

** General **

* Identity tab *

Bundle identifier: Don't set here, set in "Info"
Version (CFBundleShortVersionString): The version of the game displayed to users. Try 1.0. Increase every time you publish a new version to the public. 
Build (CFBundleVersion): The internal build number. Increase by every time you publish externally (even to Testflight)

* App Icons and Launch Images tab *
Set up your icons here! You need to use an "Asset Catalogue"

Here are Apple's constantly-changing icon size/launch screen size requirements: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/IconMatrix.html

Ugh. They literally add more required images every iOS version update. This used to be nice and simple.

When you add the icon asset catalogue, you need to drag the appropriate sized icons to the box (from Finder.) This is like a cute little puzzle game. Watch out for the 2x and 3x sizes - this means that you need an icon 2 or 3 times the listed size (eg 57x57 x2 = 114x114)

The launch image asset catalogue is much the same, except it doesn't tell you the pixel sizes. Click on the icon in the top right that looks like a box with a vertical line on the right side. This gives you some stats including the expected size of the image.


** Info **

Ensure the Bundle Identifier is set to the same thing as in Member Center/Identifiers, and the Status Bar is initially hidden.

** Build Settings **


* Architectures tab *
Set "Architectures" and "Valid Architectures" to same as "Project"

* Code Signing tab *
Set "Code Signing Identity" and "Provisioning Profile" to same as "Project"

Remove "-gta" from Other Code Signing Flags/Debug. This was to allow the app to be deployed on Jailbroken devices, but prevents it compiling to be released on the App Store.


** Build Phases **

* Run script *

Remove the script relating to code signing (it begins "export CODESIGN_ALLOCATE" and ends "fi") - this is code allowing the engine to run on jailbroken devices and will interfere with compilation of a version that can be submitted the the App Store.

Schemes
-------

Schemes are necessary for compiling the game. At the very top of the screen, just to the right of the "Play" arrow button, there should be a label that still reads "ags". Click on "ags", then select "Manage Schemes" from the drop-down. Delete the "ags" scheme. Then use the "+" to create a scheme named "YourGame"


The Project Navigator
---------------------

This is the section of the screen to the left, where you renamed the project in the section "Create A Project." It has several views - ensure you are using the top-left view, by clicking on the top-left icon that looks like a single folder.

*** Resources ***

This section is what you will be looking at most often. You need to add the files ac2game.dat, audio.vox, speech.vox, ios_ipad.cfg, ios_iphone.cfg and any other data files your game requires. Add them by dragging from Finder.

ac2game.dat is just your windows .exe renamed. You can snip out the unnecessary executable parts by opening it in a hex editor and searching for the string "PADDING". There is a block of text that repeats "PADDINGXX" for a bit, then "CLIB". Chop out everything before CLIB (but leave CLIB). This saves a little space.

If you wish to make more than one variant of a game, you can create multiple targets, and include different resource files for each target. I find this very useful for OSX to make different builds for Steam and non-Steam.

* .cfg files *

Here's what I use (with the variants for iPad)

[misc]
config_enabled = 1
rotation = 2
translation = default
[controls]
mouse_method = 0
mouse_longclick = 1
[compatibility]
clear_cache_on_room_change = 0
[sound]
samplerate = 44100
enabled = 1
threaded = 0
cache_size = 10
[midi]
enabled = 1
preload_patches = 0
[video]
framedrop = 0
[graphics]
renderer = 0
smoothing = 1 (0 on iPad)
scaling = 1
super_sampling = 1 (0 on iPad)
smooth_sprites = 1 (0 on iPad)
[debug]
show_fps = 0
logging = 0

The variants for iPad produce a "blockier" more pixelated look that I like (but some people do not), as opposed to a blurred "anti-aliased" look that I prefer on the iPhone. Experimentation is key here to find out what works for your game.

Since there is only one (universal) build, I include settings files for both iPad and iPhone and select the right one at runtime.

Libraries
---------

The standard version of AGS has only 32-bit libraries. Apple no longer accepts builds without 64-bit libraries.Obtain these from me or just look in my fork of AGS (ios branch) and take them. There are also XCode projects for these libraries available in my fork of AGS if you need to recompile them.

Code Changes
------------

Here is an overview of the changes I made to the code to get Wadjet Eye Games running smoothly. My plan was to make them play as if they had been designed for touch-screen platforms, with no awkward work-arounds that betray their PC origins.

To see exactly what I did, take a look in my fork of AGS, "iOS" branch.

*** Path to game files ***

The game files are added in Resources, and copied over to the root of the iOS App. (YourGame.app.) This is not where AGS expects to find them.

The engine is still working under the assumption that you are running on a jailbroken device and you will manually copy over into the documents folder and select your game files. I remove the ability to select files, and just load the default file name (ac2game.dat) in the root folder.

*** Dragging and Dropping ***

("Drag'n'Drop")

This commit ("Drag'n'Drop") removes the ability to run standard PC AGS games in a jailbroken iPhone, (by removing the ability to right-click) but allows much finer control over touchscreen controls in script.

JJS designed the iOS controls to be one-finger-tap for left-click, and two-finger-tap for  right click. This was to allow existing PC versions of games to be played on iOS device.

I re-wrote the game script to use a verb-coin interface on iOS, making a right-click unnecessary.  The game script is able to tell when and where the user's finger is pressed to the screen, and when it is removed. This allows taps and tap-and-drags to be simulated in-code.

*** Tap past dialogue ***

("Tap past dialogue on mouse up, not down.", "More responsive dialogs")

The engine, by default, skips past dialog when you press your finger to the screen. I changed this to when you press and release, because the other way was accidentally activating the next dialog option.

*** Wadjet Eye Utils ***

("Added AGSWadjetUtils plugin")

This is a plugin that exposes some useful functions to the script.

FakeKeyPress() allows the script to pretend a key was pressed. This is used in Gemini Rue's combat system (which was key controlled on PC, button controlled on iOS) and for making a software keyboard (the built in keyboard does not look nice in a game, has some characters that AGS cannot display, and the close button is too small.)

It also has some functions for achievements, but I couldn't get them working. Anyone who wants to fix them up, tell me how you did it!

*** Cutscene skipping ***

("Cutscene skipping")

In PC AGS games, you skip cutscenes by pressing "Esc". Lacking a keyboard, I needed some other way. It needed to be something implemented at engine level because the script is blocked in cutscenes.

I first experimented by skipping cutscenes with a long press (hold the finger to the screen for a long time) but it was too easy to activate. So I hit upon swiping the finger from left to right at the top of the screen.

I'm not sure how many players use this feature, since most adventure games get played only once, due to being roughly the same each time. It was more a feature for debug (It gets OLD watching the same cutscenes every game) which I left in for people to use or not, depending on whether they remembered it existed.

*** Set Mouse Position ***

("Fixed mouse position")

Simple fix to the scaling of the mouse position. Without it, you can't correctly set the mouse position from script. I use this to place the cursor neatly in the middle of the screen when you change scenes.

*** Config Files ***

("Load different config files for iPhone and iPad")

ios_ipad.cfg is loaded on iPad, and ios_iphone.cfg on iPhone. The difference is in the scaling and smoothing settings, to give an "anti-aliased" effect on iPhone and a sharp, pixelated effect on iPad.


*** Misc bugs & bug-ettes ***

Small, but important.

("Memory leak in ReadString")
("Sound crash bug fix")
("Dismiss Display() boxes on mouse up, not mouse down")
("Fake keypress support")
("Hide status bar")
("Move iOS-specific classes")
("Bug: Keypress not detected")
("Restore audio after phone call")
("Crude hack to restore audio after answering phone call")


*** 64-bit ***

This was a beast of a bug. Apple introduced a requirement that all games must include a 64-bit build, but that meant that I needed to recompile all the dependencies with a 64-bit slice. The last time the libraries were compiled was in Ye Olde Times by JJS.

The system that JJS used to compile the libraries was called cmake. He wrote scripts for this that simultaneously patched the library code (with his bug fixes) and built them. Unfortunately the latter half of the process (building) was very outdated and no longer worked.

The system I came up with was to comment out the building portion of the scripts and just run the patching portion (see my commit "Allegro patch only"). Don't forget to use chmod u+x to get permission to run the scripts (which are in the ags\ios\buildlibs\armv7 folder)

I then made the resulting source files into an XCode project, and built the library as a Cocoa Touch Static Library. I built it for the required architectures armv7 and arm64. Set "Always search user paths" in "Build Settings" to "Yes" and set "User Header Search Paths" to "${SOURCE_ROOT}/[LIBNAME]/include ${SOURCE_ROOT}/../../nativelibs/fat/include" (or whatever needed) or else you will get errors like "Lexical or preprocessor issue 'internal/it.h' file not found" (double-click on the paths and ensure they are recursive). Remove the autogenerated files called something like allegro.h and allegro.m from the project or else you get a lot of errors like "Semantic Issue: Unknown type name 'NSString'". "Product->Destination" must be a real iOS device you have plugged into the computer, or else the Product will not be created even though the build apparently succeeds.

Then I encountered a different problem. I added the resulting library to my project and I got errors complaining "Undefined symbols for architecture x86_64" which turned out to mean that XCode expects a library containing both iOS device architectures (armv7, arm64) AND iOS simulator (i386, x86_64) architectures.

Unfortunately XCode can't build all these simultaneously in one library. You need to build for both device and simulator separately, then combine them using a command-line tool called "lipo"

First: build for device (Product->Build For->Running) THEN build for simulator (Product->Build For->Testing). Note that by default the  "Run" scheme is Debug, which you don't really want. So "Edit Schemes" and on the "Info" tab for "Run", set the "Build Configuration" to "Release". To build for simulator, you must set a simulator as "Destination"

Then use lipo to combine the two in the following way.

lipo -create Release-iphoneos/liballegro.a Release-iphonesimulator/liballegro.a -output liballeg.a

Use lipo to test success:

lipo -info liballeg.a

Desired result: Architectures in the fat file: liballeg.a are: armv7 i386 x86_64 arm64

Next
----

That should give you a working version of the AGS engine, but you still need to alter the script of your game to work with the engine. The most important thing to do is to remove all instances of needing to right-click in the game, because if you followed my instructions, you can now only left-click by tapping on the screen. I'll write a post in the future describing the process I go through to update the script of our AGS games to work well with iOS.

Feel free to email me with any questions at janet@wadjeteyegames.com. AGS is open source, and so is my fork, so you can fork it yourself if you want, or use any of my alterations freely.


https://github.com/JanetGilbert/ags

Branch name: iOS

MyEakinBack

This is an absolutely spectacular post! I am awe inspired on the selflessness shown here. I know I was hoping to eventually post iOS versions of games, even for free.

I'm sure the AGS community here is eternally grateful! I know I am.
completed: Beyond Eternity

Joseph DiPerla

Very nice indeed! Thank you for that write up. It couldn't have been easy. But thank you for sharing. Maybe next year you can tell us how you did Android? ;-P Thanks again Janet! Someone should post this on the Wiki.
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

Mehrdad

Wow.Great job!!!
Thanks a lot Janet for this amazing post.
1)Is 3.3.3 version safety for iOS 64 bit now?
2)I heard .ogv theora codec is very slow on iOS is it right?
3)As Joseph said is here any way to ready Android port for Play Store too?

I'm Appreciate Janet for your help
My official site: http://www.pershaland.com/

JanetC

Quote from: Mehrdad on Fri 29/05/2015 06:50:16
1)Is 3.3.3 version safety for iOS 64 bit now?

Yes, the dev team have put a lot of effort into making AGS work with 64-bit now.

Quote from: Mehrdad on Fri 29/05/2015 06:50:16
2)I heard .ogv theora codec is very slow on iOS is it right?
I don't know, I don't use it. I thought you were going to experiment and find out?

Quote from: Mehrdad on Fri 29/05/2015 06:50:16
3)As Joseph said is here any way to ready Android port for Play Store too?

Nope! We used a porting service (Apportable). Last time I looked at it, the Android version needed *a lot* of work to be ready for commercial releases.

JanetC

Quote from: MyEakinBack on Fri 29/05/2015 02:36:33
This is an absolutely spectacular post! I am awe inspired on the selflessness shown here. I know I was hoping to eventually post iOS versions of games, even for free.

I'm sure the AGS community here is eternally grateful! I know I am.

Thanks! :-)

I hope we can see more AGS games on iOS now! You still have to pay $99 a year even to release free apps, unfortunately.

MyEakinBack

Quote from: JanetC on Fri 29/05/2015 13:14:04
You still have to pay $99 a year even to release free apps, unfortunately.
'Tis a small price to pay to give back to such a wonderful community. I only wish it could all go to indie developers. Although I'm sure it takes quite a bit of effort by the fine developers at Apple to keep us all safe from viruses.

I have been testing for some time with the JJS setup and a jailbroken device, and the games work quite well on Apple devices. I for one am saying it is worth the effort!
completed: Beyond Eternity

Crimson Wizard

#7
Janet, it's good to see you got it working, and I am really pleased you found 3.3.3 suitable for your cause :D.
I am still finding small bugs here and there (some of them seem to be very old, pre-3.0 bugs that, however, can cause crashes in rare cases).

Since this branch is based on 3.3.3, it would make it mostly easy to update it with future patches.


I still have a hope to merge all your work to the central repository, although that may require serious changes; for instance I would not like to add compiled binaries and libraries to the Git repositories; we may need to find a place to keep these files separately in some file hosting server. Another thing is that some of the changes you do are applicable to particular platform only: while this works in a dedicated branch (like the "ios" branch), they would need to be done another way for the general branch (perhaps using compiler switches, or engine options).
Anyway, this is a big topic and we might return to it someday.

I would also like to make a precaution regarding further changing plugin API to 64-bit. Your current change seem not break anything, but other changes may. In current implementation plugins send only 32-bit integers parameters when interacting with script, and they use 32-bit integers even for pointers on particular occasions. Obviously this won't work for 64-bit, but changing parameter type won't be as easy all times. Script interpreter expects only 32-bit integers from plugin, and if one changes plugin API, engine must be changed too, and I can't say if that will be simple, or even possible, considering maintaining backwards compatibility with previously produced games. This stopped me from modifying plugin API earlier. But this must be resolved at some day this way or another.

JanetC

Good to hear from you, Crimson Wizard!

Some of my code is definitely incompatible with the main branch, mostly in the control system changes. It could probably work with some #define 's to make sure it only compiles on the right platform.

My main concern about merging further updates from the main AGS project is save game compatibility, as it always has been. The update to 3.3.3 broke everyone's saves, and I feel really bad about that, although there was nothing I could do. I need to be very cautious in merging updates for that reason alone. People who have bought a commercial game get pretty upset when an update invalidates all their saves!

As for the plugins, they work for me, but I can't guarantee that they are safe in general. We don't use many plugins (makes things easier!)

Crimson Wizard

#9
Quote from: JanetC on Mon 01/06/2015 14:47:05

My main concern about merging further updates from the main AGS project is save game compatibility, as it always has been. The update to 3.3.3 broke everyone's saves, and I feel really bad about that, although there was nothing I could do. I need to be very cautious in merging updates for that reason alone. People who have bought a commercial game get pretty upset when an update invalidates all their saves!

Wait... what? What version were those saves made in? I am specifically trying to keep savedgames compatible to 3.2.1, as well as with previous 3.3 releases. If there was an incompatibility, it could be a mistake on my part. Why did not you mention this earlier? :(

E: I would also like to point out that it is possible to write savegames converter if nothing else helps.

JanetC

Quote from: Crimson Wizard on Mon 01/06/2015 15:04:49
Quote from: JanetC on Mon 01/06/2015 14:47:05

My main concern about merging further updates from the main AGS project is save game compatibility, as it always has been. The update to 3.3.3 broke everyone's saves, and I feel really bad about that, although there was nothing I could do. I need to be very cautious in merging updates for that reason alone. People who have bought a commercial game get pretty upset when an update invalidates all their saves!

Wait... what? What version were those saves made in? I am specifically trying to keep savedgames compatible to 3.2.1, as well as with previous 3.3 releases. If there was an incompatibility, it could be a mistake on my part. Why did not you mention this earlier? :(

E: I would also like to point out that it is possible to write savegames converter if nothing else helps.

Well, it's too late now!

I didn't mention it because it looked like an inevitable part of upgrading to 64-bit - it looked like some integers were upgraded from 32-bit to 64-bit in the save functions.

Crimson Wizard

#11
Quote from: JanetC on Mon 01/06/2015 15:54:01
I didn't mention it because it looked like an inevitable part of upgrading to 64-bit - it looked like some integers were upgraded from 32-bit to 64-bit in the save functions.
This should not be happing too, because we tried to make saving and loading independent on platform bitness to make saves portable from one system to another. Even endianess differences are handled.
I have only two guesses: the previous version you were using could have some bug in save system that we later fixed; and that difference is introduced by plugin(s), that save their own data.
Well, if not there's still some mistake in our code.

AGD2

Brilliant work, Janet! I know this was a thorn in the side for a long time. It also threw a spanner in the works for us *just* as we were about to release on the App store last year (IOS8 happened literally 2 days before). Gonna try porting it again with your latest version. Thanks for your dedication towards getting this all straightened out.

JanetC

Quote from: Crimson Wizard on Mon 01/06/2015 19:09:52
Quote from: JanetC on Mon 01/06/2015 15:54:01
I didn't mention it because it looked like an inevitable part of upgrading to 64-bit - it looked like some integers were upgraded from 32-bit to 64-bit in the save functions.
This should not be happing too, because we tried to make saving and loading independent on platform bitness to make saves portable from one system to another. Even endianess differences are handled.
I have only two guesses: the previous version you were using could have some bug in save system that we later fixed; and that difference is introduced by plugin(s), that save their own data.
Well, if not there's still some mistake in our code.

You know, there was! There was a bug with saving while background speech was onscreen. Maybe that was it.


Glad to know my work was helpful to you, Himalaya!

Crimson Wizard

Something I wanted to mention, but forgot.

Quote from: JanetC on Thu 28/05/2015 16:56:18
*** Resources ***

This section is what you will be looking at most often. You need to add the files ac2game.dat, audio.vox, speech.vox, ios_ipad.cfg, ios_iphone.cfg and any other data files your game requires. Add them by dragging from Finder.

ac2game.dat is just your windows .exe renamed.

I strongly suggest to use *.ags format for main game data file (e.g. MyNewGame.ags).
ac2game.dat is a legacy name of a game file which was used before AGS 2.4 (sic!).
I believe that JJS simply misunderstood the meaning of particular parts of engine code, and thought that ac2game.dat is how the file should be called.
AGS still supports looking for ac2game.dat for backwards compatibility, but more recent, and convenient format is GameName.ags.

In WIP 3.4.0 version we already have this format used to compile Linux distributive.

NOTE: having ac2game.dat will NOT cause any trouble from technical point of view. I think it is simply more convenient to have something with name of your game and distinct ".ags" postfix.


AGS-GD

Hi Janet,

First of all, a million thanks to you and to Crimson Wizard on the amazing work you are doing with AGS.

I've managed to compile your fork of the AGS engine, and successfully run previous games that I've compiled with older version of the AGS Editor (prior to 3.0).

However, when trying to load games compiled by the 3.3.3 Engine (which you mentioned was the version you ported), I get a message saying "This game requires a newer version of AGS (3.3.3.0). It cannot be run.", I tried using the 3.3.2 Engine as well, I'm also getting the same message "This game requires a newer version of AGS (3.3.2.0). It cannot be run.".

May I ask which is the latest version of the AGS Editor that can compile with the fork you ported?

Note: I'm using the Gemini Rue Xcode project (as I couldn't find an AGS Xcode project as mentioned in the Wiki) "Duplicate the ags project and open it in XCode (open ags.xcodeproj)".

I hope this made sense.

Regards,
AGS-GD

Crimson Wizard

Quote from: AGS-GD on Sat 31/10/2015 12:49:38
May I ask which is the latest version of the AGS Editor that can compile with the fork you ported?
I am afraid it might be 3.2.1. Janet's branch was forked out of ours before we released 3.3.
Recently we were discussing a plan to update Janet's port to the most recent AGS version, but that might take some time.

Monsieur OUXX

I'm necroposting but I think this could be interesting for everyone to read:

QUESTIONS:

1) In your port, did you manage Right-click, and if so, how does AGS interact with the "fake" right-click from iOS? (the player actually holds one finger on the screen and taps the other finger while still holding). Do you simply intercept the regular right-click event in AGS o does it work differently?

2) How do you manage the virtual keyboard in the script? For example, let's say that the user is about to save his/her game by typing the name into a TextBox. What event makes the virtual keyboard appear on top of the game?

I just can't get a grip on the general philosophy of the interaction between AGS and the host OS.
 

JanetC

Quote from: Monsieur OUXX on Mon 09/05/2016 13:15:21
1) In your port, did you manage Right-click, and if so, how does AGS interact with the "fake" right-click from iOS? (the player actually holds one finger on the screen and taps the other finger while still holding). Do you simply intercept the regular right-click event in AGS o does it work differently?

I simply don't use right-click in iOS ports. I use a verbcoin system, with a hand for left-click and an eye for right-click. The two finger tap is too clunky for a commercial release, although it is necessary to be able to play a game compiled for PC on an iPhone.

Quote from: Monsieur OUXX on Mon 09/05/2016 13:15:21
2) How do you manage the virtual keyboard in the script? For example, let's say that the user is about to save his/her game by typing the name into a TextBox. What event makes the virtual keyboard appear on top of the game?

I gave up using the in-built virtual keyboard. It didn't work very well. I construct a virtual keyboard using GUIs within AGS and use a plugin to allow me to fake a keypress when a GUI button is pressed.

SMF spam blocked by CleanTalk