beta New game uploaded: Invaderz

[AndyMt 140]

Invaderz

View File

---

This is a space invaders inspired game. Use the mouse or joystick to control the player ship.
The shield segments can take 2 hits each. If enemies get too close you retreat back to the last level.
You lose when all your lives are gone or you fall back to earth level again.

Now with 7 playable levels

Requires emulator R38!

Roadmap:

• more diverse enemy formations
• enemy attack raids over the sides
• power ups (shields, double cannon, disruptors etc.)
• boss enemy
• joystick control done
• music done
• Different enemy sprites. done
• Sprite animations. done for player sprite and enemies
• fade in/out of palettes and backgrounds. done
• more levels with more backgrounds (all planets of the solar system), done
• sound effects basics done
• title screen
•  

How to use with the local emulator:

1. Unpack ZIP file into the same directory as the emulator.
2. Start the emulator, then enter
3. LOAD"INVADERZ.PRG"
4. RUN

---

• Submitter
  AndyMt
• Submitted
  08/11/20
• Category
  Games

 

[AndyMt 140]

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 .

[SlithyMatt 530]

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?

[AndyMt 140]

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.

[JimmyDansbo 141]

 

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 ?

[AndyMt 140]

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

[BruceMcF 237]

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.

[AndyMt 140]

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.

[AndyMt 140]

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'.

Edited August 14, 2020 by AndyMt

[AndyMt 140]

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!

Edited September 11, 2020 by AndyMt

[SplitSpine 1]

Nice, but could only get to level 2, all aliens dead but the stage did not end.

Also. sometimes your shots does not hit most left side aliens.

Otherwise nice wish it was harder

Game Version: 0.3

Emu Version: Windows R38

[AndyMt 140]

Thanks for the feedback . Strange with that hanging level... I'll look into it. The collision detection on the left has an issue which I still try to track down. But it's unrelated to the HW sprite collision detection, that much I know.

The difficulty needs some balancing. I find it hard enough, but I never was a good player...

[AndyMt 140]

Ok, found the Level 2 bug. New version 0.3.1 is online.

[SimonD 2]

Once a column is finished on the end, the invaders should move all the way across the field instead of keeping the same pattern of back and forth. Earth should be the last field instead of the first. Looking forward to further development.

[AndyMt 140]

Yes, movement patterns are very basic atm. In regards to the order... had Earth as the final stop, but actually: that would mean the invaders would get closest to our homeworld just before being defeated... So I swapped it around and the task is to drive them out of the system.

[BruceMcF 237]

4 hours ago, AndyMt said:

Yes, movement patterns are very basic atm. In regards to the order... had Earth as the final stop, but actually: that would mean the invaders would get closest to our homeworld just before being defeated... So I swapped it around and the task is to drive them out of the system.

Well, there you go, bill it as the more hopeful sequel to the original ... "Invaderz: Counterattack!"

[SerErris 70]

Hi, does not work for me on Windows r38 emulator.

I created a SDcard.img from the files and attached it to x16emu. I can see all the files in the emu and it looks like this:

But when I load it the screen is getting scrambled and it stops there:

The web emulator does it correctly. but I am not able to start it on my windows machine ... any idea, what happened?

 

[AndyMt 140]

I never tried it with an SD card image. I assume it has something to do with the device I'm loading. Until now that's always 'host' so I assume that's the problem. If you just copy all the files into the emu directory it will work.

[SerErris 70]

uhh ... and messes up my emu directory  Okay, thanks, that explains a lot. I thought it would be actually an sdcard loader.

[AndyMt 140]

You actually can have the game and it's files in a different directory and then have a batch file which starts the emulator with the -run parameter. That's how I do it for debugging etc.

[geek504 44]

On 8/11/2020 at 4:47 PM, AndyMt said:

The background is 8bpp in 320x240.

I had no idea you could create different screen resolutions other the ones provided by the SCREEN command, i.e. mode $80 320x200x256 and $81 640x480x16!

[SerErris 70]

Use some POKEs in the vscale and hscale registers of Vera. Both set to 64 gives you 320x240 . The depth is not dependent ... can be anything that fits into screenram.

[geek504 44]

1 hour ago, SerErris said:

Use some POKEs in the vscale and hscale registers of Vera. Both set to 64 gives you 320x240 . The depth is not dependent ... can be anything that fits into screenram.

So, (monochrome SVGA) 800x600x1bpp = (800 pixels / 8 pixels-per-byte) * 600 lines = 60,000 bytes is possible?

Also, (monochrome XGA) 1024x768x1bpp = 98,304 bytes?

Also, (monochrome WXGA+) 1280x800x1bpp = 128,000 bytes?

Edited September 13, 2020 by geek504

[Fnord42 36]

46 minutes ago, geek504 said:

So, (monochrome SVGA) 800x600x1bpp = (800 pixels / 8 pixels-per-byte) * 600 lines = 60,000 bytes is possible?

Also, (monochrome XGA) 1024x768x1bpp = 98,304 bytes?

Also, (monochrome WXGA+) 1280x800x1bpp = 128,000 bytes?

No, have a look here: https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md
The VERA does a fixed resolution of 640x480@60Hz, smaller resolutions are actually done via scaling.

[SerErris 70]

lol .. @Fnord42 is right .. max is by all means 640x480. but other than that you are pretty free to play around with the scalings .. 

Edited September 13, 2020 by SerErris