Working on a space invaders game...

[tschak909]

Decided for my first game to be a Space Invaders type game. Did some initial sketching in Envision, and am now posting the results of my work.

 

The graphics are meant for antic mode 4 displays, with each line setting a DLI to change the color palette of each line essentially doing a hue change.. I chose to use all four colors for a shaded look rather than a non-shaded flat but colourful look.

 

What do you guys think?

 

<-- editing the character set

 

<-- doing a simple tile test

 

-Thom

[Atari-Jess]

They look okay, but I think you should try to create an original type of game rather than something there are more than enough clones of for the 8bits...

[tschak909]

well you must understand, I am trying to get the rudiments down, and do something simple for my first pass. (besides, the game will have a few nice things not in any of the other clones.) :-)

 

-Thom

[ZylonBane]

I chose to use all four colors for a shaded look rather than a non-shaded flat but colourful look.

It doesn't look shaded, it looks like antialiased high-res art. In which case you may as well just make it high-res.

[tschak909]

what would you suggest i use for the graphics mode instead of antic 4?

[Heaven/TQA]

go for antic 4 and get a feeling for the machine... next time we will have a masterpiece for you.

 

1st... did you design your enemies in multicolour? they look like you have designed them in highres and are using them now in antic 4 multicolour mode. and the font editor screenshot from envision looks like its highres instead of multicolour mode?

 

anyway...keep it coming...

 

btw. my 1st game i wrote in atari basic back in 80s was a space invader like game... it's kind of "hello world" for game coders.

[tschak909]

I designed each tile in Antic 4 mode natively, pixel by pixel inside Envision, using the following color register values:

 

COLPF0 = 0

COLPF1 = 4

COLPF2 = 6

COLPF3 = 8

 

I did not use COLPF4, but I might for a special enemy state.

 

I have decided to design the game around a rotating set of character sets (4 of them) I know this will seriously impact the memory requirements of the game, but I feel this is the best way to do the animation of the invaders while taking a minimum of CPU time in the process. With the size of each character set, this will consume roughly 4K of memory space, but it will prevent me from having to waste cycles to change the characters more than I need to. (I will need to update the segment of screen memory only to do a coarse scroll, maybe I can get away with using an LMS to do both the horizontal and vertical scrolling!)

 

I will also be using a DLI to set the hue of each line, while keeping the shading intact.

 

To note, the game is being written in MAC/65, and I will be providing full source code, once I have finished a playable version of the game.

 

Tonight's goal and objective, to set up the playfield for the main game routine! I have made a conscious descision to use the narrow playfield width: 128 pixels across.. giving me about 32 character width to work with.

 

-Thom

 

go for antic 4 and get a feeling for the machine... next time we will have a masterpiece for you.

 

1st... did you design your enemies in multicolour? they look like you have designed them in highres and are using them now in antic 4 multicolour mode. and the font editor screenshot from envision looks like its highres instead of multicolour mode?

 

anyway...keep it coming...

 

btw. my 1st game i wrote in atari basic back in 80s was a space invader like game... it's kind of "hello world" for game coders.

Edited June 9, 2006 by tschak909

[Rybags]

Mode 4 sounds good... you could even have DLIs so that each row of invaders has it's own colour set.

 

Why worry about memory? If there's only a dozen or so characters you're editing, then just have a routine replicate the rest of the character set in RAM.

 

Or, just have the one character set and move the definitions into the character set each time an animation change is needed.

 

A nice touch might be to have each row's animation out of step with the others. Just about every Invaders game out there has theirs in sync... you could be different.

 

Another thing: most home systems games have the Invaders moving in unison. Maybe have semi-independant scrolling like the arcade version.

[tschak909]

I am doing a DLI for just the reason you describe

 

This currently is a learning experience for me, my main goals with this as far as gameplay is concerned is:

 

(1) have the character set cycle every vblank by modifying CHBAS. I will try to change the starting offsets of enemy type so as to have each enemy set out of phase. If I can think of a way to have each enemy set start differently, but still keep the character set rotation code working, I will implement it. (I chose the technique of modifying chbas, because it takes an absolute minimum of machine cycles to do so.)

 

