Puzzle Games Development

Use this forum to share and discuss Uzebox games and demos.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Puzzle Games Development

Post by D3thAdd3r »

Working on some sound effects now, and decided against PCM. PCM would require a custom HSYNC that drops noise, to retain PCM and UART buffering. I am not overly intimidated to implement that, but now I think size is an issue that makes PCM a poor choice, due to Puyo Puyo plans (thinking of calling that game "Jelly Pop").

I am adding "garbage cancellation" logic that can work for both games, but I probably now need an options menu so this can be disabled, to allow for classic mode gameplay...I personally find garbage cancellation a good mechanic in all cases, in any puzzle game, for longer matches less based on what happens to get generated in the RNG. Puyo is the main consideration and Astro Blocks will follow any design choices for that...so now I see I have some changes to do. I mean to start working with the "Jelly Pop" graphics, so that I can find the best way to organize things, to keep as much code the same as possible between the two. It's doable, but Puyo requires *much* more tiles which will push against the vram pointer size..needs planning now instead of later. Forced to do ram tile stuff for menus.

I have another song ready, and like the one in the previous demo, it is from Puyo Puyo. The sound effects for both games will also be Puyo ones, modeled after an emulator sound test->GYM dump->GYM2MIDI->MIDI->Uzebox process as I have documented on the wiki before. I might resort to ripping some graphics, as I am unhappy with the way the well looks currently. Blocks for both games will still be original, but mainly I am trying to make up for limited time lately, to get this out within the next few months. Some progress.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Puzzle Games Development

Post by D3thAdd3r »

More rants, but in case anyone is interested, this is how one slightly crazy person thinks when they are developing!

Alright the Puyo Puyo clone is officially "Jelly Stack" because it can more easily share resources with "Astro Stack" for the title screen which is already optimized to very few tiles. This is important as sizes of everything needs to be close...I decided for PCM absolutely, so this at some point when I want to do network stuff, forces me to make a custom hsync that gives up noise channel to allow 3 wave + PCM + UART which I believe is possible. This also then leaves me searching for more space, but it is the only way. I had forgotten why I went PCM with Columns, and now I remember. The score effects get played so often, at different pitches, that they must sound as good as is possible. Also even the bigger point is the music constantly gets interrupted by effects. The music is rapid and I already made many compromises to make some version that would sound decent, and I can't afford to give up the backing tracks/depth so often; it is just too noticeable for this. I have lots of space free at the moment, much of this will be gone after the PCM, probably 10K left afterwards. It might sound a curious decision, but this will absolutely be an SD game so that I can stick the content I want in without so many huge compromises I had to make for Columns.

Somewhat the whole style of the Astro Stack side is being "corrupted" towards Puyo Puyo style even more. Quite frankly Puyo Puyo interests me much more as I think the mechanics are better, it is more fun, more replay value, and overall just a superior game in every way. I am not too good, but I find myself playing the Genesis version a lot lately. It has proven hard to reconcile the graphics resources for Puyo(hereby JS) with the Star Stackers(hereby AS) stuff, and also the logic is more complex for JS. To make it less complex I am adding things never in the original for AS so that things like that star which show garbage transferring over to the opponent as a combo goes will also be there just like JS. The amount of garbage to come will also be shown at the top in both(Puyo style). Also there is a limit to the amount of garbage that can fall in 1 turn, regardless the total amount to come(Puyo style). This allows less #define stuff which gets out of hand quickly. For reference the gameplay is going to be nearly a copy of Puyo Puyo Tsu which I feel is better than the original without some weird gimmicks found in later versions.

Now on the SD stuff, I will do my usual useless stuff like a fancy intro and all that. The two games(if I even care to finish AS) will share the same resource file and all sound effects, backgrounds, etc. will be exactly the same;I simply do not have enough time to develop different art resources for 2 games. The big leverage I gain off this, is space saved on the title screen, and more importantly space saved for the backgrounds. In Columns I could only do 2 simple backgrounds because I was out of vram pointer size, out of space, and out of ram tiles(all those coloring effects, etc.). This game will only need 9 ram tiles for sprites, because the 2x2 sprite for the star that shows garbage transfer will flicker on and off for each player alternating frames for a translucent look and to save ram tiles. This buys me ~30 ram tiles that I can use for as many backgrounds as I care to make. I plan to make several backgrounds so that there is more replay value, visually.

The dreaded problem of the jelly popping I have been scratching my head on. I don't want them to simply disappear, and in the original they explode into neat little particles. I really would like to make something that is polished more than I have made before. Playing Puyo Puyo Tsu where they explode different ways for different enemies, I saw one enemy where the Puyos split into 4 8x8 sprites and fell downwards; I did this with just tiles in Columns for the crash attack and it looked good(they move quite fast so it isn't so noticeable they are not sprites). This is the plan for that problem.

