Can anyone direct me toward some tutorials/guides covering this topic as pertains to Fusion?
I've found a few offering instructions for other programming languages, but find them difficult to follow.
Don't have an account yet? Then register once and completely free of charge and use our wide range of topics, features and great options. As a registered member on our site, you can use all functions to actively participate in community life. Write posts, open topics, upload your pictures, put your videos online, talk to other members and help us to constantly improve our project and grow together! So, what are you waiting for? Become a part of us today!
Login or registerTo get support for a technical issue such as installing the software, to query a purchase that you've made/would like to make, or anything other than using our software, please visit our Customer Service Desk:
Open a TicketCan anyone direct me toward some tutorials/guides covering this topic as pertains to Fusion?
I've found a few offering instructions for other programming languages, but find them difficult to follow.
Please could you explain what do you want to achieve ?
Okay, I'm looking for some sort of guide on how to best set up my code in a way which allows me to gradually build it in a fashion which is organised and simple.
Rather like in this video
Please login to see this media element.
But tailored more specifically toward Fusion.
I'm sure some would watch it and ask 'can't you apply these lessons to your own code?' and my answer would be no, because although I can understand the basic idea of what's being said, my mind struggles to break it all down effectively and translate it into the more visual format of Fusion.
And so I was wondering if there were any guides or tutorials people had seen which could take me through the process in a steady, step by step fashion?
Ah ok, I've got it now.
Well, basically you need what is usually called "game status". In its simplest version, It's just a variable, which holds the status of the game, which you can refer to in order to take different paths in your game/application.
For example. Let's think of a simple scenario. You have a game made of three main parts: 1 menu, 2 game, 3 end.
At the very beginning of the game, the game_status vaiable is set to 1, which in this particular example, means menu. Then you have somewhere in your code, the part that shows the menu, and it indeed shows it, but only when the game_status is = 1.
When, inside the menu, the user press the button "play", you set the game_status to 2. Which means: game !
Then you have, in your code, the part that reacts with the player, shows the sprites, and so on. And the menu ? That part will not be shown, because the game_status is 2 and not 1.
And so on. When the player is hit three times, then set the game_status to 3. In this case, the part that shows the end of the game, whith player score, and the like, will run, because the game_status is = 3. If the player press the button "play again", you set the game_status to 1 again.
You can easily implement this scenario with Fusion - and as well with any other programming language.
To do this, you can simply write an event with the condition "if the game_status = 1" then... and so on for the other game_status values.
Furthermore, with Fusion you could also activate/deactivate parts of code ( which are group of events - very powerful) based on, for example, the value of a game_status variable !
This way is easy - in my opinion - to have a finite status machine.
I hope it makes sense to you
Thanks for the ideas Semar, I get how you could navigate through a game that was, but what I'm looking for is something more character specific - and I apologise to the forum for not knowing the proper terminology for these things I'm inquiring about.
Something like how to effectively set up characters/enemies so they can transition reliably through their various states, for example, something which would clearly tell the game when a character should be standing still, jumping, attacking, running, running and jumping whilst attacking etc, and have some sort of reset which will switch all of these things off when they take damage.
Just a method of keeping everything organised and easy to follow when coding, avoid animation lock ups and bugs, things like that?
I apologize if I tell you about the same concept again, but what you're looking for ( keeping everything organized ) is easy to achieve from within Fusion, by using group of events.
You may set up a group of events for each state.
Each group of events can deactivate itself if necessary, this way the game-status variable decides which group(s) should be active at a particular moment.
Group-jump contains the actions that the character should do when it jumps.
Same for the group-attack. And so on.
Why don't you give it a try ? Write only the actions which belong to a game-status in a single group of events, and see if it is organized enough for you.
I appreciate your feedback Semar, but what you're suggesting I've tried many variations of myself ie a handful of different variables leading to different paths but can never quite seem to get them right?
I appreciate my issue here may simply come down to the need for further trial and error on my part until I find what works for me, but if anyone does know of a better method/set up, something tried, true and time tested then I'd love to hear about it, it'd really help cut down my journey?
I watched the video, but once the syntax got rolling it was all just goobledygook to me. My distate for syntax-heavy programming is why I use Fusion. But from what I could make out of the general gist of it, the concept seemed fairly simple, and I assume that I probably follow some of the state machine principles in my own work, without particularly thinking about it, or explicitly referring to them as state machines.
If you can describe a simple example of a specific state machine, in plain English, then perhaps one of us can explain to you how you'd build that in Fusion.
I'm pleased that it sounded like gibberish to you too, I was thinking this might be something most would understand and I was just behind.
Please login to see this attachment.
I threw this together as an example of how I'd like to set up a player character, the flashing lights showing when an action is taking place, the idea being that they're not all able to switch on at once, with some states able to switch off others , such as the player getting hurt will cancel their Moving and Running variables.
Obviously this is very quick and simple and a fully developed character will have many more states than this, what I wanted to know was how have others created their own similar systems, and which approaches do they find are most effective and reliable, especially for accommodating a larger number of player states?
I understand that a state machine only handles a variable (current_state) that marks the state, right?
I don't know specifically but that would make sense, say if your character had some sort of move which required them to be running + jumping, the input you'd use to initiate it wouldn't activate it unless they were in that state.
I'm just not sure how you'd go about setting one up? As you can see from my example with the stopped/moving, ground/air and running variables, there can be times when multiple states are true at once, would I have to figure out a separate state number to accommodate every possible combination?
For example:
0 = Not Moving
1 = Jumping, Not Moving
2 = Moving
3 = Moving and Jumping
etc
This *could* work but seems very fussy, and the list could become HUGE as more player actions are added, and the possible combinations increasing exponentially?
Display MoreI don't know specifically but that would make sense, say if your character had some sort of move which required them to be running + jumping, the input you'd use to initiate it wouldn't activate it unless they were in that state.
I'm just not sure how you'd go about setting one up? As you can see from my example with the stopped/moving, ground/air and running variables, there can be times when multiple states are true at once, would I have to figure out a separate state number to accommodate every possible combination?
For example:
0 = Not Moving
1 = Jumping, Not Moving
2 = Moving
3 = Moving and Jumping
etc
This *could* work but seems very fussy, and the list could become HUGE as more player actions are added, and the possible combinations increasing exponentially?
You could use the power of 2 (binary representation: 0,1,2,4,8,16,32,64,...)to set the various character status:
0 = not moving
1 = jumping
2= moving
4=running
8=diving
16=firing
32=climbing
....
then, you could compare the value of the charachter status in this way: character_status AND status in order to get the currently status.
For example. You press the up arrow. The character jumps. Then you add 1 to the character _status ( rename it CS from now ).
If the up arrow is not pressed, you subtract 1 to from CS.
Now, while the up arrow button is still pressed, you press also the right arrow. This way the character moves. Then you add 2 to CS.
Now let's freeze this moment. Your CS variable is = 1 +2 = 3.
If you want to know which status(es) are active, you may use:
if CS AND 1 > 0 then the character is jumping
if CS AND 2 > 0 then the character is (also) moving
And so on. If you don't have too much values, you could use this trick to manage any status combination, and still retrieve the single ones using the operator AND against each single status.
Example:
Please login to see this attachment.
Result:
Please login to see this attachment.
Another example. Let's say the character is jumping, moving and firing at the same time. This situation sets our CS to 1+2+16 = 19
This is what happens:
Please login to see this attachment.
Result:
Please login to see this attachment.
I hope it makes sense to you. By the way, I think you are making your game scenario overcomplicated, IMHO.
Thanks for the suggestion Semar, I get the general idea of what you're describing even if I still don't really understand it, but I'll do a test and see if it makes more sense to me that way.
About overcomplicating things you're probably right, but I am still very new to coding. I'm a bit of a perfectionist, and perhaps handicap myself by always trying to find the best way to do something, when I should simply be looking for *a* way at this point in my journey?
There is an extension though I haven't used it
Please login to see this link.
Thanks for the suggestion Semar, I get the general idea of what you're describing even if I still don't really understand it, but I'll do a test and see if it makes more sense to me that way.
About overcomplicating things you're probably right, but I am still very new to coding. I'm a bit of a perfectionist, and perhaps handicap myself by always trying to find the best way to do something, when I should simply be looking for *a* way at this point in my journey?
It sounds like you're a bit hazy on both (a) how exactly the logic of your state machine should work, and (b) how that logic would be practically implemented in Fusion. Given that, perhaps you should just allow yourself to spend some more time playing around in Fusion, getting your hands dirty, and with the handbrake off.
You're absolutely right to be concerned about these sorts of good practices from the outset. Spaghetti code is the worst, and is easy to fall into unless you have a discipline and a good plan. But on the other hand, you're not going to have a truly good plan if you don't have clarity of mind about what you're building. And you won't have clarity of mind without first getting your feet wet and learning from a few of your own mistakes. Don't get so hung up on building the perfect scaffolding that you run out of energy to actually build the house.
Thanks for all the advice folks, I've actually clocked over 3000 hours practice in Fusion over the last few years (yes I log it) so there's a fair bit I can do now, but I'm getting to the stage where I'm trying to tie it altogether into a properly thought out and structured approach rather than just hot shotting ideas when they come to me.
I'm feeling like effective coding doesn't come down to being able to do loads of fancy clever tricks, but rather how good you are at pulling together the basics in a consistent, disciplined, logical fashion?
Thanks for all the advice folks, I've actually clocked over 3000 hours practice in Fusion over the last few years (yes I log it) so there's a fair bit I can do now, but I'm getting to the stage where I'm trying to tie it altogether into a properly thought out and structured approach rather than just hot shotting ideas when they come to me.
I'm feeling like effective coding doesn't come down to being able to do loads of fancy clever tricks, but rather how good you are at pulling together the basics in a consistent, disciplined, logical fashion?
OK, well, you've had plenty of experience, so my comments about 'getting your feet wet' clearly don't apply. I totally agree with you about the importance of a disciplined and thoughtful approach.
For what it's worth, I can give you a peek at how I've done things in my game. I don't know if it qualifies as a state machine (probably not, or at least not entirely) and I don't know if it would meet the approval of any programming theorist. I never studied programming in any proper way, and I'm basically self-taught. Which means I made the dubious choice to pick a teacher who literally didn't know what they were doing.
But Steam says I've spent over 19,000 hours in Fusion, and 95% of that has been on Spryke. In that time, I've (eventually) done a good job of making an engine that works effectively and is easy for me to understand. In the first couple of years I was more haphazard, and by about year 3 I'd ended up with spaghetti code, a mountain of bugs, and had to redo a lot from scratch. Since then, I've been very disciplined with keeping things modular and well-organised. I'm pleased to say that even if I revisit pieces of the engine I made 5 years ago, I'll generally still find my way around pretty comfortably.
I can't overstate how important I believe it is to keep everything about your MFA organised and clear. Not just the code, but the frame editor, the icons, the naming conventions, the general workflow, and of course you should comment extensively. If you allow yourself bachelor habits, what starts as a few dirty socks in the corner today will eventually become a labyrinth of lost belongings and mysterious smells. It's the same with an MFA.
I keep my variables organised in relevant objects, and I give those objects 50x50px icons that are easy to read in both the Frame Editor and the Event List Editor. For example, this is my Spryke States object:
Please login to see this picture.
Inside it are all the different state-related variables of the player character. I use a clock icon to differentiate those that are timer-based variables, and a flag icon for flags, so that I immediately know what I'm dealing with when I see it in an expression. I group them logically and use other altVals as dividers and headings:
Please login to see this picture.
I can keep track of many of these variables during runtime in my debugging panel (the blue section):
Please login to see this picture.
In my code, I first set a bunch of parameters for the physics of the movement engine. For example, gravity. The gravity changes depending on various factors in the game. When Spryke jumps normally, it's one value, when she jumps on a special trampoline platform, it momentarily becomes weaker. While she floats in a bubble, it becomes weaker still...and so on. I set all these different gravity values early on, in my "config" section:
Please login to see this picture.
Lower down in my code is a group called Spryke States where all the various things that can determine or affect the player's state are processed:
Please login to see this picture.
For example, if the player is not on the ground, and is moving downwards, then I determine that the player is falling, which will activate the IF: falling = 1 group (this group is continually closed earlier in the code, so it will only run if it's turned on here, because falling=1):
Please login to see this picture.
In this group, I set up various things that need to be set up. For example, I cancel out certain states/variables that clearly don't apply any more (eg. set jumping and isStopped to 0). Some things will be set no matter what (event #5654), while others must only be set if the player is not on a wall (event #5648). I also set the gravity (how much the player will be pulled downwards per frame) and the fallCap (how fast the player is allowed to drop before further acceleration is stopped):
Please login to see this picture.
However, some of the things that were set here may yet be overridden. For example, lower down is the Floating section of the code. And if in this section the player has been determined to be floating, then a bunch of different code will execute. Including different gravity and fallCap values that will overide what was set earlier:
Please login to see this picture.
Once all of the player's internal states have been processed, we then process various mechanics that can affect the player externally:
Please login to see this picture.
For example, if the player is standing on a vertical platform, we make a note of it in the Spryke States object by setting vertFloater to 1, and we record how fast that platform is moving in YmovingPlatMovement:
Please login to see this picture.
Notice that the player object hasn't actually been moved in any way yet. There have been no set X(player) to... or set Y(player) to... actions thus far. All I've done is set a bunch of variables. Once the entire Spryke States and Movement-related Mechanics groups play out, the variables will have been set, cancelled out, and overidden as needed, and we arrive at the final states that the player is in. Only then is it time to actually process the movement:
Please login to see this picture.
So, for example, we now apply the gravity (insofar as the fallCap will allow). As we saw above, what those values actually are will depend on various factors. But by the time we get to this point, it's all been worked out, and they are what they need to be, depending on the various player states:
Please login to see this picture.
After applying gravity to the Y speed, we then adjust it for various other things that may be affecting Spryke. For example, the vertical platform platform we registered earlier. Notice that YmovingPlatMovement will actually be added to Spryke's Y movement every single frame, no matter what. Most of the time, YmovingPlatMovement will be 0 so won't have any effect. But whenever the player is indeed on a vertical platform, YmovingPlatMovement will be set appropriately above, and will be applied here.
Please login to see this picture.
We then consolidate everything into a final value yMovePixelPerFrame (second-from-bottom action in above pic) that will be used to actually move the player:
Please login to see this picture.
Finally, once the movement has been completed, we reset a bunch of stuff, and perform a battery of tests to see where the player has now ended up (eg. is she now touching a wall? if so, what type of wall?), some of which are shown below.
Please login to see this picture.
Spryke has been moved, and the code is totally up to date with her various states. Now, and only now, we ensure the appropriate animation is playing, depending on her various states:
Please login to see this picture.
So that's, broadly speaking, the process. Everything happens in due course, in an appropriate part of the code. All the different physics and movement parameters are stored at the top, where I can easily see and modify them. They will then be applied as appropriate by subsequent groups. First we determine the player's various states, then we check whether she's being affected by any external mechanics. Only once we know all this information do we perform any movement. Finally, once we've moved the player and re-measured her relationship with the environment, we update her animation. Here's a snapshop of my Event Manager window:
Please login to see this picture.
You will have noticed that I use a lot of graphic characters in my group names. Keeping things clearly labelled and visually segregated helps remove cognitive friction so you can spend more mental energy problem-solving and less on trying to remember what does what. I posted a big list of useful characters Please login to see this link.. I have dedicated buttons on my streamdecks/macropads for my most commonly used ones, and I use a pop-up clipboard manager called Phrase Express for the rest:
Please login to see this picture.
Volnaiskra,
this is absolutely brilliant, fantastic !
I tend too to organize my code, but what you have shown here is an amazing example of solid organized structure - really really impressive !
I'll use this topic as a structure reference from now.
Thank you for this gem, really !
Best regards,
Sergio
Thankyou so much for the deep and detailed post Volk I've already bookmarked it, it'll make a great resource to check back to
It's fascinating reading your thoughts on your own coding journey, and how similar they sound to my own? I'm sure it's the same story for many others reading, how we arrive at our own ways to get around problems and start structuring things in ways we can understand more quickly and clearly, like what you mentioned about using colours and symbols to represent different areas of code being much easier to recognise than letters and numbers?
I do similar things in my notes, anything referring to an upward movement/top colliders/jumping and hitting a ceiling etc being sky blue, downward stuff being brown like earth, left is represented by Lime green and right is Red. It really does make things much simpler to recognise and work with, it's just a pity that - to my knowledge at least - we can't change the colour of the groups themselves which are always grey?
Anyway, it sounds like you made a similar journey to me, and having been at it so much longer you've gradually been able to develop and refine a precise and effective style which works for you, hopefully this will be the case for me in time, and I can escape my own 'labyrinth of lost belongings and mysterious smells'
I really appreciate you and Semar taking the time to offer me your advice, it's been a great help
I can keep track of many of these variables during runtime in my debugging panel (the blue section):
Please login to see this picture.
Awesome
how did you make that panel?
Don’t have an account yet? Register yourself now and be a part of our community!
Almightyzentaco (Fusion 2.5 Tutorials)
Captain Quail (Firefly Tutorials)