Cutting coding clutter

Discussion in 'Programming' started by NatashaD, Aug 14, 2019 at 12:21 AM.

Tags:
  1. NatashaD

    NatashaD Member

    Joined:
    Tuesday
    Posts:
    4
    Here it goes.

    How do you manage coding clutter, by clutter I mean lines upon lines in you character objects step event. I’d like to maybe experiment but putting some stuff in other interactable objects.

    What I mean is;

    If I wanted to interact with an object in my chars code I would put,

    If place_meeting(x,y,obj_blah) do whatever

    But if I instead went into the objects step event I’m trying to interact with on my character and put

    If place_meeting(x,y,obj_char) do whatever

    Would that make it too confusing when trying to find code or should I just stick with keeping a majority of the code in my character object?

    Is there any tips or tricks that you use or would suggest to keep things tidy?
     
  2. ThePropagation

    ThePropagation Member

    Joined:
    May 16, 2017
    Posts:
    114
    Scripts. name them easily (scrPlayerJump) or (scrEnemyDeath) for example so you can find them easy
     
  3. ThePropagation

    ThePropagation Member

    Joined:
    May 16, 2017
    Posts:
    114
    So like for if you punched an enemy and it killed them do
    if punch
    { scrPlayerPunch }
    in the player step event
    and have scrEnemyHealth on the enemy
     
    NatashaD likes this.
  4. NatashaD

    NatashaD Member

    Joined:
    Tuesday
    Posts:
    4
    I never even thought about using scripts, I’ll have to look up on how to implement them so I don’t completely fail trying to use them.
     
  5. ThePropagation

    ThePropagation Member

    Joined:
    May 16, 2017
    Posts:
    114
    all you have to do is in the resource tree on the right where sprite folder and sound folder there is a scripts section. Just make a new script and name it what you want to call it for example scrPlayerPunch
    When you want to call it in the code, just type the name then (); so scrPlayerPunch();

    Put whatever code you want to in the script and it runs it all every time you call the script in the code
     
  6. TheouAegis

    TheouAegis Member

    Joined:
    Jul 3, 2016
    Posts:
    6,627
    Scripps do have some slight overhead, as they require look up tables and subroutine calls, but if organization is the stronger concern for you at this time than fractional speed considerations, which I am sure anybody in their right mind would say is a valid priority, then go ahead and use scripts. Prior to studio, scripts were almost mandatory for easily managing code, but now that studio lets you search the entire project for code, they are less necessary but nonetheless just as useful.

    If only one object is going to be running a particular code one and only one time, then put that code inside the object. if only one object is going to be running a particular code but running it more than once, put that code inside a user event. In studio 2, you can at least name the code blocks, even if you can't name the user event. This keeps your scripts resource tree less cluttered. if multiple objects are going to be running the same code any number times, then definitely put that code inside a script. Nowadays, repetition and code is not a big deal like it was in the olden days, but it's still useful to avoid.
     
  7. samspade

    samspade Member

    Joined:
    Feb 26, 2017
    Posts:
    1,965
    This is might be a much broader answer than you wanted, but I would separate the things that I do into two categories.

    The first category is using the tools that GM provides:

    Scripts: Almost any code that is repeated and needs to take arguments goes into a script. There are lots of resources about using scripts out there.

    User Events: Almost any code that will be repeated and doesn't need arguments goes into user events. User events have several disadvantages over scripts. They can't be as effectively named and they can't take arguments. However, they stick with the object that needs them which is helpful for organization purposes. And you can call a non-existing one without crashing:

    Code:
    
    with (all) {
        event_user(0);
    }
    
    
    won't cause any problems even when an object doesn't have a user event 0.

    Inheritance: This one is tricky but nothing feels better than when you've got it right and you can change up entire things game wide in a large project with just a few minutes of code. For example, switch how every button in the game from tapping to holding by changing the parent.

    Componentizing: You have to be careful with this one, especially since GM doesn't have lightweight objects yet, but it is important to remember that a 'thing' doesn't have to be all one object. For example, in a small project I'm working on I have space ships. The space ships are made of several different components. For example, the hp for each ship is a separate object (instance of an object) that has its id saved in the ship. The script that deals damage to a space ship looks like this:

    Code:
    
    with (argument0) {
        with (my_hp) {
            event_user(0);
        }
    }
    
    
    What this means is that any ship can be given any type of hp system, one that includes shields, or is immune to certain types of damage, etc, at any type by simply changing the hp object or even not giving them one, and there will be no crashes or errors. The cost is that I've doubled the amount of objects.

    Regions: They are great and you should use them. While I'm all for creating scripts for things that get re-used, the idea of breaking apart all my code into scripts just for normal code in order to cut down on clutter would drive me nuts (personally) as all scripts get stored in the same resource tab. Until GM gets methods, you basically have to choose between having 100s, if not 1000s of script in a large project or having a lot of code in one place. I view regions as giving you the ability to make one time 'methods' allowing you to have a lot more code in one event without it actually being that cluttered or hard to manage. Even though all lot of code is in one place, it can read as if it is all in scripts. There are a number of keyboard short cuts that make them even easier to use (control + m/u opens and closes all regions, control + enter toggles the currently selected region open or close, control + up/down move between regions, F4 then r create a region).

    The second (and honestly more important) category is using basic programming patterns and principals. I'm not really qualified to teach these, and they are too big to teach in a single post anyways, but my suggestion would be do a google or youtube search on the following terms and watch some videos on them. My caveat is that I don't put any of these terms out as best or mandatory just as things you should eventually become aware of and understand.
    • Don't Repeat Yourself (DRY)
    • SOLID design principals
    • Programming Patterns
    • Clean Code
    • Coding Conventions


    I would say that the more specific question you asked isn't really even about clutter. Where to put a collision check is more about a specific implementation of organization which could change a lot depending upon what you want. In other words, I would answer the above differently depending upon what you wanted contact to do. If it was a spike that would harm the player, I would put that in the spike. As I think that makes more sense. If it was collision code, I would put it in the player.
     
  8. Neptune

    Neptune Member

    Joined:
    Jun 21, 2016
    Posts:
    1,020
    Scripts and regions... though I dont ever make scripts merely for organization.
    Code:
    #region
    //COLLAPSING CODING REGION
    #endregion
    
    upload_2019-8-14_11-32-7.png

    Sometimes switches can keep things tidy, but for more robust systems, I sometimes find switches can be inconvenient.
     
    N0ba likes this.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice