Hello,

In another thread I was asking which language & API I should go for, coming back to games after 20 years (& knowing Pascal, which is more or less dead, for games, by now).

I've figured out that the best, since I'll have to learn a new language anyway, would be to check which tools are available out there, & to go for whatever API's they support.

20 years ago I had my own tools, and I'm looking for similar existing tools.

I had a good tilebank+tilemap editor, and here it mostly seems to be covered (on the paper) by the "Tiled" map editor, and more. It even seems to have solidity paths per tile (making me wonder if I couldn't also use it as a sprite bank tool), I didn't have that luxury back then. Also seems popular & supported, so this seems covered.

On the sprites side however, I'm finding a lot of simple texture packers and a lot of complex 2D animating tools (Spine, Spriter), but nothing "in-between". I don't need 2D animators (yet), however to me the bare bones of a sprite bank tool (of course back then I didn't need texture packing as nothing was 3D-accelerated, but I still had my sprite manager tool) are:

-sprite centering. Apparently existing tools (except Shoebox apparently) expect you to center your sprites inside a large blank rectangle. True that they will get rid of the emptiness anyway, but it's hard to predict your largest bounding box IMHO.
Do people really align/center sprites by code?

-collision/random rectangles. My tool had collision rectangles, the complex animating tools seem to have all this in free form, but the simple packers seem to have absolutely nothing here. Other kinds of points/rectangles/zones are handy when it comes to place points bullets are shot from, particle origins, etc.

Anyone has heard of such a good sprite bank editor with these features, or are Spine/Spriter the only options at the moment? They're overkill for me but hey, I assume they can be used for simple stuff as well.

Thanks

Welcome back ;-)

About game development frameworks:

It depends on what you plan to target with your games...

Cross platform, Mobile, C++ : Try Cocos2d-X

But there are many others, too: Unity (C#, cross platform), LibGDX (Java, cross platform), SpriteKit (Swift, iOS)

If you want to stay with 2D it does not really matter - they all have more or less the same functionality.

So it's more a matter of language.

> Do people really align/center sprites by code?

No. Of course not :-) You should align the animations - e.g. your character running right. But you don't have to align all sprites.

Did you try TexturePacker ? It should have everything you are looking for.

You can add any size of sprite to it. Just make sure that your animation phases are aligned.

It also contains a pivot point editor that allows you to adjust the animations if you have different cropped images.

The real time preview shows you how the animation will look like.

It also removes transparency around your sprites (if you want) to pack the sprite sheets as tight as possible.

The information is stored in a data file that contain the name of the sprites, the coordinates and pivot points (if supported by the frameworks).

You can load these sprite sheets into all current game development frameworks (LibGDX, Cocos2d-x, SpriteKit, Unity,... )

If you want to roll your own - you can either use the generic data formats (XML, JSON) or even create your own data format.

It also contains a pivot point editor that allows you to adjust the animations if you have different cropped images.

The real time preview shows you how the animation will look like.

Ah, I hadn't read that in its features list. Sounds like an option then, thanks for the info.

Perhaps it's then everything I need when combined with PhysicsEditor, assuming that it allows more than 1 path per sprite.

Yeah I've read in depth about all those engines, and I keep hesitating. Mainly between Cocos2D-x and Monogame.

So many choices.. I even gave another try at Blender to see if I couldn't get into 3D (afterall, more time spent on models, but less on animation) and I still can't figure out any of it.

> Yeah I've read in depth about all those engines, and I keep hesitating. Mainly between Cocos2D-x and Monogame.

Right - Monogame is also an option...

I personally would use cocos2d-x. Not only because I prefer c++... The physics integration of cocos2d-x is quite nice.

It also has built-in support for TileEd's TMX files.

And you can easily port the game to all kinds of targets: iOS, Android, Windows, Mac, Linux,...

PhysicsEditor supports multiple paths - and a loader for cocos2d-x is also available :)

> Yeah I've read in depth about all those engines, and I keep hesitating. Mainly between Cocos2D-x and Monogame.

I started reading about how sprites work in Cocos2D:x, and something didn't feel quite right to me.

When I was making games, what I called sprites were just the images, and painting them was a different part. Like, during each cycle, I would paint every sprite on purpose, the sprites were just the images, not the objects.

In Cocos2D:x, it seems that sprites are more like hardware sprites of an old console, they are the objects themselves. Looks like each sprite holds its position, scaling, etc, and "lives" by itself. Not really a concept I like, to me the real "entities" should be things like the player's character, enemies, etc, which are responsible for painting themselves, whether it's from 1 or several sprite images. But linking them to other "living" entities seems like a weird concept, one that's linked to old hardware.

But maybe Cocos2D:x also has support for programmer's responsability to paint?

Or is it a common thing to create a "sprite pool" and steal them in order to paint randomly, like in 1 frame an enemy uses Sprite#1 to paint itself, and in the next frame, where the enemy disappeared, that same Sprite#1 is assigned another texture/rectangle, so that the player can use it to paint itself? That would make sense, but that's not really how I understood Cocos2D:x's normal handling of sprites.

Afterall, even just due to z:ordering, using MonoGame I wouldn't let an enemy paint itself by sprite batching directly, I would more batch its commands myself, z-sort all this once everything has been processed, and then spritebatch the sorted array of commands. So is this "array of commands" what sprites are in Cocos2D:x?