Jump to content
IGNORED

Incoming! 2008 (aka Greetings from Vaporware Land)


Ben_Larson
 Share

Recommended Posts

(I published something about this on Stellalist but I don't think anyone saw it yet. :) )

 

After many years of being sidetracked doing other stuff (getting married, moving, grad school, getting java certified, taking up other hobbies, getting sidetracked 'playing' rather than programming), I decided to get back to do some atari 2600 programming and finally finish my ancient and dusty game 'Incoming!' once and for all. I'm committed to finishing it this time around.

 

So without further ado, here's the latest beta version. I've added moving clouds, reworked the tank graphics to give it a little more cartoony feel, made the wind more realistic (i.e. using a real X-vector deceleration now instead of just modifying the initial X vector), fixed some bugs, etc.

 

incom.jpg

 

Personally I think the wind is a bit too strong now, but you guys can tell me what you think. The computer AI isn't all that sophisticated and seems to struggle now in high wind / high elevation situations...

 

Ben

 

P.S. also, sorry for no PAL version yet. i'm sorry, es tut mir leid, lo siento, and je suis désolée. :)

Incoming1.0Beta6_NTSC.bin

Incoming1_0Beta6_asm.txt

Edited by Ben_Larson
Link to comment
Share on other sites

  • 2 weeks later...

I absolutely LOVE this game. There's a lot of strategy involved in precisely hitting your target. I like the improvements over the previous game (love the clouds! The tanks look better also.) My only complaint is that maybe the computer opponent is too good. Sometimes he fires first, and hits me right off the bat. But this is only a minor complaint, and only happens every once in a while. I'm glad to see this game ressurected. Keep up the good work! :) :thumbsup:

Link to comment
Share on other sites

I played it only briefly on an emulator (the controls of which I've not mastered), but also think that it's a great game. It's defintely in the spirit of the classics with shades of a head-to-head Human Cannonball.

 

I agree that the computer is too good. Maybe a bit more randomness in his shots?

 

Probably a dumb question, but does it do a 2 player mode? If so, do you have to alternate shots or shoot as often/quickly as you can?

Link to comment
Share on other sites

My only complaint is that maybe the computer opponent is too good. Sometimes he fires first, and hits me right off the bat.

 

The computer is very good in certain situations. If you're below the computer (especially if the distance is short), he's almost guaranteed to hit you. If it's a level shot with low elevation and no wind, the computer is also pretty good. Where he kinda sucks is high-elevation shots with wind. That's what I'm still working on. After I tackle that I suppose maybe I could add some randomness to the initial power calculation to prevent situations like you describe...

 

Probably a dumb question, but does it do a 2 player mode? If so, do you have to alternate shots or shoot as often/quickly as you can?

 

Yea there's 2 player mode. Hold down select until the number on the left goes to '2'. Shots do alternate, and there's no time limit or anything when aiming.

 

...

 

All in all, good to hear you guys like it. Hopefully I'll be done here pretty shortly. I keep hitting the 4k limit so I've been spending a lot of time 'trimming the fat' to try to squeeze in new stuff, like the clouds and the AI improvements I mentioned above.

 

Ben

Link to comment
Share on other sites

  • 2 weeks later...

New version everybody. I think this *might* be the 'official' v1.0 release version barring any new bugs found...

 

There's a change list at the top of the source code if you want to see exactly what changed. But in summary: spent a long time optimizing stuff to squeeze out more ROM space, fixed some math bugs, improved the AI some, added a new 'random terrain roughness' mode, and made a small graphical change to the clouds. Enjoy!...and feel free to comment/criticize/scathingly denounce... ;)

 

Ben

Incoming1.0RC1_NTSC.asm.txt

Incoming1.0RC1_NTSC.bin

Link to comment
Share on other sites

and feel free to comment/criticize/scathingly denounce

:twisted:

The lack of sound or any feedback when a tank is hit is a huge, huge flaw. In my opinion, of course. If you have to cut the other sounds or the clouds to get an explosion sound and graphical effect, so be it.

 

And I think the default AI is too hard. Too many one-shot kills. Here's an idea: leave the default AI as-is, but always give the player the first shot. It feels way too cheap when the terrain is generated, the tanks drop down, and the first thing that happens is the computer shoots and you're dead.

 

:)

 

As mentioned above, I love this game and I've been waiting and hoping that it would be completed! :thumbsup:

Link to comment
Share on other sites

