How to package the game for Mac platform

Started by zkr4113, Sun 18/08/2024 07:42:33

Previous topic - Next topic

zkr4113

Hi everyone, I am a beginner, I am using AGS to make a small game for my friend to play, but my friend is using Mac, and I am using Windows to make this game, I can not find in AGS to package the game for Mac platform option, and I can not find reliable information in the forums. So, I came here to ask for help on how AGS can make games that support Mac. I'm using version 3.6.0. If anyone could tell me, I'd appreciate it. Thank you!

CaptainD

I have no knowledge of building for Mac (I believe you need to compile the editor yourself, but I could be wrong) - but your friend should be able to play the game using either ScummVM or WINE even if the game is built for Windows.

https://www.scummvm.org/

(ScummVM is free, not  sure about WINE.)


eri0o

A small game should run perfectly fine in the web build.  :wink:

zkr4113

Now there is a question I am not clear, I saw a post that you need to have a Mac computer in order to make your game support Mac, do you have to operate on a Mac computer to make the game support Mac platform? Unfortunately, I only have a Windows computer :confused:

eri0o

macOS requires binaries to be signed and notarized, so not only that but you also have to be an Apple developer with a proper account and pay the anual Apple fee so you can sign and notarize your apps.

You can make an unsigned and non notarized but the person that will play has to then click all the Apple security warnings to be able to run it and you will need some way to pack it and mark the AGS engine binary as executable.

zkr4113


zkr4113

There's the fact that I don't want to post my game online, like send her my game separately so she can play it on her Mac, or do I have to do what you say?

Crimson Wizard

#8
Quote from: zkr4113 on Sun 18/08/2024 16:24:55There's the fact that I don't want to post my game online, like send her my game separately so she can play it on her Mac, or do I have to do what you say?

If you look in Compiled/Data folder in your game project, these are "raw" game files that may be packaged for any operating system in theory, but they also need a Mac engine executable to run them.

So the questions are:
- where to get this Mac engine executable.
- how to organize game files (afaik they have to have certain folder structure on Mac).
- if there's a need to configure these files additionally.

Two first things may be done on Windows, but the last one probably has to be done on Mac (i may be mistaken here). I suppose that your friend can do it too, if somebody provides instructions.


Quote from: eri0o on Sun 18/08/2024 16:15:42You can make an unsigned and non notarized but the person that will play has to then click all the Apple security warnings to be able to run it and you will need some way to pack it and mark the AGS engine binary as executable.

It would be great to have these instructions step by step.

eri0o

@Crimson Wizard everytime I try to put the binary release from macOS in the release assets of the CI people complain it won't work in their unsupported version of macOS so there are no ready built macOS binaries anywhere. If you go to the macOS topic I explained, you need a directory with ending in ".app" and you need a specific dir inside and a xml file named info.plist with the CFBundleExecutable property set to AGS. The game contents go into the Resource dir. If people stop complaining about old unsupported and let me put things in the release I will.

Crimson Wizard

#10
Alright, so these are the instructions:
https://www.adventuregamestudio.co.uk/forums/engine-development/ags-engine-mac-os-x-port/msg636660447/#msg636660447

In these instructions "app" is likely the Mac engine executable. "Resources" folder should contain game files from "Compiled/Data" from AGS project.

In regards to "Info.plist", current instruction is that it should be "xml", and it should have an entry "CFBundleExecutable" inside. But that's not enough to write one for someone who never did that before.

Is there any example of how "Info.plist" should look like inside? At the very least a user must know how to form this xml, the opening tags etc. How does "CFBundleExecutable" points to the executable, is that a relative path?

EDIT: alright, I found one in our repository:
https://github.com/adventuregamestudio/ags/blob/master/OSX/xcode/AGSKit/AGSKit/Info.plist
So this likely may be used as a template.

There's also information about this in the Apple docs, but I'm afraid that many users may find it not easy to understand:
https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html

Quote from: eri0o on Sun 18/08/2024 17:45:41@Crimson Wizard everytime I try to put the binary release from macOS in the release assets of the CI people complain it won't work in their unsupported version of macOS

Could you elaborate, what are "unsupported versions"? Is this about old versions, or unofficial versions?
Does this mean that one has to build an executable for individual versions of macOS, and they won't work on others?

EDIT: alright I found quick info about this too in that thread:

Quote from: eri0o on Sun 21/01/2024 13:19:20A person noted it won't work for all macOS in existence, specially old versions, but I don't think this is relevant, it should work from the latest version to the old version supported by Xcode, which usually goes down to 6 versions. Yeah it moves fast but macOS updates are free, you get one per year. Building for older versions is way too much hassle as you will be working against Apple. This is the sole reason I haven't put macOS binaries in the release. If others agree with me this is ok for Apple users, we can release those.

So this is a problem of people not upgrading their old versions of macOS in time.

eri0o

We always need to build on the latest macOS and the latest Xcode, it's simply not financially viable to build in older versions (need to maintain physical macOS machine with the software installed and connect to the CI infrastructure, plus the security and everything else on this). In Cirrus (and GHA) infraestrutura we will get only the latest OS and Xcode and maybe the second latest OS and Xcode.

Here it is the Xcode versions: https://developer.apple.com/support/xcode/

You can see that in theory that the lowest it officially supports is macOS High Sierra, which is from the September 2017 (notice it's the updated macOS High Sierra so this means that the person even if they bought the computer in 2017 and didn't do OS upgrade they would still be installing the security system updates to be considered supported).

This gives roughly a Six/Seven year timespan. Things older than this are unsupported - meaning they may bug out for some whatever reason, macOS error messages aren't exactly amazing...

I think this is pretty alright - yeah other OSes can do better and all, but they don't have this very expensive infrastructure. I would keep the regular builds CMake based in GHA and just activate the build on Cirrus of macOS on a release and package it there to keep the costs of it low.

Crimson Wizard

#12
Hmm, I have a suggestion to separate a question of executable's compatibility out in its own problem.

From my perspective (for instance), the first issue with macOS port is that there's no clear and fully detailed information on how the game is prepared for it in the "official" place, such as a forum thread (where this will be in a first post) or a article in the manual.

Because there's none, it's easy to miss or forget information (since I am personally not working with mac), and also difficult to help if someone asks. If there were an "official" article explaining how to make the mac game bundle step by step, possibly providing a minimal working template, that would be a good start.

Such instructions would assume that executable is available, but not specifying how just yet.

Then, the executable itself is a distinct problem. There will be 2 user groups:
1. Ones that cannot build it themselves (no mac machine, have no skills, etc). These will have to use the one that we provide. In such case they will have to live with the fact that this exe may not work on old systems. For those we would need to provide an active download link.
2. Ones that can build it themselves, or can ask someone to build for them. These will handle the situation on their own. For those we would need to provide build instructions (i think this is what readme.md is in our repository).

At least that's my vision of the situation...

eri0o

Note that SDL also won't support unsupported macOS versions https://github.com/libsdl-org/SDL/issues/9987, which means if a person don't want to use the latest available they will be also have to fork their own SDL. I would like to keep updating the SDL version, specifically because there are lots of things that I think are valuable in SDL3, like the GPU API that could make it easier to add shaders support - SDL has a new compiler to their own shader language to others.

I very much don't care about the old stuff and won't support at all, it's just too expensive, in both time and infrastructure costs.

Crimson Wizard

What happens when the engine is run on an incompatible macos, is there an error on launch, or random errors later?
If it still launches, is there a way to detect that the OS is too old and report the warning?

SMF spam blocked by CleanTalk