My simple suggestion would be just to run the game at 60 fps. A lot of games of today shoot for that goal. This will make the jumping and moving of the stick people / monsters seem munch more fluid. And i feel like in a fighting action game like this one having more fluid motion really makes the game more enjoyable.
This idea is for stick online 2 and 3. But i know with stick online 2 there will need to be more work to make sure everything works at the speed its suppose to.
But most of all its easy to implement.
I'm not really an expert on this, but wouldn't having 60 frames make Stick Online half as fast? But I guess he could just double the speed. Anyway, Isn't stick online smooth already? lul, but yeah, my game runs on 30 fps like 98% of the time, so I guess 60 wouldn't be a problem for me.
I dunno, I mean sometimes with a pvp type game, fluidity can become a bad thing.
Quote from: God-I-Suck on October 24, 2009, 07:25:27 PM
I'm not really an expert on this, but wouldn't having 60 frames make Stick Online half as fast?
other way around. Your getting twice as many frames in the same about of time.
QuoteI dunno, I mean sometimes with a pvp type game, fluidity can become a bad thing.
Nope. it makes it better because the motions of the stick people will be smother making it easier to see what is going on. The more fps the better.
Quote from: http://en.wikipedia.org/wiki/Frame_ratea low frame rate will not be able to give the illusion of motion effectively and will affect the user's capacity to interact with the game while a frame rate unsynchronised with the display device will show 'choppy' movement.
Quote from: God-I-Suck on October 24, 2009, 07:25:27 PM
I'm not really an expert on this, but wouldn't having 60 frames make Stick Online half as fast? But I guess he could just double the speed. Anyway, Isn't stick online smooth already? lul, but yeah, my game runs on 30 fps like 98% of the time, so I guess 60 wouldn't be a problem for me.
It is literally how many frames are displayed per second. Pretty much it makes everything more fluid...but it wouldn't slow anything down. Pretty much, you add in more frames "in-between" the current ones, and it looks a lot better. Of course, this is double the work on the animators part. I think it would be nice but isn't NEEDED since SO is a 2d, cartoonish, platformer and not an FPS. Still, it would be nice.
60 FPS causes fps lag on slower computers. The less frames per second, the less fps lag. I've played on computers where running 30 FPS is strenuous.
I think the game should stay at 30 FPS. I like the speed the way it is now.
Quote from: Mr Pwnage on October 24, 2009, 08:22:10 PM
Of course, this is double the work on the animators part.
Nope. He can keep all the same animation. He would just half to reduce the speed they play at by 1/2. But I'm no asking for smoother animations. I'm asking for smother movement. The animations we have now are not 30 fps them self's but are much less and is hand timed by Meiun himself. This timing lets game maker repeat a lot of frames to stay in sync with the fps the game is running at now.
Lets say my stick dude moves about 6 pixels at 30 fps. well at 60 fps it i would only need to move 3 pixels a frame to move the same speed. And it would look smother. But there animations of walking will still work at the same speed.
The movement of the sprites on screen will look smother but the animation of the sprites them self will not change speed/smoothness. understand?
Think of it like a TV on a conveyor belt. The tv plays the animation of the stick man running and the conveyor belt makes the stick man looks like he moving.
@Torch
I feel as if this will not be a problem with most people. I'm sure most people here are able to run the game at 60 fps. Considering most other games you play today run at this speed.
And if it really bothers you he can make it a option. Its not hard to do.
also if your not running at 30 fps now this will not make you any worse when the game is at 60fps. But it will make the people who can take more be faster. So if you feel as if people can not keep up you can have a 30 fps mode. So the game would look the same as it does now but will look choppy compared to the 60 fps mode.
There a more complex ways of solving this problem but i feel that will be too much work.
@11clock
Ill respect that.
60 fps would be a pointless increase in CPU usage with very little very little visual enhancement in return (in Stick Onlines case atleast).
How much more? Have your tried?
See I'm in the mind set that even if its little visual enhancement that the extra cpu it will take not much eater.
But if the gain is not as grate as the price i guess it would be more logic to stay how it is.
It will need to update everything twice as much... There is no question this is not a change I would like to make lol. A 2D game like this really wouldn't see any significant improvements, and unless it only added a very small CPU strain it is not something I would be willing to consider. It would just be overkill.
QuoteIt will need to update everything twice as much...
well. you could keep everything else at 30 fps or lower and let movement be calculated at 60. But that would be a lot of work to keep everything in sync and i know the out come of that is not worth the gain. : P
But if you as the creator of the game feel as if this is overkill I'm fine with that. Its your game and i what to experience it how the game developer intended. I'm happy how this topic turned out. : )
What Meiun said, essentially. If I'm thinking about this correctly, I can already tell you that, in the case of Stick Online, a visual difference would be barely noticeable, if noticeable at all.
Quote from: Chaos on October 24, 2009, 11:34:21 PM
What Meiun said, essentially. If I'm thinking about this correctly, I can already tell you that, in the case of Stick Online, a visual difference would be barely noticeable, if noticeable at all.
Luckily, it's not nearly as noticeable with 2D games as it is 3D. Despite this, I personally would see a large difference in how smooth the game plays if it was switched to 60 fps.
One idea for Meiun is to have the game run at the max possible framerate, and then compensate for how that effects player movement, etc. This would make the game smoother, and decrease problems that arise from playing the game under 30 fps. I'm not sure what he has already done to help the issue of a lower frame rate, but it's important enough to note.
I'm aware of that possibility, but it still wouldn't be worth it to me. I don't want to make it demand that much cpu of peoples computers for that little a difference.
Jake, do you have such a system in your game? Or does your game run nativity at 60 fps? just wondering.
Quote from: ARTgames on October 25, 2009, 10:49:57 AM
Jake, do you have such a system in your game? Or does your game run nativity at 60 fps? just wondering.
It runs at 30 fps, but I'm looking into frame rate compensation techniques.
The only good thing about 60 fps is that the collision checking is more accurate. Bad things are that GM games with more than 1 object tend to lag at 60fps for many PCs, and you have to go back and edit EVERYTHING to go twice as slow so that the balance is restored. Things don't necessarily need to be updated more... just less often quicker. But I've done this before, with a much smaller game, and changing all the variables to be scaled up 2x is a PAIN.
~Aqua
Quote from: Aqua on October 25, 2009, 05:33:26 PM
The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua
Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.
QuoteBad things are that GM games with more than 1 object tend to lag at 60fps for many PCs,
To what proof or study have done to back this up? I would like to see it. I and other gm games with my standard hardware work just fine.
Quote
Things don't necessarily need to be updated more... just less often quicker. But I've done this before, with a much smaller game, and changing all the variables to be scaled up 2x is a PAIN.
What?
@Jake
Cool! I would like to see what you can do looking at your past work.
Quote from: ARTgames on October 25, 2009, 06:04:12 PM
Quote from: Aqua on October 25, 2009, 05:33:26 PM
The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua
Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.
They are relevant. In a 30fps game, to have something move 2 inches in 1 second with 72DPI, you have to go 4.8 pixels per step. If your object is a 1x1 pixel, it will skip over 3-5 other pixels in each step. However, in a 60 fps game, if you keep the rate at 2 inches in 1 second, you're only going at 2.4 pixels per step; and in the same situation you're skipping half the amount of pixels, thus increasing the accuracy of collision checking.
Quote
QuoteBad things are that GM games with more than 1 object tend to lag at 60fps for many PCs,
To what proof or study have done to back this up? I would like to see it. I and other gm games with my standard hardware work just fine.
Unfortunately I lost that game, but it was my version of Spore to keep me busy until the real one was released. However, I posted it on a community, and many people had issues when I changed the fps from 30 to 60. I will try to find the link in that community, and will edit with my findings.
Edit: The two people who played the update both had lag. http://www.xspore.com/community/spore-games/3339-gm-spore-actual-spore-game-2.html
~Aqua
Quote from: Aqua on October 25, 2009, 06:30:35 PM
Quote from: ARTgames on October 25, 2009, 06:04:12 PM
Quote from: Aqua on October 25, 2009, 05:33:26 PM
The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua
Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.
They are relevant. In a 30fps game, to have something move 2 inches in 1 second with 72DPI, you have to go 4.8 pixels per step. If your object is a 1x1 pixel, it will skip over 3-5 other pixels in each step. However, in a 60 fps game, if you keep the rate at 2 inches in 1 second, you're only going at 2.4 pixels per step; and in the same situation you're skipping half the amount of pixels, thus increasing the accuracy of collision checking.
That really isn't neccesarily true. It is based entirely on how you code your collision and movement engine. A system can easily be programmed to avoid this issue if desired.
Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious. But this doesn't allow for precise collision checking with the actual sprite. What were you thinking of?
Offtopic- I saw your public picture for your profile on Facebook- I hope that's outdated ;)
~Aqua
Quote from: Aqua on October 25, 2009, 06:30:35 PM
Quote from: ARTgames on October 25, 2009, 06:04:12 PM
Quote from: Aqua on October 25, 2009, 05:33:26 PM
The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua
Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.
They are relevant. In a 30fps game, to have something move 2 inches in 1 second with 72DPI, you have to go 4.8 pixels per step. If your object is a 1x1 pixel, it will skip over 3-5 other pixels in each step. However, in a 60 fps game, if you keep the rate at 2 inches in 1 second, you're only going at 2.4 pixels per step; and in the same situation you're skipping half the amount of pixels, thus increasing the accuracy of collision checking.
Why are you doing that? >_< You know all you need to do is check the amount its going to move. Your going to move five pixels to the left from your object check 5 pixels to the left. Don't check one pixel/spot/etc ever step/frame/loop/etc. I could make you something to show but i feel you might understand now. Don't make it harder for your self.
QuoteEdit: The two people who played the update both had lag. http://www.xspore.com/community/spore-games/3339-gm-spore-actual-spore-game-2.html
~Aqua
That is not sufficient. That was only a sample of 2 people with unknown hardware. And we don't even know if the problem was fps related.
@Meiun
Thank you.
Quote from: Aqua on October 25, 2009, 06:46:41 PM
Offtopic- I saw your public picture for your profile on Facebook- I hope that's outdated ;)
~Aqua
A bit. Never been a big facebook user. But regardless, screw you. Last thing I need is a bunch of !@#$ing teenagers critiquing my facebook, honestly.
Quote from: Aqua on October 25, 2009, 05:33:26 PM
The only good thing about 60 fps is that the collision checking is more accurate. Bad things are that GM games with more than 1 object tend to lag at 60fps for many PCs, and you have to go back and edit EVERYTHING to go twice as slow so that the balance is restored. Things don't necessarily need to be updated more... just less often quicker. But I've done this before, with a much smaller game, and changing all the variables to be scaled up 2x is a PAIN.
~Aqua
Sorry, but you're way off the mark. Running a game at 60 fps has more upsides to it than "collision checking is more accurate". Whether or not you think the upsides outweigh the downsides is whats important. Also, your complaints about changing game code to accommodate the higher frame rate are only valid if the game was originally programmed with 30 fps in mind. The argument could go either way depending on what the developer originally coded the frame rate around. "30 fps suckz cuz you have to speed up da objects" is the same argument as yours but it takes the opposite stance. If you're replying in regards to Stick Online, then you might want to make that more apparent.
I also wanted to point out that having your collision checking rely on the exact frame rate of the game shows bad programming methods. Doing so does not account for frame rate dips, and generally shows a lack of effort in the game design.
Quote from: Jake on October 25, 2009, 08:20:20 PM
I also wanted to point out that having your collision checking rely on the exact frame rate of the game shows bad programming methods. Doing so does not account for frame rate dips, and generally shows a lack of effort in the game design.
I second that.
Quote from: Aqua on October 25, 2009, 06:46:41 PM
Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.
Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.
Quote from: Meiun on October 25, 2009, 08:25:01 PM
Quote from: Aqua on October 25, 2009, 06:46:41 PM
Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.
Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.
Good thing too...because I can say from experience that GM collisions are absolutely horrible. I was making one game, and had to tweak with the gravity: Pretty much, when the object hit the ground after falling it was supposed to stay there and become a platform, but it actually only did that 80% of the time and the other 20% it deleted itself. Lowering the gravity fixed this (well didn't fix, but made it happen a lot less)...just an example of how buggy GM collisions are. Inconsistencies in a code which SHOULD be providing a consistent result.
Quote from: Mr Pwnage on October 25, 2009, 10:17:18 PM
Quote from: Meiun on October 25, 2009, 08:25:01 PM
Quote from: Aqua on October 25, 2009, 06:46:41 PM
Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.
Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.
Good thing too...because I can say from experience that GM collisions are absolutely horrible. I was making one game, and had to tweak with the gravity: Pretty much, when the object hit the ground after falling it was supposed to stay there and become a platform, but it actually only did that 80% of the time and the other 20% it deleted itself. Lowering the gravity fixed this...just an example of how buggy GM collisions are.
Well thats almost always just because the person isn't very good with GM (no offense). Also, were you using "drag and drop" vs actual coding? (even then same thing applies to some extent). The current stick online has a sortof mix of my own coding with built in GM functions (functions, not D&D) but still obviously works fine. Long story short, it's usually the coder not the code ;] The built in collision stuff may not be perfect for every scenario or work exactly how some people like best, but it definitly does "work".
Anyways, I think we are starting to shift a bit off topic here.
Although Game Maker has somewhat limiting built-in functions, I've never known them to be buggy. Perhaps increasing the gravity too much caused the object to bypass the platform entirely? Make sure your collision checking code accounts for the speed of the moving object. I would need to see the code to tell you exactly what's happening though.
Woops, sorry for getting so off-topic.
Well it wasn't with D&D...and it was years ago when I made it, so I don't know that I could resurrect a code for you. Either way, I can't assure you my programming skills were all that great at the time, but I can say that GM collisions are very limiting, sometimes buggy, and have enough flaws that I prefer to use DLLs for coding collisions. Just my preference though.
Quote from: Mr Pwnage on October 25, 2009, 11:15:31 PM
Well it wasn't with D&D...and it was years ago when I made it, so I don't know that I could resurrect a code for you. Either way, I can't assure you my programming skills were all that great at the time, but I can say that GM collisions are very limiting, sometimes buggy, and have enough flaws that I prefer to use DLLs for coding collisions. Just my preference though.
All GM really does is offer a bunch of functions and tools for you to use to create your collision system. The functions work for exactly what they are intended, and really do not have any "bugs" (I've been using GM for something around 9 years now I think? Think you can trust me on that one). How you use them, is (as stated earlier) another story. If you want to get really fancy in terms of your needs and wants for it all then you can just code your own replacements/alternatives and not use their built in, but I wouldn't see why you'd need a DLL for it. In terms of collision stuff theres really nothing a DLL could do that you couldn't just do with coding it in GML (the overhead of the constant DLL calls might even slow it down a bit for such small repetitive calls). But, to each his own. I don't mean to judge :P. But yeah, I think I've had enough of this topic for the time being X_X
Jake and Meiun, to be honest, I could not agree more. I'm glade you all can explain this way better than i can.
@Mr Pwnage
Just wondering. What is this DLL you were talking about?
Although i know it wouldnt happen, coz its not really worth the time, it would be cool if there was atleast an option to change between 30 and 60 fps, that way atleast people can decide so if their computer can handle it, then they can change to 60 if they want :P
Quote from: Meiun on October 26, 2009, 12:16:37 AM
Quote from: Mr Pwnage on October 25, 2009, 11:15:31 PM
Well it wasn't with D&D...and it was years ago when I made it, so I don't know that I could resurrect a code for you. Either way, I can't assure you my programming skills were all that great at the time, but I can say that GM collisions are very limiting, sometimes buggy, and have enough flaws that I prefer to use DLLs for coding collisions. Just my preference though.
All GM really does is offer a bunch of functions and tools for you to use to create your collision system. The functions work for exactly what they are intended, and really do not have any "bugs" (I've been using GM for something around 9 years now I think? Think you can trust me on that one). How you use them, is (as stated earlier) another story. If you want to get really fancy in terms of your needs and wants for it all then you can just code your own replacements/alternatives and not use their built in, but I wouldn't see why you'd need a DLL for it. In terms of collision stuff theres really nothing a DLL could do that you couldn't just do with coding it in GML (the overhead of the constant DLL calls might even slow it down a bit for such small repetitive calls). But, to each his own. I don't mean to judge :P. But yeah, I think I've had enough of this topic for the time being X_X
Well maybe buggy wasn't the proper wording...more inconvenient. I use DLLs to make things more "user-friendly" to my liking, primarily with 3d collisions. And it doesn't slow the game down if you use them correctly, but that's another story.
I could only ever see myself using a collision DLL for 3d. But then again, I wouldn't use GM for a 3d game, as I find it extremely limiting, other then that collision DLL's are a waste of memory. As Meiun said though "each to there own" I personally can't see myself coding my own collision events as I absolutely adore the inbuilt collision functions (mixed in with some good o'l coding as well of course).
Now back on topic here, I don't agree that SO should demand more CPU! :O SO2 takes enough out of my good old windows 98 ;)
Quote from: Aqua on October 25, 2009, 06:46:41 PM
Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.
Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.
[/quote]
Your collision system will hopefully be more effecient for SO3 dude. 'For Loops' for collision detection is very inefficient. I'm trying to look into Separating Axis Theorem for my future games, so I'll probably need someone who's knowledgeable in Geometry and Trig.
In any case, a 60 FPS switch on/off switch, whilst nice would require Meiun to rethink how to handle gravity as getting that to match the gravity of 30 FPS isn't as simple as 1,2,3.
Quote from: Doogie on November 24, 2009, 11:38:04 AM
Your collision system will hopefully be more effecient for SO3 dude. 'For Loops' for collision detection is very inefficient. I'm trying to look into Separating Axis Theorem for my future games, so I'll probably need someone who's knowledgeable in Geometry and Trig.
In any case, a 60 FPS switch on/off switch, whilst nice would require Meiun to rethink how to handle gravity as getting that to match the gravity of 30 FPS isn't as simple as 1,2,3.
Isn't Separating Axis Theorem collision detection only helpful when using more complex shapes?
Quote
Isn't Separating Axis Theorem collision detection only helpful when using more complex shapes?
Not really, unless you call a triangle complex. Its the theorem that
'N' uses. http://www.metanetsoftware.com/technique/tutorialA.html (http://www.metanetsoftware.com/technique/tutorialA.html)
But what are the advantages of using it in a game that only needs rectangular collisions? If anything, it would cause an unnecessary amount of slowdown.
Quote from: Jake on November 25, 2009, 12:46:13 PM
But what are the advantages of using it in a game that only needs rectangular collisions? If anything, it would cause an unnecessary amount of slowdown.
Yeah I guess, but I put it up for future reference as the new SO might use slopes. In any case, a simple code to check if the player is colliding with the Axis-Aligned Bounding Box (AABB) and snapping them to the top of the floor would be more effecient for collision in the current build of the game, unless that part has been re-written over the years.