Jump to content

Titan Diamonds - 1.2 released

Fort Apocalypse

Recommended Posts



The story:


In the year 2574 a lot of things have changed. Humans have colonized our solar system and the O81b "flying saucer"is the primary means of getting around town. However, some things don't change, specifically the need for diamonds. In 2574, the largest known diamond in the solar system was found in the moon, Titan. But in the process of trying to mine it, the 2 petaton atomic bomb used was overkill and scattered diamonds across the planet and across the solar system. You are one of the many that have equipped their O81b's with rock blasters and set off to mine for the diamonds. But watch out, the explosion also caused a lot of meteorites! Good luck diamond hunter, and get rich!



* shoot rock in attempt to find diamond that is same color as playfield (also ball) except it flickers (the diamond)

* 2 players

* can shoot opposing player

* get points by collecting diamonds ("win" game at 10 diamonds?)

* may/may not die by hitting playfield

* can select different levels

* can bump into other player

* falling meteorites

* ground quakes when playfield is shot

* player resting position landing strip is "safe" to land on

* self-destruct sequence when lander is damaged (colors of red)


Original Plans not implemented/won't be implemented:

* landing pad where you refuel (ball) - pfscore not working

* ufo runs across top and shoots down at you - ditched ufo

* lose fuel by hitting playfield - pfscore not working

* run out of fuel and you crash - pfscore not working

* playfield only crumbles when ufo's shots hit ground - ditched ufo



Edited by Fort Apocalypse
Link to comment
Share on other sites

0.2 released


2 player lander duel! dynamics for lander are more lander-like now and has thrust effect and ability to shoot and keep score as well as the 2nd player lander.


For now bullets can go through rock. This makes it a bit more challenging and is not where the game is headed, unless you want me to just drop the 1 player aspect of it and make it a 2 player lander duel, which turns out to be pretty fun in and of itself.


No sound yet.


Let me know what you think


Link to comment
Share on other sites

Here is 0.3. Basically the game is almost done as I described it with the exception of a life counter because I ran out of memory (4k top). Has sound, lander collisions, lander explosions and dropdowns after dying, game ends at 10 points. Get points by killing other player or finding diamond. I also added large falling meteorites (which you can see coming as they wait for their turn to fall... a sort of radar I guess).


There is a slight bug in the 2 player scorecolor. Posted it to playerscores thread. Unfortunately I can't use pfscore to have the life counter either because of the use of playerscores. Would be great if that could be fixed because I think that having a life counter would really help the game.



Edited by Fort Apocalypse
Link to comment
Share on other sites

Let me know if you guys like the game and what you'd like to see different to make it more playable. Also, try it with a friend if you can. The two player aspect of it is still much better than 1 player since there is currently no way to die except to be shot.


I forgot that I still haven't implemented the UFO running across the top... I don't think that would be very challenging anyway. I think the best could maybe just be to say you can't hit the playfield at all unless it is to the far left or right. I'll try that next for 0.4.

Link to comment
Share on other sites

0.4 released!


* can now explode by hitting playfield (can sometimes hit it safely, sometimes you can't- some chance involved!)

* self-destruct sequence before killed (length depends on "random damage" caused by hitting playfield or getting shot)


It's basically pretty close to being done now. Can't think of anything else to do with it currently




Link to comment
Share on other sites

0.6 minor changes mostly. refactored some code to make it smaller. tried making playfields smaller by using pfvline and pfhline but that didn't work. lander position during select mode raised one pixel. fixed so won't have quake and sound if you land on your base, and fixed player 2 collision sound. falling diamond




Link to comment
Share on other sites

  • 1 month later...

Okay, I modified the version 1.1 code to use shared shape tables for the two player sprites. When I compiled the original 1.1 code, I got 1 byte free. When I compile the new code (1.1a), I get 93 bytes free, so it saved 92 bytes! :)


Be careful, because you could easily break the new code-- although if you do, you can fix it easily.


Here's how the modification works...


