To expand on some of the thoughts from my previous rant on nim, here’s a tier list I made. Yep, it’s going to be my garbage opinions! But it also includes my (admittedly subjective) first-hand experience with using these frameworks. I’ve used some for years, others just a week. And it includes a few engines and not just frameworks. So there 🧐

Criteria

How can you judge anything without clear criteria? Mine are quite specific; I am interested in making 2D games, for both jams and long-term hobby projects, so the results will seem heavily skewed if you have different needs. I have made 3D games in the past, but it’s not my cup of tea. I may expand on why I’m not interested in a future post. I’m also really keen on frameworks that are great for game jams - I’ve written about that in the past. In no particular order here are things I look for:

• Learning curve
• Quality of documentation and examples, ease of troubleshooting in general
• How easy it is to package, including web export
• How fun it is to use, vs. fighting with instability and quirks
• How powerful and flexible it is

Also, some of these frameworks are super-specialised. I try to be fair here, for example if a framework is specifically made for VN games, I’m only going to judge it by how it can make a VN game.

Last but not least, I only list frameworks which I’ve at least attempted to make a game with.

The List

• Phaser: this was my go-to jam engine and I’ve used this for many years. The examples website is excellent, and being a web framework, is great for jams. I stopped using it only because I found something even better for jams, and for other purposes, a web-only framework isn’t ideal. Still for what it is, it’s great.
• TIC-80: my weapon of choice for game jams. The limitations are perfect for jams as it’s insanely easy and fast to get something playable, and with the cheap pro version, collaboration is also easy. It’s so nice for jams that I wrote a whole post about it.
• Love2D: on the surface this seems like a bog-standard 2D game framework, but being Lua, a scripting language, the packaging is genius - you can put your code in a .love file, and it can run on any machine easily. It also has a pretty big and dedicated community, with extensions for doing a lot of things. I take marks off because of Lua, a weird (in a bad way) language, and a lack of native support for web export, crucial for jams. However on those fronts, I’ve been looking into using MoonScript + a web export pipeline, which could make this an awesome option.
• Unity: credit must be given for how insanely popular Unity is, which gives it a huge community, lots of resources for learning, and people to work with. Unfortunately it’s also very buggy, plugins randomly break with new versions, webGL export is always a pain, and wants to force you to do things a certain way.
• SDL2: so lightweight calling it a “game framework” is a bit too charitable, but there’s no denying the large number of games, especially retro games, that have been modernised thanks to this library. I’ve made a few simple 2D games from scratch using this, and that’s pretty much all it’s good for, when it comes to making a new game.
• MonoGame: I used this for a major project more than a decade ago (when it was XNA). At the time it was fantastic, as there was nothing quite like it - a simple yet powerful framework, that could target both PC and console, and supported by a large company that makes games. These days it’s still decent, with some good games still using it, but it does not offer any large advantages for the newcomer.
• OpenFL: I must admit I’ve never actually managed to make anything with OpenFL, but I really wanted to get into it. There are some really nice games made with this and Haxe, but the dev environment is not easy at all to set up. Back in the day, the promise of having a single language that transpiled to C++ for efficiency and JavaScript for web was really enticing, but now emscripten is so widespread that most good game frameworks support web export as a first class feature. I don’t really have a good reason to revisit this platform anymore.
• SFML: I consider this SDL-for-C++, although it’s a bit better and a bit worse. Better because it provides a few more nice features than SDL, worse because it’s not as well designed and built, and in the end you will still need to write most of your game yourself. Even if you need to use C++, there are better options out there for making games.
• Cocos2d: I’ve only used this briefly in a prototype, but nothing really stood out. Doesn’t seem that popular these days, so there are much better options out there.
• Pygame: Python is a fantastic language but its games offerings are woeful, due in large part to pygame. It’s quite easy to get into thanks to Python, and there are nice resources out there to get started, but it’s after the initial experiments where things fall apart - the terrible deployment process, lack of serious extensions or 3rd party games libraries, and until recent years, pygame was still based on SDL 1.x which could not do high definition at all. Don’t be fooled by how easy this framework is to pick up - it’s not much more than a nice wrapper around SDL.
• libGDX: this framework has been around for a while, and sure, it seems decent and is mature. I have no interest in coding in Java however.
• nico: I wrote more extensively about this game framework before, the tl;dr version is that this seems nice, but is very niche, and given the niche nim language and lack of maintenance activity, it’s hard to recommend this to anyone.
• Your own engine: almost a joke option, but it’s here because I’ve done this before. Just don’t do it.
• Construct2: I briefly tried this framework out to make a prototype, and discovered this kind of drag-and-drop game making is totally not for me. I would much rather code games myself, since I know how and it’s way more flexible. In theory you could make great games with it but judging from the typical Construct game (i.e. made by non-programmers), they’re nothing special.

Honorable Mentions

I haven’t tried the following frameworks but they are interesting and I would definitely give them a go if I had the opportunity.

General Purpose Frameworks / Engines

• Python Arcade: I came across this while looking for an alternative python framework than pygame, and was impressed by how it seemed to do everything right. The framework is well designed as a games framework first, with useful libraries like tilemap support, rather than a thin wrapper around SDL. Two reasons made it less enticing for me: it is still python which means it doesn’t package well, and pygame 2 adds SDL2 support which finally made it performant on HD resolutions. But if I had to make a game in python this would be my first choice. Possible Tier A
• Godot: When this first came out there was a lot of fanfare about how this would be the open source Unity-killer. Years later Unity is still going strong, and Godot has a (relatively) small but healthy community, and is a regular choice among game jam entries. I’m not so interested in using its GDScript language, nor in learning a game engine, but otherwise this seems like a solid choice. Tier A-B, depending on how it compares to Unity
• GameMaker: This popular and venerable 2D game engine seems like a totally legit choice for making games, with scripting ability so you’re not so limited to what the engine itself can support. Two reasons why I haven’t looked into it: it’s paid and not open-source, and its scripting language is proprietary. Still, recently it has started to offer a free version, so it could be worth looking into. Tier B probably
• Unreal Engine: Never had an interest in this, as it seemed to heavy to get into. Plus it’s like 12GB, so no thanks. Tier D, not for me
• Allegro: This is an old 2D games framework, originally designed for the Atari ST, but later being ported to modern platforms. It is pretty niche these days but there are a fair few quality games from the 90’s and early 00’s that use this library. It’s not bad as a 2D games framework, so I’m open to learning more about it if I ever decide to tinker on one of these older games. Tier B, only good for old games
• PICO-8: The biggest fantasy console, with a community that dwarfs its rivals. It’s pretty good, although personally I prefer the open-source TIC-80, but if I had to work on a team that uses PICO-8, I wouldn’t mind learning about it. Tier S-A, I just prefer TIC-80

Genre-Specific Frameworks / Engines

• Solarus: An engine specifically designed for Zelda-style action RPGs. For such a specific purpose, this engine is surprisingly polished and active, with several great-looking games made with it. I love seeing bespoke engines and frameworks like this, as it gives you a huge leg up over a general-purpose framework. If I had to make an action RPG, this would be one of my top choices.
• Ren’Py: This VN framework is proof that you can get great results if you focus on doing one thing and one thing well. Many successful projects use this framework, and although I haven’t used it directly, I have worked on teams that used it, and it seems really easy to use. Unfortunately VNs are not for me, but I have no reservations about recommending this.
• OpenRA: Red Alert has a huge following, but the makers of this open-source remake had the foresight to make the engine generic so that it can support many other RTS games. Now OpenRA drives many mods including KKND, Dune 2000, Tiberian Sun and Red Alert 2. Having tried my hand at making RTS games before, I know how much work there is in making a playable game in this genre, so OpenRA does most of the hard work for you.
• RPGMaker: For making a retro RPG game there is no better way. Similar to making RTS games, there is a surprising amount of work in making the basic mechanics, so a tool like RPGMaker lets you focus on the fun parts - character design, story writing, map editing - than the mechanics and UI. I’ve seen alternatives but none approach the quality of RPGMaker. I’m not really interested in making RPGs myself but if I were, this would be a solid choice.

I have no experience with these frameworks but if they work as well as they seem, they could all be Tier S or A.

Final Thoughts

Game frameworks have come a long way and yet in many ways still have a long way to go. On the one hand there are lots of cool specialty frameworks making it easier to make certain types of games than ever before. On the other, industry-stalwarts like Unity are still a bug-ridden mess to use, which is very disappointing given how popular they are and how much better they could be.

New tech is always hype-y but the game dev world seems particularly bad; new frameworks and engines that over-promise but then can’t do really basic things is an evergreen meme. I am cautiously optimistic that, in the long run, the wheat will separate from the chaff and we’ll get some truly outstanding options in 10 years time. Here’s to hoping!

For a number of years, I’ve been looking for a great new programming language to make games with. When I came across nim, it felt like a breath of fresh air and my search seemed to be over. However, after trying it for a month or so, I have sadly concluded that it’s not the right language for me.

Disclaimer

