• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • 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.

 Suggestion: Headless export

Spasman

Member
I've been using Game Maker for a very long time, for just about over a decade. One feature I've wanted since high school was the ability to run your dang game without a video card for server usage.

Now, the first thing you're going to tell me is to write a server in Java or some other language. Yeah, I've already done that, a friend and I wrote a server list for my last game in Python. That solution is great if all you are doing is sending and receiving data, such as an IP address and some basic server data. Or running something stat-based like a leaderboard or character database. Heck, you could theoretically make an entire player-only MMO as long as you keep things synchronized on the player's end.

However, it's just about nigh impossible to write an actual breathing game server in another language. Stuff thats pretty much necessary for server side calculation, such as enemy AI or collision detection, sounds like a tall order since you are essentially simulating the Game Maker engine in another language. Not only does that sound impossible, but I often wonder if you would also break some copyright laws along the way.

Anyhow, obviously the miracle that needs to happen is getting a headless export feature. I've talked to Mike a few times over twitter about it, and he said it's something that he wants but the team never has the time for.

Instead of asking that same question again, I was just curious what sort of work would need to happen to get this feature, especially now that GMS2 is out and about. Is it easy as flicking a switch (metaphorically)? Or would you need to rewrite the entire collision engine? I've always assumed the collision was graphics/GPU based and if you don't have a GPU to calculate it, that would make a lot of sense that the feature is a lot harder to implement then one would think since you would have to rewrite the nature of how collisions work.

This thread's purpose is also to sort of gauge for me how much this feature is wanted. I might be the only one, or maybe theres handful of us, or a lot of us. If you are interested in this feature, maybe leave a post and if it gains enough attention it could be a feature that they would suddenly have time for.

In conclusion, I think a headless export would be a pretty large step forward in terms of being taken more seriously. It would grant access to better GM based multiplayer games, while remaining the easy-to-make game tool it's been known for. With the projects I have in mind, I'm inching closer to finally learning some other language because GM just ain't meeting my requirements anymore. Although I can't blame them if I'm not their target audience.
 

FrostyCat

Redemption Seeker
This "running headless is the only thing in the way" myth is a common fallacy.

GML doesn't suddenly become practical for online multiplayer servers even if it can run headless. GMS 2 is still single-threaded and incapable of multiple simultaneous room states, so you still won't get very far anyways without re-engineering both.

If you know another language that can do both, use it --- GML probably won't get there in time.
 

GMWolf

aka fel666
@FrostyCat
Could you not run a separate instance of the server for each "match" or region of a world?
Not optimal, but feasible.

Though, i must agree, running headless will help. But threading becomes quite important as the game increases in both scope amd users.
Not to mention the difference in performance, and the extra utilities othe languages offer.
 
R

renex

Guest
i've been sticking to a simple p2p structure for my games, and the clients themselves keep track of sync state. allows for a minimal server.

I've always assumed the collision was graphics/GPU based
lol no
 

zbox

Member
GMC Elder
Not in support of this idea, a GML server is a big waste of resources and you can very easily write in a language that is actually meant to be for servers.
 

Spasman

Member
I don't see whats wrong with having the support if you make small multiplayer projects. I would never even need anything more then like, 20 clients. Plus I've had the experience running a few "servers" in GM on my home server with a GPU and I've never had CPU problems and i can run 7-8 of them at once. Obviously you couldn't do that much on a VPS but i dont think its too bad.

Not in support of this idea, a GML server is a big waste of resources and you can very easily write in a language that is actually meant to be for servers.
I must not know something you do, because re-coding your entire game in some other language to include collision and any enemy AI you have and anything under the server-side umbrella JUST for dedicated server support doesn't sound easy. Why don't I just switch to that language altogether?

If it's too much work with what its worth then so be it, but I'm not asking for much, just a solution for players to host a server on their virtual servers so the online game could keep itself alive. It doesn't have to run great, especially since the server host would host an average of 1 server. I'm not looking to make an extravagant server cluster of GM instances.

if you were to suggest the client syncing route, that could cause a lot of problems with cheaters since GM can't hide memory addresses and makes it open to stuff like cheat engine.

this is a pretty complex subject man, and I'd appreciate it if you added some sustenance to your post instead of making rude two-word replies.


GML doesn't suddenly become practical for online multiplayer servers even if it can run headless. GMS 2 is still single-threaded and incapable of multiple simultaneous room states, so you still won't get very far anyways without re-engineering both.
So you're saying its poor optimization from single threads makes it not worth it? Yeah its terrible, but it still runs right? Like I said, its work load vs. value I guess. If its a simple enough feature to give us, I don't see the harm even if GM runs like crap. I just want some steps taken to give some love to those who want to make multiplayer games.
 
Last edited:
N

NPT

Guest
This "running headless is the only thing in the way" myth is a common fallacy.

GML doesn't suddenly become practical for online multiplayer servers even if it can run headless. GMS 2 is still single-threaded and incapable of multiple simultaneous room states, so you still won't get very far anyways without re-engineering both.

If you know another language that can do both, use it --- GML probably won't get there in time.
No it's not.

For many, since GML is the only language they know than it is the only reasonable roadblock.

Is GML optimal, far from it. Practical, absolutely. For small servers you don't need multi-threaded, being incapable of multiple simultaneous room states is not relevant because a third party language is not "room" oriented anyway.

http://gmc.yoyogames.com/index.php?showtopic=17686 - ROPW was released over 13 years ago and allegedly held 30 players.
Consider:
  • Hardware "13 years" slower than today's.
  • GM5 considerably slower
  • It wasn't compiled
  • Single threaded
