Space Tanks - a two player adventure

[bongomeno]

Updated: 1/15/14

 

Download: spctank.zip * includes source, 4k bin, manual, map, and label *

Difficulty settings:

Left switch set to A: more frequent powerups
Left switch set to B: less frequent powerups

Right switch set to A: slower non-player-characters
Right switch set to B: faster non-player-characters

Story:

Two players (or single skilled player) operate a tank that has a command console with four functions (two joysticks). The left joystick moves the tank around and its button brings up the status display when held down. The right joystick moves a crosshair and its button fires the gun at whatever is selected. Their mission is to rescue prisoners of war from an alien planet. The prisoners are high ranking scientists of the players planet. The prisoners are being kept in a cell which can be found on the map included in this distribution. Three keycards must be found to open the cell and free the prisoners. The players tank has limited shielding and ammunition, but more may be found randomly throughout the planet. Players Will also find upgrades for the tank including the bigmissile and autolock. Alien enemies will be encountered most frequently and must be killed in order to find the keycards. Some aliens will require more ammo to kill than others, but the bigmissile upgrade allows for instant kills. The autolock upgrade causes the crosshair to lock on to aliens. Both upgrades have three uses. When the three keycards are found, the players should find the cell and free the prisoners. The players must keep an eye on their fuel level using the status display. If their fuel is running low, they must return the the ship at the starting position to obtain more.

Types of alien enemies:

Infantry
Blade Saucer
Bulldozer

Powerups:

Shield
Ammo
Bigmissile
Autolock

 

Structures:

 

Ship (starting position/refueling)

POW Camp

 

Screenshots:

 

Edited January 20, 2014 by bongomeno

[Cybearg]

Very neat! Very clever use of your resources.

 

A few things I noted as I played with two hands:

 

1. If you die to a big enemy like the big, brown tank, the enemy will shrink down to normal size in the death version. You'll need to reference NUSIZ1 in the end game loop so they keep their relative size.

 

2. I like the two-player cooperative aspect, though it'd be nice if player 2 shot an actual shot, rather than just lining up the cursor and pressing fire. Are you using the playfield ball? Maybe you could have that fire as a projectile. Whenever player 2 hits fire, if a projectile is not on the screen, it will home in to the location of missile 0 until it reaches it and disappears (unless it hits an enemy first).

 

3. There were a few times when the crosshair got lost because it went too far off-screen and got caught in the repeat cycle on the left or right or I just didn't know where it is. It's good that its location resets when the HUD is brought up, as that fixes that problem if it happens again, but maybe consider limiting the x and y locations of missile 0 so it can't get lost off-screen like that.

 

Other than that and some sound, it seems like a fun cooperative game! Kudos on that. : D

[bongomeno]

Thanks for the input! I fixed the crosshair moving off the screen and I randomized the npc/object positions for better replay value.

 

I will add your shooting suggestion if there is enough room after the sound effects. I am working with 46 bytes at the moment.

 

I am keeping this at 4k so it will work on my supercharger.

[bongomeno]

I have made some updates including code optimization and the addition of simple sound effects. I am now left with 11 bytes.

 

If anyone has any tips as far as optimizing any of my routines, that would be awesome. If I am going to sell this game, I want it to be respectable. I will comment out the code after I get some sleep (it has been over 2 days now).

[TrekMD]

Pretty cool!

[bogax]

I have made some updates including code optimization and the addition of simple sound effects. I am now left with 11 bytes.

 

If anyone has any tips as far as optimizing any of my routines, that would be awesome. If I am going to sell this game, I want it to be respectable. I will comment out the code after I get some sleep (it has been over 2 days now).

 

Have you posted your current code?

 

Just glancing at what you've got,

 

You could use more look up tables and make better

use of the ones you've got.

 

You could remove common clauses from if statements.

 

Your rooms are so similar you could probably save something

by modifying them rather than completely rewriting them.

 

I'd give examples but I'll wait to see what you're actually doing now.

 

edit

also rand & 110 produces one of 32 possibilities

rand & 60 produces one of 16 possibilities

is that really what you wanted?

Edited August 4, 2013 by bogax

[bongomeno]

I took your tips into consideration and was able to optimize a lot of the crap out of my routines. This enabled me to add a bunch of elements with memory left over for more stuff! The download link is up to date.

 

Things I added include:

sound effects

explosion sprite

powerups (explained in first post)

more randomized units

 

Any examples of how I could further optimize this would be very helpful.

Edited August 5, 2013 by bongomeno

[bogax]

I played with your previous code a little bit.

I hesitate to post it because it doesn't work

(not surprising since I wasn't really trying to

follow the game logic)

 

for the rooms I gave each room a byte in

a table with a bit for each possible opening

then XORed the old with the new and just

flipped them if they changed with four

if statements one for each possible opening.

 

I gathered all the player1 definitions into

one definition and changed the pointer

that the kernel uses.

that can save a fair amount, about half

of what a sprite defintion costs, but (at

least the way I did it) it's tricky 'cause

the numbers (probably) change when

ever you change something in the program