Nim is a great language, in fact out of the languages that have come onto the scene in the last decade or so, nim is one of the more promising. This is not meant as a critique of the language overall, only that in its current state, and for my purposes, it is not the right choice.

Why look for a new language?

When it comes to making games, I’m a bit of an all-rounder these days, but I’m still a programmer by trade, and it’s what I’m best at. Writing code is what I do, and care most about, and the current state of game programming leaves a lot to be desired:

• Good, established game frameworks often use old languages like C/C++, which lack modern features or aren’t as nice to work with
• Python, arguably the most popular language and which is fun and productive, but cross platform deployment is still an afterthought, with no standard, battle-tested method
• Modern JavaScript / TypeScript are also nice to work with, but is browser-first, and on desktop tends to be laggy and bloated
• Unity, the 800-pound gorilla of game engines, uses C# which is a good language. But the experience of making games in Unity is very much about wrangling with an engine, rather than coding in C#.

This leaves a family of less-popular game frameworks for all sorts of languages, including libGDX for Java, XNA for C#, OpenFL for Haxe, Love2D for Lua and so on. Because their userbases are much smaller, they tend to be less polished and capable, but at least there’s usually one for your favourite language.

Thus the choice for me boils down to:

• A good framework that uses an old language
• A good engine that is highly opinionated and frustrating to work with
• A good framework that is suboptimal
• A suboptimal framework in a good language

As a programmer, I could deal with the last option the best, and this is where nim fits.

Nim for Games

Nim is a great language, at least on paper. It is compiled making it fast, but also borrows great features from languages such as Python, making it a nice language to work with too. It can even compile to a JavaScript backend, which means it supports the web as a first-class platform.

In practice it is a bit quirky and has a learning curve. It uses var, let and const, but in ways that are quite different from what you might expect if you came from say, JavaScript. Its documentation is reminiscent of early-2000s-era language docs, and representation on stackoverflow is sorely lacking. Its choice to take features from Ada/Modula, two very uncommon languages, seems arbitrary and will trip up most learners, for example in its case/of statements instead of the more well known switch/case. And its pass-by-value/pass-by-reference system is something I still haven’t gotten the hang of. But overall I still found it good, and most of these issues are nitpicks and quite understandable for a new language, and would probably be easy to overcome once one becomes familiar. I certainly found it faster to learn than golang, which is much more opinionated and arbitrary.

One key shortcoming is the lack of IDE support for debugging. For simple projects, you can get away with no debugging or just occasional print-statement debugging. Fantasy consoles don’t have debugging but they are still excellent for making small games. But for anything more complex, a good debugger can often overcome an otherwise bad coding experience. For example, even though memory bugs are common in C, I’ve been able to work around them with conditional break statements in my C games. And the ability to modify values at runtime with dynamic languages is such a powerful debugging tool. Sadly this isn’t available in nim. If nim were otherwise a pleasure to work with, this could be overlooked to a degree.

The big disappointment however is with the lack of a good game framework in nim. As of writing, the list of game frameworks and engines for nim is a modest collection of barely-actively-maintained wrappers around SDL. This is ok for my purposes since I’m interested in 2D game development, and SDL is mostly fine. The standout in this list is nico, a PICO-8 inspired engine, and this piqued my interest.

As previously mentioned, I’m a big fan of fantasy consoles. Their limitations also make them easy to pick up and learn, and limitations drive creativity. Nico not only couples a nice language with a great API, it is cross platform, including for the web, out of the box. Its feature list contains all the nice things that make fantasy consoles great.

Unfortunately it is not actively maintained, despite plenty of community interest. As of writing I still have several pull requests that have stayed open for months. Being far from mature, a lack of maintenance is a critical flaw. I want to make games, not engines, which means fixing the issues myself is out of the question. Given that I was still learning the ropes with nim, this is an extra headache I did not need.

What’s Next

For now I’ll be taking a short break in my quest to find the perfect games programming language. Plenty of options exist no matter your favourite language, although you’ll be putting up with some limitations. I’ve been looking into MoonScript + love2D lately. Coupling a cool language made by a game dev’s game dev, with a venerable 2D games framework, this makes a promising combo. A lot of features are missing however, so I’m not diving in head first. If I do ever jump into a new language, I’ll be sure to keep my experiences with nim in mind, now that I have a better idea of what makes or breaks a language for games programming.

I love 2D sprite-based games; they are easy to read and a great way to showcase beautiful art and character designs. A major downside is that drawing each sprite is a significant amount of work, and it can grow exponentially depending on the game perspective!

Choosing the right game perspective has a big impact on your game’s art budget. Here’s a rundown of different 2D game perspectives and how many different sprites you need to budget for.

Summary

