Untitled Bullet Hell Game (WIP)

[jfmateos]

Tested in my vectrex and works like a charm... really an impressive work. Congratulations.

[50tbrd]

Very nice. Is there room for in game music?

I recall discussing Missile Lords with you as well. Sounded like an interesting concept.

[Der Luchs]

DER LUCHS - STRESSING THE PLAYER.BIN (10.78 KB)

Maybe something like that

[christophertumber]

Oct 25, 2014 3:45:26 GMT -5 50tbrd said:

Very nice. Is there room for in game music?

Sure. I still have more work to do on the main engine - Currently there's only two "patterns" for enemy movement. Straight lines and kamikaze. And the spawning of enemies (and enemy shots) is fairly hackish.

There's also some wiggle room in the differences in time both handle and draw different enemies. I have some that are 6 vectors and some that are 12. The drawing time on the more complex shapes is probably 10% or 20% more. Different patterns also vary slightly in CPU time usage, straight line is faster to calculate than kamikaze, for example.

Originally enemy shots were just another sprite so you could have 40-50 of any combinations of "things". Shots are now their own separate object, handled completely differently because the shot is much simplified in terms of drawing, animation and movement.

So, if I did a screen of just those V shapes or Shots I could draw a ton. But it would be pretty boring. The real maximum number of sprites depends on the mix of complex and simple.

Any additional patterns (or other changes like music) may mean a few more or less potential sprites on screen. Depending on the factors outlined above.

Oct 25, 2014 3:45:26 GMT -5 50tbrd said:

I recall discussing Missile Lords with you as well. Sounded like an interesting concept.

Pong+Missile command. My plate's a little full at the moment htough

[vectrexmad]

Really nice work Chris! Full respect to you!

[christophertumber]

UBH - Oct 26.bin (64 KB)

(FYI - Haven't checked this on real hardware in a while. Looks ok on both MESS and ParaJVE but could easily be fugly).


Much like the old days on Usenet, Imma using these threads to document my progress as I've always found posting about it keeps me focused. And installing JIRA or even Trello seems... excessive. So if this looks liek a blog, that's because it is.

Most of the core gameplay is now implemented. Attached binary is a very simple attack pattern that shows some of the capabilities.

Enemy Parameters implemented:
Speed: 7 different speeds
Pattern: Kamikaze, straight line, up to 6 independent redefinable patterns. Kamikaze enemies have different turn radii (specifically how many frames between rotation increments). Combined with speed this leads to some variety of movement.
Animation: Animated loop or rotate to face player
Shootable: May or may not be possible for player to shoot objects (ie; enemy shots)
Collide with player: Harmless objects are possible (currently only implemented for enemy explosions). May be used for bosses/mini-bosses or background.
Durability: 1-4 hits to kill

Not implemented:
Intensity - No variation on intensity except enemy shots are brighter than ships. If harmless objects will exists, should be of lower intensity
Shot rate: All enemies currently shoot at the same rate. This rate should vary (ie some enemies should be all shooty some should be all rammy).
Multi-sprite objects (larger enemies, mini-bosses, bosses): TBD

Next thing I really need to work out is how to handle multi-sprite objects for larger objects. Enemy data is a list of parameters with a routine that reads from a list. That list more or less says:

-Create enemy with vector list XXX
-And Y of YYY
-And X of XXX
-And speed of XXX
-And pattern of XXX
-And some other parameters
-Wait XXX frames until generating the next one

The handling routine just finds the first open spot on the list - which could be anywhere in the list - and plugs in the parameters.

Hrm, so if I just include an indicator there "this is part of multi-sprite #X" and then add the enemy's number into a list... Yeah. That could work. Should probably keep track of "hit points" separately too as it's often going to be >4 for these.

[VectorX]

Oct 26, 2014 14:49:35 GMT -5 christophertumber said:

Much like the old days on Usenet, Imma using these threads to document my progress as I've always found posting about it keeps me focused. And installing JIRA or even Trello seems... excessive. So if this looks liek a blog, that's because it is.

I'd suggested having blogs on here a while back, but not many people seemed interested. But continue to document away though

[vectrexrc]

considering the number of objects you have moving around - does this indicate a Vectrex version of Centipede would be feasible?

[VectorX]

^A half-assed job was done with Vectrepede on Spike Hoppin' (which you probably already know), cutting out the scorpions and fleas. It wasn't bad though as a hidden bonus game.

[christophertumber]

Oct 26, 2014 16:22:38 GMT -5 vectrexrc said:

considering the number of objects you have moving around - does this indicate a Vectrex version of Centipede would be feasible?

The problem is the mushrooms. Just looking at some screenshots and doing a quick and dirty mock-up you'd probably want something like 25x25 mushrooms. This is where character graphics and RAM would be really nice because 625 individual sprites is not going to happen (it's surprising how quickly that kind of stuff adds up Robotron isn't even nearly so heavy). If you did those as squares instead of mushrooms using a similar technique to what I've got in Specter that would be somewhere around 160,000 cycles. Unfortunately that's less than 10 frames per second - just for the mushrooms.

Even 10x10 for 100 mushrooms is a big problem. That might be feasible using my engine, with mushroom sprites having even more stripped down handling than the enemy shots (no movement, no animation). But collision detection with so many objects is a real thing.

You'd have to put some kind of artificial limit on mushrooms. Maybe have them fade over time?

[christophertumber]

lol - Just realized I can put my "attack waves" into macros for easy reference in sequencing. Making the process very much like using Sound Tracker.

And I'm overthinking group sprites used to build larger objects. They only reason they need to be "linked" is to ensure they're all destroyed at the same time. Otherwise, if they're created in the right positions and follow the correct pattern they manage themselves. So just a matter of what's the most efficient way to manage this, a reference with the enemy objects themselves or an external list. Maybe both? Object is tagged with a group number. If object is shot, the group manager is updated for hit points. If group should be destroyed, the manager's list is checked to determine which sprites to destroy.

[christophertumber]

Oct 26, 2014 15:18:09 GMT -5 VectorX said:

I'd suggested having blogs on here a while back, but not many people seemed interested. But continue to document away though

I'm on some forums that include blogs. But the problem is that they're generally very disconnected from the forums. And the forums are the real destination. You need to make a specific trip to the blog area and there's often not indication in the main forums when somethings been updated. So can be very out of sight, out of mind.

And I think other people are more inclined to post in forums than in the discussion section of blogs.

[50tbrd]

Oct 26, 2014 16:22:38 GMT -5 vectrexrc said:

considering the number of objects you have moving around - does this indicate a Vectrex version of Centipede would be feasible?

I'm not sure anyone would be happy with a vector version of Centipede. I think this may be a game that should be executed through raster graphic like YASI did. There were 11x5 invaders, 4 bunkers, the UFO plus the players ship and shots in Alex's YASI.

[akator]

I finally got around to playing this today. I love it.

[manu]

Okay. Wow. *bows to Christopher*