You cannot see outside your barrier. Yet you are impervious to all strikes from outside it. You pilot the only remaining prototype. Prove the technology works. Your orders: Find and destroy the other existing prototype before it falls into enemy hands. The only things you need to know are your orders… …and what lies within your Engagement Window.
Engagement Window is a bullet hell shmup inspired by my love of early 2000’s doujin shmups, and honestly a ton inspired by Zeroranger.
You play as a mecha pilot, piloting the only remaining prototype for the Engagement Window system - a barrier that keeps the pilot completely safe from everything outside it, while also preventing them from seeing anything outside, as well.
The most important part of any shmup - the chuuni-ass boss approach screen.
This is, of course, represented as the game window itself.
As you play, the window dynamically resizes at your Operator’s command, forcing the player to approach the space differently whenever the screen resizes. I’m also doing some neat meta stuff on top of that, like your Operator’s dialogue box being a completely separate window from the actual game!
(I’ll change this to an embed… when i… learn how to do that…)
I have made a game functionally impossible to properly screenshot.
I’m still in the process of trying to… figure this game out as I make it. Right now, it’s feeling mechanically underbaked. I definitely need a secondary shot type bare minumum.
I think that my current prototype proves that the game’s core concept has legs, but now I just need to find more than the legs. I’d like a torso, at the very least. I don’t wanna be like that one wallace and gromit cartoon with the penguin. you know the one? that one.
uhhh yeah. this is incredibly cinematic. the tweening and effects coming from window edges is really slick. (i think for future ref. you can just drag most vid files into the post editor and it uploads to the site storage… im not sure about embedding from external places)
yeah, including the narrative elements in this system is what really sells the ‘style’ for me here. i’ve seen a couple games that make use of multiple windows but as essentially different views that all look into the same scene. but this is all tied together into this HUD-like feeling. to me the ideal fun would be to spawn up as many windows as possible in that sense, every UI element even flavor ones lol - what sorta limitations do you have when you spread a single app into multiple like that? do they need ways to “communicate” or is it all top-down fed from somewhere?
Oh neat okay! I just wanted to host it offsite for the sake of saving space.
So these actually have the same answer! Previously, the solution I had to this was opening two separate game instances, and the only way to communcate between them was using gamemaker’s debug output to write to a debug file the other game could read. I would then read it, check if the debug message was in a specific format, then parse the format as a command. This, unsurprisingly, sucked! And was bad.
But a GML extension called Window’s Windows came out last week and forced me to rewrite the whole thing. This is, in my eyes, some insane dark magic. It’s all one game instance now. They’re sharing variables, communicating between each other without any tricks, just because it’s all one game. I can do window transparency, moving windows, as many windows as I want - it’s EXTREMELY freeing, and really opened up the options for what this game can do.
right now storage space isn’t a huge huge issue, unless someone is purposefully misusing it. I think there’s a ~20mb upload limit though. I also checked things out and was able to whitelist the domain you’re hosting the video from - so if you just paste the link to the mp4 directly (instead of with .md syntax) it should embed in an iframe now :>
This is a pretty neat idea. Did you have to do anything tricky to get that many bullets working? I have read that bullet hell can be difficult to program performantly.
Honestly, very few so far! Hilariously, the biggest problem is actually less of “processing all the bullets,” and more about actually spawning too many on the same frame making the game unhappy with me. I’ve done some basic stress tests, and I found I can have around 500 bullets onscreen before I notice any real performance hits, and that was before fixing a lot of performance issues caused by my awful hacky multi-window solution. And since my game is very inspired by Zeroranger, which is a lot more bullet light than say, Touhou or Dodonpachi, I don’t really need more than that!
At least so far. I’m going to eat those words one day when I have to rewrite my bullet handler code entirely! But for now, WHO HOO!!
Anyway, the biggest problem was managing bullet behavior, and making sure that the code that manages complex behavior was only running on bullets that have that behavior. That took me a while, but I do this using some scripts I wrote that I, in a fit of melodrama, call the STG System. It ended up being so lightweight and easy to work with, I’m currently using it for enemy behavior, boss behavior, bullet patterns, enemy spawning, basically everything in the game at this point. It’s been really really nice to work with.
Again. For now. One day I will probably have to eat my words and rewrite the whole STG System a fourth time, but for now, WHOO HOO!
don’t really have anything to say besides this looks really neat. i’m a huge fan of anything which breaks the boundaries of what games are allowed to play with
I have objectively better things I should be doing with my time. Quite a lot of them. The prototype level isn’t done, there’s no pause function or start screen. The game also isn’t that fun right now and needs major mechanical reworks to be really even vaguely playable. All of this is dire.
so instead I rewrote my entire UI rendering code to render the UI as separate windows because @twky suggested it and the idea lived in my head completely rent-free for a full week afterwards.
It doesn’t look great but this is more of a proof of concept than anything and honestly the fact that I got it working at all is the greatest accomplishment of my life.
urgh alright i’ll work on things that are actually important now fiiiiine
i like it! I think if there’s one thing ive learned from the community or fans of schmups its that leaning heavily into complex eccentricities is pretty much how to stand out when the gameplay formula is so solidly defined for the genre. im really not an expert but the ones i see that kind of shine to me are really just built around the most archaic and self-indulgent systems
after 6 months. i finished the prototype. At this point it is basically an alpha.
I genuinely think this is the proudest I have ever been of anything I have ever made in my entire life. I am not exaggerating. It’s clunky, it’s mid, it’s mechanically barebones, but I made a prototype for a game. By myself. I made an entire, whole-ass caravan stage. This is a miracle, in my eyes.
hey hey i just ran thru this!! I wrote up some thoughts/experience on my runs with it (spent about 40min before i beat it) that i’ve saved as a draft. lemme know if you’re okay with me posting the full readout as a reply here
my quick thoughts!
yo so i just beat this - probably took me ~40 minutes, and IDK HOW MANY tries. i would not say i’m an experienced shmup player, so in probably its a gamer’s deftness issue on my part. if anything i’d say that the hardest move is probably the one where bullets change direction mid-path? i just havent learned how to program muscle memory in response to bullet patterns as it hasn’t been my genre
i think the moment when the window slices the screen in half is definitely the killer beat of the demo. it’s where your mind immediately goes “oh this mechanic has POTENTIAL”. It feels like a reveal the first time through. I think if you really want to sell the full concept of where the limits are with this, you would then double-down into some kind of attack where new windows spawn to the side that are bullet sources. that would set the full-ish boundaries of the gameplay possibility space you are working with (without having to pull every trick out the hat just yet), in case you need a phase 3 to be able to go pitch this around to folks.
i think the only real weirdness with this prototype is not having a clear way to exit the window, which if i had to guess is mostly just a devtime thing. i will add to this my first couple runs the window zooming away on death made me think it was completely closed so the score screen popping up was a fake out. by the time it showed up i had already launched the game again so i had 2-3 running by mistake.
here’s a couple of the (minor) bugs i ran into:
bugs
not sure how i got this window to persist thru death. The dialogue was stuck at just G but everything closed fine when i quit the app. my guess is tabbing out during an interstitial transition
there seems to be something going on with score/rank duplication. this showed up a couple of times for me, and i think they were both on runs where i got really close to winning, so my actual score woulda been far higher than what i got
Hi there okay so uh. I’d recommend trying the prototype again, it turns out that the build you played uh.
Literally didn’t have 75% of the game in it. Like. there’s an entire. 75% of the game that is just. Not in there. At all. It doesn’t even have the UI I worked so hard on. Oh my god.
I messed that one up real bad, it turns out v04 literally only has the boss fight, there’s an entire stage and shit leading up to it. and that sucks because the boss fight is literally the weakest part of the game by a huge margin imho.
never make builds at 2 AM, folks.
(also the score duplication thing is not actually duplication, it’s what happens when your run has the same score as a score already on the board, it just has the same score on the board twice and highlights both of them as your previous run. it’s not particularly great but it’s a pain in the ass to fix and a lot of shmups do it like that anyway so i’m keeping it)
0v0 and i thought about asking where the health bar and such from the later gif was…
i think it does stand as a measure on its own that the idea presents itself well in the moment tho! ill try to look again in the afternoon
Thank you for the patience!! honestly, it was mostly your note that the slice was the selling point that cued me in that something was wrong, because I thought like. “That’s weird, that’s not even close to the coolest thing I do with the window, I really thought the ramming segment was the coolest thing I did with it. The only way you’d- oh no oh NO OH NO”
ok so im not actually sure I can beat the boss in a longer version of this prototype, ahaha. I’m only making it to the boss with 0-1 health left, at which point its kind of a dead-end to me. out of the kindness of your heart im wondering if there are some thoughts in mind on how to restore health mid fight, maybe performing an execution etc.
Other than that yeah - the presentation is even better than what i played last night. I think an interesting note here is that normally other shmups feel very stationary in that you are just so visually locked onto your ship + everything else is just scrolling past or moving towards you - but the “opening level” being able to constantly change direction and view port gives you a lot more sense of movement across a scene. you start at one point and end up in a lot of different places before reaching the end, rather than just scrolling aimlessly upwards linearly
the only other odd thing i’m picking up on now is it feels like at certain window resolutions the viewport is more or less ‘blurred’ than others, sometimes its nearest neighbor pixel scaling but in motion the viewport looks bilinear. maybe that helps keep things from being jarring during rapid resizes? Not sure if its intentional or something can be worked around later on
so i’m gonna level this is easily the biggest barrier to EW right now. For “some reason”, Gamemaker doesn’t like what I’m doing and is doing everything in its power to stop me from doing it. It seems to change filtering during motion because it’s not meant to be actually doing this, it’s meant to be changing the window size once and then immediately resizing the swap chain to fit, instead, I’m telling it to do it every frame, and then it doesn’t properly resize the camera and surface to match until I’ve finished moving. So in motion it looks really really bad, and I am very scared that the solution is probably going to be having to rewrite the engine’s rendering code to some degree. I swear to god I really don’t want to do that.
