next »

[Noel Berry]

..more powerful than... ..RPGMaker, MUGEN...

I seriously doubt that. I may be wrong, though.

If you think that RPGMaker, is as powerful as Game Maker, then you have obviously never tried either.

I would honestly like to know some of your reasons as to why you don't like GM. I don't have a problem with you disliking it - thats your opinion, as I have mine. But when you say you don't like it, claim you have reasons, but wont explain and back them up, then I have to conclude that you don't have all that much knowledge about GM. (Maybe I'm wrong - perhaps you know every last little crumb of things there is to know about GM, but if thats the case, then you shouldn't have a problem posting your points and backing them up).

[ஒழுக்கின்மை (Paul Eres)]

Yeah, MUGEN and RPGMaker are really quite incomparable to GM -- a big difference is that the former two are not expandable, you can't use .dll's with them. So if you want to use the FMod sound engine with RPGMaker, you couldn't, whereas you can just plug it in to GM.

It's also very hard to vary things in those two, for instance in RPGMaker all tiles and sprites are specific sizes (although this may have changed in later updates?), whereas in GM tiles and sprites can be any size you like. I don't even think RPGMaker lets you draw graphics primitives. I used this example before, but you could probably port Aquaria to GM with no real problems or differences except it'd be slower and be Windows-only, whereas you couldn't port it to MUGEN or RPGMaker at all, no matter what you did.

Those are not gripes on those engines, they were designed for specific genres, whereas GM is general-purpose, so it's natural that those would have more limitations. But the difference is is that you can pretty much make any 2D game imaginable in GM, whereas you can't in MUGEN or RPGMaker.

[Atnas]

I've been using RPG Maker for the past four years and Game Maker for the past one day.

RM is really not as limited as people think. With the last two installments, you can do anything you can dream of with ruby scripting. But it's just plain stupid to use it to make games like platformers when there is GM, and GM isn't the ideal choice for rpgs when there's RM.

For the average user, GM is more powerful than RM, but RM has a much flatter learning curve.

----------------------------

Thank-you so much Derek for this tutorial, you've started me off on GM. It's really handy for fleshing out ideas into reality in a snap. I'm an artist and not a programmer, so I can't say ew to anything that helps me concentrate on what I like to spend the most time on. 

[ஒழுக்கின்மை (Paul Eres)]

Ruby scripting sounds interesting, but I wouldn't say that GM isn't the idea choice for RPGs, since RPGs in RPGMaker tend to all look the same, whereas RPGs in GM tend to vary in appearance a lot. It'd take more work, but it'd have more of its own style and flavor in GM. Have you heard of Barkley: Shut Up and Jam: Gaiden? It started out as an RPGMaker game, but then the author ported it to GM because RPGMaker couldn't do everything he wanted to, and as a result it was a much better game than it could otherwise have been.

[Skofo]

Mm, yeah. Apparently I was wrong. There aren't any dream engines I've been talking about that I could use as an example.

MUGEN and RPG Maker and ioquake3/Sauerbraten are easier and faster to make fighting games, RPG games and FPS games, respectively, but Game Maker does seem to be more flexible than those.

But Game Maker is still crappy in a lot of ways. I might eventually take up the job of making an open non-programming-requisite game making program that delivers better performance, more modularity and a lot more organization than Game Maker does.

So, yeah. I was wrong in some aspects. Let's a whole beer. 

[ஒழுக்கின்மை (Paul Eres)]

Mm, yeah. Apparently I was wrong. There aren't any dream engines I've been talking about that I could use as an example.

MUGEN and RPG Maker and ioquake3/Sauerbraten are easier and faster to make fighting games, RPG games and FPS games, respectively, but Game Maker does seem to be more flexible than those.

But Game Maker is still crappy in a lot of ways. I might eventually take up the job of making an open non-programming-requisite game making program that delivers better performance, more modularity and a lot more organization than Game Maker does.

