shmups.system11.org

Yeah, I'm working ANOTHER 2D-in-3D randomized abstract shmup, like we don't have enough of those already.

At the moment I don't have much, and I'm mostly setting this topic up so it constantly reminds me to work on it

Anyway, if you played the first one, what parts would you keep in a sequel, and what would you change? Or, if you have some new idea, feel free to post it too.

Sweet news. Saw your updated sig a bit ago and was wondering when we would get the first glimpse.

Do you still plan on having multiplayer? I never got to try that but I thought it was a cool idea.

Either way it would be nice if there was configurable controls. When I use a gamepad its often the standard xbox360 pad, and I hate using the stick for it. I would rather set things up to use the dpad. Its not a show-stopper but would be nice.

Be sure to keep tate

Multiplayer will be there, as well as doubleplay.
Dpad support is a matter of maybe five lines of code, no problem there. Not sure about full config, but i'll add at least some .ini file so you can swap buttons.
And tate is already in.

Not all bugs are bad.
While making a bullet shader, I forgot to turn off lighting, which caused very strange, light-scattering-like effect. A couple of tiny changes, and here we have, i believe for the first time in a shmup,
dynamically lit smoke:

http://www.youtube.com/watch?v=2rcBuGQj2ys

Of course, there will be much less of it in actual game, as it limits visibility and needs quite powerful GPU.

Cool! Many of our times greatest inventions comes from mistakes like this.

One of most common complaints with 2D-in-3D games is that there's sometimes hard to see what's going on. Enemies and special effects have nasty tendency to obscure bullets.

How to combat this? See, after you draw all solid objects, you no longer need the G-buffer, it just sits in the memory doing nothing but taking up valuable space. So, let's render all bullets into G-buffer, and then, after all the postprocessing is done, combine it with rest of the picture. Now you can be 100% sure they're above everything else, including bloom (yes, they do cause bloom, but bloom doesn't affect them), smoke, and other junk.


(note: scanlines will be probably removed from final version, or made optional)

I like the fog and bullet effects so far. Not sure about the scanlines (It looks like there should be lines every other column of pixels, but there's not)

Keep in mind that you are going to want to put some bullets even on top of other bullets! (Yes, complex patterns do need layers of bullets!)

Good points. Scanlines were an attempt to simulate trinitron CRT, but it doesn't look as good as I expected. I'll switch it back to every other column, or some combination of both.
Right now the bullets are displayed in order they were created. If I change it to depth sorting, layers shouldn't be a problem (Although I'm not sure if I'll actually need them, this game will be more about fast aimed attacks than complex patterns).

Could've fooled me with that giant bullet barf fest. :3

Was it just for testing? Awww, and I was already drawing lines on my screen trying to find the correct route through the pattern...

Progress report:
First enemy completed. At the moment it can't do much, just move down, shoot at player, and die. Of course, with different movement, shooting and dying functions it can be turned into (almost) any other enemy.
Also, I have sound now (thanks to fredrikpj).

Bullet barf mode shouldn't be that hard to implement. Just slow all bullets down, randomize their directions a bit, and reduce cooldown time for all enemies. I may include it as a bonus.

Been trying to figure out a scoring system that works with randomly generated game, and isn't overused to death.

Here's an idea:
-After you destroy any enemy, there's a countdown (depending on enemy size, 10 frames for popcorn to 60 for large enemies). If you hit enemy during that countdown, it drops medal.
-Medals have less value the longer they are in the air (like in Blue Wish). So, closer to the enemy equals more points.
-After countdown ends, enemy finally explodes, taking out nearby bullets (again, depending on size), these are also converted to medals.

Good? Bad? Terrible?

How about instead of the enemy just exploding in medals, it also explodes in bullets that damage other enemies.

Actually, that would be a cool idea for a shmup where you are a bioligical ship fighting mechanical ships. Like those queens from Starcraft that parasite enemies and they explode >_>

Did a quick test. Chain reactions this causes are nice, but too unpredictable. http://www.youtube.com/watch?v=BStPhd2xrGM

Well the idea wasn't every enemy blows up this way, just the first one you kill that starts the countdown timer. Also, any enemies killed with those special bullets should release medals as well.

Even better: the explosion itself can damage other enemies. If the damage is lower than enemy's starting hitpoints, weaker ones can get destroyed by it (with bonus points of course), but no chain reactions. This will require a bit of programming (I don't have actual explosions yet) but the result can be really cool.

Do it, but I like the idea so much that I may make my own version of it someday

OK, implemented, and seems to work really well.
http://www.youtube.com/watch?v=qEGcmHC0TKk
When multiple enemies explode in close proximity, the combined force can destroy enemies of the same size, which wasn't a part of the plan, but it looks cool, so why not keep it?

Note: medals are still invisible, still working on a model.
Note2: bullets slowed down to show cancelling, it won't be as easy in actual game.

Erm, not exactly what I was thinking of, but that's still cool.

Nice explosions.

Update: I'm not dead yet.
Been trying to make this game work on older machines. Simplified shaders, moved bullets and particles to separate threads, stuff like that. Biggest problem I ran into: display lag.
Modern GPUs seem to spread rendering over several frames. Doesn't matter in most games, but in high-speed shmup it's very noticeable. You can prevent this by forcing it to complete all rendering before displaying anything, but you lose like half of the performance that way.
Fuck this shit, should've made it 2D.

Just take a timeout mate, the solution will come sooner or later

I don't think there's solution at all, it's a hardware thing. Just added force finish as an option for those with really fast computers, and even without it, it's not THAT laggy, 3 frames maybe, not worth stressing about.

this looks great. loved the first game and can't wait for this one.

that sounds like Guwange slightly

It might slightly sound like it, but it would play entirely different IMO.

Question for owners of WinXP-based MAME cabs:
What's the control setup on these, and are there any additional requirements (screen resolution, etc)?

I'd like to make this playable on them (well, ones with recent hardware anyway).

Also, current state:

Still no enemies other than the placeholder, however it has now multiple attack and movement patterns.

I'm also thinking about replacing the circuit background with something more interesting.
Either random boxes with glowing edges (should look like some kind of virtual city), or some kind of angular techno-foliage (like Vectrex trying to display Crysis jungle ), or both.
Any other ideas (something simple please)?

I would use Taito TypeX2 as your hardware reference. But at best, PC cab owners have tri-sync monitors, meaning 800x600 is max resolution, with 640x480 preferred as it can simulate 320x240 with scanlines. Also if the cab only has a lowres arcade monitor, 640x480 can be downscaled and played fine at 15khz.

As for controls, simple keyboard is all thats really needed as most PC cabs use a JPAC interface, although joystick support would probably help round out all other possible hacked controls.

Type X2 is quite similar to my PC (Unless there's something in XP Embedded that makes it incompatible with normal XP apps). If you turn off effects type X should suffice too, but I really don't have any way to test it.
I'll have to change some effects to scale with resolution, there's way too much bloom in 640x480. Score display is also hard to read in 640x480 yoko, i'll just make it bigger. Oherwise it should be OK. Thanks for the info.

Oh yeah, Tate display option would be fantastic!

Already there, as well as horizontal mode (though HUD isn't correctly repositioned yet) and stretch, only common modes missing are wobble and split screen (both are useless IMO, but if someone really needs them, I can add them).