It’s time to start filling out the game with placeholder content — all the tiles, mobs, weapons, effects. etc. Anything that is going to be an item (at least, the least amount) needs to have a placeholder. That way I can estimate, organize and fix up anything that still isn’t ready for “all the items”, so to speak.

Currently, I have 6 sprites for a “tileset”. I will be working with my atlas file, so I need to add debug names as I will be drag&dropping a lot of stuff between assets and it’s easy to get things wrong:

In fact, I am adding a preview of the sprites I linked in the definitions for a specific style. This is really important so that I can quickly spot any errors:

One thing I still haven’t added to tiles is variation, so I’m going to do that now while I reserve atlas space. I think I’ll have 3 variations for each tile:

This might look like overkill for debug-only sprite identification, but one just has to try doing this without these among hundreds of sprites:

I don’t necessarily need to have 3 variations. For example, wall tops can all be the same. Or I might need 6 floor variations. So I can move the tiles around a little afterwards. For now, I’ll keep it at 3 and mess with specific later. The important part is that I have enough room in the atlas and the sprites are together.

My current tile asset “layout: is basically that a theme (like “factory) just links to all the tile definitions individually:

This makes adding many tiles very cumbersome and not reusable. So I will make an asset that stores just the 4 tile:

It’s pretty much like the main collection, just without the style attached to it:

I’m also using some of my verification methods for editor stuff, so I can quickly check for common problems. For example, accidentally linking the same asset will immediately show errors:

I’ve made enough off-by-one or last-one-wrong errors to really want these everywhere. Besides, I might just forget or skip something a month from now and never notice.

And then them main collection can just link to these definitions one at a time per style (also with sprite preview):

So now the layout is more hierarchical, less redundant and I can reuse tilesets easier making new collection easier:

I also decided to add a quick timed sprite variation preview, so I can quickly spot any errors in the tile variations:

And now to spend ages making all the placeholders. Never underestimate the time to drag & drop so many assets:

I made 8 tilesets/themes and I think that’s the number I’ll stick to. This is already quiet a lot. I’m not entirely sure I can even have unique individual styles (room, hall, etc.) in the levels if I am to have enough tilesets between levels. They might just repeat between levels — hall style for one level might be room style for another. What I really need is color masks for tiles, so that I can recolor them manually. Not sure this is something I have time to mess with. And it also requires art with specific rules as I can’t just tint or hue-shift the tiles or something. I can use variations as these sub-styles, although then I have no variations. However I look at it — improving variety needs a hell of a lot more sprites.

Sometimes I just need to add all the placeholders and link all the wires to see the big picture.

So anyway, I can now have a list of all my (placeholder) tile collections (assets):

In fact, I will rename them “tilesets” instead of “themes” to avoid ambiguity.

And a similar list for my themes extended to all tiles:

Except I have this “first” and “last” theme that don’t quiet work anymore. The problem is that I want to reuse some themes for the first and last levels, but I don’t want to make a version for each of those and currently theme holds both the tiles and layout:

So I’m separating those into two:

Theme list can now specify themes applicable to certain levels:

And layout list can specify the layouts applicable to certain levels:

Now these no longer conflict.

I also decided to remove the grouping logic where I selected themes in a limited grouped-up manner:

Basically, I can’t easily correlate these to the ranges of themes. I felt like it was a bad idea to begin with and now I have to get rid of it, because it doesn’t even work anymore. I just hard-coded to select 4 themes per run and “spread” it along the levels. So the player will see the same tiles for a few consecutive levels. But I think it’s better than showing all themes and then not seeing anything new next run.

And all of this put together finally works:

Unfortunately, I sort of broke my per-level tile style variation. Unless I repeat tiles between themes, I would have to make new tiles. For now, I will just have the same theme throughout the whole level, because I will prioritize the main tilesets first. I can always adjust them later to make minor variations in color or something for special rooms. I hate that I don’t have certain rooms styled special, but I think it’s more important for the dungeon levels to differ first.

One idea I mentioned is that I really want to try out the tile palette for sprites. Make sprites in a limited number of colors and then recolor them. Not exactly a new thing, but it has some technicalities and considerations and, of course, maintenance. We’ll see.

I was going to add placeholder for all the sprites and assets. Tile placeholders was just one of the many I need and I expected to do them all together. Now I’ve done only tiles and it’s already taken forever.

MicroRogue DevDiary #106 – Tile and theme placeholders
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *