Are you working on a Godot desktop game? Would you like to publish it to MacOS, without the pain of learning about MacOS-specific requirements like signing, notorization, and paying $99/year?
The good news is, if you plan to publish your game on Steam, you can easily do this, without Mac hardware. My inspiration for this is: be the change you want to see in the world. Publish your game for Mac (and Linux), so the market grows, and more great games support these OSes.
If you're interested in how to do this, skip the section below; if you're interested in how this all works (sort of), the next section gives a very brief overview of the problem.
I don't pretend to understand how all this works. My understanding, as someone who mainly uses Unix and Windows, is the following:
The key thing here: the DMG contains an .app "file" (looks like an executable on MacOS), which is actually a zip file. That zip contains your actual binaries.
Follow these steps:
Gamereplaced with your game name) at the root, with a
Executableshould be set to
Gamewith your actual game name / folder name).
And that's it! If you launch the game on Mac, it should just work!
Finally: I recommend you always make sure someone with Mac hardware tests your game to ensure it launches correctly. If you don't have a friend with a Mac, you can always ask me on Twitter or by email to try it out.
Hello! I made lots of changes to Gem Worlds over the last couple of months, based on player feedback that the game could use more interesting interactions between things in-world.
Based on that, I added a few terrain types to the game; they generate in each world:
I also added, then scrapped, a couple of terrain:
Conveyor belts added a lot of interesting dynamics to the game. Unfortunately, they also contributed a disproportionately huge amount of bugs. In the end, I scrapped them.
Meanwhile, they also exposed a huge performance issue, where moving caused a drop of ~130ms (roughly ten frames). Fixing this required ripping out and rewriting the main collision-detection system, which resulted in an explosion of bugs, and took way too many weeks to fix. Alhamdulillah, those are all fixed now.
I also added (again based on played feedback) keys and locks! In every 5th and 10th level of each world, the exit appears from the start, but lock blocks surround it; you need to find one (or three) keys to unlock them and exit.
I'm looking forward to shipping a new v0.5.0 demo soon inshaAllah, and getting (and integrating) more feedback and features into the game. When that ships, I would really appreciate it if you could give it a quick play-through, and let me know your thoughts.
Despite not working much on Gem Worlds during Ramadan, I'm very happy to announce:
Based on feedback from a couple of players, I changed a number of things in the game; most notably: - I added keyboard bindings and fixed tooltips for all skills and items - You can change sklils at any time, by quitting to the skill shop (you resume back from the same level afterward).
While this resulted in lots of people looking at Gem Worlds, it resulted in a mere ~30-ish downloads. This confirms one of my hunches from a few months back: the core game itself isn't that interesting or captivating. Based on the feedback I received from a couple of players, despite being designed as "play, die, retry with different skills," the replayability and interest in continuing through the game is minimal or zero.
This dramatically hurt my motivation to work on the game. It's the biggest game I've ever made (by at least 50%). Regardless, my plan is to inshaAllah continue slogging through the leftover work to get the game out.
At this point, I may not run a beta version, either; that requires at least a significant amount of players (new and recurring), which I didn't get access to. I'll provide updates on that as development continues.
One of the problems we run into as game developers, is keeping our game demos up-to-date. Data suggests that keeping your demo up longer results in more wishlists and sales; but how do you manage keeping your demo up-to-date with your game as it changes (including copying over bug-fixes)?
Most developers opt to keep a separate branch/version of demo code, and manually keep that up-to-date. As the game and demo code diverge more and more, porting over changes and bug-fixes becomes a bigger and bigger headache.
Instead, I proprose another solution: using feature toggles to keep your demo separate. This way, you keep a single code-base for your demo and production game. (You can read about feature toggles in Fowler's execllent, comprehensive guide.)
How this works:
Benefits of this approach:
The main drawback of this approach, is that your demo includes all the content and functionality of the actual game. While this means you can easily do things like switch which skills and levels are available to the player, it also adds the possibility of someone reverse-engineering your demo and getting full access to your game. If you're not okay with that, I suggest you look at other approaches.
Depending on your language/engine of choice, you either gate content behind pre-processor statements (e.g.
#if DEBUG) or regular if-statements (e.g.
if Features.IsDemoMode == true).
I can't stress this enough: it's really important to learn from "defense in-depth" and gate as much as you can. You want to protect your game from technically apt adversaries who can decompile/reverse-engineer it and gain access to the full game.
To do this, add checks absolutely everywhere possible. For something like Gem Worlds, this means adding checks in the skill shop, in the core game (when a level loads), on the title screen (continuing a game but you're past the end of the demo?), etc.
For additional security, if possible, store content and data in JSON/external files, and use your editor to switch which of those files is used in the demo. (e.g. if your skills are stored in
skills.json, maybe you have two versions -
skills-demo.json - and can switch which one is used in the demo build.)
While this is game-specific, the more checks you add, the better; not only do you reduce the chance of accidentally giving players access to the full game, but you also make sure that there's no way for them to break out of the demo content.
The other problem with gating using feature toggles, is that it really requires additional testing of the final build. Try your game, play through to the end; then put on your attacker hat, and try to circumvent the restrictions. Can you edit the save files and get inaccessible skills, or go past the last part of the demo? Make sure you test until you feel comfortable that it's bullet-proof.
If all else fails, platforms like Steam allow you to remove/disable the binaries (and in Steam's case, it yoinks the files away from the user's system). You can always rely on that in case things go bad.
Finally, constructing the demo build. Many programming languages since C/C++ allow you to define build-time constants, and specify build profiles. This includes C/C++, C#, Java, and others. I will focus on Godot/GDScript, since that's my current stack of choice.
As of Godot 3.4, you need to:
Custom (comma-separated), add your feature, e.g.
(The same steps apply to other game engines, like Unity, MonoGame, etc.)
Once that's done, viola, you have two separate builds - demo and non-demo. Make sure you test thoroughly!
This blog post illustrates one way to create demo builds, that are always in synch with the main game content. It's not the best approach or the worst, simply one approach you can choose. While it ships the full game along with the demo, with defense in-depth, you can be quite confident that players can't access anything they shouldn't.
Hey all, just wanted to drop a quick note and let you know that Gem Worlds is pretty much content-complete. You can play the game from start to finish, and aside from some bugs and missing polish, the game is done.
For the next couple of months up to the release, the plan is to add missing polish (like sound design, story events, and an ending) and find/fix bugs. There won't be much to show, but it's critical work.
On the bright side, I am also planning to launch a demo of Gem Worlds. The demo will remain up-to-date with the rest of the game (it won't lag behind in terms of features or fixes), and I hope many of you will play it and pass along your feedback.
In summary, the roadmap for the next few months (other than Ramadan, which is most of April and won't include much/any gamedev) looks like: