functionality of sgdk2

[billybob884]

Hey, i actually had a few questions as to what's in-store in terms of features for sgdk2.

the biggest question on my mind is this, will there be a way to make the player "hug" the ground (slopes) without having to pump up the gravity? like one of the most annoying things (for me, at least) in sgdk1 was that when u were walking down hill, u really couldn't jump, u had to stop walking before you could do so. i was hoping there would be some support for this in 2.0

another, albeit less important, question is, in sgdk you could make falling platforms, but if i remember right, it was tedious, and you had to setup the paths for each individual tile that would fall. will there be an easier way to do this and similarly repetitive things?

[bluemonkmn]

All that can be done in the alpha, I think.  If you look closely at the rules in the player sprite, I think you will find one called something like "Snap to Ground", which forces the player sprite to touch the ground if it's within 2 pixels of it (or however many pixels you specify in the parameter).  I hope this accomplishes the desired effect.  I suppose it depends on where that rule is relative to the jumping rules as to whether you will be able to jump while going downhill.  (If you snap to the ground first, and then check for jumping, it should work.)

Falling platforms should also be possible using logic similar to the floating scores that appear when you pick up a piece of fruit in the sample game (ie., when you pick up a cherry "100" floats up from it).  Notice that the fruit simply consists of tiles.  So if there's a way to make a "points" sprite float upward from a fruit tile when it disappears, surely there's a way to make a "falling platform" sprite float downward from a breaking bridge tile when it disappears.

If you investigate the rules on the sprites and plans, and look at the code in the source code folder, you might be surprised at how flexible SGDK2 games are compared to version 1.x games.  All the solidity handling is in customizable code now.  All the sprite movement is in customizable code too.  Every rule you see in the sprite definition editor and the plan editor represents a function defined in the source code folder that can easily be customized by changing the code, and it is saved with your project so you don't have to rely on the right version of the engine to have your rules up-to-date.  These "Rules" are kind of like special functions from 1.x, and the functions they call are kind of like the special function types (switch to map, etc), and the best part is now you can make up your own function types by adding a new function to the SpriteBase class or the PlanBase class, and it will look and work exactly like the default set of functions delivered with the basic installation.  And all that without requiring changes to SGDK2 itself.  You can even provide your own documentation for the function that will appear on the sprite definition screen when the function is selected.  So I hope to see some other interesting project templates that people will provide with lots of new and interesting rule types added.

[billybob884]

Ok, another question. i've poked around your demo a little, though not enough to say i have any semblance of a good understanding of it, so with that in mind, how heavily based upon actual scripting are games made with this engine going to be? because what ive realized i liked most about sgdk1 was that you really didnt have to have any programing knowledge to be able to make a game; once you understood the basic format of the special functions and tile interactions, you were good to go unless you wanted something complex.

as im sure you (or durnurd) remembers, i have virtually no scripting knowledge, so you can probably understand my concern. for example, you stated in a previous post (in this thread?) that not even the arrow keys are hard coded in. heh, i guess with the recent thought ive been giving to making a sequel, i'm just getting a little jumpy as to how complicated this may be.

[bluemonkmn]

The intention is that people still be able to make games without writing any code.  So tell me if you consider this simple enough to be similar to version 1's functions (that you say you like) and not similar to scripting -- change the key that is used to jump by following these steps:
1) Going to the Sprite Definitions folder
2) Opening the "Player" sprite
3) Go to the Rules tab
4) Expand "If Climbing"
5) Expand "Else (not climbing) if trying to climb up"
6) Expand "Else (not trying to climb) if standing on solid"
7) Select "And pressing button 1"
8) Drop down the list for the "Input" parameter
9) Select InputBits.Up to make the sprite jump when up is pressed instead of button 1.