Perspective	Sprites Needed	Genres	Examples
Top-down (vertical)	1x	action, arcade, puzzle, vertical scrollers
Side view	1-1.5x	beat-em-up, fighting, infinite runner, metroidvania, platformer, run-and-gun, side-scrolling
Isometric (4 directions)	2-2.5x	business simulation, turn based strategy, turn based tactics
Oblique	3-3.5x	action RPG, overhead shooter, RPG, RTS
8-directional	5-5.5x	8-directional shooter, real time tactics

Top-down: 1x

Games with a perfectly vertical perspective are the cheapest to create sprites for. You only need to create one set of sprites, and even if you need characters to face different directions, you can let your rendering software rotate the sprites. A lot of simple or retro game genres use this economical perspective - arcade games, top-down action games, puzzle games and so on.

The downside is that it’s not a very flattering perspective. Characters can’t show off their face, only the tops of their heads. Buildings only show their roofs, which are rarely shown in real life, plus it’s hard to show important parts like doors.

On the other hand, cars and other vehicles look perfectly fine in this perspective. This is why games like top-down vertically scrolling shooters use airplanes or spaceships instead of human characters.

Grand Theft Auto 1 and 2 used a top-down perspective for its human characters and cars. The cars look great; the human characters less so.

Side view: 1-1.5x

Side view games are also very cheap to draw for. Compared with top-down games, it shows off characters and scenery much better. Because of this ability to intimately show off characters, it’s popular in fighting games and metroidvanias.

Games like infinite runners only have one fixed view of the characters; even if you allow the characters to move left and right, as in platformers, side-scrollers or run-and-gun games, you can mirror the sprite, which is very cheap to do.

Contra sprites are simply mirrored, which makes the character’s handedness change. But it’s so fast-paced that most people don’t notice.

One caveat is if the characters are handed, it can look odd when they are simply mirrored. Sometimes you can get away with it; if not or if you care about it enough, it can take some time to rework to mirror the sprites.

Dragon Quest, like many JRPGs, have the player look at the character sprites for long periods of time, so it pays off to make sure they are holding their swords and shields on the correct sides, no matter which way they are facing.

Isometric (4 directions): 2-2.5x

Isometric games combine the advantages of the freedom of movement of top-down games with the attractiveness of side-scrolling games. If you limit movement to the four diagonal directions, you can get away with only creating 4 sets of sprites: front-facing and back-facing, with the other two directions simply mirrored!

In Super Mario RPG, although the main characters can be viewed in 8 directions, most characters are only shown in the 4 isometric directions.

Similar to the side-scrolling perspective, if your characters are handed, you may need to slightly rework sprites when they are mirrored.

Because not being able to move vertically or horizontally feels unnatural for action games, this perspective finds more use in slower-paced genres like turn based tactics and turn based strategy games.

In the business simulation game Theme Hospital, players build out rooms in their hospital while managing staff and incoming patients. The isometric view helps show off the rooms and quirky characters.

Oblique: 3-3.5x

3/4 oblique perspective is a highly versatile perspective. It can show off characters and scenery well, as well as feeling natural for players to move around in, so it can be used for a lot of genres. Overhead shooters, RPGs, RTS games, ARPGs, as well as genres that work with the other top-down-style perspectives… oblique perspective can handle them all.

The cost is that the sprite work required is substantial: you need at the very least 3 sets of sprites: side view (mirrored for left/right), front view and back view. Again, if your characters are handed, you may need to rework the side view sprites too. For this reason oblique view sprites tend to be simpler compared to side-scrolling games.

Super Contra has overhead shooting sections where the player can face many directions. Its iconic, set-piece bosses however are fixed in one perspective, so the artists can afford to put extra effort into them.

8-directional: 5-5.5x

If you want to draw characters moving in 8 directions, the amount of sprites required approaches the limit of what’s sensible for hand-drawn sprites. You must draw at least 5 sets of sprites: in addition to the 3 sets for the cardinal directions, you also need 2 sets for the diagonals.

Gauntlet 2, a fast-paced shooting game, being able to move and shoot in 8 directions is crucial, so the sprites are drawn in all 8 directions.

The substantial artwork cost means you should carefully consider workarounds:

1. Allow players to move diagonally, but only draw 4 directions

1. Use the perfectly vertical top-down perspective, letting your renderer or image editor do the rotation for you

1. Use 3D-rendered sprites, which also lets you add arbitrary number of angles

This perspective only makes sense for games where showing the 8 directions is really important, like 8-directional shooters.

You can use either oblique or isometric perspectives for buildings; oblique may be easier to navigate but isometric shows off more sides for buildings.