Hey guys, it’s been a long time since I was in the habit of writing longer blog posts.
Social media has made me very lazy, and now with AI generated slop taking over many platforms, I think it’s more important than ever to start making sincere and long-form content again. Maybe I can even turn some of my writing into YouTube videos later…

Anyway, it’s often said that “limitations breed creativity”, in the sense that various constraints on a project will force you to find creative solutions to problems with whatever resources you have available. You can see this quite well in a lot of indie games that can’t afford to do everything that AAA games do, so they focus on doing a few things very well, and if you’ve played retro games, you can see how hardware limitations of something like the NES console dictate the design of the games that run on it.

In my case, the games I work on are also designed around my personal limitations, rather than me trying to chase the coolest thing that’s trendy at the moment.

My earliest browser games – such as The Kitten Game, Mecha Dress Up Game, and Brawl Royale – were basically glorified PowerPoint presentations: You click a button, and an animation plays somewhere. There were a few variables keeping track of score and stuff like that, but for the most part, the state of the game was just tracked by whatever animations were currently playing. That’s all I knew how to make at the time, since I had some animation experience, but very little programming experience. All of these games were focused on having cool, catchy or even violently shocking animations, while the gameplay was very primitive. They were also all quick to make – about one month of work each. But it worked. That was enough to make fun web games at the time (around 2008). And even today you can still make games that are basically PowerPoints – such as visual novels – if you have an interesting premise and some good design skills.

The next step from there was to learn programming! While I was studying computer science at university, I was still making browser games in my free time. They taught as Java, which wasn’t too different from the ActionScript 2 and 3 languages that Flash uses, so it was just a case of me skimming through some textbooks to see how object oriented programming concepts were implemented in Flash’s languages. You can track my progress quite clearly in the first 3 Epic Battle Fantasy games – each game really pushed the limits of what I could program at the time. Making a Final Fantasy 6 style RPG was totally impossible for me – I could design one, but I still didn’t have the programming skills to pull it off. So each Epic Battle Fantasy game added a few more basic mechanics as I got better at programming: Starting with in-battle turn-order and move selection, then adding level-up perks and more character customization, to finally adding an explorable overworld and more detailed menus for item management.

Gradually ActionScript 2 fell out of favour for the newer, faster and stricter ActionScript 3. It was like going from JavaScript to cleaner Java code. I had to suddenly get serious about organising my code, since ActionScript 2 let you get away with some very sloppy coding practices. Anyway, my next few projects started to get more technical. Bullet Heaven and Adventure Story were action games now – not turn-based – so performance mattered. Animation quality was scaled down as I focused more energy into optimizing performance and testing the limits of what a little browser game could handle. I got to know Flash lot better – what the performance bottlenecks were, how to organise object classes neatly, and just generally getting comfortable with programming anything I wanted in ActionScript 3.

Epic Battle Fantasy 3 was at the very limit of what could be done with very sloppy, unprofessional code. So now that I had a bit more experience with good coding practices, I could make Epic Battle Fantasy 4 an even larger and more ambitious game. In fact, it was perhaps a bit too ambitious for the browser game market, which declined massively while I was working on the game, and mobile gaming took its place. Problems such as browsers deleting your save files and it being quite a large download also plagued the game. But eventually, and luckily, it was allowed to be published on Steam, and I saw more success there than I ever had before. So I was getting to the stage now where I really had to be aware of and consider what worked for each gaming platform.

Bullet Heaven 2 is a bullet-hell shoot-em-up, and it was an experiment in using Flash’s hardware-accelerated engine, called Stage3D. Flash graphics were generally rendered by the CPU, which is why they’re so slow, but it also makes working with them much easier. Using Stage3D meant you could do some very ambitious graphics using the GPU if you put in the effort to code them right. So I started this project by testing out how many bullets and other particles Flash could reasonably display on screen, and it turns out, a few thousand is no problem at all if I make correct use of spritesheets and a low number of GPU calls. So I built the game around that concept. I also learned a bunch about object-pooling, and other memory management practices, but unfortunately was too lazy to implement all of those correctly, so the game stutters occasionally when the garbage is collected. Overall, the game could have used more time in the oven, and it wasn’t my most successful one, but I learned a lot!

Something worth mentioning about all the EBF games is how Flash’s performance limitations influence their design. This is why there’s no dynamic camera moving around in battle, and why you’re permanently limited to 3 characters on your team. This is why the world map is broken up into small, dense sections like a GameBoy Zelda game. Regular Flash graphics works best if there’s only animation happening in a few parts of the screen at a time, and background stuff can just be cached in place. Most of the places where the games slow down are because I broke the rules and did some very inefficient effects. There are advantages of course – I don’t have to worry about memory management or asset resolutions, since Flash uses vector graphics. (more on that later)

Epic Battle Fantasy 5 was my first EBF game made specifically for Steam, and I was also a financially stable and experienced programmer now, so a lot of limits were off the table, and new opportunities arose. It was a question of how polished can I make the gameplay from previous games, in a reasonable amount of dev time? I figured I could put up with about 3 years of work before I went insane, so that’s what happened. Some new design goals were:
• Make the game polished enough so that people will be happy to pay up-front for it without needing to play a free version first. So this meant: polished, consistent graphics, a catchy trailer, and 98% positive Steam reviews.
• Fill it to the brim with content so that people can keep coming back to it for years, and no one can say that it was priced too expensive.
• Reboot the story in a way that new and existing fans will understand it.
• Take advantage of new social media platforms like Discord to really leverage community involvement: feature more fanart, get feedback on balance, support mod development, etc.
• Translate it to an ambitious 12 languages with the help of the fans!
(Chinese in particular turned out to be a really big deal)

All of that went very well, and the game was a huge success. The main issue is that I don’t know if I ever want to work on any project of that size ever again, because on top of those 3 years, I also spent another year making an update and then a mobile port. So in future, a new limitation will be to keep the work interesting for myself by doing as many things differently as I can.

Finally, the game I’m working on now – Matt’s Hidden Cats – is built mainly with two goals in mind: to take advantage of Ruffle’s strengths, and to be a casual game that anyone can play – including my parents and the children of my friends.

Ruffle (a Flash emulator) has been in the works for a few years, but only in the last couple of years has it become viable for running ActionScript 3 games. What Ruffle is exceptionally good at is rendering Flash’s vector art using the GPU, which is something that the original Flashplayer only did on mobile devices. Flashplayer on PC used the CPU, which you’ll know isn’t ideal for drawing graphics – it works okay in a small window for browser games, but really starts to slow down in HD resolutions. With Ruffle, I finally had access to a game engine that renders vector art very fast, even at high resolutions – I don’t think there’s anything else like it. And since I’ve been using Flash the whole time, I didn’t have to change my work flow very much.

What this allows me to do is to have tons of animations on screen with unlimited resolution, and a hidden object game can really take advantage of this, as the genre is known for having very detailed levels, and the ability to zoom in and out. Some of the hidden object games I’ve played have issues with graphics becoming a bit blurry or pixelated when fully zoomed-in, and this leads to a bad experience when trying to find very small items. You can overcome this by making all of your assets very high resolution, but that of course increases the hardware requirements for the game. Vector art doesn’t have this problem – it’s always sharp!

If you’re not familiar with vector art, you should know that it doesn’t use pixels – it’s not a bitmap. It’s a mathematical representation of how the computer should draw lines and shapes, and outside of Flash games, it’s pretty rare to see in 2D games. (it’s conceptually similar to how 3D shapes are drawn)
You’ve probably seen it used in map apps.

Anyway, the development of Ruffle opens up a lot of new possibilities and makes Flash games with vector art viable in the current year on modern hardware, which is pretty cool. And the tech is only going to keep getting better, since it’s a work-in-progress.

The second goal of Matt’s Hidden Cats is to be a good game that even non-gamers can easily pick up. I haven’t seen many good examples of this since the earlier PopCap stuff like Bejeweled, Peggle, and Zuma. Now that mobile gaming has taken over, most casual games are free-to-play and ruined by predatory micro-transactions, and are artificially designed to keep you coming back every day indefinitely. Matt’s Hidden Cats won’t insult your intelligence – you get a complete game with hand-made levels that you can play at your own pace.

I’m aiming to address a lot of the gameplay problems that other hidden object games have. Here’s some examples:
• A lot of them have very limited hint systems: sometimes you have to wait a frustratingly long time to receive a hint, or sometimes the hint just isn’t very helpful. In Matt’s Hidden Cats you’ll have options to change how often you can use hints, and the degree of helpfulness they offer, so you can make progress at whatever pace suits you.
• Often the games become more frustrating as you try to find the last one or two items in a level. To address this, items you’ve found remain circled, so you can clearly see in which parts of the level you haven’t found anything in, which really helps narrow down where the remaining items might be. It’s a subtle hint that players will probably feel smart about exploiting.
• There’s usually no difficulty options in these games! Most puzzle games go for a one-size-fits-all approach, which will exclude some players, and it also means that once you complete a level, there’s not much point in ever replaying it once you know the solution. In Matt’s Hidden Cats there are 3 difficulty options, with a different set of goals to find in each. Easy mode is for younger kids, Normal mode is not trivial but also not challenging, and Hard mode is for anyone who really wants to dig in deep and spend some time getting to know every nook and cranny in the game.

This aspect of game design applies to all of my other games too – I look at games in the genre, take mechanics that I like, and change things that I think should be done differently. Maybe this won’t lead to a completely groundbreaking and innovative game, but it means that my games will be familiar to fans of whichever genre, and the mechanics have already been proven to work in other titles, so I don’t have to reinvent the wheel and spend a lot of time trying out completely new concepts.

You’ll probably have seen by now that a lot of indie game projects out there fail because the team doesn’t have the experience or resources to pull off what they had envisioned. It seems kind of obvious, but I think you should strive to design a game based around what experience and resources you currently have, rather than trying to make your dream idea work at any cost. And even if a project doesn’t turn out how you wanted, there should still be a meaningful place for it in your portfolio of work. For me, even if a game doesn’t turn out to be financially successful, at least it was a good learning experience.

Anyway, that’s all I’ve got to share for now.