What different kinds of games can be made?

BionicDance

Member
Been looking at the website; didn't really see a FAQ.

Been thinking about making a game for a while now, but all the examples seemed to be platformers or other action games...what I didn't see were turn-based strategy games, and I'm wondering whether those are possible.
(Got the distinct impression that FPS games aren't a thing with this engine, but that's okay.)

And what else can you build with it? How about RPGs, for example?
I mean, I'm mostly interested in the strategy stuff, turn-based, but I'd love to know the other possibilities besides platformers and street fighting and such.

Thanks.
 
Anything is possible if you use your imagination.



... and have a thorough understanding of GML. I'd recommend checking out the GameMaker Marketplace (marketplace.yoyogames.com) and looking through the free, open-source projects which are available to you there.
 

chamaeleon

Member
Been looking at the website; didn't really see a FAQ.

Been thinking about making a game for a while now, but all the examples seemed to be platformers or other action games...what I didn't see were turn-based strategy games, and I'm wondering whether those are possible.
(Got the distinct impression that FPS games aren't a thing with this engine, but that's okay.)

And what else can you build with it? How about RPGs, for example?
I mean, I'm mostly interested in the strategy stuff, turn-based, but I'd love to know the other possibilities besides platformers and street fighting and such.

Thanks.
You can do most things (including 3d if you want to, although there's not much support beyond the basic 3d primitives needed to support it). Turn-based strategy or 2D or 2.5D RPGs should be right up there in GMS comfort zone.

\Everything is centered around a "step" model. Objects define events that are fired every step, and instances execute the step code for the objects they implement. What you want to happen every step (running at "room speed", usually 60 or 30 fps) can be whatever you want. Maybe you react to user input all the time every step, maybe you only do it when your game is in a certain state (i.e., it's the player's turn to do something), maybe the game is performing all computations for all enemy units in one step, maybe it spreads up the computation over multiple steps by slicing the work up in suitable chunks. It's really up to you to define the game play and implement it.

Think of this way, every strategy game you have played essentially represent time passing. You "just" need to define what state your game is in as this time passes, and you do that by changing the state (that is, variables and data structures representing your game state) as needed when the appropriate condition (defined by you) occurs or has occurred in the step where you detect or compute this.

Arguably, your biggest challenge is going to be to come up with your game idea proper, and its flow,and the visual elements, etc. If you do this right, GMS should make it relatively easy to implement, while keeping in mind that computer programs are stupid and does exactly and only what you tell it to do.
 

BionicDance

Member
Anything is possible if you use your imagination.
I'd dispute that, but I'd rather not dive down that particular rabbit-hole at this moment. Heh.

I'd recommend checking out the GameMaker Marketplace (marketplace.yoyogames.com) and looking through the free, open-source projects which are available to you there.
I'd already been there, but the problem is that the titles of the games are so truncated and the thumbnails are so small that I can't tell what each game is without clicking on it.
So I was just hoping someone could say, "Oh, yeah...RPGs and turn-based strategy games are totally possible with this engine."
 

BionicDance

Member
You can do most things (including 3d if you want to, although there's not much support beyond the basic 3d primitives needed to support it).
Well, I do 3D CGI (with a very, very old copy of 3DS MAX 2013; can't afford the new stuff anymore), so building 3D models wouldn't be a problem for me, assuming they were importable.

Turn-based strategy or 2D or 2.5D RPGs should be right up there in GMS comfort zone.
Beautiful! Thank you. :)

Everything is centered around a "step" model.
Oh, sure. Like any game, really.

I guess my question was as much about whether action happens continuously or whether you could have the action stop in order for the player to input their commands and have them executed.
And it sounds like...

...maybe you only do it when your game is in a certain state (i.e., it's the player's turn to do something)...
...you can. :)


Arguably, your biggest challenge is going to be to come up with your game idea proper, and its flow,and the visual elements, etc.
Well, as I say, I make CGI art, and I've certainly rendered 3D art into 2D sprites before, so the visual elements won't be a huge challenge. The biggest challenge, art-wise, will be music, cuz I don't do that.
As to the idea for the game, well, I have a few in mind that I've been longing to see but which game companies have declined to make, so I guess it's up to me...

If you do this right, GMS should make it relatively easy to implement, while keeping in mind that computer programs are stupid and does exactly and only what you tell it to do.
Yeah...I remember briefly flirting with BASIC and Pascal when I was a kid and encountered that hurdle all too often.
 

BionicDance

Member
Ooh, here'z another question: can it play pre-made video (like MP4s) for cut-scenes?

And is there a FAQ somewhere that'll answer these kinds of questions without bugging the community?
 

Yal

🐧 *penguin noises*
GMC Elder
You can definitely make both FPS games and turn-based strategy games in GM. Or, well, I definitely can, at least. :p

My YaruFPSEngine is a kinda crappy beginner resource originally made in GM6 and full of sprites made in 10 seconds in MS paint, but it somehow miraculously still works in GMS2 (with a generous dose of compatibility scripts). Performance will be limited since it doesn't have a 3D level editor and GM doesn't have particularly good 3D model support, but it's sufficient for people that think cubes and slanted planes is all they need. I've made two jam-length games with it, but never a full FPS... mostly due to me losing the source file a while back and only recovering it recently, but also I've never quite had an interest in FPS games.


Shattered World is a turn-based strategy game made in the course of 3 months for a competition that spanned an entire summer holiday. It was made in GameMaker Studio 1.x Lite (a now non-existant version that limited access to certain resource types and functions) so it's doing some serious duct taping behind the seams, like using a Timeline resource to store all the level data at different timeline steps. One of the main reasons the project is unfinished is that all the technical debt I built up made the engine impossible to keep working on, with every new feature I tried to add breaking 500 different things and the GMS1 --> GMS2 transition making some functionality I relied on be deprecated. But hey, it'd be even more possible to make it in GMS2, now when you've got stuff like array literals - that'd revolutionized the way I handled statistic data.


Also, last but not least, you can make a fully functional F-zero clone in GM. The main performance bottleneck in Daemon Detective Racing Zero is collision checking, since you need to iterate over a pretty big portion of the track and do collision checkings with every polygon against the cars to make sure they don't pass through a section - GM's main performance bottleneck in general, from my experiences, is GML loops (especially when nested) and this project has them up the wazoo. 3D drawing isn't so bad, since once a 3D model is piped over to the GPU, it's basically just one call to draw it - it's less than 40 calls to draw the entire racetrack (with skyboxes and stuff adding a few extra models) and all the 30 cars, and it's got performance on par with the draw event in one of my 2D platformers. In one of the tech talks, Mike Dailly implied that modern GPUs essentially can draw any polygonal object at the same speed, no matter how complicated it is (basically that's what AAA games needs, so GPU makers optimize for that) and after I lived by those words for a while I mostly found them true from experience - drawing 100 individual triangles basically is 100 times slower than drawing a model with 100 triangles in it.



So TL;DR, use the profiler to check bottlenecks and you can basically do whatever you want. (Unless it's any 3D more advanced than a PS1/N64 game, because then you need to script it on a triangle-by-triangle basis)
 
Last edited:

FrostyCat

Member
When I hear people saying that GM isn't capable of turn-based strategy games, it's because they got their first impressions from people who aren't educated in fine computer science. The "platformers-and-pixels" crowd are almost always designers with a coding side suit, not actual programmers. The ones with a formal background all agree it's 100% doable, whether they have actually done it themselves or not. Oh, and anyone who is old enough to remember Hovendall Tactics would know it's a matter of technique and ingenuity this whole time.

And in case you think this just "theoretically possible" or "small scale experiments only", I'm almost notorious in the GMC for turn-based strategy games by now. Here are a few turn-based strategy games that I developed as experiments or jam entries over the past few years:
You will definitely hear even more from me on this front once the upcoming GML 2020 updates are out, which contain accessor chaining, object orientation and a whole load of goodies that makes genuine AI much less hacky to do. It won't be a free pass from computer science like how GM is usually marketed, but it will be doable for anyone who is willing to dive into abstract data modeling.
 

BionicDance

Member
You can definitely make both FPS games and turn-based strategy games in GM. Or, well, I definitely can, at least. :p
Well, that's good to know. Thanks. :)

My YaruFPSEngine is a kinda crappy beginner resource originally made in GM6, but it somehow miraculously still works in GMS2 (with a generous dose of compatibility scripts). Performance will be limited since it doesn't have a 3D level editor and GM doesn't have particularly good 3D model support, but it's sufficient for people that think cubes and slanted planes is all they need.
Hrm.
Well, FPS wasn't my first priority, anyway, but it's nice to know it's possible. As I said, most of what I saw were more like old-school NES RPGs and street fighters with go-faster stripes, and that there are more options is nice.

That GM doesn't have great 3D model support is disappointing, cuz 3D models are my bread and butter, but I can make do.

Shattered World is a turn-based strategy game
Again, good to know, thanks. :)

I do have one question, cuz this is mildly important...how is NPC movement implemented in GM?
I mean, for example, how easy is it to have an enemy unit move to avoid hazards and to find cover from the player's weapons fire? Is that built in, or do you have to figure out how to code it yourself?
That kind of thing frankly terrifies me, as a non-coder, if I have to do it myself...

Also, last but not least, you can make a fully functional F-zero clone in GM.
Well, that's only completely awesome. :)

3D drawing isn't so bad, since once a 3D model is piped over to the GPU, it's basically just one call to draw it
That seems easy enough.
What about characters? Like, bones and deformations and all that?

So TL;DR, use the profiler to check bottlenecks and you can basically do whatever you want. (Unless it's any 3D more advanced than a PS1/N64 game, because then you need to script it on a triangle-by-triangle basis)
Maybe I should lay my cards on the table a bit more...

I've been kind of disappointed with the directions the X-Com series took after the first game, which I absolutely loved. And since nobody else seems to be making games based on alien abductions and such, it might be up to me to do it.
Now, X-Com 2 and Enemy Unknown were beautiful aesthetically...it was mostly the story and the changes to character movement that I didn't care for. (I liked having actual action points rather than the bizarre two-moves-and-you're-done-and-shooting-ends-your-turn-no-matter-what-move-it-is crapola...yanno?) Well, that, and I liked the base-building in the first game better, as well.
I'd like to do my own version that's more like what I wanted to see...if I can.
 

Yal

🐧 *penguin noises*
GMC Elder
The "platformers-and-pixels" crowd are almost always designers with a coding side suit, not actual programmers.
Which just so happens to be one of GM's core target audiences these days, judging from how a lot of GMS2's GUI is a lot more visual-oriented (connected windows, dragging and dropping assets to connect them, etc). There might be some degree of resonance between the two.

Also, let's not forget that a few decades ago, the main common ground between an RPG
upload_2019-12-26_21-57-11.png

and an action shooter
upload_2019-12-26_21-58-5.png

was that they both were platformers. We see a similar pattern today with RPGs (Skyrim, Pathologic), puzzle games (Portal, Antichamber) and a lot of other genres all being first-person games, but looking back a few years ago, platformers were even more ubiquituous in all of the game industry than they are in the indie games of today. Whether it's because jumping is innately fun, sideview perspective melds particularly well with our landscape-view-oriented savannah brains, or because programmers can't be arsed to draw 4 sprites for a character if they can get away with just having one, there's probably a reason platformers has been around and going strong for so long.
 

BionicDance

Member
When I hear people saying that GM isn't capable of turn-based strategy games, it's because they got their first impressions from people who aren't educated in fine computer science.
As I say, I flirted with programming in high school, but never really got into it, so much. The learning curve was high and my teacher never really explained what it meant to build an engine, so what I made was...well...awful. (I was trying to make something like Zork, but each room was its own bit of code rather than using a central engine that would call out to functions and then come back...I'm probably explaining that badly, so I'm going to plead the you-probably-know-what-I-meant defense. Heh.)
And when I got my hands on a primitive copy of Lightwave 3D, making CGI animation grabbed my interest and never let go.

The "platformers-and-pixels" crowd are almost always designers with a coding side suit, not actual programmers.
I might be flattering myself when I say that I probably fall somewhere between those two...or maybe not.

And in case you think this just "theoretically possible" or "small scale experiments only", I'm almost notorious in the GMC for turn-based strategy games by now. Here are a few turn-based strategy games that I developed as experiments or jam entries over the past few years:
Not quite what I meant by "turn-based strategy games"; I was thinking more like, say, character or military combat rather than board-and-card game type stuff, but I'm sure the basic ideas can be extrapolated...
 

chamaeleon

Member
Well, I do 3D CGI (with a very, very old copy of 3DS MAX 2013; can't afford the new stuff anymore), so building 3D models wouldn't be a problem for me, assuming they were importable.
There is zero support for importing 3d models of any sort unless you look for an extension on the marketplace which implements it for you using the basic primitives (points, edges, triangles).

I guess my question was as much about whether action happens continuously or whether you could have the action stop in order for the player to input their commands and have them executed.
The action "stop" if your step events does not execute a particular code path according to your game state (an if statement checked a variable and decided to not do something because you're not in the correct state). There is no concept of stopping the execution of code in order to wait for something to happen. You have an event loop that is supposed to execute all the time, and every step (30/60 times a second) your code makes a decision what to happen, be it adjusting player position due to a key press, compute full or partial state updates, draw the screen, etc., rinse & repeat. Do not get in the habit of thinking about putting some kind of pause, sleep, or long loop to stop things from happening, just don't perform whatever action in the step event until enough real world time has passed (which you can measure), or some other condition is satisfied.
 

Yal

🐧 *penguin noises*
GMC Elder
I mean, for example, how easy is it to have an enemy unit move to avoid hazards and to find cover from the player's weapons fire? Is that built in, or do you have to figure out how to code it yourself?
That kind of thing frankly terrifies me, as a non-coder, if I have to do it myself...
There's some basic stuff like a grid-based motion planning grid-->path mechanism, and the even more rudimentary "moving straight towards a point and then turning if there's an obstacle in the way". For basic games and grid-based games, it might work okay (though the mp_grid paths get really stiff if your game isn't set on a grid - I'd recommend just getting the path data and then devise a system for moving more naturally from point to point).

That seems easy enough.
What about characters? Like, bones and deformations and all that?
No built-in support. You might be interested in TheSnidr's Model Format and the associated tools, though.
 

BionicDance

Member
Do not get in the habit of thinking about putting some kind of pause, sleep, or long loop to stop things from happening, just don't perform whatever action in the step event until enough real world time has passed (which you can measure).
I phrased myself...not poorly, exactly. Just not as specifically as I could have.
Because what you just said is what I meant, really: "Okay, game...don't do nuffin' else until you get the player's input, uh-kay? Just keep waitin' f'dat before making the enemies go all shooty-shooty again, okay?" ;)
 

BionicDance

Member
There's some basic stuff like a grid-based motion planning grid-->path mechanism, and the even more rudimentary "moving straight towards a point and then turning if there's an obstacle in the way".
I kinna figured this stuff would have to be in there, really.
I was thinking, like...checking line-of-sight kinna stuff. Like--and I realize this will be super hacky--if you needed your code to do something like:

IF player_can_see_enemy THEN move_enemy_to_cover;

That sort of thing.

For basic games and grid-based games, it might work okay (though the mp_grid paths get really stiff if your game isn't set on a grid - I'd recommend just getting the path data and then devise a system for moving more naturally from point to point).
I was picturing a hex-grid, but that might be too complicated for a first time out...?
 

chamaeleon

Member
That seems easy enough.
What about characters? Like, bones and deformations and all that?
To be very clear what GMS supports out of the box you can look at the Primitives section of the manual. You'll see the level of support ends at creating vertex definitions (position, color, etc.), whether a batch is a triangle list or triangle strip, send said vertex buffer to be drawn, etc. You do have shader support, of course, which allows you to do whatever dynamic effects you may desire (to the extent it's possible, I'm not well-versed in shaders).

Without an extension or code from someone else you would end up writing code not dissimilar from this:
Code:
vertex_format_begin();
vertex_format_add_position_3d();
vertex_format_add_colour();
vertex_format_add_textcoord();
global.my_format = vertex_format_end();

v_buff = vertex_create_buffer();
vertex_begin(v_buff, global.my_format);
vertex_position(v_buff, 10, 10);
vertex_colour(v_buff, c_white, 1);
vertex_texcoord(v_buff, 0, 0);
vertex_position(v_buff, 110, 10);
vertex_colour(v_buff, c_white, 1);
vertex_texcoord(v_buff, 1, 0);
vertex_position(v_buff, 110, 110);
vertex_colour(v_buff, c_white, 1);
vertex_texcoord(v_buff, 1, 1);
vertex_end(v_buff);
var tex = sprite_get_texture(spr_Background);
shader_set(shader_prim);
vertex_submit(v_buff, pr_trianglelist, tex);
shader_reset();
 

BionicDance

Member
To be very clear what GMS supports out of the box you can look at the Primitives section of the manual. You'll see the level of support ends at creating vertex definitions (position, color, etc.), whether a batch is a triangle list or triangle strip, send said vertex buffer to be drawn, etc.
Oof. So building and rigging a character in 3DS MAX, importing it into GMS, and creating stock animations that the engine can trigger when needed is...not really thing without plugins or mods, then?

Ah, well. I can make do without it.
 

Rayek

Member
Oof. So building and rigging a character in 3DS MAX, importing it into GMS, and creating stock animations that the engine can trigger when needed is...not really thing without plugins or mods, then?

Ah, well. I can make do without it.
GMS is an excellent 2d game engine. 2D being the key here :)

While 90s retro 3d quality can be achieved with it (Daemon Detective Racing Zero has that nice "DOS 1994 Magic Carpet" quality feel to it), if your needs are anything which even approach current 3d game visuals, you will be fighting a lost battle. Nor does it support (as I learned the other week) OpenGL shader 3 or even 2 - GLES 1.1 is supported only. This by itself limits what you would be able to do from a 3d visual quality point of view.

3D is not its strength nor do the visual tools support these very well, and you will be battling the engine's limits, and its severely limited 3d tools and commands. Let alone importing a rigged 3d character and tying it to a state engine which triggers the animations which then smoothly and seamlessly blend from one character animation to another.

Of course, you could re-invent the wheel, and build your own 3d character engine in GML, right?
Not. A. Good. Idea. This is just wasting your time, and I would strongly suggest looking at a modern well supported 3d game engine which have these things already figured out for you.

In short: unless you intend to create a retro type 3d game, just don't bother with 3D in GMS, in my opinion. Look elsewhere.

You mention you wish to create a RPG/strategy game in a similar vein as X-Com. The original X-Com is 2d isometric, and this is very doable in GMS. It is relatively simple to render your characters as 2d isometric animated sprites in Max, and build an isometric game. In this case no need for true 3d characters. It will vastly simplify the scope of your graphics as well, yet still look very nice (if executed well).

Secondly! Many strategy games rely on an intricate well built and user friendly GUI.

To remind yourself how diverse and deep the original X-Com's GUI is, play it online: https://epicport.com/en/xcom

"But." And this is relatively large "but" depending on how much your time is worth to you:
GMS does not have any built-in support for standard GUI components. As I wrote, strategy games tends to lean a lot on GUI components. When building such a game in GMS, you will have to code a custom GUI system from scratch, and this does put a strain on your development time.

Coding complex expansive GUIs for a strategy game can be a daunting task all by itself. I wouldn't want to think about tackling an X-Com interface with all its screens without at least some help from the game engine itself.

Other 2d/3d engines come with a standard 2D GUI system out-of-the-box, and this can save a boat-load of development time while developing GUI-heavy games, because it avoids re-inventing the wheel once more.

That said, it can be fun to create your own 2D GUI components and system. And it gives you full control. Up to you.

Third, path finding. GMS's path finding only deals with stationary non-moving objects, I believe. Although, with an X-Com derived game you will have to develop your own game AI anyway.

In any case, building a X-Com like strategy game for your first game is (most probably) setting yourself up for failure. Instead of worrying about whether you will be able to import your 3d characters properly (which can be a nightmare to set up for a beginner even in a dedicated 3d game engine with direct support), perhaps try to get a basic 2d version using basic shapes running to see if you are able to create the basic strategy game play.

The original X-Com developer (Julian Gollop) created a bunch of smaller 8-bit strategy games before tackling X-Com with a team of people. Start small, see if things work out, then branch out.
 

BionicDance

Member
Okay, first thing's first..."Rayek"?
As in, the magic-user from the Sunfolk in Sorrow's End? That Rayek?

if your needs are anything which even approach current 3d game visuals, you will be fighting a lost battle.
Yeah...from what I saw on the website, that's what I figured.
But I had to ask...nothing ventured, right?

You mention you wish to create a RPG/strategy game in a similar vein as X-Com. The original X-Com is 2d isometric, and this is very doable in GMS. It is relatively simple to render your characters as 2d isometric animated sprites in Max, and build an isometric game.
Again, from what I saw on the website, I figured.
And I've done that sort of thing before, once for a friend's game and once for an intro to my YouTube videos (I'd totally link the video here, but apparently links require approval, and it's kiiiiiiiind of controversial, what I did, so I'm not gonna.

Secondly! Many strategy games rely on an intricate well built and user friendly GUI.
I'm actually not too worried about this.
I mean, if the commands for doing it are there--as in, "click-this, game-does-that"--then designing the UI and interface won't be that tough. I've done that sort of thing before.

To remind yourself how diverse and deep the original X-Com's GUI is, play it online: https://epicport.com/en/xcom
No need; I have it both on disc and on Steam. :)

"But." And this is relatively large "but" depending on how much your time is worth to you:
GMS does not have any built-in support for standard GUI components.[/quote]

I'm not sure I know what you mean by that, exactly.
If it can do any kind of menu at all--and surely it must have that capability--then creating a UI shouldn't be that difficult. Yes? No?
I mean, surely it has support for clickable buttons; it must. Creating a graphical overlay and adding clickable hot-spots must be built in, or how could any RPG-like game be functional? How could you equip characters, change their weapon and armor load-out if there wasn't some sort of similar interface? Maybe it's not built in, but it you can create the graphics for the menu--have an alpha mask to allow the map to show through, or use a PNG file with a built-in alpha mask, and maybe draw bounding boxes for where the player can click for certain functions--and the genetic test would show that, indeed, Bob is your uncle.
Drudgery, perhaps, for the amount of work involved, but easy enough to figure out.

Maybe I'm wrong.

Maybe I'm completely mis-judging how GMS works since I haven't used it yet--right now I'm just asking about capabilities to decide whether it's worth even trying--but I can't imagine game-creation software that can't do this!

Third, path finding. GMS's path finding only deals with stationary non-moving objects, I believe. Although, with an X-Com derived game you will have to develop your own game AI anyway.
How easy/difficult is that?
I mean, if I'm doing something X-Com-esque, the environment, at least, would be pretty stationary.
My biggest worry would be things like NPCs avoiding the player's line of sight/fire.

In any case, building a X-Com like strategy game for your first game is (most probably) setting yourself up for failure.
You're probably right.

Instead of worrying about whether you will be able to import your 3d characters properly (which can be a nightmare to set up for a beginner even in a dedicated 3d game engine with direct support)
Well, I'm not a total beginner. I haven't said it here, but in my reply to the Intro thread, I mentioned that I've worked in the industry.
That was back in 2001, but still...I scripted cut-scenes at first, and then moved up to level design, all in the Lithtech 3D engine; prior to that job, I'd worked as developer support (artwork side) for Lithtech itself, which is probably the main reason I was hired by Zombie, back in the day.

But I was never a coder, just an artist.
 

Rayek

Member
Yeah, that Rayek. Big ElfQuest fan here since the 90s. :)
One of my favourite characters in the comic.

In regards to GUI building: don't underestimate that task. Simple example: a scrollable list of building or weapons icons which can be dragged to the play field / character interface/inventory. If the game engine has a built-in scrollable field GUI component it's an easy drag and drop in your GUI layer. If that scrollable field must be designed and coded from scratch...

If your game engine offers a full set of pre-built theme-able GUI components and behaviours for responsive behaviour, it will save tons of time. On theme colour or texture change, and all components update to match that, instead of you having to worry about updating all the various elements. It also helps with quick prototyping, because as a developer you don't have to worry about the hassle of creating these in the first place.

Well, it all adds up.

GUI building can take a massive amount of time in my experience. Even simple ones may take time and effort.
For one very simple shooter game I created a few years ago, it took me a week to get the GUI done. Just a couple of standard screens. With support for standard elements this would have taken me a day, or so.

Anyway, just have fun building a 2d prototype version of your game idea. Then decide how to extend it.
 

BionicDance

Member
Yeah, that Rayek. Big ElfQuest fan here since the 90s. :)
One of my favourite characters in the comic.
My last name is 'Fahr'. For a reason. ;)

In regards to GUI building: don't underestimate that task. Simple example: a scrollable list of building or weapons icons which can be dragged to the play field / character interface/inventory. If the game engine has a built-in scrollable field GUI component it's an easy drag and drop in your GUI layer. If that scrollable field must be designed and coded from scratch...
So...scrolling through a list of options/items isn't built into GM? Really?
That seems...bizarre.

I d'know. I'm hoping you're just under-estimating my capabilities because you don't know me.
I'm reminded of the time when I bought a programmable lightsaber that let you add your own colors, effects, and sounds for when it ignites/extinguishes, takes a hit, clashes with another object for any length of time, etc... Everybody told me how difficult it was, how arcane the interface would be...but I watched the tutorials and it seemed super-super easy. And it was; just points on a timeline. Easier than editing video or doing 3D animation, that's for darn sure! The interface had a few unexpected quirks, but what interface doesn't? I had what I wanted ready to go in about an hour.

So I'm hoping that's what's happening here. Hoping. :)
I should find a bunch of tutorial videos to watch; I'm sure YouTube has more than a few. That'll probably show me the possibilities, yes?

If your game engine offers a full set of pre-built theme-able GUI components and behaviours for responsive behaviour, it will save tons of time.
I'm not really sure what you mean by this, but if you're saying what I think you're saying, then I can do it.
If not...then I don't know.

