Jump to content
IGNORED

My first game: Dragon Defense


Tyler Frisbee

Recommended Posts

This certainly isn't a very groundbreaking game, but its my first Atari 2600 game, so I just wanted to see what people thought. In Dragon Defense, you assume the role of a wizard defending a castle wall against an army of dragons. Each time a dragon hits the wall or blasts it with fire, part of the wall crumbles. If the dragon makes it past the wall or you lose all 3 of your lives, the game is over. By collecting mana potions (represented by the ball), you are able to cast four different spells. Each spell requires a different amount of mana points. You can cast a shield spell (0 mana points) by pressing the fire button, an attack spell (1 mana point) by moving the joystick to the right while pressing the fire button, a healing spell (4 mana points) which regenerates the 3 lives you begin with by moving the joystick to the left while pressing the fire button, and finally a spell which rebuilds any damage caused to the castle wall (8 mana points) by moving the joystick down while pressing the fire button. You gain a point for every dragon you kill. Tips: its best to aim for the head and torso of the dragon when firing, also I may have hidden something of an Adventurous easter egg in the game. Thanks to everyone around here, especially Random Terrain that, without whom, I'd never be able to get this off the ground!

 

Dragon Defense.bin

Dragon Defense Manual.pdf

 

 

post-39533-0-12970300-1423934621_thumb.pngpost-39533-0-04988700-1423941057_thumb.png post-39533-0-91914300-1423940793_thumb.pngpost-39533-0-49789300-1423941157_thumb.png

 

Edited by Tyler12464
  • Like 4
Link to comment
Share on other sites

Looks neat! At first glance, thought of Archon. lol Thanks for sharing and posting screen shots. Label looks pretty snazzy too!

 

Gotta give this and that new pinball game winkdot just produced a try tonight.

Thanks! I'd love to hear what ya think! And ya, the shield sprite especially resembles one of the sprites from Archon lol

 

 

The gameplay and graphics are pretty basic so it does get a little monotonous after a while, but it can get pretty exciting and addictive pretty fast. Label art is cool too, you should try distributing carts. You wouldn't have anything against throwing it into a harmony cart, right?

Glad you liked it! I doubt its good enough for me to distribute on carts, but ya, feel free to throw onto a harmony cart

Edited by Tyler12464
  • Like 1
Link to comment
Share on other sites

Is there anything that typically causes it to exceed 262?

 

 

It probably just takes too long to run.

You might be able to break it up and

do some stuff this drawscreen and other

stuff next drawscreen

 

The processor creates the screen periodically

in real time

it needs to do this at a fixed time.

after it draws the screen there's a little time

left while it waits for the next time it needs

to draw the screen

That's when your program runs

If your program takes too much time between

drawscreens it'll miss it's schedule.

 

 

There's probably speed optimizations you

could make

 

it would help if you posted your source

Link to comment
Share on other sites

Is there anything that typically causes it to exceed 262?

I just added a link to this subsection, so you'll need to refresh the page to see it:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#oe_timing_problems

 

 

If your code hasn't changed much, the pfpixels are probably one of the things that are causing a problem:

 

atariage.com/forums/topic/234618-game-flickering-black-after-title-screen/?p=3169169

 

 

As it says on the bB page, one pfpixel uses 80 cycles every frame:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#pfpixel

 

If you use a boatload of pfpixels every frame, you'll be clogging up your program. Stella is very forgiving, so you can think everything is fine if you don't go out of your way to check the scanline count.

Link to comment
Share on other sites

not sure I follow your code but it looks to me like

your else clauses turn on pixels that should already be on
your line of if statements keeps running through statements that
turn off pixels that you've already turned off
so most of your calls to pfpixel are completely redundant
and you should only need to mess with the pixels when f changes

not sure this will work or if I got it right but

try replacing the f = f + 1 statements and if statement tests
of f with calls to this subroutine

(sorry, can't test it, don't have all that newfangled bB stuff)
(I may have slipped the tables by one)

 

 

edit: damn, I must have been groggy last night see if this works better

