Hi!
This is a very simple clone of Arkanoid, that I created to learn to code games in Pico8.
Although I have 15 years of experience in coding, this is my first time programming a video game, which is an area I would like to work professionally.
The game has the basic mechanics for collisions, levels and score. Some SFX but no music yet. I started to work on sprites when I decided to publish this version to gather feedback and ideas from the community.
If you're going for arkanoid like mechanics, the ball/ship collision is mostly there, but you're missing the rounded ship edges effect, both visually and mechanically. It's also possible to hit the ball multiple times in a row, which makes the ship feel ghostly as you see the ball and the ship sharing pixels for multiple frames in a row.
Collision with game edges seem mechanically OK, but you shouldn't show the ball peeking out of bounds.
Ball/brick collision feels sticky and unnatural :
you can hit the top of a brick from top right, and have the ball bounce back to the right, as if it hit a corner.
Tile fading looks nice when hitting a brick from middle bottom, but looks weird otherwise. Maybe have an animation for hit from middle, one for hit from side, and a last one for hit from corner, and display the proper one with horizontal and verticals flips when needed.
Collision seem overall frame based. This is especially bad when horizontal speeds go over two pixels per frame.
Balls can start to blip through thick walls switching up and down movement every frame, leaving a trail a of unconnected rectangular 1 brick holes inside the mass.
In the original, it's very frequent that a ball hits multiple walls, enemies, and bricks between two frames, especially since the balls keep getting speed (gotta grab the player's coins). It's not necessary to go to the extremes of the original since the main goal is to give a pleasant experience rather than emptying the player's pockets, but it's still a necessity at current game speeds for elements to feel solid.
It's also possible to make the player stick slightly out of the game vertical borders, probably due to an off by one frame collision check and a frame based collision check, instead of speed/time trajectory/collision computation, followed by and end result displayed on the frame.
Hope I'm not too discouraging, as rewriting the collision system is no small task, but well worth it as it's what defines the game-play feel of a breakout game.
I agree, there's still to work on brick collisions; the issue gets serious especially on unbreakable blocks: at level 4 the ball got stuck in an infinite bouncing loop between 2 yellow blocks in the middle and there's no way out:
RealShadowCaster: thanks for all your feedback. Not discouraging at all, but very constructive and informative. Do you have any examples of speed/time and trayectory?
I like your suggestion on having different animations for the brick break depending on the side of collision.
Heracleum: I’m aware of that particular bug. It is an annoyance. As a workaround, the second button puts the ball back the paddle, like at the start of the level.
.png)
In arkanoïd, balls are single points. The sprite is of course bigger than that, but the ball often overlaps over bricks for a frame.
For your game, since the ball is quite big compared to the screen, a square or octagonal hit box might be more appropriate.
Brick hit boxes depend on brick neigbourhood. Every angle is 45 or 90 degrees for the brick hit boxes.
The isolated brick hitbox has 8 sides, while a brick in a line only has two sides.
The green line shows the invisible trajectory of a fast ball.
During a frame, the ball has a certain horizontal and vertical distance to move, regardless of how many bounces tat requires.
Starting from top right, it goes through the corner of a like and gets it's 1st hit on top of a tile.
Some amount of vertical and horizontal distance has been spent, and the y direction is flipped. The hit tile is flagged as hit.
The ball now goes up left and hits a corner.
Some distance has been consumed, the horizontal and vertical distances are swapped (X flip for vetical hit, Y flip for horizontal hit, and X/Y swap for corner hits), the tile is marked as flipped.
The ball can now finish its move without hitting anything, we have the new X/Y coordinates that will be used for the display of the frame.
On screen, we had a 1st frame the ball on the to right tip of the green line, and next frame it is at the other tip of the line, with hit sound and two highlighted tiles. Somehow, this looks convincing and solid.
[Please log in to post a comment]