Writing a server in GML IS the next logical step for the majority of Studio users who want to explore Client Server programmers. Cripes, I've seen you take a strip of novices who aren't ready for network programming. And now your suggesting that the gap be widened by suggesting that not only should the be using another language, but they should be coding multi-threaded servers.

A GMS authored commercial grade server? No way. Just too much overhead. (And probably a 64 client limit? Am I right?).
No, The 64 client problem was fixed in 1.4.1629 a year and a half ago. Studio can support 1024 sockets.
 
Last edited by a moderator:

Spasman

Member
Re collisions, etc on server argument, the answer is "don't worry about it".

http://gamedev.stackexchange.com/qu...server-side-or-cooperatively-between-client-s
Ehhh. My first online game I did all hit detection client-side and its a mess. Players with terrible internet or poor frames would lag, and the hit wouldn't register to the server until the client would send the message they were hit. And it would cause some strange behaviors.

Ex. Some kid gets hit by a rocket which would be an instant kill. His ping is well above 600ms because he's on his mom's 5 year old laptop in the backyard connected to his neighbor's wifi, so in that 600ms before he tells the server he was hit, he manages to fire off his own rocket well after being hit and kill his aggressor. Not very fair since he was suppose to be dead well before firing the rocket.

I switched to server-side hit detection and damage calculation in my new project and while it can get jittery, its overall performing much better. The fluctuations of connection quality between players made things a lot more jarring with client-side, but with server-side things seem to be much more consistent and responsive and with a little client prediction going it can be even greater. Granted these are just my experiences. Maybe I just did something completely wrong the first time.

For small servers you don't need multi-threaded, being incapable of multiple simultaneous room states is not relevant because a third party language is not "room" oriented anyway.
Precisely. My newest project has 1 room actually related to the game and its size is 20x20. I've made a map editor that completely ignores the room settings and makes its own rules and settings. Everything takes place in one room and loads instances from a file created by a map editor. The most my project does with rooms are for menus and setting up variables. Changing rooms in an online game is just a headache in general, even if both client and server are running on GM. I found it much easier and more efficient to have everything take place in one room, and just wipe everything and load a new level.
 

zbox

Member
GMC Elder
well 600ms ping is always going to introduce "fair"-ness problems, regardless of where the collision detection is done.

It looks like most games do this by letting clients figure out the fine details by themselves, and then the server occasionally tells them if they've made an illegal move based off some loose approximations. If it works for AAA games I'm sure its good enough for a GM project :p
 
R

renex

Guest
this is a pretty complex subject man,
it is, and it's also unrelated to this thread. gml collisions are first bucketed with an r-tree, then bounding boxes are checked, then if necessary a loop will check every pixel against every other pixel. 100% cpu-based.
 

Mike

nobody important
GMC Elder
Headless is something we'd like one day...... but it's not even close to being on our list at the moment, there are just too many other things to do, and demand for this is minimal (to say the least)
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Linux export is the most headless it gets right now: with a bit of effort you can install the dependencies on a GUI-less Linux distro, trick it into thinking that it has a monitor connected, and so run your game, which would stop trying to render [into nowhere] as soon as it starts. I've ran a GMS server on a DigitalOcean this way ($5/month; use anyone's referral link to get first 3 months for $5).

So I'd suggest to use that until your game gets popular and successful.

Once you're "there", some other options would open up as well - for example, last month I had migrated someone's 10K LOC GMS server to Haxe+Neko:
17-01-25-2.png
Obviously, this involved writing some very strange purpose-specific software (transpiler), adding some hints to source code (Haxe is a strongly typed language, GML isn't), and precisely replicating the used GM functions, but if you have a budget, the option is there, and the result is satisfying - the game's programmer continues to prototype server in GMS while the resulting application is optimized far beyond what's possible with GM and makes best (multithreaded) use of server' resources.
 

Mike

nobody important
GMC Elder
I was asking for this in about 2010/2011, and they said it should come to GM:S 1.x, and... yeah. We have 2017.
Yeah, and you know as well as we do the demands that often get placed on us outside of just the product. Every time something comes up, the lower priority stuff gets pushed down. Hell... the Pi export is way higher than this, and I've personally been waiting 4 years for that one! :)
 

Spasman

Member
Linux export is the most headless it gets right now: with a bit of effort you can install the dependencies on a GUI-less Linux distro, trick it into thinking that it has a monitor connected, and so run your game, which would stop trying to render [into nowhere] as soon as it starts. I've ran a GMS server on a DigitalOcean this way ($5/month; use anyone's referral link to get first 3 months for $5).
I'll have to give this a try myself, I knew you could run it through Wine on a Linux VPS since it emulates a video device or something, but obviously that is a resource hog. Taking out that middle man would be a lot better.
 
R

renex

Guest
error 0xc000007
You replaced the wrong DX module... I replaced the correct module and got a more elaborate error instead.

Code:
Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    GpcMR.exe
  Application Version:    1.0.0.0
  Application Timestamp:    58f0fa67
  Fault Module Name:    KERNELBASE.dll
  Fault Module Version:    6.1.7601.23714
  Fault Module Timestamp:    58bf87bb
  Exception Code:    c06d007e
  Exception Offset:    0000c54f
  OS Version:    6.1.7601.2.1.0.256.1
  Locale ID:    1046
  Additional Information 1:    0a9e
  Additional Information 2:    0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:    0a9e
  Additional Information 4:    0a9e372d3b4ad19135b953a78882e789
 
Top