Hisami game TouhouFest 2024 update

A quick search gives me https://www.blankmediaprinting.com/cd-printing-custom-cd-labels these people can print CDs in jewel cases for $2.39 (for 25-49 CDs, it gets cheaper if we do more). They can print booklets to go with the CDs for a few 10 cents extra per CD. For convenience, we could add a download link in the booklet. There are a ton of other options and we probably want a handful of them. Each add a few 10 cents. With taxes, it might go as high as $4 per CD. I think Aeon also can print CDs, but I'm not sure if he can do artwork, etc? If it's just a matter of burning a CD, I can already do that, but unless we do something to decorate the CDs by hand, I don't think a plain burned CD adds much value over a simple download.

Similar to the cards Rak distributes, or just a business card. We could ask Rak what he does. Seems like we can get 100 cards for $19 here: https://www.zazzle.com/book_launch_author_promotional_book_cover_business_card-256986777803860614

Probably prohibitively expensive, even for uselessly small USB drives? The cheapest on Amazon are like $6, but we'd want customization to make it feel special and specific to our game.

I like this because it's relatively easy to implement.

If we break up the game into different difficulty levels, each with about 20 stages, the player is likely not going to force themselve to play more than 20 levels at a time unless they really want to play more. This'll prevent fatigue.

A downside is that players may not come back for a 2nd play session, if they are satisfied with clearing on the lowest difficulty, since that alone would be a complete experience and may be satisfying enough to some players.

I'd like 2 to 3 difficulty levels (Normal, Hard, Lunatic?), where each difficulty is a completely different set of levels and you unlock higher difficulties by clearing the lower.

