Although the competition hasn't started yet, I wanted to present a WIP of Hat Trick port. I've started the project about a week or two ago. Hat Trick is a one-on-one (plus goalkeepers) hockey game. The game was released for c64, dos and atari7800 and arcades. The atari version even had its source code released to the public some time ago. However I don't like that version. Haven't played the dos version. We had c64 so I've played it very often with my brother. Great two player fun. We still play it from time to time on an emulator.
Unfortunately there was no z80 cpu version...

Current state:
- puck movement
- goalies movement and animation
- puck with goalie collision (although not yet calibrated... but the checking of hitboxes is implemented)
- checking for goal
...so kinda a pong clone at the moment

Graphics are currently based on the dos version - 320x200 with 4 colors.
As there won't be used any platform specific stuff (excluding the char mode for panel and title screen) this should be easy to port to the cpc...

Looks that 50fps with single buffer and no-flicker should be feasible...
Puck is a compiled sprite, goalies are compressed sprites and the players should be at least compressed sprites. The problem is that for the players one needs 8 (directions) * 4 (preshifting) = 32 sprites. However each player has to have different color so we get 64 sprites needed... I don't know how much memory is needed for that, but I want to go with 32 sprites and use a mask table for changing colors... That way, if later I would want to add additional players, I could make them also of different color (using checkerboard?).
For that I have to make some improvements to my sprite conversion tool...

On the screenshot:
white border = erasing goalies
blue border = drawing goalies
red border = erasing puck
green border = drawing puck

I'm not planning to do one player mode (I have no clue about implementing ai and it's not that fun... I think).
I have a few ideas for additional gameplay/options/features but for now I'm doing a port... I fear implementing the inertia, player momevemt and proper collision system... Maybe I will have to do some reverse engineering...Hope not...

As always - don't mind the colors...

(I hope that posting this wasn't another bad idea of mine)

It is look great!

As I see there is the leg animation also , please check it , may be I see wrong, but there are five frame for each position, and with different leg state.

That's correct, but I must multiply this (what's in the image) by four because of shifting (I need one pixel movement). And so directions * animation_frames * shifting = 8 * 5 * 4 = 160...

Understood, and what do you think, if you keep the movement by pixel, but player start position (sprite 3) can be at every 4th pixel, in this case you need double sprites 1,2 ,4,5 only
so if the player turn the joystick in on direction very short time the sprite would move 4 pixels , but by pixels
Or double sprites 1,2,4,5 , and with this solution with a short joystick turn the sprite would move 2 pixels.

Looks that it should be feasable to make the game for up to six players in 50fps and with just a single buffer. As you can see the drawing and erasing of all the sprites takes about half of the frame (well a little more but there still around 120 scanlines left and I think it should suffice...or so I hope)
The compressed sprites need currently ~50kb so a lot (the color chages between players are made via color swap LUTs). For an ep64 version the number of players would have to be the normal 2 on 2 max (if no turbo I guess). However that would require to do a test if standard sprites with masking via LUT are quick enough...

I forgot to uncomment the call to the players erase routine and thought that I have the entire icefield (around 160 scanlines) without any sprite code execution...but after I spotted my mistake and modified the loop I got only around 120 free scanlines. 40 scanlines of the icefield do the drawing but I guess I could move there the code for the goalkeepers... I wouldn't want to have to work with sorted sprite tables...

EDIT:
added the deleted screenshot after doing some optimization. Now only part of the goalkeepers' drawing code is executed on the icefield.

Decided to try having the legs as separate sprites. Earlier I thought that it would slow down the drawing code but it turned out to be only little (well depends on how you look at it...but it isn't that bad) than having an entire sprite for each frame. And what's more important - it also shrinked the needed amount of memory (for the draw&erase code) to less than 24kb. I regret not trying it out earlier...