My GM shmups - Last Chance,MEGATANK, Flying V, XYX, ZPF

[BPzeBanshee]

What you have so far definitely seems pretty neat! Have you made use of any of the Shining Armour editor stuff?

[Rozyrg]

Not yet... last I was picking at it, I was trying to figure out the distortionless TATE issue and came to the conclusion it's code was wholly alien to my own. (Not the first time that's happened, either.)

It had been in the back of my mind how to do this for awhile, so it was inevitable that I'd eventually get sick of it rolling around in my head and just see if worked or not. I still haven't quite figured how it's going to read back the instructions exactly, mostly due to how I have the levels structured; but at least I've narrowed it down to the minimum amount of variables per enemy that need to be input. Might have to start studying queues or something similar to this end... I see they worked well for your replay mechanism (later difficulties notwithstanding, of course.)

[mjclark]

Have you made use of any of the Shining Armour editor stuff?

Don't want to go OT but I'd forgotten all about that Shining Armour project and its sorry demise.
Wonder what happened to him...

[BPzeBanshee]

Not yet... last I was picking at it, I was trying to figure out the distortionless TATE issue and came to the conclusion it's code was wholly alien to my own. (Not the first time that's happened, either.)

It had been in the back of my mind how to do this for awhile, so it was inevitable that I'd eventually get sick of it rolling around in my head and just see if worked or not. I still haven't quite figured how it's going to read back the instructions exactly, mostly due to how I have the levels structured; but at least I've narrowed it down to the minimum amount of variables per enemy that need to be input. Might have to start studying queues or something similar to this end... I see they worked well for your replay mechanism (later difficulties notwithstanding, of course.)

The actual queue structure I have works fine, it's been the actual behaviour of using the queue heads for movement per frame along with randomisation of attack patterns/enemy spawnpoints which have been my issue (which as of writing I believe I've since fixed). By all means make use of the code and maybe even put it input replay for your game some time.

Have you made use of any of the Shining Armour editor stuff?

Don't want to go OT but I'd forgotten all about that Shining Armour project and its sorry demise.
Wonder what happened to him...

I hope he's okay. Most likely he just had other commitments in the physical world stopping him from seriously working on it, or pursued other interests like the developer of Magical Broom Shooting. I think you'll find mjclark that there's a lot of developers in this forum that have put the project on hold indefinitely or just stopped working on the stuff outright which is a shame since some of them had the potential to go very far. If you're curious, PM me and I'll list names off the top of my head.

[Rozyrg]

I knew exactly what you meant when you mentioned randomization... tons of my enemies do the same, especially if they're set to spawn in variable locations. Usually something like:

Code: Select all

if x<room_width/2 {}
if x>room_width/2 {hspeed*=-1}
if x=room_width/2 {hspeed*=choose(1,-1)}

It's very likely I wouldn't have the foreseen the consequences of that regarding replays either. Complicating it even more, some have randomized firing delays, some don't even fire based on a similar choose or random call made on their creation, some make similar movement changes multiple times (the tanks especially). So much for me doing replays. Well...maybe next time when I can plan ahead.

Anyways, queues came to mind since there's the matter of sorting possibly hundreds of time/step checks without the benefit of hardcoded, pre-structured if/when entries. Using loops going the maximum step number to check if the time matches is out of the question (the test level shown is 10000 steps), so I'm planning on at least paring it down to only what's being used. Fortunately, the editor already separates the entries by what section of the grid they're using, so I already have a nice, linear sequence to work with. Still, anything that gives me an edge sorting through all that on the fly would help...so yeah, it'll be dissection time soon!

Another snag I didn't think about is the issue of enemy formations/ waves. While it would make more sense visually to have a single enemy actually represent a single enemy, there'd be no way to utilize some of the specialized formation-specific behavior at the same time. Granted, there aren't *that* many enemies that use these (not in XYX at least) and it won't make a difference if I build another project specifically around these limitations. Decisions, decisions...

edit:

