Leveraging AI for Engine Development: Thoughts & Suggestions

Games
1

We all know that what the team led by Vlad is doing is truly remarkable. However, why is development still mostly limited to bug fixes and resolving issues?

What about leveraging AI to accelerate the evolution of this engine?

We’ve heard of developers successfully rewriting or recreating Adobe software in other languages using AI. Our engine is massive and full of potential—so why not take a giant leap forward with the help of AI?

For instance, what if we explored features like:

  • Multi-language support: Adding support for other programming languages like C#.

  • Official IDE: A comprehensive, official development environment (Visual Editor / IDE).

  • 3D Graphics: Robust support for 3D rendering.

  • Advanced Visuals: Advanced 2D lighting systems and visual effects.

  • Console Support: Streamlined and easier exporting to consoles.

  • Ecosystem: An official asset store and community marketplace.

2

@laboladoapp has been at this for a while, in their own fork.

There’s definitely work there worth yoinking back in, and I’m trying to get in touch with somebody to coordinate.

On Discord there’s actually been a lot of discussion about this lately.

I know the Flick guys have been doing bug-hunting and have some prospective improvements in the hopper, and @Siu and I have been on a tear hunting down bugs, and at least noting them if not submitting them yet. (Looks like the Vulkan branch might be getting a new lease on life, and we were talking last night about using it as a staging ground for, say, compute shaders.)

This PR was run through the wringer at the end teasing out flaws; we’ve done the same on this one in the works (needs an explanation), which deals with tons of inconsistent-across-platforms build details, and have been stomping around other branches, either pending PRs or not-yet-submitted stuff (0-1 texture coord helpers for sprite sheet-style stuff; NaN-boxing Lua; etc.).

Hasn’t landed anywhere but as a zip in Discord yet, but this is another one that looks promising: https://www.youtube.com/watch?v=BZXS0-jeyYI

EDIT Submitted a PR for the emitter thing.

3 Likes
3

There are a few things I think are worth addressing here, especially since I imagine many people share these thoughts. It might be time to put them on the table and have an open discussion about them.

As far as the official Solar2D repository goes, @vlads’s focus is on maintenance rather than adding new features. Every PR submitted to GitHub requires a code review from him and/or @Scott_Harrison (I’m not entirely sure how the responsibilities are divided between them), and that alone can be time-consuming. Opening the door to more features would mean more time spent reviewing code, dealing with potential breaking changes, and addressing bugs that arise afterward. It also raises an important question: who would be responsible for fixing issues introduced by a PR? Would that responsibility fall on the person who submitted it, or would Vlad ultimately be expected to handle it?

As @StarCrunch mentioned, there are already people who have forked Solar2D and are expanding and improving it in various areas. StarCrunch himself has contributed quite a bit over the past few years.

My current view is that, over time, the community may end up with several forks, each serving different needs and goals. If the intention is to bring these efforts together, someone would need to oversee and coordinate the process. That person would also need to have the community’s trust and credibility for people to feel confident contributing to and adopting the project.

One possible approach would be to have an experimental branch (or community-led) separate from the production branch, where new features and improvements could be introduced without directly affecting the stable version. Contributors would be responsible for maintaining their own contributions, fixing bugs they introduce, and addressing any issues that arise from their changes. This would allow development to move forward without placing the entire burden on the people maintaining the official repository.

If this were done within the official repository, Vlad would naturally need to be involved in some capacity. If it were hosted separately, then whoever took the lead would ideally be a long-standing, trusted member of the Solar2D community. Of course, there’s nothing stopping anyone else from starting their own initiative, either.

7 Likes
4

I am in favour of said experimental branch.

I think it’s a good thing that Solar2D’s main branch is stable and developers can expect it to remain so. There are plenty of bugs and other issues there to work on, and they take time and care.

So far, all of the work I’ve done on Solar2D core has been authentic human slop. That being said, I’ve been using Claude more and more, and it’s capabilities are amazing. It empowers competent developers and enables all sorts of cool things. On the flip side, it also makes people who can’t even read code believe they can just prompt Claude/GPT/Gemini and whatever comes out is fully functional, bug free, and production ready. Real magic.

It’s important to keep ”full vibers” out of the main branch and to ensure Solar2D remains reliable and stable. At the same time, I don’t think it’s a good idea to just have everyone spin up their own fork and fracture Solar2D into tens or hundreds of unique forks. Having an experimental branch, where developers would be allowed to take more risks and be more liberal with changes would be great.

