At the end of 2024, I was stuck in the mud with CiderKit. I wasn’t able to wrap my head around Strict Concurrency becoming mandatory with Swift 6, and I wanted to make my project compliant with that. I ended up making some nice refactoring within the map management classes, but forcing myself into it was a mistake. I finally realized I needed a break from all that, and decided to stick with Swift 5 for the time being. And to work on something else for a while. Though, that moment lasted almost 6 months and gave me VGTunes.

The first version was released more than a year ago, on January 15th, 2025.

VGWhat?

I am passionate about pretty much everything in video games. From tech to art to design, I love it all. But, besides the actual games themselves, soundtracks are what I consume the most. And, unfortunately, video game soundtracks, however famous they may be today, did not always receive the recognition they deserved. Case in point, most streaming platforms lack a dedicated “Video Games Music” category, or at best have a curated subsection that contains only a few entries. I always said to myself that, given the opportunity, I would work towards a better platform for video game music.

Another aspect of today’s digital music landscape, one that is not tied to video game music specifically, is that many people are using either Spotify or Apple Music. That’s not my case, and I became somewhat tired of being a Deezer¹ user confronted with another significant part of the world sharing links from other services, making them essentially useless for me. What if there were a website listing video game soundtracks and their location on the various streaming platforms? A database of streamable video game soundtracks if you will.

That became the starting point for VGTunes, a website where you can find video game (hence the VG) music (Tunes), and where it is streamable from. Plus other infos, like the Steam page for the game.

Finding the Intersection

Other people are already building similar things.

First, you have individuals building more editorial oriented websites like NOWPLAYING. But that’s not my goal. I’m lacking the time for such authored content.

On one hand, you have VGMdb: a proper database of everything video game music, including physical editions. The website is fairly complete, with detailed information on every entry. Though in many cases, links to streaming services are missing. This is the reference website and my main target. I hope at some point in the future VGTunes will be as detailed and complete.

On the other hand, you have social websites like Songlink/Odesli and Listen.to. However, these websites are not databases. They only allow people and artists to create custom webpages with links to the various avenues where a specific album or song is available, acting as a single URL to use on their website.

VGTunes is basically a mix of these. It’s a database, expected to be as complete as possible, but with the design philosophy of the social websites.

Starting Small

As I write this post, VGTunes references more than 2,300 albums and 1,200 artists. More than a year after the start of the project, it’s already a substantial database. Of course, it is nowhere near completion as I had to start from nothing.

How do you fill up a database of streamable video game soundtracks? For some reason, streaming platforms have no comprehensive way to search by genre, or even a dedicated genre for video game soundtracks. Even worse, some albums have no genre attached. That couldn’t be the starting point, nor a valid source for automation.

I turned to VGMdb and search for an API. In late 2024, nothing concrete was available. Right now, in April 2026, an API seems to be on its way, but is still in private beta and unvailable to me at the moment.

So, I had to build my own tools to populate the database.

Tooling Up

I took a very naive approach: search the streaming platforms for generic keywords (“original game soundtrack” for example) and add each result manually. The very first version of this search/add tool was very rudimentary. The tool was searching on Deezer and I had to manually get the IDs for other platforms by hand (Apple Music and Spotify only at the time).

At the time of writing, the website supports Apple Music, Bandcamp, Deezer, Spotify, Tidal, as well as Steam and links to Steam soundtracks when available. It was unimaginable to be able to scale with such limited helpers.

So, I refined the process over time to automate as many steps as possible. The starting point is still pretty much the same: search for an album on one of the platforms and select it for inclusion in the database. But after that, the current backend of VGTunes actually scans other platforms for similar results and automatically link albums if an exact match is found. It saves me a lot of time and helped grow the database much faster. It is still far from perfect, but it works.

VGTunes Backend Dashboard

I also created a website generator (as the front-end of VGTunes is basically a static website) that takes information from the database and creates the various web pages for every referenced album and artist, including alphabetical catalog pages.

What’s Next?

There is probably a visual redesign down the line for VGTunes. And more platforms added to it, like Qobuz, YouTube Music, and others.

On the feature side, I would like to create browser extensions that would allow sharing VGTunes links when listening to a referenced album on the supported streaming platforms.

Only time will tell what comes first.

My Motivations

I’ve been using Unity since 2013 almost daily, at work and during game jams. Even though I’ve moved to SpriteKit for my personal projects, it cannot export games to Windows or for the web. WebGL exports are especially important for game jams as it allows people to safely play games with even installing them. So far, Unity was the perfect candidate.

However, in september last year, management at Unity decided to introduce a new way of monetizing the engine: the Unity Runtime Fee. It would be an understatement to say that developers around the world were disappointed. The first proposed solution was an insult to every game developer that was using the engine. Luckily, the final draft was much more sensible, but a lot of trust has been lost along the way. And Unity has a long road ahead to regain that, even if the Runtime Fee has finally been canceled.

Enters Godot. The same day Unity announced their new fee, Godot introduced its development fund. Unity’s bad move gave it a lot of attention as many indie devs and small to medium studios looked for an alternative to Unity. And so did I!

But it can be pretty hard while working to learn new technologies that are not directly applicable to the production at hand. That’s why I decided to give Godot a try during my favorite game jam of the year, to see for myself if there’s any potential for me or for the studio in the future.

(Alt Shift, the studio I’m part of, still uses Unity and will continue in the foreseable future. This post, like all the content of this website, exposes only my personal views)

A Bit of Disclaimer

As I said earlier, I’ve used Unity for more than ten years now and, during this time, exclusively with C#. The fact that Godot embraced C# officially a few years ago makes it a very good alternative choice over Unreal that uses C++. In order to avoid starting completely fresh during the game jam, I decided to follow a few tutorials (notably from Brackeys) to get familiar with the editor and the components. The tutorial uses GDScript, Godot’s first-party scripting language, but I converted most code pretty easily to C#.

Unfortunately, I discovered a few days before the game jam that the WebGL export template for Godot wasn’t available in the dotnet version of the engine. If I wanted to export for the web, I would be stuck with GDScript. Many people consider GDScript a very good choice for Godot, so I decided to take the bullet and went with it.

So basically, everything that follows is me trying my best to code a game in about 96 hours, while discovering pretty much everything about the engine. I’m certain some of my conclusions are wrong based on that, and that solutions exist that I didn’t find by myself.

The Good Bits

Light but Mighty

