• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Gamemaker Studio 3D

A

AndrewC

Guest
I can see YoYoGames gradually adding 3D elements into GameMaker Studio.
However, wouldn't it be better to have 2 separate products, GameMaker Studio 2D and GameMaker Studio 3D with each focused on that type of game.
For people who love GameMaker, like we do, they could have the same IDE, GML, shader methods, export options, DrawGUI, events, alarms, etc, to make the learning curve between the 2 nice and easy, but where it needs to be different, like designing 3D worlds, doing 3D collisions etc, it could be.
 
I say this as somebody who works exclusively in GameMaker's 3D, but it would be pointless. GameMaker's focus was never, and currently will never be in 3D development. It would be a lot of work on YoYo's part just to still be outshone by other engines. GameMaker's specialty is being an easy-to-pick-up 2D development tool; going 3D counters that image. What would the differences really even be between the two, apart from the room editor, in your viewpoint?
 
A

AndrewC

Guest
What you say makes sense.
Historically I've made 2D games and had thought of making 3D games but GameMaker isn't good enough in 3D so I will probably just have to learn Unity3D. So, GameMaker for 2D and Unity3D for 3D. However, it would be nice not having to learn another IDE, programming language etc, but still, such is life.
 

TsukaYuriko

☄️
Forum Staff
Moderator
When the title of the website's index page is literally "Make 2D Games with GameMaker", it makes it pretty clear where the focus is at.
 
S

Sam (Deleted User)

Guest
If you have a look at some things @Lonewolff and @TheSnidr has done you'd be surprised. If you aren't happy with how GameMaker renders your models you can use shaders and/or extensions for that extra wow factor. I also would recommend checking out that 3D tool @Joe Ellis has been working on for a while now.
 

kburkhart84

Firehammer Games
As I understand it, there are still a few limitations to GM's 3d, that despite having shaders as we have now, we can't just bypass. Those limits are much less than they used to be, and much less than people make them out to be(see the above-mentioned projects for proof). But they still do exist. We don't have good access to the full render pipeline at this time...couldn't use geo-shaders if we wanted, are stuck with OpenGLES shaders(unless we use GLSL or HLSL and limit our platform compatibility).

The other stuff, like lack of models' integration, animation, built-in shaders, etc... these are of course all things that can still be added by us. I personally am still stuck between wanting to make and use systems for this, or just using an alternative and calling it done(in the future I mean, right now I'm not messing with 3d).
 

Yal

🐧 *penguin noises*
GMC Elder
Making two separate versions of the same product means twice as many bug reports to fix for half the profit, so it makes no sense from a business perspective.

GM gives you raw vertex buffer access, which is basically the exact thing everything is using at the moment (basically, prepare data to send to the GPU directly for maximally efficient drawing), but the engine support is basically... raw. You don't get walls and floors, you get bricks and mortar. I recently updated a Game Maker 8 project to modern standards just to salvage the 3D level editor. It even has pure-GML skeletal animation, but it's horribly inefficient compared to modern skeletal animation (tons of interpreted trigonometry and multiple draw batches per character).


Vertex buffers basically are everything you need, though - when I ran profiling on MariaEngine64, drawing the entire level (which includes half a dozen surfaces and multiple shaders) took up about half a percent of the total resource load. Granted, I've got a good GPU, but it's still way more efficient than I imagined.
 

kburkhart84

Firehammer Games
It even has pure-GML skeletal animation, but it's horribly inefficient compared to modern skeletal animation (tons of interpreted trigonometry and multiple draw batches per character).
I had Vertex Skinning(loaded a sequence of OBJs) going in gml years ago...it was too slow on my laptop I had at the time just with a couple models...I think it was GM8 though, no YYC of course. It was able to hold over 60FPS on the gaming PC I had at the time though, but yeah, with that performance it was still a dead end. I'll likely do something in the future with 3d and GMS2, but I have too much other stuff on my list to get done first.
 

Andrey

Member
I think that GameMaker Studio 3d would be a good marketing move and the beginning of a new stage in the development of the engine in 3d (2d + 3d in one). Real-time ray tracing in 3d greatly raises the bar for image quality + 3d sound + vr. To bet only on 2d-it is inevitable to lose market share among engines year after year (this is my non-expert opinion). Full 3d functionality provides an opportunity for growth for beginners who started with 2d, but then move to 3d after a while. This makes it possible to save and multiply the clint base. Personally, I am very happy to work in GMS2. But I also understand that I have a growing desire to work with lighting that is only possible in 3d.
 
