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

[BPzeBanshee]

So I started from scratch and did nothing to the numbers at all and somehow it just works. And it works in GM8 too even though I'm sure I used this exact code before and it didn't work.



In other news these pillows on the wall are very comfortable.

[BPzeBanshee]

In another move straight into the "what the F^&* was I thinking beforehand" territory, I've gone and made several changes to the parent/child structure of enemy parent objects to better improve code consistency and also better support distinction between collidable and non-collidable enemies.

The existing structure basically revolved around obj_en_parent being the main enemy type, and obj_en_ground then having code to fight against being dragged along the screen by the camera controller and the player hitbox colliding with it as if it were a normal enemy. There was also checks on both enemy object->player shot and player shot->enemy object collision events for z depth which obviously was overkill and not necessarily making a lot of sense - a leftover from a much bolder plan regarding 3D enemies. I won't go into details as to what this implies here but obviously this isn't ideal use of inheritance or effective programming at all.

The new system fixes all this. The camera iterates only through obj_en_air now so obj_en_ground children stay in world space as they should. The collision events on obj_en_parent's side no longer check z depth but instead a boolean (or as close as GM will let me to a bool) can_collide which is default set to 1. Child objects simply declare their health in Create followed by event_inherited() which will initialise the parent's related variables and then from there it can override them as it should - for instance obj_en_ground overrides can_collide which means players can fly over said object without colliding as they should (the previous code before worked fine but this is a *better* solution).

I also added a can_damage check in obj_en_parent's events which allows for invulnerable enemies at the flick of a switch. This was originally going to lead to obj_en_wall being a child with can_collide=1 and can_damage=0 but I decided that keeping the wall as an inanimate object with collisions was more efficient than having every wall-based object run enemy code checks that weren't going to be used. For now the only objects that override can_damage are the Omake bosses which have their enemyHP value manipulated by a timer, this stops the jittering effect seen when shooting them.

Now that obj_en_air is being effectively used now this also means that you can make weapons like homing lasers that will prioritise air-based enemies over ground types. obj_en_parent then is only directly used for objects that are themselves extensions of another enemy. For example the Stage 1 platforms consist of obj_en_plat which is a child of obj_en_air and 4 obj_en_platTURs which are direct children of obj_en_parent. The turrets don't need to be obj_en_air children because their positions are being directly manipulated by obj_en_plat anyway.

My next and last area of attack before cracking down on stage 3 is the wobble scroll code. trap15 said it best a while ago, it really should be manipulated by something other than a fixed function formula that is obscure to understand. I'm hoping by calculating an ideal speed value for the x position to be manipulated by, along with keeping tabs on maximum distance from the camera's own x position that clamping the view x and just manipulating the view relatively with keyboard commands will just work. This is the last thing really standing in my way for effective 2P support that doesn't fuck with the view, I just need to think it through more. If anyone has suggestions for handling this please let me know.

[rfeese]

For scrolling in the x dimension or "wobble", I did a calculation based on the player's x position on the screen each frame. So if the player is in the center, then the wobble is centered. If the player is all the way at the left, then the wobble is all the way left. For 2-player, I take the average x position of the two players and use that for the calculation. Then, you probably want to have a maximum speed at which the wobble can scroll if a player dies so that it does not suddenly snap to the new calculated position. For multiple layers of parallax, I apply an additional factor that affects how far each layer scrolls relative to the others.

[BPzeBanshee]

That actually sounds a lot like the current system I have, but mine has become a fair bit more convoluted than I'd like. For reference here's my code:

Code: Select all

// camera Create event
w = max_w/(max_w-240);

// End Step
if instance_exists(obj_player)
then view_xview[0] = x+floor((obj_hitbox.x - x)/w)-x_o
else if max_w > 240
    {
    if xview > x+floor((max_w-240)/2) then view_xview[0] -= 1;
    if xview < x+floor((max_w-240)/2) then view_xview[0] += 1;
    }

TL;DR magic numbers ahoy

x_o is a variable that compensates for the view being offset by 40 pixels when rotated (long story there). max_w is the maximum width you can travel in sprite size notwithstanding, which in my rooms are 320 pixels. Right now it works nicely but my attempts at working two hitbox x positions into have led to very iffy results, and changing max_w dynamically in a way that something like Gradius Gaiden does in its final stage leads to a sudden snap as you describe. How much simpler is yours?

[rfeese]

I had to revisit some old code. Mine's not simpler. What I am doing is similar, except that I am processing things in small time chunks (my game runs based on fixed time steps, with multiple time steps calculated per frame as necessary) and making calculations based on the time chunk. I am doing all position and scrolling calculations in floating point. I have a maximum speed for wobble move (and it is faster than the player speed). Then, I find the target x scroll position based on player x or average of player1 and player2, or center if everyone is dead. Then, move towards that based on the time chunk and max speed. Then I also clamp the position to the target x if it is within a certain range so that it doesn't oscillate or jitter.

[trap15]

A number of arcade games just shift the screen scroll a fixed amount when the player directions are being held, and bounds players within the display screen. So when two players are in, they both affect the screen scroll. Whether this is what you'd like to do is another question.

Another solution I've seen is a "fixed function" scroll, where the scroll position is directly tied to the player X (or in case of 2P, the average of the X positions). To avoid the "jumping", they will just spawn the player back at the same X they died at.

[BPzeBanshee]

I think trap15, I'll probably come up with something closer to your first suggestion as this allows for more freedom in player spawn positions. For now I've dropped plans on it while I've got other things in the works.

One thing I got fed up with recently was a lack of loop point support in audio, long story short I made an Audiere wrapper which is my first foray into C/C++ and have since removed GMFMODSimple entirely out of GMOSSE. The DLL is called GMALP for lack of a more creative title, and removes the last critical part of this that's even remotely anti-dev-friendly regarding licensing. All that's really left to replace in the resource department is the Gleylancer voiceovers and a couple of altered sounds, not counting music files.

The music DLL is a little less fleshed out than I'd like. It supports multiple loop points but the indexes for them are kept in an internal sorted list in Audiere namespace that I can't reliably track from the outside without making my own separate sorted list with the same behaviour, which I don't know how to do yet. I also have no idea how to remove something that's been loaded into memory back out again manually, so naturally using the streaming option is not only recommended practice but essential. In GMOSSE's case it works well enough to adopt and hopefully I'll get around to improving it some more over time - GMOSSE's abstracted music controller code means you can if you wish replace it and stick in a GM-friendly audio engine of your choice without changing actual game code.

[e_tank]

@rfeese (@BPzeBanshee)
your method is exactly how i would suggest approaching the camera scrolling / wobble prob, too. though i disagree in that i think it's very simple solution. just set a target position based on both player's pos and/or other factors and then try to scroll to it by some fixed amount every tick, nothing complicated here

so something like this:

Code: Select all

target_pos = get_target_camera_pos(p1, p2)
camera_scroll = target_pos - camera_pos

// avoid overshoot
if camera_scroll >= 0
    camera_scroll = min(camera_scroll, FIXED_CAM_SCROLL)
else
    camera_scroll = max(camera_scroll, -FIXED_CAM_SCROLL)

camera_pos += camera_scroll
// clamp to bounds
camera_pos = min(max(camera_pos, MIN_CAM_POS), MAX_CAM_POS)

anyway, keep up the great work BPzeBanshee, and kudos to you for keeping your engine open source. it's a shame there's so little open source stg dev, i think it's pretty much just you, Noah! (one-two), and Kenta Cho (that's all i'm aware of at least). also, hows about proper linux support one of these days, i'm keeping my fingers crossed

[BPzeBanshee]

Thanks for the support and the code advice!

also, hows about proper linux support one of these days, i'm keeping my fingers crossed

The shift to Studio has made this very viable now with a little bit of work. The main obstacle I can see is figuring out how to compile GMALP and if necessary Audiere for a Linux environment so you can still have music with loop point support.

