Jump to content
MrTrust

My First Game Project: Torpedo Torpor

Recommended Posts

Posted (edited)

Not sure if I'm posting this in the right place; maybe a mod can help me move it if not.  Anyway, I thought I would document my progress on my first Atari game project.  So far I have very, very little to show for my efforts, but I just starting learning bB today, so it took me a couple of hours to get this basic little germ started.  The hope is that keeping a log of my progress will spur me to keep working on the game and not get too distracted. 

 

Anyway, the basic idea is you are defending Integalactic Federation' giant force field from Kamizake alien starships.  Your laser batteries will take out care of incoming enemy fighters, but in order to destroy the approaching motherships, you will need to rely on your torpedoes.  These are remotely controlled and detonated, and you will need to be accurate with that detonate button, as the enemy's own force fields will redirect unexploded torpedoes by harmlessly.  There's another catch; your ship's computer doesn't multitask, so until your torpedo attack is resolved, your ship will be a sitting duck.

 

The game idea is inspired by a couple of my favorite Atari games: Galaxian, and Stampede.  I've always preferred the former to its infamous sequel because of the single shot restriction, forcing you to choose your shots carefully.  The latter would just be a shmup on a horse if not for the genius mechanic of using your player sprite to interdict the enemy, uh, cows.  So, I wanted to come up with something where you really had to pay close attention to both your player and your projectiles, and having the added reflex test of having to manually detonate your shots should help create some intense gameplay.

 

I'm doing the game in bB right now because, well, I don't know jack about 6502 Assembly, I'm not a programmer, and I've never designed an original game before, so I need training wheels at some stage of the process.  Second, from what I've played of other games that use it, the standard bB kernel should be up to the task, but I may still have some real challenge getting all the features I want implemented.  My hope is that just getting some tangible results will help spur me on to hit the books on ASM hard enough to write my own kernel, and thrn I can just port the game logic over, but at the very least, I'll have something.

 

So, Day 1, what have I got?  Well, I got the player ship and one enemy mothership on the screen, with some dirt simple animation on the latter.  The torpedos are firing and detonating, and you can score a point for nailing an enemy ship.  If the enemy gets to the right side of the screen, your score resets to zero.  Annnnd... That's it.  Not much to show, I know, and the enemy ships are very wonky right now, but hopefully I will make more progress in my next session, not having to set everything up, and maybe doing a little less groping witht the syntax and learning statements.

 

Features to be added, I think in order:

 

- Laser Batteries.  These will be mapped to right on the joystick.  I believe I'm just going to recycle Player0 for this.  Just bump the player ship forward and make it a straight line.  If I do it in one or two iterations of the main loop, the effect should look okay.  It's a short range weapon.

- Multiple motherships.  Looks like with the standard kernel, I only get two player objects, so I guess I'm going to have to figure out how to flicker the player in more than one coordinate.  Hoping to have up to three on screen at once.

- Enemy fighters.  Guess I'm just going to use the missiles for this.  Don't believe I would want more than two, that would make 1 - 5 targets at any given time.

- Get the speed right.  The idea is the motherships will advance slowly, continually dispatching fast moving fighters which you have to move vertically to get with your lasers, once you get an opening, it's time to let a torpedo rip.  The point is to balance between being in the right position and taking the right shots.

- Add the force field.  Easy enough.  Guess I'll just use playfield and stick it behind the player.  Any time a missile or UFO collides with it, I'll cycle the Player0 color to keep track of remaining hits until it explodes.

- Waves.  Gotta' increase the speed at some point.

- Scoring system.  Should be pretty straightforward except points for hitting a mothership with a torpedo should decrease as it moves further to the left, thus tempting the player to take longer, riskier shots.

- Sound.  Looks like I'll need a laser noise, a torpedo launch noise, an explosion and a game over ditty at minimum

- Graphics.  Make them not look like hot garbage.

- Pre-Start and Game Over loops.  Can't just have chaos.

- Playfield obstacles to guide torpedoes around

- Something for the difficulty switches to do.

 

So what do you guys think of the idea?  Any suggestions, critiques, forseeable challenges?  I'm just flying by the seat of my pants here, so any knowledge or feedback anyone wants to share couldn't possibly hurt at this point.  I hope to maybe make some progress tomorrow or at least someyime this week.

 