Last edited:
I think that GameMaker Studio 3d would be a good marketing move
More like buisness suicide. When your competitor offers that, and then some, for free, how can you even think it's going to be a viable product?
If you want to go 3D, the options out there are much better...I mean, you can literally paint pathfinding on the map with the mouse in some engines, so GM still has a long way to go.
I like to see GMS as kind of your first guitar or car. Most will want to upgrade eventually, but nothing quite beats the comfort of something you're so used to work with, even with it's flaws.
And all in all, it all comes down to the guy on the keyboard and his determination to get s**t done.
There was a guy a couple years back, he remade the first HALO (or something similar, can't quite remember) level all in GMS, and it looked quite amazing.
 
How do companies launch their cloud services if competitors have already launched them too? Is it suicide? New technologies attract attention and investment.
Because there's a market share there, unlike in 3D game engines. I mean, what do you really expect, and what is currently not available for either free or dirt cheap? You can already make full-fledged 3D games with only freewares and open-source apps, I much rather Yoyo pushes and refines what they are best at, and work on features people actually want and will use.
 

Amon

Member
I think a 3D Engine, doesn't have to be an Unreal/Unity killer, built into GameMaker to allow dev of 3D Games using the GameMaker way of doing things would be totally awesome.
 

Yal

🐧 *penguin noises*
GMC Elder
Believe it or not, GM is a lot easier to use and better documented than any of the alternatives. A lot of Unity's documentation is outdated, improperly labelled, or only exists as unannotated multi-hour streams. (I don't have first-hand info on this but I can dig up secondary sources on request). Granted, people doesn't need to know how anything works if they can just get assets from a store and mash them together, but just look at how its reputation has tanked to the point that people actively decide to avoid a game if they know it's made in Unity these days... because of people mashing together store assets for a quick buck and/or horribly inefficient and unpolished results.

I think GM doesn't really need a lot of more backend support for 3D... we already have the more dimension-agnostic camera, raw vertex buffer support, structs (better vector support). The big drawback right now is lack of native support for common model formats, and the shader support being limited to an ancient version of GL ES (if you want reliable results on all platforms)

