Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Nice work!

I like how you used SDL and OpenGL, how the game is tiny (just 200kb without the libs!), and how editing maps is easy.

Minor things:

-the game window is a bit too tall for my small laptop screen, although it's just playable.

-the sounds are a bit harsh. Some low pass filtering or reverb might help. How did you make those? (bfxr/sfxr?)

My main criticism:

The physics is buggy, especially for high speed shots. There's tunneling (the ball moves through walls) and collisions being resolved in the wrong direction (wrong velocity reflection).

How did you implement it?

I think the best way to do it is to implement continuous collision detection and resolve between a circle and a rectangle, where the rectangle consists of four line segments and four circles with radius zero (the corner points). Continuous circle/line segment collision detection and resolve is easy enough, especially if all line segments are horizontal and vertical, like in your case. Perfect continuous circle/circle collision is a bit harder: that actually requires writing down a quadratic equation (for the distance between the circle centers, parameterized by time) and solving it with the abc formula. But that is what's necessary for perfectly resolving high speed collisions for a ball that bounces on a square corner...

(+1)

Thanks for your constructive criticism!

The window size is actually 4 times the framebuffer size; 3/4 of the current size should work fine.

Yes, the sound effects are actually generated on sfxr, I didn't actually played around much, after I had found some sounds that were good enough. I can change that, I get your point :)

And with the collision detection: I actually use a discrete approach. So yeah, tunneling is an issue which I could fix by just restricting the maximum velocity the ball can move. My approach is that I first check if a collision occurs and if it does, I handle both axis separately to resolve the collision. I might have a clue why collisions are resolved in the wrong direction. I will have a look at that. After all, I will have a look on continuous collision detection, that's something I want to learn about anyway.

I'm a software engineer with a strong focus on computer graphics, but actually never got my hands dirty on game programming, which is a hole different beast. I used an data oriented approach instead of a "classical" object oriented approach. This way I didn't end up with overengineering things, like I tend to do with my never ending side project of a 3D game engine (which is actually more a 3D rendering framework, but who knows the difference nowadays, right? :)

I didn't really care about the size. 200kb is actually pretty much for such a small game. BMP/WAV for ease of use isn't the go to decision when you aim for compression haha.