I want to make a small 2d, side-scrolling platformer, something like old mario or metroid. This is just for fun, something I can do over the next n years as a hobby, not a commercial project. I'd be developing it solely on Linux (ubuntu) but it would be nice if at some point I could build it for windows/mac as well. I was wondering if anyone has suggestions for a 2d game engine/product that I should start with. I'm looking for something simple (I don't have any experience writing games) but that is written well enough that I won't easily paint myself into a corner. I'm planning to do pixel art and tilemaps so something that includes an editor or can import tilemaps from some other popular product would be nice. Also looking for something that is as "future proof" as possible, something that is maintained (but don't necessarily want something so new that's actively changing and will make development more difficult).

So far I've seen:

• monogame - seems a little low-level but I didn't do a lot of reasearch on it
• godot - seems much higher level and a lot of tutorials available

make it as a jk mod

This won’t sound helpful, but it is completely true:

There are so many alternatives for a simple 2D game out there, it would take much longer to research and deliberate them than it will take you to pick at random and make your game.

Right, that's the problem. I was hoping someone here already did some research and could point me to something that doesn't suck. My problem is that since I have no experience in this I won't know whether something sucks until it's "too late" -- or maybe it will never be, I don't know.

More what I mean is, there are a lot of options that don't suck. There are probably 30 really good options that would meet your given criteria. So the important part isn't whether your choice is good, because it almost certainly will be. The important part is whether you'll succeed using it and enjoy using it. And that's just too subjective and personal. It's something that's informed more by your aesthetic preferences, personal goals, and past experience than any objective measure of quality.

So, I mean, I guess I'm just rephrasing my previous advice. You've really gotta close your eyes and imagine what you'd like it to be like to work on this game, think about the language and where you fall on the balance between spending time creating a workflow vs. spending time learning one. Once you have those answers it's pretty easy to pick something that's good enough. Or, failing that, at least you'll have an easier time getting help picking one.

I dabbled a bit with Godot and it seemed easy enough, but I think it also allows you to get just about everything done. Yes, much is abstracted away, but I think (haven't tried it) that if you have to you can break out to do whatever you need to do that it is too high level for.
Plus, it compiles to just about every platform under the sun, including the web.

You have a choice of about three to four programming languages, I think. But the internal Godot scripting language seemed easy enough to me.
And the IDE itself is written with Godot itself, which speaks for its power.

Ugh, and I've got to change my sig again. That text is awful. But I hope you can understand what I mean.

I've experimented with a lot, but enough with Godot, Libgdx, Monogame/XNA, SFML, and SDL to say something about each of them. They're all really good. They're also all really different.

If you're willing to spend a lot of time learning and you want to avoid writing code as much as possible, Godot would be my recommendation. If you like managed code and want more direct control over your workflow, but don't want the schlep of writing your own content pipeline, Monogame and Libgdx are both great options too.

But to be honest, if I had to choose something right now for myself, to write a simple Super Mario Bros. like 2D platform game, know what I'd pick? SDL. But that's because I already know what I'm doing, and I know that writing a ~custom engine~ would actually save me time in this specific case over having to learn a more sophisticated game engine/IDE first. I'd just hack together some script to process Tiled maps, which is really all that kind of game would need. But again, I know what I'm doing. This is very bad advice if you don't.

Thanks for the information, this is really helpful. I don't mind learning a workflow, especially given I don't know what a "content pipeline" is made up of in the first place. Seems like godot is a good place to start.

A content pipeline (asset pipeline) is just whatever end-to-end workflow you use to get art into the game. These range from very simple to very complicated, depending on your needs.

Usually a content pipeline has the following stages (not necessarily standard terms):

- Authoring (e.g. make a model in Blender)
- Import/ingest (e.g. load/parse the model into an intermediate representation)
- Editing (e.g. view the model, insert environment probes)
- Process (e.g. “bake” environment maps for the probes)
- Export (e.g. write the finished model into an optimized file format/structure)
- Load (e.g. the engine parses the finished model into the final data structure used for rendering and gameplay)


JK modders never knew well enough to make a pipeline, but what it probably looked like for the original devs was:

- Make 8-bit BMP textures using the agreed upon character palette.
- Make a character model in 3dsmax with components named a certain way, with materials that used those 8-bit BMPs.
- Run an export plugin to write out the 3DO and MAT files to an output directory.
- Place the models in a level using a custom editor (Leia)
- Test in a “/game” directory (fast path)
- Run a script to archive the directory into a GOB (slow path).

Just because of what they were doing, their workflow definitely would have been more manual than a mature modern workflow should be. I could be wrong though. Certainly it’s missing what I would consider a final build/export step, because everything is ASCII text and parsing that probably increased their level load times by a few orders of magnitude back in the day.

Mature engines today generally provide fast paths that let you skip work (e.g. Blender’s glTF exporter lets you embed metadata and materials that an engine that understands Disney’s BSDF can interpret directly, so you might not need to do much to them after import). They also generally provide a distinctive fast path for testing, like in-editor testing, or exporting assets that have some slow processing skipped (e.g. play a level without baked light maps or environment maps). Advanced engines are designed to accommodate build farms and continuous integration, so you can offload long bake steps to a cluster (or otherwise so they can complete overnight). And because you’ll often have to target multiple platforms/devices with different capabilities, this ends up looking more like a matrix than a simple script.

...but sometimes they don’t do much to help you. Like XNA/Monogame has a content pipeline, but it’s very programmery. You had to add your content to Visual Studio and then build it, with no fast path or decent way to write tools offered. I think they were originally planning on releasing an XNA Studio product that would add that stuff, but it never happened and given the architecture XNA settled on I’m not sure how it could. That said, if you’re a solo programmer working on a game by yourself, it’s very cool and not actually that annoying since you’re in visual studio all the time anyway.

But you’re making a 2D game in Godot, so for you this will mostly end up being dragging and dropping PNG files.

Just don't buy 2027.35 eurodollars' worth of assets and expect them to do the work for you.

I mean, no one's that dumb

Lo-fi is still trendy. You’d be better off leaning on “my art sucks on purpose” before buying assets.

Haha...

Jon`C thanks for your replies, extremely helpful.

I am not planning on buying any art/assets. I'm going to do it myself and/or have my son help (he also has no experience). As you can tell from my artwork on massassi.net, I am truly a unique artist. Specifically the left frame sidebar image is my handiwork. I don't think I've done any art since then.

I feel like the art is going to be more time consuming and challenging than the programming.

Funnily enough my son started stitching pictures together and imagined they were a computer game. So now we've actually started to make it a real game, using his drawings as sprites. As soon as I have an alpha or beta and his approval I will post it here.
Look out for Zombie Jäger - King of the Zombies.

has anyone ever made an actual 2d sidescroller in jk? I think Grismath did something along those lines

Not JK related but there was that funny SMBs like secret level in Star Trek Elite Force II, as you'll recall, I posted here about ten years ago.

Yes, including in Life of Grismath 2

Found my old post:

ok fastgammmmerrrr

I have spent some time learning godot. It's actually pretty straightforward once I started to understand how their node hierarchy works. It's fun playing around even on just one screen with a ground and a character that can jump. One iteration I had something wrong with the jump code and it would jump with increasing speed up to infinity. I'm using the "2d" engine and it feels weird that all the units are in "pixels." I guess it makes sense, it's just odd to me (no previous game programming experience other than some cog for jk arena).

Getting keyboard/controller support was easy. Getting "fun"-feeling physics was easy. I'm convinced even more now that the hard/time-consuming parts will be the design and artwork rather than the programming. Which is actually really cool.

Not entirely on topic but I recommend checking out Micro Mages.