Design Step Events Versus GML Events

[samspade]

Which would you rather use and why: an object where everything is in the step event, an object where everything is in multiple events?

Example, a button object that has left pressed event, the mouse enter and leave event, the left released event or one object that does the exact same thing but all in the step event.

I've been experimenting with different versions of the same object. It seems that using multiple events plays a little nicer with inheritance as you don't have to override the whole step event to change one thing. You can also 'name' events which means if they are simple enough you can get some nice easy to read documentation. If you want something exactly in line with what they do, they are also easier to create.

But the downside for me is that once you go beyond a certain level of complexity it is just overwhelming to look at the events, open all of them, and try to make sense, especially since you can't control how they are ordered. Where as in a step event you can use regions (and/or scripts) to order code. If you want something a little different than what an event does, you could be screwed, but you have a lot more flexibility in the step event.

 

[FrostyCat]

I'm of the school who maximizes the number of delegated events and scripts, rather than Step-cramming at every opportunity.

In addition to the inheritance issue (which I also use for UI elements like buttons), it also helps stop excessive coupling early. Too much sensitivity to execution order is a symptom of excessive coupling in GML (i.e. your current piece has to have been coupled to the ones that come before it for the ordering to matter so much), and from what I see on the GMC, this is often a petty want rather than a genuine need. The more ways your code can be rearranged and still work because they're independent, the easier it is to reuse, work with, and fix mistakes in if any crop up. A related note on this is how I recommend never using the Instance Order list. If you have to fix the order like that and know so many other things at once, your code is insufficiently granular and thus not architected properly.

Right now we only have 16 User Events to help delegate and the events are sometimes limited (e.g. there is a continuous Collision event but no on-contact Collision event), but that limit will soon be lifted with methods in GML 2020. If you have experience with any other OOP language with events, you'd know events and methods are one and the same. So my prediction is that the main code mass will shift from direct-action space (Step event) to declarative space (Create event, if that's where methods will be set up). The way people now think about the events-vs-Step issue will directly impact how GML 2020's arrival will boost their productivity or leave them behind.

 

[NightFrost]

I've been reading up on C# recently, which is an OOP language. My knowledge of OOP has been pretty casual-level before, but diving into C# I can see the direction where GML is heading in V2.3. I agree that there'll likely be pretty significant changes in how code gets structured when OOP-savvy people get to work with the new stuff. Even if GML's OOPish design will still lack (for now?) things like abstracts, interfaces, delegates, etc.

 

[kburkhart84]

I'm with FrostyCat on this. I can't stand having massive code in a single place if I can avoid it, especially when the event system is there and ready to be used. GMS right now may not be fully OOP, but it has plenty of OOP concepts in place and sticking everything into the step event ruins a lot of those benefits. There is also the benefits of parent/child objects as well. Why not take full advantage of what systems are provided to us instead of trying to work around them. Organization is key to any project that is beyond a certain size.

 

[samspade]

I only have a basic understanding of Javascript (I've taken a few courses, watched a fair amount, and made a few small websites, but I wouldn't trust myself to be able to do much of anything). In general I agree, although I'm fine with long sections of code for things which are not repeated I think most 'events' by definition are incredibly common and so worth thinking about. In fact with the exception of the input and collision events most events are mandatory (e.g. you actually can't do the thing they do without them).

However, many of these objects are very simple. So I'm currently working on buttons for example, which is why the events come up as many buttons rely on inputs of some kind which is a type of event you can code yourself in the step event. Many of these buttons are maybe 10 lines of code. So the question is really do you want 10 lines of code in the step event or do you want 5 lines of code in 5 GML events. And for order I didn't meant order in which they are called (where I definitely agree with FrostyCat) but order in how they are displayed. It bothers me that I can't order the GML events, and often their ordering is not what I would want for reading comprehension. In the step event, I can put them in the 'order' I like.

That said, 2.3 is going to be great and will change things. Then I can ask questions like which do you prefer, methods or gml events?

 

[Yal]

Which would you rather use and why: an object where everything is in the step event, an object where everything is in multiple events?

Neither, an object which calls multiple scripts to do things. Allowing reuse of convenience code between different objects as much as possible makes scalability much greater, and since scripts can leave behind instance variables (and not just script-scoped variables) you can even emulate aspect-oriented programming this way!

 

[Niels]

Which would you rather use and why: an object where everything is in the step event, an object where everything is in multiple events?

Example, a button object that has left pressed event, the mouse enter and leave event, the left released event or one object that does the exact same thing but all in the step event.

I've been experimenting with different versions of the same object. It seems that using multiple events plays a little nicer with inheritance as you don't have to override the whole step event to change one thing. You can also 'name' events which means if they are simple enough you can get some nice easy to read documentation. If you want something exactly in line with what they do, they are also easier to create.

But the downside for me is that once you go beyond a certain level of complexity it is just overwhelming to look at the events, open all of them, and try to make sense, especially since you can't control how they are ordered. Where as in a step event you can use regions (and/or scripts) to order code. If you want something a little different than what an event does, you could be screwed, but you have a lot more flexibility in the step event.

I would like proper functions in GML where events can all take place in 1 script..


I

 

[Joh]

Neither, an object which calls multiple scripts to do things. Allowing reuse of convenience code between different objects as much as possible makes scalability much greater, and since scripts can leave behind instance variables (and not just script-scoped variables) you can even emulate aspect-oriented programming this way!

I do something along those lines.

Always wondered if it was flawed because I'm dismissing a lot of the GM native & meant to be used functionality.
All my objects have 1 script(of same name as object) that take 1 argument (essentially event)

so it goes in object o_controller
sc_controller(0) //create
sc_controller(1) //step
sc_controller(2) //draw
(& more on needed basis)

thus I do all my code in one script (sc_controller) with a argument0 test for each event.
Its a bit weird seeing everyone else despise long codes, I like to have everything related to one object on one page! create, step, cleanup, draw! I somehow cant stand the GM interface, having to click on create or step open a new/change window rather than just scroll up to desired event.

I use a lot of script for everything (functions), so its not like scripts are that long.

Really love GMedit and I use it more than GMS2 now, pure code interface. The way Objects are shown there is a formal equivalent of my hacky method and is an idea way to go about ito me. (segments with shortcuts, all in one page with the ability to collapse)