Fortunately, many things are advocating for Godot from the get go. For starters, the editor / engine is very small. About 250 MB on macOS, as a Universal binary which supports x86_64 as well as Apple Silicon architectures. That’s impressive compared to the 8+ GB of the Unity Editor 6000. Sure, you have to install the dotnet runtime by yourself if you want to use the corresponding version, but that’s a minor issue and does not explain the size difference.

Of course, the editor is in itself way less demanding on the system (putting aside the memory required for your project). This is especially important for me as I sometimes use a Intel MacBook Air 2020 with 8 GB of RAM and it struggles to handle Unity and Rider simultaneously (as Rider is a memory hog). Godot + Visual Studio Code would be a breath of fresh air!

Projects are also way smaller, as there is no Library folder. These special Unity folders, present in every project, can take a lot of space. For example, for my GMTK Jam 2023 project, the overall size of the Unity project folder is about 2 GB, from which the Library folder takes 1.37 GB. And, obviously, the bigger the project, the bigger the Library folder.

The only downsides of the small size of Godot is that you have to download export templates separately (and for all platforms at once). This download weighs about 1 GB.

Complete Editor

Just like Unity, the Godot editor is mostly fully featured, with views for the scene / world, the hierarchy, an inspector, animation tools, etc. I have not explored the full panel, but expect for coding, I never had to leave the editor while building my game.

Godot also includes a debugger, that is perfectible but totally serviceable anyway. However, the main difference with Unity is that the game does not run inside the editor itself. It runs in another instance of the player and the editor / debugger connects to it remotely (hance the Remote view you use to see the current hierarchy, and to inspect objects).

There are also many types of nodes already provided by Godot. Many of my use cases during the game jam have been covered from the get go.

One Node, One Purpose

In Unity, the scene tree is composed of Game Objects, that then hold multiple components to give them purpose. That works but this is not ideal. It becomes quickly difficult to identify which object holds what components, and we sometimes have to create one Game Object per component (generally global managers) and name them accordingly. That clearly defeats the purpose.

Godot took a drastically different approach. Every object in the scene tree is a node, and each node has one purpose only. Each built-in node has a specific icon in the scene tree that helps identification even more (it is probably possible for custom nodes, but I didn’t dig into that yet). Working with objects in the hierarchy has never been easier!

Call Down, Signal Up

This design pattern is not specific to Godot as this is a best practice in many cases.

Basically, within a hierarchy of objects, if you want to communicate things from a parent to a child node, you just have to call a method on one of the child nodes, because parents generally know how their children are organized. In the other direction, as children have no knowledge of their parent’s structure and ancestry, calling methods generally ends up in a beautiful mess.

Enter events. Or signals. Or whatever you call them. Children are supposed to emit a signal or invoke an event to notify one of their parents that something notable has happened. Communication between sibling nodes should also pass through signals or events: one sibling emits a signal, the parent catches the signal, then calls the right method on another child sibling node.

This design can (and should) be implemented in any engine. Unity included. However, it is especially embroiled in Godot’s DNA as, by default, you can’t see the child nodes of a scene nested inside another. In Unity, all children of a prefab are visible by default if you expand the corresponding hierarchy. That often leads to unfortunate connections between GameObjects and components that should never have been linked. By hiding the child nodes, Godot does not train you to connect them in unwanted fashion. If you decide to engage with a worse practice, you have to want it and act accordingly. Therefore, my Godot project instantly felt more organized than any of my previous Unity projects.

Not All Roses

Unfortunately, for me at least, everything is not perfect within Godot.

A Node Path is Not a Node Reference

When using GDScript, Godot will encourage you to use @onready variables. They are basically variables that are initialized when the object is ready to be used. These variables are initialized with a reference to another node thanks to a relative path.

@onready var my_node: Node = $relative/path/to/my/Node

However, as the path to the referenced node is hardcoded into your scripts, they won’t be updated if you change the name or position of the referenced node in the hierarchy, or of any of its ancestors. And if you’re not careful, that’s something that will come to bite you at runtime the next time you run your game. If the problem is in a less frequently tested area, it may be missed. Be careful.

There is no such things in Unity. We have serialized fields in the inspector, but that would be @export variables in Godot, for which the problem doesn’t seem to occur. They are updated by the editor when moved or renamed. I would recommend to avoid @onready variables when possible, especially on complex trees.

A Resourceful Mess

Storing structured data with Unity is simple. Create a class deriving from ScriptableObject, then create an asset based on it, and you’re almost good to go.

Godot has a similar mechanism called Resources. You create a class deriving from Resource and you can then create an asset based on it. However, in my brief experience, this was way more complicated and unstable than with Unity. I had to reboot the editor multiple times to see my changes reflected in the structure of my resources. That may be due to the fact that I was using Rider as an external text editor, but that was very frustrating. In the end, to save some time, I just used JSON files and a simple function to parse them. But I lost the ability to edit them in the inspector.

Lost Time

Speaking of unstability or inconsistencies, I also encountered several issues while trying to setup an external editor, wether it’s Rider or Visual Studio Code. Procedures are well described for the two IDEs, but in both cases, each time I edited a file, I was granted with a box asking me to reload the file or use the one in memory because it had been edited outside of Godot itself. What is the point of defining an external text editor if you can’t reload the files automatically? Turns out there is a totally different setting just for that that is not enabled by default when an external text editor is defined. That should be the case in my opinion.

But, even with that, after having set up Visual Studio Code completely, I was unable to edit my JSON files. Godot would refuse to load them and each time went back to the state it had in memory. I lost half an hour on this strange behaviour, that doesn’t seem to occur with Rider. I haven’t tried to reproduce it since then, so there was maybe a glitch somewhere, but it was definitely not a smooth ride with external editors. Which is a shame because the built-in editor is missing critical tools, notably for refactoring.

Where Are My Sprites?

For my project, I used Sprite2D nodes. I was expecting something similar to Unity when you can create sprites within a sprite sheet in advance and use them directly within your Sprite renderer. For the life of me, I wasn’t able to find an equivalent in Godot and had to fall back to use a texture region, which was OK but way less convenient, especially when you want to change the sprite of your node at runtime. I had to manually input the regions for each of my sprites in my JSON configuration file to be able to do that. What a waste of time.

Obscure UI Nodes

The history of UI components within Unity has been a long-running gag among developers. For a long time, we had no built-in UI framework, and then we got Unity UI during the 4.x version cycle. And several years later, Unity UI was deprecated in favor of UI Elements. But, even now, the new framework is not completely ready yet and not backward compatible. So many people remained with the former so far.