So I'm thinking the work that remains would mostly be front end-focused (which should hopefully mean less work, since the GM GUI doesn't need to be tested on all platform exports?):
  • A new "3D model" asset type which lets you load common formats (OBJ, FBX, whatever... I'm not really an expert on this stuff) which is stored as a 3D mesh in a GM-internal format and then loaded into a frozen vertex buffer when the game is run.
    • Models are untextured and viewed as such in the Model Editor, to match how they're used currently.
    • Opening a model file with bundled textures could pop up a dialog asking if you'd like to import them and create sprites assets as well.
    • Perhaps there could be a "preview textured" option on the model editor which lets you pick a sprite to see how the model looks with it attached.
      • Also maybe there could be an option to set the default texture of this model, to make the room editor workflow easier - see below.
    • Much like for a vector sprite, you can't really edit things in the model editor.
    • Dragging a 3D model onto the "sprite" field of an object will change its representation to use that mesh instead (including in its default draw event) - however you still need to draw it yourself if you want any sort of animation.
  • A new "model layer" for the room editor, which can only be used if you put the room editor in the new 3D mode.
    • (Perhaps "3D room" could be its own new asset type, which is like a normal room but in 3D view and with controls updated to match - e.g. cameras/views are defined using to/from 3D points and a FOV angle instead of an X/Y/W/H tuple)
    • You can place 3D model mesh entities on a 3D layer. They default to their default texture, but it can be overridden much the same way you can change instance variables (also stretching, blending etc).
    • Under the hood, the layer is drawn by a loop that vertex_submits all meshes added to the later.
  • Normal 2D layers are locked to the XY plane at Z = 0.
  • Instances with a model instead of a sprite will do much the same thing, vertex_submitting it in its default draw event. image_xscsale, image_angle etc are used to build the transformation matrix.
  • We need new builtin instance variables: z, zspeed, image_zscale. Perhaps boolean gravity_on_zaxis too?
  • Also some new functions, such as motion_add_3d
  • We could do with some support for mesh collisions as well.
    • Perhaps masks could mimic sprites for consistency and include rectangular prism, ellipsoid, pill (cylinder with spherical top and bottom, useful for taller characters), and "precise" (which means every triangle is checked, SLOW). You want a sphere or pill shape for characters, and precise collision for level terrain meshes.
    • There's new functions point_in_mesh, point_below_mesh, collision_line_mesh, and mesh_in_mesh for manual collision checking.
    • Collision events with a mesh object fires if the meshes overlap. Not sure how to deal with the case when sprite and mesh objects are intermixed.
 

Andrey

Member
Believe it or not, GM is a lot easier to use and better documented than any of the alternatives.
Yes, and that would be a good competitive advantage in promoting the new 3d format!


So I'm thinking the work that remains would mostly be front end-focused
Although a material editor, shaders editor would be useful. And also support for ray tracing, Vulkan.
 

TsukaYuriko

☄️
Forum Staff
Moderator
The question isn't whether it's technically possible - of course it is - but whether it's feasible. It's easy to say that developing feature XYZ just requires you to develop it... but to develop it, you need time and developers. It's easy to say you can fix that by just hiring more developers... but for those to work for you, you have to pay them, provide them with development hardware and/or office space, allow them some time to become familiar with the code base of the product, and all of that costs money or time (and therefore money), isn't guaranteed to bring in any additional revenue that would then generate profit, or to even offset the cost of development. That's where things stop being easy... :)
 

Mert

Member
My decades of journey with Yoyogames has only taught me one thing: If you're not blaming the company's efforts on Game Maker, then you're not getting good updates from it.
 

Bart

WiseBart
If you have a look at the things that have already been made to allow 3D in GM then you'll notice there is a lot already.
If you combine all those and add a bit of code for the things that you need for your game specifically then you'll most likely end up with a pretty decent 3D game.

Admittedly, what could be better is ease of use of all that existing functionality and a somewhat better integration into GM's IDE.
I agree with Yal's points on that, though I think quite a few of them could be solved quite easily:
A new "3D model" asset type which lets you load common formats (OBJ, FBX, whatever... I'm not really an expert on this stuff) which is stored as a 3D mesh in a GM-internal format and then loaded into a frozen vertex buffer when the game is run.
This can be done more or less using local asset packages. Simply define the contents that a package needs to qualify as a valid "3D model asset".
Quite a few model formats seem to be supported already these days. But it would be nice to have some kind of "conversions library" to easily convert between formats internally.
A new "model layer" for the room editor, which can only be used if you put the room editor in the new 3D mode.
This is being worked on, in a way :)
A mapping of layers/groups of models/groups of geometry/... could work equally well, I think.
No need for a 3D mode if you assume a topdown view (with the z axis effectively pointing into the screen).
In-game you can still use any orientation or whatever you'd like. Use euler angles, quaternions, dual quaternions, ...
We need new builtin instance variables: z, zspeed, image_zscale. Perhaps boolean gravity_on_zaxis too?
Simply define a root parent object and define those variables as object variables. Make all objects that need the variables children of that parent object. Modify instance variables in the Room Editor. Provide that project as a clean and ready-to-use template, possibly again as a local asset package (because why not).
I think that's as user-friendly as it can currently get.

I'd like to add to all that proper documentation for people new to using 3D in GameMaker.
And many interfaces, conversions, etc. Proper interfaces between the file formats and the underlying data, between shaders and uniforms, between external software and GM, etc.

So, personally, I'd say there's not really a need for a GameMaker:Studio 3D but rather a need for 3D in GameMaker:Studio.
 

Andrey

Member
The question isn't whether it's technically possible - of course it is - but whether it's feasible. It's easy to say that developing feature XYZ just requires you to develop it... but to develop it, you need time and developers. It's easy to say you can fix that by just hiring more developers... but for those to work for you, you have to pay them, provide them with development hardware and/or office space, allow them some time to become familiar with the code base of the product, and all of that costs money or time (and therefore money), isn't guaranteed to bring in any additional revenue that would then generate profit, or to even offset the cost of development. That's where things stop being easy... :)
I agree 100%!
But this is a vicious circle: no expansion of functionality -> no influx of new clients (newcomers to 3d gamedev) -> no money. On top of that, I see that for many GMS is like a cradle, growing up, they go further. In my opinion, this is very bad. The customer base then grows poorly (money flow also). How many games does the average developer release in their lifecycle while working at GMS? And games are the main advertisement for the engine. The longer the developer at GMS, the better the games are (due to the increase in experience). If the developer, having gained experience, leaves ...
Again, declarations of intent quite spur the audience: we want, we plan, we dream ... something like
 

Andrey

Member
So, personally, I'd say there's not really a need for a GameMaker:Studio 3D but rather a need for 3D in GameMaker:Studio.
Yes!
GMS 2.3 - > GMS 2.4 - > GMS 2.5 ... -> GMS 3.0 (with the development of 3d functionality along with 2d).
 

Yal

🐧 *penguin noises*
GMC Elder
If you have a look at the things that have already been made to allow 3D in GM then you'll notice there is a lot already.
If you combine all those and add a bit of code for the things that you need for your game specifically then you'll most likely end up with a pretty decent 3D game.

Admittedly, what could be better is ease of use of all that existing functionality and a somewhat better integration into GM's IDE.
I agree with Yal's points on that, though I think quite a few of them could be solved quite easily:
This can be done more or less using local asset packages. Simply define the contents that a package needs to qualify as a valid "3D model asset".
Quite a few model formats seem to be supported already these days. But it would be nice to have some kind of "conversions library" to easily convert between formats internally.
This is being worked on, in a way :)
A mapping of layers/groups of models/groups of geometry/... could work equally well, I think.
No need for a 3D mode if you assume a topdown view (with the z axis effectively pointing into the screen).
In-game you can still use any orientation or whatever you'd like. Use euler angles, quaternions, dual quaternions, ...
Simply define a root parent object and define those variables as object variables. Make all objects that need the variables children of that parent object. Modify instance variables in the Room Editor. Provide that project as a clean and ready-to-use template, possibly again as a local asset package (because why not).
I think that's as user-friendly as it can currently get.