Went ahead and got the inter-connectivity with XYX up and running. Enemy positioning, checkpoints work and basic loading seems to go pretty smoothly. Just having a high maximum time causes about a second or so of lag when it loads up (which it does only once after you've selected a ship), though, so hopefully it won't be too much worse when there's actual stuff in there. It does work, though!!

[BPzeBanshee]

Excellent news!

For the issue of randomisation, should you attempt to try putting in such variables I recommend trying to store the current random seed of every step along with player movement into a queue and then upon replay forcing the seed to the queue that got its information from loading the file. I've now taken out all randomisation so GMOSSE won't do this but it's trivial to do (at the moment the only thing that doesn't seem to work with the replays is runs with Arxtyan, I have no idea why its causing issues especially since I've removed all random variables that matter from it and it gives me headaches).

[Rozyrg]

Ahh... clever approach. Still kinda makes my head spin thinking about weeding out the randomization in there...

Updates as of this morning:

• - Levels can be given names (up to 10 characters), which will be shown when you load it in-game and when it starts.
  - XYX will now load and organize *any* created levels : up to 100, as long as they have names and a max time higher than 0. You can conveniently scroll through them all in-game, too.
  - Fixed some checkpoint issues... I haven't tested these at all without checkpoints on, though.
  - You can now assign a background set to the level corresponding to any generated via the map builder, although it's only represented by a number so far.
  - Retooled the map builder to use longer horizontal 'strips' rather than small square(ish) tiles. I think this will allow enough flexibility while cutting down on draw loops and how much data needs to be sifted through.

[BPzeBanshee]

Ahh... clever approach. Still kinda makes my head spin thinking about weeding out the randomization in there...

In theory there would be no randomisation to weed out with the existing code other than:
when recording

Code: Select all

//begin step event
ds_queue_enqueue(global.randomseed,random_get_seed());

Code: Select all

//step event
random_set_seed(ds_queue_head(global.randomseed);

in the obj_replaycontrol or whatever object you're using to handle the loading/playback process with the required queues.
That being said I had issues with this even still, but I cleared the game of randomisation BEFORE I thought to change the actual script file which GMOSSE uses for player controls from Begin Step to Step, leaving the queueing at Begin Step so knowing this you may actually nail it before I do .

Will the map builder support custom backgrounds/tiles or just use what's ingame?

[Rozyrg]

As of now, it only uses assets duplicated from the game; but I don't think it'd be too hard to add that feature, as I have background gfx already divided into sets. Having a few set aside for that purpose and a specialized ini for the file addresses should do the trick for that, I think. You'd need to adhere to some size restrictions, obviously, though.

I'll probably need to draw the line there, however.... not planning to allow for custom enemies. Although adding more that are strictly for use with the editor later on is hardly out of the question.

edit: DONE

• - up to 50 images are allowed per custom set
  - middle mouse changes basic xscale/yscale rotation of current tile, no need for duplicate flipped images
  - *somewhat* more user friendly and understandable interface, though it will need much more work in this area
  - the map's maximum rows can now be set within the editor

[BPzeBanshee]

I dont suppose an alternate button set on the keyboard could be set instead of middle mouse button? It's quite excluding of people who are unfortunate enough to have Apple Mouses (they DO have three buttons contrary to appearance but the middle scroll button is faulty by design).

Other than that, definitely liking the progress so far.

[Rozyrg]

I can do that. I thought having as much on the mouse as possible would be more intuitive; but it was already getting a bit cluttered and there'd be nowhere else to go if I needed to add more functions.

Speaking of clutter, I've had to expand the Level/Arrangement Builder to include a second page.

• - checkpoints (naturally)
  - "hinge" points (time doesn't advance until a set enemy has been destroyed)
  - assign background sets made with the map builder and what speeds they will move at. You can have two separate layers if you want as well.

..and just for the heck of it, here's what the ini for using custom gfx looks like:

Code: Select all

[custom0]
image0=gfx1.jpg
image1=gfx2.jpg
imagetrans?1=1

All images have to be in /custom/, sized 160x54, and imagetrans? will tell it to remove the background color for the corresponding image. Although I think it goes by that weird GM thing where it's always the pixel at the far lower right that determines which is the transparent color.

[BPzeBanshee]

I thought that transparent pixel colour bullshit got removed along with the old image editor when GM8 was released. :/

Oh well, its certainly sounding like its coming along very well. I wish I could say the same for GMOSSE (although with that feedback I got just now maybe I can make progress next week after exams...).

[Rozyrg]

As far as the GM sprite editor goes, yes; but it's still there if you use sprite_add's removeback parameter. I didn't know how else to allow for transparent sections, honestly; but it's not all that hard to get around. Being able to rotate each section helps with this, of course.


Just to clarify about the layering... the top one always counts as the 'ground', which will set the default vspeed of any non-airborne objects, while the other passes under it and just sort of does it's own thing. Basically, I was playing some Blazing Lazers this morning (the first level with the large battleships) and boggled at how I could leave out something so fundamental. >_>

Oh well, its certainly sounding like its coming along very well. I wish I could say the same for GMOSSE (although with that feedback I got just now maybe I can make progress next week after exams...).

Thanks. The editor part's moving along at least; but the game itself is kinda on hold until I can figure out how to fill in those gaps towards the end. I wouldn't sweat it, either... making even a little progress always feels great.

Edit: Custom song support has been added,too

[Rozyrg]

Updates:


I've combined the Map and Level editors, although that pretty much just means they're contained in the same executable, so you can't test both at the same time or anything crazy like that. Doing that wouldn't give you an accurate estimation of map position relative to enemy spawns anyways. I *am* trying to devise something that gives you some idea what position the map will be at a particular time/step index, though.

Speaking of crazy things, proper in-editor enemy testing would require moving over a big chunk of the game's core (including dozens and dozens of scripts), too... so I might have to just leave that out altogether. Considering I've easily run both the game and the editor at the same time to test minor level changes (on my old Vista desktop at that), I don't think it's really much of an issue.

[BPzeBanshee]

That enemy placement editor actually looks REALLY intuitive now. As for finding a particular time/step when running a map I recommend having a debug mode (I'm a big fan of debug modes with detailed info as you've seen ) but with a step counter that starts when you start a map. I do this in GMOSSE for every room and whenever the stage clear controller appears (a leftover piece of code from when I was first implementing the stage clear thing, I wanted to make the timing of it exactly like how Gleylancer did it). That I suppose is a simple enough thing but I imagine you're gunning for something more complex?

Speaking of crazy things, proper in-editor enemy testing would require moving over a big chunk of the game's core (including dozens and dozens of scripts), too... so I might have to just leave that out altogether. Considering I've easily run both the game and the editor at the same time to test minor level changes (on my old Vista desktop at that), I don't think it's really much of an issue.

Does this mean one can easily just have the editor up, implement a change, save a file and then have the game refresh the map somehow where its obvious it won't cause errors besides restart? That certainly sounds convenient.

[Rozyrg]

Yeah, the easiest thing would be to do a simple scroll test with a step counter... that wouldn't even take moving many assets around. Still, I was thinking I could have a fairly simple static overlay that kept everything on the same screen.

And yes. It only loads level data A: before you select one to play and B: right as you start the level, so you could make changes and save them all day while you're playing the last one you made in the actual game with no recourse. Well, not unless you managed to save on the exact step it was reading the .ini file. >_>

[BPzeBanshee]

The level data is in a .ini file?

No wonder you were complaining about stutter issues with it then earlier (if memory serves) - Game Maker's default INI file reading is apparently renowned for being quite slow (why it'd be slower than doing basic text files I dunno). Aero Flux uses a INI parsing DLL that does all the INI work and it's completely lagless if you're interested in reducing whatever noticeable load times you have.

[Rozyrg]

Cool.. thanks for letting me know.

It's not really an issue yet as it's really no more than a split second stutter; but I'm definitely going to keep an eye on it as the test levels get more complicated. I haven't even passed the 5-6k step mark on any of them yet, which is where most of the hardcoded levels end.

Part of the issue before was there being 8X or more tiles per screen to contend with; but I'm sure potentially hundreds of enemy placements will make up for that.

[Rozyrg]

As almost all the features I want are in the editors (minus boss support and the fancy step overlay thing), I'm back to trying to finish the main game.


The first major obstacle is Matriarch, the only unfinished boss aside from the TLB. As ridiculous as the onslaught of bullets might look from this pic, I've consciously been trying to make her less difficult than she was before. It's been very rare that I could even pass her first phase with checkpoints on. >_>

At this rate, it definitely doesn't look like I'll make the 2012 deadline (minus manual, case and other goodies even) as I've been kinda stumped as far as adding new enemies goes; but at least I'm making some progress again.

[Rozyrg]

Almost forgot about this...

This was the fighting game mock-up I was making for a friend's music video project. It didn't quite pan out (he decided to go with something much simpler), so this is as far as I got before I got the word. Most of it is really just 'sketched in', and I didn't even get around to doing the actual characters, as they would have to have been based on the performers in the video.

In the grand tradition of cartoonishly exaggerated landmarks for stage locales, I decided to make an amped-up, futuristic version of Vulcan Park in my home town. Not quite accurate, sure; but I honestly couldn't care.
------------------

On more shmup related matters, I'll definitely be getting the HTML5 version of GM before too much longer. I'll probably shoot for something fairly simple starting out just to test it (ie an arena style shooter) rather than porting any current projects right away, though.

[BPzeBanshee]

On more shmup related matters, I'll definitely be getting the HTML5 version of GM before too much longer. I'll probably shoot for something fairly simple starting out just to test it (ie an arena style shooter) rather than porting any current projects right away, though.

Bit of an expensive Christmas present eh?

I don't know how well it works as an alternative (I imagine proper GM:HTML5 is better) but I've noticed there's a few free programs trying to do the same thing as of late, namely Tululoo Game Maker. I had a bit of a run with Tululoo, its command interface is basically a silly version of GML (relative numbers: a = a + 1, a += 1 crashes), and it has no error debugging functions.

I think I missed something here. When did you add AirWolf to this?

[Rozyrg]

Bit of an expensive Christmas present eh?

Yeah; but I can definitely think of worse ways to spend some extra holiday cash. For instance, buying a new game system... or a truckload of Grindstormer Genesis carts in the vain hope of finding one that works. <_<

When did you add AirWolf to this?

Oopsy, unintentional spoiler. That's one of the unlockable ships. Which I was pretty sure you had already seen. Been awhile I know, though.
I could never figure out a good 2P color for it, TBH.

[BPzeBanshee]

Bit of an expensive Christmas present eh?

Yeah; but I can definitely think of worse ways to spend some extra holiday cash. For instance, buying a new game system... or a truckload of Grindstormer Genesis carts in the vain hope of finding one that works. <_<

Fair enough. Maybe you might be able to compile some builds of GMOSSE under it for me (since it exports to Windows under the new graphics engine too) to see how much performance improvements it provides.

Which I was pretty sure you had already seen. Been awhile I know, though.

It has been quite a while. I do believe that is a new ship compared to the build you sent me last - the one next to it I recognise but I'm pretty sure there was a vegetable there last time instead of AirWolf-DDP hybrid.

[emphatic]

That fighting game mockup looks amazing. You're an amazing artist!

[Rozyrg]

Thanks, man! As much I knew it might not make it into the video (drawing a background is one thing, making a functioning fake fighting game is another), I was really inspired, anyways.

It has been quite a while. I do believe that is a new ship compared to the build you sent me last.

Doh! That's right, the Cobra (heli) was actually the last one I added, come to think of it... blasted faulty memory. The name ought to be a hint as to what inspired it, too.

[BPzeBanshee]

It has been quite a while. I do believe that is a new ship compared to the build you sent me last.

Doh! That's right, the Cobra (heli) was actually the last one I added, come to think of it... blasted faulty memory. The name ought to be a hint as to what inspired it, too.

Aww, I was truly hoping it was an AirWolf cameo.

[Rozyrg]

Somehow I just missed out on Airwolf in the 80's, maybe I was too young? Then again, I do remember watching shows like the Equalizer with my dad, which were definitely on the grittier side of the tv-spectrum, so I have no idea, really.

I guess it's not too late to replace the biker looking chick I have piloting it with Ernest Borgnine, though.

[BPzeBanshee]

Biker looking chick? Sounds like Birthday from Batrider, and sounds good! Looking forward to release now.

[Rozyrg]

Just from looking her up earlier (not too familiar with Batrider), I had the urge to go back in and revamp the Cobra pilot's portrait... it was one that wasn't quite there yet anyways. Raizing/Eighting really had some fantastic character art for their games!

Updates:
End of December and I'm still slowly crawling towards the finish line for XYX. *sigh* The TLB will have his own (short) stage, which will not be easy on it's own. I just started making enemies for that and I'm only now wrapping my head around actually making a working boss out of what I have (which is more or less static images at this point.)

I have settled on an idea for my soon-to-possibly-exist GM: HTML5 project, too... already drawn a bunch of graphics for it and everything, yay!

XYX demo version changes

• - game now ends a third of the way through Level 3
  - you are restricted to 1 continue
  - only 3 of the 6 difficulty settings are available (Easy-Original-Arcade)

(Keep in mind this demo will be the one actually pitching the full game.)

[Atomhead]

I have settled on an idea for my soon-to-possibly-exist GM: HTML5 project, too... already drawn a bunch of graphics for it and everything, yay!

Nice one! I'm interested to see how fast you can get it to run. I haven't tried HTML5 yet but from what I gathered it's slow, and doesn't support
WebGL (which is supposed to be something that could make browser games run like desktop apps - without external plugins).
Also sound is said to be really immature in HTML5.
Best of luck though!