MatchOOlu

Test your memory. Test your dexterity. Explore your mind.

Development History

MatchOOlu is a card matching game written in Java using the libGDX framework. It also utilizes Ashley, a libGDX specific implementation of an entity component system (ECS). I am Ultivanius, and I was the sole developer and publisher for this project. The game design, code, graphics, sounds, music, and marketing material was all created by me.


Why ECS?

Entity component system (ECS) is a code pattern that can provide several advantages when building video game code and is being used in more and more game projects, especially since engines like Unity have made their ECS systems production ready. One of its biggest advantages is the efficient processing of large numbers of game objects. MatchOOlu does not really have a large number of game objects however, so why would it use ECS? Why indeed.

The answer is that MatchOOlu was not intended to be a commercial product at inception. It was intended to be a learning exercise. Unity had been telling everyone about how great their ECS system was (DOTS with Burst Compiler) for a couple of years, but the system was not yet production ready. As I was interested in the ECS pattern and saw that there were several frameworks across different languages that provided an ECS implementation, I decided that I would start a small project to get a better grasp on the concept. A card matching game was one of the first projects I thought of. I figured that it would be simple to write and let me focus on learning ECS and possibly a new language.

After a bit of research, I discovered Ashley, a simple ECS implementation written for libGDX. I was not familiar with libGDX, but it sounded like a neat framework allowing cross-platform development using Java or Kotlin. I had been working with C# in Unity for awhile, which is pretty similar to Java, so I decided that the Ashley/libGDX combo would let me focus on learning ECS and would make a great choice. I was also interested to see how easy it would be to deploy a project on multiple platforms with as much shared code as possible.

Why a commercial release?

With the project and frameworks selected, I decided that it was time to prepare a game design document. I would never suggest that learning projects such as MatchOOlu should have game design documents, but I honestly just love writing them. Brainstorming ideas and trying to come up with modes and mechanics is so much fun for me. I actually have quite a collection now and continue to make more. Hopefully more of them will turn into finished projects.

As my list of ideas grew, I suspected most of them would never actually make it into the game, but I began to wonder if any matching games had implemented some or all of the things that I had come up with. After all, whenever I think of an idea that seems novel, I remind myself that I am probably not the first to come up with it, but there is a chance that no one has implemented that idea in production yet. I began looking at every matching game that I could find. Nearly every single one was a very simple implemnentation with almost no options when it came to decks, tables, layouts, or modes. Perhaps such a game existed, but since I couldn't find it, any such game might have a marketing problem. Perhaps the idea of a fully featured card matching game was too simple for most developers to consider. Huh.

After a few days of mulling it over, I decided that this learning project would now be a commercial game and that I would still use Ashley ECS and libGDX to write it. MatchOOlu was born.

How much work could it be?

MatchOOlu started development in 2022. I worked part-time on it before switching to full-time development in late 2023. As expected, the game logic itself was very easy to write, but the fact that this was now a commercial project added quite a bit of work, including work on assets or features that were cut from the game. The largest portion of time was probably dedicated to creation of the various assets. Although the final designs are intentionally simple, there were many iterations of each deck and layout that considered how each aspect would test a player's memory. Also, although I enjoy it, I am quite slow at composing music.

This project was a great reminder of how even a simple game concept can take quite a while to solo develop when it becomes a commercial project. I think I could easily write a simple card matching game in Unity within a few hours, but when adding multiple overlapping game modes, multiple decks, multiple tables, a custom OST, custom sound effects, multiple difficulty options, a custom ECS friendly UI system, a custom model batching system, a custom shadow solution, a level select system, a records system, a notification system, a multi-platform save system, multi-platform audio/display options, a help system, achievements, unlocks, and a custom entity pooling system all while trying to polish things to modern commercial standards, come up with and implement a marketing plan, and use a new framework and coding pattern, timelines tend to balloon a bit.

Despite being a bit amazed at how long such a simple sounding project took, this was a great project to work on. I now have a pretty good grasp on the ECS pattern, have a better understanding of the how's and why's of 3D batching, and improved my coding, graphics, and audio production skills. I've also learned quite a bit about how my short-term memory works!