Titan Diamonds - 1.2 released

[Fort Apocalypse]

SEE LAST POST FOR LATEST VERSION!

 

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!

 

Features:

* 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

 

titan_diamonds_0.1.bastitan_diamonds_0.1.bas.bin

Edited January 20, 2008 by Fort Apocalypse

[Fort Apocalypse]

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

titan_diamonds_0.2.bastitan_diamonds_0.2.bas.bin

[gambler172]

Hi

A "Lunar Lander"like game with some additions would be great.

greetings Walter

[Fort Apocalypse]

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.

titan_diamonds_0.3.bas

titan_diamonds_0.3.bas.bin

Edited November 18, 2007 by Fort Apocalypse

[Fort Apocalypse]

Screenshots. Third screenshot shows the exposed diamond to lower left.

Edited November 18, 2007 by Fort Apocalypse

[Fort Apocalypse]

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.

[gambler172]

Hi

Checked your last version.Plays very well.Hope to see more soon.Would be good,if you loose a life,when your ship hits a meteorite.And the side movement could be a little bit faster.

greetings Walter

[Fort Apocalypse]

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

titan_diamonds_0.4.bas

titan_diamonds_0.4.bas.bin

titan_diamonds_0.4.bas.asm.txt

[Fort Apocalypse]

Preposed labels

Edited November 19, 2007 by Fort Apocalypse

[gambler172]

Hi F.A.

Nice;will check it on real hardware at weekend

greetings Walter

[Fort Apocalypse]

Walter, here is 0.5. left and right movement speed doubled.

 

Like it much better! Great suggestion!

titan_diamonds_0.5.bas

titan_diamonds_0.5.bas.bin

titan_diamonds_0.5.bas.asm.txt

Edited November 19, 2007 by Fort Apocalypse

[neotokeo2001]

Preposed labels

 

A couple of quick ones

 

[Fort Apocalypse]

Awesome! I really like the second one!

[Fort Apocalypse]

My first 1-player win in 0.5... and yes I died 6 times.

[gambler172]

Hi FA

Yeah,version 0.5 plays much better.

Great work.

Greetings Walter

Edited November 20, 2007 by gambler172

[Fort Apocalypse]

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

titan_diamonds_0.6.bas

titan_diamonds_0.6.bas.bin

titan_diamonds_0.6.bas.asm.txt

[gambler172]

Hi FA

Checked Titan Diamonds on my PAL 7800 system.

Works nice

greetings Walter

[Fort Apocalypse]

0.7 - 2 more levels with no gravity, faster reentry time

titan_diamonds_0.7.bas

titan_diamonds_0.7.bas.bin

[Fort Apocalypse]

Here are the screenshots for each level now (1 and 2 player game but only two player levels have screenshots shown):

Edited January 16, 2008 by Fort Apocalypse

[Fort Apocalypse]

fixed things like diamond drop, added heavier gravity to level 2 and 3

titan_diamonds_1.0.bas

titan_diamonds_1.0.bas.bin

[Fort Apocalypse]

now you don't move, you only shoot when firing. much less frustrating.

note ships bounce off each other properly from 1.0 on.

map changes.

titan_diamonds_1.1.bas

titan_diamonds_1.1.bas.bin

[SeaGtGruff]

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):

 

  player0:
 %00100100
 %00111100
 %01111110
 %00111100
 %00011000
 %00111100
 %00111100
 %01111110
 %00111100
 %00011000
 %00100100
 %00111100
 %01111110
 %00111100
 %00111100
 %00100100
 %00111100
 %11111110
 %00111100
 %00011000
end
 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

etc.

 

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.

 

Michael

titan_diamonds_1.1a.bas

titan_diamonds_1.1a.bas.bin

[Impaler_26]

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!

[Fort Apocalypse]

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!

 

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!

[Fort Apocalypse]

1.2 - new level, screensaving colors

titan_diamonds_1.2.bas

titan_diamonds_1.2.bas.bin