45 replies to this topic

[theloon]

This work is licensed under the Creative Commons Attribution 3.0 Unported (CC BY 3.0)

http://creativecommo...icenses/by/3.0/

MONSTER MANAGEMENT SECURITY BUREAU OF CINCINNATI 2This is a show piece for the Louisville Arcade Expo.  Writer/Artist Ricky Henry wanted something to draw crowds in for his comic/manga work Monster Management Security Bureau of Cincinnati.The video game convention is in March so development and production needs to be done by mid Feb.  This is my only project with a hard deadline right now.

Features:

* Two player cooperative gameplay

* Two simultaneous laser shots of different colors

* Up to 8 enemies simulated

* Parallax side-scrolling

* Unique coloring for each individual object on-screen

* Health bars have unique coloring per player

Instructions:

This is a two player cooperative game.  The objective is to rack up as many points as possible - which also means both players surviving as long as possible.  RESET will reset game.  SELECT will toggle between 3 difficulty levels: NORMAL, HARD and MANIAC.  Each players FIRE button will launch a laser.  Once a salvo has been launched no additional lasers can be fired from your ship.  Lasers will damage and pass through enemies.  Each player has a shield bar at the bottom left (player 1) and right (player 2) side of the screen.  If too much damage is taken from collisions with enemies or fire then the player will be forced to land.  Landing reduces the cities morale (topmost status bar).  If morale drops to zero the game is over.  At certain periods during the game a boss will appear shooting fireballs.  Once the boss is defeated gameplay will resume at a higher difficulty level.

Enemies:

SPACE BUNNIES
Four mutant space "bunnies" will march forward intent on invasion.

COMETS
Space debris and evil satellites will shoot forward seemingly intent on harshing your mellow.

FIGHTERS
A duo of space mutants press forward whilst tactically diving or retreating unexpectedly.

SPACE PICKLE
The leader of the fleet.  Will strafe the players while occasionally attempting to ram them.  Launches fireballs and warps around the screen.  When hit teleports to a new location.

M.M.S.B.C. 2 for the Atari 2600 is the work of Jason Santuci.  M.M.S.B.C. the comic book is copyright BIT"POP by Ricky Henry and Chad Shoettle.

Special thanks to go:

SeaGtGruff for his pfscroll library

R.T.  KevinMos3 and others for feedback

iesposta for bug hunting

stephena for his excellent work on Stella.

bogax for coding help and scorebar routines

CPUWIZ for having my back

Finally, big thanks to AtariAge in general.  No way this would ever have a chance without you guys.

Attached Thumbnails

• 
• 
• 
• 

Attached Files

•  mmsbcII.bin   16K   122 downloads
•  mmsbcII04.bas   21.96K   65 downloads
•  MMSBCL.zip   343.88K   67 downloads

[theloon]

Okay.  Build #5 is posted up top.  Here are some highlights:

* Player lasers no longer pulse.  This improves hit detection but makes beams dimmer.
* Collision with enemies detected.  Shields for players now go down when hit.
* Collision with players detected.  Enemies now are repulsed and shake randomly when hit.
* No longer attempt to alternate player/enemy colors per frame.  The color blending wasn't pronounced enough to warrant it.
* Enemies march forward and wrap around when far left side of screen is reached.

Usually I like to flash the player color randomly when hit.  This is a nice visual que that an injury has taken place.  Can't do that here since the "players" are actually the missiles.  Since missile0 and player0 share the SAME COLOR both player and enemy flash.  No good.  I'll have to rely on other means to indicate a hit.. sigh.

[iesposta]

I like how it alternates bunny face, bunny tail, and that they dance.
Your programming ideas are always very original (like missiles as players).
Good start!

[theloon]

Okay, did a 2am-5am coding spree.  Results at top.

* Player ship collisions registers by shaking effect
* Collisions with monsters now flashes color in shield bars.
* Bounds checking so player ships cannot get stuck in ground.
* Monsters now move off screen.  New monsters randomly appear from far side. (although only one monster type is present)
* Since player sprites cannot be shared made separate models for player0 and player1 sprites.

[theloon]

Okay, coded 'till 3:00am today.  Results at top.

I ended up ditching the ON GOTO and ON GOSUB as my own lack of skill coupled with bB weirdness rendered them unreliable.  Added comet enemies!  Played around with colors so almost EVERYTHING on-screen has a unique color.  Player ships are even multi color!  The shield bars are also dual color.  SOMETHING was corrupting the pfscore bars so I kinda had to redraw them every frame.  I figured I'd alternate colors to simulate different shades for each players shields.

Please tell me if any of the flickering is too much.

UPDATE:  Okay, 6:43am is here and I realize what looked great on my laptop looks awful on my LCD monitor.  Build 14b changes the colors a bit and adds animation to the players ships wings such that they tilt when moving up or down.  Whew!

[theloon]

Up at top I posted the game binary of my last LAST changes for Saturday.  Just the binary mind you.  Wanted to show off the start of a "health bar" up top for the city of Louisville.  Also, I forgot to mention enemies can be destroyed in these most recent versions.  The cityscape has become more defined as buildings can now have smokestacks.  Sloowed down the speed of the buildings too.  They are in the distance, after all.

I'm afraid of flicker being to strong.  Definitely interested in what people think of it.  Wondering how it looks on a real TV too.  The benefits of interleaving colors per frame are huge though.  Did you notice?

* blue AND red pfscore bars at the same time!
* Light blue and light red balls (player ship 1 & 2s shots).  Note that the ball should be a single thing and not two shots.  It also shouldn't be a different color (or colors!) than the playfield.
* Player ships (missile0 & missile1) do not share the same color as sprite0 or sprite1.

[theloon]

Made some great progress last weekend but now I've got good news and bad news.

Good news is:  Looks GREAT on a real TV.  Different LCD monitors have different refresh rates which make things either a little more red/blue or flicker more/less.  No such problems on real TV.

Bad news is I'm going over cycle.  In particular when the enemy goes off screen on the left hand side.  I'm feeling pretty bummed about this.  Unless I can pin down a particular line of code I may have to rewrite almost everything.

[bogax]

I didn't really try to understand your code.

I can see things that might possibly speed things up
(I didn't try to figure out if they actually would
or if it would be enough to bother)

for one thing

draw_shieldsp0
if shieldsp0 < 32 then pfscore1 = %10000000 : return
if shieldsp0 < 64 then pfscore1 = %11000000 : return
if shieldsp0 < 96 then pfscore1 = %11100000 : return
if shieldsp0 < 128 then pfscore1 = %11110000 : return
if shieldsp0 < 160 then pfscore1 = %11111000 : return
if shieldsp0 < 192 then pfscore1 = %11111100 : return
if shieldsp0 < 224 then pfscore1 = %11111110 : return
if shieldsp0 < 255 then pfscore1 = %11111111
return

could be rewritten as

temp1 = shieldsp0 / 4 / 8 : pfscore1 = sh0tbl[temp1] : return

data sh0tbl
%10000000, %11000000, %11100000, %11110000, %11111000, %11111100, %11111110, %11111111
end

you've got a number of tail calls that could be optimized eg

move_nothing0
player0x = (player0x - 1)
if player0x = 0 || player0x > 240 then gosub change_object0
return

could be

move_nothing0
player0x = (player0x - 1)
if player0x = 0 || player0x > 240 then goto change_object0
return

and if I'm reading right

change_object0
player0x = view_width
player0y = (random&63) + 1
tempvar = (random&3) + 1
if tempvar > 3 then temp5 = 3
if tempvar = obj_nothing then gosub create_nothing0
if tempvar = obj_4bunnies then gosub create_4bunnies0
if tempvar = obj_comet then gosub create_comet0
return

could be