Topedo.bas.bin

Edited by MrTrust
  • Like 4

Share this post


Link to post
Share on other sites

Okay, Day 2.  So far, so good.  Got three line items from my list up and running.  The laser batteries are now operative by pushing right on the joystick, and we have more enemy targets.   The collision detection should be working okay, and your ship will take damage as enemies cross your y plane before the score resets.  Hitting a ship with a torpedo is 10 points, and with lasers is 1 point.  Graphics have been changed to be a little less awful on the eyes.  Flicker is pretty brutal; will have to see if there's any way to minimize that down the line.  It's now starting to resemble the beginnings of a game.

 

Had a frustrating moment where an accidental erasure of an indent totally crippled my whole program and it took a little while to track down the error, but other than that, much smoother sailing.  Other than dumb operator error like misplacing variables and whatnot, the only real snag I hit was with the collision detection.  With juggling the second Player 1 sprite, you can't just use the collision function because only one valid target is on the screen at any given time.  I came up with two different methods.  For the torpedo explosion, I'm repositioning the second sprite three times in the subroutine and using the collision detection each time.  It works, but it appears I have to redraw the whole screen and define player colors for each check, which seems ham-fisted and slow, even though it looks okay to my eyes.

 

The lasers were a different story, since to fire it I'm redrawing the screen three times to move the Player 0 sprite to create the animation, I would need to check collision three times against three targets, that's 9 redraw calls every time you shoot the laser.  I can only imagine that would be a huge mess, visually.  So instead, I just check the variables for the coordinates of the sprites directly against each other, but adding and subtracting to account for the vertical and horizontal size of the sprite itself so you don't have to be pixel perfect.  This was a pain in the ass because it requires complex conditional statements, and I needed to change a variable with one statement to reset the ship's position, but need to compare the unchanged variable in the next statement.  My brain wants to be able to check a conditional and then execute two or three instructions all within the same statement.  Oh, well; figured it out anyway, and it seems to work okay.  Little choppy looking, but it might be able to be cleaned up later.

 

Not a terrible start, I don't think.  Not much to the gameplay at present, but the skeleton is at least there now.  I need to incorporate the enemy fighters next, and also get the all the targets moving in something less predictable that just a straight left right trajectory.  I get the feeling this is going to be the main challenge, as I've only got 10 variables and 1.4k left, and getting all that going is going to be the most complex logic in the game, so I may need to start figuring out how to optimize the code before I get all the main game elements in place.  I would prefer to be able to get it all up and running with my caveman methods and then refine everything from there.

 

I'm really enjoying the convenience of having bB and a modern IDE to work with, as it makes getting the bones of the game going a snap, and I can look at the compiled ASM and get a little glimpse as to what's going on under the hood, but I also do wish I'd learned this stuff a lot earlier, because I feel a lot like a monkey in a zoo that's been given a hand tool to figure out, and I wish I understood the way the machine works better.  Anyway, hopefully today's revision will get the idea across better than my last post.  Again, any feedback, advice, criticism would be much appreciated.

 

 

Topedo-5-31-21.bas.bin

  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)
6 hours ago, MrTrust said:

Again, any feedback, advice, criticism would be much appreciated

a PAL60 colors version would be nice, maybe not in this early state of the development, but you should take a look at the color constants on @Random Terrain's webpage (and maybe use them):

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#color_constants_ntsc_pal60

 

Edited by Al_Nafuur
  • Thanks 1

Share this post


Link to post
Share on other sites
On 5/31/2021 at 8:26 PM, Al_Nafuur said:

a PAL60 colors version would be nice, maybe not in this early state of the development, but you should take a look at the color constants on @Random Terrain's webpage (and maybe use them):

 

Ah, yes, that is definitely going on the to-do list.  I will probably a little bit on that until I get the graphics more finalized, since I'm not sure if those are the colors I will end up using, and at any rate, I might ultimately have to eliminate some color switching to save some ROM.  Hate to do it, but I am running out, and I've got a looooong way to go.

 