Each difficulty could easily have different tilesets and even different stories (but they don't have to), so it's a flexible game structure that can be adapted to any level of effort.

If we somehow can come up with an intriguing story, it'll provide the player with external motivation which might let them overcome puzzle-solving fatigue. We'd drip-feed them story at regular intervals. Perhaps by having them talk to NPCs during the levels or through cut-scenes. The great difficulty of this approach is to come up with an actual story that's compeling enough to overcome puzzle-fatigue. That's not an easy thing!

Eat the grapes on Minoriko's hat.

Eat the peach on Tenshi's hat.

Could be about stopping Mokou/Kaguya from escaping. Or just about breaking out of Hell yourself so you can get scolded some more.

First stage(s) of campaign starts as normal Eientei, but then Reisen appears and hits Hisami with her 'lunatic red eyes'. The rest of the campaign takes place in some lunatic fever dream. Could use a mishmash of other tiles floating in a void. (These kinds of dungeons are very popular late-game dungeons in JRPGs for a reason, becasue it's a good way to reuse assets.)

Two potentially different flavors of this idea (that could be combined):

• Focus on the external influence (Reisen): large red rabbit eyes, perhaps during stage transitions, perhaps always in the background.
• Focus on Hisami's mind: fill the stages with things on Hisami's mind. Like grapes, peaches, bamboo, Zanmu. Could be erotically charged, since this is Hisami's madness-induced fever dream. (pin-up/swimsuit Zanmu posing with grapes, etc)

The first flavor works as it is: it's easy to understand since the player just got attacked by Reisen. The 2nd flavor would ideally be combined with some elements of the first flavor, to make it clear to the player that what they are seeing is a result of Reisen's attack.

Hisami slides until she hits something or lands on a normal floor tile or falls into a pit. There are some nice interactions with the grab mechanics, since we can grab blocks to effectively alter the shape of the player character to setup wall collisions to exit the slide.

Potential art complications: Pushing other 'blocks' onto the ice should make them slide as well. Fairies, Kaguya and Mokou and regular blocks are all 'pushable'. The fairies and Kaguya/Mokou may need a slide animation. Or they could just slide in their idle animation, perhaps with some extra effects? There are additional complications that arise due to having movement (here, sliding blocks) that is separated from the player movement. Since many of the same complications arise with having moving enemies, I'll discuss them in a separate section.

Adding enemies would make the game feel much more complete and lively, and would add a nice action element to the game. Since enemies would move on their own (not tied to player movement), many of the same complications would arise as in the case of blocks sliding on ice. Again, see this section for a discussion of these complications. They may also need unique animations for when the slide on ice, since this is a special state where their AI doesn't apply.

Here, I'll list a few potential enemies. Personally, I think the melee enemies are more interesting, and it's also less work since it doesn't need a sprite that can face in all 4 cardinal directions.

Could substitute 1x1 wall tiles in certain tile sets. Could also be slightly different from regular walls, in that you can push blocks through them – but not blocks you have grabbed, as your vines will catch fire!

Gets destoyed by being pushed into fire.

Face your inner darkness! If we go with the 'madness' level idea. Mirrors your movement. Palette swap of Hisami?

Here, I'll be using the word 'tilemap' in a technical Godot sense.

The floors, walls and holes (etc) in our game exist on several 32x32 grids, each being a seperate tilemap. Each tilemap spans all of space. Each tile ('cell') in the grid can be empty, or occupied by a specific tile. Since the play area of our game is limited to a single screen, most of this infinite space is just empty tiles, which is the default.

For manual (non-auto) tiles, like the floor, we just override the default empty tile with a specific floor tile. Tiles can have different sprites, and even collisions and other properties, but our floor tiles have no collisions and are basically just sprites.

Sprite size vs tile size

The sprite of the tile can be larger than the cell size of the tilemap. For example: if a tile with a larger sprite than the cell size is placed next to empty cells, it will just intrude upon those empty cells. If the nearby cells are not empty, you need some way of determining who renders on top of each other. Often, you want them sorted so the tile lower on the screen covers the other, which can be achieved by just clicking box. The lower part of the grass tiles above another grass tile will not be shown.

The Eientei floor has sprites that are the same size as the cell size, so this is not an issue. However, it will be an issue for our wall autotile, so I thougth it'd be easier to cover it here, to separate it from the complication of autotiles.

Autotiles

In many cases, we want our tiles to look (and perhaps even behave) differently depending on neightboring tiles. Autotiles are a way to solve this problem. Basically, it is a map from neighboring tile configurations to a specific tile. A basic autotile only cares if a neighbouring tile is occupied or not, so we can represent it as a bitmask where a bit is either true or false. For 3x3 autotiles (the only thing I ever use), we'll only consider the neighboring cardinal (east, west, etc) and diagonal (northeast…) tiles, as well as the 'center' position, so we use 9 bits. The 9-bit bitmask is typically represented as a 3x3 grid on top of a cell, representing the direction of the neighboring tiles the bits represent.

Note that for 'simple' autotiles, '5' (representing the tile under consideration) will always be filled, since it often doesn't make much sense to think about what tile to place in a position if that position is empty.

The 'hole' autotile for Eientei is particularly simple, so let's use it as an example. It only cares about whether it has a non-hole tile above it or not, and otherwise always use the same tile. Holes with more complicated edges will likely need a full set of autotile tiles.

The wall autotile in the jam version uses everything we've discussed so far: the cell size is 32x32, but the sprites are 32x64 (but has transparency for the top part, so it never covers the full 64 pixels). The sprite is offset so that it sticks up from the tile where it is placed, but the collisions are only for the bottom 32x32 part of the sprite. Note that half of sprite of a tile which has a wall in the cell to their south will be covered, as the sprite of the tile in the cell to the south extends a full 64 pixels up. This doesn't really matter, since we are covering walls with walls that look the same, but we could have drawn less pixels if we were clever. The walls with no wall tiles in the cell to the north are shorter, to make sure not to cover any non-wall tile.

If we wanted the walls to cast shadows, we'd have to extend also extend the sprites down/left/right (96x96 would be easiest). To make shadows, we'd add semi-transparent black to tiles next to non-wall tiles to darken the tiles rendered underneath (like the floor tiles). The 96x96 area would be mostly empty, since we only want some shadows to extend slight below and left/right, but I like to work with square tiles.