Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Thanks For the Fun Jam and Great Showcase!

A topic by miratha created Nov 06, 2023 Views: 68 Replies: 1
Viewing posts 1 to 2
Submitted(+1)

I just watched the showcase on YouTube, it was great, thanks for doing it and Octojam. Now I'm watching the other showcase videos in reverse order. I'll address a few things from the video about Dodge Catch Shoot.

The ability to move up is currently pointless. But I'm glad you found it :)

The player is drawn in an XOR fashion, but the falling objects are each erased and redrawn individually. I use the redraw of the  objects to determine collision with the player. I thought about switching those around too late, so I'm saving it for the next version.

The laser is the only thing using the delay timer (during gameplay), it's used to make sure the laser remains on the screen long enough to be seen. The falling rocks and player movement each have their own timer values. All three timers are balanced for 500 cycles/frame. I haven't tried adjusting the timers for a lower cycle speed. It's too complicated and a good reason for a next version.

The "E" in the upper-left is the error screen, there is a bug I haven't tried to fix yet. The player is allowed to move faster than the falling rocks, so the ship can move into a falling object and not be detected immediately. If a fire command is processed before the rocks are moved down (and collision detected) the program is unable to locate the object the laser hit and shows the error screen.

I plan to start over and use XO-Chip instructions for version 2. I'm excited to have color and sound.

Submitted(+1)

It was a fun watch, and enjoyable to work on a gamejam for such a limited platform. It's always impressive to see what others are able to squeeze out of this platform.

As far as Fencing goes: the reason I didn't finish collision wasn't due to the animation system. Early builds (before realizing my other issues) had the sword only one DXYN wide, so erasing and redrawing just the swords in separate calls wouldn't have been an issue and I could just check the collision flag.

The problem is that I wanted to handle sword->sword collisions differently than sword->player. And while I could probably do a dance of erasing both swords, stamping each one in for collisions, and then stamping in both, it seemed like it'd be more efficient to do things by hand. I was sensitive to Display Wait since VIP-playable was a stretch goal of mine.

So if I wanted to do everything by hand, I needed to know what the valid bounds were. And of course my sprites usually don't reach each other, so it didn't seem worth it to put in that effort until the sprites are fixed.

I'm probably going to have to get over my pride of having it all be my own work and just ask someone I know with artistic skill to help out with the drawing part. Then I can tackle the rest of it.