Jump to content

Recommended Posts

Now we're making tracks! I've got a playfield for the game, along with some limited animation. You can probably guess where I'm going with this... it's a Whack A Mole/Mole Attack style game, with Byron popping out from one of nine holes. A cartoon mallet is controlled by the player, and the fire button swings it. Bopping Byron on the head scores you points, while bopping him on the butt subtracts them. Reach the target score in the allotted span of time and you advance to the next stage; fail to do this and you lose. (Later stages have Byron holding up a bomb... this will instantly end the game if you strike it.) In addition to the standard whack a mole gameplay, I'm planning quick draw bonus rounds which challenge you to hit one safe target from several that pop up at once, or hit Byrons in the order that they appear (kind of like Simon).

 

It's still not playable, but I've got most (all?) of the graphics ready. I just need to figure out the game logic; I'm probably going to use a DIM statement to split the screen into nine sections, and each section operates independently from the others. Sound will likely be a problem... I've never been good at this, but it seems there are various tools that will make things easier for me, including one by the ever-busy Tursi.

byron_bash.bas byron_bash.rom byron_title.rom byron_title.bas

  • Like 7
Link to comment
https://forums.atariage.com/topic/364885-whack-em-smack-em-byron-dev-log/
Share on other sites

Wow! It looks pretty cool :)

 

I could suggest a DATA table having the #hole_offsets for each of the 9 holes, starting from zero. And a DIM array state to hold the state of each of the 9 holes.

 

I could further suggest a draw_hole procedure receiving a variable c, containing the number of hole to draw, and it would choose how to draw the hole based on the state array.

 

Then your offset would be #c = #hole_offsets(c), you would have a ON array_state(c) GOTO draw_1,draw_2 and you could do PRINT AT #c adjusting by offset.

 

I couldn't resist to put some screenshots taken with CoolCV.

 

image032.png.43fc2f4f791125f7c66d5ad4f41f715e.png  image033.png.b2e4c1f0d21a07ad5cf315f2aade851d.png

  • Like 1

We've reached a slight impasse, it seems. CONT1 can't be used to read diagonals, at least not by saying things like IF CONT1.LEFT AND CONT1.UP... for up and left. I can read the individual directions by addressing CONT1 directly, but this presents its own problems... pressing fire in conjunction with one of the directions adds 64 to the total, and could complicate matters slightly. I'll have to brainstorm and see what I can do to work around this.

More progress. I've got the mallet up on the screen... it's fully controllable with the joystick, and can be swung by pressing the fire button. (Probably either fire button, judging from the way the Coleco controller is read and how I've set it up. I don't know how to parse bits out of a byte, although I'm sure there's a way to do it.)

 

Next on the menu? Getting the Byrons to pop up!

whackem_game.rom

15 hours ago, Jess Ragan said:

We've reached a slight impasse, it seems. CONT1 can't be used to read diagonals, at least not by saying things like IF CONT1.LEFT AND CONT1.UP... for up and left. I can read the individual directions by addressing CONT1 directly, but this presents its own problems... pressing fire in conjunction with one of the directions adds 64 to the total, and could complicate matters slightly. I'll have to brainstorm and see what I can do to work around this.

The CONT1.UP is only meant to return a non-zero value if the joystick direction is upwards.

 

However, this is meant to allow the generation of the smallest possible code, as CVBasic only applies an AND instruction to the controller port value, also the AND logical operator is bitwise.

 

So if you need to test for two directions, you need to do this: IF CONT1.UP <> 0 AND CONT1.LEFT <> 0 THEN ' Upper-left

 

I've made an example.

TEST12.BAS

whackem_game.romwhackem_game.bas

 

The game! It's starting to resemble a game! I'm excited. So far I've got a working mallet, a working score (built from one 16-bit variable and one 8-bit variable; when both are full the score rolls over), a working timer, and one to three Byrons that pop out of holes when the timer "interval" reaches "intervalmax." There is still no collision detection; I'll need to squeeze that in there in a later update.

 

The game is probably way too fast at the moment, but I'm planning to include a dynamic difficulty adjustment based on the stage reached. The higher the stage, the faster the action and the more Byrons that appear. Butts will also appear more frequently in later stages, as well as deadly bombs that end the game instantly. As with your standard whack-a-mole style video games, the player is expected to reach a target score for that stage, which raises depending on the difficulty level.

 

Everything's running well so far, even if the code is an absolute mess. One sticking point is that swinging the mallet noticeably slows the game down, and spamming it will reduce the action to a crawl. I'm not sure if this can be fixed, but I certainly hope there's a solution.

  • Like 1

Wow! It looks pretty cool.

 

You already coded the game like separated state machines, so that's excellent for game pace.

 

The MalletSwing label should be located just above the TimeForTimer label. That's the cause the Byrons don't animate when the mallet is swing. Or alternatively, the GOTO MalletSwing statement should jump instead to TimeForTimer

 

 

  • Like 1
20 minutes ago, Jess Ragan said:

Dang! Good call! I just made the change and the game runs more consistently now. Can you explain why?

If the mallet was swing you jumped over the joystick movement code, but also over the time counter for the Byrons, so these stopped moving.