I’d still recommend having a brief conversation on ”what work gets started/worked on”, so that it doesn’t just become a free for all, but it wouldn’t have to adhere to the strictest ”make sure nothing breaks and everything is 100% backwards compatible” that the main beach adheres to.

For instance, I’ve had Claude look into ”finishing” the Corona SDK to Solar2D rebranding. It’s fairly silly that the app is Solar2D Simulator, but it has Corona Labs, Corona SDK, and Corona mentions everywhere in the various apps and even folder structures and registeries. Changing all of those things would break things. Some intentionally, others by accident. If we also want to remove mentions of Ansca from the code, then even more so.

I’ve also thought about finishing Danny’s work to properly bring Solar2D to Linux, but I would definitely need a lot of assistance from Claude with that.

I know many others have all sorts of interesting plans as well, like upgrading/redoing the particle system, upgrading the Box2D library, improving the rendering pipeline, bumping GLSL versions, integrating proper asset compression/”encryption” for builds, optimising this and that, etc.

I would love to see a concentrated effort to bring all of these to the main engine repo. There needs to be control on who is doing and what, so that we don’t start seeing Solar2D turn into Solar3D with hundred different renderers, ten unique video players, and web3 integrations.

Native plugins are also a great way to extend Solar2D and they allow developers to add all sorts of nice and nuanced things into Solar2D.

We should absolutely leverage AI and use it to improve Solar2D. It needs controls, but needing Vlad and/or Scott to review everything would be too much of a bottleneck. Having a more liberal experimental branch(es) would be great, and then bringing the thoroughly tested and proven features to the main branch.

(I was typing this on my phone and my thoughts probably wandered off at times. I hope my thoughts/ideas came across somewhat clearly.)

5 Likes
5

Oh, and I wanted to chime in on these ”quickly” as well.

  • Multi-language support: you can integrate native code with plugins already. If you want to make C# or some other language a supported ”main game scripting/programming language”, I think it’s a terrible idea and it would move Solar2D away from what Solar2D is, how and why it works, etc. I don’t see any point in that, I only see downsided and problems.
  • Official IDE: no need and no reason. Why invent VS Code, Sublime or such, when they already exist and are free? (i just re-read the quote and I think my attention was grabbed by ”Visual” and IDE, and I just made the ”Visual Studio” connection. :sweat_smile:) I think should focus on Solar2D. If someone wants to create their own IDE, they can. If you’re talking about some level editor or such, I think @Siu was working on something like that.
    • An IDE is a bit of a mixed bag. On one hand, they are more beginner friendly and allow for some quick and clean adjustments for assets on maps, but at the same time, they can require massive redesigns and workflow adjustments. Part of the reason why I use Solar2D is because it lacks editors and it’s just code and the simulator window. I can edit levels in Tiled and import the levels and make Solar2D work for me without having to fight against how someone wants me to use tilemaps in the engine.
  • 3D-graphics: just use Godot, Unity, Unreal or any other 3D engine. That would be such an enormous amount of work and it would essentially require creating an entirely new engine, Solar3D. It doesn’t make sense.
  • Advance visuals: this is trickier and I am in favour of rendering pipeline, shader, OpenGL improvements/version bumps. I also have a shadow system that I can share. 2D and lighting just don’t technically belong together as lighting requires a camera, planes, and 2D doesn’t have those. Any lighting/shadow system in 2D is some sort of ”hack.”
  • Console support: yes, this’d be great. I don’t know how open console manufacturers are and how easy it is to get devkits or permissions, but this’d be great if it’s doable.
  • Asset store and marketplace: requires constant maintenance, needs servers that cost money. There are 3rd party places. I wouldn’t recommend spending time or money on this. There’s no money to be made there, and if it’s not about the money, then people can just share their assets or code for free, like many do.
5 Likes
6