All the rules on that sprite might scare you right now, like "I have to make all these rules every time I want to add a sprite!?" but don't worry.  First of all, the player sprite is much more complicated than the average sprite.  And second, you don't have to define these sprites from scratch if you don't want to.  The player sprite in that project, for example, was imported from the sprite library, and there will hopefully be many more sprites in the library in the final release so that every useful sprite type supported by version 1 will have an example sprite template that you can import to use as-is or build from.  The cool part is now you can make your own sprite types with whatever states and rules you want if you have an idea that doesn't match any of the delivered sprite types (assuming you aren't scared of the rule system, which is hopefully still quite a bit easier than coding/scripting).  Whereas version 1 was limited to "Single State", "Left/Right", "8-State" and "36-State" , now you can make up your own types, and many more types will be available in the library.

The hope is that the names of the rules (like "Else (not trying to climb) if standing on solid" and "And pressing button 1" are plain-English enough that someone who doesn't know how to code will be able to find the rules they want to fiddle with and make changes that might get them what they want.  The hope is that this rule system is about as simple as the special function system, but much more powerful.  Let me know how successful that was :).  Documentation might make a big difference here, so if you find anything particularly confusing here, let me know, and I'll try to remember when writing the documentation to make a note of it and go into more detail in that area.

[durnurd]

Oh, that reminds me, I think the indentation should be a bit more like programming in that tree, where you can see the ELSEs and the END IFs even if the IF isn't expanded (on the same level) so you know the general outline of the code, even if it's completely unexpanded.

[bluemonkmn]

Oh, that reminds me, I think the indentation should be a bit more like programming in that tree, where you can see the ELSEs and the END IFs even if the IF isn't expanded (on the same level) so you know the general outline of the code, even if it's completely unexpanded.

So did I, but that doesn't work out very cleanly, unfortunately.  It's weird to have a node that doesn't have any data... you click on it and what happens to the pane with all the data... just disabled?  A number of things get more complicated if I try to do that, unfortunately.  I suppose I could try again, but I was hoping people wouldn't mind the current structure in which every tree node maps to exactly one real rule... err... except for the Ends .

The current structure is just more straightforward internally because the "else" and everything in it are still subordinate to the whole condition statement.

[billybob884]

oh, well that doesnt sound too bad. im sure its just like anything else that'll take a little practice and maybe a tutorial to get used to. just at first seeing all the code u had written in the scripting folder got me a bit jittery

[durnurd]

All the code in the Source Code is there for customization, but it's all generated when you make any new project by default.

[billybob884]

how about sprite collisions in sgdk2? like the 2 main things i can think of is, say for example, you have an enemy with spikes on the top of it, and you only want it to hurt you if you touch the spikes on top. will you be able to do something like that? or again where it may be even a little more complex, like having a pillar slamming up and down from the ceiling, you want it to kill you if it comes down on you, but not if you run into the side.

[Jam0864]

What, sort of like hitpoints? That would be really cool.

[billybob884]

Yea basically, the only example I can think of off hand is in Mario when you have to jump on the little mushroom guys. I know that someone was able to do something like this in sgdk1, except that you had to have 2 separate sprites right next to each other and a bunch of special functions. It wasn't that hard, it was just annoying to do

Actually, another question (lol, I may as well just ask now). I've actually been brainstorming a little about how I would go about making another game.., and my question is this. How customizable will player sprites be? Because I've been thinking about how I'd like to be able to set it up.

The concept isn't too bad. It would basically be three 'states'; a 'normal' state, a 'hurt' state, and an 'invincible' state. The way I would like to do it is each state would have only a left/right for each 'position', a stading left/right, a walking left/right, a jumping left/right (a rising and falling for facing each way, so 4 total for this one), a crouching left/right, and a crawling left/right. The only catch is each position's tiles would be different in each of the three states.

I hope I'm not explaining this too poorly. Like, the normal state would look like all the original animations in my first game, but then the hurt ones would be flashing, and maybe like a color change for the invincible ones, or something. I don't think that I could have done this in sgdk1 because I would have had to have 5 sprites for each state, and there would be a problem with switching to the right state's position. How feasible does something like this sound? Would it be ridiculously hard to implement, or would it be doable?

[bluemonkmn]

how about sprite collisions in sgdk2? like the 2 main things i can think of is, say for example, you have an enemy with spikes on the top of it, and you only want it to hurt you if you touch the spikes on top. will you be able to do something like that?

There are three ways I can think of to deal with this in SGDK2, and the best is to create a sub-framed sprite.  Each sprite definition has a number of states, and each state has a number of animation frames.  Because you may want collisions to be handled differently depending on what the sprite currently looks like, each frame in each state has its own collision mask (based on which pixels of the frame are beyond a certain opacity level).  This achieves the same effect you got in version 1 with sprite collisions being based on non-transparent pixels overlapping.  SGDK2 goes a step farther when it allows each frame to be composed of sub-frames (frames whose delay is 0, meaning they get merged with the next frame).  You can set the collision mask for each sub-frame separately too.  So you could put the spikes in one sub-frame and set its mask to pixels with an alpha level of 127 or higher, then put the rest of the creature in another sub-frame and set its mask to empty (alpha greater than 255, which is impossible).

or again where it may be even a little more complex, like having a pillar slamming up and down from the ceiling, you want it to kill you if it comes down on you, but not if you run into the side.

This might be more challenging if you want collisions with different parts of the same sprite to be handled differently (one collision stops the player from moving farther into the pillar, and another hurts the player).  This one would probably require multiple sprites and the use of a function (already delivered in the default source code, I think) that sets the position of a sprite relative to the position of another sprite.

The concept isn't too bad. It would basically be three 'states'; a 'normal' state, a 'hurt' state, and an 'invincible' state. The way I would like to do it is each state would have only a left/right for each 'position', a stading left/right, a walking left/right, a jumping left/right (a rising and falling for facing each way, so 4 total for this one), a crouching left/right, and a crawling left/right. The only catch is each position's tiles would be different in each of the three states.

Invincible and hurt wouldn't necessarily need to be states.  They could be counters that affect the player's color.  That's relatively easy to do with a call to modulate a color channel on the sprite based on a counter value or a sprite parameter value (you can have a rule that, when the "hurt" parameter is 1, toggles another counter between 127 and 0, and sets the alpha channel to match in order to make the player flash translucently).  But if you want to use separate graphics for all those states, that's possible too.  It just gets a little more difficult to manage.  But there's no trick to it really.  It's all quite straightforward. You just create a state for each of the states you mentioned above, define the frames in the states, and then define the rules that determine when the player switches to those states in the Rules tab.  Defining the rules would probably be the most tedious part because you would have to, for example, define a separate rule for switching from left normal to left hurt and one for switching from right normal to right hurt if you want to really use separate states for normal and hurt.  Anyway, it's much more practical than it was in version 1.

[billybob884]

Invincible and hurt wouldn't necessarily need to be states.  They could be counters that affect the player's color.  That's relatively easy to do with a call to modulate a color channel on the sprite based on a counter value or a sprite parameter value (you can have a rule that, when the "hurt" parameter is 1, toggles another counter between 127 and 0, and sets the alpha channel to match in order to make the player flash translucently).

yes, either flashing transparency, or maybe flashing red. either way, thats exactly what i want for the 'hurt state'. the reason why i think the 'invincible state' will need its own sprite is because i will probably want it to be consistent with the first game, and in the invincible state, you were 'powered up', u ran faster, jumped higher, etc.

[durnurd]

Those could all be dealt with in counters as well.  Just have the jump height be a counter that's normally set to 10, when they're invincible, set it to 15 or something.  Same with speed.

[bluemonkmn]

One thing you may not have realized is that states are not tightly integrated with rules, so creating a new state in itself doesn't make the sprite behave according to a new set of rules.  Switching the sprite to a new state would only do that if you create the rules such that the sprite behaves differently when it's in that state.  You may have noticed that the states defined for a sprite don't have that much information associated with them.  And in fact that is the extent of a state.  All it has is the appearance of the sprite, the collision masks for that state, and the solid size of the sprite when it's in that state.  The rest is all rules.  So if you want the sprite to behave differently for some reason, that can all go into the rules. The only time you need to create a new state is if you want the solid size of the sprite to change, when you want it to collide differently, or when you want the sprite to look different in a way that can't be accomplished by modulating colors/alpha on an existing state.  Even changing the solidity definition that a sprite uses is done on the sprite instance with SetSolidity (or something similar -- can't remember exactly), and is not hard-wired to the state.