next »

[falsion]

I suppose. But it gets frustrating when there's a huge flaw that isn't your fault but the developers of whatever tool you're using.

That's what kinda made me give up these "easy" game making tools and go in the hard way. If there is a mistake, I'd rather have it be my own fault, not the fault of the "game making tool" I'm using.

I like making mistakes I can actually learn from and fix. Often with game making tools, there's a lot of stuff you just have to "just deal with" and never hope to fix.

Also it seems like companies like Clickteam and YoYoGames are all about selling exporters now instead of fixing obvious bugs in their program. What's with that?

[TeeGee]

Good coding skills are very important, even in GM (it's not like MMF, you actually code/script stuff in it), no doubt about that.

But coding a feature like inventory is one thing, while having to code an entire engine from scratch is another. And then you have to test it (and it doesn't work), and then you have to port it to other platforms (and it doesn't work), and then you realize you need to add physics and particles systems with some editor (and they don't work). After several months, you realize that what you have is still not a game, but some basic engine that doesn't even have a fraction of features of Unity or GM.

I've been making games professionally for 7 or 8 years now and during that time had the chance to work on completely custom tools, GM-likes, and even those AAA engines. Custom engines are cool and very efficient, but even at a company where we had a fully developed proprietary framework (that took years to code and perfect mind you) and a programmer team to maintain it, we still had moments where we wished we simply went with Unity instead. When I went full-time indie, I consciously decided to go back to GM. For small indie teams, unless it somehow limits the scope of your game, I think such tools are the way to go.

I may complain about GM's faults and development schedule, but I can't deny the fact that I've had a completely playable demo of Cinders (which looked just like it looks now and had all the underlaying code work as intended) within a month.

I suppose. But it gets frustrating when there's a huge flaw that isn't your fault but the developer's of whatever tool you're using.

No doubt about it. But as Gabriel said -- it's a trade off.

[falsion]

I guess I'm not experienced enough to talk about coding in an "actual language" yet. But I really do get frustrated when there's an issue and it isn't my fault.

I'm hoping to become proficient enough where I don't have to rely on such tools like this. I'm sure it's possible. I know a guy who has made games in assembly and made lots of homebrew games for old consoles and some demoscene stuff. He works so fast I doubt he'd ever need something like GM.

I think that's the way to go. I want to be like that. Then GM, MMF, or whatever can go ahead and bite me.

[True Valhalla]

Gabriel and teegee have already hit all the main points. I know C++ and would still choose GameMaker over it any day. Unfortunately my major project requires me to use a combination of the two, but for everything else I am a GM purist

You'd be impressed with what experienced GM users can create in short periods of time.

[Blademasterbobo]

i use gm for jams and stuff like that, but for anything bigger than a jam game, it's way more effort dealing with the bugs than it is just rolling my own stuff. it's not that hard to get gm-esque capabilities in your own thing, gm's main advantages are the UI / built in level editor (which, let's be honest, suck anyway) etc. mainly interface things. (hence being better for jam stuff.)

[TeeGee]

Not to brag (haha, right), but done under 48h : http://moacube.com/games/co-op/

Though I can relate to falsion's sentiment and I find his attitude commendable. Isn't: "I'm pissed at all the X out there, so I'm going to do it better" a foundation for this scene's very existence, after all?

[Tumetsu]

I gave up GM after I learned AS3 and Flashpunk. Partially because Flashgames seem to get more players but mostly because of the workflow. After I got into working in IDE like Flashdevelop with only code I can't imagine going back to GM dor now. All code and traditional OoP just feels better to me than GM's UI. However if GM introduced a way to work like that with its GML I'd probably use it again.

[C.A. Silbereisen]

i used to use c++. i thought i wasn't a "real" game developer unless i used a "real" programming language and wrote my own engines and stuff like that. after a couple years of not getting anything done i dropped my ego and switched to gm. i don't really enjoy programming so anything that helps me reduce the effort is good (gml is programming for idiots) and i'm not looking to get a job in the game industry or build a portfolio or anything like that. i just mak gams as a side hobby and gm is perfect for that.

[eyeliner]

i don't really enjoy programming so anything that helps me reduce the effort is good (gml is programming for idiots) and i'm not looking to get a job in the game industry or build a portfolio or anything like that. i just mak gams as a side hobby and gm is perfect for that.

Yup. Though I have ignored my GM 8.1 license for far too long, and getting Construct 2 for HTML5 anyways, I figured that the best approach is to get my hands on something quickly instead of reinventing the wheel every time.

[moi]

if you are an amateur (not making gams professionally),90% of the time your experience will be :
-if you use a "real programming language", you'll get games done, but very simple games, simple half-finished platformer prototype, maybe an arena shooter or you'll spend months creating a very complex minecraft-like simulation that will sort of work and then you'll give up on everything
you'll create the structure of sthg you had in mind
-if you use a high level package, you'll be able to reach a higher level, all the complexity and brain oil that you would put in solving a simple platform collision bug, you'll be able to use it for a puzzle, story element, asset creation or a complex level design. You'll make a gam and it will be more than you imagined.

[Gabriel Verdon]

The other thing to keep in mind is that with Game Maker, you can write your own .dll's and extensions in C++ or pretty much any other language, and then use them in your GM project.

[Oddball]

I guess I'm not experienced enough to talk about coding in an "actual language" yet. But I really do get frustrated when there's an issue and it isn't my fault.

Using an 'actual language' won't stop you running into issues that aren't your fault. I mean are you going to code everything and use zero external libraries? Even if you code everything from the ground up an external system will pop up and bite you in the ass. 90% of issues players have with my game stem from either a sound or graphics driver. So much so that I start nearly all support emails with update you drivers. And I've had several issues with external libraries that I can't solve directly so have to devise workarounds. It's the nature of modern computing I'm afraid. I say use whatever you are comfortable with and whatever will make the process least painful for yourself.