Very cool game. The AI does seem a little too "dead-on" sometimes. It'd be nice if it was a little stupider on its first shot. Just like a human player. :)

 

And I agree with Bob... the tanks need to go "boom". :D

 

A minor quibble (although it may be nothing can be done about it)... it looks a little strange sometimes when a tank is sitting on just one or two pixels. Maybe if a tank hangs over the terrain by a certain amount, it should fall down to the next block. I don't know if that could result in the tank tumbling down a hill - but that might be cool too.

 

post-2641-1201421040_thumb.png

Link to comment
Share on other sites

I agree about the computer AI being too clever. It normally only takes 1 miss to get you nailed (unless there's a very large difference between vertical positions or obstructing playfield).

 

There's definately room for optimization. Just by cutting out many of the player-specific branches (by reusing an index register), I'd freed 90 bytes. I'm sure that there's more where that came from. I threw in a couple of el-cheapo sound effects...but the shots hitting terrain didn't turn out quite right.

Incidentally, Ram could probably be organized a bit better so that there's less waste...pushing 1-frame only stuff to the end so the stack can reuse it, or to hold results of frequent checks that require a few bytes of set up overhead. If you can save even 1 byte, that would provide a counter for better sound effects :)

 

BTW there's a slight timing issue as well during the tank destruction that throws off the scanline count...could be during reinitialization for the next round?

 

Double-semicolons used for areas that I edited.

Inc2.zip

Link to comment
Share on other sites

Wow thanks for all the feedback guys. I was beginning to sorta think nobody really cared... ;)

 

Nukey I feel embarassed that you actually read though my crappy source code. :D But anyway, I built your binary and it appears to work fine except for a small player-graphics graphical glitch right before the scores are displayed (in z26 at least). Maybe that's because I had to replace your LAXs with LDA and LDX since my version of DASM doesn't seem to recognize the illegal opcodes. :( I'll definitely try to merge your optimizations into the baseline though.

 

Also, I'm aware of the scanline count going off a bit after a tank gets hit - that happens when the playfield is being generated (takes a while to do), so the timing to keep a stable picture isn't perfect there...but it's only 1 scanline and it appears to work fine on a real TV.

 

And I agree with Bob... the tanks need to go "boom".

I agree with all of you that it needs some sort of tank exposion sound effect, I just didn't put it in cause ROM space was so low. Actually...I sorta knew as I was posting the RC1 binary that I was gonna 'get it' for this. :)

 

If you have to cut the other sounds or the clouds to get an explosion sound and graphical effect, so be it.

With regards to an actual explosion on screen...I don't think that's gonna happen unfortunately. See the way I'm displaying the player graphics on-screen is very ROM-inefficient but very fast speed-wise (classic computer science speed-vs.-memory tradeoff). I did it that way in order to have time to display the full width asymmetrical playfield, 2 single-line resolution players, the double-line resolution ball, and also have time to do the playfield and background color changes. The only way I think having an explosion on-screen would work would be to write another kernel to use during the explosion sequence which doesn't display the ball and I don't think there's ROM space for that. Although I suppose there's the possibility of illegal opcodes in the kernel to shave off more time...that I have not looked into.

 

At any rate I will put in an explosion sound at the very least. I could also add some randomization to the computer shot calculations...the thing is, is that I seem to beat him fairly regularly so I was concerned that it might be too easy if I do that. Maybe you guys could post some of your scores in games vs. the computer to convince me otherwise?... :D

 

Thanks again,

Ben

Edited by Ben_Larson
Link to comment
Share on other sites

Another suggestion - the controls for adjusting the elevation/firepower are a bit too sensitive. It makes it difficult to adjust the settings by only one number. It would help to have that be a little less touchy. Maybe for the first second or so that you touch the controller, it moves the numbers slowly, then speeds them up.

Link to comment
Share on other sites

I don't know if it was asked before or if its too early to ask for it, but do you also plan a PAL60 version of the game?

I would love to play it here on my console :)

 

I will also try the actual version.

Link to comment
Share on other sites

I don't know if it was asked before or if its too early to ask for it, but do you also plan a PAL60 version of the game?

I would love to play it here on my console :)

 

I will also try the actual version.

 

Actually I'm planning to do a 'real PAL' (i.e. PAL-50) version. Not sure if it will be a 'cheap conversion' (i.e. just add blank lines) or a 'real conversion' (try to stretch the picture) right now though. You should at least avoid any color loss with the current version if your equipment supports PAL-60 (although the colors will be wrong).

 

