Jump to content
IGNORED

Whack-A-Mole - A cheesy little 2k game


aftermac

Recommended Posts

I finally got around to writing a game in bB... and since Whack-A-Mole is playable, keeps score, and has an end, it technically qualifies as a "game". :)

 

To start the game press reset. To "Whack-A-Mole" move your joystick in the direction of the mole and press fire. Your score will increment. After 100 moles the game will end and you can press reset to play again. Missing a mole will cause the next mole to appear and increment the counter, so misses will count against you.

 

This game might be better suited for the keyboard controller, but joysticks were easier at this point. I have only tested this in Stella, so I'm not sure what it would do on another emulator or real hardware.

 

I just started working on this last night and it's most likely not a finished product, but I thought I would put it up now that it is playable. I know the game is pretty cheesy, so go easy on it, but any feedback is appreciated! :D

 

whack_a_mole.bas.bin

whack_a_mole.bas_003.bin

whack_a_mole.bas_006.bin

whack_a_mole.bas_011.bin

Edited by aftermac
  • Like 1
Link to comment
Share on other sites

Great start - this is a fun game!

 

A few things - the time between moles appearing should be constant. Right now, if you 'rapid fire' the fire button the moles pop up quicker. It seems to me that the time between moles popping up should be the same or get shorter as the game goes on... Also, it should be easy to get two moles going at once since you're only using one sprite. Sounds would be helpful to tell if you hit or missed. You'd only need two, so it shouldn't be too difficult.

 

Looking great so far though.

Link to comment
Share on other sites

Quick ideas:

 

  • Looks like it's coming up in the same hole two times in a row sometimes. Might be better if you tell the program to always use a different hole than it was just in.
    _
  • Maybe animate it so it looks like it's coming out of the hole. Maybe the faster you hit it, the more points you get.

Link to comment
Share on other sites

Thanks for the feedback! I've implemented a few of your ideas in the latest version.

 

Fixes:

  • The speed is now consistent.
  • There is now a sound when you hit a mole.
  • The mole no longer comes up in the same hole twice in a row.

 

I will probably implement a speed increase the further you get in the game, in the next version.

 

I like the idea of 2 moles and animations, but that will take a bit of creativity and reworking of the code. Currently, there are only 5 bytes available and I'd like to keep this a 2k game. I've never programmed with byte limitations before, so this is a fun challenge. :)

 

whack_a_mole.bas_003.bin

Link to comment
Share on other sites

Nice little game! :D

 

As your game doesn't use scrolling you can gain 192 bytes (IIRC) if you don't include the "pf_scrolling.asm" module.

 

Just delete the "pf_scrolling.asm" line in the default.inc file. Have a look here.

 

Thanks! I remarked out the "pf_scrolling.asm" line and now have 197 bytes available. :)

 

I'm also thinking of adding a "bonus"... for example if you whack 20 moles in a row you get a bonus 20 chances, thus creating the potential for much higher scores.

Link to comment
Share on other sites

Several new changes in this version.

 

For every 10 moles you hit in a row:

  • Slight speed increase.
  • An extra 10 chances.
  • Background changes color.

 

I have also animated the mole and you get 3 points for hitting the mole on the way up, but only 1 for hitting it on the way down. ie. the quicker you hit it the more points you get.

 

At this point I don't think I'm going to add a second mole. I'm pretty happy with how the game has come along.

 

whack_a_mole.bas_006.bin

Link to comment
Share on other sites

I like the changes in the latest version! The game plays nice but there are two things that could be added IMO:

 

- A visual clue in which direction the joystick has been pressed, for example change the color of the hole

(with a missile sprite maybe) according to the direction you pressed or add a hammer (that will probably use

too many bytes though).

 

- A visual clue how many chances you have left. Maybe just change the scorecolor to red when you have

only 1 chance left?

Link to comment
Share on other sites

I like the changes in the latest version! The game plays nice but there are two things that could be added IMO:

 

- A visual clue in which direction the joystick has been pressed, for example change the color of the hole

(with a missile sprite maybe) according to the direction you pressed or add a hammer (that will probably use

too many bytes though).

 

- A visual clue how many chances you have left. Maybe just change the scorecolor to red when you have

only 1 chance left?

 

