G.M.O.S.S.E - Now on Github! (29/3/24)

[BPzeBanshee]

That might've been it. Been a while, I remember there was other issues as well but can't recall the specifics. Will try your new build once I get the chance though!

[cave hermit]

So I don't understand: is this a standalone application that lets you make shmups, or is this just code that can be integrated into a game maker project?
I'm interested in making games, but I have zero coding ability and I don't have the time to learn a coding language since I'm busy with college; I was really interested in Game Maker, but then I found out that you need to learn the game maker language to actually make a competent game.

[S20-TBL]

So I don't understand: is this a standalone application that lets you make shmups, or is this just code that can be integrated into a game maker project?

It's mostly the latter. You can co-opt the project file itself by replacing the default assets with your own material, or integrate bits and pieces of the code into your own separate project (which I did for certain functions by retrofitting some of the scripts into my own game and crediting BPzeBanshee for it), but you'll need at least a basic understanding of how GML works either way, as well as a registered version of Game Maker (the free version disallows GML usage).

Much of the code is properly commented so it's not really too difficult studying how the engine works, but if you're pressed for time you can check out Suny's own engine on this same forum instead. From what I understand it's drag and drop.

[BPzeBanshee]

S20-TBL nailed it. It's still code, completely GML and eventually will be a fully functional game: you can either make your project from a copy of the project file or use portions of it for something you're making from scratch. If you want something *really* simple but still in this field of things I recommend Warbird (see signature).

GM Lite doesn't so much disallow GML as it does kill a few commands I'd consider essential for even a basic professional game. Externalisation is pro-only, image_angle (dynamically rotating a sprite without pre-baking it in) up til 8.1 or so is pro-only, image_blend for aesthetics, DLL use, etc. GML use is very much allowed in Lite but there's some limitations of course.

[S20-TBL]

GML use is very much allowed in Lite but there's some limitations of course.

Ah. I must have been thinking of 7.0 or an older version then, but I could be wrong. My first serious attempt at a GM game was from 7-8 years ago and I remember not being able to use GML--either that or I didn't bother to yet at that point.

[suny]

Much of the code is properly commented so it's not really too difficult studying how the engine works, but if you're pressed for time you can check out Suny's own engine on this same forum instead. From what I understand it's drag and drop.

Yes, the SHMUP Creator is drag n' drop. It will allow people to make games without code, and is already feature rich.
However, it will never do everything, and will never be as flexible as someone own code.

Learning to code a little and using G.M.O.S.S.E is currently one of the best way to make an original shmup imho.

S.

[BPzeBanshee]

Bought a new graphics card (actually two, HIS Radeon HD 7790s, but mobo only supports one) and ran into a nasty issue with Catalyst Control Center's latest version not liking anything GM-related at all whatsoever. Had to use a driver uninstaller program to wipe the driver slate clean and then install 14.4 (was running 14.9, then the beta 14.11) to get things going again. I miss the blur on the Intel Integrated to be quite frank, but the GPU's power to dual-screen and run everything else I want to run in hi-def is leading me to keep at least this one for now.

Unfortunately as a result I've not been able to really do much of anything GM-related for the last month as a result, so this is basically another post saying things aren't dead, just moving very slowly while my interest and patience is spent on other things.

Oh, btw, I missed one thing in the last screenshot. What's the point of a thunderstorm in a shmup without something in it?



If you happen to realise its full size you can understand why I'm taking my sweet time bothering to program it, especially with what I have planned.

[Squire Grooktook]

So, I tried giving this a shot, having recently aquired Game Maker: Studio. Unlike the previous complaint from Nasty Wolverine on the last page, I was able to successfully import the project from the .gmk file. However, it gives two compile errors (first one is that "screen_redraw" is an unknown function, and second is that "set_synchronization is an unknown function"). I'm guessing this needs to be run on an older version?