Ben

Link to comment
Share on other sites

With regards to an actual explosion on screen...I don't think that's gonna happen unfortunately. See the way I'm displaying the player graphics on-screen is very ROM-inefficient but very fast speed-wise (classic computer science speed-vs.-memory tradeoff). I did it that way in order to have time to display the full width asymmetrical playfield, 2 single-line resolution players, the double-line resolution ball, and also have time to do the playfield and background color changes. The only way I think having an explosion on-screen would work would be to write another kernel to use during the explosion sequence which doesn't display the ball and I don't think there's ROM space for that. Although I suppose there's the possibility of illegal opcodes in the kernel to shave off more time...that I have not looked into.

Even something as simple as making the hit tank "glow;" i.e., cycling the colors or making them brighter would be nice. Lots of games do that and it looks pretty good.

 

:)

Link to comment
Share on other sites

Nice to see this game finally being finished!

 

I played a few rounds and i agree with the other guys, the game really needs a nice explosion sound and a "death" animation. This would make the game much more fun to play IMO.

 

It really looks a bit strange when the tanks are placed on only 1 or 2 pixels sometimes, maybe you could check that the tanks stand on "solid ground" before you place them on the playfield?

 

Besides that the game is fun to play, keep up the good work! :thumbsup:

Link to comment
Share on other sites

Even something as simple as making the hit tank "glow;" i.e., cycling the colors or making them brighter would be nice. Lots of games do that and it looks pretty good.

I actually thought of the exact same idea the other day after posting about this. :) I think that's what I will try to do.

 

It really looks a bit strange when the tanks are placed on only 1 or 2 pixels sometimes, maybe you could check that the tanks stand on "solid ground" before you place them on the playfield?

I forgot to comment on this earlier. The 'gravity defying tanks' is a result of using the hardware collision detection. I agree it would look better to make them fall under those circumstances...but it would take some extra logic, and rom space is in short supply if I'm gonna stay under the 4k mark... so we'll see.

 

Ben

Link to comment
Share on other sites

For explosions, a sound effect in combination with color cycling the tank that's blowing up is as effective as anything, and pretty simple to implement. You could also toggle the reversal bit.

 

Also, I'm surprised that nobody mentioned this, but the numeric angle indicator simply is NOT intuitive. I realize the tanks are too low resolution to help much, but how about doing a Trick Shot deal and move a missile in an arc to imply the angle?

Link to comment
Share on other sites

It really looks a bit strange when the tanks are placed on only 1 or 2 pixels sometimes, maybe you could check that the tanks stand on "solid ground" before you place them on the playfield?

I forgot to comment on this earlier. The 'gravity defying tanks' is a result of using the hardware collision detection. I agree it would look better to make them fall under those circumstances...but it would take some extra logic, and rom space is in short supply if I'm gonna stay under the 4k mark... so we'll see.

Another solution is to only position tanks on 4-pixel boundaries. That way they are always over at least 4 pixels of playfield.

Link to comment
Share on other sites

Also, I'm surprised that nobody mentioned this, but the numeric angle indicator simply is NOT intuitive. I realize the tanks are too low resolution to help much, but how about doing a Trick Shot deal and move a missile in an arc to imply the angle?

I like the accuracy of having the numbers, but an aiming point (in addition to it) would be nice to have.

Link to comment
Share on other sites

A minor quibble (although it may be nothing can be done about it)... it looks a little strange sometimes when a tank is sitting on just one or two pixels. Maybe if a tank hangs over the terrain by a certain amount, it should fall down to the next block. I don't know if that could result in the tank tumbling down a hill - but that might be cool too.

 

Could you have a tank shape which included a "table" underneath but configure CTRLPF so that the playfield would obscure those stripes? When placing the tank, use the shape without the "table", but then once the tank is in place add the table. Then it would appear that there was a platform built under the tank to hold it.

Link to comment
Share on other sites

It would just give an indication of the angle though - not the actual target.

 

The aiming point is merely a proxy for a more detailed turret. It would just be offset far enough from the tank to be able to move in a detailed enough arc to get a visual idea of the angle. It would be clear when playing it that the dot would not be the literal trajectory, based on the various factors. Dots have been used in other games beyond Trick Shots for similar purposes, like pitching and golfing games.

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.

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

  • Recently Browsing   0 members

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