GUI building can take a massive amount of time in my experience. Even simple ones may take time and effort.
Can you be more specific? I mean...what kinds of things do you have to do?

I mean, I'm picturing putting a bunch of graphical elements on the screen, and clicking them triggers certain reactions. Like you click a certain button and maybe the graphic changes to a "pressed" mode, a sound plays, and then an event is triggered, be it a character doing something or opening up a new screen to show character stats/equipment, whatever. And then a button on that screen to go back to the main screen again...
Am I even close?

For one very simple shooter game I created a few years ago, it took me a week to get the GUI done. Just a couple of standard screens. With support for standard elements this would have taken me a day, or so.
What would you consider "standard elements", as opposed to what you had to do?

Anyway, just have fun building a 2d prototype version of your game idea. Then decide how to extend it.
Hell, I might just start with something completely different, simpler, just to see the possibilities.
I can probably come up with something small, as a proof-of-concept. My own version of Galaga, maybe. I d'know. I'll ponder it. :)
 

BionicDance

Member
Oh, yeah...looking at tutorials, this seems pretty intuitive, this system.
And I'm not even afraid of coding, now, because it looks like there is a kind of auto-complete if you start typing in a command, so you can see what's even possible.

I'm gonna have to play with this. Cuz I have ideas. :)
 

