[WIP] CastleBoy - Castlevania demake!

[dir3kt]

Hello!

With @Increment we are working on our first Arduboy game. He does the pixels and I do the code. We are trying to produce a game similar to old versions of Castlevania.

Here is a short preview of the beginning of the first stage (still rough in terms of level design):

Currently the game takes 60% of the Flash. We still have a lot of stuffs in store to stay tuned

We hope to finish it by christmas

[bateske]

Be sure to talk to @JO3RI about compression if you'd like to fit in more levels. This looks great!!

[Botisaurus]

Wow this is amazing!

[JO3RI]

Someone called me ?

@dir3kt make sure to create all your levels first (even with place holders), so you'll have an idea of how big the code will grow. When you've got all levels, add bosses (if you're intending to do so).

For how to compress levels and maps have a look at our technical page for "Virus LQP-79" http://www.team-arg.org/vlqp-technical.html

And the technical page for "Mystical Balloon" http://www.team-arg.org/mybl-technical.html

[DarkLord]

Wow that is awesome. I can't wait to see more on this game.

[dir3kt]

Hey thanks a lot for all the positive responses!

@JO3RI thanks a lot for the links. Actually what you did for Mystical Balloon is very close do what I do currently. However I use 2 bit per tiles so I can differentiate between empty tiles, grave tiles (background props), 'wall' tiles and ground tiles. Each tile is rendered differently depending on its neighbor. For example first empty tile under a wall tile as a small effect, first ground tile as some grass, etc...

However I do think this is not enough as we also want to have interior stages which will have subtle tiles such as chains holding the platforms and windows/walls in the background. Because of that I need to increase to 4 bit per tiles which will give 16 tiles to play with! But also double the size of all stages...

So I though of another technique which I will try to explain here. Maybe somebody already tried it and can tell me in advance it's a bad idea

In the level there is lot of repetition so it seems that RLE can give good compression rate (to be checked with real data). The problem is it would take too much RAM to decompress a full level.

Frame rate is 60FPS.
Each tile is 8x8 pixels and there are 16 different tiles (4bits per tile).
The game only scrolls horizontally so in height there is always 8 tiles, not less, not more. Width of stage can vary (max is 256 tiles).

My idea:
Split each stage into RLE compressed blocks of 16x8 tiles. The RLE would simply bit 4bit RLE + 4 bit tile data, so it fits into one byte which makes it easier/faster to decompress. As one block takes the whole screen horizontally only two blocks need to be loaded into the RAM at the same time (16x8x2x4=1024bits=128bytes). When the player enter a new block I only need to load one block of 16x8 tiles into the RAM. Now the big question is can I decompress the block within one frame without having the player noticing it?

If this is too slow I can also try to use smaller blocks (e.g. 8x8). However I'm scared this would dramatically reduce the efficient of the RLE...

So basically the idea is to have a 'streaming RLE algorithm'.

[crait]

WHOA!

This is really looking great!

[JO3RI]

Go with half screen blocks, and get 4 buffers. You'll have maximum 3 half screen visible at once, so the 4th can be loaded while walking (left if walking left and right if walking right) and you only have to switch buffers when needed.

BUT I wonder if you'll gain much bytes this way. We have double tile-sheet working on the fly, without the use of RAM and without hiccups.

What we do is create a tile-sheet of 8x8 bytes and then we create "room" chunks that actually result in a new tile-sheet (using for example 64x64 sized tiles). Maybe better explained here: http://www.team-arg.org/dun-technical.html

Using this way, you don't need decompressing, you just lookup the correct tile, 2 tile-sheets deep. We also do collision tile based. Put the tiles you can go over at the beginning of you tile-sheet. Collision is nothing more than, if (tile > 4) collide; (or whatever tile is the first one you can walk on)

[dir3kt]

You were right @JO3RI I run some numbers and RLE doesn't give a good compression rates on my maps. I will stick to the Mystical Balloon approach but with 2 bit per tile. The technique you used for Dungeon is very interesting but I don't think it's very usable for a platformer, as there are lot of variations in the placement of the tiles.

Actually I followed your advice to add placholder maps. Plus I added placeholder scenes for title, game over, .... Now I get a better idea about the size of the game. I still have 10k left for extra enemies, bosses and juiciness!

[bateske]

I'm a big fan of procedural generation but you've got to get really tricky to get the maths to created unique elements that are fun to play.

http://community.arduboy.com/t/squario-the-ultimate-adventure?source_topic_id=2600

Squario is a fairly good attempt at this, but the levels are not that complicated

[JO3RI]

@bateske the trick is to use a seed in procedural generation
We'll explain once we finish Arduventure. It will use a combination of both procedural and fixed in a way that it gives interesting results AND is always the same when restarting. In Dungeons 2 (we are working on too) the seed will change on every game restart and will be different for every player. BUT stays the same during a game or when continuing a saved game.

@dir3kt do you think you would need more than 256 chunks ? If you create 12 levels, you have 21 different chunks for every level you can use. If you split it out in worlds, for example you have 4 worlds, it means you could create like 64 chunks to use in each world ... a chunk could be for example 1/4 screen. And if you only use 2 bits for each tile => that would mean 32 tiles = 8 bytes for each chunk. Or 2048 bytes for 256 different chunks.

Level size = amounts of chunks in a level. 16 full screens = 16 * 4 = 64 bytes for 1 level. That's a total of 12 levels = 12 * 64 = 768 bytes. Don't know how many tiles you're using but with 8x8, that's 8 bytes for each tile. if for example you have 32 tiles, you'll use 256 bytes.

All this results in a total of 3096 bytes for 12 levels in 4 different worlds and each level is 2048 pixels wide.

[Gaveno]

@dir3kt what if you use a combination of the two approaches? Mystic Balloon style for the foreground and something more along the lines of Virus or Dungeons for the background? You could create a few generic chunks that are repeated for the background.

[dir3kt]

@JO3RI again, thanks a lot for all the info! I think this could work however my biggest issue with this approach is that it constraint level design. Also I don't need so many levels! My aim is to have short level with different enemies. Currently my plan is to have 9 levels of 96x8 tiles + 3 boss levels of 16x8 tiles (single screen). With 2 bit per tile this sums up to 1824 bytes.

The seed trick for Arduventure is so neat! Fixing the seed to make the player feel the game is not randomly generated is such a nice idea. Also excited about Dungeons 2

@Gaveno Actually this is mostly how background work but in a much more basic way. What I do is I choose tile in function of the row/column position. For example in the indoor level a window is placed each 4th column of the 3rd row, if the tile is empty.

[pixelplatforms]

This looks incredible!

[DarkLord]

Excited to play this game. Been busy and haven't been to the community in a while.

[fjsantosb]

Hi dir3kt,

Very cool project; It really looks great!

Regards,

[Dreamer3]

However I do think this is not enough as we also want to have interior stages which will have subtle tiles such as chains holding the platforms and windows/walls in the background. Because of that I need to increase to 4 bit per tiles which will give 16 tiles to play with! But also double the size of all stages...

Stages could also be encoded differently depending on the complexity needed... or even switch encodings for different sections.

[dir3kt]

Thanks for all the positive comments

Yeah I also though about a similar approach @Dreamer3, for example use RLE for outdoor and standard encoding for indoor, etc.. At the end storing tiles in 2 bit and using rendering trick seemed to make it. The levels are not so big and the code is so expensive that it would not have made us gain a lot of bytes.

We have 3 stages, each with a different style and each with an end boss. We still have a bit of work on the last boss as well some help/end screen to add. We have 3k left. So we can make it!!

By the way here is a quick preview of stage 2:

For some reason I can't edit to OP. (???) So cannot added it here...