Don't worry. It's been awhile since I studied the ancient Egyptions, but I'm pretty sure they didn't have reanimated mummies or golems guarding their tombs, either. ;P

Wah wah wah wah wah... The fact that no one hasn't seen them, yet is no proof that they are not there. 

Needed a break from animating golems. The animations are indeed not very Golem-like. Not that we saw a real Golem doing better, but yes... He should probably move slowly, but with force.


More tests of inertia and friction of the hero... (a small dust animation on breaking?) On the right side, the hero stops when he slithers towards a gap. (using the fall animation frame for that)


Some egyptian backgrounds, like statues and columns... (reference on the right side)

Because both columns and statues are in the background, I only used 2 dark colors. Don't like the columns very much, but this is my very best try. I can do columns build out of small bricks, but the egyptian columns are pretty much solid, right?

Yes, these are only "animation-mockups"... So it might be necesarry to cut of the slide or the friction. It's hard to say without actually playtesting it. But I would prefer to keep them. Some guy from tigsource made the suggestion, that you are actually controlling the hat in the game, instead of the guy.  

The sliding and slithering might be a problem when you slide towards an edge. Then you will fall down. There are 2 possible solutions to this problem:
- the hero falls over the edge, but manages to grab the edge with his hands.
- the hero rows with his arms for a second at the edge and finally manages to stop. (oh no, more animations!)

Good to know that there're over 100 blocks left. There's no absolute need that one single tilemap covers every room. Each room might get its own tilemap with 256 blocks. That would just eat up more memory, but the rooms could be loaded from disk or cartridge, so I don't want to restrict the graphics here. My converter actually works this way, it reads the PNG of the mockup and builds a tilemap and the tiles.

Anyway, I was tinkering with more animations...


rope climbing...


old - new

runnig: tried to make the running more dynamic (does not really look better)

->
(disclaimer: only the left picture is certified, the right one is ignoring the C64 restrictions here - just a color test)

A solid gray background looks interesting... But I think this contrasts to the style of all the mockups I made so far (with a black background). I had to test it, but I couldn't make it significantly better. I think a need a little break from drawing backgrounds, maybe some ideas will fly by then.
   
I understand now what you meant with embracing and I like the new dithering on the rock golem. (in fact, this was the 3rd or 4th try to draw a golem) I also tried to "camouflage" the wide pixels in the green mockup by drawing some edgy plants, but in the end Helm's dithering looks better although you see the wide pixels clearly.
   
By the way, the C64 has no "vram" for sprites. It just gets the sprite data from the standard memory. So you do not have to copy sprite data if all your sprites fit in a 16k memory bank.
   
mrsid! Just great, man! "in a few minutes", eh?  Thanks for the pixel-hints at the elevator. I guess there are even more nasty blocks with some "forbitten" pixels. It's hard to see without a check program. Thanks for attesting these restrictions, I was actually getting anxious and about to remove some bats. The hires sprites look supercool in the emulator, ha! Too much brown in the background, maybe.


Update! Had a few minutes... yada yada yada... animations and stuff, here we go:
 

Here's an update of the hero, using Adam's excellent pose. Like this, the global sprite colors are orange and yellow. (dark grey might not be the best color for sprites if the background isn't black)
A) medium grey outlines do not blend with background (but blends to skin color a bit)
B) dark grey works nice with black background (but blends with brown and blue backgrounds a bit) Yes, I know... black outlines do solve these problems... I just don't like them, haven't decided, yet.
C) test with taller legs (better?)
D) ptoings safari-hat
E) no hat
F) alternate head - I like the big head in the idle pose, but I do not like it animated. Maybe because he has to look more to the right, but then the head looks worse.


running: not half bad, a bit stiff maybe. Looks a bit like he has swallowed a broom. Couldn't get it better, though. Also tested accelleration an friction here.
   

jumping: jumps immediately, but pauses a bit after landing...


crouching: 2 versions, which is better? What is crouching good for, anyway? In some games you can avoid bullets. Ridiculous... It doesn't have any planned purpose for now. But I have the animation frame anyway.


attacking: the 3 attacks... whipping and throwing are using the same animation. Shooting looks a bit stiff again. All animations do not change the legs, couldn't find a good way to do it. Any of the attack animations utilize 1 additional sprite. (which has to be reserved for the player) The 2nd animation is for being hit by an enemy.
   

digging: An archaeologist has to dig somewhere, right? Since we have this reserved sprite, I could add some dust while digging.
   

elevators: I mad a mistake in the previous elevator animation, the rack rail in the background vanishes if the elevator is halfway on the block. I could fix that by reserving another 32 blocks, then it would be smooth again. But is this necessary? (Yes, Mummies like to ride the elevator) The 2nd animation is a test for an elevator in "slam-mode"! (so I can use the blocks as elevators, doors and traps)


"How would Indy pass these traps?"

Thanks for the support! I am not sure if I still would working on this without all your feedback. It's a bit strange to follow the C64 restrictions 100% for a potential PC game. The restrictions help me to focus, but they do not really help me much to create the graphics. Well, let's see...


The C64 can have up to 8 sprites... in one zone. We can build multiple horizontal zones, divided by raster splits.

- Split "A": in this split we reset all 8 sprite positions, so the 8 sprites can be reused (the score display and stuff are build out of sprites)
- Split "B": this split just changes one multicolor color. (pretty much obsolete)
- Split "C"/"D"/"E": resets sprite positions again. (Split "D" and "E" do only reset positions of sprite 4 and 5, see graphic below)
- Split "F": changes background colors and at least one sprite position (for the scorpion)
- Split "G": changes all sprite positions again for the map and the map name. (the map is build out of 3 stretched sprites)

Since we do not have a complaining C64 programmer here who has to program this, no one stops me here.
The sprites have a fixed size of 24x21 and cannot be smaller, yes. Do I miss something? The only problem I could see here is, if a sprite moves close to the top or bottom area. Then it will overlap the status display. I am not sure, but I think a sprite cannot overlap itself vertically over a raster split.


Hm... yes, the golem could be build out of streched sprites, not using any raster splits at all. Interesting, but the streched sprites would have superwide 4x1 pixels. Uhhh...


Yes, I don't like the contrast in the boss mockup very much, too. Has Yeti be seen in Egypt, yet? One thing to consider: 2 of the 3 sprite colors are shared between all sprites. But the 2 colors are not set in stone, yet.

@ptoing: That's... that's really thrilling! And if I switch the emulator to NTSC, the effect vanishes.   (a pity!)
"Mayhem in Monsterland" does indeed use some of these color combinations with near lumina-pairs. But it's hard to use mixed colors... Moving on without mixing. (at least for now)


Update-time! Let's include some elevators of the egyptian machinery...   I used moving blocks instead of platforms. Like this, the blocks could be used as elevators and as doors.

To move the blocks on the C64, I need a lot of the 256 characters of the C64 charset. But like this, I can build rooms that have lots and lots of elevators and doors. That's an important gameplay element. Either they move in a certain rhythm, or the blocks are controlled by switches. In the end, all the graphics may not fit into one single charset.


BOSSFIGHT!

I need a split in the bottom half to switch to reverse-mode. (I can only use 4 colors for the rocks in reverse-mode) In the top half, I used black as background color. (Otherwise I cannot use blue background blocks)
The two layers of background do not show that much depth. I am a bit disappointed.  

Some calculations for the ROCK GOLEM:
- The C64 has 8 sprites. The hero needs 3 of them. (2 sprites, because of the overlay and a 3rd sprite for the whip, the dynamite or the gun bullet)
- So we have 5 sprites left for the boss: Sprite 4 and 5 for the body will be duplicated with 2 raster interrupts to build two 24x63 sized supersprites. (Like this, they cannot overlap) Finally, we have sprites 6/7/8 for the hands, which can be moved freely. (handy for the attack animations)

And yes, every Lazycow game needs a guardian:
- "I am the guardian!"
- "What are you doing here?"
- "Make an educated guess!"