Thanks for the feedback Impaler! I really like both of those ideas! :)

 

Right now I have 11 bytes left, so lets see what I can come up with. I already had to reduce the animation from 4 sprites to 3, to make room for everything. I'm sure there is some inefficiency I can improve on. :)

Link to comment
Share on other sites

I like the changes in the latest version! The game plays nice but there are two things that could be added IMO:

 

- A visual clue in which direction the joystick has been pressed, for example change the color of the hole

(with a missile sprite maybe) according to the direction you pressed or add a hammer (that will probably use

too many bytes though).

 

- A visual clue how many chances you have left. Maybe just change the scorecolor to red when you have

only 1 chance left?

 

Thanks for the feedback Impaler! I really like both of those ideas! :)

 

Right now I have 11 bytes left, so lets see what I can come up with. I already had to reduce the animation from 4 sprites to 3, to make room for everything. I'm sure there is some inefficiency I can improve on. :)

 

Ok, I freed up a whopping 6 more bytes just by moving some code around, however adding the scorecolor routine took 17 bytes... so, I have exactly 0 left.

 

I'm pretty sure there has to be a more efficient way to generate a number between 1-9 than the way I'm doing it. This routine is pretty self explanitory, but it generates a random using "r" then some if-then statements divide 255 into 9 parts and sets the hole the mole is going to appear and the coordinates. Actually, now that I think about it, I could just use "m" in place of "r" altogether, but I'd still like to streamline the whole routine.

 

r = rand

if r < 28 then m = 1 : player0x = 43 : player0y = 19
if r > 27 && r < 56 then m = 2 : player0x = 79 : player0y = 19
if r > 55 && r < 84 then m = 3 : player0x = 115 : player0y = 19

if r > 83 && r < 112 then m = 4 : player0x = 43 : player0y = 43
if r > 111 && r < 140 then m = 5 : player0x = 79 : player0y = 43
if r > 139 && r < 168 then m = 6 : player0x = 115 : player0y = 43

if r > 167 && r < 196 then m = 7 : player0x = 43 : player0y = 67
if r > 195 && r < 224 then m = 8 : player0x = 79 : player0y = 67
if r > 223 then m = 9 : player0x = 115 : player0y = 67

 

If I had a statement that could just use "rand" to pipe 1-9 directly into "m" then I could get rid of all the ">", "&&", "<" code. I'm not sure if it would free enough space to create an indicator for which way you are pointing, but this is the most inefficient bit of code in the program. Any thoughts?

 

Maybe start the game with a slower speed for the moles.

 

I'm sure I can do something... might have to rework the animation routines a bit, though.

Link to comment
Share on other sites

r = rand

if r < 28 then m = 1 : player0x = 43 : player0y = 19
if r > 27 && r < 56 then m = 2 : player0x = 79 : player0y = 19
if r > 55 && r < 84 then m = 3 : player0x = 115 : player0y = 19

if r > 83 && r < 112 then m = 4 : player0x = 43 : player0y = 43
if r > 111 && r < 140 then m = 5 : player0x = 79 : player0y = 43
if r > 139 && r < 168 then m = 6 : player0x = 115 : player0y = 43

if r > 167 && r < 196 then m = 7 : player0x = 43 : player0y = 67
if r > 195 && r < 224 then m = 8 : player0x = 79 : player0y = 67
if r > 223 then m = 9 : player0x = 115 : player0y = 67

 

If I had a statement that could just use "rand" to pipe 1-9 directly into "m" then I could get rid of all the ">", "&&", "<" code. I'm not sure if it would free enough space to create an indicator for which way you are pointing, but this is the most inefficient bit of code in the program. Any thoughts?

Hmm... i'm a bloody beginner myself but there should be a better way to do this... maybe with "on rand goto" or data statements... I'll have to look that up...

If you don't mind you can PM me your code and i can try to squeeze out a few more bytes...

Link to comment
Share on other sites

Haha! Good game for your first try!!! :D :thumbsup:

 

Thanks, Iwan! :) This is something I've wanted to do for a long time. I've got more ideas for the future, too... maybe a fighting game, a paddle shooting game... :ponder:

 