If you aren't fussy about that though, an aspiring GM Linux dev can just replace the calls to GMALP functions with the internal ones, switch the USE_SANDBOX var in scr_main_init() to 1, and it'll cross compile for Ubuntu just fine - Zenohell (which was built from GMOSSE and then ported separately to Studio) DID work on a VirtualBox Ubuntu setup in testing but exporting of Debian installer packages (which I think are needed to be accepted for Steam/Ubuntu Software Center) are currently screwed.

[horaceappleton]

Hi! I recently picked up Game Maker Studio, and I was curious if there was any build of GMOSSE that would be useable in GMS rather than Game Maker 8.1 Pro. Please forgive me if there's a simple way to perfectly import the July 2014 build from the OP into GMS that I'm not aware of; naively clicking "Import" made it immediately throw up a window of script errors pointing out obsolete functions.

[BPzeBanshee]

Hi horaceappleton! At the present moment there isn't a public release for GMOSSE that works under Studio but fear not - I do have it working under Studio now, it just needs a bit more time before I can release.

My current plan coming Monday is to bring over the changes from this renderer overhaul to make the render system more feature packed and also readable for all involved, clean up everything I've been messing with and get a release out at some point after that, stage 3 be damned.

[BPzeBanshee]

Ok guys it's out. About damn time, I know.



Last day before my next work week so I won't have the chance to get a video up. Changelog was way too long so I summarised it in the readme.

Download: Dropbox / Mediafire

I also have the original soundtrack folder that made use of Gleylancer and Crue Ball tunes. If you wish to use that download from here, extract to your GMOSSE folder and select the config file for it from the Audio Options ingame.

[Demesejha]

Alright as I begun trying to work on my Danmaku style game, I been trying to work with G.M.O.S.S.E but I can't quite seem to figure out why the game's music just wont load.

I've even tried using the basic music archive distributed with it but still no dice. It just won't load the OGG in game when I run it from the project itself.

Is there a reason for this or a way to fix it? Am I doing something wrong that I'm missing?

[BPzeBanshee]

Could be a few things but can you confirm for me as to whether it works when you export it? I suspect it'll work as intended when actually run from an exported exe rather than the Play button which splits the game's working directory up into several different folders.

EDIT: I got the music to play from the Play button but to get it going but you'll need to consider two factors:

1) At least on my machine it seems GM:Studio 1.x's importing of things into Included Files is bugged - you'll need to include your music.ini as well as your audio files (ie. the music folder) AND make sure they've shown up in the datafiles folder of your .gmx folder system afterwards. It didn't copy over for me so I had to manually copy them into the folder.
2) Once you get this working, because of the way GM does its sandboxing through the "Play button" compile this will copy your music folder into a new temp folder every time you run it - obviously not ideal for rapid prototyping at all. There is an option in Preferences > General > "Automatically clean Temp Data on Shutdown" that will nuke the folder the temp folders are kept in once you close the IDE but it's still not ideal when devving for hours at a time.

For these two reasons the "best practice" method I use to develop GMOSSE is to Export to ZIP (takes about as much time), unzip to a folder with the inis/music and run the game from there. GMS2 was giving me similar troubles a while back, I think it might be the same bug. Will investigate later.

[Avida]

Necroing the F out of this thread because someone (me) is stupid enough to use Gmosse in the year of our lord 2023 but I have some questions I'm too stupid to work out:
-I've seen references to bullet cancelling in some of the sprite names despite not appearing as a feature in the example game. So does Gmosse secretly have bullet cancelling in it already?
-I'm trying to combine the "options" "highscores" and "credits" main menu options into one switch selection similar to the "start game" options. Unless you used voodoo magic, I genuinely have no clue how you did it.
-Still on the main menu topic, despite turning off all references to the warp effect background, for some reason it still shows. What's up with that? Is it in a script somewhere?
That's really all I have for now. I know this is an incredibly old engine that probably nobody uses anymore but it's peaked my curiosity so here we are haha. Many thanks.

Edit: Thanks for the approval mods. I managed (in question 2) to combine those 3 under one selection using the 'case' code already there as a base. Problem is, now if I select that option in the menu, both that option and the "start game" one goes green. I assume it has something to do with those pesky "else draw_set_color(c_green);" lines in the Draw event but it's still pretty confusing.