(2) only the bottom enemies shoot

 

(3) each enemy has its own type of shooting, with the added touch that the bottom most enemies have the additional state of extending themselves (via a player/missile graphic) to the bottom of the screen, very abruptly, in a "smashing" motion. If the ship gets under it. *splat* .. a nice incentive to get rid of the bottom meanies first :-P

 

(4) try to do smooth scrolling for the ships.

 

(5) try to implement some sort of static background WHILE the smooth scrolling is going on. (5 is a maybe, and will be attempted _LAST_)

 

-Thom

 

Mode 4 sounds good... you could even have DLIs so that each row of invaders has it's own colour set.

 

Why worry about memory? If there's only a dozen or so characters you're editing, then just have a routine replicate the rest of the character set in RAM.

 

Or, just have the one character set and move the definitions into the character set each time an animation change is needed.

 

A nice touch might be to have each row's animation out of step with the others. Just about every Invaders game out there has theirs in sync... you could be different.

 

Another thing: most home systems games have the Invaders moving in unison. Maybe have semi-independant scrolling like the arcade version.

[Rybags]

Since you've chosen to change colours, then doing the CHBAS change can be independant too.

 

If you're only doing 4 character sets, it would be a simple task. Maintain a list of character pointers for each row in a table, then the code might look like:

 

LDA CHPOINTERS,X

CLC

ADC #1

AND #$F3

STA CHPOINTERS,X

 

That eg would work for character sets rotating through $40,$41,$42,$43... if your character sets were at $4400-$47FF, then you just add an ORA #$04 after the AND #$F3.

[Heaven/TQA]

don't worry about RAM... you have nearly 48k of it...

[tschak909]

what would X be initialised to? would I increment X at each pass of the interrupt?

 

-Thom

 

Since you've chosen to change colours, then doing the CHBAS change can be independant too.

 

If you're only doing 4 character sets, it would be a simple task. Maintain a list of character pointers for each row in a table, then the code might look like:

 

LDA CHPOINTERS,X

CLC

ADC #1

AND #$F3

STA CHPOINTERS,X

 

That eg would work for character sets rotating through $40,$41,$42,$43... if your character sets were at $4400-$47FF, then you just add an ORA #$04 after the AND #$F3.

[Heaven/TQA]

x would be incremented after a certain time

 

lda font_no

and #3

tax

....

 

and in your VBL font_no is incremented after couple of time...

you can not do "inc font_no" ever VBL as its too fast...

[Rybags]

Don't do calculations in DLIs. Best to maintain tables for colours, chset pointers etc. and carry out involved stuff in the VBI or main loop.

 

Like Heaven said, you don't want to do certain things every VBI. So, either have a delay counter, or you can use the low byte of RTCLOCK.

 

AND #1

BEQ EXECUTE - execute every 2nd VBI (25 per second)

 

AND #3

BEQ EXECUTE - execute every 4th VBI (12.5 per second)

 

AND #7

BEQ EXECUTE - execute every 8th VBI (6.25 per second)

[tschak909]

when do I want to use the two different type of VBI vectors?

[Rybags]

Immediate vector is supposed to be for short running things that must be run. The routine has to be short because it can cause problems with SIO if it runs too long.

 

Deferred can run almost the entire duration of the display. But, deferred is not guaranteed to run - if a IRQs are disabled or the CRITIC flag ($42) is set (like during I/O), or if an IRQ was running when VBlank started then the deferred routine isn't called.

 

But in a game you don't usually worry about needing I/O, so you could use a long Immediate routine.

 

Or, you can dispense with VBI entirely and use a delay loop which waits for RTCLOCK to update:

 

LDA $14

WAIT CMP $14

BEQ WAIT

... main program loop - read joystick, check collision, update screen etc.

[tschak909]

I am slowly progressing. I have the first DLI routine set in place to set the colors. Had to use a chain of routines each modifying the DLI vector at the end of each pass. Because I had to make four distinct color changes, I decided to hard-code them into the routine, so that I could minimise the number of cycles being done. I will be modifying the look of the screen layout from here, but now I have something i can work with and mould to look the way I want it to look.

 