Unity UI is a weird framework with its own take on many aspects of the UI. But it’s functional and well known, even if it has its drawbacks, especially with layouts. However, there is something that it does very well, and this is anchoring. Thanks to Canvas and RectTransform components, you can basically place any object anywhere you like on the screen and it will adapt to any resolution and aspect ratio.

Godot seems to have a similar approach with its UI nodes. But, the anchoring system seemed much more rudimentary to me. I had a hard time with the UI and ended up compromising what I had in mind to adapt to what I was able to do. I used many Margin Containers to position my objects, but for some things, that didn’t sound right. I clearly need more practice with it to see if the problems comes from me or from a lack of functionality in the built-in nodes.

GDScript is Definitely Not C#

I’m pretty sure it will come as a very unpopular opinion, but I am not a fan of GDScript. To be clear, GDScript seems a very capable language and is tightly integrated with the rest of the editor. But it doesn’t align well with my personal preferences.

First, this is a language that uses significant identation. In other words, it defines blocks using indentation. While it is said to make things more readable, in my experience that’s not the case. I’m probably biased after 30 years using C-based languages, but it is really hard for me to identify where blocks end at a glance, especially if you insert blank lines between blocks (I do that a lot to separate groups of closely related instructions).

Second, this is an interpreted language. The Godot editor or the various static analyzers do their job to identify code that won’t compile, but there were a lot of occurences in my code where it wasn’t possible, mostly when using dictionaries or variants, or when emiting signals. Dictionaries can’t be typed, variants can accept every type, and emiting signals seems a place where analyzers should be able to detect parameters types, but they don’t. In these cases, you will identify issues only when running the game. I would really love to get typed dictionaries and a way to parse JSON to a known class so that values you get in both cases are typed too. It reminded my of the dark old times of early PHP 5 in many regards.

Finally, the Godot editor does not provide any unit test for GDScript. There are plugins for that obviously, but in my opinion, it should be an integral part of the editor flow, just like we have the Test Runner in Unity.

My Humble Conclusion

Godot is better than Unity, on many levels. The introduction of C# as a first-class citizen changed a lot of things for me when considering an engine. It would make the transition from Unity way easier for us as a studio, as we could bring with us most of the engine-agnostic code we created over the years. As for the type of games we do at Alt Shift, or for the scope of games I do during game jams, it seems a very good match.

However, there are some things that need to be addressed first, some things that we take for granted when working with Godot’s competitors.

C# support is still experimental on mobile, even though the actual limitations are not explicitly defined in the documentation. Also, WebGL exports are not compatible with C#. That may seem like a minor things, but playing games in the browser has never been so popular, especially in countries with limited access to internet or where app stores are not available. We can’t code our games twice for that.

The several issues I got with external editors have to be ironed out. Due to the limitations of the internal editor when it comes to C#, this is really important. Anyone willing to do serious work with Godot would want to work in a dedicated code editor, like VSCode or Rider.

Also, Godot has to provide an easier way to manipulate an important quantity of data. Resources don’t work well. Parsing JSON files without validation/mapping is not sustainable.

One thing is now obvious, migrating to Godot from Unity is not easy. Not all your experience will be translated in the process. You’ll have to rebuild a significant part of your knowledge base. But that’s probably true to every transition between engines. At least, the presence of C# means you won’t need to learn a new language, only new APIs.

As for me, I will continue to test Godot during game jams in the years to come. It was fun to use and a breath of fresh air to learn new tools. I recommend everyone to give it a try anyway.

A few days ago, I released MFX, a PHP micro-framework I’ve been working on for the past 10 years. Releasing something to the public can be daunting, but in my humble opinion is necessary to bring your creation to its next stage. And, as you’ll see in this post, feedback was very useful.

Story Time

I’ve started programming in PHP in 2004, 20+ years ago. Back then, most web hosting providers still used PHP 4, even though PHP 5 was around the corner. PHP 4 had minimalistic object-oriented programming capabilities and no strong typing. PHP 5 was the answer to that.

The new version introduced so many fundational changes that the transition took a long time. However, by the time I changed employer, at the end of 2008, PHP 5 was well established. PHP was then really popular and, moving towards a more strongly typed language, my interest grew as well.

I stayed in this job for 5 years, until my departure in late 2013. The primary focus of the company was browser games. Therefore, I learned a lot of useful lessons about writing high availability websites and APIs with PHP. This was especially true since most of our tools were developed in-house. Errors were made along the way, obviously, but I tried my best, in my position of senior developer, to improve efficiency and reliability along the years. The company ended up with a battle-tested set of tools and a nano-framework as the core of each one of its websites.

After I left, we decided with former colleagues to create our own game studio: Cheese Burgames¹. We needed some internal back-end tools to support many aspects or our games (localization, game design databases, etc). Of course, I was going to write them in PHP. Nodejs was already a thing, but I could not stand JavaScript (and TypeScript was not mature yet). And so the first stone of MFX was laid.

Fast Forward to 2016

For three years, Cheese Burgames became my sole occupation. During that time, step by step, MFX has seen a lot of evolution. But, as the sole developer in our team of three, I had to handle the development of our games with Unity in C# as well. And MFX remained an internal project. We never actually used it for any of our clients.

But in 2016, after about a year trying to find a publisher for our game Revery - Duel of Dreamers, we had to come to the conclusion that the company wouldn’t go for long anymore. And that’s when I got in touch with my current employer, Alt Shift. I was about to became a senior Unity C# developer only, as PHP was not used in the company. That should have been the end of MFX.

However, a few years later, in 2019, we had to build a back-end and an API for one of our clients and I decided to use MFX. It was the opportunity I had missed so far to validate in the field that my design choices were valid. And MFX delivered! We stopped working with this client a year and a half later due to a change in their priorities, but I had my answers.

The Road to Release

Thanks to that external project, MFX was fine. But it remained an internal tool in essence, even though I started writing some documentation. And after that, we never took a PHP gig with another client. The framework’s code was already available on GitHub in 2018 under a MIT license, but it was pretty much unusable without my support.

So I started to slowly extend the documentation. In 2022, I even worked with a former Alt Shift colleague who wanted to use MFX for the website he was building. He has worked with me on the external project involving MFX and was comfortable enough to consider using it on his own products. I took the opportunity to add support for PHP 8, which became mandatory, and for Composer as well. I also fixed some bugs my friend identified along the way.

Over the past year however, the main road blocks remained the missing parts of the documentation. But, writing page after page, I gradually reached completion. It’s not perfect. It’s probably missing some valuable information. But it’s there. Only remained pressing the button.

