Today I learned what a texture atlas is, and also the annoying nuances of some names, specifically the difference between a sprite sheet and a tile sheet.

So you have sprite sheets (these I knew about) - sequences of images of an in-game object, usually for the purposes of animation, whether it is a character, monster, object, or whatever. They might be split up in various ways, such as a single sprite sheet holding all the frames for a given game object (eg. every animation for one character) or a category of animation for that object (eg. the character's running animations).

Each image in the sprite sheet has an equal amount of space eg. 32px wide by 48px high, even if the actual image doesn't fill the space, so given those dimensions per image, if you had five sprites your resulting sprite sheet might be 160px by 48px. Duplicate images may also appear where one or more animations call for the same frame.

They are easy to work with both manually and programmatically, but consume more storage space due to the additional visual space. They also require more memory to load and use, and if sent over the wire, they use more bandwidth too.

Then you have texture atlases (which I only discovered yesterday) - in 3D game development they mean something a little more specific, but in 2D they are a mess of individual images pieced together in a way that consumes as little visual space as possible.

The images in the texture atlas will not have uniform sizes and so can't be read as a sprite sheet. But they come with a text file (JSON and XML are pretty common, others are possible) that basically gives the details of the individual images within the atlas. Duplicate images can be filtered out, with each listed in the text file but referencing a single image in the image file.

They are harder to work with manually, but the text file can be used by an engine/framework/library so you don't have to do much. Smaller file size means smaller memory usage, and lower bandwidth.

Finally you have tile sheets - zero rules here, it is just a name not a "standard". They can be anywhere from a sprite sheet that doesn't have the same amount of space for each image, to a texture atlas image that doesn't have the text file to decode it, to a random assortment of images chaotically spaced.

They are (probably) not optimized for file size, they are difficult to work with manually, and programmatically they are the hardest to work with.

Why I am I talking about it?

Because, most importantly, I realised that the majority of my resources are just tile sheets 🤣

The character assets are all sprite sheets, so unless performance becomes a real issue I can use them as they are with no problems. A few animated items like lights and ceiling fans also have sprite sheets, but they often have annoying amounts of blank space so they could be better optimized.

But so many of the other assets are full of empty visual space while not being an evenly divisible grid. So they can't be used as sprite sheets (without some crazy code, or loading them in multiple times which consumes more memory), and they have no mapping files for me to import them as texture atlases.

For things like walls or non-interactive furniture & fixtures this isn't a big deal. I don't need them as distinct objects in Tiled. I can just paint them as tiles, and draw my collisions separately on a different layer since that seems to be best for performance. 100's of individual objects each with a hitbox object being checked for collisions is always going to perform worse than 100's of individual tiles with no care about collisions, and only a handful of manually defined hitbox objects being checked for collisions.

But it is a serious pain for doors, which are meant to be animated objects but some do not have an evenly spaced grid layout in the tile sheet, and it also makes it harder for me to use furniture that I want the character to interact with and be able to open and close such as the cupboards and boxes that have different opened and closed states in my assets.

I can't just repack all of my assets because I'm not going to use every single one in this (or probably any other) game, so loading texture atlases with absolutely everything packed in there is as bad as, or worse than, loading only the separate images that I need. Also it is a huge waste of my time.

So I am left with a few options....

I could work out most of what I am going to use now, separate them into logical groups and repack them as texture atlases, and then I can code accordingly as I go. This requires some hard thinking on the locations and objects I need in this particular game, which in turn requires more progress on the story.

Or I just split only the potentially interactive object images into usable separate images now, create sprite sheets where needed, and when the game's levels are finished I can repack exactly what resources I've used as texture atlases, and change the code to fit too.

Or I could (again) put some effort into the story so I know my requirements for locations and objects. Then anything I identify as needing a sprite sheet, I make into a sprite sheet, and the rest I leave as tile sheets and only look into texture atlases if performance proves to be a problem.

I think I will go with option 3.

I'm not planning this game to be huge, so I doubt I will need the performance boost of texture atlases over sprite sheets/tile sheets. Pre-optimization is one of the big time wasters in programming, and if I do need to optimize I can handle the texture atlas packing and necessary code changes later.

Also directing some effort into the story is a sensible move right now - it will help me determine the game's necessary features, and will help me not waste time on the unnecessary features I am dreaming up.

Features like movement & pathfinding, area transitions, object interaction, inventory, and conversations are necessary. But mechanics like hiding, visibility, and noise will be a waste of my time if I don't find reason to introduce a scene where something or someone is stalking the character.

So, it looks like my next task will be to dig into my collection of story hooks and turn some of those random thoughts into a more cohesive idea. Meanwhile I still have movement and pathfinding that I am working on. I've also got another post I plan to write which will brainstorm some of my ideas on how to introduce horror into the game.