change_object0
player0x = view_width
player0y = (random&63) + 1
tempvar = (random&3) + 1
if tempvar > 3 then temp5 = 3
on tempvar goto RET create_nothing0 create_4bunnies0 create_comet0

RET
return

This is just for illustration.
like I used temp1 without regard to whether you were
already using it (if you are you'll have to figure
something else out obviously)
or like you shouldn't need RET, tempvar should vary 0-2

edit:
I see you're doing a lot of bankswitched returns.
it'd probably help a lot if you knocked that off
if you don't/can't then an on..goto that only has two
targets and allows a tail call optimization is probably
faster

Edited by bogax, Tue Feb 5, 2013 2:02 PM.

[theloon]

I really appreciate the help bogax!

I initially was using on goto/gosub but ran into some mysterious issues.  I should try again (especially if it saves cycles).

I'll definitely borrow your pfscore bar code.  I never thought to use DATA statements!

I'm not sure I understand the points about:

move_nothing0
player0x = (player0x - 1)
if player0x = 0 || player0x > 240 then gosub change_object0
return

..because your before and after look the same to me.

Also, how are the gosubs bankswitched?  They should all be in the same bank.  Is the bB assembly using complicated gosub code used for multi-bank jumps?

My intention was to force an event driven model on the bB code.  I'm starting to realise quick and dirty goto style is the only way to stay under cpu load.

[bogax]

theloon, on Tue Feb 5, 2013 2:18 PM, said:

I'm not sure I understand the points about:

move_nothing0
player0x = (player0x - 1)
if player0x = 0 || player0x > 240 then gosub change_object0
return

..because your before and after look the same to me.

yours is gosub, use goto (since you're going to return right away
any way) that way you save a return

Quote

Also, how are the gosubs bankswitched?  They should all be in the same bank.  Is the bB assembly using complicated gosub code used for multi-bank jumps?

