Depending on your commute, keeping a smaller controller in your car or bag isn't too hard. Given that all the UFO 50 games only need 2 buttons it's not that bad to carry something flat like snes...
Depending on your commute, keeping a smaller controller in your car or bag isn't too hard. Given that all the UFO 50 games only need 2 buttons it's not that bad to carry something flat like snes style controller vs awkwardness of the modern gen console controllers.
I don't know if there's an elegant solution there anyway, considering there's a lot of appeal (to me, at least) for UFO 50 as a local multiplayer game.
I don't know if there's an elegant solution there anyway, considering there's a lot of appeal (to me, at least) for UFO 50 as a local multiplayer game.
I was holding out for a Switch port, but I might pick it up on Steam now and give this a try on my Logitech G-Cloud. Does anyone know how this actually works? Is it because UFO50 was built using...
I was holding out for a Switch port, but I might pick it up on Steam now and give this a try on my Logitech G-Cloud. Does anyone know how this actually works? Is it because UFO50 was built using some platform-agnostic engine that already has an Android runtime, or is it using some kind of emulation?
UFO 50 is built using Game Maker, so one could take the assets of the game, stuff them into a Game Maker compatible APK and get it to run well enough, depending on various versions and compilers...
UFO 50 is built using Game Maker, so one could take the assets of the game, stuff them into a Game Maker compatible APK and get it to run well enough, depending on various versions and compilers involved.
We're lucky in this case that the UFO 50 developers chose to compile the game the way they did. GameMaker has two ways to compile your game: VM and YYC. VM is how the engine initially worked...
We're lucky in this case that the UFO 50 developers chose to compile the game the way they did.
GameMaker has two ways to compile your game: VM and YYC. VM is how the engine initially worked (after the initial release of GameMaker: Studio, at least - in the pre-GMS versions, games' source code was stored as plaintext and interpreted directly); source code is compiled to bytecode and packed together with all the game's assets into a data file. It's called data.win on Windows, which is probably the most common name it's referred to as, but it has a different extension on every platform for some reason. At this point, this data format has been completely reverse-engineered, and there is a high-quality decompiler for the bytecode (as a part of UndertaleModTool, a full modding suite for the engine) that can turn it back into readable GML code. This data file is paired with a runner that's the same for every game made with a given GameMaker version, which is what makes UFO 50 relatively easy to port to Android in this case. You just need to get an Android runner for the correct GameMaker version, which is easy to obtain by just compiling a dummy project, and you're good to go.
YYC still uses a data file with the same format, but source code is no longer stored in it. Instead, it's transpiled to C++, then compiled to native machine code as part of the runner executable. This makes the game not especially moddable, and would make it way harder to port to other platforms.
I've always used VM for my own GameMaker games to allow mods and ports like this to be possible. I always find it a shame when a game is locked down enough to be difficult to mod. This kind of thing is what gives games longevity, and I think it's important to encourage it.
Unfortunately, things may change in the future. YoYo Games has been working for a while on a new GameMaker runtime (tentatively called GMRT), which will completely change the format games are stored in and possibly lock modders out. At the very least, it would be a whole lot of work to build back to the point we're at now, where GameMaker games can be completely taken apart and changed at will. I'm sure there will be improvements along with the new runtime, but it's a real shame we might have all that progress reset soon.
The main benefit is huge performance gains over VM, though for most GameMaker games, which overwhelmingly tend to be fairly graphically simple 2D fare since that's what GameMaker is good at (it's...
The main benefit is huge performance gains over VM, though for most GameMaker games, which overwhelmingly tend to be fairly graphically simple 2D fare since that's what GameMaker is good at (it's maybe the best major engine for pixel art games), that doesn't really matter. Some developers may want their source code to be locked down, also - not everyone is quite as mod-positive as me.
A cool project but requiring a controller means it's not really "on the go" for me.
Depending on your commute, keeping a smaller controller in your car or bag isn't too hard. Given that all the UFO 50 games only need 2 buttons it's not that bad to carry something flat like snes style controller vs awkwardness of the modern gen console controllers.
I don't know if there's an elegant solution there anyway, considering there's a lot of appeal (to me, at least) for UFO 50 as a local multiplayer game.
I was holding out for a Switch port, but I might pick it up on Steam now and give this a try on my Logitech G-Cloud. Does anyone know how this actually works? Is it because UFO50 was built using some platform-agnostic engine that already has an Android runtime, or is it using some kind of emulation?
UFO 50 is built using Game Maker, so one could take the assets of the game, stuff them into a Game Maker compatible APK and get it to run well enough, depending on various versions and compilers involved.
We're lucky in this case that the UFO 50 developers chose to compile the game the way they did.
GameMaker has two ways to compile your game: VM and YYC. VM is how the engine initially worked (after the initial release of GameMaker: Studio, at least - in the pre-GMS versions, games' source code was stored as plaintext and interpreted directly); source code is compiled to bytecode and packed together with all the game's assets into a data file. It's called
data.win
on Windows, which is probably the most common name it's referred to as, but it has a different extension on every platform for some reason. At this point, this data format has been completely reverse-engineered, and there is a high-quality decompiler for the bytecode (as a part of UndertaleModTool, a full modding suite for the engine) that can turn it back into readable GML code. This data file is paired with a runner that's the same for every game made with a given GameMaker version, which is what makes UFO 50 relatively easy to port to Android in this case. You just need to get an Android runner for the correct GameMaker version, which is easy to obtain by just compiling a dummy project, and you're good to go.YYC still uses a data file with the same format, but source code is no longer stored in it. Instead, it's transpiled to C++, then compiled to native machine code as part of the runner executable. This makes the game not especially moddable, and would make it way harder to port to other platforms.
I've always used VM for my own GameMaker games to allow mods and ports like this to be possible. I always find it a shame when a game is locked down enough to be difficult to mod. This kind of thing is what gives games longevity, and I think it's important to encourage it.
Unfortunately, things may change in the future. YoYo Games has been working for a while on a new GameMaker runtime (tentatively called GMRT), which will completely change the format games are stored in and possibly lock modders out. At the very least, it would be a whole lot of work to build back to the point we're at now, where GameMaker games can be completely taken apart and changed at will. I'm sure there will be improvements along with the new runtime, but it's a real shame we might have all that progress reset soon.
Any idea what the benefits of YYC are? I imagine there are reasons besides locking down the source code.
Since its compiled to machine code, I imagine it comes with some performance gains
The main benefit is huge performance gains over VM, though for most GameMaker games, which overwhelmingly tend to be fairly graphically simple 2D fare since that's what GameMaker is good at (it's maybe the best major engine for pixel art games), that doesn't really matter. Some developers may want their source code to be locked down, also - not everyone is quite as mod-positive as me.