Excellent game! Keep up the good work! 👍

At first, I wanted to recreate the gameplay of Enduro for the Atari 2600, which is a very good game. I found it too difficult to fit into the jam size limits, so I did some changes, trying to keep as much of the feeling. Activision games made in those years were really amazing.

I'm afraid not. Once you get to a maximum size, other fishes appear that are even larger than yours and can be very fast, making it harder to avoid them. Being heavily constrained on code size by jam rules means you have to sacrifice a lot of non-essential things.

Thanks! I had to spend more bytes on gfx and effects than I had expected, so gameplay ended up a bit lacking. I also had to reduce bg colour cycling because it could cause dizziness.

Nice game! I like the sprite animation and the suffocating feeling that lava will fall on you at any moment if you don't dig fast enough.

Wow! Nice game!

Nice game! It looks good and plays well.

Thanks!

Of course, any resemblance to any well-known epic space opera multimedia franchise is purely coincidental and not intended 😉

Before runnning out of spare compressed bytes, I had also planned to add a star field in the background... and a death star, sorry, I mean a mother ship 😁

Nice presentation. And physics feel great. Well done!

Thanks! Unfortunately, highscore had to be removed in order to meet the compressed bytes limits. IIrc, I've got to level 6 once, but I had to be extremely focused. In fact, if you want to get a driving license for riding speeder bikes in Endor, this is the simulator you have to master 😅

Thanks! As your fish gets chonkier, game unlocks larger size fishes and it's more difficult to avoid collision.

Both official logo or a mosaic of jam entries after jam finishes would be fine. I would buy two t-shirts.

Nice game! The only important thing you have to collect is fuel. But you end up taking everything you can get.

Thanks! I needed a background with some pattern to make the black outlines of the blobs stand out. So I figured a soft vertical scrolling of 16x16px tiles could work. As the blobs required several hits, I thought their colour could change and give hit point feedback. The remaining problem to solve was that the ship colours and background didn't have enough contrast, so I added a thin black border around ship and bullets. I don't know how, but everything could fit into 1024 compressed bytes.

Thanks! Adding user-controllable firing doesn't add too much code, but when you're just above 1024 compressed bytes, everything counts, Anyway, I think I'm getting too lazy and going auto-fire in every game from the start, instead of adding it only as last resource to keep within compressed code limits.

You're right, when you play higher levels at high speed, it's better that other bikes stay off-screen so you can focus on planning ahead your movements. It's crazy I just had to tweak tree drawing a bit to keep the framerate at 60 fps without drops to 30 fps.

Thanks for creating and sharing those tools! They're perfect for adding some sprites without getting a big penalty in compressed bytes. I know I'm not using them at their full potential but I prefer to keep character set in a readable range. 

All the information you need to encode sprite data into text strings and decode those strings in your game is here:

Tools

• Tweetcart Sprite Graphics Tutorial by JadeLombax - cram sprites+anim using only code!

Thanks! I spent many hours playing this game when I was a kid. The ZX Spectrum 48k was the first computer my father brought home and this was one of the first games I played, so it's also a special game for me. I still have got nice memories from the golden age.

Nice game! The controls and movement of the ship feel very good. It looks like the typical Tron highway with rush hour traffic you find everywhere.

Great game! Although unlimited ammo with no overheating issues makes it easier to survive as long as you don't lose fire power, watching the resulting fireworks is very satisfying. The circfill screen clearing effect is great and the sfx sound is excellent.

I had to take apart a lot of features in order to meet the constraints 😭. And even so, I had to fight every single byte against the compressor 😅. I remember playing Charr (a Scorched Earth clone for the Amiga) countless hours in local multiplayer. Still, the game deserves a full featured version for PICO 8.

I had the palette arranged for bitplanes with 8 colors followed by brighter versions of them, but I forgot to use bitplanes 🤦‍♂️😅

