bongomeno Posted August 3, 2013 Share Posted August 3, 2013 (edited) Updated: 1/15/14 Download: spctank.zip * includes source, 4k bin, manual, map, and label *Difficulty settings:Left switch set to A: more frequent powerupsLeft switch set to B: less frequent powerupsRight switch set to A: slower non-player-charactersRight switch set to B: faster non-player-charactersStory: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:InfantryBlade SaucerBulldozerPowerups:ShieldAmmoBigmissileAutolock Structures: Ship (starting position/refueling) POW Camp Screenshots: Edited January 20, 2014 by bongomeno 6 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 3, 2013 Share Posted August 3, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
bongomeno Posted August 3, 2013 Author Share Posted August 3, 2013 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. Quote Link to comment Share on other sites More sharing options...
bongomeno Posted August 4, 2013 Author Share Posted August 4, 2013 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). Quote Link to comment Share on other sites More sharing options...
TrekMD Posted August 4, 2013 Share Posted August 4, 2013 Pretty cool! 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted August 4, 2013 Share Posted August 4, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
bongomeno Posted August 5, 2013 Author Share Posted August 5, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
bogax Posted August 5, 2013 Share Posted August 5, 2013 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted August 6, 2013 Share Posted August 6, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
bongomeno Posted August 6, 2013 Author Share Posted August 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
bogax Posted August 6, 2013 Share Posted August 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
bongomeno Posted August 7, 2013 Author Share Posted August 7, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted August 8, 2013 Share Posted August 8, 2013 (edited) I added comments spctank_mod.bas Edited August 8, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
bongomeno Posted January 15, 2014 Author Share Posted January 15, 2014 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? Quote Link to comment Share on other sites More sharing options...
bongomeno Posted January 20, 2014 Author Share Posted January 20, 2014 I am considering this for the label. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.