Scrolling Game Development Kit Forum
SGDK Version 2 => Help, Errors, FAQ => Topic started by: Wyzemann on 2011-03-17, 03:39:57 PM
-
I am trying to set up the player to have controlled jumping (Commander Keen style). This means there is power for a certain amount of time when the jump input is pressed. However you have the option of letting off mid-jump for shorter jumps. You can also move left or right during the jump.
So I have set a parameter to read the frame at which the input is pressed. It adds an arbitrary number of frames to it and stores it to a new parameter. When it reaches that number it cuts off the power until the landing. (I've yet to determine how to prevent multiple jumps within the jump during this time but it's a start).
The jump is now controllable. The problem is that the frames advance significantly faster when you are moving left or right at the same time as jumping which means you barely get off the ground when moving, but can get pretty high when not moving horizontally.
It's almost like the counter is getting two streams of data at the same time whenever you have x motion. The FPS read at a constant rate. The counter is ticking markedly faster when the horizontal input is pressed. I'm not sure if this is a bug or if it's user error. However if I remove the one data source there is no activity on the counter.
All of the jump handling is done from a level plan. The horizontal motion is done from the sprite definition. Everything thus far is done using basic rules without scripting.
Any suggestions would be appreciated.
-
Hard to get a full grasp on your problem without seeing it firsthand. I think this is some of the information I need to know:
1. What is incrementing your counter? Can you verify that it's something that only executes once per frame (is that how it's supposed to operate?)
2. What are you referring to with terms like "streams of data" and "data source"? Those aren't SGDK2-native terms... perhaps you are using them to refer to something you build into your project or using another term for an SGDK2 concept?
3. Your goal sounds relatively simple, have you considered the following solution?
a. Add a parameter to the player sprite
b. When you detect a jump, set the parameter to 1
c. If the parameter is greater then or equal to 1, then increment the parameter value; if the jump button is still pressed, also AlterYVelocity by a very small negative amount
d. If the parameter is greater than 40 (or some jump time limit), reset the parameter to 0.
If this doesn't help, please pose your project or a link to your project in your reply so I can take a look at it firsthand. Attachments to post have a limit of 128 KB or 256 KB I think (if I recall correctly -- I forget which), so if it's larger than that, you'll have to make a simple example of the problem and post that or post your project elsewhere and link to it, or upload your project to the SGDK2 support site at http://sgdk2.enigmadream.com/support/ (http://sgdk2.enigmadream.com/support/)
-
I did pretty much the jumping behavior you want to do in my game. I kinda tried to do the same thing than you Wyzeman, but I found a much easier way to do it. Here is my recipe:
1- Like bluemonkmn said, use a sprite parameter (I called mine IsJumping). Set it to 1 when you input the jump button and set it to 0 the next time your character SnapsToGround or RidesAPlatform.
2- When your character jumps, on the initial input only for the jump button (right after or before you set the IsJumping parameter to 1) input a negative dy to your character powerful enough to reach the desired max height of a jump.
At this stage, your character jumps at max height whenever you press the jump button but only when it is on the ground. The character always jumps at the same height whether you hold down the jump button or not. Nothing in this behavior influences horizontal inputs, so you can still control horizontal direction during your jump. And now for the last step, breaking the jump when the players release the jump button.
3- Still on the sprite behavior, add a condition that looks for jump button input press with parameter InitialInput only to false and add a "and" condition to "IsJumping = 1". This way you know all the time during the jump if the jump button is pressed. But we want to know the opposite. So switch the 1st condition to listening to button input to not (check the "not" check box). This way we know, all along the jump if the player releases the jump button at any time. Within this condition, set the dy of your character to "0".
So at any time during the jump, if the player releases the jump button, the jump breaks and the character starts to fall.
All those rules are in the sprite definition, so you don't have to rewrite them in each map you do.
So to, sum it up, in pseudo code (you can do all of this by rules) it looks like this:
1 : If jump buttonPressed(initial only = true)
2 : and IsJumping = 0
3 : IsJumping = 1
4 : dy = -10
5 : end
6 : if snaptoground(1)
7 : or IsRidingPlatform
8 : IsJumping = 0
9 : end
10: if not jump buttonPressed(initial only = false)
11: and IsJumping = 1
12: dy = 0
13: end
Your horizontal code for inputs goes wherever and is not influenced by the jump behavior.
I hope this helps!
-
Ah, just remembered something (I'm doing this by memory, so I might forget other things), between rule 11 and 12, you also have to check if your character dy<0, other wise, it's just gonna stay suspended in the air. So it looks like this:
11: and IsJumping = 1
11.5: and dy < 0
12: dy = 0
I think that's it.
-
As of now the game is about as simple as it can be so I simply uploaded it as is to the link you suggested. Right now all I have is a player sprite, a couple of tiles, and some counter displays, and I'm trying to make it behave.
I am grateful for the solutions you guys have proposed. I am looking forward to implementing them ASAP. The counters are just for display (troubleshooting) since I don't know how to draw parameter data directly. They aren't being used to control anything. The rules that affect the behavior of the game are tied directly to the sprite's parameters.
I apologize for using abstract terms. I think it would be easier just to look at what has been done. The counter is tied to the player sprite parameter which is tied to m_ParentLayer.m_Player1.frame. The counter is updated as long as the up input is pressed.
For me this is somewhat of a black box. I understand this is supposed to provide the frames of the animation being displayed in sequence, which I suppose should be at the framerate of the game. (Which I have limited to 30 fps).
It's like it's getting pulsed 30 times per second by whatever pulses it when the jump animation is playing (one data source), and then when there is a horizontal input it's getting pulsed by an additional whatever so it gets too many pulses per unit time. Of course this is speculation and I'll let you be the judge. The bottom line is it is behaving an in unexpected way that could have implications for other things as well.
Thanks a bunch,
Chris
-
I can't look at the project at the moment (hopefully I will remember when I get home), but I can provide some more tips.
1. You can get past the black box problem and debug your project if you download C# Express (for free) from http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-csharp-express (http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-csharp-express). SGDK2 outputs project files so you can load and debug the project. (It outputs the project in an old format so you'll have to go through the project upgrade process if you get C# Express 2010, but that's pretty simple and quick.) Then you should be able to step through the code if that helps.
2. You can output debug information about parameters with a function called (I think) LogDebugValue.
-
Does your sprite animate when moving horizontally and not otherwise? If so, I wonder if something about the way you tied the counter to the sprite's frame is causing it to change faster when the sprite is animating. (Frame does not change when the sprite is not animating, for example because it is not moving horiziontally, but changes significantly in proportion to the speed that the sprite is moving if you tied animation speed to horizontal velocity.)
-
I looked at the project and I see you have rules that are causing the counter to increment twice per frame when you are jumping and moving horizontally. The AnimateJump rule will cause the counter to increase when you are jumping. AnimateL and AnimateR will cause it to increase when you are moving left or right. So if you are doing both at the same time, it will increase twice as fast.
-
That's cool. I didn't think that would overlap like that. My intention was to apply those to only the L and R sprite states, and had no idea that could happen.
I am interested in getting set up with the C# compiler and will get that running soon. Unfortunately it looks like my time will be more and more limited each day as I am in the process of moving out of state and approaching the deadline for vacating.
Thanks for your input,
Chris
-
I integrated Vincent's strategy into my logic and cleaned things up a bit by consolidating everything back into the Sprite definition.
Setting dx to 0 mid jump is much more elegant than using a timer to block an input. I also reconfigured the animation to prevent the double framerate problem in case I use timers in the future. The only thing I had a problem with was using the "snaptoground" method. It seems to work intermittently and requires a high threshold to function at all (around 12). I tried implementing the "IsOnTile" method and that does not work either, ven when I set to detect all solid tiles. It's a mystery.
The only thing that does work for me is the "Blocked" method and it works consistently.
So far progress is very slow and I'm learning through trial and error, and of course, your suggestions.
-
IsOnTile will likely never return true for a solid tile because sprites generally don't overlap solid tiles. That's what IsOnTile is for -- checking what tiles the sprite is overlapping. The Blocked function is better for determining if the player is able to jump. That's what the sample game uses for determining if the player should be able to jump (in combination with IsRidingPlatform). Also, I wrote a function for my own project called "IsAgainstTile" for checking tiles around the sprite rather than overlapping the sprite. You could add this to a new file in your project's "SourceCode" folder and then it would be available for you to use in the sprite rule editor too if you want it:
public abstract partial class SpriteBase : GeneralRules
{
/// <summary>
/// Determines if a tile at the sprite's current position is a member of the specified category.
/// </summary>
/// <param name="Category">Tile category against which the tile will be checked.</param>
/// <param name="RelativePosition">The sprite may be on multiple tiles at once. This parameter
/// indicates which part of the sprite to look at, and gets the tile from the layer at
/// the specified position.</param>
/// <returns>True if the specified point in the sprite is on a tile in the specified category, false otherwise.</returns>
[Description("Examines the tile on the layer at the sprite's current position and determines if it is a member of the specified category. The RelativePosition parameter determines which part of the sprite to use when identifying a location on the layer, and Direction determines which direction from that point to check. (TouchTiles is not necessary for this function.)")]
public bool IsAgainstTile(TileCategoryName Category, RelativePosition RelativePosition, Direction Direction)
{
Debug.Assert(this.isActive, "Attempted to execute IsAgainstTile on an inactive sprite");
System.Drawing.Point rp = GetRelativePosition(RelativePosition);
switch(Direction)
{
case Direction.Up:
rp.Offset(0, -1);
break;
case Direction.Right:
rp.Offset(1, 0);
break;
case Direction.Down:
rp.Offset(0, 1);
break;
case Direction.Left:
rp.Offset(-1, 0);
break;
}
return layer.GetTile((int)(rp.X / layer.Tileset.TileWidth), (int)(rp.Y / layer.Tileset.TileHeight)).IsMember(Category);
}
}
In my project, SnapToGround is after ReactToSolidity and before MoveByVelocity. If you don't have it there, or if you have other rules in between, they might interfere with SnapToGround's ability to function properly.
Have you looked at how the player sprite in the sample game works to see what you might learn from that?
-
I actually did learn from the player example, but now that I look at it again I am understanding more since I've learned a lot since I started.
In fact I wouldn't have got past going left and right without it. The player example is much simpler. My player now has different states for jumping and switches left and right states in the air, and now, thanks to Vincent, the jump can be interrupted based on the input being released.
I will be glad to try out your suggestions and new rule and see how they all work, probably some time this evening. Next I will work on adding some new animations for climbing and shooting and see how I can make those work.
Chris
-
Hey Chris!
I'm glad you found my code useful! Likfe bluemonkmn said, SnapToGround works well after ReactToSolid. I wasn't aware of the existence of IsOnTile or Blocked. Are these new functions?
-
I was able to get bluemonkmn's code "Against Tile" to work nicely, but am still not able to get the SnapToGround method working consistently. I have uploaded my project if you would like to check it out. The offset must be set at at least 12 before there is a result.
In the project the character will not jump unless the ground is detected using the rule called "OnLanding". You should be able to get it to fail when you turn and jump (while on the ground) simultaneously, but not every time.
Chris
-
I wasn't aware of the existence of IsOnTile or Blocked. Are these new functions?
They have been around for at least a few releases. I can't remember when I added them, so they're not very new. I do remember Durnurd pointing out some issue related to the Blocked function, but I can't remember if it was a problem with the way Blocked worked (meaning I needed a new function) or if it was a problem in another function that caused me to add this new "Blocked" function. But that was probably a year ago if not more.
-
I was able to get bluemonkmn's code "Against Tile" to work nicely, but am still not able to get the SnapToGround method working consistently. I have uploaded my project if you would like to check it out. The offset must be set at at least 12 before there is a result.
In the project the character will not jump unless the ground is detected using the rule called "OnLanding". You should be able to get it to fail when you turn and jump (while on the ground) simultaneously, but not every time.
Once again I'm reading the forums when I can't look at the project. Can you tell me exactly what you expect SnapToGround should be doing, and what it *is* doing (just based on your observations)? You're not expecting it to prevent you from jumping are you? That's not what it was designd for (although if you pick a significantly high threshhold, it probably could). What velocity are you using for jumping? What maximum velocity do you use for horizontal movement? Anything else I should know about your parameters related to movement in understanding how you expect SnapToGround to work?
-
Yikes, I really missed those functions. They could have been useful. Too bad for me! :P
-
In response to what I think SnapToGround does, I have made these conclusions based on my reading of the documentation and the forums, but I could be dead wrong.
It is a method that is implemented to bring the player sprite all the way to the "ground", which is defined as the solid tile(s) the player sprite lands on. It is declared with other methods such as ReactToSolid and must come immediately after react to solid.
There is a threshold for the SnapToGround method to activate defined in pixels. Once it detects that the player is close enough it alters the y velocity of the player to make sure it does not stop above or below the solid tile and will always reach the same y position relative to the tile.
The method can also be used as a test, since it returns true when it is activated. In my game the test occurs in a place where it must return true for the jump to be possible. Whether it is the SnapToGround method, or the other methods (I have used Blocked, and IsAgainstTile successfuly).
This exercise is merely academic, since the other two methods work without fail. I expect that the player should be "Snapping to the ground" each time it reaches the threshold. It should return true in my "OnLanding" test each time where I have implemented it as a test. It seems to be that most of the time it is doing that, but for reasons I don't understand, sometimes it does not. This makes it so the IsJumping parameter does not get reset and subsequently malfunctions preventing the player from jumping.
The inputs are the same. Press left, or right, and jump at the same time. Do this about 20 times and one of those times will probably result in a failure.
I also expect that the threshold would only need to be 1 pixel, but it requires 11 or 12 before it works. I am unsure of what it uses as a reference. I think would be the same thing the other methods use, but it something seems to be offsetting it. Perhaps there is something else wrong that I am not aware of.
As a precaution I did check the sprite's frameset. I thought maybe that had something to do with it. I found that all of them have a y offset of 5 except for a couple of frames. In the project you have been sent you'll see this inconsistency. I fixed that and it didn't fix the problem so it doesn't seem to be that.
-
OK, I may understand the confusion here. I didn't realize (remember) that the function could also be used as a test. If that is the part that is not working as you expect, then I think I can explain it. When used as a test, you may have noticed that the documented return value is "returns True if the sprite was snapped to the ground." I guess this may not be clear, but that doesn't necessarily mean that it will always return true when the player is touching the ground. It only returns true if the function had to do something to snap the player to the ground. There are cases (I would have expected more than you're reporting) when the player just hit the ground and ReactToSolid already adjusted the player so that it is hitting the ground so SnapToGround doesn't need to do anything else... then it would return false.
-
Sounds like a really bad strategy then. I'll stick with IsAgainstTile.
-
Does Blocked lack something?
-
I have extra options with isAgainstTile since I can specify tile categories and relative alignment. I think this could be useful if I were to, for instance, have some tiles on a level where jumping is prohibited. Chances are I will never do that, but I thought, what the heck. I got it working I might as well use it.