So I was thinking a couple days ago, and I've been wanting to help out with this project and I realized there is one big way I can help. Because during my time away from here, I was certainly not away from GameMaker: Studio.
I've actually got some code and some tweaks I'm wanting to suggest to you which would achieve the following in your game:1) Increased user input responsiveness; faster input response (such an important thing, yet GM users rarely address it, probably because they aren't aware they can control it)
2) More fluid gameplay, smoother than a baby's buttocks
3) Increased efficiency and game FPS (i.e. not the graphical FPS, but the logical 'FPS')
But instead of barfing up the code here right now in a rather haphazard way, I'd like to give it in a very nice and concise way. I think I mentioned some place that I'm trying to get a GameMaker:Studio tutorial thing written out with the plan to post a topic in the code section, and I'll be including the code I'm talking about in there. So I'll be sure to let you know when I get it up (or you'll just see the topic, so I guess I don't need to tell you...). So I'm just giving you a heads up. It will be the part that talks about
disconnecting the drawing from the logic. It makes use of frame skipping.
Of course, I'm saying all of this assuming you achieve the 60 FPS simply by setting the room speed to 60. And you probably don't have any kind of frame skipping implemented yet? Please correct me if I'm wrong.
I played the latest tester demo yesterday and realized the physics/movement speeds and animation speeds are still needing to be tweaked and slowed down a bit (I'm guessing that's because of the transition to 60 room speed from 30?). I was actually reluctant to even mention this stuff about tweaking it with frame skipping and whatnot until I had played the demo, because if all your speeds were already perfected, you'd have to change them again to implement my suggestions, if in fact your room speed is only 60 and not set higher. I say this because I will be suggesting upping the room speed to 300,
and it should be obvious that a faster room speed means more executed cycles of events per second, which means more movement will happen per second, making everything faster, so things need to be made to move less each step to compensate. Pretty straightforward.
BTW, faster room speed is how you gain better user input responsiveness. This is something I will explain in that topic I mentioned. I hope many GM users catch on to this, because the slightly sluggish controls of GM games are hurting so many games. Input response is ultra critical to a proper and great gaming experience.
So anyway, I'll be trying to write out all this stuff as fast as life allow me so I can get that topic up for you and all the GM users. I expect it will help the project a lot and it's really not hard to implement. BTW,
it's less than 10 lines of GML to add. The time-consuming part of implementing it would be to slow down all of your movement and animation speeds to compensate for the room speed up.
Of course, it'll be up to you to implement or not, but I'm just throwing the suggestion out there, because I seriously think it would be more than worth the trouble of implementing it.
Possible complications after implementing:It would not break anything
unless you're putting logic inside of the draw event that doesn't belong there, because frame skipping will often times not even execute anything in the draw event; it's not like it just skips over drawing functions, but it skips the draw event entirely.
You would have no worries of my code breaking game logic. My method does not control speeds by multiplying movements by delta time, as that gives slight inaccuracies in your movement logic, unless you do some overly-involved code. But it's seriously not worth it at all, and the extra logical processing required for that overly-involved code would likely give worse CPU performance than my way in the end. Even if that weren't the case (which I'm pretty certain it would be), you'd still get more complex code that could even lead to nightmare testing and headaches if you make a tiny slip up, or worse, you might even miss a screw up that causes logic to be inconsistent and may even make the gaming experience unfair at random intervals... uh, yeah, just too many downsides with delta time movement, especially since GM already has stuff 'under the hood' of its room speed control to maintain timing quite well.
Over the course of about 1.25 years, I was off and on trying various things with delta time and frame skipping until I arrived at the code I have now, and it's just a really good solution, given the way GM works. Some other GM users also have done a lot of work testing and trying various things out in this area and have concluded that frame skipping is the way to go as well.
Ah, but I'd better shut up. I always talk too much when it comes to these things. Sorry, haha.
I really hope this info - and the stuff I plan to share with you later - will help you take HoB and any other future GM projects further.
/ wall of text
Looks like this bug really upset Link. As you can see in the image, he's beside himself (I can't resist making a bad joke).
Actually, I got the error again when I tried shooting an arrow at a wall in there, so I guess it just doesn't like the player to shoot arrows while in the shop?