After adding sprite decoding, I had a few compressed bytes in excess of the 1024 limit. I had lots of fun tweaking little changes to the code and watching the compressed byte counter go either up or down with same char count. 🤪

Thanks! I used your sprite encoder/decoder for the single 5 color 8x8 sprite that get scaled and color cycled depending on fish size. Very handy and compact code, so it doesn't compress well. I was thinking about going 16x16 2 color and add color banding in the decoder but the game was already working around this 5 color sprite.

I've just watched a gameplay of this game on YT. Nice!!!

Yes, I think Scramble is the original arcade game. But there were a lot of similar games and arcade ports for early 8 bit computers: Skramble! For VIC-20, Kamikaze and Cavern Fighter for ZX Spectrum, ...

Thanks! I'm glad you like it. I wanted to test new enemy movement patterns but I was not sure whether it would work fine or it would be a mess.

Thanks for playing. Most of the games I make tend to be very fast paced or increase speed with time or benefit from very smooth movement, so setting 60 fps could be the most important part of the code.

Incredible. Well done!

Just incredible. Well done!

Thanks! You're right, you never know how close you are to minimum dimensions. I could have set 1x1 instead of 8x8 but very thin boxes looked a bit weird.

The full screen flash was intentional, to let you know you successfully caught the red guy. But you're right, it also disables the spotlight mask and shows the red guy new position for one frame. Too fast for my eyes to notice, I suppose. If I had to code this game again, I would remove the flashing, as it's a bit unpleasant for the eyes.

Thanks! This one was hard to get under 1024 characters of code. Movement logic is a bit flawed and there was no room left for power pills.

Thanks for the kind words. The code is a bit unoptimized as I don't have much experience with using tline(). So I ended up with a code size over the maximum allowed. I had to reduce portal glitch code and take out sfx just to get to the size limits.

I decided the sequence had to be displayed on screen because in the movie the glyphs expressed coordinates. As a nice side effect, looking at the next glyph allows you to plan ahead, if you're fast enough.

Thanks for the kind words. The code is a bit unoptimized as I don't have much experience with using tline(). So I ended up with a code size over the maximum allowed. I had to reduce portal glitch code and take out sfx just to get to the size limits.

I decided the sequence had to be displayed on screen because in the movie the glyphs expressed coordinates. As a nice side effect, looking at the next glyph allows you to plan ahead, if you're fast enough.

Thanks! Before ghost logic wasn't finished I wasn't sure if random movement would make for a challenging game. But 4 ghosts wandering in a small maze at the same fast speed as you move without stopping or getting stuck definitely gives it a nice difficulty.

The key code for movement is:

d=i>1and 1+((e.d-3)\2+rnd(3)\1)%4*2or e.n

That code executes when a character reaches a 8x8 tile and decides in which direction index 1+2*(0...3) it moves afterwards. Player takes i=1 and follows the next movement you selected before reaching the cell (it's a bit buggy because in order to leave a straight movement you have to set new direction just before you arrive to the tile). Ghosts take a random direction as long as it's not blocked and is different from going back. So no pathfinding, only random movement plus some logic to avoid weird behaviour.

Thanks! Again, difficulty tuning not the best in town. I was betatesting with keyboard. With a good gamepad it's easier to reach every threat faster and place spray at the right point.

Thanks for playing and commenting. Maybe the code for out of screen bullet removal is a bit buggy:

if(q.x>128)c=1

if(c>0)del(p,q)

It seems the 128 value is too high.

Also difficulty tuning in most of my short games looks like "player is allowed to survive for ... seconds"

Thanks! I run out of chars because of the not really needed separate function body for sprite rotating and scaling. So I was not able to add sfx and use better gfx effects for the gate. I'm not happy with the colours either but I could't fit a full custom pal.

I harvested every resource and started in another screen but it was game over in a few seconds because bad house placement and unpredictable zombies. The house placement and very first seconds of gameplay are critical for surviving.