I'd like to add to all that proper documentation for people new to using 3D in GameMaker.
And many interfaces, conversions, etc. Proper interfaces between the file formats and the underlying data, between shaders and uniforms, between external software and GM, etc.

So, personally, I'd say there's not really a need for a GameMaker:Studio 3D but rather a need for 3D in GameMaker:Studio.
I mean, I've made a 3D collectathon engine, so I've got a pretty good grasp of what's possible and how to achieve it. But having official engine support for some of these things means new users don't need to track down external tools that might break when something updates (like all existing assets when 2.0 and 2.3 dropped), might be hard to find, might be an additional cost, etc. And making your own 3D room editor from sctatch is such a massive undertaking, I ended up resurrecting a Game Maker 6 project to salvage the one I made back then for said engine. (Granted, I had to replace basically everything piece by piece, but at least I could do it evolution-style with a working product at every step instead of intelligent-design-style)

Especially the "accept a top-down view" thing feels a bit backwards in 2021, we're not living in the age where Doom is the most successful 3D game anymore.

And even though layers might seem like a good fit for different height levels, they're absolutely painful to work with because of a multitude of reasons (you can't easily tell what layer something is on, for instance, so it's very easy to place things on the wrong layer, and you can't get a good feel for the 3D space unless you manually add in your own half-transparent rectangles to fade out things)
 

lolslayer

Member
My take on this is that I hope to see more graphics API functionality made available to the user, and that YYC makes it possible to create extensions to the IDE so that we can create our own internal tools for 3D game development.

There is fundamental OpenGL ES 2 functionality out there that isn't accessible in GMS2. Adding these functions would be a great start.
 

kburkhart84

Firehammer Games
My take on this is that I hope to see more graphics API functionality made available to the user, and that YYC makes it possible to create extensions to the IDE so that we can create our own internal tools for 3D game development.
I've held out for quite a while that this is needed, and would open up so many doors as far as us getting things done. Even in my input system, I wrote the configuration program as a group of rooms, and you have to run a build to get to them, but it would be so much nicer if I could make a custom window in the IDE itself, and that window's code had access to settings, files, assets, etc...