You may have noticed I used a narrow playfield. I did this to be more in line with the aspect ratio of the original game, as well as to give me more cycles per line to do color palette changes. I am glad the idea I had worked. I just need to tweak the colors, maybe make them brighter, and perhaps play with the top score line a bit. I wanted to keep it nice and readable, but if I want color, I'll probably have to use an antic mode 4 line there too, I just wish I could have a border around the whole thing..but I guess that's out of the question....

 

I have hardcoded and filled the screen with invaders right now, just so i can get a sense of the space of the screen, there will not be this many invaders on screen at once, I know they need space to breathe and move around....

 

Now i will design the character for the player....

 

Screenshots posted below:

 

<-- before any DLI treatment ... totally monochrome

 

<-- after the DLI treatment ... technicolor!

 

-Thom

[Rybags]

Maybe use a 28 character high screen? That would enhance the aspect ratio even more.

 

Why not just use indexes for the colour change?

 

Then the same program code can be used on all DLIs.

 

In any case, might be quicker to do DLI vector changes at the start of the DLI. By the time that's done, you won't need a STA WSYNC on a narrow screen anyway.

[emkay]

Now i will design the character for the player....

 

Screenshots posted below:

 

<-- before any DLI treatment ... totally monochrome

 

<-- after the DLI treatment ... technicolor!

 

 

It looks like a 2006 hires

 

You really would do better with such game, when using more relieable colours and to rotate them.

With some small animations, the game looks more "living".

Look at Drop Zone or Bandits. Those games come optically out of the screen, but your colour usage will surely end in "dead" graphics.

 

A "galactic" Battleship has to look grey with some yellow and red blinking.... for example.

 

So my suggestions here: Use two colours for the ship-body with anti-aliasing and the reg. 710/711 for different colour FX.

[tschak909]

Would it be possible to implement two separate smooth scrolling regions? i.e. one spot for the invaders that march across and down, and one section for the movement of the ship ??? if not, no big deal, i'll just implement one section for the meanies, and do PM for the player.

[gauntman]

Would it be possible to implement two separate smooth scrolling regions? i.e. one spot for the invaders that march across and down, and one section for the movement of the ship ??? if not, no big deal, i'll just implement one section for the meanies, and do PM for the player.

 

Yes, you can set the HSCROLL and VSCROLL registers in the DLI, so independent regions can be made to scroll pretty easily.

 

Just remember that the scrolling bands cannot intersect. So for instance diving invaders or bullets will need to be PMs

[Rybags]

Probably best to use a Player for the ship, it makes collision detection much easier.

 

Really, you would need to use PMGs for the bullets as well since scrolling would distort their positions. It might be an idea to use a player for the ship's shots as well, since to be authentic, shots are supposed to collide and cancel each other out (GTIA doesn't do detection of Missile to Missile collisions).

 

Possibly the best solution is to use the same Player for the ship and it's shots... you would need a DLI just above the ship which would read the relevant collision registers, store to HITCLR, then reposition the relevent player/s.

Edited June 13, 2006 by Rybags

[emkay]

Probably best to use a Player for the ship, it makes collision detection much easier.

 

Really, you would need to use PMGs for the bullets as well since scrolling would distort their positions. It might be an idea to use a player for the ship's shots as well, since to be authentic, shots are supposed to collide and cancel each other out (GTIA doesn't do detection of Missile to Missile collisions).

 

 

 

Ocourse the best solution would be the Playfield-Ship with x-scrolling. You can make it bigger and more reliable then. I don't see the problem by comparing x and y position if the ship is shot or not.

The Attack-Wave (if there are some) could be done (as always) with splitted and overlayed Players. Missiles are still free for shots.

[Rybags]

Yes, playfield for the ship would probably be best.

 

For some reason, I was thinking back to the suggestion of background graphics, in which case using a player would be easier.

 

To make the game more interesting, plus stand out from the clones, how about power-ups/bonuses/penalties that drop Arkanoid-style?

 

Multi-fire, expand ship, slow down, speed up, smart bomb, etc.

[tschak909]

and now I understand why every line will need its own LMS instruction...

 

 

but .. hmm damn, i need to think on how to implement the march downward now...

 

-Thom