Rayek

Member
Check out this scroll list tutorial for GMS:

Compare this with an engine that includes a scroll container component that features all this basic functionality and more. You drop it in, and with some visual configuration and settings it just works.

As a comparison, it is possible to code your own html/css/javascript scroll list for a web form. No-one does that anymore, because browsers have this basic functionality built-in. It is a simple html tag with options that easily takes care of this.

Now imagine having to do a full GUI with tons of screens and popups for a strategy game sporting a default theme . It can be done of course, but I'd rather focus on the game and content itself, rather than having to deal with this type of grunt work.
 

BionicDance

Member
Check out this scroll list tutorial for GMS:
Okay, I see what you mean, now, about it not being built in.

I think that's silly--that's, like, the most basic functionality--but it seems you could write the code for one screen, then copy->paste for all the others, making whatever small tweaks you need, dunnit?

Now imagine having to do a full GUI with tons of screens and popups for a strategy game sporting a default theme . It can be done of course, but I'd rather focus on the game and content itself, rather than having to deal with this type of grunt work.
Well, if you can't make the game without them, if certain styles of games aren't possible because making scroll-bars is a dealbreaker, it seems a bit limiting. I'd rather take the time and make the game I have in my head, personally.
It's like how, in some of my animations, the characters aren't moving right from just key-framing alone, so I'll actually take video of myself doing what they're supposed to be doing, map that onto a plane in the scene so I have visual reference, use that as reference to get the timing and motion right, then delete the plane.
It's a ton of extra work, but it's worth it in the end. At least, I think so, anyway.
 