Day 3 was continued progress.  I think we're at the bare minimum requirements to call this thing a game at this point.  Enemy fighters are in, and the attacks are now bifurcated.  Only torpedoes will destroy enemy motherships, and only lasers will destroy enemy fighters.  The game speed it a little closer to what it should be at least to start with.  The Game Over loop is in place; joystick to start and to reset after game over.  No reset switch yet until I can free up a variable to debounce it.  Oh, yeah, I ran out of RAM.  Not super worried, I can put in bit operations and free up maybe 5 variables, and I might be able to make use of the temporary variables.  Just need to look over the documentation harder.  Fingers crossed, I should be able to free up some more space.

 

Of course, that's going to slow things down, as I'll probably need a day or two just to rewrite the code and tidy everything up.  Also, I will probably go back and see if I can streamline the torpedo explosion subroutine and cut down the number of instructions and redraws there to free up some more ROM.  I really should take care of that before I work on adding any more features in.  I haven't even started messing around with sound yet.  Using both missiles for each fighter is expensive, so I might have to scrap that and just use squares and call them something else, but I'm hoping to avoid that.

 

The two main challenges I'm going to have from here are A) getting the fighters to launch from the motherships themselves rather than just the right edge of the screen, and being able to control the speed of the incoming targets.  Just advancing the sprite at x number of pixels makes the game way too fast to start out with, so what I've got going is two variables (well, actually four, but hopefully only two in the end) that I'm using to count the loops.  One goes from 0 to 5, and the other goes from 1 to 4.  So, I can advance a ship on 0 for the first variable, or 1 on the other if I want it to go faster, or have it only go when the first is on 0 and the second is on 3, or when the total of the two is nine, or on 0 AND when the total of the two is 9, etc.  My thinking is, as the difficulty ramps up, I will have enough options that I can just make a subroutine where the conditionals are more relaxed, and the ships advance faster and faster without having to write too much additional code, though figuring out all the intervals feels like it will take more understanding of numbers than I have naturally.

 

If there's anyone reading that knows what they're doing, is how you do it when you're moving things around the screen at varying speeds, or is this a dumb way of doing it?  It feels intuitively correct, but then again, so does everything that kinda' works when you don't know what you're doing.  At any rate, this will probably be all I have new to show for a little bit, as the next phase will be all internal optimization and, theoretically, won't change how the game looks or plays.  In the meantime, I think the core gameplay conceit is at least present now.  The next step after the housekeeping phase will be to get the game more challenging and less predictable.  Very much enjoying the process up to now.

 

 

Torpedo-6-1-21.bas.bin

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, MrTrust said:

If there's anyone reading that knows what they're doing, is how you do it when you're moving things around the screen at varying speeds, or is this a dumb way of doing it?

Yeah, I just use counters when I don't want something to move every frame, but it's arguable that I know what I'm doing. You could look into using fixed point math if you can free up some variables.

 

1 hour ago, MrTrust said:

The Game Over loop is in place; joystick to start and to reset after game over.  No reset switch yet until I can free up a variable to debounce it.

I don't usually worry about debouncing the reset switch, but if you want to, you can recycle one of the variables from your main loop. I'd think about debouncing the fire button too. Now you immediately launch a torpedo when you start a new game.

  • Thanks 1

Share this post


Link to post
Share on other sites
9 hours ago, KaeruYojimbo said:

I don't usually worry about debouncing the reset switch, but if you want to, you can recycle one of the variables from your main loop. I'd think about debouncing the fire button too. Now you immediately launch a torpedo when you start a new game.

 

Yeah, I don't know what happened there.  The fire button is debounced, but I must not have the check in the right place or something.  I'm going to need to rewrite that variable anyway, so that'll be a priority.  I don't know; when I added the reset switch in there without debouncing it, I had to hit it a few times to make it work, especially if resetting mid-game.  I tried piggy-backing off of one of the frame counters to see if that would work, but no joy.  Don't think I'll need to worry about it, though, since it looks like I can cram 7 more booleans into the joystick debouncing variable anyway, and that should be enough for my purposes.

 

9 hours ago, KaeruYojimbo said:

Yeah, I just use counters when I don't want something to move every frame, but it's arguable that I know what I'm doing. You could look into using fixed point math if you can free up some variables.

 