So, yeah. I was wrong in some aspects. Let's a whole beer. 

If you could do that it'd be pretty great, but (and I don't mean to sound doubtful or discouraging) there have been a lot of people who have attempted it -- making a game engine which is easy to use, general-purpose, and has good performance is a pretty demanding task. And looking at your profile you're only 17 (?), so that'd be completely amazing if you could make something better than GM alone. Would you really have enough knowledge to do something better than a program that took a university computer science professor nearly a decade to create, and for free at that (since you expressed dislike of profits from hobbies in the income poll)?

[Skofo]

Mm, yeah. Apparently I was wrong. There aren't any dream engines I've been talking about that I could use as an example.

MUGEN and RPG Maker and ioquake3/Sauerbraten are easier and faster to make fighting games, RPG games and FPS games, respectively, but Game Maker does seem to be more flexible than those.

But Game Maker is still crappy in a lot of ways. I might eventually take up the job of making an open non-programming-requisite game making program that delivers better performance, more modularity and a lot more organization than Game Maker does.

So, yeah. I was wrong in some aspects. Let's a whole beer. 

If you could do that it'd be pretty great, but (and I don't mean to sound doubtful or discouraging) there have been a lot of people who have attempted it -- making a game engine which is easy to use, general-purpose, and has good performance is a pretty demanding task. And looking at your profile you're only 17 (?), so that'd be completely amazing if you could make something better than GM alone. Would you really have enough knowledge to do something better than a program that took a university computer science professor nearly a decade to create, and for free at that (since you expressed dislike of profits from hobbies in the income poll)?

Of course I do.

You can not defeat that which has no job and is very bored.

Also, I did not express dislike of profits from your hard work. I merely rebutted someone else stating that having a principle of not charging for your games is silly, which it is not.

[ஒழுக்கின்மை (Paul Eres)]

I agree with you there, but I thought the way you expressed it was a bit offputting. Even the original person you were defending didn't call anyone who sold games a "greedy little parasitic minx" :D

And, still, plenty of people have no jobs and are bored. If that's all it took to make great programs, we already wouldn't have to put up with the negatives of Game Maker, because someone would have done what you propose to do already. I've known people who have attempted it (a friend of mine tried to make one in Python, it had a great design and had specific layouts for different genres, and you could mix and match elements and exclude the ones you didn't like), but all of them found the project harder than they thought it'd be and gave up before it was anywhere near complete.

[Skofo]

I agree with you there, but I thought the way you expressed it was a bit offputting. Even the original person you were defending didn't call anyone who sold games a "greedy little parasitic minx" :D

And, still, plenty of people have no jobs and are bored. If that's all it took to make great programs, we already wouldn't have to put up with the negatives of Game Maker, because someone would have done what you propose to do already. I've known people who have attempted it (a friend of mine tried to make one in Python, it had a great design and had specific layouts for different genres, and you could mix and match elements and exclude the ones you didn't like), but all of them found the project harder than they thought it'd be and gave up before it was anywhere near complete.

Blah, I was saying that selling games sometimes isn't the way to go for people because you feel greedy and icky on the inside. I wasn't trying to refer to anyone as greedy.

Also, I think that a big part of the performance/organization issues in Game Maker is that it tries so hard to be easy-to-use that it works against the flow of logical programming. And really I think the hardest hurdles of programming to jump through are the memorization of all the little signs and how to use them and stuff and the organization of code. So I thought to make something that works like actual programming, except the program guides you through the organization and you can use human-language buttons to do what you want and where you want it, similarly to Game Maker. And it'd all save into standard, editable .py or .cpp files or whatever I choose to do it in, which can be compiled, or adjusted by those who feel confident enough. Not to mention that the files will be saved in/opened from a standard code file format, so you'll also have the support and help of a much larger community even if the program isn't too popular.

