Scrolling Game Development Kit Forum
SGDK Version 2 => Help, Errors, FAQ => Topic started by: Joe on 2008-03-06, 07:23:02 PM
-
First: It is cool. Don't get me wrong... Its just not very easy for newcomers. Let me explain
Well, first, it is for making Scolling Games... the first tut only tells you how to make some flying triangle game... and it only scrolls left and right. What if I want to go up? Thats easy enough to figure out... but what if I don't want a flying triangle? What if I want... I don't know, a scrolling game like Mario or Knytt or Earthworm Jim or something... you know... kind of like what I think when I think of scrolling games. You know, a platformer.
Shouldn't there be a tutorial on how to make a platforming game? I know I can import sprites, but when i try to import the SHFL character I always get errors about platforms definitons and such... Well, I don't want platforms anyway... but I do want to jump around. but I can't see how. The closest I could come was, well, what I thought was right ended up being not able to control the character.
There should be a way to make a simple platforming game - left-right player & floor. Then the next step should explain an item and inventory. The next step should explain enemies... like simple walking back and forth on the ground enemies. They hurt you and take away health.
I just think its a bit overwhelming to be dumped in a blank environment like SGDK on startup and be asked to make a decent platformer, or even a simple one, for that matter.
Sorry if I'm coming across as a bit rough, but this is from a person who hasn't used it before and i thought I should mention it just so other people dont just give up, you know... so yeah... a bit of that stuff would be nice.
-
Yes, I had to severely limit the number of tutorials I wrote because I'm only one person and can't do so much in such a limited time. If I had tried to write all the tutorials you're talking about before releasing it, nobody would probably get to use SGDK2 until next year. But yes, I realize there's lots of room for expanding the documentation. The good news is, all the people who say that SGDK2 looks really complicated to start with and almost give up... they end up saying that it's much easier than they expected (if I recall correctly... any of those people care to comment?). I have already written and released a couple of the most critical tutorials that were requested but not included. But it all takes time, and there are trade offs. If I'm working on documentation, then I'm not working on features, so everyone has to decide what's more important. The intention was that the sample project could take the place of a number of tutorials. It's much easier to create a project that demonstrates how to do all sorts of things than it is to write book-fulls of documentation describing how it was done (and probably easier to read that way too). So hopefully if nothing else, you can use the sample game as a source of information until more tutorials come along.
Currently I'm working on upgrading SGDK2 to OpenGL because I hope that it will allow SGDK2 to run on more video cards and maybe even run faster (some things were simplified), but most importantly, it will bring SGDK2 one step closer to being portable to other platforms. Other open source developers will also see SGDK2 in a better light if it's based on OpenGL, and I might actually get some help around here so that we can have two or more people working on features and/or documentation instead of one. Although I do have to give durnurd credit... he has written some great video tutorials based on the written tutorials.
-
I didn't want to make it sound critical, but just voice my surprise at what is given to begin with
It seems strange to me that the sample project is a platformer but the tutorial is a flying triangle game. Or that it has a rotating sprite wizard but not a left-right sprite wizard... or even instructions to make a left-right sprite. I figured that would be the main focus of the Kit and judging by what I see of sgdk1 projects, its what the thing was used for...
[edit] I suppose what it boils down to is, I just want to make a normal game, you know? I know how to make walls and pick-up items, but I don't know how to make a character that runs on the ground and jumps. As a newcomer, I would like to know.
-
for that problem with the platforms: just create a new Tile Category which is called exactly like the error message says.
for the left/right sprite: create a new sprite definition. look at the "player" sprite within the sample game. you will see how it is with states and rules. if you don't need a climbing sprite, you can use only a few rules out of that "if climbing" tree. you can copy the rules and insert them into your own sprite.
-
I didn't want to make it sound critical, but just voice my surprise at what is given to begin with
Well, then , let me see if I can explain, because I think there are good reasons behind most of those decisions:
It seems strange to me that the sample project is a platformer but the tutorial is a flying triangle game.
The tutorial project is much simpler than the sample project because it's designed around the idea of creating a game from scratch rather than creating a typical game. The intention is to get familiar with all the aspects of SGDK2, not to create a game the way you normally would create a game (if you want to do that, see the tutorial about importing sprites). If I were to create a tutorial that designs a platformer from scratch, it would be pages longer than this tutorial, which is already hard to follow. If what you really want to do is create a platformer, I suggest looking at the sample game, now that you have a basic understanding of all the concepts in SGDK2 from going through the triangle game tutorial.
Or that it has a rotating sprite wizard but not a left-right sprite wizard... or even instructions to make a left-right sprite.
The only reason the rotating sprite wizard exists is because it's very hard to create 360 perfectly rotated states manually. If all you want is a left-right sprite, you can easily import one of those and modify it to your liking, deleting the rules you don't care about. But a rotating sprite can be based on 360 states, 180 states, 72 states, 36 states... whatever... I didn't want to create separate templates for all those. I'm just trying address the most critical usability issues first, and having to manually create rotating sprites would be a serious usability problem without this wizard (more so than left-right sprites at least).
I figured that would be the main focus of the Kit and judging by what I see of sgdk1 projects, its what the thing was used for...
Yes, I too believe that left-right sprites will be the most common type of sprite in SGDK2. That's why most of the available sprite templates are for left-right type sprites.
I suppose what it boils down to is, I just want to make a normal game, you know? I know how to make walls and pick-up items, but I don't know how to make a character that runs on the ground and jumps. As a newcomer, I would like to know.
You were on the right track by importing a player sprite. You just need to make a few adjustments after you import the sprite (and I need to document them):
1) Either add a Ladder tile category to your project, or disable all rules that refer to the Ladder tile category in the Player sprite's rules.
2) Either add a Platform sprite category to your project or disable all rules that refer to Platrofm sprite category in the Player sprite's rules.
3) Adjust the graphics associated with the player sprite if you want it to look different.
Hopefully the error messages that you get when you try to run or build the project guide you in the right direction at least. But as I said, I do need to document that part better. Durnurd has suggested a feature that allows more thorough documentation of sprite templates so that people importing them know how to use them better, and I agree. Anyway, I hope this helps and is enough to get you moving along on your project.
-
Alright, so I tried... I really did... I found gravity and took the "if moving left" rules from SHFL... I've tried as hard as I can...
I renamed the triangle's Norm0 to Right and picked one where the triangle points left and renamed it Left. That makes the "if moving left" and "if moving right" rules from SHFL work... I think.
At first I added the gravity rule. The triangle sat on the floor and didnt move. That meant gravity worked... so to get it to move, I added the jump rule. Jump it did. I'm not sure how well, as it just hit the roof (not far away) but that seemed to be OK. The sprite didn't rotate or move left/right anymore, so I put in the two rules mentioned above, "if moving left" and "if moving right" thinking that would work, but I go press F5 and look:
tuttuttut\Sprites\Player.cs(202,15) : error CS1502: The best overloaded method match for 'SpriteBase.IsMoving(SpriteBase.Direction)' has some invalid arguments
tuttuttut\Sprites\Player.cs(202,29) : error CS1503: Argument '1': cannot convert from 'SpriteBase.InputBits' to 'SpriteBase.Direction'
I'm so close, I can feel it... please my friends, help a fellow SGDKer out ! ! !
-
do you have already PolarAcceleration active? take this: AccelarateByInputs
the error message is somehow saying that it was getting something like "Key A is pressed" instead of "go left"... somehow.
-
Did you review the rule that had the error. The error is saying that you have at least one rule that is calling the "IsMoving" function. Have you checked all the rules in your sprite that use the IsMoving function? One of them apparently has a parameter specified that was not valid. Did you paste something in that was not from the drop-down list for the first parameter? That would cause this kind of error. If you can't see the problem, show us what all your IsMoving rules look like.
-
Keep in mind I am using the tutorial project and have simply renamed the states Norm0 to Right and Norm60 to Left, just i case you were wondering...
if moving left: if IsMoving SpriteBase.Direction.Left
and facing right: and IsInState (int)Sprites.Player.State.Right (int)Sprites.Player.State.Right
then face left: Do SwitchToState (int)Sprites.Player.State.Left RelativePosition.CenterMiddle
if moving right: if IsMoving SpriteBase.Direction.Right
and facing left: and IsInState (int)Sprites.Player.State.Left (int)Sprites.Player.State.Left
then face right: Do SwitchToState (int)Sprites.Player.State.Left RelativePosition.CenterMiddle
As I was typing I realised the last bit of "then face right" should have "State.Right" in it. So I changed it, hoping that would fix the problem, but the same error came up.
-
Well, that's obviously not the problem then. The problem lies elsewhere, then. Could you open the file Player.cs, and look around line 202 (in notepad just hit CTRL+G to go to a line) and see the comment directly above that line, which is the name of that rule. Look in that rule and see if there's a problem. If you don't notice anything, post line 202 plus a few lines on either side (5 or 10) and I might be able to see the problem.
One other thing I thought of is to select the "Delete all output files" option from the File menu. I doubt that would help, but if nothing still looks wrong, then that may fix it,
-
Line 202: /// <item><term>O</term><description><see cref="key_button2"/></description></item>
/// <item><term>Numeric Keypad 7</term><description><see cref="key_button4"/></description></item>
/// </list>
/// Default set number 3 is mapped as follows:
/// <list type="table">
/// <listheader><term>Key</term><description>Mapped to</description></listheader>
/// <item><term>I</term><description><see cref="key_up"/></description></item>
/// <item><term>J</term><description><see cref="key_left"/></description></item>
/// <item><term>L</term><description><see cref="key_right"/></description></item>
/// <item><term>K</term><description><see cref="key_down"/></description></item>
/// <item><term>U</term><description><see cref="key_button1"/></description></item>
/// <item><term>O</term><description><see cref="key_button2"/></description></item>
/// <item><term>M</term><description><see cref="key_button3"/></description></item>
/// <item><term>,</term><description><see cref="key_button4"/></description></item>
/// </list>
/// </param>
public KeyboardPlayer(int defaultSet)
{
switch(defaultSet)
{
case 0:
InitializeKeys(
I don't think I'm doing this right... should it always be this hard?
-
once you know how to do it, it becomes easy. Just takes a while to get used to. :D
-
You looked in the wrong file. You need to look in the file specified by the error. Specifically, tuttuttut\Sprites\Player.cs(202,15). That is, find your SGDK2 file, go in to the tuttuttut directory, then into the Sprites directory, and open the Player.cs file.
-
Line 202: if ((this.IsMoving(SpriteBase.InputBits.Right) && this.IsInState((int)Sprites.Player.State.Left, (int)Sprites.Player.State.Left)))
protected override void ExecuteRules()
{
// if moving left
if ((this.IsMoving(SpriteBase.Direction.Left) && this.IsInState((int)Sprites.Player.State.Right, (int)Sprites.Player.State.Right)))
{
// then face left
this.SwitchToState((int)Sprites.Player.State.Left, RelativePosition.CenterMiddle);
}
// if moving right
if ((this.IsMoving(SpriteBase.InputBits.Right) && this.IsInState((int)Sprites.Player.State.Left, (int)Sprites.Player.State.Left)))
{
// then face right
this.SwitchToState((int)Sprites.Player.State.Left, RelativePosition.CenterMiddle);
}
// if player is pressing up
if (this.IsInputPressed(SpriteBase.InputBits.Up, false))
{
// accellerate
dy = -10;
}
// Rule 1
this.AlterYVelocity(0.1);
// react to solidity
-
Line 202: if ((this.IsMoving(SpriteBase.InputBits.Right) && this.IsInState((int)Sprites.Player.State.Left, (int)Sprites.Player.State.Left)))
wasn't there supposed to be a direction instead of an input?
-
Indeed. The Player Sprite's third rule (Second in the collapsed list) is wrong. Tanja is exactly correct.
-
THANKYOU EVERYONE
Now just so everyone knows, these are the rules you need to make a left/right sprite that jumps, like Mario, etc.
Firstly you need two states, a left and a right state. If you rename Norm0 in the template you made to Right, then choose another state where it points left, rename that Left.
To make the sprite stick to the ground instead of being able to fly, add gravity. This is a rule named Gravity. Select "Do" and "AlterYVelocity" and add ".4" into the delta box. You'll also need three rules called "if moving left", "if moving right" and "if pressing up". I'll go through these one at a time, as they all have subrules which you'll need to add.
Make a rule called "if moving left" and select "if" and "IsInputPressed". Then from the Input box, select "SpriteBase.InputBits.Left" and set Initial Only to "false". If it was true, you would only be able to move one "step" at a time, setting it to false means if you hold down the key, the player will move along until you let go of the button.
This rule is a part of "if moving left" so make sure it is nested. Make this rule "and facing right" then select "and" and "IsInState". In First State, select "(int)Sprites.Player.State.Right" and the same for Last State.
This third rule is also part of "if moving left" and is the last one to be included there. Make a new rule called "then face left" select "do" and "SwitchToState". In the State box, select "(int)Sprites.Player.State.Left" and in Alignment select "RelativePosition.CenterMiddle" and tick the box "end if/while". What we've just done is told the player to move left when we press left. The second rule checks if it is facing right and the third turns the sprite to face left before walking.
In order to move right, we do the same things except replace Left and Right and vice verca in all the rules. Here is what to do anyway, incase you need it.
Make a new rule called "if moving right" and select "if" and "IsInputPressed". From Input select "SpriteBase.InputBits.Right" and InitialOnly is "false".
Create a new rule (a sub-rule of "if moving right") and name it "and facing left" then select "and" and "IsInState". From both FirstState and LastState, select "(int)Sprites.Player.State.Left".
Create a new rule (a sub-rule of "if moving right") and name it "then face right" and select "Do" and "SwitchToState". From State select "(int)Sprites.Player.State.Right" and from Alignment, "RelaticePosition.CenterMiddle".
In your inertia rule you'll need "do" and "reactToInertia" selected. From RetainPercentVertical, type 100. From RetainPercentHorizontal, type 80.
If this isn't going right, I have two extra rules which I'm not sure what they do (can someone help?). One is called "Rule 1" and has "Do" and "AlterYVelocity" selected. In delta, it has "0.1"
The other rule is named "Rule 3" which has "do" and "AccellerateByInputs" selected. In Accelleration, have "10". Then in Max have "5" and in HorizontalOnly, select "true".
This should result in having a left-right jumping sprite.
If anyone out there wants to follow the first tutorial, then inserting these rules, please do so we can clean up the explanations and sticky this somewhere. I'm certain other people will want to know.
Cheers.
[edit] There is an error in there somewhere which allows you to jump infinitely high if you press up over and over again in quick succession. After figuring all that out, I'm a little fatigued so I'm taking a break. If anyone else can spot the error (or can think of a quick solution) please go ahead and do so.
-
Isn't it easier to just import the player sprite and delete what you don't need?
-
Instead of making a game, wouldn't it be easier to open SHFL and just look at it?
Importing the player sprite might be easier, but its not a way to do it yourself. When I first imported it, I got so many errors I wanted to cry. So with tweaking and attempts and such, the above is what I came up with for a barebones typical player sprite. Note that most/all of the rules are based on the blob in SHFL... but this tells someone what they do need to get some basic play going on.
You can say delete what you don't need, but for someone who doesn't know what they don't need, thats a scary task... "What if I mess up" "what if i delete the wrong thing?" "how do i know what this one does anyway" were typical things that I thought of while attempting to go at it. Usually this was followed by "Why isn't it easier?" "Why doesn't someone just tell me how to do it?" The only thing that kept me going was the idea that someone else would be in my position and would want to know. ie, guy doesn't know SGDK and wants to make a jumping sprite but doesn't know how.
The above says how, hopefully in a fairly followable manner.
-
Good point. Thanks for providing the info from a newcomer's perspective. If I had tried to write it, it would have been pages and pages long because I wouldn't know which details were important to explain, so I would have tried to include everything, and then it would have been too long for anyone to follow. I hope you find the effort of learning this worthwhile and that things are getting easier as you go along.
To attempt to address your unanswered questions:
1) Rule 1: I don't know why there would be another AlterYVelocity in addition to the .4 one you already have for gravity. Maybe you kept one from the tutorial and one from teh sample project? You only need one.
2) Rule 3: AccelerateByInputs allows the sprite to move in response to the inputs being applied to the sprite. For example, if the player is pressing Left, and the player's input is mapped to this sprite, then AccelerateByInputs will cause the sprite to accelerate 1 pixel per frame per frame if you pass 10 tenths-of-a-pixel as the first parameter. (You know how to find out all the details about what all these functions do right?)
3) Jumping: Did you take a close look at the player sprite in creating the rules for jumping? The important parts are a) If Blocked(Down) or IsRidingOnPlatform (to make sure they can't jump in the middle of the air) then set the y velocity (dy) to a negative number like -10 (using the "=" function).
-
As I become more versed in the ways of making a simple game, I'll post back about how to do simple stuff, which hopefully will be along the same lines as what another person in the same situation would be attempting things.
Still not sure about what those two "extra" rules up there do, and how to get the jump to only work from the ground (pressing up three times allows you to jump in the sky three times as high as I'd like) but apart from that, following the tutorial then those steps will get you somewhere.
[edit] "Rule 3" up there is apparently very important. It allows the player to move left and right. I think it tells you how fast you can go sideways. Without it, you won't be going anywhere.
-
to stop the played jumping again in mid air, make a rule
if - is blocked - direction, down
then do all the jumping stuff here
-
I can't change that back there :(
Here is updated code: THANKYOU EVERYONE
Now just so everyone knows, these are the rules you need to make a left/right sprite that jumps, like Mario, etc.
Firstly you need two states, a left and a right state. If you rename Norm0 in the template you made to Right, then choose another state where it points left, rename that Left.
To make the sprite stick to the ground instead of being able to fly, add gravity. This is a rule named Gravity. Select "Do" and "AlterYVelocity" and add ".4" into the delta box. You'll also need three rules called "if moving left", "if moving right" and "if pressing up". I'll go through these one at a time, as they all have subrules which you'll need to add.
Make a rule called "if moving left" and select "if" and "IsInputPressed". Then from the Input box, select "SpriteBase.InputBits.Left" and set Initial Only to "false". If it was true, you would only be able to move one "step" at a time, setting it to false means if you hold down the key, the player will move along until you let go of the button.
This rule is a part of "if moving left" so make sure it is nested. Name this rule "and facing right" then select "and" and "IsInState". In First State, select "(int)Sprites.Player.State.Right" and the same for Last State.
This third rule is also part of "if moving left" and is the last one to be included there. Make a new rule called "then face left" select "do" and "SwitchToState". In the State box, select "(int)Sprites.Player.State.Left" and in Alignment select "RelativePosition.CenterMiddle" and tick the box "end if/while". What we've just done is told the player to move left when we press left. The second rule checks if it is facing right and the third turns the sprite to face left before walking.
In order to move right, we do the same things except replace Left and Right and vice verca in all the rules. Here is what to do anyway, incase you need it.
Make a new rule called "if moving right" and select "if" and "IsInputPressed". From Input select "SpriteBase.InputBits.Right" and InitialOnly is "false".
Create a new rule (a sub-rule of "if moving right") and name it "and facing left" then select "and" and "IsInState". From both FirstState and LastState, select "(int)Sprites.Player.State.Left".
Create a new rule (a sub-rule of "if moving right") and name it "then face right" and select "Do" and "SwitchToState". From State select "(int)Sprites.Player.State.Right" and from Alignment, "RelaticePosition.CenterMiddle". Tick the End If/While box.
Create a new rule called "if pressing up" you can also call this "jump" or something more descriptive. Select "if" and "IsInputPressed" then in Input select "SpriteBase.InputBits.Up" and in InitialOnly, select "true".
Add another rule (this is a subsection of the "pressing up" rule) call this "on ground" or something. select "And" and "Blocked". In the direction, select "SpriteBase.Direction.Down". This checks if you can't move down (because you're on the ground) and allows you to jump. If you're in the air, you can move down, and thus won't be allowed to jump.
Add another rule (this is also a subsection of the "pressing up" rule) call this "accellerate" or whatever you like. Select "Do" and "=" (that's the equal sign, just one, not two of them with no other text) and in Value, select "-10" (thats minus ten) and in Output To: select "dy" and tick the end if/while box
In your inertia rule you'll need "do" and "reactToInertia" selected. From RetainPercentVertical, type 100. From RetainPercentHorizontal, type 80.
There is another rule, it can be named "Walk" which has "do" and "AccellerateByInputs" selected. In Accelleration, have "10". Then in Max have "5" and in HorizontalOnly, select "true". This tells the sprite how fast to move when you press any of the buttons.
This should result in a left/right jumping sprite.
If it doesn't work, I have an extra rule which I'm not sure what it doed (can someone help?). One is called "Rule 1" and has "Do" and "AlterYVelocity" selected. In delta, it has "0.1"
This should definately result in having a left-right jumping sprite.
If anyone out there wants to follow the first tutorial, then inserting these rules, please do so we can clean up the explanations and sticky this somewhere. I'm certain other people will want to know.
Cheers.
[edit] There is an error in there somewhere which allows you to jump infinitely high if you press up over and over again in quick succession. After figuring all that out, I'm a little fatigued so I'm taking a break. If anyone else can spot the error (or can think of a quick solution) please go ahead and do so.
[edit] In the first run, I forgot to add the jump information here. Thanks to Jam0864 for suggesting a fix anyway and allowing progess to be made. You can now jump only when on the ground.
Note: In the second rule of "if pressing up", if you select select "And" and "TouchTiles". Then in the category, select "TileCategoryName.Solid", you should be able to climb walls by walking up to them and pressing up, repeatedly.
-
Let me explain AccelerateByInputs a bit more clearly. This is the main rule that tells the sprite to accelerate in response to the inputs being pressed. You wouldn't have to make the sprite move; you could make it turn instead (like a rotating sprite does). AccelerateByInputs affects the dx and dy (horizontal and vertical velocity) of the sprite based on the inputs that are being pressed. Yes, it also determines how much the inputs affect the acceleration (how fast it goes), but it is also the primary reason the sprite responds to inputs. Another thing that is responsible for sprite movement that I don't see mentioned is MoveByVelocity. Here are the main functions involved in movement:
1) MapPlayerToInputs - associates (copies) a player's inputs to those of a sprite.
2) AccelerateByInputs - associates the inputs of a sprite with it's velocity directly (left = accelerate left, right = accelerate right)
3) MoveByVelocity - causes the sprite to actually move in response to its current velocity setting. This is separate from acceleration so you have an opportunity to ReactToSolid after accelerating, but before moving.
-
it is very good that joe is showing us how difficult the beginning is for a newbie. it is even more cooler that he took the time to write this tut. i hope it will go into the help files soon.