Rayek

Member
My last name is 'Fahr'. For a reason. ;)
:)
Skywise is my second favourite char... wait - well, actually it's his daughter Jink. The new issue is out which introduces Jink at a very young age. I still haven't had time to purchase the latest issue.

Anyway, it is worthwhile to invest a bit more research in the various popular game engines, play around with each one, and decide which one will fit your project(s) best. At work we use GMS for serious games, at home for my personal projects I switched to an open source alternative this year.

PS All of Julian Gollop's games were played to death by myself. Spent many a night on defeating the aliens in X-COM on the Amiga.

I have been thinking about creating a survival star-base type like game based on a mixed genre with elements derived from and inspired by X-COM, FTL, and a solitaire mini-board game called Deep Space D-6.
 
Not quite what I meant by "turn-based strategy games"; I was thinking more like, say, character or military combat rather than board-and-card game type stuff, but I'm sure the basic ideas can be extrapolated...
This might be helpful to you.


I kinna figured this stuff would have to be in there, really.
I was thinking, like...checking line-of-sight kinna stuff. Like--and I realize this will be super hacky--if you needed your code to do something like:

IF player_can_see_enemy THEN move_enemy_to_cover;

That sort of thing.


I was picturing a hex-grid, but that might be too complicated for a first time out...?
It's possible, but generally AI is very project-specific. My friend helped me with the AI for PROJECT ENIGMA. They're pretty clever, actually. Pardon the frame-rate in this recording. My laptop can't run a game, and capture 30FPS video simultaneously. The best advice I have is to measure twice and develop once. In other words: Plan this step very carefully, and either go into development with a clear plan (or give your programmer clear instructions - if you decide to out-source this bit.)



To be very clear what GMS supports out of the box you can look at the Primitives section of the manual. You'll see the level of support ends at creating vertex definitions (position, color, etc.), whether a batch is a triangle list or triangle strip, send said vertex buffer to be drawn, etc. You do have shader support, of course, which allows you to do whatever dynamic effects you may desire (to the extent it's possible, I'm not well-versed in shaders).

Without an extension or code from someone else you would end up writing code not dissimilar from this:
Code:
vertex_format_begin();
vertex_format_add_position_3d();
vertex_format_add_colour();
vertex_format_add_textcoord();
global.my_format = vertex_format_end();

v_buff = vertex_create_buffer();
vertex_begin(v_buff, global.my_format);
vertex_position(v_buff, 10, 10);
vertex_colour(v_buff, c_white, 1);
vertex_texcoord(v_buff, 0, 0);
vertex_position(v_buff, 110, 10);
vertex_colour(v_buff, c_white, 1);
vertex_texcoord(v_buff, 1, 0);
vertex_position(v_buff, 110, 110);
vertex_colour(v_buff, c_white, 1);
vertex_texcoord(v_buff, 1, 1);
vertex_end(v_buff);
var tex = sprite_get_texture(spr_Background);
shader_set(shader_prim);
vertex_submit(v_buff, pr_trianglelist, tex);
shader_reset();
I saved this snippet of code. Thank you very much.

GMS is an excellent 2d game engine. 2D being the key here :)

While 90s retro 3d quality can be achieved with it (Daemon Detective Racing Zero has that nice "DOS 1994 Magic Carpet" quality feel to it), if your needs are anything which even approach current 3d game visuals, you will be fighting a lost battle. Nor does it support (as I learned the other week) OpenGL shader 3 or even 2 - GLES 1.1 is supported only. This by itself limits what you would be able to do from a 3d visual quality point of view.

3D is not its strength nor do the visual tools support these very well, and you will be battling the engine's limits, and its severely limited 3d tools and commands. Let alone importing a rigged 3d character and tying it to a state engine which triggers the animations which then smoothly and seamlessly blend from one character animation to another.

Of course, you could re-invent the wheel, and build your own 3d character engine in GML, right?
Not. A. Good. Idea. This is just wasting your time, and I would strongly suggest looking at a modern well supported 3d game engine which have these things already figured out for you.

In short: unless you intend to create a retro type 3d game, just don't bother with 3D in GMS, in my opinion. Look elsewhere.

You mention you wish to create a RPG/strategy game in a similar vein as X-Com. The original X-Com is 2d isometric, and this is very doable in GMS. It is relatively simple to render your characters as 2d isometric animated sprites in Max, and build an isometric game. In this case no need for true 3d characters. It will vastly simplify the scope of your graphics as well, yet still look very nice (if executed well).

Secondly! Many strategy games rely on an intricate well built and user friendly GUI.

To remind yourself how diverse and deep the original X-Com's GUI is, play it online: https://epicport.com/en/xcom

"But." And this is relatively large "but" depending on how much your time is worth to you:
GMS does not have any built-in support for standard GUI components. As I wrote, strategy games tends to lean a lot on GUI components. When building such a game in GMS, you will have to code a custom GUI system from scratch, and this does put a strain on your development time.

Coding complex expansive GUIs for a strategy game can be a daunting task all by itself. I wouldn't want to think about tackling an X-Com interface with all its screens without at least some help from the game engine itself.

Other 2d/3d engines come with a standard 2D GUI system out-of-the-box, and this can save a boat-load of development time while developing GUI-heavy games, because it avoids re-inventing the wheel once more.

That said, it can be fun to create your own 2D GUI components and system. And it gives you full control. Up to you.

Third, path finding. GMS's path finding only deals with stationary non-moving objects, I believe. Although, with an X-Com derived game you will have to develop your own game AI anyway.

In any case, building a X-Com like strategy game for your first game is (most probably) setting yourself up for failure. Instead of worrying about whether you will be able to import your 3d characters properly (which can be a nightmare to set up for a beginner even in a dedicated 3d game engine with direct support), perhaps try to get a basic 2d version using basic shapes running to see if you are able to create the basic strategy game play.

The original X-Com developer (Julian Gollop) created a bunch of smaller 8-bit strategy games before tackling X-Com with a team of people. Start small, see if things work out, then branch out.
I disagree with several parts of this post. Although it doesn't have robust 3D options in the box, and I have no experience with developing 3D games personally... it seems to me that you'd want to build a lot of the framework by yourself... but I'm only speculating.

In my opinion: The best reason to choose GameMaker is the desire to export your game to any platform - with a minimal amount of platform specific configuration.

There are some excellent GUI frameworks available which (seems) like it would be 2D even in a 3D game 99% of the time. I'm particularly fond of this one: https://github.com/Kezarus-tech/Monastery-Framework

There are some 3D extensions/projects on the GameMaker Marketplace which (seem) decent.
You're probably right about starting with 8-bit / 2D games and working up, but as a wise old-man once told me: TAKE ANY ROAD YOU WANT.

- - -

