Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

The stripes and consistency are certainly a step forward!

A lot of my tools I use have pretty primitive importing/Sprite sheet support.  So I can only specify how big a cell is and step over them by index.  In other words, the characters are imported as a block of images, similar to a tilesheet.  With the game engine only understanding each frame/pose as an offset of the positional index.  Think along the lines of rpg maker sprites or old nes Sprite sheet data.

I realize you would lose the labling, and it might be a lot of work, but it could be handy to have a second version of the sheet which just has the character sprites in a grid on their own, for such index only engines. 

You could offer both so users can still use the first as an animation reference or for more advanced engines that have a mapping/frame system.

On the other hand, that new layout already looks much easier to rearrange from on my own as well.

For my personal use case I was actually going to use this for a platformer main hero Sprite, so I would be editing or skipping animations anyway.  There is only left and right in my platformer world. (Making an old school looking GB style platformer for fun and to learn some engine stuff in app game kit). For more "normal" use the above format could still be very useful in a lot of game engines.

Keep up the great work!  These sprites are filling a great little gap for retro but original sprites. :)

Thanks for the kind words.

I'l certainly consider what you say, and look to make the sprite sheet more 'Universal'. I did once upon a time create sprite sheets with and without 'offset', maybe i could do this again. I was thinking of downloading the 'Trial' version of the software you were talking about to get a feel of its interface when it comes to importing sprite sheets, not sure if it will be the same though? As for labelling, it wouldn't be a problem to duplicate the sprite sheet and then remove the labelling, its merely a reference really.

Index only engines is interesting, because technically, the sprite sheets uses a lot of duplication's, or 'Recycled' tiles to create all what i have so far, just like you would if you were indeed using a BMP file for 'primative' consoles such as a NES. In-fact that's exactly what there based on. Animations/frames put together using (what would be indexed) 8x8 sprite tiles. :) If i was to remove the duplicate 8x8 tiles from the sheet, it wouldn't be half as big as it is now, and then removed the 'Mirrored' 8x8 tiles as well. The biggest task and work would be to actually document the 'Meta data' to to create each 'frame' of an animation in a 'state', especially with so many.  However, if there was a call for it, if someone asked me the 'meta data' information in assembly code as an example i would try and do it. :) trouble is, i don't think my work is that good at the moment to warrant being asked and there isn't much call for it, and with most software not needing such data these days im not sure its worth me doing, hence why they are set up as they are. :)

Let's see what you think of the new reworked sprite sheets when i release them, then you can tell me if there better or not, or let me know what could be improved. honestly, i appreciate the feedback. There's no point me doing the art if it cant be used, i want it to be used! :)

The tool I'm using is actually closer to a programming tool, it doesn't have "Sprite importer" so much as commands to create them myself.  Here is how a Sprite sheet image, previously loaded with a command, could be created into a Sprite for example:


https://www.appgamekit.com/documentation/Reference/Sprite/SetSpriteAnimation.htm

As you can see the engine has this primitive charm to it.  It expects all the animation to just be frames scattered over sheets.  It also expects the user to code just about everything, the tool itself is a basic language sdk more then anything visual.  It just happens to be hooked up to a very efficient renderer/processor capable of some sweet graphical outputs with a lot of under the hood work done for the user already.

I am actually making a little level editor using said tool, with a Sprite blitting itself around the screen to create the tiles of the game.  So then I just call a draw tile function and let the single Sprite do its thing.  It is very similar to old school game engines in that regard.  I find it fun to use, though many others would probably be like "why?".  Sometimes such limits are what keep me going.  I like taking silly limits and really pushing it. :)

I will look forward to the update!

(1 edit)

Would this be better? no labelling, 4 frames that run left to right, no offset. 16x24pixels.

Files have been updated, i hope these are much better suited for your needs. thanks for the feedback.:)

Apologies for keeping you in suspense.  Life surprised me.

Those are perfect!  Thanks so much! :)

Your welcome! Good luck with your game, be really cool to see it, so don’t be shy of showing it.:) I thank you for your feedback for these assets, I am always willing to make them better so getting the feedback is important. Any other issues or problems you may have with these or other assets of mine, be sure to let me know and il do my best to for fill the developers requirements. All the best! :)