[BPzeBanshee]

Necro indeed, but it's one I've needed to do for a while, so thanks for posting!

For the record I've still been updating this in the background between putting the defibrillator on Xeno Fighters R some years ago and wrapping up Zenodeath as part of Team Grybanser Fox, all of which has used portions of code here, including migrating it to the current GameMaker (2023.6). If it's of any help, I'm open to sending test builds with source code around, but it's a bit WIP at present - I am working towards getting a Github repo for it when it's ready since that seems to be the mecca for GameMaker development nowadays.

To answer your first question and be straight to the point, the script you're looking for is called scr_clearbullets(). The function that script calls in current public release isn't exactly best practice (instance_change, eww), but use that knowledge to make alterations/improvements as you need, most of the bosses death routines and stage clear controller call it.

About the draw code, it sounds like you've already worked out the 95% of it, but to elaborate, the way GameMaker handles draw routines is that it inherits from previous state. For example if you changed alpha using draw_set_alpha, it'll draw everything else after that at that value, which is why the else statements are there each line. This also applies cross-object too which is why it's good practice to set font, alpha, h/valign and colour before drawing text in any object that you're wanting to do that with. If you wanted to get *really* tricky with stuff like widgets and optimising heavy draw routines, that's where surfaces and setting draw targets come in, but walk first before you run.

[Avida]

Goodness, I wasn't expecting a reply so soon! Thanks for clearing up those queries, because of that everything's acting the way it should be now!
Also had no idea you were behind Xeno Fighters R? It was one of the prime reasons I went with Gamemaker in the first place which brought me here to Gmosse. Funny how life works like that. Speaking of which (XFR, not life) I'm in love with its widget system. Care to give off some pointers on how you achieved it or just wanna keep that on the down low?
Thanks again!

[BPzeBanshee]

Well, funny you should put it that way, that was kind of my experience in 2009: Ed started it, I joined in as a beta-tester, did GMOSSE on the side as a curiosity, the hiatus happened, I got busy with other stuff, then I got the port going in 2018 when I realised it's bus factor of people still having access to the source code became a worry.

As for the widgets themselves, adding some basic examples to GMOSSE is on my to-do list, I'll explain the process we came up with them. Ed basically designed and got the basics of them working first (including the use of primitives for the ship statistics pentacle thingy). Once the appearance was finalised and we had an agreed scale target (1x scale at 1080p), I used surfaces and a bit of user-defined event/object inheritance to come up with a way to draw said widget draw code using the Post-Draw event in a way that updates only when needed so they don't unnecessarily flex your GPU. As a result we have a parent widget object that has all the surface management trickery, and the children objects have the widget-specific code.

[Avida]

Thank you, sounds like you've been extremely busy though so don't push yourself too far.
As for the widgets, that kind of stuff is way over my head haha. I'm still out here using if statements like they're going out of fashion and didn't even know what case/switches were until I looked at your code. Ah well, guess a good background is all you need anyway lol.

[BPzeBanshee]

After yet another conversation with a fellow and realising how many years it's been since I started this project, I've decided that for better or worse I need to kick it out the door and make it available for all to see on Github. I've had a private Bitbucket Git repo for many years as is good practice, but the wider STG and GameMaker community tend to use the former, so I've used Github's migration page to bring the entire project history there.

So here it is. Enjoy.

GMOSSE runs on the latest GameMaker (as of time of writing v2024.2). A final MK-X release build is planned but needs more time for stability checks and real life stuff, after which I'll probably drop the roman numeral moniker and go with normal people numbers or date or something. There is a 'legacy' branch that has the final commit of when the project was running on Studio 1.4.9999 for those curious but I'd highly advise just using the newest GM - it's free for non-commercial use, games made with it run extremely well on modern machines compared to pre-2016 GM, and I've fixed and improved a lot of my own code.

[edusword]

Thanks A LOT for sharing this update. I studied very well this project two years ago, and I learned a lot. Now I can use it in GMS2. Thank you!!