Not a fan of AI coding myself, so I just wanted to chime in with my two cents on the general direction of this conversation:

  1. Should the aforementioned experimental branch come to life eventually, I’d hope that instead of a single developer being responsible for its maintenance, some sort of “Solar Council” handles its oversight in a collaborative manner. As XeduR mentioned, relying on Vlad and/or Scott to handle everything would be too much of a bottleneck, but designating just one dev as the maintainer would only shift said bottleneck, which would defeat the point. Inviting some of the most trusted members of the community to such an initiative, however, would both gather their expertise in one place instead of spreading it across several personal forks and ease the burden of responsibility each of them may feel otherwise, if suggested as the sole maintainer or anything like that. I’m sure most people that fit the description would be too humble to nominate themselves, so since I’m not qualified to be a part of such a gathering myself, I can’t help but notice the presence of several such individuals in this very post. :slight_smile:

  2. Just a secondary thought, but some sort of feature request page would help a lot to gauge general interest in specific improvements. Even enthusiasts working purely on stuff they’re interested in themselves might sometimes be curious about how much real-world use their potential project might get, after all. Such a page also wouldn’t need to be anything fancy, MonoGame uses a simple GitHub issue for that iirc, for example, though I’ve seen more specialized tools like Opire and BountyHub as well. Could also support paid bounties since while it doesn’t happen often, some people are willing to save time by paying others to implement a feature their project needs, and it’s easier when such initiatives are centralized in one place rather than reinvented with varied conditions in numerous branches for each particular request. This could be especially useful when it comes to console ports (assuming the legal parts are solvable similarly to the Switch situation) since those would only interest a specific subset of Solar devs, but one with decent potential to fund the initiative.

5 Likes
7

@XeduR, everything you mentioned sounds good to me.

Restricting access to that branch to certain developers would also be a good idea, with exceptions on handpicked requests whenever necessary. It would simplify management, since we’d mainly need someone responsible for merging changes and handling builds.

If we get the green light from the big boys, we can discuss on Discord who wants to work on what, or put together a priority list of things that are needed and that we can all agree on.

I do have a visual editor in the works, and it’s at the top of my priority list. I’d really like to get it out there. I’m still undecided about adding code editing. I’ve experimented with it before, but it’s not currently on my TODO list.

Also, for the sake of this discussion, I do want to point out for anyone reading this thread that this is not strictly for using AI.

3 Likes
8

The idea of a council or a similar group has also been on my mind since we went open source and a community remained.

If we do need to designate someone for the branch and there are no volunteers, there a few a people I could nominate if it gets down to that point. :grinning_face:

1 Like
9

Yeah, absolutely. This conversation just happens to take place inside an “Leveraging AI” thread.

AI is a great tool, but like I had mentioned, all of my contributions (so far) have been certified human slop. I have a few additional human slop PRs in the works and a few others waiting for an eventual review/merge. :smiley:

In my mind, the goal is to improve and extend Solar2D in ways that makes sense, with the tools and techniques that makes sense, but those vary from one person to the next. On that note, some sort of way to make suggestions and discuss them would be great. I’m not sure if GitHub issues would be the place, or if it’d need something more structured.

1 Like
10

We must also consider what we want out of Solar2D for the future.

Agentic coding will eventually get to the point where the appeal of a single codebase game engine that builds for multiple platforms becomes less relevant. If you can simply instruct Claude to build your game natively in Xcode and Android Studio, the crossplatform advantage becomes less significant.

Solar2D is a great 2D engine that does exactly what it needs to do at basic level, but it is missing some bells and whistles.

I agree that we don’t need a full-fledged IDE, but I think there is room for some simple companion apps and tools that work hand in hand with the simulator. For example, being able to adjust variables during runtime, a built-in sprite/texture packing tool, a proper tile map editor, lighting & physics tools, and other small utilities that make game development easier without turning Solar2D into a massive IDE. Something like Solar2D Studio, which focuses on purists who still want to manually code apps, and have assist tools for display object positioning, scene management etc.

I’m also a big fan of community voting for new features and roadmapping.

Anyways, I have been here on and off since March 2012 when I first subscribed to Ansca Mobile. I am still here and enjoy using this platform. I will support it in anyway I can.

1 Like
11

I would like to participate in this discussion because I’m Ai addict now.

I’m a mechatronics engineer, so at university (29 years ago) we focused on PLC, assembly, and basic C++ and VB6 which was strong back then :slight_smile: … and in my specialty they don’t teach us object oriented programming, they focus on controlling machines by code… but after graduation i ditched the hardware and got stuck in desktop programming, i was very good at it, i mean my programs performed very well, minimal bugs, but i knew for sure that my code doesn’t look good, but it works perfectly

Throughout the years i kept doing what I’m doing and became very experienced in Enterprise solutions that are Database related, like Archiving solutions and ERPs, but in 2013 I thought I was too old to learn new languages specially for mobile development, I thought it was too complicated, until i met Corona Labs back then, I fell in love with it, created simple games, and mobile apps and made good money from it.

