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

[Rozyrg]

Welp, still no definite fix for the GMS - OUYA problem and we seem to be going straight into the next (potential) NGDEV thing, so any game updates will be sporadic as ever. >_>

Laser Carrot v2 (WIP), Megatank v2 (WIP), and the untitled dragon game (can't remember if I've posted the link here or not) will all go to PC first at this rate. As usual, feel free to leave any suggestions for making them less shit.

[railslave]

Almost done with the gfx for this guy:

This is just a mockup I threw together in GM. He does absolutely nothing interesting yet.

Im sorry, ...but

BASTARD

Thought id have fun reading this thread from the beginning lol...but, ill be swinging from the rafters with anymore one man awesomeness like that!!

[BPzeBanshee]

Thought id have fun reading this thread from the beginning lol

Speaking of beginnings, I feel that this conveys Flying V in a nutshell.

[Rozyrg]

BASTARD

I dunno if he made the final cut; but I actually re-did all the gfx of him for Neo.

Speaking of beginnings, I feel that this conveys Flying V in a nutshell.

I really want to port that over TBH, in my dreams I see flashes of playing it on my TV running at a super smooth framerate. -_- Plus I could be a totally evil fuck with something like that on the market: like, completely gutting the easier settings and sell credits via IAPs. >_>

[BPzeBanshee]

I really want to port that over TBH, in my dreams I see flashes of playing it on my TV running at a super smooth framerate. -_- Plus I could be a totally evil fuck with something like that on the market: like, completely gutting the easier settings and sell credits via IAPs. >_>

That actually would be pretty cool. I'm not a huge fan of lots of difficulty options myself, but having one balanced mode would be sweet, and even IAP setup similar to the likes of Mars Matrix DC or Crimzon Clover's shop functions could work.

As for giant meat thing railslave noticed there, if it's in NEO XYX it isn't in stage 3 anymore going from the videos I've seen of it in action. Shame I have neither a Dreamcast or NEO-GEO otherwise I would've purchased it, I didn't like the initial look of it but it actually looks decent in the newer videos (and when I mean look, I mean gameplay-wise, obviously I'd be mad to criticise the awesome artwork).

One other random question: any way to get rid of the blue bars on Laser Carrot Attack/MegaTank?

[Rozyrg]

He was actually supposed to be the game's TLB; but I never got around to coding him beyond just getting him on screen. The only reason you see the L3 bg is because it's running in the debug test mode.

The blue borders were there just to accommodate for the OUYA and the general unpredictability of how the game window will try to stretch to fill the screen. Knocking them out is super easy, will do that.

Would you have any preference as far as modes? I can never make up my damn mind on that kind of thing.

[BPzeBanshee]

I'm not too familiar with what you're handling internally but if it's possible to have two options: borders on/off and stretch being what your current settings basically represent, I'd go with that. Is that sortof what you meant?

[Rozyrg]

Exporting to Android, it will stretch the display by default; so that's just something you have to work around. Also, using surfaces has some repercussions as far as messing with the display, too - going to fullscreen freaks out on my laptop for one.