One last thing: I like the way you think @BionicDance. I hope that you decide to "stay a while" and keep us informed on your project(s.) I'm not an artist or a programmer (I've always gravitated towards Game Design myself.) Don't hesitate to contact me if you have room for an occasional volunteer-collaborator.

Have a wonderful day, everyone.
 

Rayek

Member
Although it doesn't have robust 3D options in the box, and I have no experience with developing 3D games personally... it seems to me that you'd want to build a lot of the framework by yourself... but I'm only speculating.
As a programming exercise, perhaps. But even if you did, it is just not possible to arrive with GMS at the same high standard of 3d rendering like (for example) Unity, Unreal Engine, or Godot. And there is no need to re-invent the wheel in those cases either. Import your 3d model(s), set up your camera and 3d scene in the 3d scene editor, and start coding the game logic. Basic stuff like 3d collisions, ray casting, a true wysiwyg visual 3d viewport while developing, seamless 3d animated model import... It's all there. And at a quality and ease-of-use that an individual developer couldn't hope to match (not within acceptable time and effort limits).

I am not saying no-one should attempt to do any 3D in GMS - far from it. If you are already proficient in GMS, and wish to create a retro-style 3d game in it, go right ahead. What I am saying is that a dedicated 3d game engine will make your 3d game development experience much easier, efficient, and more pleasant. 3D game development is hard enough as it is. Why make it even harder by adopting a purist approach?

Game Maker Studio is a 2d game engine, and excels at that. This year I dabbled a bit in Unity to see how 2d works in it - and absolutely hated it. Some people have made 2d games in Unreal engine. Even experienced Unreal users advice against that.

Use the right tool for the right job, I'd say. For 2d games, GMS is an excellent and proven choice. For 3D games you'd just be making your game dev life more miserable and the end result just cannot hope to compete with the dedicated 3D game engines.

That said, combinations of 2d/3d are possible too, and depending on the scope of this, GMS may still be a good choice. 90% of your project could be 2D, with 3D animated characters laid on top of 2D environments/maps.

In short: it depends on your project, your intention, your game design and graphical style. But I stand by my opinion that for 3D games GMS is a less than optimal choice (understatement), just as I think that anyone building a 2d game in Unreal is hammering a nail with a steam roller. Decide on your development tools based on the requirements of the project at hand, not the other way around.
 
As a programming exercise, perhaps. But even if you did, it is just not possible to arrive with GMS at the same high standard of 3d rendering like (for example) Unity, Unreal Engine, or Godot. And there is no need to re-invent the wheel in those cases either. Import your 3d model(s), set up your camera and 3d scene in the 3d scene editor, and start coding the game logic. Basic stuff like 3d collisions, ray casting, a true wysiwyg visual 3d viewport while developing, seamless 3d animated model import... It's all there. And at a quality and ease-of-use that an individual developer couldn't hope to match (not within acceptable time and effort limits).

I am not saying no-one should attempt to do any 3D in GMS - far from it. If you are already proficient in GMS, and wish to create a retro-style 3d game in it, go right ahead. What I am saying is that a dedicated 3d game engine will make your 3d game development experience much easier, efficient, and more pleasant. 3D game development is hard enough as it is. Why make it even harder by adopting a purist approach?

Game Maker Studio is a 2d game engine, and excels at that. This year I dabbled a bit in Unity to see how 2d works in it - and absolutely hated it. Some people have made 2d games in Unreal engine. Even experienced Unreal users advice against that.

Use the right tool for the right job, I'd say. For 2d games, GMS is an excellent and proven choice. For 3D games you'd just be making your game dev life more miserable and the end result just cannot hope to compete with the dedicated 3D game engines.

That said, combinations of 2d/3d are possible too, and depending on the scope of this, GMS may still be a good choice. 90% of your project could be 2D, with 3D animated characters laid on top of 2D environments/maps.

In short: it depends on your project, your intention, your game design and graphical style. But I stand by my opinion that for 3D games GMS is a less than optimal choice (understatement), just as I think that anyone building a 2d game in Unreal is hammering a nail with a steam roller. Decide on your development tools based on the requirements of the project at hand, not the other way around.
Word.

@BionicDance -- take a look at the "Made with GameMaker" forum and even the "Work in Progress" forum for hundreds of raw examples by GameMaker users of what can be made using GameMaker.
That, too.

So... I collect/hoard tutorials and after this conversation I decided to "dig through my archive" and round up some which I think may be of interest to you. These range in complexity, newness, and length... but it should give you a basic idea of "what you're in for" hypothetically based on what I know about your goals:

Edit: Here are some official, written tutorials for GMS2 also.
The "platformers-and-pixels" crowd are almost always designers with a coding side suit, not actual programmers.
It's a little bit rattling whenever someone points it out to me that I fit a(ny) stereotype... but you've pegged exactly right. Touché.

One last thing. I could have sworn that I read something last month about a new feature in GMS2 which will specifically help with cut-scenes... but I can't find it anywhere. Someone halp me. Did I dream that? :confused:

Edit: Edit: Here's a few marketplace projects relevant to your questions about NPC AI.

Sorry for the long post and so many edits, but you're asking a lot of good questions and I've got things bookmarks for many of them.
 
Last edited:

BionicDance

Member
You're probably right about starting with 8-bit / 2D games and working up, but as a wise old-man once told me: TAKE ANY ROAD YOU WANT.


One last thing: I like the way you think @BionicDance.
Aww, shucks. :) You'd be surprised how many people take the exact opposite position on that matter.

Plus, as I say, I've worked in the industry a bit, and I think that experience will help me get started just thinking as a developer. I'm sure a lot of folks come to GameMaker with big dreams of making their own game and with not the tiniest clue of what goes into making one, and their expectations are...unrealistic. But having been frustrated, disappointed, and failed in the past is a real teacher, innit? I have stories... Heh.

I hope that you decide to "stay a while" and keep us informed on your project(s.) I'm not an artist or a programmer (I've always gravitated towards Game Design myself.) Don't hesitate to contact me if you have room for an occasional volunteer-collaborator.
Thanks! I think I will stay for a while.
I mean, my first post, I kinna asked some seriously n00b-y questions, and rather than responding with a lot of "RTFM!" and eye-rolling, you guys stepped up, welcomed me, and, darn it, actually answered my questions. If nothing else does, that makes me want to stay.
You folks internet right. ;)
 



Aww, shucks. :) You'd be surprised how many people take the exact opposite position on that matter.

Plus, as I say, I've worked in the industry a bit, and I think that experience will help me get started just thinking as a developer. I'm sure a lot of folks come to GameMaker with big dreams of making their own game and with not the tiniest clue of what goes into making one, and their expectations are...unrealistic. But having been frustrated, disappointed, and failed in the past is a real teacher, innit? I have stories... Heh.
Well, we get some folk who should be asking these kinds of questions but don't. Then get overwhelmed when they realize that making video games is not an easy thing to do (even with the right tools for the job.) They'll then come here with the expectation of instant-answers to their problems. They don't usually stay long. They tend to storm off and then... probably do something similar on the Unity forum another forum.

Thanks! I think I will stay for a while.
I mean, my first post, I kinna asked some seriously n00b-y questions, and rather than responding with a lot of "RTFM!" and eye-rolling, you guys stepped up, welcomed me, and, darn it, actually answered my questions. If nothing else does, that makes me want to stay.
You folks internet right. ;)
Welcome to the GameMaker Community. It's a neat place. The regulars here are tremendously helpful (as long as you try to help yourself to the best of your ability.)