you have to compile, figure out what the

new numbers are and then recompile

with the new numbers.

it doesn't have to be done that way

but it cost less and saves more if it is,

both in time and space

 

I made o1, o2, o3 etc into subroutines

and selected amongst them using

on gosub

COLUP1 and NUSIZ1 and the player1

shape were all taken from tables

and set outside/ previous to the

subroutines each of those got a bit

in a constant byte indicating whether

they should be changed or left alone

Edited August 5, 2013 by bogax

[bogax]

I incorporated the stuff I mentioned except

the area data is the line flags instead of

having a room number and looking up the

flags.

 

I did some other minor tweaks.

You don't need a goto in an

if statement if all you're doing

is a goto

 

if then goto label

 

can be

 

if then label

 

if the label is close enough.

it's faster and takes fewer bytes.

 

if you're making assignments of the

same value be it constant or variable

doing them consecutively on the same line

will save bytes.

 

I don't know if I got it all right

I didn't try to thoroughly test it

 

It might not compile correctly

because addresses for the player

data needs to be right and it

might change with a different version

of the compiler or different settings.

 

Could use variables for that, but there

were none left

 

spctank_mod.bas

[bongomeno]

I will have to take some time to implement your modifications.

 

Just going from what you said at first, I managed to free quite a bit of memory and eventually even more. At this point I have added more features to fill out the game. I have updated the info and files in the first post.

[bogax]

It occurs to me I didn't comment the code

that's kind of lame.

On top of that I changed the names of the

kernel variables. I hope that doesn't

obscure things too much.

 

I made one other change that I didn't describe.

SWCHA, which is the joy switches, is used to look

up dir then dir is used to look up increments

for the position variables.

You might be able to get by without dir in there

at all and just look up the increments with

by the state of SWCHA.

doing it that way means you take time to do

things you don't need to just in case

(incrementing a variable by 0) but lets you

use less redundant code.

and you're not doing a bunch of if statements

so it may not take more time or not much more.

Also the timing is less variable.

 

when a player is displayed it's something like

this

 

for index = playerheight to 0
screen = playerdata[playerpointer + index]
next

 

of course it's in machine code not Basic.

 

the player statement sets up the pointer

which is two bytes, playerheight, and

the playerdata table.

Playerheight is set according to the amount

of data.

The pointer is 16 bits but for timing reasons

high byte doesn't change.

The way I coded it, all the player data is in

one player definition and the height is

changed to 7 instead of 87 or what ever it

is for the whole table.

Then to change the player you just poke

the lower byte of the pointer to where ever

you want in the table.

I did that with constants.

but you could do the defintion then save the

player0pointerlo in a variable and then

set player0pointerlo relative to the variable.

ie do the player definion so that playerXpointerlo

is set to the base of the table and save that in

a variable so you don't have to keep figuring

it out at compile time.

then you'd choose your spot in the table

something like

player0pointerlo = (player_no *  + playerdata

 

That costs you a little overhead (basically

setting the height) but saves you approximately

8 bytes per player definiton avoided (if you

set the playerXpointerlo with constants)

 

edit

I took the base of the the player data table

from the .lst file

but if you're comfortable with binary you

could just poke it to the screen.

the code get's padded with zeros so that the

player data table doesn't staddle a page

boundary ie so that the upper 8 bits of the

pointer isn't different for different parts

of the table.

The poke to the screen would take 4 bytes

so either you'd have to subtract 4

(and remove the poke) or the padding would

swallow the 4 and you wouldn't have to

subtract 4

Or if you're very unlucky it will get padded

or not depending on whether the four bytes

are there or not.

In which case it will get tricky

 

here I've removed two lines from

the playfield definition which

just compensates for the pokes to

the screen

 

playfield:
XXXX....XXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
XXXXXXXXXXXXX.....XXXXXXXXXXXXXX
end

var4 = P0plo : var8 = P1plo

 

Of course you could take the 8 bytes

or two lines out of something else

eg the title screens

The gap at the top is just to mark

where one nibble ends and the other

begins

 

Edited August 6, 2013 by bogax

[bongomeno]

It will take me a few hours to digest that info after I get some much needed sleep.

 

For now, I have updated the download with my latest version.

[bogax]

I added comments

 

spctank_mod.bas

Edited August 8, 2013 by bogax

[bongomeno]

Hello everyone.

 

First of all, I would like to thank bogax for the code modifications and comments posted above. It was very useful in helping me free up ROM! I took a break from working on this game for a while because of school and other projects, but this month I found some time to look at your post more closely and rework my code. I only used the suggestions that I understood fully. I could probably free up more memory, but I have already added all of the features that I planned out.

 

I have added a fuel meter and a ship that the player was supposed to have arrived in, but may also be used for refueling when in contact with the tank.

 

This update is a last attempt to get feedback before I comb through the game a few more times to make sure I am not missing any glitches. My intention is to produce 4k carts to sell on my website for $20. On that note, would anyone here be able to inform me of a service that could provide me with decent boxing that could have art printed on it?

[bongomeno]

I am considering this for the label.