fw
 temp1 = col[f] : temp2 = trow[f] : pfpixel temp1 temp2 off
 temp1 = col[f] : temp2 = brow[f] : pfpixel temp1 temp2 off
 f = f + 1
 return

 data col
 1, 1, 1, 1, 1, 0, 0, 0, 0, 0
end

 data trow
 1, 2, 3, 4, 5, 1, 2, 3, 4, 5
end

 data brow
 10, 9, 8, 7, 6, 10, 9, 8, 7, 6
end

Dragon Defense mod.bas

Edited by bogax
Link to comment
Share on other sites

I think that its probably the pfpixels, I tried playing with the drawscreens and speed optimization with no improvement. I can't really do anything about the pfpixels though without really changing the game entirely.

 

 

with the kernel you're using it's possible

to manipulate the screen directly without using pfpixel

 

the screen is 4 bytes per row the first column

(of bytes, 8 screen pixels) is bytes 0, 4, 8 .. etc.

 

the corresponding screen variables (names) are var0, var4 etc

 

here I've rewritten the fw routine to look up an index

for the screen byte (indexed relative to var0) then

apply a mask to mask out the appropriate screen pixel

 

 

fw
  temp1 = top[f] : var0[temp1] = var0[temp1] & mask[f]
  temp1 = bot[f] : var0[temp1] = var0[temp1] & mask[f]
  f = f + 1
  return

  data mask
  %10111111, %10111111, %10111111, %10111111, %10111111
  %01111111, %01111111, %01111111, %01111111, %01111111
end

  data top
  4, 8, 12, 16, 20, 4, 8, 12, 16, 20
end

  data bot
  40, 36, 32, 28, 24, 40, 36, 32, 28, 24
end

 

Link to comment
Share on other sites

I think I know what your doing, but I don't completely follow...heh, I'm not a great coder..

 

 

 

Hard to know what you don't follow

 

& is a bitwise AND

 

1 AND 1 = 1

1 AND 0 = 0

0 AND 0 = 0

 

so

if you AND x with 1 you get x

if you AND x with 0 you get 0

 

& ANDs corresponding bits in two bytes

putting the result bit in the corresponding bit

of the result byte

 

%11000000

& %10111111

= %10000000

 

 

the playfield is 32 (pixel) columns x 12 (pixel) rows

each byte is 8 bits

a playfield row is 4 bytes (ie 4 (bytes) x 8 (bits))

each bit is a playfield pixel

the whole playfield is 48 consecutive bytes

var0 is the name of the location of the first byte

of the playfield which is pfpixels 0..7

in the upper left corner

 

the fourth byte of the playfield is var4

(the first byte of the second playfield row)

but you can also refer to it as var0[4]

(var0[0] is just var0)

 

the data statements work in a similar fashion

 

in this case the first byte of each row is %11000000

the 1s are the firewall

 

so you look up the location of the playfield byte

you want according to whatever f is in the

top and bot tables and put it in temp1

 

temp1 = top[f]

 

you need to do that because you can't use indexing

to index something ie you can't do var0[top[f]]

 

so you use temp1 to refer to the desired playfield

byte

 

var0[temp1]

 

which you & with an approprate byte chosen

from a table using f

 

mask[f]

 

&ing the appropriate bit with 0 turns off that pixel

then put the result back in the same byte of the

playfield

 

var0[temp1] = var0[temp1] & mask[f]

 

Link to comment
Share on other sites

  • 2 weeks later...

I managed to reduce the amount of pfpixels which fixed the scanline issue throughout most of the game. It plays beautifully on the 2600 too :cool:

I've attached the updated version, the wall is one layer thinner now which makes the game a lot harder, but it fixed the problems

Dragon Defense.bin

  • Like 1
Link to comment
Share on other sites

The atari is a very old device....create back in 1492 by Christopher Columbus. How about making a game for the Xbox one?thanks.

I didn't realize the software situation for Xbox one was so bad that people were out begging for someone to program it.

Link to comment
Share on other sites

Very cool sounding game. I love wizards! Whenever I play an RPG I'm always a magic user. Going to be trying this game out for sure. Sure the whole brick break thing has been done, but I love the concept of casting spells by collecting mana vials!

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.

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...
  • Recently Browsing   0 members

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