I’m quite sad that most games for smartphones are either gatcha-hell, or add-ridden messes.

What good options are there? I tried OpenTTD for Android, but the UI is really not optimized for such a small screen.

Meanwhile in my engine’s editor, the default is dark mode, with no plans on making light mode on my end.

I would add to the downside that it’s not the best programming language for game development, etc. There was some blog post about how troublesome is it to develop games using Rust due to some of the features that are good in other areas, like the whole concept of “immutable by default”.

I can also recommend D, if you want to deal with different issues, like the D Language Foundation fearing of change due to not wanting to deal with division from a new and incompatible version yet again, the GC being both a blessing and curse, if you want to go without a (tracing) GC you’ll need to go with a custom runtime that potentially missing many of its features, the attribute hell, etc.

Thanks, but that’s not what I’ve wanted the help for.

EDIT: Why all the downvotes?

The standard answer is C/C++.

The nonstandard answers are:

• D. It’s fairly close to Java, but with garbage collection you’ll still at like 50MB depending on your usecase (it just doesn’t immediately give the memory back to the OS for speed reasons), or you have to use some of the alt runtimes without a GC and many of the standard libraries.
• Rust, if you can deal with immutability by default, a borrow checker, and many other quirks.
• There’s also languages like Zig, Nim, etc.

> died by suicide

Sometimes even bad guys with a gun stop themselves.

Yes, I’ve meant declarations, which makes stuff much harder. There are tools that automatically writes you the header files, but it was a major PIA when I learned C++.

Okay, I likely have mixed it up with another language, which sounded similar…

Issue with C# is, that it’s quite far away from a system language, and I would have to write the engine’s main core in some more system-level language, and I don’t consider it good practice to write every component that doesn’t directly interfacing with the OS in a trendy scripting language.

I have talked to people about Rust gamedev (including those who left Rust for D due to gamedev), and it’s not a very good one, due to the functional aspects. Outsiders often joke about how Rust has more game engines than games.

Zig has the header file problem. Header files were originally created to get around memory limitations of old workstations, that no longer exist. They also complicate coding, since you now often have to implement things at two places at once. However, Zig not only copied C++'s multi-inheritance, but also its header files, without understanding the actual reason why it existed in the first place.

Classes can be useful for abstraction. Just because they often overused doesn’t mean they’re bad.

Without an explicit class, I would either:

• had to reimplement them in a language without them (which looks extremely ugly and can be unsafe),
• create an “omnistruct” that keeps track of all posssible field (only looks a bit ugly),
• use uglier virtual functions for cases when I would need local states (doStuff(cast(void*)&localstate, values) vs localstate.doStuff(values)).

While structured programming was a godsend to the chaos preceding it, newer programming paradigms should have been instead seen as tools rather than the next dogma. OOP got its bad name from languages that disallowed its users to develop without classes, and enterprise settings making its devs to implement things that could have been simple functions as classes, sometimes complete with factories.

Same is with functional programming. There’s clearly a usecase for it, but isn’t a Swiss-army knife solution for all problems of programming.

It’s too high level for my usecase, so unless I either use a preexisting game engine, or develop mine using a system language, so C# is only good as a scripting language in my usecase, and sometimes you want “hard-code” new features, not script them.

I only had a bug once from unintended data mutation. In a GUI setting nonetheless, where state mutability is a must. The fix and tracking down the bug took 2-3 hours at max. No thanks, I’ll be staying with datastruct.nextState() rather than const nextState = prevState.nextState() (which is even harder to from the inside), or even worse, passing around global states in a function argument at an attempt of having a program state, which is essential for gaming. You know, games are famous for having interactibility, and not just about walking around in a static world (which is allegedly a thing for the few Rust games).

You forgot immutable by default.

It has no classes

https://github.com/ZILtoid1991/newxml/tree/main

This XML parser of mine uses safe by default.

Pointers are not guaranteed to be safe. DIP1000 was supposed to solve the issue of a pointer referencing to a now expired variable (see example below), but it’s being replaced by something else instead.

int* p;
{
  int q = 42;
  p = &q;
}
writeln(*p);     //ERROR: This will cause memory leakage, due to q no longer existing

With an even more generic art direction.

D has many memory safety features. For local variables, one should use pointers, otherwise ref does references that are guaranteed to be valid to their lifetime, and thus have said limitations.

That’s why I often recommend D instead.

Has a much more C-style syntax, except much more refined from the years of hindsight. The catch? No corporate backing, didn’t jump on the “immutable by default” trend when functional programming evangelists said for loops are a bad practice and instead we should just write recursive functions as a workaround, memory safety is opt-in (although “safe by default” can be done by starting your files with @safe:), some of the lead devs are “naive centrists” who want to “give everyone a chance at coding even if they’re bad people (nazis)”, implementing new changes to the lang has slowed down significantly up until the departure of Adam D Ruppe and the drama surrounding it, etc.