next »

[qMopey]

Demo available!
Click link to play in browser (desktop only). Feedback welcome  
https://www.randygaul.net/games/block_man.html

~ An icy girl known as "Block Man" makes a slow descent to find something she lost long ago, something deep and forgotten... ~

The list of updates.

• Initial GIFs
• Quick and dirty level editor
• Simplest background system I could think of
• The Darkness

[qMopey]

Here's the initial batch of images from early development! In no particular order

[qMopey]

Trying out more saturated colors, as everything was looking a little bland. Also went with 3x pixels instead of 2x. 2x was a little too hard to see. Going to probably work on some background art next!

[buto]

I like the character and the smooth rotation animations. Nice pseudo 3d pixel art look!

Interaction with the blocks on some of the gifs looks really cool. Especially the ones where you pull them from a distance and push them to distant places really fast

If you can dodge the tediousness of some block-pushing games, e.g., by those fast pull/push actions or some cool special powers, this could feel pretty crisp, I think. certainly looks cool

[qMopey]

Thanks buto! Worked pretty hard on that rotate, now just need to find a good use for it    I have some ideas for obstacles and powerups, we'll see what happens!

In about 45 minutes I've setup a functioning level editor. Dear ImGui really is quite amazing.

[oahda]

Looks great! And of course have to say yay to ImGui! So what's all the spinning about?

[qMopey]

Spinning is for this XD

[qMopey]

New ice block and sheen when holding 

[oahda]

Spinning is for this XD

Good use of spinning!

[qMopey]

Now with ICIER ICE

ooo shiny (reflection of girl in the ice)





Special thanks to FlohOfWoe for his sokol_gfx.h header! Really makes adding little FX like this quite easy.

[Sp1ke]

I'm possessed by Neo political correctness. It's block woman! 

[qMopey]

I'm possessed by Neo political correctness. It's block woman!  

Aha! Good catch. Though, it's said she does identify as a man, and also doesn't mind much which pronouns she's referred to by  


Background Brick Tiles

New backgrounds! Block Man (aka Icy Girl) will be set within a crypt. So the art direction for the game will be 75% cute and 25% creepy  



I needed backgrounds but didn't want to use a level editor, tile editor, or anything like that in order to save time. I just need something that looks nice and can be done in less than half a day and forever after forgotten.

I implemented as simple of a system for drawing backgrounds as I could think of. After studying Minish Cap background tiles, I noticed a clever way to tile bricks with only two basic patterns that must be applied in a checkerboard pattern. Since I've designed this game to have a screen similar to a Game Boy Advanced, I chose the game's internal screen dimensions to be 320x240 pixels, and tiles to be 16x16. This leaves a screen size of 20x15 tiles.

However, since the tiles are *not* odd dimensions it is impossible to perfectly tile bricks or squares within a single tile by dividing it in half, or any equidistant amount of pixels. Below is a picture showing an example of how it's not so easy to make tiles for an even number of pixels with just squares/rectangles, without big 2-pixel thick borders, or unevenly sized borders.



What I noticed in Minish Cap was the trick to simple leave one side of a tile without any brick borders. This offset bricks within one tile by one pixel... But the result looks great! And the tile pattern of zig-zag bricks is really nice to help give the background some variety and break up all the horizontal/vertical lines.



So this means there are two types of tiles, like a checkerboard. Ones with two horizontal bricks, and ones with two vertical bricks. That means I can hand-draw maps with two different elements like these (below), and easily render them.

Code:

array<array<string_t>> BackgroundMaps = {
	{
		"XXXX0000XXXX00000XXX",
		"XXXX00000XXXXXX000XX",
		"00XX0000000XXX000000",
		"00000000000XXX0000XX",
		"00XX000000000X00XXXX",
		"00XXX000XX00XXX00XX0",
		"00XXXX00XX0000000000",
		"0000XX0000XX00XXX000",
		"XXX0000XX0XX00XXX000",
		"XXX0XX0XX000XXXX0000",
		"XXXXXX0XX00XXXXX00XX",
		"XXXX0X0XX00XXXXX00X0",
		"XXX0000XX000XXX0000X",
		"XXX00XXXX000XXX00XXX",
		"XXX00XXXX000XXX00XX0",
	},
	{
		"00000000000XXX0000XX",
		"XXXX00000XXXXXX000XX",
		"00XX0000000XXX000000",
		"XXXX0X0XX00XXXXX00X0",
		"00XX000000000X00XXXX",
		"00XXX000XX00XXX00XX0",
		"XXXX0000XXXX00000XXX",
		"00XXXX00XX0000000000",
		"0000XX0000XX00XXX000",
		"XXX0000XX000XXX0000X",
		"XXX0000XX0XX00XXX000",
		"XXX0XX0XX000XXXX0000",
		"XXXXXX0XX00XXXXX00XX",
		"XXX00XXXX000XXX00XXX",
		"XXX00XXXX000XXX00XX0",
	},
};

Then I exported two arrays of tiles, one for each checkerboard spot. After doing a little bit of math, and using a seeded RNG generator, unique background tiles are selected for X and 0 based on the given map. Briefly: an X is picked as either a red/black checkerboard pattern based on its index, and then a random tile of that type is deterministically chosen to be drawn. Here's the function to initialize an array of brick sprites.

Code:

void InitBackgroundBricks(int seed)
{
	rnd_t rnd = rnd_seed(seed);
	int background_index = rnd_next_range(rnd, 0, BackgroundMaps.count() - 1);

	background_bricks.clear();
	for (int i = 0; i < 15; ++i) {
		for (int j = 0; j < 20; ++j) {
			string_t path;
			if (BackgroundMaps[background_index][i][j] == 'X') {
				if ((i & 1) ^ (j & 1)) {
					path = BricksEven[rnd_next_range(rnd, 0, BricksEven.count() - 1)];
				} else {
					path = BricksOdd[rnd_next_range(rnd, 0, BricksOdd.count() - 1)];
				}
			} else {
				path = "data/brick_empty.png";
			}
			sprite_t s = AddSprite(path);
			s.transform.p = v2((float)(j * 16 + 8 - 320/2), (float)((15 - 1 - i) * 16 + 8 - 240/2));
			background_bricks.add(s);
		}
	}
}

So now backgrounds can be easily added by modifying text arrays to pick where bricks are drawn, the brick image index is randomly chosen, but, the checkerboard pattern is preserved. Also since the RNG is deterministic, each level is assigned varied tile indices automatically!



All in all the code took about 25 minutes to write and integrate into the game! Yay, as simple as possible backgrounds achieved

Though there's no background walls... Yet.

[buto]

Looks very good! Thank's for the detailed overview!

[qMopey]

WIP on some walls of the church crypt. Learning a lot about pixel art, but it's a slow going for now. Open to any advice from you wonderful artists out there!




Edit: 8 hours later after some sleep, altered lighting on the arch + wall to darken everything. It's too bright, especially for a crypt.



Still very unhappy with the wall bricks. Going to instead aim for something more flat and much simpler with less noise. 2 colors, instead of 3.


Edit: Tried to reduce noise of brick wall, went with flatter pattern with bigger shapes.

[qMopey]

No visual update this time. Instead I was watching Noel Berry's twitch stream where he showed a cool platformer game he's working on over the weekends. Inside of his code he was parsing Aseprite files straight into animation objects for the game to use. The idea is really a great idea, so I went ahead and wrote a single-file header library to parse .ase/.aseprite files. It's here in my cute headers collection, and is called cute_aseprite.h!

Here's some of the docs for cute_aseprite.h.

Code:

/*
	DOCUMENTATION

		Simply load an .ase or .aseprite file from disk or from memory like so.

			ase_t* ase = cute_aseprite_load_from_file("data/player.aseprite", NULL);


		Then access the fields directly, assuming you have your own `Animation` type.

			int w = ase->w;
			int h = ase->h;
			Animation anim = { 0 }; // Your custom animation data type.

			for (int i = 0; i < ase->frame_count; ++i) {
				ase_frame_t* frame = ase->frames + i;
				anim.add_frame(frame->duration, frame->pixels);
			}


		Then free it up when done.

			cute_aseprite_free(ase);


	DATA STRUCTURES

		Aseprite files have frames, layers, and cels. A single frame is one from of an
		animation, formed by blending all the cels of an animation together. There is
		one cel per layer in the entire file. Each cel contains its own pixel data.

		The frame's pixels are automatically assumed to have been blended by the `normal`
		blend mode. A warning is emit if any other blend mode is encountered. Feel free
		to update the pixels of each frame with your own implementation of blending
		functions. The frame's pixels are merely provided like this for convenience.
*/

Next up is for me to hook up the aseprite loader to a proper animation wrapper. I actually have been hacking animations in so far, so it'd be nice to have a *real* animation abstraction.

[qMopey]

Since the game was born from a game jam, I spent some time re-implementing the entire game within an entity component system rather than the pure ad-hoc architecture of before. I was getting bogged down with lots of copy pasting. I also revamped the "asset pipeline", which just means using cute_aseprite.h to directly parse aseprite animations, as all the old animation code was *really* hacky. I won't get into all the technical details, but I was able to add reflections and shadows to everything with reusable components. I'm also prototyping some other entity types, but that will have to wait for another devblog entry!

For now, just shadows and reflections on everything!

[qMopey]

Added shadows. Made a mochi monster (not shown here just yet, but it works and is in the editor preview). Made a real level editor. Surprisingly the game works with multiple player instances, without intentionally designing the code to do so... Cool  

[qMopey]

Prototyping something...  

[qMopey]

It's now controlled by a slider from 0 to 1

[buto]

Oh wow - looks pretty spooky. Especially when those arms/worms reach into the light circle.