(sorry if this is a dumb question, I read through the readme and didn't see anything about this, if I missed something obvious I apologize)

[BPzeBanshee]

Thanks for giving it a spin at least!

You hit the hammer on the nail there - as it currently stands GMOSSE isn't *quite* compatible with GM:Studio yet, so you'll need at least GM 8.0 Pro (which is what I use when working on it) and from there it should run flawlessly. I believe in the scripts that call set_syncrhonization and screen_redraw I have commented out the GM:Studio equivalents, you can try commenting out the current form and uncommenting those but last I checked there's still a few outstanding compatibility issues mainly in either error-spewing or aesthetics. Eventually a GM:Studio port will happen though.

[Udderdude]

Looking forward to stage 3!

[Squire Grooktook]

Thanks for giving it a spin at least!

You hit the hammer on the nail there - as it currently stands GMOSSE isn't *quite* compatible with GM:Studio yet, so you'll need at least GM 8.0 Pro (which is what I use when working on it) and from there it should run flawlessly. I believe in the scripts that call set_syncrhonization and screen_redraw I have commented out the GM:Studio equivalents, you can try commenting out the current form and uncommenting those but last I checked there's still a few outstanding compatibility issues mainly in either error-spewing or aesthetics. Eventually a GM:Studio port will happen though.

Ah, I see. Thank you for the quick response. I'll have to see what I can do on my end.

[BPzeBanshee]

Been doing a lot of changes lately, internally and externally. And I have cool videos to show! Keep reading.

- New title screen. Video here because it looks better in 480p60 motion: https://www.youtube.com/watch?v=Rz55kvJpWHc


- I actually added this in ages ago but Kaiser drew an alternate sprite for Arxyne.


- Simplified some of the homing laser code also. Arxyne not so much but Xonochrome's homing lasers had a bit of confusing duplicate code that could've been simplified so I did so.

- Turns out GMFMODSimple's FMODAllStop() does what it says on the tin, and not what it says in its own description, so music wasn't getting freed properly in some cases. Fixed this and made some changes to obj_ctrl_music to make line-by-line replacement of the engine with something like XeAudiere a lot easier. Yes, Zenohell was a guinea pig for this but I'm not ready to ditch perfect loop point support for GMOSSE just yet.

- Verbose logging is no more. I found it was more annoying than helpful and just produced overhead I don't think most folks need. Make your own logging to fix your bugs, prospective developers. :3

- Bullet colours can now be changed from the options menu under Misc. Settings. You have the choice of plain red, plain blue or the ring^-27-like mode I've had them running for the last two releases where the bullets default to blue and change to red within proximity of or on collision course with the player.

- Sound play commands no longer get called if the sound volume is set to 0. This is to somewhat help alleviate the select few folks who has dedicated (to-crash-and-burn) PCI sound cards with shitty drivers that cause stutters in GM games, and also folks like myself whose legacy PC's sound card actually died and still want to test the game out without noise.

- Enemy spawners are now a thing. By that I mean objects that actually create enemies rather than bullets. Expect to see some of these in stage 3. Speaking of which....

- Stage 3 is slowly taking shape. It's not ready for video footage yet but the big cruisers in the stage have 6 pads that can be dynamically changed on instance creation to turrets of your choice. Enemy spawners are also supported. The giant plane boss has all 50 of its turrets connected and in sync with its (very little) movement, and can be individually enabled or disabled (so it wont rotate and shoot), but nothing else has been done for it just yet. My work with the cruisers and the giant plane involved a bit of two-dimensional array work to keep things sane and it gave me a lot of headaches initially but hopefully the end result will be easy to understand.

- Quite a few 3D-related changes. Stupid crap code in the 3D enemy objects, along with some really abusive use of instance_change that should never have worked before (and doesn't in ENIGMA) is now gone. scr_3D() itself is now really easy to use, simply set your z value on Create and call scr_3D() in Step, no need for extra rising/falling/z_speed vars now since you control your z value yourself (and by yourself i mean in your object of choice).

- I put my simplified scr_3D() and array control to the test and made Raiden II's walking tank boss at 1am this morning. Video here: https://www.youtube.com/watch?v=CppRELf-BBM


Apparently 480p60 videos are a thing now. I was actually running GMOSSE at 720x960 (ingame upscaling at x3, 240*3,320*3) so it really should've been higher rate but this looks nice too and better than the 240p shit I was getting before.

[emphatic]

Great work!

[nasty_wolverine]

- New title screen. Video here because it looks better in 480p60 motion: https://www.youtube.com/watch?v=Rz55kvJpWHc

the particle effects need some work
- Fade out particle alpha over time
- Make the particle speedup over time
- Make the particle get bigger in size
- Randomize the color a bit

It will give the illusion of getting closer over time

[BPzeBanshee]

To be honest I'm considering removing the particles entirely but I'll give your suggestions a go after work.

[BPzeBanshee]

Not much progress on Stage 3 yet, and probably won't be for a while with family matters + Zenohell stuff. I did make three important internal changes you should all know about though:

- firstly, the Virtualbox display hack has been removed, or rather put into a commented-out script that isn't called anywhere. When I ran VirtualBox a while back they'd finally fixed the emulation/wrapper issue that was stopping GM games from expanding correctly in fullscreen so this is simply no longer needed. I keep it in the GMK for historical purposes for now, and when it gets closer to final release I'll most likely delete it along with any other unused data (not that there's much of that anyway, I'm pretty finicky about that sort of thing).

- secondly I made a change to the initialisation room and the script that calls it, scr_main_init(). Instead of having your core controller objects placed in the room with Game Start events to initialise things I've made scr_main_init() (which is called in the room's Creation code so there's no actual objects in the room initially) actually spawn the objects in and what used to be Game Start events in those controllers is now object creation events. This means that now things are initialised not only in a set order but a human-determined set order and not left at GM's whim, which obviously is a better way to program and is immensely more helpful for debugging startup errors.

- thirdly I made spawning of the player hitbox more sane. obj_player has checks in place so if obj_hitbox doesn't exist for whatever reason it doesn't actually care, which should better allow for modification to do stuff like player takeoff intros and that sort of thing without having to use a fake player ship object. obj_hitbox is currently spawned from obj_ctrl_game before the player ship itself is created if it doesn't already exist.

The latter two issues are most likely the last of the old novice mistakes I made when designing this early on and I'm glad I finally got around to remembering and fixing them properly.

Btw, font-spacing issues, sprite transparencies and external file handling aside GMOSSE seems to import into GM:Studio pretty well now. You'll get an error about the command used to set vsync which got replaced with a different command and the pause image system completely breaks but gameplay seems intact. Still a while to go until I get the time to figure these kinks out - if any advanced GM:Studio users have the time and knowledge about these sort of things please get in touch.

[Udderdude]

There's now an official GMOSSE Twitter account! No, it's not a fake. :p

https://twitter.com/gmossepowered

[tiaoferreira]

In my project PIXEL FIGHTERS, I've made a walkspider too, based, of course, on classic boss from Raiden.

ARACNOBOSS, a savage spider killer machine

The first concept with pen


In game version


It moves on four directions, I've not finished the left-right animations, spider bosses are fun to build (and much fun to destroy on game), heheheh!

[BPzeBanshee]

Nice drawing skills you got there man

[tiaoferreira]

Thanks, Sir! The same is valid to you!

[BPzeBanshee]

Thought I'd give a bit of an update on the status of this project.

I feel bad I've left the release over a year old but I assure you this project is far from dead. As a few of the regulars already know and more have guessed it's been put on ice while I've been working with fellow programmers Kaiser and Rozyrg and artist Samurai Fox on the sequel to Zenodyne we released a few years back, Zenohell. Once it's done and out in the world I'll be resuming work on GMOSSE and there's big changes planned which I wanted to bring up here first.

With Game Maker Studio becoming as popular and stable as it is now keeping GMOSSE under the legacy platform is becoming less and less viable for it's original purpose - serving as an example of the right way to code a shmup in GM. I know least one person who hit a brick wall because the current public GMK will not run in Studio without significant code modifications that the average new user isn't going to be very comfortable with, and how can I promote good programming in GM when I'm working with an old IDE that's becoming less and less relevant? Unfortunately that has only one answer - dropping legacy support, dropping the ability to even run this program on my legacy PC which has been so good for performance tests and getting GMOSSE running in Game Maker Studio. So that's exactly what I'll be doing once I get working on this again.

Seeing as Zenohell is built on GMOSSE, in a way I already have the necessary code changes ready for this migration - Kaiser and I went through the transition with Zenohell to great success last month after a fair few headaches. I have workarounds for the stupid sandbox requirement that I've always hated, fonts are working as before if not better thanks to a few new things I've learnt about font sprite structures and code to bring the music code back into GM's much improved internal audio system while keeping similar functionality as before (aside from file format support which nobody cared about anyway). I'm hoping eventually I'll be able to make use of the GMS Professional license I've recently bought on the Humble Weekly Bundle to get this working on other platforms as well like my new Lumia 532, but that's for a much later date.

Once it's working in GMS I'm also going to test putting the GMX project file (since it's no longer in a binary GMK blob) on a GIT repo for backup/management purposes. If it works out I probably would only update that on a per-release basis rather than uploading whatever the current code is in case of stability issues introduced, but it'd provide a few ways to download the project rather than a Mediafire/Dropbox link.

After that the priority will be getting stage 3 complete. What's the stage going to be like you ask? I've mentioned a few of my past inspirations on here and posted a few WIP screenshots so you probably already know it's going to be grand. Turned out a lot of code I had for the giant ship to keep the turrets in sync was working around a stupid oversight of mine so the code for that will be a lot more simple in the future allowing newcomers to make a lot more sense out of the parent/multi-turret enemy system. And yes, there will be an Omake as well, with a familiar face but very new mechanics. When that's out of the way I'll fix up a few things in the previous stages, namely a redo of the stage 1 boss to make things more interesting and possibly some sprite redraws. Expect more multi-part objects and visual tricks in the distant future as well.

Before I go ahead with it all though I'd like to hear your opinions on the subject matter. I can't help but feel I may be leaving a few folks behind going to Studio and I'll try to keep things as version-agnostic as possible if there's a demand for it, but the potential to take this further by propelling it forward has now tipped the worth higher than the trouble.

[BPzeBanshee]

https://www.youtube.com/watch?v=gzDO_iy9owI

After a long day involving me mowing my lawn, getting a severe migraine that no amount of painkillers could remove and a cold shower before bed I had my first spark of coding genius in several months (scrolling at "decimal speed" values = integer speed value / integer delay before actually forcing the event) and rewrote the camera controller (obj_ctrl_screen) to be much less shit. Now it's aptly named obj_ctrl_camera, is not created in Room Creation code or placed in the room via the Room Editor and is instead handled as follows:

Code: Select all

//stage controller create
scr_camera_init(maxwobble,spdx,delayx,spdy,delayy)
//change on the fly
scr_camera_spd(spdx,delayx,spdy,delayy)

For example, going up as shown in the video used scr_camera_spd(0,0,-1,3) which successfully handles a theoretical move speed of -0.33 pixels per step by only executing the move of scrolling objects (and the camera itself) every three frames and offsetting by 1 pixel (-1/3 = -0.33). The old code was a clear case of me overthinking things and didn't work when I wanted to use speed like -0.25 (-1 pixel every 4 steps). I think I can improve on this a bit to just have one script and an instance_exists check for creating the controller instead (its all globalvars anyway) but I need to see what kind of effect altering the maxwobble variable (used to determine distance used for wobble scroll effect) on the fly has on the game.

I think once I implement GMFilesystem to allow for reading/writing things outside GM's sandbox and track down the last of the severe bugs I'm going to release this as MK-IX, stage 3 is still going to be a long way away and I'm a bit too burnt out at the moment to force myself to finish it. The code changes and the fact this is no longer running in legacy Game Maker is a big enough deal for it I think.

[trap15]

Err, is fixed point impossible or something? This delay thing sounds convoluted and weird.

[Giest118]

Err, is fixed point impossible or something? This delay thing sounds convoluted and weird.

Game Maker is good in a general sense, but it's shit in certain very specific ways. One of those ways is that there's no real control over the format it gives to numbers.

[BPzeBanshee]

Let me put it this way - you can't split a pixel and just doing y += 0.33 in an environment where floating points are known to be inaccurate (last I checked that wad inherent in all machines not just GM) is defo weird. For "decimal speeds" just doing an integer value every so many frames makes much more sense to me.

[trap15]

No I mean... Track everything as integers where 256 = 1. So you divide by 256 and floor it to get the screen position. Fixed point.

[BPzeBanshee]

Bear with me here, I'm not entirely sure we're on the same page. Are you proposing to handle decimal speeds by setting for example on y axis view_yview[0] = floor(camera.y/256) and still increment camera's x by integer values?

[e_tank]

according to this page gms doesn't have an integer data type, all numbers are stored as 32-bit single precision floats internally. lua does this as well, but at least they had the sense to default to doubles. on top of that according to this page they use a fixed (instead of relative) epsilon value for comparisons, again wouldn't be an issue on doubles but for singles i can see how that might be a potential gotcha to watch out for. hmm, talk about dumb design decisions for a tool aimed at abstracting away these types of low level issues in an attempt to be accessible to beginner programmers.. (tho at least they allow you to set the eps value)

anyway, might as well use what they give you instead of trying to pound a round peg into a square hole. 32-bit floats aren't necessarily bad, you just have to be a little careful. unless i'm missing some info about gms doing something even stupider than it is, as long as you don't allow your numbers to grow too large you shouldn't have to deal with precision probs. if you're having inaccurate precision probs feel free to post or pm me and i can prob help

[trap15]

Bear with me here, I'm not entirely sure we're on the same page. Are you proposing to handle decimal speeds by setting for example on y axis view_yview[0] = floor(camera.y/256) and still increment camera's x by integer values?

No, why would I be saying that? You could do it that way I guess, but it'd be best to make most coordinates like that. If you're worried about busting float precision you could always use a smaller decimal.

[BPzeBanshee]

Ok, now I know we're definitely not on the same page. I clearly failed to explain the crux of the problem, my apologies. The problem is not with storing decimal values in general but the fact that views (specifically view_xview[0]/view_yview[0]) do not take decimal values at all. As soon as you feed it a decimal value it rounds it - after all you can't split a pixel and these functions are directly tied to the screen. No amount of precision can help with this component.

The original code in my camera controller's method of getting around this was by snapping the views to it's x/y position (which can take decimals), storing a decimal value in a local var and having that incremented. When said variable made it to an integer value the object and therefore the view would then get incremented by that, followed by a reset of said variable. At least that was the original idea.

It became clear to me that rounding within view_x/yview[0] did not occur at the same time in the event order as the rounding in the draw events of objects like the player ship, so what began to happen was the player ship and others would shake wildly when using decimal speeds even though their positions were being updated at the same time. What I ended up with was a complete and utter clusterfuck. The floor/ceil abuse helped solve that somewhat but that code stopped working for speeds less than 0.5/-0.5 entirely. I think in terms of "convoluted and weird" I only have myself to blame for this code.

The rewritten code looks like this. alarm[0]/alarm[1] is just internal timers, I'll probably declare my own vars to make it look less intimidating before release. I know not everyone here is GM savvy but with the common understanding of code we all have I think we can all agree it looks better to understand than the clusterfuck I had before, and functions a lot better as testified by my video. If this is still confusing though I'm open to suggestions as to how to improve it and the associated scripts for it.