MFX 1.0 is Out!

On July 9th, 2024, I released MFX on GitHub, and published some messages on my socials and on Reddit in the PHP subreddit. And boy, I got a lot of feedback. Some good, some even very good. And some not so much.

But that’s the risk I was willing to take. So far, I’ve almost been the sole developer of MFX. I needed a fresh perspective on it. And I was glad to be criticized this way. In the days that followed, I managed to improve syntax consistency, ease of use, security, and even add Docker support.

What’s Next?

Releasing a first version is one thing, but you need to keep it alive. Fortunately, I am at a stage in CiderKit’s development where I will soon need tools to support some aspects of the games. My plan is to recover the source code of the tools I made for Cheese Burgames and update them for the new version of MFX.

Some new features and improvements are also planned for MFX on its own, but the complete list will probably evolve. And of course, I hope some people will try the framework and make some contributions.

July 2024 Update: Since the redaction of this post, Apple has released a sample project that allows building games for the PlayDate with Swift. After a bit of exploration, it turned out it was working very well. Going forward, I will use Swift as my language of choice for the PlayDate with PlayDateKit. Therefore, you should not expect any further progress with this tutorial.

For once, I decided to explore a different platform. SpriteKit isn’t going away, but for some things in my regular job, I wanted to see how difficult it would be to develop games for the PlayDate in C. In case you’re wondering now, no, Alt Shift has no plan to release a PlayDate game any time soon, but we like to explore different things from time to time.

The Setup

During my initial setup of the PlayDate SDK, I ended up with step-by-step guides that are not cross-platform for the most part. Through the official documentation, you can either use Xcode on macOS, Visual Studio on Windows, or CLion on both platforms. At Alt Shift we use both Windows and macOS, so the only viable option there would be CLion, which is paid (and not cheap).

Jetbrains, the developers of CLion also make Rider that we use daily, so I have no problem considering CLion as a very capable IDE. But the cost remains a problem if the tool becomes an integral part of your development workflow on a platform as niche as the PlayDate. You may not recover your investment.

In the past, we used Visual Studio Code on both Windows and macOS to develop our Unity games. Visual Studio Code being as versatile as it is, I was pretty sure it would be great for PlayDate. But I had a hard time finding any tutorial on how to set it up. There are templates but most do not come with explainers. So I had to build one myself.

Here it is!

Disclaimer

This tutorial has not been tested outside of macOS (for now). Furthermore, I only used the PlayDate Simulator so far. Adjustements are probably needed to build and debug on actual devices. I will update this post with additional instructions for Windows when time comes if needed.

Sample Project

I found that the “Hello World” sample project from the PlayDate SDK was a good starting project to ensure that your Visual Studio Code is fine. So I’ll use it for the rest of this post.

You can find it under C_API/Examples/Hello World in the PlayDate SDK folder. Copy it anywhere you want to get started.

Dependencies

Setting up Visual Studio Code for the PlayDate requires a few things only. If you’ve installed all dependencies needed by the PlayDate SDK for the C language, you’ll only need the C/C++ extension from Microsoft (but you can opt for the C/C++ Extension Pack that comes with an additional theme).

To keep things simple, I chose to use plain Makefiles to handle compilation. But your mileage may vary here and you may want to install specific extensions for CMake or any other fancier build tool.

Don’t forget to set the PLAYDATE_SDK_PATH environment variable. You will need it later.

Project Settings

First, we have to add a few options to .vscode/settings.json:

{
  "C_Cpp.default.includePath": ["${env:PLAYDATE_SDK_PATH}/C_API"],
  "C_Cpp.default.defines": ["TARGET_EXTENSION", "PLAYDATE_SIMULATOR"],
  "[c]": {
    "editor.defaultFormatter": "ms-vscode.cpptools"
  },
  "C_Cpp.formatting": "vcFormat",
  "files.associations": {
    "*.h": "c"
  }
}

• With C_Cpp.default.includePath, we add the PlayDate C API folder to the include path to be able to use the PlayDate SDK headers without Visual Studio Code complaining.
• With C_Cpp.default.defines, we set the defines required to compile and debug for the simulator.
• Other settings are here to help formatting .c and .h files.

With the project settings in place, you should be able to get auto-completion running and be able to navigate your code. Though you won’t be able to build. Yet.

Build and Launch Tasks

In order to actually compile the project and run it on the simulator, we need to update two other files.

First, in .vscode/tasks.json, we will add a “make” task. As its name suggests, the task will build the project.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "make",
      "type": "shell",
      "command": "make",
      "problemMatcher": [],
      "group": {
        "kind": "build",
        "isDefault": true
      }
    }
  ]
}

Then, in .vscode/launch.json, we will add a launch configuration that will run the build on the simulator, executing the “make” task beforehand to make sure the build is up to date.

Important Note: Be sure to change HelloWorld.pdx to the actual name of your build when needed.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug",
      "type": "cppdbg",
      "request": "launch",
      "program": "${env:PLAYDATE_SDK_PATH}/bin/Playdate Simulator.app",
      "args": ["${workspaceFolder}/HelloWorld.pdx"],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "lldb",
      "preLaunchTask": "make"
    }
  ]
}

First Run

Now that everything is in place, press F5 to build your project and run it. You should see the console display some messages and after a few seconds an “Hello World” message should appear on the simulator’s screen. If not, then, start again, from the top.

Otherwise, you’re almost good to go. There are only a few more things to set up and call it a day.

Additional Settings

Formatting

While working with Visual Studio Code, you may want to auto-format your files when you’re saving.

For that, you have to add a .editorconfig file at the root of your project. You can either configure this file as you see fit or download this template with my own preferences.

Then enable “format on save” by adding this in the settings.json file:

"editor.formatOnSave": true

Ignoring Some Files

If you’re using git to save your work (And I hope you do use either git or any other of its competitors!), there are some files you need to ignore. When building your game, many intermediary files will be created that should not be committed to your repository.

If you have no .gitignore file in your repository (many hosting providers offer initial templates when creating a repository), create one at the root of your project.

Then, either way, add these lines to your .gitignore file:

build
*.pdx
.DS_Store

Conclusion

You’re now ready to work with the PlayDate Simulator and create great games and apps for the PlayDate. I’ll update this tutorial in due time with instructions on how to build, run, and debug on the actual device.

Documentation for SpriteKit is sparse. Many parts of the framework are pretty obscure. So that’s no surprise if many solutions can be found outside of Apple on personal blogs, or StackOverflow and the likes. However, there are some very specific areas that are even more obscure, with pretty much no information available out there. That’s the case for fonts.

