Hey GameDev!

I'm currently sitting with a cool 2D game concept and time/team to get into a decently good development cycle, but torn between several engines. I'm currently considering:

• Java or Kotlin - LibGDX
• C# - SFML bind(SFML.NET), Unity, Godot
• C++ - Unreal, Cocos2d-x, SFML

I'm not exactly sure about language either; With my interests lying mostly in Java/Kotlin area, they are pretty slow.

C# is mostly referred as go-to game dev language, but SFML is pretty low-level(and won't run on my Linux Mono setup duh) and I personally don't like Unity too much as it's pretty heavy for my taste and seems somewhat messed up with its truckload of different features. Maybe it's not true and I've been approaching it from the wrong end since everyone seems to recommend it? Godot is there, too, but its C# support is in beta stage right now and they themselves advise not to use it for serious projects.

I also considered C++ as I'm somewhat fluent in it, but it's pretty low-level and shooting myself in a leg seems to slow down the development and clutter the code too much. Maybe it's not true for some engines/APIs? Not sure.

Just in case, I also know Python 3 and JS basics in case there is a decent solution(though I was unable to find it).

If there are good options I'm missing for listed languages - please let me know as well!

Godot's GDScript is close enough to Python, and the editor has some bells and whistles, including code completion (somewhat wonky, last I checked, but still). Godot is spoken of favorably for 2D game development, although I tried it for 3D, with mixed results, so I can't speak on it with expertise. But try it anyway. It's really light-weight, and quick to get up and running.

The only thing is that if you have plans for any programming cleverness. Namely, I tried to do internal classes, and I would say, while it's technically possible, it's best to keep it relatively simple. Oh, and I found it significantly slower than LibGDX. Then again, I was doing some "clever" things in code, maybe not suited for games in general.

Its 2D physics is intuitive and quick to setup too, for what it's worth, especially if you're making a platformer.

That said, I haven't touched half of the other platforms and maybe there's something better. Plus, I specialize in 3D... Grain of salt and all that.

Oh, have you looked at Game Maker? I haven't, but if we're talking "go-tos", I don't think it can be beat.

I've already started it with LibGDX after some consideration. Thanks though =)

Good luck. It's fine, but here's some possible caveats, to spare you some pain further down the road.

Unless I've missed something vital, it has no WYSIWYG level editor, like you get with Unity. Well, there's Overlap2D, but use at your own risk, it's buggy.

Even though it's by far aimed at 2d, there's a lot of things you have to do through 3d... Well, you've noticed that.

...I'd love to know how you're getting on with it. I've pretty much delegated it to physics experiments and other procedural challenges. I'd love to discover that it's more robust than that.

Yeah, there isn't a WYSIWYG editor. Not that I'm going to use one, either - maybe for UI it would be neat, but my game isn't going to implement a proper moving camera(maybe some screenshakes, but that's it).

Have you tried Processing? It's generally designed for such things as experimenting with data or visualizing something as fast as possible afaik.

And, well, yeah, hopefully I can make it work with my architecture in mind

I actually got back into libGDX trying to follow challenge videos by a guy on Youtube, who was working in Processing. I'm not sure why. Maybe I was more afraid of learning new frameworks than now. Or I wanted to work in something more gamedev-oriented. The point is, I don't think I had many translation problems. Which is another argument for the position that it's not the platform but what you do with it.

If you're ready to learn advanced C++ with XLib/WinApi/SDL/SFML, then consider writing your own software rasterization using portable SIMD vectors and multi-threading, to increase performance by a factor of up to 112 times on OctaCore CPUs (16 SIMD lanes * (8 cores - 1)), unless you're doing something simple being bound by cache speeds. It's actually fun once you have templates for creating your own CPU shaders without any GPU limitations to deal with. If you're shooting yourself in the foot using pointers, then replace pointers with a template class that has the same operations but with debug time bound checks, to get helpful error messages instead of a mysterious crash. Hard sprites can be drawn using memcpy one row at a time using pre-stored start-end line intervals for each sprite. It will be more than enough performance for realtime 1080p resolution and your game logic. If you want nice graphics instead of a high resolution, you can pre-bake highly detailed isometric 2D tiles with diffuse, depth and normal maps and have realtime 3D light using deferred rendering. Your game will work on Linux even when when the user didn't bother to install GPU drivers, but don't count on getting full screen in Linux no matter what the framework promises.