Your vague mention of industry experience has piqued my curiosity a bit. I'm a serial-failure-entrepreneur myself (but I'll never, ever, stop making games because it's literally the only job I've ever wanted.)

The closest thing I've ever had to a job in the video game industry was a seasonal Q.A. position at a company known for a very popular World of Warcraft add-on.
 
Last edited:

Rob

Member
@BionicDance There are some decent tutorials on YouTube if videos are your thing.

To learn how to make a Turn Based Strategy game - sergeant indie helped me get on my feet in terms of creating A* pathing code and there are plenty of tutorials featuring turn based mechanics.

Gamemaker has its own functions for path finding that you can also use.

I think the main limiting factor is your knowledge of GML as @SilentxxBunny said, as well as your own tenacity.

When I coded my first turn-based RPG battle system I had to really sit down and think about the order in which I wanted everything to happen. It's not enough to just wing it, you need to be able to understand how everything is going to interact with everything else - when the player presses "OK" - what should be happening at any given time? Should a message be played? Should the next character get their turn? Is an attack being performed? Is this code going to create a conflict and mean you need to rethink something?

If you're not used to coding then it can be a little tricky at first (as I found it) but the hours you put into this hobby/career will pay off eventually. Just make sure those hours are actually useful and not spent changing 1000 lines of global variables when a for loop + array / data structure would have reduced the time investment 900%.

I always seem to have to learn the hard way and make every mistake you can make but if you're not like me you'll advance a lot faster!
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
I totally agree with Rob! Whenever something is tedious - figure out a way to let the computer do it for you. Using scripts instead of repeating code (and then having to change every copy if you find a bug) is a good starting point, and then you can work your way up from there.

One of my recent achievements is some auto-tiling code... I got fed up having to spend ages first making nice slopes for the player to walk up on and then place decorative tiles, so I added a mode to the level editor that fills in a shape you outline automatically. It's got some caveats (like only being able to autotile either up or down, not between two sloped lines, and picking tiles from a very specific region of the tileset) but those were mostly a necessary evil to make implementing the feature simple. It's good enough to meet my demands, at least (I could make 48 levels in just a few hours).

