Search the Community
Showing results for tags 'Squish Em'.
-
SUCCESS! Christmas morning! Ahh...I know that glazed look of concentration... The day after Christmas - at it again: He even let his brother play a little: Hope you all had a wonderful Christmas! (PS The 5200 port of Squish 'Em is almost done... )
-
WELL, THAT was a whirlwind! Finished up Squish 'Em with just days to spare. I posted the list of differences vs. the A8 version in the Squish 'Em thread, but I thought I'd recap here and try to collect my thoughts about my next project(s). First, Squish 'Em - this turned out waaaay better than I thought. It was easier than I hoped (and a lot of fun ) to disassemble the A8 source, which allowed me to get the timings to match exactly and the sounds to match very very closely. I still had to make some compromises but they all turned out to be minor ones, so I'm happy and pleased with the result. I'm also very happy that I was able to squeeze it into 4K. Wow - two games released this year. Busy busy. Though, once again, I took the summer mostly off, so I squeezed most of my coding into intense bursts in the spring and the fall. And I just remembered - I also modified Go Fish! to allow a 6-digit score. So, enough looking back - what's next? A couple of minor projects: -convert Elevators Amiss to PAL (or, likely, PAL60). -possibly convert Go Fish! to use Econobanking or whatever that cheap 8K banking scheme is called. A couple of big projects are also in the works: -I've been thinking about picking up the Supercharger RPG I was working on a year or two ago and trying to bang that into shape -I've also been toying with a big project for a while now, bugging Nathan for sprites, and writing kernels (on paper). I'll keep this one under wraps for just a bit longer - but I will say that the possible availability of a 64K cart has revived my interest... -Something for the A8? It's kind of a dream of mine to write an A8 game, but the difficulty is picking a project, of course. Anyway, if you've read this far, thanks for indulging a little navel-gazing and have a good Christmas!
-
THINGS ARE MOVING ALONG, though my self-imposed deadlines are looming and looking more and more unrealistic the closer they get! Unsurprisingly. I'll keep plugging away, though, and we'll see what happens. The Latest! Big changes: -Scrolling now works, though the kernel isn't completely tightened up yet. -Randomly generating girders, monster colors and positions. -Moving monsters. -Player movement constrained. Now pressing up scrolls the screen, down does nothing. -Matching up things to the original: starting location of player is correct. Brick falls at correct speed (and speeds up to fall at same relative rate when you are climbing). Monsters "fade in" when they appear. Scroll stops at correct place. A few notes: -I have to scroll two lines at a time, rather than one. It looks a little chunky compared to the original, but I think I'll have to live with it. -Realized that the girder colors change during the game! They are hardcoded in the kernel now; have to see if I can change that. -I think the falling brick is ok. -_Fandal_ helpfully disassembled A800 Squish 'Em for me so I'm hoping to extract the sounds. I think the sound hardware is mostly the same, except with the BIG difference that the A800 has 8 bits of frequency resolution, compared to the 5 bits that the 2600 has. Are any of you experienced uncommented-asm readers able/willing to help me partially disassemble this? -Still have 48 free bytes of RAM! I don't want to count my chickens before they hatch and all that, but this just may be my first project where RAM wasn't an issue. Would be nice...
-
YET ANOTHER update. Changes: Biggest changes are -adding the climbing animation. The animations are mostly done now, though I need to tweak things a little - the climbing animation is a little goofy when you start with your left hand up. -major cleanup on the kernel. This is very close to being complete. Enemies no longer jump around when the screen is scrolling and there are many fewer graphic glitches at the top and bottom of the scroll area. EDIT: Just glanced at the screenshot I took for this post and noticed a graphic glitch in the player!
-
SQUISHING IN FULL EFFECT! New update. Still not technically playable, since you can't die, but pretty close now. Changes: -Player now moves at correct speed in all directions and is animated when he moves sideways. -Only can squish enemies by actually stomping on them. -Enemies are generated correctly (i.e., 1 blank row, 15 rows of 1st enemy, 16 rows of 2nd enemy, 1 row with bonus item, 15 rows of 3rd enemy, 1 row with suitcase, repeat). To do: -clean up kernel transitions, tighten up all SLEEPs, and finalize all page-crossing locations -decide whether or not to stripe brick (Or girders?). And then do it if so. I'm leaning towards not doing this. -finish add enemy/girder data generator. Enemies and items are pretty much done, the girder generation needs all the special cases taken care of. -finish enemy movement schemes -finish collision detection -finish animating player -death animation (scroll player off bottom of screen) -add sfx -add music -finish scoring -finish level transitions -all gamestate transitions -console controls -testing/polishing So, there's a lot. But I'm getting there!
-
YOU GOTTA LOVE WORDS WITH CONSECUTIVE 'u's in them, even if they are made up. Anyway, I gave it the ol' college try, but I couldn't quite get a playable version done last night. Changes: -Added legs-up animation when you press the button. -Enemies can be squished! Er, just by touching them. The timing on this needs work also. -Constrained player movement. This is now done, except for animating the little bastard and getting his left/right speed correct. -Added some of the scoring; you gain 10 points for climbing one level. I think that's it. I might try to make this sort-of playable and then post a new version tonight, otherwise I probably won't post any new versions until next Monday.
-
SQUISHING CONTINUES! Oh, I slay me. Anyway. Did some more work last couple of nights. Changes: -Rewrote part of kernel to use actual enemy graphics (without 13 trailing zeroes) -Animating enemy graphics. This, as I mentioned before, is amazingly easy. Even easier than I thought it would be: I just take the frame counter variable and write it to REFP0. That's it. -Added six-digit score -Got girder color-changes into the kernel, looks much nicer now. -Moving the brick. I'm not sure whether or not the brick is visible enough or not. I think it might be ok, since it is in motion. When the game gets closer to release I'll solicit opinions on whether or not to stripe it, I think. That will be a very easy change. -Fixed the issue that was goofing up the enemy graphics; it wasn't a timing issue - I had forgotten to set VDELP0! Also, I wrote myself a to-do list/schedule. It's in the source, but I'll reproduce it here: ;--------------------TO DO: ; ; -*DONE*re-write main kernel loop into two loops: top loop doesn't draw enemy ; bottom loop does (save gfx ROM) ; -*DONE*use actual enemy graphics (and animate) ; -add multiple entrance points to kernel with appropriate timings ; -*DONE*add girder color changes? ; -clean up kernel transitions, tighten up all SLEEPs, and finalize all page-crossing locations ; (and get scanline count at steady 262 [or?]) ; -stripe brick? (Or girders?) ; -add scrolling ; -add enemy/girder data generator ; -add enemy movement schemes ; -constrain player movement ; -add collision detection ; -animate player ; -add squishing (start thread in homebrew forum here? Or earlier?) ; -----------need to be at this point by Thanksgiving!------------------ ; -death animation (figure out how to scroll player off bottom of screen) ; -add sfx ; -add music ; -add scoring ; -all gamestate transitions ; -console controls (including pause? 7800 detection/support? music toggle?) ; First thoughts: yes yes no ; -testing/polishing ; -----------aim for December 1 at this point!-------------------------- ; -SaveKey/AVox? ; -PAL conversion? TJ to help?
-
RETURN OF SQUISH 'EM! I haven't forgotten or dropped this project! Here's the latest code and binary. Where I'm at: -Kernel is mostly there, just needs a few things here and there and some tightening up. I think I introduced a page-crossing error last night which is why the "enemy" graphics are messed up a little. -Converted all graphics to data. Discovered something interesting in the process: all enemy/item animation is done by flipping the reflection register. Very nice! It's also used for the player animation as well. To do: Everything else. Main goal right now is getting a sort-of playable binary working; at that point I'll start a thread up in the homebrew forum and continue all development discussion/news there. Immediate to-dos: --get scrolling working. --Rewrite kernel slightly so it can use enemy graphics. --Get score display working --get correct movement scheme in for player --add movement routines for enemies --randomly generate building to climb I'm worried about: -Getting the music/SFX to sound right. -The player seeing the brick. It might blend in with the backgrounds too much, since it shares a color. Big goal: have final binary by December 1 2007....okay, stop laughing. No, seriously, that's my goal. I'm...cautiously...optimistic about that deadline, but we'll see. I hope to have a shiny, labelled copy wrapped and under the Christmas tree for my oldest son to open on December 25th. We'll see if I can do it. EDIT: Here's a screenshot of the original A800 game, for comparison purposes:
-
A NEW YEAR! TIME TO MAKE plans! What...February already? Oh well, better late than never. Anyway, my plans for the year have come into focus only recently, so I thought I'd share. Major Projects: 1. Finish the Maids+Elevators game. 2. Port Squish 'Em to the 2600. Minor Projects: 1. Modify Go Fish! to allow higher scores (or allow the score to "roll") for a few folks that can actually max it out. 2. Mystery project that I'm working on with Nathan Strum. Details: Squish 'Em is going to be a Christmas present for my two boys, or maybe just for my oldest. So for the year as a whole this is the top priority. However, I'd really like to finish the M+E game so I'm going to work on that first - but I'm going to start working seriously on Squish 'Em in mid- or late-spring, so if M+E isn't done by then it will have to wait. However, before all that I'm going to make the modifications to Go Fish! This should be a relatively easy project - - I just need to get off my duff and get busy. The mystery project only exists in some mockups that Nathan has done (and is working on) and, on my end, on paper. He will have more time in the summer to work on this and I'll probably fit some time in then as well to whip up some demos. But this project, assuming it happens , is really a 2008 project. I.e., it is as tentative as it is possible to be. So that's that. I'd still like to write something for the GBA and the A800, but I just don't see that happening.
- 4 comments
-
- 2600 Game Development
- Squish Em
-
(and 2 more)
Tagged with:
-
THOUGHT I'D WRITE A BIT about what I'm planning to do for the 2006 Minigame Compo. A 4K port of Squish 'Em, an early 8bit game. (Yes, I was planning this before I read this. ) Screenshots: Typical screenshot: Bigger enemies! Plus falling brick! Your goal: the suitcase full of cash. About to Squish 'Em! Squished! Ooh, now he pops back up and is angry! (White and unSquishable.) It's a pretty fun game; I enjoyed it a bunch 20+ years ago (and last night, for that matter). Looking a little closer... I really think the game was originally designed for the VCS! Check it out: -6-digit score, though the 8bits can easily support a score as wide as the screen. -The playfield is symmetrical, but only the center. There are obvious reasons why it is easier to have a partially symmetrical playfield on the VCS, holding PF0 static; no real reason why on the A8. -Relatedly, the left eight pixels are blank for most of the screen. No real compelling reason to do this on the A8; on the 2600 this would hide unsightly HMOVE lines. -Most notably: only two sprites on any one scanline: the man and the enemy. This is really inexplicable; the A8 could support up to 3 enemies on any one platform without flicker and still have the missiles left over for the falling brick. -Also notable: color changes, both in the playfield and on the man, happen on a line-by-line basis. This is a limitation of the 2600; not necessarily of the A8. (Since only one sprite is used for the enemies, you could use all 3 sprites for the man, which would allow more than one color per row.) -Also: the score and the extra men are on different lines, despite the fact that they don't overlap. ... And of course, after writing all this down and being proud of my amazing detective skills, I go back and read the instructions, which have a Atari 2600 section. So, has this ever turned up? Interesting that a game obviously designed with the 2600's limitations in mind (and apparently developed simultaneously for the 2600, A8, Colecovision, and VIC-20) would then *not* end up being developed/released for that platform. Anyway, given all that, you'd think that a 2600 conversion would be easy, right? Well, I though so, anyway. But after writing some things down, it turns out to be a little trickier than I thought. There isn't enough time for a partially symmetric playfield, two single-line-resolution sprites (one with single-line-resolution color changes), a falling brick, and all the counter updates and loop maintenance stuff. So...first order of business: what feature gets cut? After a bunch of thinking and scribbling last night, I figured that PF1 only is used to display 2 "pipes;" PF2 is used to display four. So, why not make PF1 symmetric as well as PF0? With that change, I think everything else will fit. (Question for A8 folks: After counting and recounting on my TV screen last night, Squish 'Em only displays 144 pixels left-to-right - what's that all about?)