The Simple Way

If you are using the SpriteKit Scene Editor embedded in Xcode, this post won’t interest you much. Fonts are handled pretty easily like on any other WYSIWYG editor. You choose your font, with its specific style and weight, and it appears inside your SKLabelNode as expected.

The only thing you may need to do if you use a custom font that is not pre-installed with macOS is to bundle it with your app and declare its usage to the system. But beyond that, you’re good to go.

A Family Matter

Unfortunately, that’s not the same story if you want to handle fonts programmatically. To identify the font to use on a specific SKLabelNode, SpriteKit provides you with a single property only: fontName.

This cryptic field hides in fact a lot of information. But first we have to take a step back and understand how fonts actually work.

Fonts are divided into families. Each family has a different name. Some popular font families are for example Arial or Times New Roman. Then, in a given family, you have variants for each style (italic, oblique, condensed, etc) and weight (light, bold, regular, etc). Not all font families contain all style and weight variants though. And to make matters worse there is no standardization when it comes to variant names.

For example, the italic version of Times New Roman is called TimesNewRomanPS-ItalicMT. Whereas it is Arial-ItalicMT for Arial. Or Baskerville-Italic for the Baskerville font family. There are similarities, but this is not 100% consistent.

Ask the Oracle

If it wasn’t confusing enough, SKLabelNode’s fontName property accepts two possible values: a font family (ie Times New Roman) or a font variant name (ie TimesNewRomanPS-ItalicMT). If you set the property with a font family, the default regular font variant will be used. But how to guess the font variant name then if you want to use italic or bold, or even both?

If you are using only a few fonts, you can get that information from the Font Book app and use it directly into your code. For that, select a font variant and display its information. In the right panel, you should be given access to an Identifier section (see screenshot below).

Font Book app showing a font variant name

However, in my case, CiderKit is an engine. It should be able to handle any font. If you’re facing a similar issue, that means you have to query the system’s font management thanks to either NSFontManager on macOS or UIFontDescriptor anywhere else.

At the end of this post, there is a Swift script you can use to get the right font variant name for SpriteKit.

You can use it like this:

let myLabel = SKLabelNode(text: "My text string")
// ...
myLabel.fontName = FontHelpers.fontName(with: "Times New Roman", italic: true, bold: false)

This script is currently limited to regular, italic, bold, or bold italic variants, but should be pretty easy to extend if you need to.

#if os(macOS)
import AppKit
#else
import UIKit
#endif

final class FontHelpers {

    class func fontName(with fontFamily: String, italic: Bool, bold: Bool) -> String? {
        getFontName(fontFamily, italic, bold)
    }

    #if os(macOS)

    fileprivate class func getFontName(_ fontFamily: String, _ italic: Bool, _ bold: Bool) -> String? {
        var traits: NSFontTraitMask = []
        if italic {
            traits.insert(.italicFontMask)
        }
        if bold {
            traits.insert(.boldFontMask)
        }
        let font = NSFontManager.shared.font(withFamily: fontFamily, traits: traits, weight: 5, size: 12)
        return font?.fontName
    }

    #else

    fileprivate class func getFontName(_ fontFamily: String, _ italic: Bool, _ bold: Bool) -> String? {
        var descriptor = UIFontDescriptor().withFamily(fontFamily)
        if bold || italic {
            var traits: UIFontDescriptor.SymbolicTraits = []
            if italic {
                traits.insert(.traitItalic)
            }
            if bold {
                traits.insert(.traitBold)
            }
            if let newDescriptor = descriptor.withSymbolicTraits(traits) {
                descriptor = newDescriptor
            }
        }
        let font = UIFont(descriptor: descriptor, size: 12)
        return font.fontName
    }

    #endif

}

CSS have evolved a lot since their introduction in 1996, going through several monolithic iterations up to version 2.1, then being split in many different independent modules for CSS 3 and 4. From a specification point of view, this is bit of a mess. I only need a subset of it though: no flexbox, no positioning.

Why?

Because embarking in writing my own CSS parser, I did some research. Unfortunately, to the best of my abilities, I didn’t find something that really suited my needs. SwiftSoup is a full HTML parser, way too complex for my use case. And others are either not maintained or not Swift packages (and I don’t want to invest anymore in Cocoapods or Carthage). Furthermore, I will probably limit styling to the actual look of the controls and don’t need many of the positioning features of CSS.

What’s In It? What’s Missing?

And then CiderCSSKit was born. For now, it’s mainly a pure lightweight CSS parser.

Here’s the list of existing or missing features:

• syntax validation is implemented, but you can create any property with any value you like, without control (background-image: 10px for example)
• provides easy access to style properties, in bulk or individually
• named colors are already implemented, but any other keyword will be interpreted as a string
• complex CSS combinators (>, +, and ~) are not implemented
• no support for pseudo-classes and pseudo-elements (like :hover, :first-child, or ::first-line for example)
• no support for attribute selectors (like a[target] or a[target="_blank"])
• built-in functions are limited to rgb and rgba
• short hexadecimal colors (#fff for example) are not supported (colors must use six hexadecimal digits)

What’s Next?

I plan to implement ways to extend the capabilities of the parser, notably with a specific model for custom validation and functions. That will allow the use of CiderCSSKit in other contexts than CiderKit’s UI management. I hope that in the future, the package will be agnostic enough to be use by anyone out there. But for now, I have to test it in real situations and improve.

Header image by Negative Space under Creative Commons CC0 1.0

SpriteKit Sample Image from Apple Developer Website

The Objective

In its first iteration, CiderKit is designed to handle isometric maps. SpriteKit provides a tile system than can produce such maps. But there’s a catch. In order to achieve complex level designs, I want to support various elevations in the same level, though SpriteKit is limited to a single plane. It was the first blow.

I also wanted to achieve great control over the lighting, notably over intensity and precise near and far attenuations. However, SpriteKit light nodes are limited, preventing me from providing additional data. And last but not least, SpriteKit lights are by definition 2D lights. Due to the complexity of my target lighting model, I needed true 3D positioning.

In front of these issues, I started designing my own solution. But many challenges were still ahead.

The Plan

I am not entirely sure how SpriteKit handles lighting, but I’m pretty confident it is using a forward rendering strategy. It implies computing lighting as each sprite is rendered, without any regard (and possible optimization) for overdraw¹. Isometric maps with elevation can produce a lot of overdraw, with parts of the level occluding others. This problem can also be wildly exacerbated if you add a lot of visual details. I was looking for a solution that would allow me to use many individual lights, so forward rendering was clearly not the best approach.

I immediately settled for a deferred rendering pipeline. As the name suggests, this kind of rendering method defers the lighting phase at the end of the process, allowing for a single computation per pixel and massively limiting the impact of overdraw. However, it requires several preparatory render passes to gather the necessary information like position, orientation, and albedo. But how to do that within the very efficient but rigid update loop of SpriteKit? I would have to find out.

As I stated earlier, SpriteKit lights are not suitable in my case. The second part of my plan then became the implementation of new custom lights. That opened a lot of additional questions. Should they be SpriteKit nodes or only data abstractions? How many can I use at the same time? With how many associated data?

Deferring The Execution

First step to a deferred rendering pipeline: implementing multiple render passes, each associated with a specific information for the light computation. Each of these render passes produces a projection on screen of the corresponding data, stored in a render texture. This way, the final lighting step will know for each pixel of the screen what information to use.

In any given 3D space, in order to shade a scene, in complement of all data from the lights, you need at least three information: position, orientation, and albedo (the “base color” of the material). In a regular 3D pipeline, you would then get 3 render textures: depth, world-aligned normals, and albedo.

With a perspective camera, you can reverse the depth computation in order to obtain the position in space for each pixel. But, with an orthographic camera like the one in CiderKit, depth is not enough. That’s why I had to exchange depth for a true 3D position render texture.

Unfortunately, SpriteKit does not explicitly allow additional render passes or using multiple render targets. The engine is voluntarilly limited to preserve its extreme efficiency. I had to find my way through the various APIs and dig out the hidden gem I needed: SKView.texture(from:)

The figure below illustrates the successive steps of the process:

The first four steps are done in the didFinishUpdate(for:) method of an SKSceneDelegate, so after animations and physics have been updated themselves.

1. First, there is the warmup sequence. I have to do some global shader preparation. And I disable the objects that should not be considered for the light render passes.
2. Then, I configure the custom shaders to generate normal data and render the included objects into a new texture object.
3. The same is done for positions with a second pass.
4. In the cooldown sequence, the custom shaders are then reverted to their default state, in order to produce albedo data. I also gather light data for the lighting shader that will be applied later. Finally, I reactivate all objects.

The three last steps are handled by the normal SpriteKit render process. Lit objects are rendererd independently of the overlays thanks to this specific scene node layout:

SKScene
  - Underlays container
      - Grid
      - ...
  - SKEffectNode (Lit objects root - holds the final light gathering shader)
      - Map
      - Other lit objects
      - ...
  - Overlays container
      - Gizmos
      - ...

• All active objects but the overlays are rendererd first. Any object that does not use my custom shader will render with the default SpriteKit shader.
• Thanks to the SKEffectNode and the lighting shader, the final gathering stage can then produce actual lighting on the scene.
• Overlay elements can then be rendered normally over the lit objects.

Mimicking 3D

As beautifully complex as this deferred render pipeline can be, it does not provide actual data from the sprites. By themselves, 2D sprites are only that: 2D. For the human eye, they can represent a stylized character, a 3D object, or many other things. But they remain a projection of something on a two-dimensional plane. There is no actual data, notably for orientation or relative position, baked into them. So, I have to provide all of it as supplements.

That’s why lit objects in CiderKit are based on three different textures as illustrated below with the default map blocking textures.

• The albedo map is pretty straightforward. The texture provides the base color (albedo) directly.
• The position map is probably the most complex one. For each pixel, the texture provides a normalized position information. This normalized data is then translated into the world thanks to specific attributes set during the render process. X, Y and Z values are respectively mapped from the red (R), green (G) and blue (B) channels of the texture.
• The normal map is also relatively simple to understand and works almost like in any 3D software, and stores orientation data for each pixel. Each color channel is mapped to an axis. The sole difference is that the normals are aligned with the isometric world instead of locally with the object. That’s notably why, in this example, each sprite representing one face of the blocking is only represented with a single color as they are already aligned with the corresponding axis of the world.

Metal Frame Capture

Adjusting and fixing all the render passes was not an easy tasks and there were many bumps on the road. By chance, all of this has not been done blindfolded. Thanks to the Metal Frame Capture tool integrated with Xcode, I was able to understand exactly where things went sideways and react accordingly. This is a very powerful tool I encourage you to dig into if you’re working with Metal-capable devices.

Metal Frame Capture Graph

Troubleshooting Availability of the Metal Frame Capture Tool

However, if you’re still running an Intel Mac, you may have issues accessing the Metal Frame Capture tool. For some reason, Xcode does not always give you access to it. If this is the case for you, you can force its activation from the scheme editor. Go to Product > Scheme > Edit Scheme…, then select the Run scheme and its Options tab. You should have a setting called GPU Frame Capture. If not already, set it to Metal and the Metal Frame Capture tool should now be available.

The Result

I still have to actually make games out of CiderKit. However, in my humble opinion, visual tests turned out great so far (as you can see on the following video). There are some limitations, like the fact that I am currently limited to 16 concurrent lights during the render phase, but I’m confident all of this won’t be for nothing.

A great art direction with good light control is critical nowadays for your games to stand out of the very populated crowd. This is a first step, won’t be the last, but an important one nonetheless.

Stay tuned for more!

In its early days, Apple (and subsequently the Mac) was a big player in the gaming market. Many important titles (like Myst) and influential studios (like Bungie) were born in the Apple ecosystem of yesteryears. But as time went by, due to many factors, the global Apple market share in the personal computer segment plumeted. And so went its relevance with gaming, as Richard Moss noted in his Secret History of Mac Gaming.

The Secret History of Mac Gaming, by Richard Moss / Bitmap Books

Nowadays, macOS’s market share remains very low. In gaming, it is about 2.5% of the installed base according to the Steam Hardware Survey. That’s pretty much nothing. And yet, most storefronts like Steam, GOG or the Epic Games Store have compatible offerings, with many indie titles but almost no big AA or AAA games.

In 2021, I wrote a piece on Medium about the state of Mac gaming in 2021. Even now that Apple Silicon Macs are there and in their second generation, everything I wrote then remains relevant. Macs were already machines on which you could play. Now that Apple Silicon brought back performance, they are even better gaming machines. So, what’s the problem?

The Offering

The problem is the lack of games. Apple with macOS is pretty much on the same spot Epic was when they launched their Epic Games Store. Confronted with the Steam defacto monopoly, Epic had to find a solution. Their store is still not relevant or profitable for most developers, but they are gradually grabbing some chunks of the market. All of that thanks to exclusivity deals and weekly free games.

Illustration by Alex Castro / The Verge

The parallel with macOS is there too, Steam being replaced by Windows. Microsoft’s operating system can basically play any game. Why on earth would someone buy a Mac to play only a fraction of the gaming catalog? At a substantially higher price even. Current Mac gamers are mostly people that also use their Mac for something else, making gaming one of the cherries on top. Many Mac users who can afford it also have a Windows gaming PC on the side.

Back on the Epic case. Why would you buy a game on the Epic Games Store if you are already a client on Steam? It is less convenient to have two launchers and your collection of games is divided. But all it takes is a free account. The entry barrier is way lower than with console exclusive titles (as you have to buy a $500 console). And even lower if you consider the price of a very powerful Mac, like those equiped with the Max or Ultra chips.

Resident Evil Village

At WWDC 2022, Apple made several gaming oriented announcements that gave us hope for a brighter future. In the same keynote, they notably announced that Resident Evil Village would be ported to macOS as a showcase of the power of Apple Silicon.

And with its Octobre 28th 2022 release¹, Resident Evil Village delivered! Not everything was perfect, but reviews of the port were generally positive. It proved Macs are very capable gaming machines, probably at the expense of Apple paying for the port to be done (even though we have no information of a potential deal of this nature).

But once again, there’s a catch. Resident Evil Village was released a year before on Windows and consoles. This is basically a technical demo at this point. Mac players were thrilled. But they were alone. The same story goes with the ports of Divinity - Original Sin 2. And in the future with No Man’s Sky. All these games are great, but they are not exclusives. There’s not a chance it will improve significantly macOS’ market share.

Apple Arcade

With Arcade, Apple tried to appeal to gamers with exclusive titles. However, for how good these games were, they weren’t significant enough to bring a wide outsider audience to the service. Pretty much none of them were widely expected by players and thus they remained dispensable. These games made Apple Arcade a very good deal for a time, but I don’t expect anyone to actually buy a Mac to play Arcade games, especially as all of them are also available on iOS/iPadOS.

That brings the question of the interest of Apple for gaming on the Mac. As the iPhone and the iPad are huge sellers in the gaming segment (not AAA gaming for sure, but they generate a lot of money anyway), is the Mac still relevant with gaming for Apple in their ecosystem? I obviously do not have the answer, but I know for sure that many people, myself included, would be glad to be able to play more games on their Macs.

The Alternative

Recently, Microsoft announced that they will officially support Windows for ARM on Apple Silicon Macs through Parallels. That’s a great news for users with mixed workflows as BootCamp, the official Apple solution to run Windows natively on Intel Macs, is not available anymore on Apple Silicon.

However, even if this is a very efficient solution for existing Mac customers to enjoy their Mac even more, that does not resolve the main issue of the availability of native games and the overall attractiveness of the platform for outsiders. Plus, Parallels (or VMWare Fusion) is not free. It’s at least $100 to add to the bill.

With Parallels, Apple is pretty much in the exact same situation than linux gaming with Proton and the Steam Deck. The Steam Deck is so good at running most Windows games from the Steam catalog that developers do not have to bother porting their games to linux (even though the Deck runs SteamOS, a derivative of Debian, a linux distribution). Parallels won’t incentize developers to bring native ports of their games to the platform.

And to add insult to injury, you also have many cloud streaming services available for macOS, such as GeForce Now, Boosteroid, Xbox Cloud Gaming, …

The Solutions

Then, what to do? The list of potential solutions is not long in my opinion. If Apple intends to increase the market share of the Mac, pro users won’t help much more. Indeed, the profesional and creative audiences are already there. The main issues, namely performance and lack of connectivity, have been addressed respectively with Apple Silicon and the various Mac redesigns. Now, it is the consumer market that needs to be addressed. And games are a huge part of it.

Commissioning ports of important AAA games is good from a technological stand point. But the timing is not relevant. Releasing Mac ports several months or years after the initial release won’t improve the situation. The player base is already constituted elsewhere. At least ports need to exist from day one.

Another true game changer (pun intended) could be exclusive titles, timed or not, coming from franchise that have an already installed audience. If Apple could get several big names, early adopters of such games would be forced to buy a Mac. Is this a good practice? No. As a PlayStation player, I was so disappointed when Microsoft got Rise of the Tomb Raider exclusive to Xbox consoles for a year. I even considered buying a Xbox One. I didn’t in the end as I was already too busy to play all the games in my back catalog, so I waited. However, some players were converted this way. In the same vein, remember when Microsoft snatched Halo, which was originally planned as a cross-platform Windows+MacOS game?

Now What?

The “gaming on macOS” situation is rather complex. The market share won’t increase by magic. Apple has to do something but it is difficult to know what exactly. Technologically, the future is bright. Now bring on the games!

Header image by Trusted Reviews under Creative Commons 4.0

I expect most macOS, iOS, or tvOS developers to use Xcode as their main development environment, especially if they’re working with Swift. You can use other IDEs with other languages, like Xamarin or Unity for example, but that’s not the “Apple way”. This obviously also applies to anyone working with SpriteKit. In this post, I will detail what’s good or wrong with Xcode support for SpriteKit. And there’s much to say!

Available Tools in Xcode

As for many file types and other frameworks like SceneKit, Xcode comes preinstalled with some built-in editors for SpriteKit. The goal is to help authoring SpriteKit projects visually, pretty much like you would edit your scenes in the Unity editor for example. Here are some of the most useful.

The Scene Editor

With the SpriteKit Scene Editor, you can basically build and animate your scenes visually directly from Xcode. I’ve used it for SKTetris and it can be pretty functional. You can add to the scene most of the built-in nodes like sprites, labels, shapes, or even tile maps. Your scenes are then stored in .sks files that you can load directly by name from your app’s bundle.

It is even possible to setup GameplayKit’s entities and components from the Scene Editor. Each type of node comes with its own custom inspector that allows you to control their look and feel. Animation is another part of the Scene Editor. Indeed, the bottom part of the editor allows you to create custom animations, based on SKAction, for your various nodes. Finally, SpriteKit scenes being nodes themselves, you can easily create isolated scenes for some elements that you want to reuse or load inside another scene. It is also a very good tool to create UI layers for your SceneKit project, as you can use a SpriteKit overlay if needed.

The Asset Catalog

Pretty much no scene would be whole without some sprites, right? That’s where the Asset Catalog may come handy. Indeed, it is the place to store your sprites, individually, or eventually ask Xcode to combine them into atlases for optimum performance. You can even store them in different resolutions for different screen sizes if needed. The Asset Catalog will also handle texture compression or hardware classes (like memory or GPU configurations) to help you provide the most adequate texture to any device in the whole Apple line-up.

The TileSet Editor

As its name suggests, the TileSet Editor is designed to manage sets of tiles for various map types. You can configure tile groups for complex 2D, isometric, or hexagonal grids. The tile sets, groups and rules are then directly usable in the Scene Editor with a Tile Map node. The TileSet Editor works in tandem with the Asset Catalog as the sprites have to be part of a catalog before being used in tile groups.

The Particle System Editor

Almost as self-explanatory is the Particle System Editor which helps setting up particle systems visually, that can be then used inside the Scene Editor or programmatically afterwards. Many parameters of the particles can be tweaked, from the lifespan, the speed, the scale, the rotation, or the color over time.

Not Every Love Story Ends Well

Unfortunately, for almost every good thing Xcode brings to the table, there are drawbacks and inconveniences that make them pretty much unusable in practice.

The Trusty Asset Catalogs and TileSets

The Asset Catalogs and TileSets are probably the most valuable assets in everything Xcode has to offer. First, they are properly serialized with JSON files and folders so it is very easy to work with, even in external tools. And the fact that they are humanly readable make resolving conflicts much easier when working with versioning in teams.

However, not everything is perfect. Asset Catalogs notably misses some key parameters like the filtering mode (all textures are created with linear filtering), constraining you to handle nearest filtering mode through code when you use it, notably in pixel art games.

Having more control over the compression format would be great too. Automatic or Lossless is not enough, and allowing access to the wide variety of formats handled by Metal would be nice. For example, 16-bit pixel formats can be very useful to reduce application size without sacrificing quality in many cases.

One last thing is that we have no control over the generated atlases. There is no export of the actual coordinates of the sprites, making almost impossible for additional data layers (normals, emissive, …) to match the exact position for their own sprites.

Double Trouble Scenes

The Scene Editor is very useful to visualize your scenes. However, don’t try to work in teams on complex scenes (or on particle systems, whose files share the same issues). .sks files are generated as binary files. If two people work on the same file at the same time, you are pretty much out of luck if you have to resolve conflicts. Unless you convert them to XML. Because, under the hood, .sks files are just binary property list files with another name.

With this simple command-line, you can convert them to XML:

plutil -convert xml1 -o my-xml-scene.sks my-binary-scene.sks

I tried a few years ago to convert .sks files to XML to see if Xcode would open them. But at the time, it was immediately crashing. This problem seems now to be resolved as of Xcode 14.2 but if you modify your scene file and save it again, it will fall back to binary. That’s pretty inconvenient. There may be a solution to explore with git’s pre-commit hooks, but Xcode should allow one way or another to keep .sks files as XML files. Even settings the file type as XML in the file inspector doesn’t help.

Another broader issue I have with the SpriteKit Scene Editor is the lack of customization. The editor allows you to assign GameplayKit’s components to nodes in the scene, and you can declare some properties as inspectable that will appear in the user data section (thanks to the @GKInspectable attribute). However, this does not work well for custom types or even enumerations. And you can’t add validators or custom fields like you would in Unity’s custom inspectors.

Both of these issues are huge hits for productivity as they can become regular annoyances or total blockers.

The Impact on My Personal Workflow

When I started working on CiderKit, I comtemplated my options. But everything mentioned above geared me towards finding custom solutions. Furthermore, the built-in tilemap node for isometric maps is fairly limited compared to what I planed: there’s no elevation support.

Also, even if I still use the Asset Catalogs for storing my textures, atlases themselves are created in an external tool beforehand (at the time directly with Aseprite, but most likely thanks to TexturePacker as the pipeline will mature). Sprites are then generated programmatically based on custom JSON files describing the atlas structure.

Obviously, all of this requires a lot of investment in time and effort to bypass the weaknesses of Xcode’s own implementations. But that also gives me a lot of control regarding data management and optimization, producing way better results in the end.

This is not a surprise that Apple does not invest a lot in SpriteKit in regards to the small community of developers behind it. I am even grateful that SpriteKit has not been deprecated, and I am firmly crossing my fingers it won’t happend anytime soon. But the stack that runs under the hood is very efficient, if not perfect, and we can produce great things with it anyway.

The tools are not everything. The people wielding them are important too.

This post is a direct follow-up to my 2022 retrospective. This time I will lay out my goals for the new year, regarding my projects and this website.

Post More Often

Six posts in 2022 is not nothing. But in my opinion, it’s not enough. I’m not aiming for quantity over quality though. However, I should be able to publish more often without sacrificing content. Good regular content probably requires planning and that’s exactly what I will do. I already have six other posts in the pipeline and hope to publish once every two weeks going forward.

A few examples:

• Lighting with CiderKit
• A Formal Introduction to MFX
• Work-Life Balance is not Binary

Updating My iCloud Implementation

Almost since its initial release, Nihongo no Kana has always supported iCloud synchronization accross devices. However, the current implementation uses deprecated features and I have yet to find a replacement, as no explicit upgrade path is provided by Apple. This is the least likely update to happen this year as it will require a lot of research, trial and error while implementing, and testing to ensure a consistent experience to the users. I have to admit that I’m not looking forward to this task.

Releasing MFX 1.0

Last year, I froze the source code of MFX while planning a 1.0 release. However, a big part of the documentation is still missing. My plan is to complete the missing pages and proceed with a formal release before the end of the year. This is doable, and MFX can make a very good tool for writing fast and efficient PHP websites or even APIs.

CiderKit

A lot of things happened with CiderKit last year, and a lot will happen this year. However, The Untitled Project remains mostly undefined at this point and will probably end up being a multi-year journey.

How can I be sure I’m moving in the right direction? I can’t if I’m waiting for the final release. And that would be stupid. So my plan is to release smaller incremental games, for which I build tools that can be reused accross projects, expanding the scope of CiderKit progressively.

My main focus this year will be around UI, as the first of these smaller games should not need much more on the sprite assets side, now that I have animation tools at hand. Expect news and screenshots all year round, and maybe a release at the beginning of 2024.

Six Months From Now

The start of the summer holidays, at the beginning of July here in France, will be a good point in time to check on these goals, to see how many have been reached and how many won’t be fulfilled.

So stay tuned!

Header image by Jernej Furman under Creative Commons 2.0