if you've got multiple banks and you don't tell bB you're returning to
the same bank bB assumes you might be returning to a different
bank and checks and that takes more time. (if you want to gosub to
a different bank I think you have to explicitly specify or else bB
assumes it's the same bank)

philosophical statement:
there's nothing wrong with gotos just don't abuse them

Edited by bogax, Tue Feb 5, 2013 2:52 PM.

[bogax]

it appears that bB sometimes treats random as a call
to randomize ie the same as rand
I suggest you change random to something else, probably
something that doesn't start with rand and see what that
does for you.

[theloon]

I've been refactoring my code.  No gosubs.  Using macros and defines for clarity.  Broke down an put an underscore in front of constants.  Incorporated bogaxs pfscorebar display code (thanks again!).  Removed scrolling on the grass as R.T. said it was distracting.

I SWEAR the SWCHA diagram on R.T. website is bass akwards.
http://www.randomter...ands.html#swcha

Unless I'm doing something really funky in my code again, that is.. sigh.

Attached Files

•  M2REW_02.bas   4.17K   27 downloads

[theloon]

Not quite ready to post another binary at top.  Not all features are back into place after the rewrite.  Here is what we have back:

* Monsters move
* new monsters generated as old ones leave play
* Laser shots for both player ships

Still lost:

* Ships wings no longer tilt (may not put back due to complications in player ship movement)
* Collision between lasers and monsters
* Collision between ships and monsters

So far I'm only calling rand once.  I'm using the counter variable as rand in other places where distribution isn't a huge factor.  Trying real hard not to duplicate code.  Only branching when I need to touch player0/player1 specific code.

I'm going to mention this again:  SWCHA seems incorrect to me.  I thought x goes UP as you move right and y goes UP as you move down.  I'm having to do the exact OPPOSITE in my joystick routines.  Again, I'm following the SWCHA diagram on R.T.s website.

Attached Files

•  M2REW_05.bas   7.77K   35 downloads

[Cybearg]

Tried the version at the top. At first, I was confused about what was going on. I know it's still a work in progress, but I think that sound effects to demonstrate if hits are doing damage (since otherwise the foursome of monsters just kind of wiggle when hit like I tickled them).

I played in z26 (which seems like it's more accurate at replicating the way a real 2600 looks compared to Stella) and everything was very flickery from what I saw. The life bar, the buildings, the monsters, and the planes were all flickering colors and the planes were flickering between being a block and a rectangle. I thought either this was intended or some rare occurrence until I tried recording it with FRAPS then watched the footage. Things look fine in the footage after the first few seconds, but the entire game looked like it does in those first few seconds for me, with everything flickering. Also, the score seems to reset and repeat, which I assume wasn't intended.


Overall, I think it's neat! I like the little car-blocks moving at the bottom and the buildings scrolling past and it's a great use of pfheights, methinks. I have a couple suggestions.

1. You were probably going to do this anyway, but I'd say break off those groups of four monsters so that the monsters move individually. They can come at the player from different angles/patterns, creating pinch maneuvers that forces the player to get out of the way, etc. On a similar note, maybe (depending on if this would playtest well or not), make colliding with the buildings below to be a bad thing, allowing the player to dip between the buildings here and there but forcing the player to move back up into the more dangerous upper region. That would keep the player moving up and down.

2. I found that I played always on the far left side of the screen and never really moved right, even though I could. I'd recommend doing something to force the player out of the far left of the screen, such as something dropping down from above to drive the player right, or maybe the monsters could move in pinch maneuvers, as mentioned above, which connect at the left, forcing the player to move right to avoid being hit.

Also, some kind of boss after a while would be neat as well.

[stephena]

Cybearg, on Sat Feb 9, 2013 10:40 AM, said:

I played in z26 (which seems like it's more accurate at replicating the way a real 2600 looks compared to Stella) ...

Arrgh.

• Use OpenGL mode in Stella.
  
• Turn on vsync.
  
• Set aspect ratio to 80% or so.
  
• If you really like z26 colours more, use z26 palette.
  
• Go into TV effects and turn on scanlines and different TV modes (composite, Svideo, RGB, etc).

I don't see how you can say that Stella won't accurately show how a real 2600 looks.

[Cybearg]

stephena, on Sat Feb 9, 2013 11:39 AM, said:

Arrgh.

• Use OpenGL mode in Stella.
  
• Turn on vsync.
  
• Set aspect ratio to 80% or so.
  
• If you really like z26 colours more, use z26 palette.
  
• Go into TV effects and turn on scanlines and different TV modes (composite, Svideo, RGB, etc).

I don't see how you can say that Stella won't accurately show how a real 2600 looks.

No offense! I meant it in the sense that, out of the box, I saw rolling and other things demonstrating the problems inherent with a real 2600 in z26 but not in Stella. Awesome that there are ways to replicate it (and no, I don't like z26's colors more), and no offense is intended. That was just a side-note to explain that I was assuming that's what the game would look like on a TV, though it may not.

[stephena]

Cybearg, on Sat Feb 9, 2013 12:04 PM, said:

No offense! I meant it in the sense that, out of the box, I saw rolling and other things demonstrating the problems inherent with a real 2600 in z26 but not in Stella.

Then the appropriate thing to do is report the ROM and version of Stella used so that the emulation can be improved.  A simple note (to me) saying "XXX ROM doesn't roll in Stella when it does on a real TV" would suffice.  Please forward/post the exact ROM that causes this issue, and a brief description of how it differs from a real console/TV.  This feedback will help improve Stella, and in the long run help all developers.

[theloon]

stephena is the maintainer of Stella.  He is a very active developer and actually cares about the quality - and thus the benefit of his work.  Trouble is, end users like us generally smack talk about bugs and issues instead of reporting them correctly.

[theloon]

@Cybearg: Thanks for checking out my game!  You made many good points.  Allow me to explain a little.

I know it's still a work in progress, but I think that sound effects to demonstrate if hits are doing damage
Sound hasn't been implemented yet but IS in the mix.

everything was very flickery from what I saw.
If you saw the other posts in this topic I've encountered weirdness where some monitors have different tints too.  Basically, none of that happens on a real TV.  I DO try to minimize eye strain on an LCD but it's a challenge.  Different LCD monitors will have different true refresh rates.

I thought either this was intended or some rare occurrence until I tried recording it with FRAPS then watched the footage.
Since I'm time-sharing objects and colors every other frame use ALT-P in Stella to enable the phosphor effect.

the score seems to reset and repeat, which I assume wasn't intended.
Very much intended but never explained.  In my work in progress builds I frequently use the score to debug.  Basically, "set score = 0" to clear out the score and then "score = score + [whatever]" to show the value you want on-screen.

I like the little car-blocks moving at the bottom
Random Terrain gave me some feedback that it was distracting.  Removed them in the current build.  Thanks for the thumbs up on the buildings, though ^_^

I'd say break off those groups of four monsters so that the monsters move individually.
The 2600 gives us 2 sprites.  Either I can have 8 monsters (4 to a sprite) marching in a straight column or only 2 that can split up.  It's a tradeoff for sure.  I chose more on-screen enemies than maneuverability.  In any case, I haven't programmed in the AI yet.  Hopefully I can figure out how to diversify movement.

Also, some kind of boss after a while would be neat as well.
Definitely!  I plan on a boss at the end of each level.  After the boss is crushed the speed goes up.

Thanks for the other input I missed here - definitely considering your opinions (true gold for developers!).  I just picked the ones that seemed closer to misunderstandings.

[stephena]

theloon, on Sat Feb 9, 2013 5:01 PM, said:

stephena is the maintainer of Stella.  He is a very active developer and actually cares about the quality - and thus the benefit of his work.  Trouble is, end users like us generally smack talk about bugs and issues instead of reporting them correctly.

Yes, sorry if I didn't make it clear who I was and why I was requesting bug reports.

Also sorry if the initial response was terse.  It's just that I'm trying to work on Stella for the past few days, and I keep getting sidetracked by having to snowblow my yard (just finished clearing 30x75 lot about 1.5' high).  Grumble, grumble ...

[Cybearg]

Sorry for the mess-ups and gaffes. Just trying to help! :I

I know that there's player 0 and player 1 sprites there. Then you've got the monsters and one or two other enemies that go across the screen, so as you say, it makes sense that you're short. I'd definitely say split the one group of four into two groups of two if you can, especially if they all have a shared hitbox. It's almost impossible to miss them since the missiles go right through and hit the ones behind them, but if you have two enemies that move separately, the player has to strategize as to which one to hit first. This is especially true since the risk isn't so much to the player getting hit, since there's infinite respawn so long as there's a player 1 just chilling at the bottom of the screen, so any way you can make it more challenging for the player to get all enemies destroyed before getting past the player is a good thing (within reason of course).

And it's no problem, stephena! I didn't realize that there were developers around, and it was entirely from my own ignorance, anyway, so don't worry on it.

[KevinMos3]

theloon, on Sat Feb 9, 2013 5:37 PM, said:

I like the little car-blocks moving at the bottom
Random Terrain gave me some feedback that it was distracting.  Removed them in the current build.  Thanks for the thumbs up on the buildings, though ^_^

I liked them too.  Nice parallax effect.  I hope you add them back at some point.

[Cybearg]

If they seem annoying, maybe tone down the color. Make them a light grey instead of white so that they don't pop from the background so much.

[theloon]

I'll see if I can tone down - but keep the extra layer of paralax.  It was one of the things draining on CPU time.  When all the other features are back in we'll see if it can be put back.

Well, I slacked all this weekend.  Let's see if I can crank dat keyboard and make up for lost time

[theloon]

Forgot to mention this.  I don't know the term for it.. er, live blogging?  Dunno.  In my Lakavision Limited blog I'm making an entry every hour this night until I can't take it any more.  This could mean until the morning of Monday.  How long can I stay focused?  How much sleep does one need for a work-day?  Let's find out!

http://www.atariage....-coding-frenzy/