To make the border, I'm actually altering the main room's width/height and then setting global vars that define the borders of the play area. What I had it do before was check if the current OS was Android (handy feature in GMS) and if not, it would skip the bit where you can adjust it and set both border wid/hi vars to 0. I just temporarily put that part back in to make sure it still worked along with the upscale settings (also since I can't check on the OUYA.)

[Rozyrg]

The testing issue was finally fixed and I'm back on the OUYA team... yaaaay! I had to take the bullet and update GM Studio to get there; but it turns out it wasn't that big of a deal ultimately. I was probably wrong to fume so much over it before; but hey, riding the rage rollercoaster can be fun sometimes. >_>

I haven't got it fully out of a state of brokenness yet; but from the tests I've run, Fire Arrow's speed issue seems to have been solved by the surface rendering technique. You know what that means...

[BPzeBanshee]

Hooray!

What is the Ouya's window specs anyway?

[Rozyrg]

If you mean resolution, it's 1080p (upscaled) across the board. That's partly the reason the surface trickery is needed. You can't *make* it run at a lower resolution, so you just force it do the upscaling in a way that's less taxing on the system (and also doesn't look weirdly artificially sharp or smooth.)

TATE will be as easy as changing a single variable, fortunately; but the aspect ratio is kind of an issue. So far, it only looks correct if I force it to run in portrait, otherwise it tries to stretch the whole image to screen, which looks pretty horrible. Not sure how to get around that aside from adding ginormous borders.

edit:

Most of the major crashes and funky graphical glitches are fixed now, it plays like the real deal. The bulk of what needs to be done (other than just testing the shit out of it) is just getting a proper key config in place, tweaking sfx volumes and oh yeah,.... finding some new music. <_<

[BPzeBanshee]

If you're using surfaces in the same way I managed to come up with rotatable surfaces like your Cave ports it should be able to just angle at 90/270 degrees and not need to stretch to 16:9.

Then again, I say this, but it took me almost an hour just to figure out how to get fucking sounds playing again in Warbird after the legacy sound engine failed to play MP3 music like the piece of shit it was. Changing some commands fixed it but even if you put in an OGG it does some kind of conversion on compile time anyway and I found that a bit odd. Who knows what else they changed that I've not kept up with.

[Rozyrg]

I like the new audio engine for the most part. It's actually not much of a hassle to implement, either, since I usually glob all the sounds together in a single script with one or two command calls doing everything. The OGG thing is really weird, I agree, though.

Something to keep in mind if you're using the same kind of simple surface trickery I am. My laptop won't even run these shaders at all, naturally.

The forced screen stretching seems to really just be a Android/mobile OS export issue as far as I can tell, you're not likely to encounter it unless you want to mess with the testing features on a tablet or something. But yeah, TATE should as easy as changing a variable in draw_surface_ext now, pretty cool.

edit: apparently it's not that simple (at least on my setup), I'm just getting a black screen with any rotation value other than 0.

I also started unspooling Flying V in GMS just for the heck of it. It looks doable; but just getting through that tangled nightmare web of scripts and shitty legacy code ... yikes. Should be fun.

[BPzeBanshee]

Make sure you're adjusting the x/y positions too when using draw_surface_ext, as the image's "center" is 0,0, so if you do a 90 turn it won't be on the screen at all. My experimental build that I made a thread for in Development here adjusts for that so it always remains on-screen.

[Rozyrg]

Definitely seems like what's going on, yeah. Didn't quite think it all the way through when I was messing with it (big surprise.)

Oh yeah, in case you were wondering how much of a ridiculous clusterfuck FV's guts are, I just managed to find ~ 350 lines worth of uninitialized variables just for enemy instructions alone. I think I'll be eating crow for weeks after that complaining I did way back when...

[BPzeBanshee]

And now I feel this one conveys my feelings best right now.

[Rozyrg]

Yep, sums it all up really. >_> It got up past 400 by the time I was done. That just what happens when you constantly pull new variables out of your ass and try to consolidate every possible enemy behavior into the parent object. On the plus side, some needed improvements were really easy and obvious... gotta love old shitty code.

Still a long road to the point where I can even hit that green play button, though. Crossing my fingers this will even work at all.

[BPzeBanshee]

Sounds like some seriously bad design you're gutting out, kudos on realising it and doing the process though.

From what I've been taught of inheritance you ideally want ONLY what's common between all enemies in the parent (HP, calling death event when HP <= 0), and anything else (ie. unique features, sprite, behaviour) in a sub-type of it, ie an enemy that inherits from the parent enemy object.

So, to do it right with cars in a nutshell:

Ideal way:

Code: Select all

* Car     
           > Holden Car    
                     > Holden Commodore
                     > Holden Camry
           > Ford Car    
                     > Ford Falcon
           > Mitsubishi Car 
                     > Likasombody Chiwahah

What your Flying V code sounds like:

Code: Select all

* Holden/Ford/Mitsubishi/VW/WTFCar
           > Something like Holden/Ford
                    > Holden Commodore
                                  > Car
                    > Holden Camry
                    > Ford Falcon
           > Something with funny names
                    > Likasombody Chiwahah
                    > #!@$!#^#!&&**(

Kinda looks like inheritance in reverse which is really not how code should be done in any language let alone GM. But you knew this already, I'm just stating what we both know into the open.

[mice]

Needs more abstraction, I think, don't create a car class.

Vechicle has-a propulsion-system
Petrol is-a fuel-type
PropulsionSystem has-a fuel-type
Laser is-a AttackSystem

carEngine = new PropulsionSystem(new Petrol());
car = new Vehicle(carEngine);
car.setAttackSystem(new Laser());

And be sure to read:
http://berniesumption.com/software/inhe ... destroyed/



EDIT: And of course you should use a builder pattern and pools with pre-created objects.

[BPzeBanshee]

I think you overcomplicated the car example, but yeah, more or less that. I think GM's design is more oriented around the factory pattern, though either method can be done.

Speaking of which, I keep forgetting to fix one fuckup I did with GMOSSE's enemy inheritance: air (colliding with player and scrolled with screen) vs ground (! on everything in the last bracket) should be a variable switch in the enemy parent - is in the air or is on the ground. Currently I have the enemy parent and a inherited parent object for ground enemies, which isn't "inheritance is evil omg" as much as "BPze sure messed that one up, quit the weed man".

Anyway, could be an interesting thread topic if anyone's keen.

[Rozyrg]

Bad design is putting it mildly. Yeah, I realized it was problematic a long time ago. The idea was to have everything accessible so that I could essentially just build a new enemy out of a stack of variables and allow for the maximum amount of potential variations.

For example, I would have a whole bunch or variables dedicated just to creating bullet patterns all within the enemy itself :

• basic type (spread, circular, special, etc.)
  homing/not homing
  bullet sprite
  speed
  initial firing delay
  delay between shots
  spread count
  spread angle variation
  shots per burst
  maximum number of shots

The benefit is that it all can be changed on the fly when the enemy is spawned (again, allowing for the maximum potential for variation); but it gets unwieldy pretty fast. Afterwards, I would just put all of this in a special bullet pattern creating object, the specific type being selected by a single variable. Pretty much the same way I now have all the specialized actions for any enemy also called by only one variable.

To that end, I've learned to keep any others that might be required as generic and multi-use as possible, like special1,special2,special3, timer1,timer2,timer3, or action1,action2,action3.

[Rozyrg]

Good grief...this variable cataloging by itself is turning out to be absolutely unending, looks like I might save time in the long run by just redoing the bulk of this. It's like trying to unspool the magical endless spindle of shitty coding.

Starting again from scratch is looking like viable option too... -_-

[BPzeBanshee]

How much of that bad code exactly is stopping it from working in GM:Studio?

It may be horrible horrible code but if it operates correctly and you just want to do the port you may be able to get away with a old code/new code portion setup where components like the menu are redone and gameplay that uses the old code is left intact. Otherwise, frankly I'd have to agree with you on the setup: GMS is hard enough for old projects to operate the same as before.

[Rozyrg]

It's all just having to declare variables, believe it or not... basically, the first goddamn step. Here, that involves tracing them back through a meandering web of scripts within scripts within scripts within objects, then making sure inheritance orders or instance creation via other scripts don't interfere with anything on top of that. Going along this way, it's going to be quite a while before if I can see if it even works at all and any of this frustration is worth the trouble, much less see if it runs acceptably on OUYA or anything like that.

I've decided just to gut everything, rebuild the more potentially problematic stuff from scratch first and hammer in improvements from the get go rather try to tiptoe around old code like it was a floor covered in rusty thumbtacks and lightbulbs. I really just need to have something up on the screen for the sake of motivation, too.

Once that's done, rebuilding the stages shouldn't be a problem as I pretty much just have to copy/paste the enemy spawn times and such from the GM8 build. The other plus is that I can go ahead and shed the bulk of those superfluous game modes and options as well.

[Rozyrg]

I've recoded the basic guts and got it running, it seems to perform really well on the OUYA. I'll pile on the medals, bullets and debris fx like there's no tomorrow and it doesn't seem to skip a beat. It's likely going to be a different story once I get stuff like backgrounds and a million different enemy behaviors in place; but it's looking great so far.

edit: Whilst it runs great on a tiny Android console, for some reason it constantly runs at lower than 10fps on my laptop. Wtf?

-----------------------------
Just a heads up, too: Fire Arrow and Flying V (OUYA versions) will be needing some music eventually.
Cue the usual examples and a few more:

• 1,2,3,4,5

On the lighter end of the spectrum (I really love this synth heavy jazz fusion sound)

[Rozyrg]

Some details for the FV remix:

• - music will be by railslave , although I might leave the older soundtrack in as an option
  - gameplay is basically the same as the old Arcade Extra/MegaMedal mode, where clearing an entire enemy formation can wipe out any of their bullets, changing them into medals. If anyone still wants stuff from the other modes (free weapon switch etc.), please let me know... I'll otherwise just be leaving them out totally.
  - most enemies will have totally different movement patterns/behaviors, meaning stages will likely be structured differently as well.
  - default difficulty might be jacked up a bit higher, although I don't having anything like a ranking system to 'adapt' to your play in (yet.)

[railslave]

Some details for the FV remix:

• - music will be by railslave , although I might leave the older soundtrack in as an option
  - gameplay is basically the same as the old Arcade Extra/MegaMedal mode, where clearing an entire enemy formation can wipe out any of their bullets, changing them into medals. If anyone still wants stuff from the other modes (free weapon switch etc.), please let me know... I'll otherwise just be leaving them out totally.
  - most enemies will have totally different movement patterns/behaviors, meaning stages will likely be structured differently as well.
  - default difficulty might be jacked up a bit higher, although I don't having anything like a ranking system to 'adapt' to your play in (yet.)

a Taster


http://www.mediafire.com/listen/od9zlka ... nagain.mp3

Expect it to get nastier, harder and technicaly , very fast ..

im thinking a mix of satanic men about town "Deicide" and cello chamber music


MORE DIFFICULT?? ARE YOU INSANE!! :p

[nasty_wolverine]

Some details for the FV remix:

• - music will be by railslave , although I might leave the older soundtrack in as an option
  - gameplay is basically the same as the old Arcade Extra/MegaMedal mode, where clearing an entire enemy formation can wipe out any of their bullets, changing them into medals. If anyone still wants stuff from the other modes (free weapon switch etc.), please let me know... I'll otherwise just be leaving them out totally.
  - most enemies will have totally different movement patterns/behaviors, meaning stages will likely be structured differently as well.
  - default difficulty might be jacked up a bit higher, although I don't having anything like a ranking system to 'adapt' to your play in (yet.)

oh man, more flying v, MOAR!!!

[BPzeBanshee]

I thought the original trippy music fitted in well considering the clusterfuck of colours that was in it. Keep it in.

[heavystylus]

Hey there Gryzor and all

Just commenting to say I'm really looking forward to seeing these released on the Ouya. Gryzor - you do know that the GMS IAP for Ouya is not yet integrated? I was chatting with Mike Daily of Yoyo games the other day and apparently they are 'reworking IAP across the board for a future update, and Ouya IAP functions are part of that'. He could not give me a date tho :/

Anyway, you can still always sell the apk via your site direct using PayPal or PulleyApp.com or similar. Or just release them for free :3

Will definitely be following this thread