I think I will need to use fixed point math, if for no other reason than I want to be able to use odd/even checks, which I think I can do it that way.  Divide the variable by 2, and check if the second byte is zero should do it.  Of course, I'm a little confused as to how that functionality works.  I need two variables for it, right?  And I can reassign either one like usual, or do I need an alias and can only refer to that?  It's kind of hard to quickly write little testers for these things, and I couldn't find a debugger in vbB that would let you step through and see what state all the variables are in at any time.  I suppose I could do it with Stella if I can figure out where the right memory registers are.  

Share this post


Link to post
Share on other sites

Days 4 & 5: Not too much exciting happening on these days.  I went through and optimized to the best of my ability.  Freed up a lot of memory and made the code more readable and editable, relatively speaking.  Made less actual progress on the game since I spent a lot of the time looking over different resources to try and figure out more about how the actual assembly works, thinking I would need to incorporate some inline ASM into the game to make it all work.  Spent some time learning to convert hex and binary to decimal and vice versa.  So far, I've been able to get done what I need done with my ham-fisted methods, but I believe I will need to go deeper before I'm done with this project.  One challenge I keep running into is that much of what people write about programming for these old systems, even when geared toward beginners, tends to implicitly assume a level of knowledge that likely isn't there.  Maybe if I get better, I might use this experience to write a guide of my own.

 

Day 6: Okay, now there's a little meat on the bones.  We've got the fighters launching from the motherships and responding to the player's movements.  The damage cycle is now more visually apparent, and the reset switch is in there.  The game now ramps up difficulty as you play.  There are a few glitches when resetting as some of the variables don't seem to clear correctly on reset, but that should be relatively easy to fix, and probably the most obvious place to add in some assembly code.  An extra reset or two should take care of it for the time being.  Getting everything moving around correctly was a bitch.  My own novice stupidity, since I kept writing code like the kernel will only draw a sprite or missile if you tell it to instead of masking them, so that was most of a day lost to ignorance.  Nevertheless, we're getting there.

 

Next thing is to add the sound.  I've got three variables and a bit left in RAM, and 6 bucks & change left of ROM.  I really would like to add a starfield and have the destroyed motherships leave behind debris that blocks the torpedoes, but for the time being, I'm going to call those stretch goals as that might be really pushing the practical limits of what the kernel can do.  I'm contemplating having the enemy ships fire at the player rather than simply crashing into the force field, but that'll eat up two of my three variables, so we'll have to see how feasible that is in the end.  The immediate goals are to get sound up and running, work out a PAL 60 conversion, and then put in a real scoring system.  My hope is that these will be easier and less time consuming than the other steps have been, but every time I feel like something in programming is simple, it turns out it's actually me that is.

 

Once that's done, I think it will be a matter of tightening everything up and fixing bugs, then I'll go back and reassess what extra features I have memory left for.  I feel like this iteration is a substantial improvement, and the picture is starting to come together.  Thanks to everyone for the feedback so far; always appreciated.

Torpedo-6-8-21.bas.bin

Share this post


Link to post
Share on other sites

Days 9 & 10: Cowabunga.  I'm going to go ahead and say I have version 1.0 of the game now.  Sound is in.  Enemy randomization has been fixed.  The scoring system is in place, and I think (hope!) the glitching has been taken care of.

 

New feature: Torpedo Team Play!  Setting the left difficulty switch to A will enable the second joystick to take over the torpedo controls as ship's gunner.  First player can move and activate the lasers as normal.  Obviously, this mode will significantly reduce the challenge of the game and is intended for co-op play with kids or unskilled players.  Setting left difficulty to A and right difficulty to A will allow for 2nd player torpedo control, but player one will not be able to move during a torpedo fire mission.  This mode will require more cooperation between the pilot and gunner, or use a dual stick control setup for an enhanced challenge.

 

From here, I think it will mostly be a matter of tweaking and cleaning things up, fixing bugs, etc.  PAL 60 version is next on the agenda.  Just about out of ROM at this point, but I miiiiight be able to sequeeze in a Game Over music or high score save.  We'll see.  Meantime, I hope people enjoy the game so far and let me know what you think, good bad or indifferent.  Fixing things up from here may depend on feedback.  

Torpedo-6-10-21.bas.bin

  • Like 1

Share this post


Link to post
Share on other sites

That's pretty nice for less that 2 weeks works I like the graphics and sound.

The gameplay kind of reminds me a little of missile command... but flipped it on its side.

