Progress Thread - Brick Breaker (formerly Brix Battle)

Brix Battle brix batle birx bltaeieoijadpoisfvsd

Game updated!
It's the same game with more levels, more balls per continue and unbugged paddle!



Can you beat all 10 levels?

Good luck on your entry!

I don't know if anybody else will think the same, but I can't help but being reminded of this:

Hans Brix? Ah, no!

Thanks!

edit: removed to clean thread of visual pollution

If it helps, you can look at the structure of my project, for which the development has all happened under Linux so far:

https://github.com/mikejmoffitt/6502jam

I'm progressing at a snail's pace but that's due to university + laziness.

I finally crossed the hurdle of writing an Object manager with Animation support... looking back I don't know what I was thinking with writing overly complicated routines which were flawed by design. The end result is so simple that I feel ashamed looking at older code... I guess that's how practical experience works



I just need to implement Axis Aligned Bounding Box collision and I'm set to actually work on the game. Wish me luck.

Well this is looking like a game already!



My title screen is basically done. There's a good amount of code left to be written but I think I did the harder parts already.

That title screen and its animation looks both cool and cute at the same time. For some reason it reminds me of Battle City for the Famicom.

I'm glad you liked, thanks! Battle City if I recall correctly draws the title with brick tiles too, right? I can see the similarities.

****

I implemented a reliable state machine, now I can schedule PPU writes and time stuff. This will mainly be used for the non interactive parts of the game, like drawing the title screen, high score board, maybe some "cutscenes" too if I get around to it before february.



Now I just need to do opcodes to transition between game states... and actually program the game itself. I also need to stop being lazy and sync nametable writes with its attributes.

If you want to add a cool demo element to it, you could wait a short amount of time (~15 seconds?), then allow a ball sprite to start to knock away bricks from the title.

I was going to fill the screen with tiles in a spiral order after a couple of seconds but your idea is just as good! I just need to know how many seconds it can possibly take because I want to show a high score table afterwards. If it's not much I'll probably do it, if not I'll combine it with the spiral fill after a certain amount of time.

Sprite/BG collision detection plus a ton of improvements and additions under the hood done!

http://i.imgur.com/JeS8qi2.gif

I'm not sure if I can finish this on time for the competition... but it has been fun and I went very far with this one. Probably going to finish it with or without competition.




Edit: doing proper reflection was easier than I thought and making the metasprite touch the solid tile and invert its velocity worked pretty well.

I thought that the proper way was to actually get how many pixels penetrated on a solid tile and subtract that in the total displacement in the frame (eg. speed = 3px, moving in X axis makes sprite overlap 1px with solid tile, total displacement = 3px - 1px - 1px (eject edge from tile, then move the same amount of pixels in the reverse direction). If you do this any differently or if you know that my method is flawed, please let me know.

http://i.imgur.com/UgpScbd.gif

Game now has REAL vector movement with subpixel precision, supporting lengths from 1 to 8 and 30, 45 and 60 degree angles and its analogues on the other quadrants of the trig circle. Not to mention that collision with the player's paddle (umbrella) is now heightmapped and sectioned to give better control to the player.



I suppose I can adapt the logic easily to add more angles or actually allow a 90 degree angle (aka UP) but that's not really needed for now. Never saw any paddle-ball game that allowed the player to bounce the ball in a straight line anyway.

Tiles, tiles, TILES !
I also implemented tile durability and I have more types of tiles currently drawn and loaded in the game's logic (but still unused).



At the moment I'm seriously considering to scale down my game and go through the path of least resistance due to the compo's deadline. I might just submit a breakout clone since everything that's needed for that is already in place. If the deadline is extended I can continue working on the original concept (1 vs. 1 battles, different enemies, having a shop in between battles where you can buy tiles with points and lay them on your side of the field, puzzle "coffee breaks" similar to Side Pocket's trick shots) but with 3 days remaining this is unattainable.

------------------------

I loved participating in this competition since before this the only thing I did was program trivial mock games where the most complex thing inside was uploading a screen to the nametable, lacking the drive to push forward when complexity started to increase. I'm proud of what I've accomplished, since this helped me to master many important concepts involved in the creation of a NES game, like PPU update scheduling, collision detection, math, input, indirect jump tables... I also appreciate more how difficult and laborious it is to make a NES (or any other platform) game and polish it. Prior to this compo I'd look at some homebrews released and go "wow what a bad game, why hasn't the dev implemented A B C D E F and made G H I J do X Y Z?", well, now I know why.
So even if I don't make it I think this was far from being a waste of time, and at least in my case I feel like the objective of the competition was a success.