(This is actually from an asset pack I recently released, in case anyone's interested)

You might ask yourself why I made my own level editor instead of using the room editor... there's actually a bunch of reasons.
  • The project needed to be compatible with both GMS1 and GMS2, so a custom room format would help keeping it unitary between them
  • The project handles a lot of map data automatically, and that only works if there's a way that data can be generated in the first place
  • Felt like a fun challenge to attempt
  • I don't like the GMS2 room editor and wanted to avoid it :p

Another example... I'm currently working on a Pokémon clone asset, and earlier today after realizing most attack animations would do essentially the same thing (go through objects one by one, and spawn some sort of effect for each target), I broke out the code for those into a script. The effect itself had to be broken out from the script logic (since it would be different for each attack animation object) and I ended up putting it in User Defined Event 0 so I wouldn't need to have an unique script and an unique object for each attack animation.

Code:
///fx_deferred_effect_loop_state_machine()
switch(state){
   case 0:
       current_target = 0;
       state++
       cntr = 0
   break
  
   case 1://Step
       cntr--
       if(!cntr){
           if(current_target >= array_length_1d(target)){
               instance_destroy()
           }
           else{
               cntr = 30
               with(target[current_target]){
                   with(other){
                       event_user(0)
                   }
               }
               current_target++
           }
       }
   break
}
Right after doing that, I realized that most of the attack animations would spawn a projectile object that would create other effects when it hit the target, so I added another convenience script to automate that as well - it just takes a sprite and an effect script as arguments and handles everything else automatically - computing the coordinates to shoot between, projectile lifetime, depth... it's a bit of a kludge since it uses object instance variables and the call stack instead of just arguments (notice how it relies on the with(target)--> with(other) call order to function since it uses "other" to get the original target!) but it's so convenient to be able to program the effects with just one line of code I'm willing to sacrifice my coding style to keep my mind intact :p
Code:
//fx_deferred_projectile(sprite,hit_effect_script)
//Used in event_user[0] of a battle-effect only.
//Shorthand to create a projectile effect that might spawn another effect in turn when it's destroyed.
var trg = other.id, n;
with(user){
   var dir = point_direction(x,y,trg.x,trg.y), len = point_distance(x,y,trg.x,trg.y)
   n = fx_sprite_projectile(argument0,1,x,y,dir,8,dir,0,0,0,len/8,argument1,trg)
   n.depth = depth + 1
}
return n
 

Rob

Member
I had a similar "Eurika" moment whilst working on my Tactics Tutorial system.

When a character takes their action, apart from moving, they're either going to make a physical attack, cast a spell, or use an item.

I always had the 1-tile physical attacks as a separate thing from how magic aoe or other more complicated things would work in my head but it's actually the same thing and just goes to show how I'm still looking at games from an outside perspective rather than from inside.

All the attacks, spells, and items can all use the same code:

[Whats the target tile?]
[Play animation for current actor]
[When target tile is reached check for effect - this could be AoE. a single flame bolt or the swing of a sword]
[Work out the effects for each affected actor]
[Job done]

It all seems so simple now but this kind of issue rears its head a lot!

Ps can't sleep as gf is breathing on me heavily and... I don't like it!
 
  • Like
Reactions: Yal
I totally agree with Rob! Whenever something is tedious - figure out a way to let the computer do it for you. Using scripts instead of repeating code (and then having to change every copy if you find a bug) is a good starting point, and then you can work your way up from there.

One of my recent achievements is some auto-tiling code... I got fed up having to spend ages first making nice slopes for the player to walk up on and then place decorative tiles, so I added a mode to the level editor that fills in a shape you outline automatically. It's got some caveats (like only being able to autotile either up or down, not between two sloped lines, and picking tiles from a very specific region of the tileset) but those were mostly a necessary evil to make implementing the feature simple. It's good enough to meet my demands, at least (I could make 48 levels in just a few hours).

(This is actually from an asset pack I recently released, in case anyone's interested)

You might ask yourself why I made my own level editor instead of using the room editor... there's actually a bunch of reasons.
  • The project needed to be compatible with both GMS1 and GMS2, so a custom room format would help keeping it unitary between them
  • The project handles a lot of map data automatically, and that only works if there's a way that data can be generated in the first place
  • Felt like a fun challenge to attempt
  • I don't like the GMS2 room editor and wanted to avoid it :p

Another example... I'm currently working on a Pokémon clone asset, and earlier today after realizing most attack animations would do essentially the same thing (go through objects one by one, and spawn some sort of effect for each target), I broke out the code for those into a script. The effect itself had to be broken out from the script logic (since it would be different for each attack animation object) and I ended up putting it in User Defined Event 0 so I wouldn't need to have an unique script and an unique object for each attack animation.

Code:
///fx_deferred_effect_loop_state_machine()
switch(state){
   case 0:
       current_target = 0;
       state++
       cntr = 0
   break
 
   case 1://Step
       cntr--
       if(!cntr){
           if(current_target >= array_length_1d(target)){
               instance_destroy()
           }
           else{
               cntr = 30
               with(target[current_target]){
                   with(other){
                       event_user(0)
                   }
               }
               current_target++
           }
       }
   break
}
Right after doing that, I realized that most of the attack animations would spawn a projectile object that would create other effects when it hit the target, so I added another convenience script to automate that as well - it just takes a sprite and an effect script as arguments and handles everything else automatically - computing the coordinates to shoot between, projectile lifetime, depth... it's a bit of a kludge since it uses object instance variables and the call stack instead of just arguments (notice how it relies on the with(target)--> with(other) call order to function since it uses "other" to get the original target!) but it's so convenient to be able to program the effects with just one line of code I'm willing to sacrifice my coding style to keep my mind intact :p
Code:
//fx_deferred_projectile(sprite,hit_effect_script)
//Used in event_user[0] of a battle-effect only.
//Shorthand to create a projectile effect that might spawn another effect in turn when it's destroyed.
var trg = other.id, n;
with(user){
   var dir = point_direction(x,y,trg.x,trg.y), len = point_distance(x,y,trg.x,trg.y)
   n = fx_sprite_projectile(argument0,1,x,y,dir,8,dir,0,0,0,len/8,argument1,trg)
   n.depth = depth + 1
}
return n
https://yaru.itch.io/monster-collector-engine
 
I mean, I'm picturing putting a bunch of graphical elements on the screen, and clicking them triggers certain reactions. Like you click a certain button and maybe the graphic changes to a "pressed" mode, a sound plays, and then an event is triggered, be it a character doing something or opening up a new screen to show character stats/equipment, whatever. And then a button on that screen to go back to the main screen again...
Am I even close?
So even for something that seems relatively simple like this, it both is and isn't. It's very easy to have a graphic change and some script+sound run when clicked. But what happens if you have two buttons overlapping (i.e. you click something, which spawns a menu and part of that menu is covering the original interface that you clicked, where buttons are). Naively, people assume that when they click on that second menu, only the second menu will be triggered, but -anything- under the mouse will trigger on the click, meaning that background buttons can be clicked even when covered with another button in the foreground. This means you have to build some sort of depth system in. But what happens if you want the background area to still be clickable while the foreground menu is open UNLESS it is directly covered by a foreground menu. You'll have to take this into account as well when developing your depth system and so on and so on.

There's a lot of potential things that can become screwy when developing even a simple GUI system from scratch, let alone a complex one.

Also, by the tenor of your questioning, I get the feeling that there's something that you're not quite grasping about GMS. When people say you can do anything, that's because GML is rather flexible for a scripting language built on top of a game making program, and there's very little things that you simply -cannot- do with it (I mean, there's really nothing that you can't do with it, but in order to do some things that you can in "real" languages, you'll often have to bodge together an alternate method of achieving your goal). It's not so much can GMS do something, but rather do you understand comp-sci and game programming in general well enough to be able to realise your goal.

For instance, a turn-based game programmed in GML is, in general, very similar to how you would program one in Java or something. If you have trouble thinking through the actual way that you would program a turn-based game in -any- language, then you'll have trouble programming it in GML. If you understand how to program a turn-based game in any language you choose, you'll have very little trouble programming one in GML. So the limitation is not so much in the programs feature set, but in your feature set instead.

Unless you are wanting to program a new Fortnite or something (which you've already mentioned is not your goal), your best bet is to focus on learning the syntax of GML and game programming loops rather than focusing on whether GMS can or can't do something (with the caveat, already mentioned, that some other tools might be better suited to some tasks, though not impossible in GMS).
 

Yal

🐧 *penguin noises*
GMC Elder
So even for something that seems relatively simple like this, it both is and isn't. It's very easy to have a graphic change and some script+sound run when clicked. But what happens if you have two buttons overlapping (i.e. you click something, which spawns a menu and part of that menu is covering the original interface that you clicked, where buttons are). Naively, people assume that when they click on that second menu, only the second menu will be triggered, but -anything- under the mouse will trigger on the click, meaning that background buttons can be clicked even when covered with another button in the foreground. This means you have to build some sort of depth system in. But what happens if you want the background area to still be clickable while the foreground menu is open UNLESS it is directly covered by a foreground menu. You'll have to take this into account as well when developing your depth system and so on and so on.

There's a lot of potential things that can become screwy when developing even a simple GUI system from scratch, let alone a complex one.

Also, by the tenor of your questioning, I get the feeling that there's something that you're not quite grasping about GMS. When people say you can do anything, that's because GML is rather flexible for a scripting language built on top of a game making program, and there's very little things that you simply -cannot- do with it (I mean, there's really nothing that you can't do with it, but in order to do some things that you can in "real" languages, you'll often have to bodge together an alternate method of achieving your goal). It's not so much can GMS do something, but rather do you understand comp-sci and game programming in general well enough to be able to realise your goal.

For instance, a turn-based game programmed in GML is, in general, very similar to how you would program one in Java or something. If you have trouble thinking through the actual way that you would program a turn-based game in -any- language, then you'll have trouble programming it in GML. If you understand how to program a turn-based game in any language you choose, you'll have very little trouble programming one in GML. So the limitation is not so much in the programs feature set, but in your feature set instead.

Unless you are wanting to program a new Fortnite or something (which you've already mentioned is not your goal), your best bet is to focus on learning the syntax of GML and game programming loops rather than focusing on whether GMS can or can't do something (with the caveat, already mentioned, that some other tools might be better suited to some tasks, though not impossible in GMS).
To be fair, having interface elements be able to cover each other is pretty bad UX design (apart from the aforementioned issues of which elements can be interacted with being unclear, you can end up hiding vital information from the player this way), ideally you should have submenus spawn at free space... this also makes the flow from step to step clearer. If you look at most "boring" utility applications like Outlook or Excel, you'll see that the only time they really spawn an UX element on top of another is when you open a separate window, and usually that steals focus from the main window entirely until you close it. The ribbon menu has a "main" area that changes states as you click the different menu types listed on top (File, Edit etc), there's a "main stuff" area which is wholly separated from the menus state-wise. Things like that wouldn't be too hard to emulate with GM's views, now when I think about it...
 
To be fair, having interface elements be able to cover each other is pretty bad UX design (apart from the aforementioned issues of which elements can be interacted with being unclear, you can end up hiding vital information from the player this way), ideally you should have submenus spawn at free space... this also makes the flow from step to step clearer. If you look at most "boring" utility applications like Outlook or Excel, you'll see that the only time they really spawn an UX element on top of another is when you open a separate window, and usually that steals focus from the main window entirely until you close it. The ribbon menu has a "main" area that changes states as you click the different menu types listed on top (File, Edit etc), there's a "main stuff" area which is wholly separated from the menus state-wise. Things like that wouldn't be too hard to emulate with GM's views, now when I think about it...
Very true, but like with most things, it really depends on the project. Perhaps you want moveable UI elements, and the player places them in a position where they can potentially clash. Perhaps there's a popup menu for units on the screen, which depending on the placement of the unit could cover or go under particular UI elements. Of course, you can spend time coding it so these situations don't happen, but that then increases the complexity of what you are trying to do, hence the hidden difficulty of creating a GUI system from scratch.
 
Top