So, main object/ship to collision map is working and done. Just finished the player projectiles (bullets) to map collision; removes bullets from the projectile queue when it hits a surface/collision tile. Moving on, now it’s time to work on the dynamic object creation/deletion code for the script handler. Just a little more functionality and I should be able to do a real test stage/level to show off in video (albeit simple). Also, still haven’t figured out what to do with replacing the R-Type 2 assets. I rather code than worry about it for now, so I might end up demoing (video) it with them. Lame, I know. But whatever.

On a side note, been thinking about ideas for the weapon system design. I’d like to pack as much bullets, action, explosions, and enemies on screen at once without flicker (don’t we all). The weapon, or rather projectiles and pods/options, play a big factor into this. It would definitely be easier to do a vertical shmup than a hori one, but maybe next game ๐Ÿ˜‰ Anyway, it can be tricky choosing the right kind of weapons that look great and minimize sprite count, but look completely natural to the game design. I’m not in that part of the game development stage yet (least coding, almost all design/tweaking work), but I’m keeping things in mind as I go. Obviously graphic FX as well.

Advertisements

8 Responses to “”

  1. Aiming for a bullet and explosion extravaganza ? ๐Ÿ™‚

    • Well, just lots of stuff going on screen at once (and continuous). But not ‘bullet hell’ type of shmup. I was thinking more along the lines of Lords of Thunder, Gate of Thunder, and Spriggan Mark 2. Those games, on the higher difficulty settings which keep the enemies coming non stop. I.e. there’s lot to do.

      • I see. There was a very good shooter on the snes I used to like named Axelay. It supported really good graphics and well done stages with skewed perspective for some of the bgs. Macross was good on the snes, too. It was different than the pce version.
        There was also Valken (sequel of Leynos) which was nice in its presentation and action (although it wasn’t a shooter)
        it would be interesting to be able to change the form of the ship like the Valkyrie in Macross. Alterning with phases similar to forgotten world.

  2. Spriggan Mark 2 is one of my favorite Shmups. It’s like Cybernator on the SNES and Target Earth on the Genesis (which both games are related to each other), but in shmup form. Too bad you can transform the mech/ship in Spriggan Mark 2. You know, I was planning for a release of this current game for this summer. But I would really like to do a mini-shmup game to release meantime. A side scrolling mech/ship type shmup game would be cool. And I do mean mini – like 2 levels long. Release it on hucard (physical). The game engine should be mature enough by that point to do such a promotional thing. My brother does precision machine work (has a bridgeport mill and lathe in his shop) and is looking to making a vacuum mold injection system.

    • I know spriggan mark2 on the pcecd. There is lot of dialogue in that game. I see, a small promotional game to show the engine would be cool.
      By molding system, do you mean you’ll manufacture your own hucards ? ๐Ÿ™‚

      • Yes, make our own hucards. Not a big deal, really. The plastic part is done by vacuum injection mold. You can buy the two part resins to do this (no melting plastic/etc). The PCBs are thin, but not unattainable. And nothing more than a tsop or such surface mount flash rom the bottom side. There’s plenty of rom even in the existing hucard plastic casing for such chips. They’re about as tall as glop tops.

  3. Have you considered making more projectile/sprite heavy weapons use flickering sprites? I’m thinking back to the NES days where in Gradius, the laser would flicker in segments so that it was technically using fewer sprites on a line. You’d still have to track where those sprites would be and manage collision detection, but you could cheat around the sprite line limit.

    • Yes ๐Ÿ˜€

      Raiden on the PCE also uses flicker for weapon sprites. It alternates between two sets of bullets for the spread weapon (there’s a lot of bullets on max power of the spread weapon). But since the bullets move so fast, it’s pretty hard to notice. I’m keeping that trick in mind.

      As for lasers, there’s a trick you can do on the PCE. Writing to any VCE register (even just ‘selecting’ a color slot) causes the last visible pixel to stretch onscreen until the VCE has access to the CRAM again. If you use the Txx block transfer instructions, you can make a nice horizontal solid line. You just need a starting and ending sprite to cap the line since the ‘res’ or stepping is little coarse (a 16 pixel sprite should be enough) and you use the sprites to force the color you want to stretch as well. So yeah, full beam weapons that can cover the whole screen but only requires two sprites. Emulators currently don’t emulate this, but it’s solid behavior on the PCE for all models. The downside is that the taller the ‘beam’, the more cpu cycles it steals since you need to waste a scanline hsync call with a Txx instruction.

      If I don’t end up using the laser trick for the main ship, it’ll probably end up being used for a mini boss or such attack.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: