next »

[aberrantmind]

http://csanyk.com/rants/2013/03/leveling-up-as-a-game-maker-dev/ I'm at level 4 according to this.

[TheLastBanana]

It's been a long time since I've used Game Maker, but is that first point for level 4 actually a good idea? It seems to me like constantly recreating your objects, especially if you have a lot of them, wouldn't be great for performance.

In any other language, you'd probably just have a variable to keep track of the state (i.e. STATE_RUNNING, STATE_JUMPING) and just handle it accordingly.

EDIT: I read through his other post on the matter. I'll give the guy the benefit of the doubt and assume he's tested the performance, in which case it seems more like a matter of preference. I don't know if really makes you "better" at Game Maker, though.

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

9

[PowRTocH]

9

[aberrantmind]

It's been a long time since I've used Game Maker, but is that first point for level 4 actually a good idea? It seems to me like constantly recreating your objects, especially if you have a lot of them, wouldn't be great for performance.

In any other language, you'd probably just have a variable to keep track of the state (i.e. STATE_RUNNING, STATE_JUMPING) and just handle it accordingly.

EDIT: I read through his other post on the matter. I'll give the guy the benefit of the doubt and assume he's tested the performance, in which case it seems more like a matter of preference. I don't know if really makes you "better" at Game Maker, though.

yeah, I've been wondering about how well that would work out  myself. I've been using booleans to turn states on/off which works good.

For a relevant question for everyone who answered, how was your leveling progression different? what are some revelations you've had where you felt like you leveled up?

[csanyk]

It's been a long time since I've used Game Maker, but is that first point for level 4 actually a good idea? It seems to me like constantly recreating your objects, especially if you have a lot of them, wouldn't be great for performance.

In any other language, you'd probably just have a variable to keep track of the state (i.e. STATE_RUNNING, STATE_JUMPING) and just handle it accordingly.

EDIT: I read through his other post on the matter. I'll give the guy the benefit of the doubt and assume he's tested the performance, in which case it seems more like a matter of preference. I don't know if really makes you "better" at Game Maker, though.

Author here.  Thanks for the traffic

You're correct that it's possible to implement the State Machine pattern in a single object.  In my experience this makes the code a lot more complicated and difficult to manage.  From an aesthetic standpoint, I like to keep my objects as simple as possible, with only the code in them that they need to run for each state.  I find that this makes them simpler to understand, debug, modify, etc. and maybe makes them faster at runtime since you don't have to do a lot of "if FOO_MODE{//blah}" since each instance only represents a single mode.  

As long as the instance_change() and Create Event doesn't "weigh more" than the branching, then it is probably advantageous to have State Machines built from multiple, lightweight objects rather than a single, multi-state object.

That said, there's no single right way to implement the State Machine pattern.  If what you're doing works, go with it.  But give the other approach a try sometime and see if you don't like it better.  

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

if you use instance_change() and inheritance it should be alright, yeah, because all local variables (such as position, speed, gravity, etc.) would be maintained when you change an object's type

however, doing that is functionally equivalent to simply changing an object's events. if you use user events, you don't need to change an object's type to change its events

so basically, if you do do that method, don't think of it as changing an object type, simply think of it as one way of changing an object's events

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

the way i do it though is to assign functions to variables and then run those functions in certain events, and then change those variables. that way you avoid all the if/then or select/case stuff

in other words, let's say an enemy's step event is 'pace back and forth'. the pacing script would be assigned to the step event function variable, and it'd use script_execute() on that variable. if that enemy is put to sleep or something, then it's replaced with a 'do not move' script instead

the effect is the same: changing an object's events. it's just that this way is done purely through code without changing the object type, but also without the overhead of having to use multiple if/then or select/case checks on a variable; it simply stores a script identifier in a variable and executes that script from the event, and that variable can be changed at whim

[TacoBell_Lord]

Level: Asian

[TheLastBanana]

Fair enough, thanks for the explanation. I'd probably lean more toward Paul's method, but I can understand how it would be helpful from an organization point of view. It's been years since I've done anything with Game Maker beyond really basic prototyping (like, two object types total, haha) so it's interesting to see how other people are working with it.