This is looking better and better! I like what i see a lot. Congratulations!

The graphics are distinct, coherent and fun. If i get to nitpick, maybe the "crushed/passable" characters could perhaps be brought a little more in line with the rest, but that's my subjective view.


I suppose it's because that gives the player exploitable control over the ball, + 90 degrees can get balls stuck in persistent loops in some circumstances.

Super fun happy crunch tiem!

The decision of not pushing back the deadline was reasonable, and the right thing to do IMO, specially considering that there's a second category for late submissions. I'm just disappointed that I'm not going to be able to use this video for effect correctly anymore (:P):

http://www.youtube.com/watch?v=qJEmqZcfWJs
"bwahahahah I'm not a game killa hahahahah"

Come to think about it, I'm not sure if I can finish the game as I first drafted it to be even if the deadline was extended so no big deal really. I'll just focus in my ブリックブレーカー game for now and do the "full game" for Category 2 if I feel like I can finish it in time for cart inclusion. Here's some footage of the game's current state right now:

https://youtu.be/KygvdNaBAV8


You probably noticed that it doesn't have any sound. My audio man won't be able to do any arrangements for me (and it's my fault for not asking in advance for them) so it will probably be silent unless I decide to add one of the public domain .ftms I have in my HDD into it.
Also, notice that there's a glass object in there (with wrong palette though), I will try to add levels just like the bonus ones I was planning for how the game was originally designed, puzzle maps where you have to get the ball to a target tile without breaking any glass objects. It's just a "if (breaktile(x,y) == TILE_GLASS_SHATTERED) then game_fail()" so I think it might be doable.



Thanks, that means a lot
I thought that the "damaged/crushed" tiles were ok and not in a different style. That blue shell looking thing was supposed to be jello (???) and not really related to the blue cross tile so please ignore that, esp. considering that I changed it to a more acceptable-looking one (which still might not look like what it's supposed to be):



It probably won't make into the submitted game though.
If you're talking about how the graphics are top-down AND 3/4 perspective, I know that it's kind of jarring but I couldn't get good results when I tried to do the brick wall and iron plate/brick thing in a way that looked isometric. I'll try to improve that later.

I really like that jello! Both actually The aiming is a great addition. Things being at different angles feels commonly accepted for this sort of style. It might even actually add something to the soup, now when i think about it. A little whacky perspectives can go a long way to catch interest. European medieval, baroque and traditional japanese art styles (which i know terribly little about) does this in varying forms all the time, not to mention cubism. I wouldn't worry about it too much.


I'm sorry, i could have been a lot more specific. I think most of them are! The one that stands out to me is the one for the bricks, which feels like a representation of crushed brick, but perhaps not a direct derivate of the bricks that were there in prior to crushing.

Here's a quick mockup (though in a somewhat different style)


To the upper right is simply a metatile of crushed bricks. I made them from hacking away pixels from the original structure and moving them into a disarray. I also attempted to move them so that they'd break the tile grid somewhat, to signal the dissaray of a pile. To the upper left is some metatile variations made from the same four tiles. To the lower left they are put next to each other. Randomizing metatile content could perhaps work well.

I used the same technique when doing the brick walls and power ups blowing up animations for wrecking balls (there were some compromises and decisions, all frames didn't make it into the submission and others got changed. I just lazily took a snapshot that happened to be sitting on my desktop):

Deteriorating things that explode/destruct frame by frame feels easier to me, even if, say, only a few or even one selected frame would be used.

In the mockup above in the post, i made an interim frame between 'cracked' and 'destroyed' which would be redundant to the game logic, but helping in the process getting there.

https://www.youtube.com/watch?v=04854XqcfCY


Game released with an hour to spare! Bet you thought I wouldn't make it, huh?
I'm too tired right now to properly comment so I'll give my post mortem tomorrow (today in my timezone). For now I ask, if you manage to find a bug please report it to me here, if you have an emulator recording file, even better.

I've finally completed a game. This is awesome but I'm too tired to celebrate.

edit: by the way the ROM is in the first post. Thanks!

I really like the title screen. I don't know why but it gives me an early Atari ST feel.

You're too kind about my pixel art.
I think that's an excellent method of doing explosions/destruction. Some variation would also help too, yeah. Your example is very good and while it's unrelated it also has some nice edge embossing to make them distinct when adjacent with one another, something that I wanted to do on my metatile but didn't have time to. I'll see if I can update the art following your tips for the multicart version, thanks a lot.



Isn't bouncy stuff a recurrent theme in PC scene demos? Maybe you're familiar with one of those.

I've just released the source code for my game! It's not pretty but it's there, under the MIT license.

https://gitlab.com/aleff/BrixBattle

Edit: aha! I think I got why the paddle-ball collision felt so weird! There's two reasons, first of all my threshold to decide whether to use the left, center or right corner of the ball was too small, making it difficult to "aim".

Secondly, due to the way the paddle graphics are presented, one would expect the ball to merely invert its Y direction when the ball hits the center of the umbrella, since it's a flat surface (and all other flat surfaces i.e. bricks behave that way), but sometimes it reflects on X too due to how the paddle works in this game (sectioned into parts, each giving the ball a fixed movement vector, disregarding the ball's current one).

The second one is not much of a problem and it's easy to adapt to it, but the first issue made the second one confusing. I'm in the process of improving the game and that was taken care of and it makes a lot of difference. Check git for the update.

How much more do you plan to add to the game over the next few weeks? I ask because I notice that you left 9E40-9FFF,AD60-DFFF,EE40-FFF9 in the PRG ROM unused. That's over 21 KiB. If you aren't going to add more than 5 KiB of stuff, building it as an NROM-128 would help other things fit on the multicart.

I'm adding a couple of levels and doing some tweaks so > 5 KiB is unlikely. I'll rebuild it as NROM-128 for multicart inclusion. By the way, since my game's title lost all meaning and without context it is also gramatically wrong ("Bricks" Battle ???), I've changed the title for another one (Brick Breaker). Is that a problem?



I like the simple look of the new title screen so don't make me revert to the old one

edit: Tepples, I'm uploading the updated version to the 1st post. I'm not sure if I'll add anything else at this point. edit2: hold on, a minor bug just appeared from thin air when I made the jump to NROM-128.

The RESERVED_MULTICART part is actually unused, right?

GitLab is being dumb, somehow no one can clone my PUBLIC repository, so here's an alternative place to download the game's source:

https://github.com/AleffCorrea/BrickBreaker



Yep. Just added some junk text for fun. Feel free to add the A53 redirection code in it. It's a Donkey Kong (Arcade) reference.

Testing on real hardware there appears to be an issue on the very first boot screen being full of garbage tiles which get scrolled off screen when the title screen shows up. My guess is that the nametable isn't being initialized and the rom assumes it's clear which it isn't. It would be nice to remedy this for the action53 cartridge for a bit more polish. Let me know if you're able to work on this, or if you need more details about the problem.

I'll be honest and say that I was just lazy with the game . I'll see if I can add code to properly do full screen updates and send you the updated ROM tomorrow, thanks.

Here’s a photo of the initial display after selecting the game in the menu.

And a video of the whole thing, if you look closely you can see it takes a couple frames for the left half of the title screen to get its proper color as well, but maybe that’s intentional.?

brick breaker title video

Thanks, but as I said this was just laziness. I just didn't want to do it for some reason at the time, which is hilarious because I fixed it and polished the game in less than an hour, literally.

The final NROM 16k build of the game is available here: https://github.com/AleffCorrea/BrickBre ... r/brix.nes

Now with less ugly visible screen updates, Level 2 completely purged (the #1 reason people didn't care for my game was this unreasonably boring and hard level, I'm sure of it) and levels slightly adjusted and reordered to make for a better experience overall.

INL: can you do a quick test on hardware to see if I'm mistiming PPU on/offs? IIRC the screen jumps if you turn the PPU on outside of vblank, I'm almost sure my game does this correctly but it never hurts to ask someone with real hardware to test it.

Sorry for the delay, got a chance to test the new build out just now and all looks great. Thanks for taking the time to do this!