Commander X16

This is the support thread for Invaderz:
viewtopic.php?t=6278

Based on the experience with Brixx I wanted to go one step further and exploit the full power of the VERA chip. This game now has loads of sprites at the same time of which more or less all are moving. The background is 8bpp in 320x240.

Right now only one level is playable, no sound etc.

The plan is to have kind of a "storyline" where you defend each of our planets in the solar system. Starting from earth where the aliens suddenly appear. Then the player's task is to drive them out of our solar system.

Let me know what you think ?.

Very nice! I see collisions do need some work, but overall it plays quite nicely! I noticed that, unlike the original Space Invaders, you can have shoot while your last shot is still on the screen, but it does appear to be a little throttled. Is it ignoring some clicks outside of a certain window, or just waiting for time to elapse since the last shot?

Yes that is correct - you can have a maximum of 2 shots on the screen and there is a waiting time of 20 frames (330ms) between shots. I didn't want allow too many shots at the same time, as the game would be over quickly. Except if the enemies could shoot as much... same effect. But it get's unplayable above 4 - I tested it. Higher levels might allow up to 4 shots (from both player and enemies).

Above 5 the emulator starts to throttle, the CPU then seems to be at it's limit with collision detection. I still have potential for optimizations by using assembler for the collision detection. But already with this much on the screen I'm pretty happy. So I don't know if I will dig into assembler for this.

 

20 hours ago, AndyMt said:

I still have potential for optimizations by using assembler for the collision detection.

What language is the game written in ?

It's written in C using cc65. I'm quite happy with it.

As a long time Galaxian fan, I'm really interested in a game with a shot quota, but "bigger than one".

One alternative to a delay on the follow up shot is to allow the follow up shot when the current shot explodes OR passes a certain part of the screen. So, say, in level 1, if the first shot is 40% from the top or higher ... OR exploded ... its follow-up is available. The in level 2, it's 60% from the top, or higher ("congratulations, your fire control has been upgraded!"). Then in level 3, it's back to level 1 but there are two independent "tracks" ("you can been upgraded to two torpedo tubes!"). Then in level 4, same as level two but two independent track.

20 hours ago, BruceMcF said:

One alternative to a delay on the follow up shot is to allow the follow up shot when the current shot explodes OR passes a certain part of the screen. 

Yes, something in the line of this... The delay actually translates to a certain distance, so that effect is already there. But yes - I could allow a second shot as soon as the current one exploded. I'm still fiddling with all the parameters to balance the game. I might also introduce 3 difficulty levels the player can select from. From there difficulty would increase with each level, maybe in ways you have described.

Version 0.2 is online.

I've Improved the collision detection and also the handling of shots.

Also added some basic sound effects thanks to @DusanStrakl's example. 

The Web-Emulator struggles a bit with the PSG emulation. Switch off sound effects by pressing 's'.

Version 0.3 is online now ?.

ATTENTION: requires emulator R38. Uses hardware sprite collisions now.

I started implementing multiple levels. Each level has kind of an intro message, to give the game a background story. Also experimented with fade in/out of background images, which looks already quite nice. The enemy formations now behave slightly different per level, at the moment they basically speed up, and move closer. Future versions will improve this.

The enemy sprites are still placeholders. Next version will should improve there.

I hope you have as much fun playing it, as I have with implementing!