My code worked, but my background (which i didn’t develop) also made me use Solar2D in a wrong way i would say, although my code worked, but when i Used ChatGPT, i realized how object oriented is done in solar2D, i used to read it, but i thought it was a bit complicated, but with Ai I understand how it works now, and I appreciate how the code looks minimal, correct and tidy, and modifying the app in general is much simpler.

So Ai is great in general for any person, any language, any task.

I would never go back to writing code myself, it’s like trying to walk from London to Los Angeles, but I know how systems are structured, and how they work, and I know exactly what to ask Ai, eventually it can code much better than me, but still it cannot design a system like me, if I was a better coder then i would not use it to code, so each person can decide how to make use of it.

I think Solar2D is great as it is in what it does, it never failed me in any app feature i wanted, i even used it for a TV show, a web portal, a desktop system, and of course hundreds of mobile apps.

@XeduR and @vlads and anyone working on Solar2D engine, many many many thanks for your efforts, your work keeps us alive and working… your work makes ChatGPT or Ai in general work perfectly, otherwise, if your work was not perfect, Ai would not give perfect results on Solar2D.

proud to be part of this community :blue_heart:

12

I have in progress the PR which will automate the followign - if you would make a PR or branch ‘experiment/yor-experiment-name’ it will build and publish pre-release with some fake version and your-experiment-name with only requirement that the e ‘master’ branch is fully merged into it.

This will give clear distinction between base mainline version and experiments, and ability to merge non breaking changes into main branch.

Problem with game engines that we cannot branch out too far - breaking changes are very harmful to users. Every breaking change we make is forcing people to discover that their games doesn’t work anymore just because Apple/google forced them to submit a new build. Unfortunately

5 Likes
13

It’s great that a topic about this has come up; I’ve been wanting to bring it up myself, but I was worried it might be too repetitive. I’ve been using Solar2D since the “Corona” days I love the Lua language, and, just like the language itself, I’m Brazilian.

Unlike most users, I use Solar2D to build mobile apps rather than games. I’ve always appreciated how simple and easy it is to create things with it no need for Android Studio, Xcode, or heavy emulators. But, as is often the case in life, circumstances change, leading us in new directions. This year, I moved from the Apple ecosystem to Linux and Android, simply because the Apple ecosystem no longer offered a good cost-benefit ratio for me. I’m finding a similar situation with Solar2D: it doesn’t currently run on Linux, there’s very little visible evolution in the tool, and I see its “competitors” pulling further and further ahead in every regard. Just last week, I was considering switching to React Native, as it addresses several issues I face with Solar2D such as Linux support, a much larger library of pre-built components (which are also free), and a better system for handling UI across different screen sizes.

While I’m not an expert developer capable of contributing to the actual development of Solar2D, that doesn’t mean I can’t share my thoughts on how it could be improved. I love this tool, and my criticisms come from a place of wanting it to thrive and evolve. I do feel that the tool has stagnated and that there’s a lack of clarity regarding its future direction. Please don’t take my comments as disrespectful or arrogant; I’m simply a fan of Solar2D who wants to see it continue to grow and improve.

1 Like
14

Keeping experiments separate is definitely part of the idea, but I also think it would be useful to have a shared, unified experimental branch where we can combine all the changes and see how they work together.

We definitely don’t want to break anything or create extra headaches for you. With that in mind, we could even keep the current production build as the “vanilla” version indefinitely and have a separate “community-led” branch for everything we’re experimenting with.

You’d still have full control over what gets merged into master, if ever, at your own discretion and whenever you feel something is ready.

There’s no telling where this will all lead, and we certainly hope for the best. For now, we just want to get the ball rolling, experiment, and see what the community can contribute without interfering with the official master branch. The goal is to keep the stable version safe, avoid breaking anything, and give ourselves room to explore without entering the danger zone.

2 Likes
15

I’d be open to having AI be used to help speed up development. Solar2D feels like it’s on maintenance mode most of the time, and AI could be used to help it move forward and evolve instead of being stuck in coasting mode.

As someone who’s been using it since close to day 1, I’d love to see it be more actively developed like it used to be in the early days.

I agree that stability and not breaking things is a huge plus for Solar2D. I can open up a 10yr old project and 99% of things still work.