It's pretty amazing what this system is capable of.  I do agree, a game over screen, might be a good addition if you can fit it in.

 

I personally have moderate hobby/indie level experience programming casual games, in Flash, C#, Python and a little C++,  and trying to learn Assembly now.  But I think I may shift to bB as a starting point for Atari games.   I am learning that having experience in other languages doesn't

really help a whole lot when it comes to learning assembly.  Sure I am comfortable with hex/binary, and basic bit shifting, along with the

general concepts of loops, variables, sub-routines, etc.

 

But the 2600 is SO MUCH different, then every other game engine, or language I ever touched.   Using bitmap sprites, and X/Y screen cords, as well as some sort of screen buffering/page flipping etc, is just common place in all modern game engines/frameworks.  So even for someone with some programming experience, ASM programming, and working with the TIA registers, and counting processor cycles and scanlines. is a new thing to me.   Then having to fit all that into 4K ROM...  you have to love have the challenge, this puzzle presents to you as a developer.

 

Over all, great job, I think utilizing Bb as a starting point, and adding some inline assembly where you can, is the a great approach, and most likely how I am going to approach it as well.

 

Good luck, on finalizing this game off, and all your future games.

 

 

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I gave this a try, and it's pretty good! The graphics and sounds are good, and the control scheme is clever. I would say that the challenge level seems to start out a bit too high. I personally would like to start out with less enemy ships, and add more as you go along to ramp the difficulty. Maybe others would feel differently though. I'm personally wanting to try out the two-player variant when I get a chance.

 

Unfortunately I got an "invalid instruction" error in Stella a few times when trying it out. It always seemed to be right after firing the laser when it happened, but only once in a while. It wasn't obvious to me what could be causing it.

 

2074595695_ScreenShot2021-06-11at10_28_21AM.thumb.png.8852a41638881e784864a51391e98b93.png

  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks so much for the kind words, guys.  Those of you with unkind words, don't be bashful.

 

21 hours ago, method72 said:

I personally have moderate hobby/indie level experience programming casual games, in Flash, C#, Python and a little C++,  and trying to learn Assembly now.  But I think I may shift to bB as a starting point for Atari games.   I am learning that having experience in other languages doesn't

really help a whole lot when it comes to learning assembly.  Sure I am comfortable with hex/binary, and basic bit shifting, along with the

general concepts of loops, variables, sub-routines, etc.

 

Well then, certainly bB will be a snap for you to get into.  Being able to go from a standing start to a (mostly) functional game in 10 days speaks to the awesome power of the language and the tools.  Hell, just being able to click and button and instantly compile and test your program is light years' advantage from what people would have had at the time, right?  I would definitely recommend it if you just want to bite the bullet and get a 2600 game done.  Unfortunately, if you run into a real bug, like apparently I have, it'll be really hard to fix, and there's a general feeling of cooking from a meal kit rather than making your own recipe, but if none of that bothers you, it's definitely a really fun toy.

 

21 hours ago, method72 said:

But the 2600 is SO MUCH different, then every other game engine, or language I ever touched.   Using bitmap sprites, and X/Y screen cords, as well as some sort of screen buffering/page flipping etc, is just common place in all modern game engines/frameworks.  So even for someone with some programming experience, ASM programming, and working with the TIA registers, and counting processor cycles and scanlines. is a new thing to me.

 

Yeah, I haven't abandoned my initial ambition of learning ASM enough to port this game to it and, say, reduce the flicker, which I know is possible if I get down to the kernel level, but I think for my first real 6502 project, I'll try something on the 5200 or 8-bits instead.  I can sort of wrap my head around how 6502 works, but the whole one-scanline-at-a-time thing is a little much for me at the moment.

 

7 hours ago, Karl G said:

I would say that the challenge level seems to start out a bit too high. I personally would like to start out with less enemy ships, and add more as you go along to ramp the difficulty. Maybe others would feel differently though. I'm personally wanting to try out the two-player variant when I get a chance.

 

I'm running of fumes as far as ROM goes, so I'm not quite sure I can swing that, but I made the fighter launches more intermittent and the movements a little more aggressive, maybe that will smooth out the difficulty.  Since there's not a true two player mode, it's kind of part of the design to get one player in and out of a game quickly so it can pass back and forth faster.

 