[csanyk]

the way i do it though is to assign functions to variables and then run those functions in certain events, and then change those variables. that way you avoid all the if/then or select/case stuff

in other words, let's say an enemy's step event is 'pace back and forth'. the pacing script would be assigned to the step event function variable, and it'd use execute_script() on that variable. if that enemy is put to sleep or something, then it's replaced with a 'do not move' script instead

the effect is the same: changing an object's events. it's just that this way is done purely through code without changing the object type, but also without the overhead of having to use multiple if/then or select/case checks on a variable; it simply stores a script identifier in a variable and executes that script from the event, and that variable can be changed at whim

That sounds like an approach I took with a "button" object that I implemented, where I created an object variable called "action" and then set action = script_name, which thereby created an "alias" for script_name.  That way, I was able to make the button object generic by creating whatever scripts I needed to handle various button clicks, and setting action = scr_button_action_1 or whatever.  This saved me from having to create a lot of redundant button objects; I only had one oButton, and would set action=script_name upon creation to make the button do what I needed it to do when clicked.

It was a handy approach, worked great, and was not obvious until I figured out that if you don't put the () at the end of a script's name, it serves as a reference to the script asset rather than calling it like a function.

[s0]

i kind of contest this

By now, you’re starting to realize that not every piece of GML that you write actually NEEDS to be a script, and sometimes it’s actually BETTER to write it in an Execute GML Code action instead of an Execute Script action. You use each when it’s appropriate, and have stopped writing scripts named “do_ThisObject_Event” … a while ago.

it might be better sometimes but 90% of the time it's better to use scripts. one huge disadvantage of execute code actions coupled w/ lots of objects (in gm8 and lower at least, haven't tried studio yet) is that it becomes a nightmare to search for specific pieces of code. also the 1 window restriction for the code editor (though i've heard this is fixed in GMS) is really annoying.

overall good article though.  

[Blademasterbobo]

level 10 is when you've moved beyond using game maker

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

@c.a.- in gm8 and gm7 you can't search code events but in gm studio you can. i believe he's using studio. i use gm7 so i don't use execute code primarily for the reason that i can't search it

however, it *is* true that execute code is moderately faster than calling a script event. that difference is real, but usually not all that important to a game's speed. for very speed-intensive objects you *may* want to use execute code occasionally. to maintain searchability you can duplicate that code in a script somewhere, comment it out, and leave comments specifying where the code actually is

for example, with bullets, in a game where there are hundreds of bullets on screen at once, execute code may be the best choice even in gm7/gm8, because there are so many of them that you need all the speed you can get

you can also do this optimization right at the end, when your game is about to be released, it's an easy thing to switch up, and you don't have to *develop* it that way, just make the optimization when the game's done

[csanyk]

@c.a.- in gm8 and gm7 you can't search code events but in gm studio you can. i believe he's using studio. i use gm7 so i don't use execute code primarily for the reason that i can't search it

Correct, I started with GameMaker in fall 2010 with 8.0 and am now using Studio.

[cactus]

Level 3-ish, apparently. I generally disagree with the notion of leveling up in a tool such as Game Maker by getting better at optimization, neat coding and effective structuring.

To me Game Maker is all about putting the application's abilities to good use (creatively) and easily being able to create a game that feels good to play and is nice to look at.

If judged by the scale of the article, then Blademasterbobo's suggestion for level 10 seems pretty reasonable.

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

in a similar vein, i've found that some of the best gm games ever were made by some of the worst coders ever. coding skill is not necessarily reflective of skill at game design

so if you want to get better at making games, trying to improve your coding is not actually going to help you all that much. for example, i believe hanako (of cute knight fame) still regularly uses "execute string" in her games, which is like anathema to a lot of gml coders

[aberrantmind]

I've been using almost entirely execute code with scripts called from there.

@csanyk your position and motion tutorial was mega helpful btw, thanks for putting that up!

[forwardresent]

I'm probably a level 2/3 user, my GML isn't great and I'm still figuring GM out. I'd like to get more into GMS, probably will choose it over Unity this summer.

[poe]

10 by bobo's definition