• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Action game devs: What does your player object code look like?

kpenrose92

Member
Hey everyone. I'm just looking over the code I've been working on for a top-down action-adventure project and wondering if I'm organizing everything in the player object right. The more actions I give to the player, the more complicated my step code has become. Now, whenever I want to create a new action, I have to navigate a confusing web of code to implement it.

I'm curious to how other people manage to organize their player's step code and keep it legible and understandable.

My player object runs like a state machine, with a variable called "state". States are broad changes made to the player's behavior, like pausing him for dialogue, attacking, or dying and respawning.

Inside each state are substates managed in a variable called "phase". This controls the stages of various attacks, powerups, and move states such as swimming, falling into pits, etc.

Anyway, how do you keep your player object organized? For example, do you use lots of scripts for small blocks of code, or do you tend to use scripts only when needed? Screenshots and code chunks would be awesome to read. Thanks!
 

curato

Member
Sounds like you are on the right track. Come up with plan and break it into manageable sections. I would say that is pretty close to how I tackle a computer controller character like and enemy. basically have the step look at the conditions have the logic make a determination on what the action should be and set the state and let that code section do what it is supposed to do.

For a player controlled character I usually look at the conditions of where I am and combine that with the user input. like if you in the air over a pit it would not matter if I pushed D to move left I am going to fall or if I am on a platform and push Space I may jump but if I am seeing that I am in water I might swim upward.

Same sort of concept as the AI controller character, but the important part is make sure you have organized in a fashion that makes sense to you and it readable to you even if you come back a month later to try to read it. The fact that you are putting so much effort into how to break the logic up is a great sign for your project. It is a concept that is all too often overlooked. If you look at life cycle of software like 1/6 of it is actually building the software and as you get further along the cost of correcting a design flaw goes through the roof. It is always a good plan to define your projects requirements and define them preferably in a design document before you even open gamemaker to write the first line of code.
 

kpenrose92

Member
basically have the step look at the conditions have the logic make a determination on what the action should be and set the state and let that code section do what it is supposed to do.
Question: when it comes to triggers that actually cause the state to switch, do you keep them together in one place? One problem I've run into is that different states have different triggers to switch states (and these triggers are located a bit sporadically through different scripts, making debugging difficult).

It would be nice if gamemaker had a way to view all uses of a variable like in visual studio or other IDE's. I wind up spending way too much time hunting down chunks of code.

It is always a good plan to define your projects requirements and define them preferably in a design document before you even open gamemaker to write the first line of code.
I've been doing this too. I recommend https://draw.io to anyone for drawing diagrams of logic etc.
 
Each state should hold it's exit triggers within itself. So if you have a run state, the exit for that (i.e. key no longer being pressed or whatever) should be within the run state script (or switch, or however you're handling the states). That's the point of states, really, giving you control over how things switch between behaviour models. If you're not doing this, there's almost no point to states, as you'll end up chaining conditions together to figure out the exit, which removes the benefits of state machines. There are exceptions to this, but this is the basic idea.
 

curato

Member
Each state should hold it's exit triggers within itself. So if you have a run state, the exit for that (i.e. key no longer being pressed or whatever) should be within the run state script (or switch, or however you're handling the states). That's the point of states, really, giving you control over how things switch between behaviour models. If you're not doing this, there's almost no point to states, as you'll end up chaining conditions together to figure out the exit, which removes the benefits of state machines. There are exceptions to this, but this is the basic idea.
Exactly right have the main logic determine which state you are in then keep everything that pertains to the state in that state. I would advise setting each state as a script and pass it any information it need then your main logic looks clean and you have each state broken out so it doesn't confuse you what belongs with what.
 
Top