First, I took the four shapes-- normal, up, down, and left/right-- and defined them as one long player0 shape, just before the "init" line label; set player1pointerhi to player0pointerhi; and set both player heights to 4 (i.e., one less than their desired heights, or 5 - 1):


 player1pointerhi = player0pointerhi
 player0height = 4 : player1height = 4

Then I compiled the new code, so I could see what label batari Basic used when generating the data for the player-- which turned out to be "playerL039_0." When batari Basic compiles your "player0:" and "player1:" statements, it places the actual player shape data at the end of your code, before the score graphics, and generates a label in the form "playerL0?_?," where the first "?" is the code line number on which the "player?:" statement occurred, and the second "?" is the number of the player (i.e., "0" or "1"). For example, if the very first line of your code is a "player0:" statement, then batari Basic calls that line ".L00," and it will use "playerL00_0" as the line label for where it puts the actual player0 shape data. Every line of batari Basic code gets numbered in this fashion, beginning with ".L00" for the first line, followed by ".L01," then ".L02," etc. Blank lines don't get numbered this way.


Next, I wanted to define some constants for the pointerlo values which will point to the desired shape in the table, since you don't have any spare variables to use for saving the base address of the shape table. I added the following lines near the beginning of your code, just after your other "const" definitions:


  const pnormal = #<playerL039_0
 const pup = #<playerL039_0 + 5
 const pdown = #<playerL039_0 + 10
 const pleft = #<playerL039_0 + 15
 const pright = #<playerL039_0 + 15

I think you may already know enough assembler to know that "#<xxx" represents the lo byte of address "xxx." Each shape in the table is 5 bytes, so the first constant ("pnormal") should be equal to "#<playerL039_0," and for the others we add 5 more-- i.e., base + 0, base + 5, base + 10, and base + 15. The left and right shapes are the same, but I defined their constants separately, using base + 15 for both.


But by adding these five lines, the "player0:" statement got pushed down five lines of code, so that means when the new code is compiled, batari Basic will assign the label as "playerL044_0" instead of "playerL039_0," see? So I had to change the "const" statements to use "playerL044_0":


  const pnormal = #<playerL044_0
 const pup = #<playerL044_0 + 5
 const pdown = #<playerL044_0 + 10
 const pleft = #<playerL044_0 + 15
 const pright = #<playerL044_0 + 15

Next, I commented out the subroutines where the player shapes get set (i.e., "p0normal," "p0up," "p0down," etc.).


Finally, I searched for everywhere that those subroutines were called, and replaced the "gosub" statements by "let" statements (with the optional "let" keyword being omitted, of course):


  rem  gosub p0normal : gosub p1normal : gosub resetpf
 player0pointerlo = pnormal : player1pointerlo = pnormal : gosub resetpf

  rem  if joy0up then lander0yaccel = lander0yaccel - 0.02 : if timer{0} then gosub p0up
 if joy0up then lander0yaccel = lander0yaccel - 0.02 : if timer{0} then player0pointerlo = pup
 rem  if joy0down then lander0yaccel = lander0yaccel + 0.01 : if timer{0} then gosub p0down
 if joy0down then lander0yaccel = lander0yaccel + 0.01 : if timer{0} then player0pointerlo = pdown
 rem  if joy0left then lander0xaccel = lander0xaccel - 0.02 : if timer{0} then gosub p0left
 if joy0left then lander0xaccel = lander0xaccel - 0.02 : if timer{0} then player0pointerlo = pleft : REFP0 = 8
 rem  if joy0right then lander0xaccel = lander0xaccel + 0.02 : if timer{0} then gosub p0right
 if joy0right then lander0xaccel = lander0xaccel + 0.02 : if timer{0} then player0pointerlo = pright



I left the original code-- commented out-- so you could see how it was changed, but you'll probably want to just delete those commented out lines.





Link to comment
Share on other sites

I finally took some time to play this, very nice concept!!


And although i totally suck at it i really like this game!!


Keep up the good work!




Thanks also to Curtis for the 2-player scores, Michael for freeing up more space with the sprites (I need to add another level or something now! :) Thanks, Michael!), and Fred for bB! :)

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.
Note: Your post will require moderator approval before it will be visible.

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.

  • Recently Browsing   0 members

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