7 hours ago, Karl G said:

Unfortunately I got an "invalid instruction" error in Stella a few times when trying it out. It always seemed to be right after firing the laser when it happened, but only once in a while. It wasn't obvious to me what could be causing it.

 

Nor to me.  I think I managed to replicate it; it happens every 3rd new game, and the lasers will simply reset the game, and the detonation will give you the invalid instruction error.  I don't know what's going on here.  It's not like anything changes if you go through the game start loop over and over.  I went through both subroutines to see if I could isolate the code that was causing it.  No joy.  I cleared all the RAM I possibly could and all the TIA registers at the beginning of the program just to be sure.  No good.  Reboot seems to take care of it and I don't see that it messed up my RNG appreciably, so let's see if it works any better from here, but it seems like something's getting "stuck" in memory somewhere that it shouldn't.

Torpedo-6-11-21.bas.bin

  • Like 1

Share this post


Link to post
Share on other sites

If you want to share your source, either publicly or privately, I would be willing to see if I can figure it out. 

  • Thanks 1

Share this post


Link to post
Share on other sites

Okay, thanks to the technical assistance of @Karl G, version 1.2 of the game should now be bug-free, and no need to worry about the RNG being messed up.  The long-promised PAL 60 version is here, and doing it was actually quite a boon, since I had to resort to a data table to cycle the force field colors rather than relying on simple addition, but fewer calculations freed up some ROM, which allowed me to add in the extra check for using the player 1 fire button during the team play modes rather than joystick right.  Then, I scrimped and I scrimped and I scrimped some more and freed up juuuuuuuuuuuust enough room for a novice difficulty setting.  Use the select switch at the game start screen to switch to the novice difficulty setting, indicated by a yellow force field prior to game start.

 

Other than that, just cleaning up some small glitches I happened to notice during testing.  So, there we are, I am literally at exactly zero bytes of ROM and I don't think I can stuff anything else into the game at this point, so other than tweaking the difficulty balance from here or fixing any bugs that might remain, I think I'm going to have to say we're just about finalized.  Next on the agenda is the manual and a few other goodies to go with the "official" "release".  Should be a much easier project than the game itself was and a nice break.  In the meantime, thanks to everyone who's given the game a go thus far.  Please let me know if you have comments/questions/problems.  I can't test the game on real PAL hardware, so if anyone has that ability and would like to let me know how it works, that would be great.  

TorpedoV1-2.bas.bin TorpedoV1-2PAL60.bas.bin

  • Like 2

Share this post


Link to post
Share on other sites

Still have a couple of kinks to be worked out, but I'm going to continue the break for another day or two.  Sometimes it helps to step away for a bit and come back to a problem with a fresh set of eyes.  In the meantime, the manual cover is mostly done save some scaling and touchups.  I would love to have gotten the chance to actually paint an illustration to really give it that early 80s 2600 look, but I'm not really good enough to do that without a lot of effort, and there's only so much free time.  I feel like we have a mid-to-late 80s vibe that kind of works, though, right down to the bad composition and goofy mish-mash of fonts.  Hopefully when it's finished it will make a nice companion piece for the final version of the game.

 

 

ttcover.thumb.png.0a428d75afee61fe0704d17b716a8c17.png

  • Like 4

Share this post


Link to post
Share on other sites

Well, I wish I could have gotten this whole thing done in 2 weeks, but it looks like I've run a little long.  I think I have the balance dialed in to where it should be at this point.  I've noticed there may be some lucky games where there are long periods where there are no fighter launches, but such is the way with random numbers, I guess.  Not that the game really needs it, but here's the manual for those who like the complete retro experience.

TorpedoV1-3PAL60.bas.bin TorpedoV1-3NTSC.bas.bin TTManual.pdf

  • Like 6

Share this post


Link to post
Share on other sites
Posted (edited)

ZeroPage Homebrew is playing Torpedo Torpor on tomorrow's (Fri Jun 25, 2021) stream LIVE on Twitch at 12PM PT | 3PM ET | 7PM GMT! Hope everyone can watch!

 

Games:

After Dark

(WATCH AT 1080P60 FOR FULL QUALITY!)

 

