Solar2D

Solar2D is a 2D game framework you write in Lua, released under the MIT licence. It's the open-source continuation of Corona SDK, and its whole personality is that it's small: fast to build with, light on the device, and free of the machinery a bigger engine drags along.

The one thing that most defines it: there is no editor. You write code, you point the simulator at it, you watch your game reload. That's the loop. Some developers find that liberating. Others open it, look for the scene view, and quietly close it again.

What it is good at

The build-run-see cycle is genuinely quick. You edit a Lua file, the simulator picks it up, and you're looking at the change without a compile step long enough to make tea. For 2D mobile work — where you're nudging a sprite two pixels left for the ninth time — that speed compounds into real hours saved.

Lua is the reason. It's a small language you can hold entirely in your head, and Solar2D leans into that rather than burying it under abstractions. If you've written any scripting language before, you'll be productive in an afternoon. If you haven't, Lua is about the kindest place to start.

The output is light. Solar2D games tend to be small binaries that run happily on modest phones, which matters more than the spec-sheet crowd admits — a chunk of the mobile audience is not carrying this year's flagship. Building for Windows, macOS, Android and iOS is the framework's core competency, and it treats those four as first-class rather than as afterthoughts bolted onto a desktop tool.

There's a plugin ecosystem for the things you'd expect a mobile game to need: ads, analytics, in-app purchases, the usual monetisation plumbing. And because it's MIT-licensed, what you build is yours with no revenue-sharing arithmetic hanging over the project. No thresholds to track, no percentage to hand back later.

For 2D — sprites, physics, tweening, particles, UI — the API is direct and readable. You call display.newImage, you get an image. The framework rarely makes you assemble three systems to do one obvious thing.

What it is not good at

There is no 3D. None. It's a 2D framework and doesn't pretend otherwise, so if your next idea has a Z axis, this is the wrong page.

There's no official browser export. If "play it instantly in a tab" is on your requirements list — for a game jam, an itch.io page, a marketing demo — Solar2D doesn't do that out of the box, and you'd be fighting the tool to get there. Its targets are the four native platforms and that's the design.

The absence of a visual editor is a real cost, not just a stylistic choice. Laying out complex scenes by hand in code is slower than dragging boxes around a viewport, and there's no built-in animation timeline or particle designer to tweak values live. You build your own tooling or you eyeball it. For some genres that's fine. For a content-heavy game with hundreds of hand-placed screens, it grinds.

The community is smaller than it once was. In the Corona era there was a large, active forum where nearly any question already had an answer. That energy has thinned. The framework is maintained and open, but when you hit an obscure problem you're more likely to be reading old threads and source code than getting a same-day reply. Budget for more self-reliance than a bigger engine would demand.

And because the ecosystem is smaller, some plugins and integrations lag behind the platform churn that Apple and Google inflict every year. Nothing that can't be worked through, but you're closer to the machinery than you'd be somewhere with a full-time platform team papering over the cracks.

Who should pick it

The ideal Solar2D developer is a solo dev or a small team shipping 2D mobile games, who is comfortable living in code and doesn't want an editor between them and the game. If you like Lua — or want an excuse to learn it — that's a strong signal.

It suits puzzle games, arcade games, casual games, 2D platformers, card games, hyper-casual experiments: things where the value is in mechanics and feel rather than sprawling authored content. If you can prototype the core loop in a single Lua file, Solar2D will get you there fast and keep the build small enough to run on a cheap phone.

The MIT licence makes it a sensible pick for anyone commercially cautious — students, hobbyists turning pro, anyone who'd rather not sign up for a revenue relationship with their tools. What you make stays yours.

Skip it if you need 3D, need a browser build, need a designer-friendly visual editor, or specifically want a large forum to hold your hand. Those are legitimate needs and this framework won't meet them by trying harder.

Getting started

Download the framework from solar2d.com and install the simulator — that's the window where your game runs while you develop. The first hour is best spent making a single sprite appear, then move, then respond to a tap. Small wins, fast, is how this tool wants to be learned.

Learn Lua first if you don't know it. Tables are the whole language — arrays, objects, everything is a table — and once that clicks, the rest is quick. Don't skip it and hope to absorb it sideways; an hour on Lua fundamentals saves a week of confusion.

Then learn the display and event basics: display.new* for putting things on screen, the event listener model for input and frame updates, and transitions for movement. After that, get comfortable with the composer library for managing scenes, because that's how you'll structure anything bigger than a demo.

Keep the official docs open in a tab the whole time. With a small community, the documentation and sample projects are your primary lifeline — read them early rather than searching for a forum answer that may not exist anymore.