Hello,

I've been programming for nearly 25 years now, and I'd like to get back to what I was doing 20 years ago: games.

But of course, a lot of things have changed, and I've myself changed. I don't have the patience I had back then, I'm not ready to asm-code every sprite blitter anymore, but well, it's what game engines & graphic cards are for today anyway.

So I wanna do 2D games, not that I don't like 3D, but I can still do pixel graphics, not 3D models.

I come from Pascal, and while I think Pascal is the best language, I understand it's nearly dead by now - leaving the horrible Delphi & kinda bad FreePascal as the only compilers. So I'll have to learn a new (possibly scripting) language as well, and I guess it will always look more or less like C.

I've already tried Unity, but.. it didn't feel at all like how I was making games 20 years ago. To start with, I like to think in "game ticks", not "events". I kinda understand why an engine moves away from that, afterall you can't always force the graphic card to the refresh rate of your game's clock like you could under DOS. But.. I'd still prefer a game loop-based system, assuming there are still engines that work like this(?)

I've browsed game engines, picked some that felt like they were matching, so if anyone has any tip for me, thanks!

I'd like to make a tile-based puzzler in the vein of Apogee's Paganitzu. Even though the graphics will be pixellated, I'd probably use the engine in full res, so that I can smoothly move sprites around, not snap them to pixels in a small, scaled up buffer.

Since I'm moving away from the horrible Delphi, portablity is a big plus, thus I've picked those that appear to feature portability, at least to Android.

http://www.godotengine.org

http://www.cocos2d-x.org

http://overlap2d.com
http://ethanonengine.com

Is any of those the best for me? Or any other?

I think probably the best route for you would be either:

Use C++ with a library such as SDL.

Use Java with libGDX

These are going to be a little more familiar with how you remember coding but, not so level that you need to write your own sprite blitting routines.

Of the other engines you mentioned:

Godot is a good engine but, will probably put you off in the same way that Unity did.

Cocos2d-x is lower level but it prefers you to schedule actions rather than working with the game loop directly. You can work with the game loop directly but, usually its not the way you use Cocos2D.

Overlap2D is not an engine but a level / UI editor that can be used with other engines like Cocos2D
Ethanonengine I have no experience with this engine so couldn't really say. In fact I'd not heard of it until your post.

Thanks.

Yeah SDL seems to be a great option as well. Heard about it a lot.

Java.. I'd rather stay away from it (but maybe for wrong reasons).

I've watched some Godot tutorials, seems to be heavily event-based, but also with events happening on each game loop. But I haven't tried it yet. Building a tilemap looked painful, albeit powerful (with solidity zones for each tile).

Back then I had my own sprite editor, and I found it easier to put all of my sprites in banks, load & access each bank at runtime, so that I didn't have to hardcode sprite alignments / hot zones (hit boxes & other useful rectangles), & I didn't have to limit sprites to fixed rectangles. I hope such editors exist, especially with the added PITA to stack them efficiently on textures nowadays (I assume).

That's a bit what attracted me to Godot, as each sprite seems to have its own zones - only for the tiles as well it seems way overkill. This said, I also like the idea of having the map made of freely-placed sprites, even though that then means there is no "map" anymore.