A big problem has been constantly thinking what is the most important things to keep, because 256-RAM_TILES_COUNT is ultimately not very much. Using ram tiles for the BG helps this a huge amount as I don't have to keep multiple things in range of the core blocks(and deal with all the offsets when you straddle the critical stuff with the bg stuff..I think people know what I mean about that trick). I already drew all the Puyo from scratch to avoid the huge amount of tiles the Genesis version uses. Mostly there are so many variations for any type of connection or multiple connection, where one eye would look up, one would look down, other times to the side...just impossible to hundreds of tiles here. This is close to the final graphics for the blocks in the game, where you can see I added a flashing white border which represents your controlled puyo as it drops(like original), and a "stretch up" and "stretch sideways" animation they puyo will do as they fall and land(also like original). This is the critical factor when I looked to understand why the original feels so much more alive than my own. I also added ghost markers that will show where things will land, as the newer version seems to have:
jellypopcore_uzeboxpalette.png
jellypopcore_uzeboxpalette.png (4.57 KiB) Viewed 5620 times
A big change, I am not doing on chip AI. Instead there will be simply practice mode where you endlessly build chains, and 2 player mode. I am essentially setting a requirement to have an Uzenet module if you want to play against an AI, since it is way easier to develop good AI when you have lots of ram and cycles. I barely squeezed AI in for Columns, and I had to base the entire game around it at 30hz. I want 60hz and a taller screen.

Music, I want maybe 5 songs for which I already have the data to use. It is impossible to squeeze 5 songs in flash for this game(AE did 6, only because of high SD leverage), and I don't want to compromise like I did with Columns. SD music streaming is the answer, but I don't have a working implementation yet. This is a technique which I believe will help more than just this game, so this is high priority right now. Finally all the micro decisions I have made, have left me with this which should be an accurate representation color and otherwise of what a multiplayer match will look like:
multiplayer_concept_big.png
multiplayer_concept_big.png (122.71 KiB) Viewed 5627 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Puzzle Games Development

Post by D3thAdd3r »

Think I am done with backgrounds, and there is only <= 16 unique tiles each so I can use ram tiles for something else also. Took quite a lot of time to get things to look decent with Uzebox palette, but I think there is good variety and not too hideous in general.
Attachments
jellystack_bgs_big_NTSC_blur.png
jellystack_bgs_big_NTSC_blur.png (726.69 KiB) Viewed 5599 times
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Puzzle Games Development

Post by Artcfox »

Wow, looks very cool. I very much enjoy reading your thought process on this stuff. Once things aren't so busy with me, I definitely want to work on more games.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Puzzle Games Development

Post by D3thAdd3r »

Alright after some delay I am back working on this. Disappointing SD streaming music performance during testing caused me to refactor this game in a large way. It is too difficult to dodge the totally unknowable seek delay on SD cards, and I don't care to do all that work and have an outcome where the games plays like crap(stalling) for people depending on their card. My solution is to pre-load all resources for the entire game into SPI ram at start up. This takes about 2 seconds in CUzeBox and I am re-directing the whole game around this for music and graphics(ram tiles).

That is a big change, but it has big benefits. There is no hopes of backwards compatibility with non-expanded version for this path, but then it allows me to push things because I know the timing is the exact same on all such consoles. There are definitely some things I never did with SD->ram tiles, simply because it didn't work on my slow cards. Anyway I am trying to keep myself accountable here to release another demo soon with the Puyo Puyo clone mechanics in place. I think I had 2 project I left incomplete, and it seems like I always finish 1 out of 3 I start..so that seems promising for this!
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Puzzle Games Development

Post by Jubatian »

If you are doing bulk SD Card -> SPI RAM transfers, you may finish them faster if you temporarily "disable" the display for it. Just narrow it down for example to a loading bar in the middle using SetRenderingParameters(), the lines not used for display will be available for the main program, in one line with a large inline mixer you may be able to transfer about 45 bytes (use 512 byte blocks if you have RAM for it). This way you should be able to get ~ 10K / frame, so the full transfer (completely filling the SPI RAM) would take only about 200ms (and you wouldn't even need a loading bar then as nobody will notice).

Graphics is certainly very nice! :)
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Puzzle Games Development

Post by D3thAdd3r »

Thanks, I will try that. Maybe even just a cli/sei since it will be so brief, and I think the Uzebox loses sync for a bit on reset anyway.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Puzzle Games Development

Post by nicksen782 »

That's slick! Great idea for when lots of data needs to load and a visual pause is okay.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Puzzle Games Development

Post by uze6666 »

Added to the Wiki! :P
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Puzzle Games Development

Post by D3thAdd3r »

Thanks for putting that up Alec, AstroStack is my most neglected game for sure.

Seems not even that bad or too far away from complete, AI was getting there and gameplay seems to work right. Throw some working 2 player in there, and make the Uzenet a TODO. Crazier things have happened, I'd guess I could finish that one quickly and randomly some time. Not my favorite puzzle game mechanics, but it's something different. If I go back at this, I will do PCM for sure.
Post Reply