that game is too hard for me :(

 

nice idea though

 

Ouch, that's rough! My best score so far is 166 (with this version... the scoring has changed each time), but I don't have a screen shot.

 

I appreciate your feedback, though! Between your comments and what neotokeo said, maybe the game is starting off a bit quick. That's something I'm going to work on and it would be great if you would give it another try after I implement the changes. :)

 

That has been a big challenge with this project is finding a balance between too easy and impossible.

Link to comment
Share on other sites

Haha! Good game for your first try!!! :D :thumbsup:

 

Thanks, Iwan! :) This is something I've wanted to do for a long time. I've got more ideas for the future, too... maybe a fighting game, a paddle shooting game... :ponder:

 

that game is too hard for me :(

 

nice idea though

 

Ouch, that's rough! My best score so far is 166 (with this version... the scoring has changed each time), but I don't have a screen shot.

 

I appreciate your feedback, though! Between your comments and what neotokeo said, maybe the game is starting off a bit quick. That's something I'm going to work on and it would be great if you would give it another try after I implement the changes. :)

 

That has been a big challenge with this project is finding a balance between too easy and impossible.

 

Since this is a game that kids might play you should either start the first few levels at a slower speed or have two versions of the game selectable from the start (Easy/Advanced). I think the default should be easy. Great game. Hard to believe it is your maiden voyage. :thumbsup:

Link to comment
Share on other sites

Haven't had a chance to play with it, but it sounds fun.

 

Seeing the screenshot now, it sorta says to me, "I want to be played with the keypad controller". The correlation between what's on screen and which button I hit on the controller seems more like playing the mechanical arcade version. Slightly. Could be an option if the game goes to cartridge (which I think it very well could/should, especially if a kid-friendly "Teddy Bear" version is included).

Link to comment
Share on other sites

oh, i'll be definitely following the development, thanks. that screenshot wasn't actually my high score, just to give people browsing the boards a rough idea how does the game look. i often find myself not being able to try the game in emulator (that's mostly at work, but shhh - don't tell my boss ;) ) so i would love to have a possibility to at least look at the screenshot.

 

if it comes to the gameplay, well - for a casual atari gamer like me, it's bit frustrating and discouraging at the moment. but most people seem to have fun with it, so don't rely on my opinion too much!

Link to comment
Share on other sites

Since this is a game that kids might play you should either start the first few levels at a slower speed or have two versions of the game selectable from the start (Easy/Advanced). I think the default should be easy. Great game. Hard to believe it is your maiden voyage. :thumbsup:

 

Thanks! I've been writing code in various forms for 15+ years now, but nothing nearly as fun as video games. :)

 

You make some great points... making a kid friendly option is definitely a good idea!

 

Haven't had a chance to play with it, but it sounds fun.

 

Seeing the screenshot now, it sorta says to me, "I want to be played with the keypad controller". The correlation between what's on screen and which button I hit on the controller seems more like playing the mechanical arcade version. Slightly. Could be an option if the game goes to cartridge (which I think it very well could/should, especially if a kid-friendly "Teddy Bear" version is included).

 

Yeah, I agree this would be a great keypad controller game... in fact when I came up with the game concept, I was looking at my kids controller... funny that I didn't think of making a kid-friendly option... :ponder: :)

 

The problem is that there isn't great (any?) support in bB for the keypad controller... and I haven't even thought about touching assembly language yet! :)

 

oh, i'll be definitely following the development, thanks. that screenshot wasn't actually my high score, just to give people browsing the boards a rough idea how does the game look. i often find myself not being able to try the game in emulator (that's mostly at work, but shhh - don't tell my boss ;) ) so i would love to have a possibility to at least look at the screenshot.

 

if it comes to the gameplay, well - for a casual atari gamer like me, it's bit frustrating and discouraging at the moment. but most people seem to have fun with it, so don't rely on my opinion too much!

 

I'll remember to post screenshots for any future games I make! :)

 

Your opinion is important! That's what's great about having a community of people to get ideas from. I'm just glad (and slightly surprised) that so many people think this is at least a decent attempt at a game! :)

Link to comment
Share on other sites

I like the changes in the latest version! The game plays nice but there are two things that could be added IMO:

 

- A visual clue in which direction the joystick has been pressed, for example change the color of the hole

(with a missile sprite maybe) according to the direction you pressed or add a hammer (that will probably use

too many bytes though).

 

