Jump to content
  • Advertisement
Sign in to follow this  
anothergol

Finding the right sprite "bank" tool

This topic is 834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Edited by anothergol

Share this post


Link to post
Share on other sites
Advertisement

Welcome back ;-)

 

About game development frameworks:

 

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

 

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

Web, Html, Javascript: Try Phaser

 

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.

Edited by Andreas_Loew

Share this post


Link to post
Share on other sites

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.

Edited by anothergol

Share this post


Link to post
Share on other sites

> 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,...

 

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

 

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!