So you could say that I'm planning to build a wrapper for Pygame/SDL of sorts so that even complete non-programmers can be guided through with helpful buttons that help/automate through the more redundant parts like the programming signs and organization stuff. I'm thinking I'd use Pygame for this, since Python seems like the easiest next step for game developers to go up to, plus it'd make organization a lot easier, and you can also program in it while the program is already running.

[ஒழுக்கின்மை (Paul Eres)]

Yes, I know what you were saying, I just think what you were saying was incredibly offensive and incorrect. I don't think you feel greedy or icky on the inside, I can't even imagine what it would feel like to "feel greedy". To work a year on a game full time and only earn about $5000 from it isn't really even greedy, because you'd be making less than you would working minimum wage.

I think it can be just as idealistic and noble to quit working a normal job and sell games independently as it would be to keep working a normal job and give away games for free. Both of them involve major sacrifices, and both of them are done through love of games. Nobody becomes a shareware independent game developer to make money, because the money is so poor relative to what they could make in a normal programming job, they do it because they can't imagine spending their life doing anything else, and because they want to work on games full time rather than a half hour a day or something. So, is it really "greedy" to be prepared to live on such a low amount of money just because you like games? There's a lot of material comfort and security you give up in order to become an independent developer.

Could you name specifically how Game Maker works against the flow of logical programming? I'm not sure what you mean.

Most of the performance problems of GM come from it being an interpreted language, and if you were to use Python it probably wouldn't have any better performance than GM itself does. So using Python to create something like GM wouldn't give you any performance boost, and even using C++ probably wouldn't because you'd still need to create an interpreted system anyway. So I'm not sure how you intend to improve performance.

And I don't think the hard part of programming games is memorization, the hard part is learning how to code all the low-level stuff that most games require (like collision detection, sprite animation, tiling systems, particle systems, etc.), which is why GM is helpful: it lets you create games with all of those already in place, giving you the things that 90% of games need so that you can focus on the part of game design that's important.

When I first started creating games in QBASIC and C, the hardest parts for me were those low-level things. I once spent about three months just creating a font for a game. I drew the letters on graph paper, put them into an array, and then drew the text pixel by pixel based on that. In GM I can just load a .ttf and use that, so something that used to take me months only took me a few minutes. As another example, I spent a long time just learning how to access video memory, and to flip between two "pages" of video memory in order to make the frame rate smooth. In GM, all of that is automatic, and I'm happy I don't have to waste time on low-level things anymore; I never finished games back then, despite a huge amount of time and effort spent on it, but I can finish them now because the low-level stuff is simple.

[Skofo]

Okay, then. I'm sorry if I incredibly offended anyone.

And a big part of the slow performance rate in Game Maker is poor optimization. Game Maker's 'objects' seem as if though load up everything that's usable by them, so you can't make more than 50 (forgot the exact estimate, but not too many) or so on an average computer on screen at once without seeing some performance hits, even if those objects aren't doing anything.

And the low-level parts will be as simplified as possible without resorting to hacking around things that ends up making everything messy like Game Maker did, from what I've seen. I haven't used Game Maker in a -long- time so I can't quite remember any examples yet, but I'll try to dig up some after I get some well-earned sleep after a long, hard day of [unintentionally] pissing everyone here off.

[ஒழுக்கின்மை (Paul Eres)]

I agree that the objects aren't optimized: if you don't want to use 'gravity' in your game, there should be a checkbox or something to remove the gravity check from the objects. It definitely should do that, but doesn't. Same goes with friction, speed, and all the other checks GM objects have.