229329984_20210625-LetsPlay-AfterDark.thumb.jpg.8e8d6767b45e5ac13737552d7ee19ff1.jpg

 

Edited by ZeroPage Homebrew
  • Like 2

Share this post


Link to post
Share on other sites
5 minutes ago, ZeroPage Homebrew said:

ZeroPage Homebrew is playing Torpedo Torpor on tomorrow's (Fri Jun 25, 2021) stream LIVE on Twitch at 12PM PT | 3PM ET | 7PM GMT! Hope everyone can watch!

 

Games:

After Dark

  • Super Cobra Arcade (2017) by John Champeau @johnnywc

1752719746_20210625-LetsPlay.thumb.jpg.c6e54088fa26ed12c66e8dfd5e70b2ec.jpg

 

229329984_20210625-LetsPlay-AfterDark.thumb.jpg.8e8d6767b45e5ac13737552d7ee19ff1.jpg

I really wish I could but that timeframe is 10am in the morning in the middle of my work so I'm not able to participate or watch at that time. 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, -^CrossBow^- said:

I really wish I could but that timeframe is 10am in the morning in the middle of my work so I'm not able to participate or watch at that time. 

No problem, you can catch it in the archive on YouTube the next day. 🙂

 

- James

Share this post


Link to post
Share on other sites
5 hours ago, ZeroPage Homebrew said:

ZeroPage Homebrew is playing Torpedo Torpor on tomorrow's (Fri Jun 25, 2021) stream LIVE on Twitch at 12PM PT | 3PM ET | 7PM GMT! Hope everyone can watch!

 

Oh, man, that's unexpected, but awesome.  I will be at work, but I'll try my best to tune in.  I was going to roll this once I got more time, but if you can break 20,000 on normal difficulty, you'll be the first Certified Far Orbit Defense Armada Torpedo Ace, and I'll try and get the patch ready to show by weekend's end.

 

Same challenge goes out to all comers (while supplies last).

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, MrTrust said:

 

Oh, man, that's unexpected, but awesome.  I will be at work, but I'll try my best to tune in.  I was going to roll this once I got more time, but if you can break 20,000 on normal difficulty, you'll be the first Certified Far Orbit Defense Armada Torpedo Ace, and I'll try and get the patch ready to show by weekend's end.

 

Same challenge goes out to all comers (while supplies last).

Challenge accepted! I'll do my best to earn the CFODATA patch. 🙂

 

Hopefully you'll be able to tune in (secretly at work) to answer questions in the chat about your game!

 

- James

Share this post


Link to post
Share on other sites
3 hours ago, MrTrust said:

I was going to roll this once I got more time, but if you can break 20,000 on normal difficulty, you'll be the first Certified Far Orbit Defense Armada Torpedo Ace

Is it normal difficulty when the wall is blue or yellow? I'm rather far from 20000 either way, but would still like to know.

Share this post


Link to post
Share on other sites
6 hours ago, bluejay said:

Is it normal difficulty when the wall is blue or yellow? I'm rather far from 20000 either way, but would still like to know.

 

*sob* and after all that trouble I went to to write a manual...  JK, it's blue.

 

If it makes you feel any better, I've not actually done it myself.  I got 18k and change once, but the difficulty has since been backed off a bit, so I think it's probably stiff but doable.

  • Like 1

Share this post


Link to post
Share on other sites
On 6/17/2021 at 4:25 PM, MrTrust said:

Well, I wish I could have gotten this whole thing done in 2 weeks, but it looks like I've run a little long.  I think I have the balance dialed in to where it should be at this point.  I've noticed there may be some lucky games where there are long periods where there are no fighter launches, but such is the way with random numbers, I guess.  Not that the game really needs it, but here's the manual for those who like the complete retro experience.

TorpedoV1-3PAL60.bas.bin 4 kB · 17 downloads TorpedoV1-3NTSC.bas.bin 4 kB · 42 downloads TTManual.pdf 1.22 MB · 31 downloads

Only got to play this on my phone but liked what I've played so far!

 

I will need to check this out on PC to play it with more popular controls.

  • Like 1

Share this post


Link to post
Share on other sites

Just tested that on Javatari and love it! I’ll definitely bring the rom to some of my devices hoping it will work fine as well… thank you and congratulations!

Share this post


Link to post
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...