There is fundamental OpenGL ES 2 functionality out there that isn't accessible in GMS2. Adding these functions would be a great start.
This is what I was referring to earlier in this post, that there are simply a certain few things we can't easily do without certain access to the rendering pipeline. Part of that would come with a newer version of OpenGL ES shaders, but the other part would be some access to things that we don't currently have, similar to how they added vertex buffers and custom vertex formats, which aren't just a simple update of the shader language version.
 
  • Like
Reactions: Roa
S

SSJCoder

Guest
I think it's better if they actually make the language a done deal, fix all these floating bugs and really stabilize the product. If you're just going to keep on adding features then what I think is going to happen is that trend of people spending half of their days+ hunting down those bugs.

which seems to be fine with people these days they are used to it (and basically every modern OS has more bugs than ever before). I guess a voice of reason isn't the trend these days. Nevertheless if there is a strategy and hiring options for these things, and assuming the code base isn't a total mess, well, all of that and assuming YYG is open minded and listening to the community, then perhaps it might be feasible.

But given YYG is very quick to shut people down for "wandering about future features" or "rumours about features" "speculation", and the way they handled GMS 2.3 (which was a total mess!), yes, granted, they wanted to release it already after many delays. But, from a wise person's perspective this highlights how effective they are. I'd say YYG isn't the company to ask for such things, and honestly, if they don't get some competent people in there all you will have is this sparkly pretend-product while half the people using their products are actually not being effective because the tool keeps breaking down their projects.

Reality is, as of now, I don't think YYG has what it takes, I'd be more convinced if a team of smart & competent programmers out there somewhere actually came up with an exclusively 3D product inspired by GM's interfaces. That seems like a more realistic goal. Big corporations don't tend to be the biggest pioneers, all you have to do is pay attention to the market and all these companies, where innovation comes from. Where the amazing, effective, bug-free products come from. (which today are a rare breed !)
 
D

Deleted member 16767

Guest
There's still much to do in 2d imo. Like for example, an easy way to actually use your own *.file useable with all surface layers. Having different named surface layers for every stuff is just a billion more code to do.
 

Kezarus

Endless Game Maker
I pick "2D engine that is stable and robust" any day of the year instead of a "proto-quasi-3D" one.

GM should focus on what they are good at, a 2D Engine. I just want it to be bug free and with lots of options for 2D.

Make any effort for 3D support on it will strain an already thin development crew that Yoyo have.

I probably shouldn't say that amidst lots of people defending 3D support, but... ¯\_(ツ)_/¯
 

Roa

Member
More like buisness suicide. When your competitor offers that, and then some, for free, how can you even think it's going to be a viable product?
If you want to go 3D, the options out there are much better...I mean, you can literally paint pathfinding on the map with the mouse in some engines, so GM still has a long way to go.
And yet, people still ask for it year in and year out. And people still do crazy 3d projects against all odds :rolleyes:
The demand is there, and so is the market. You can't say people won't pay more for less cause they've already have been, support be damned.

Yoyo's marketability isn't being the "best 2d engine".
Yoyo's marketability is the fact that they made a custom environment that nobody else offers, that promises quick development times, cross platform support at the click of a button, and a custom easy to use language tailor specifically for game development.

[edit]
Also, there is a big difference between offering all the tools for a 3d game vs simply allowing users access to things that would make building these tools for themselves a hell of a lot easier. It's not like the features requested are useless to 2d either lol.

I'm an avid Unity 3d users and as far as I've gotten with the experience of using it, nothing replaces the actual IDE and language of GMS.
 
I'm an avid Unity 3d users and as far as I've gotten with the experience of using it, nothing replaces the actual IDE and language of GMS.
Same here, bro, to me, no one has a better IDE and workflow than GMS, and going full 3D, and I fear we'd kind of lose that. Don't get me wrong, I'd love to have the equivalenet of their camera tools, serialize options, etc.
and I love GM, otherwise I wouldn't have spent 200$ on something I could get the equivalent of for free, right? But it's a 2D engine, advertised as the "ultimate 2D engine", at that, so I just don't see Santa bringing a 3rd dimension to us in any forseeable future. Honestly, if they would to be bringing full 3D functionalities tomorrow, I would probably leave GMS behind and permanentely switch, as it would probably buggy as heck for years.
 

kburkhart84