We have collision detection! And point labels! (You would not believe how annoyed I get when ColecoVision arcade ports don't have these.)

 

One slight problem: new Byrons will pop up in holes where there is already activity from bonked Byrons. This seems easy enough to fix, by placing a flag in the PoppinByrons routine preventing new Byrons from being spawned in those locations.

 

There's still no trace of sound or music. I have ideas for these, but as I've stated before this is not my strong suit.

whackem_game.rom

  • Like 1

whackem_game.rom

 

We're in the mid to late alpha stage. This demo lets you play one round with standard settings. Once it's finished, the game halts and needs to be restarted either with the reset button on the ColecoVision, or the appropriate option on your favorite CV emulator.

 

I'm liking where this is going. I have the level logic for the first two stages set up, but it's not read yet, nor is that section of the game finished. Adjusting the level stats not only makes the game faster or slower, but can be used to create special situations ("sure shot" stages where players are given a limited number of targets, making accuracy a must, "speed round" stages where TONS of Byrons pop out of the holes, etc.). The original plan was to include bonus stages, but I haven't gotten to that yet... I imagine it'll be tricky.

 

While I'm at it, here are a few conceptual scenes in the game. High scores are a possibility, but let's see where development takes us first. The red game over screen appears only when the player strikes a bomb... it's a little showy and may not be in the final build because of memory constraints. (I'm doing pretty well with ROM size so far, but there's still sound effects to worry about.)

 

Anyway! Give it a spin, let me know what you think.

 

 

highest scores.png

whack em game over sample.png

  • Like 2

I'm astonished by the graphic details. Well done!

 

I haven't tested in real hardware, but I remember the default controller stick isn't very good for diagonals. I could suggest an optional interface using the keypad as a compass rose.

 

I was thinking about using the second player keypad as an optional control. Heck, if I were really daring, I could even create an expansion module consisting of a matrix of nine very large buttons, similar to what you might find on an arcade panel. Call it Expansion Module 99: the Mole-er Controller.

 

As for the graphics, I'm using Aseprite to build them. There's a grid option that lets you separate your pixel art into 8x8 chunks, so I can more easily work around the system's limitations.

 

One thing that's weird is that I used your TMScolor program to turn some custom border graphics I made into CV graphics. The top and bottom of the graphics had dithering in it despite my best efforts to limit each line to two colors. But I liked how it looked, so I'll probably keep it that way.

  • Like 1

I actually lost some progress earlier when I busted a FOR/NEXT loop, couldn't find the damn thing, and had to restart from a way too old back up copy. Ugh. UGGGGGH. But now has arrived the MYSTERY BYRON! Whack him with the PEEK-0 hammer for a bonus, higher than all other bonuses in the game and perhaps even double that. And gaze in awe at his iridescent green BONUS! sign! It looks nice... the VDP has some gross colors but it comes through on the shades of green.

 

Next? Bombs! Hit them and be blown sky high! (But the program is already the size of many ColecoVision games and it's only 75% finished. I might not be able to make it as explicit as I wanted. I don't know what the overhead is on the compiler. These games go up to 32K, right, Nanochess? Is bank switching a concern, or is that handled auto-magically?

whackem_game.rom

  • Like 1
4 hours ago, Jess Ragan said:

I actually lost some progress earlier when I busted a FOR/NEXT loop, couldn't find the damn thing, and had to restart from a way too old back up copy. Ugh. UGGGGGH. But now has arrived the MYSTERY BYRON! Whack him with the PEEK-0 hammer for a bonus, higher than all other bonuses in the game and perhaps even double that. And gaze in awe at his iridescent green BONUS! sign! It looks nice... the VDP has some gross colors but it comes through on the shades of green.

 

Next? Bombs! Hit them and be blown sky high! (But the program is already the size of many ColecoVision games and it's only 75% finished. I might not be able to make it as explicit as I wanted. I don't know what the overhead is on the compiler. These games go up to 32K, right, Nanochess? Is bank switching a concern, or is that handled auto-magically?

whackem_game.rom 15.54 kB · 2 downloads

Wow! It looks really good.

 

You can go up to 32K for your games. Currently, there is no support for bank-switching.

 

I'm working on more optimization for the CVBasic compiler so you can regain a few kilobytes in big programs.

 

Did you ever want to play Whack 'Em Smack 'Em Byrons with a keypad? Now you can! Just plug in a second controller and bop those bratty bears at your leisure. I was thinking about implementing this earlier, but "Everybody Loves" Rayxanber (the AtariAge user, not the Data West video game for the TurboDuo) convinced me to finally add it to the feature list.

whackem_game.rom

  • Like 1

Work on Whack 'Em Smack 'Em Byrons continues apace. Now there are intermissions! Well, intermission in the singular form. More are planned, for a total of eight. I'm really liking some of the screen wipes and partial screen wipes I've included... it gives the game an air of class. (I mean, as much class as you're getting from a ColecoVision game where you're clobbering ursine toddlers over the head with a hammer.)

whackem_game.rom

  • Like 1

The wacky bear whackin' game is steadily chugging toward the finish line! It's more done than undone now. Some things are still required... I wanted more intermissions, the comments between stages need to be better centered, and I should probably squeeze the title screen in there too. Obviously, sound is completely missing, and I'll have to work (or find work) to fill in those gaps.

 

Note that some stages are supposed to have special conditions, which are not yet properly implemented. Still, it's more or less complete. Maybe eighty percent complete. Depends on how much you think sound matters. Maybe seventy five percent complete. What's nifty is that the VRAM is dynamic and can be refreshed with new data depending on the stage or situation. It takes up extra cartridge storage, but at the rate things are going, I think I'll be able to do all I want with this and keep the total package below 32K.

whackem_game.rom

3 hours ago, Jess Ragan said:

There's a title screen now! Also, Byrons who escape your mallet are removed and cannot be hit. That was a problem with previous builds, but not anymore!whackem_game.rom

Wow! Pretty amazing what you did in only 2 weeks! A full-blown game :)

 

Kids' mode? Don't mind if I do! Kids' mode currently cuts the quota to 60%, and could later be used to adjust other stats.

 

I have to deal with some unpleasant business in my life which could slow down the production of the game, not that there's that much left in the game to do. So if I disappear, that's the reason. I'm not... at optimal mental health right now. :(

whackem_game.rom

  • Like 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...