I don't even know how tilemap rendering is done nowadays - I understand the problem of stitching stretched tiles perfectly, I assume the only good option is a fixed-size render buffer that's later stretched-up, or tiles that bleed & overlap enough (but that requires the kind of illustrative artwork I can't do myself)

I'm still looking for the best engine for my needs, I checked A LOT of the available SDK's out there, & while I still don't know what I want, I now know what I don't want.

-coming from over 20 years of pascal, I didn't even know what C# was, I naïvely thought that it was what C was to C++. But ok, it's managed code, no thanks, I like to know what's happening behind my back. Also coming from Delphi, I'd rather stay away from that horrible .NET (well when it came to Delphi it was a horrible experience).

So I figured out that C++ was probably my best option. Sure I'll have to learn it, but the concepts aren't that different from pascal, it's just the language that changes.

-I thought that every SDK out there now worked the same, and that I was just too old for this. But no, things like XNA/Monogame or SFML still work exactly the way I like: a game loop, blitting stuff, full control.

So that most likely excludes Cocos2D:x for me, because it seems that it can't be used that way, it's using that same concept as in Unity: movable objects, events, etc. I really don't understand where this concept is coming from (Flash maybe?), nor how a game is made this way. I would really like to understand, but when I think of the not-so-complex platform games I was making 20 years ago, I really can't imagine all of the stuff in it being objects that belong to the graphic engine, I can't picture this working. I can understand why a game engine has to buffer commands, it's the graphic cards that require batching, but I don't understand why a game engine wants to control animation & stuff.

To me a game is: a game loop (nowayays the loop advances in variable steps, that I understand, screen refreshes are not a constant anymore), processing input, doing game logic, rendering the stuff. All in clear blocks.

Problem is that the "simpler" SDK's out there are generally the least supported. Looks like with Unity there is a TON of stuff to look at. With Cocos2D:X there's support for a couple of great things.

Anyway, C++ & "non-event-based" SDKs already limit my choices a lot, if I also select the ones that have native support for the Tiled map editor:

-SDL

-Allegro (these 2 I remember from a long time ago)

-indielib

-SFML

I've read that SFML (edit: neither SDL nor Allegro apparently??) doesn't do sprite batching by itself, too bad if it's true because the API looks simple. But I'd rather avoid having to dig in OpenGL myself, on top of having to learn a new language.

Cocos2D-X still has a main loop. You aren't forced to use the events and actions if you don't want to. You can still just blit your sprites to the screen and update their coordinates in the draw method the same way you can in Monogame or SDL. The actions are just their for your convenience. If you were to write a complex game at some point you would end up writing your own tweeting or interpolation methods and that is all that the Actions are.

Yes, I figured that out in Cocos2D:x, however it's unclear to me if its "sprites" are designed to be the real entities on-screen, or if they can be re-used on the fly.

That is, say in the first cycle of a game you have an enemy & the player on-screen, and in the second cycle, the enemy has disappeared, while the player is still there. The way I'd do it, I'd pre-create a tank of reusable (Cocos2D) "sprites", and during the first cycle, the enemy would use sprite#1 to draw itself, and the player would use sprite#2 to draw itself.

Then in the next cycle, the enemy wouldn't be there anymore, and the player would now use sprite#1 to draw itself.

But I don't know if that's a good use of Cocos2D's sprites, if there is a big penalty in changing a sprite's texture coordinates, and possibly its Z-order. In any case, it's the idea that an entity in the game is tied to a graphic object, that I don't like (I mean, those entities are none of the engine's business). And yes, I would probably end up writing motion stuff myself, but I wouldn't tie them to graphical objects, but to the game's concrete entities.

Another example, say I want a tilemap, with 3 layers:

-the background (decoration parallax layer)

-2 foreground "solid" layers, tied together, only separated to overlap tiles for more complex results

Now let's imagine I want to rotate the 2 front layers alone.

The way I'd do it, would be to first render the background map, and then render the 2 front layers in a temporary texture, and then rotate/blit that texture over the background.

I read about Cocos2D:x working exclusively in "nodes", and I couldn't figure out how this would work. But it's kinda critical, because if I want the rotated map to have antialiasing, the tiles can't be rasterized rotated, it would certainly go wrong on the edges. The map has to be fully rendered first (& in this case, the 2 front layers rendered to the same texture), and then the result can be rotated. But again, this is something I could figure out how to do with those "simple" SDK's, but with Cocos2D it looks like you have to fit this inside the node system in some way.

There's already tilemap support in Cocos2D:x btw, but reading the description I'm not even sure how it's implemented:

http://www.cocos2d-x.org/wiki/TileMap

In the screenshots section, the first one seems to hint that each layer is rendered to a texture. But the description doesn't hint that. And "Each tile will be represented by an CCSprite" can mean several things. But I assume that it's not really creating a sprite for each of the map's tiles, only the visible ones(?). And even here it doesn't make much sense to me.

I've also read about using a fragment shader to render whole maps, but it's not even something I'd want to touch, on top of having to learn a new language. Which is kinda why I'd rather pick the engine that has a philosophy that I understand but is also done efficiently. Because having to fix things myself in someone else's code will probably end up worse than having to do it from scratch in the first place.