Firehammer Games
I've said how I want the plugin system and a bit more 3d stuff as well, but I agree that it isn't my first pick of things they should fix. I agree the language should really get fleshed out better. I'm also of the mindset that they should add static typing to it, either as optional or as a requirement. If they did that, they could then fix issues where all the different variables you have ever declared show up in the auto-complete of any code, anywhere. I think that dynamically typing things like it is now adds more confusion, and then on top of that they can't make auto-complete better because of it, and then on top of that the decreased performance from it...making GML statically typed is pretty much a win all around. There are a couple things you can do with dynamic typing that make actual sense, but most of what we see here works perfectly fine in a static typing language. If nothing else, they could make things static, but have either an extra data type for dynamic, or they could add static typing as an option, though having it as an option means they probably wouldn't go all the way with what benefits that brings.
 

Yal

🐧 *penguin noises*
GMC Elder
I've said how I want the plugin system and a bit more 3d stuff as well, but I agree that it isn't my first pick of things they should fix. I agree the language should really get fleshed out better. I'm also of the mindset that they should add static typing to it, either as optional or as a requirement. If they did that, they could then fix issues where all the different variables you have ever declared show up in the auto-complete of any code, anywhere. I think that dynamically typing things like it is now adds more confusion, and then on top of that they can't make auto-complete better because of it, and then on top of that the decreased performance from it...making GML statically typed is pretty much a win all around. There are a couple things you can do with dynamic typing that make actual sense, but most of what we see here works perfectly fine in a static typing language. If nothing else, they could make things static, but have either an extra data type for dynamic, or they could add static typing as an option, though having it as an option means they probably wouldn't go all the way with what benefits that brings.
I remember one of the big GML head honchos responding to requests for static typing with something along the lines of "you don't wanna know what sort of hoops you need to jump through to get around that in C, stop looking at it like some sort of holy grail". Might not be very high on the "nice to have" list.

Having ideas for how to make autocomplete better in general could be more fruitful (and less work to implement?). Like, say, I've noticed that global arrays consistentlyt don't show up in autocomplete hits, which is a bit of a bummer if you use arrays for absolutely everything.
 

kburkhart84

Firehammer Games
I remember one of the big GML head honchos responding to requests for static typing with something along the lines of "you don't wanna know what sort of hoops you need to jump through to get around that in C, stop looking at it like some sort of holy grail". Might not be very high on the "nice to have" list.

Having ideas for how to make autocomplete better in general could be more fruitful (and less work to implement?). Like, say, I've noticed that global arrays consistently don't show up in autocomplete hits, which is a bit of a bummer if you use arrays for absolutely everything.
I hadn't heard that, but it makes sense. The main thing they "might" be able to do right now with auto-complete is to store what variables are where, and track real-time during code writing what scope things are in, and then filter the variable list to only those variables. It does mean though that they would have to track any time code calls a function too, since instance variables can also be created in global functions. And global functions have no way to know what objects are going to call them, so I see no way to know what variables are available in said functions....static typing won't fix that issue either.
 

Kezarus

Endless Game Maker
I learn to always declare variables at the start of a class. To create variables, mid-code, in a outer function... boi, it grind my gears...

If YoYo really goes for the Variable Definitions features, balls to the wall, and plain and simple deny other variable declarations for instances, that would be very good IMHO.

Of course, one could be free to declare scope variavles with "var", but that only needs auto-complete on, you guessed it, the current scope.
 

kburkhart84

Firehammer Games
I learn to always declare variables at the start of a class. To create variables, mid-code, in a outer function... boi, it grind my gears...

If YoYo really goes for the Variable Definitions features, balls to the wall, and plain and simple deny other variable declarations for instances, that would be very good IMHO.

Of course, one could be free to declare scope variavles with "var", but that only needs auto-complete on, you guessed it, the current scope.
I do the same thing almost always. The only time I have a function that adds an instance variable is if it is some part of a system. For example, I have a thing I do with parent/child objects, but not inheritance, rather transform relationships, where the child object follows the parent around the room. I have one function that adds an instance variable for the parent instance, along with the offsets between parent and child(x and y position). Then another function gets called in each endstep to make the child follow the parent. Having the function add the variables needed for this means I don't need the user of the system to care about it.
 
Top