Although I do think you can make way more than 50 on most computers: Immortal Defense averages around 300 objects on average at once, and works fine on most modern computers (anything with > 2.0 ghz CPU). I don't really get problems until it gets to around 500, and most games don't really need 500 different sprites running around on the screen at once (although some do, danmaku games are a prime example, so GM isn't a good tool to make danmkau shooting / bullet hell games).

[Skofo]

Even better would be to NOT have those useless checks in the first place when you're not using them.

[GregWS]

I suppose before creating an exe GM could scan through your code and see whether you use them or not, and simply turn them off if you don't.  I assume this would take some time depending on the size of your game, but it's better than having to check things, and I suppose you could turn on/off this "check code for variables used" feature.

[increpare]

I suppose before creating an exe GM could scan through your code and see whether you use them or not, and simply turn them off if you don't.  I assume this would take some time depending on the size of your game,

So long as it was a well-documented optimisation, I guess. (The nice thing about radio buttons and check-boxes is that they would presumably perform a check to see if you were using any of these variables and let you know if you were.  Man I haven made a program with radio buttons in a LONG time...getting nostalgic for them now  ).

[ஒழுக்கின்மை (Paul Eres)]

Still, I have the feeling that even if this were done it'd be a very minor optimization. Maybe you'd get 5% more speed out of it or something. It's hardly something that'll make GM work like a compiled language, the primary reason it's slow is that it's interpreted, and it's no different than Python and Java in that respect.  It's probably even faster than those two because parts of the GM runner are compiled in Delphi, whereas games made in those two are completely interpreted. I don't really think it'd be possible to get any performance *increase* by creating a game creation engine in Python -- even PyGame is fairly slow in comparison to GM, try drawing 10,000 circles on screen in GM and in PyGame every frame to compare the speed difference. The last time I tried it, GM was faster.

Also, there's a way to draw sprites without requiring all those checks already, you can just use draw_sprite from a controlling object; you theoretically could make a game just from a single object if you wanted to, just make it draw everything itself, and store the coordinates of each pseudo-object. (That might be even slower though, because GM's object-checks and drawing are done with compiled code and yours would be interpreted code.)

The main problems I've had with GM don't really include its speed or performance. It'd be nice to be able to use 5,000 objects on screen instead of only 500, yes, but I can live with 500. My main dislikes of it are that it's Windows-only (although that'll hopefully change eventually), and its sound engine -- you really have to use an external sound library, GM's sound functions are quite useless.

[Matt Thorson]

Yeah dude if you make a "GM alternative" that does everything GM does but better I would switch in a second.  Many have tried and failed, but try anyways! I will salute you if you finish.

But yeah, don't use Python or you might be in for a bad surprise when it turns out to be even more "eww".  (I'm surprised you even wanted to use Python - most people who call down GM think any interpreted language is garbage)

[Blaster]

Thanks for the tutorial, Derek. I needed the excuse to finally bite the bullet and start making something. Looking very-much foward to part two.

I think, in the next one, if discussion starts to derail again, maybe someone should make a 'pros & cons of gamemaker' thread. I don't mean to discourage discussion, but, well... yes.

[muku]

It's not really relevant, but I'd still like to correct one thing:

the primary reason it's slow is that it's interpreted, and it's no different than Python and Java in that respect.  It's probably even faster than those two because parts of the GM runner are compiled in Delphi, whereas games made in those two are completely interpreted.

Java isn't interpreted. It's compiled to bytecode, and that bytecode is just-in-time compiled to machine code at runtime, which makes it quite fast; not as fast as C++, but quite a bit faster than any interpreted language.

Python also has an optional JIT compiler (Psyco), though the effects aren't quite as drastic. It's very useful though.

[GregWS]

Thanks for the tutorial, Derek. I needed the excuse to finally bite the bullet and start making something. Looking very-much foward to part two.

I think, in the next one, if discussion starts to derail again, maybe someone should make a 'pros & cons of gamemaker' thread. I don't mean to discourage discussion, but, well... yes.

I agree that it's become something of a gong show.  I did create that "suggest improvements for GM" thread, but frustratingly enough a lot of people just suggested stuff related to the playing of GM games, instead of the creation of them.  Anyway, yeah, I do think this should have stayed focused on the tutorial and things directly related to it (other than the merits of the program that it's about; if you don't like GM, then don't bother posting in this thread).