- A visual clue how many chances you have left. Maybe just change the scorecolor to red when you have

only 1 chance left?

 

Thanks for the feedback Impaler! I really like both of those ideas! :)

 

Right now I have 11 bytes left, so lets see what I can come up with. I already had to reduce the animation from 4 sprites to 3, to make room for everything. I'm sure there is some inefficiency I can improve on. :)

 

Ok, I freed up a whopping 6 more bytes just by moving some code around, however adding the scorecolor routine took 17 bytes... so, I have exactly 0 left.

 

I'm pretty sure there has to be a more efficient way to generate a number between 1-9 than the way I'm doing it. This routine is pretty self explanitory, but it generates a random using "r" then some if-then statements divide 255 into 9 parts and sets the hole the mole is going to appear and the coordinates. Actually, now that I think about it, I could just use "m" in place of "r" altogether, but I'd still like to streamline the whole routine.

 

r = rand



if r < 28 then m = 1 : player0x = 43 : player0y = 19

if r > 27 && r < 56 then m = 2 : player0x = 79 : player0y = 19

if r > 55 && r < 84 then m = 3 : player0x = 115 : player0y = 19



if r > 83 && r < 112 then m = 4 : player0x = 43 : player0y = 43

if r > 111 && r < 140 then m = 5 : player0x = 79 : player0y = 43

if r > 139 && r < 168 then m = 6 : player0x = 115 : player0y = 43



if r > 167 && r < 196 then m = 7 : player0x = 43 : player0y = 67

if r > 195 && r < 224 then m = 8 : player0x = 79 : player0y = 67

if r > 223 then m = 9 : player0x = 115 : player0y = 67

 

If I had a statement that could just use "rand" to pipe 1-9 directly into "m" then I could get rid of all the ">", "&&", "<" code. I'm not sure if it would free enough space to create an indicator for which way you are pointing, but this is the most inefficient bit of code in the program. Any thoughts?

 

Maybe start the game with a slower speed for the moles.

 

I'm sure I can do something... might have to rework the animation routines a bit, though.

 

You could do this:

 

m=(rand & 8 ) + 1

 

which will give you a random number between 1 and 9. Just take the space out between the 8 and ). I couldn't put them side by side or I got this 8)...

 

This should also work:

 

r = rand

m = r/32 + 1

 

I'm not sure which one would give you a better 'true' random number. You could play around with it...

Link to comment
Share on other sites

You could do this:

 

m=(rand & 8 ) + 1

 

which will give you a random number between 1 and 9. Just take the space out between the 8 and ). I couldn't put them side by side or I got this 8)...

 

This should also work:

 

r = rand

m = r/32 + 1

 

I'm not sure which one would give you a better 'true' random number. You could play around with it...

 

 

You could do this:

 

m=(rand & 8 ) + 1

 

which will give you a random number between 1 and 9. Just take the space out between the 8 and ). I couldn't put them side by side or I got this 8)...

 

This will only give you the number 8 or 9

 

After experimenting a bit here is what gives me the best result:

 

m=((rand) / 29) + 1

 

Though, I had to add "include div_mul.asm" to the program... I still ended up gaining 40 bytes of space. It's not quite perfect, but I think it's pretty close. All 9 moles seem to pop up regularly during a game.

 

m=(rand & 8 ) + 1 seemed to give me a 1 or 9.

 

m = r/32 + 1 would only be 1 - 8.

 

I've also reworked the logic that checks for a hit and gained ~50 bytes. It shouldn't take that much to implement a "Teddy bear" skill, but I should also be able to rework the animation routine to scale better with the speed changes. I've also been playing with code to show which mole you are aiming at, but that isn't nearly ready for prime time, if it makes it to the final version at all. Don't have a new version to post yet, but I should before the weekend is over.

Link to comment
Share on other sites

Hey guys, could you try out the version I've attached here on "left difficulty B", please? I slowed it down quite a bit (I think), but I would like your opinions. The only other game play change you should notice is that the score will change to red if you have less than 15 moles remaining. All of the other changes in versions 7-10 are bug fixes and optimizations.

 

Thanks!

 

whack_a_mole.bas_011.bin

Link to comment
Share on other sites

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...