Harvest Moon Clone

[durnurd]

I understand the problem you're having with changing sprite states.  The simplest way to solve the problem is to find a pixel in the graphic of the state you're switching from and the state you're switching to that should be at the same location in both states.  In the graphic sheet editor, find the x and y differences between these pixels, and offset the graphic of the "to" frame in the frameset editor to be the correct amount to compensate.  This is the best way to ensure that switching states will not cause a jump.

[Tanja]

well, thanks.
this wasn't the exactly the problem i meant. normally i try to make all sprite graphics with the same canvas, so no jumping is possible. this may not make sense for all sprites, i guess.

okay, this leads me to the following question to bluemonk.
i do not understand, why shifting the collision rectangle and shifting the frame's position are the same thing. could you please explain the necessities?
i mean, if my sprite graphics have different sizes at different states, i understand why and how to offset the frames just like durnurd explained above.
but if my sprite is not at the upper left corner of its graphic, and i would need to shift the rectangle some pixels down und to the right, why have i to shift the whole frame?
i tried different frame sizes for my zeppelin some time ago. it jumped while it moved horribly to all sides, because i tried to find for every frame the best rectangle size and position, and shifted therefore the whole frames.

[durnurd]

I think part of it is just the fact that the collision rectangle starts at the x,y coordinate of where the sprite is and the width/height of the collision rectangle is the width/height of the sprite. Shifting the frame position simply offsets it from those x,y coordinates.

I've seen some games that store each and every graphic separately in its own equivalent of a graphic sheet, and group several graphic sheets of the same sprite together in something in between a graphic sheet and a frameset.  I suppose the problem there could be loading more graphics into memory, but it doesn't seem to be a problem with the games I've seen that do it (mostly RTS games).

[bluemonkmn]

i do not understand, why shifting the collision rectangle and shifting the frame's position are the same thing. could you please explain the necessities?

You mean why does the collision rectangle determine the location of the sprite when switching states?  The answer is, I saw no reason to make it different.  I had implemented a collision rectangle that determined where the "solid" edges of the sprite were, and when the question arose "When I change to a different state, how shall the new state be positioned?" the simple answer was "Use the collision rectangle, and allow the rule to specify which point in the collision rectangles should line up between the two states being switched."  I see no reason that this would be inadequate.  It makes sense, doesn't it?  If you have an image, and some portion of that image is considered "solid", and you want to switch to another image representing the same object, and it also has some portion that is considered solid, it makes sense that the solid part would be the part that doesn't move, right?  Just like the center of gravity in a real-world rotating object.

[Tanja]

hm well, i understand this way of thinking. i for myself think different. i always thought the two lined up points were choosen frome the entire frame, not from the solid part.
and after thinking about your way, i still believe this is not optimal. making the change between two states without jump is much easier by using the same frame size, than trying to find the right value for shifting the entire frame after switching states. you have to make much more rules for that, and if you some time decide to change your graphics size you have to work over all values.

but, what i want to say is this: you don't think about the possibility that a sprite changes its size several times within ONE state. what now? imagine a guy who is kneeing and standing up the whole time (with some room at the frame around him). try to make the collision rectangles for THAT.

all i want to suggest is, that i would make much more sense to give the user two simple input fields more: offset x for coll. rectangle, and offset y for coll. rectangle. in that preview window for example.

[bluemonkmn]

I think I still don't fully understand your point of view, but I don't want to give up until I do.

and after thinking about your way, i still believe this is not optimal. making the change between two states without jump is much easier by using the same frame size, than trying to find the right value for shifting the entire frame after switching states.

But the frame size is even more unpredictable than the solid size.  You can have all sorts of different frame sizes in the same state, and it would be extremely difficult to switch states without graphics jumping around uncontrollably if you had to worry about every frame size instead of just the state's size.  At least with the state's solidity size, you know that the sprite will always be a specific size when it's in that state, so when you switch to another state, you know the current size of the original state without having to check every frame.

you have to make much more rules for that, and if you some time decide to change your graphics size you have to work over all values.

If you change your graphic size, it's better to only have to fit it in with the state where it's used instead of having to worry about how that new size fits into every place where the state might change from that frame.  For example, assume I have a Left-facing frame that's used in my "Flying left" and "Super-speed Left" states for "Enemy Follow Path" sprite, and the same two states for a "Enemy Follow Player" sprite.  I offset the frame a couple pixels because I know that wherever it's used, there are a couple pixels that don't really represent the "solid" part of this image.  Then I change the size and I have to offset the frame a couple more pixels.  I only have to do that once for the frame.  If there were an offset for each state, I would have to go to each state where the frame was used and change the offset (I would have to change it 4 places instead of 1).  I might also have to go to every rule that changes states and looks at all the frames to take the new frame size into account when switching states.  By this test, I think the existing solution is much easier because you only have to change the offset once instead of 4 times, and you don't have to worry about all the rules that would manually handle the offset.  (So I think I'm not understanding you.)

but, what i want to say is this: you don't think about the possibility that a sprite changes its size several times within ONE state.

That's not possible -- one state always has the same size.  One of the purposes of a state is for grouping frames with the same solidity size.  For example, walking and crawling would be different states.  All the walking frames should be the same size as each other, and all the crawling frames should be the same size as each other.  Crawling frames would be shorter than walking frames, but you shouldn't be changing the size of the sprite just as part of the animation, otherwise simply animating the sprite could cause it to need to move in reaction to solidity.

imagine a guy who is kneeing and standing up the whole time (with some room at the frame around him). try to make the collision rectangles for THAT.

I don't understand.  Kneeling should be a different state than standing.  And if the solidity rectangle for those two states are set up correctly, it's easy to switch between them, and the frames will be easily positioned properly by aligning the bottoms of the solidity rectangles when switching states.

all i want to suggest is, that i would make much more sense to give the user two simple input fields more: offset x for coll. rectangle, and offset y for coll. rectangle. in that preview window for example.

I don't see how more input fields would simplify things.  More values would make it more complicated, not simpler.  Can you provide another example maybe?

[durnurd]

I have an idea for some sort of improvement:  You can pop up a window that allows you to preview a switch between states using all the different matching points (top-left, top-middle, etc.), and you can then zoom in really close (if you want to) and offset one of the state's frames while flipping back and forth until it looks good to you, and it will automatically update the all the frames that state uses in the frameset.  If not actually changing it, then previewing what it will look like before the game actually runs would be nice.

[Tanja]

good idea, durnurd.

i must confess i talked a lot without proving my sayings. the whole time i thought one could could set different sized collision rectangles for every frame of a state.
i think we talked about different things. sorry.

i made this picture. it shows what i wanted to talk about, and what i thought would be possible. this is my zeppelin, and you can clearly see the collision with solid tiles isn't working so fine. what size should i make it? okay, it is no question of life and death. it matters not much to my game, but it's a example.
i would like to change the size of the collision rectangle for each frame.

what about that? you have an algorhtym which determines what pixel is considered solid (for the mask). what about an algorhytm that looks after the four corner points of a sprite and sets the rectangle automatically?

[bluemonkmn]

Since a state can only be one size, I'm confused by your picture.  Do you want 4 separate states?  It seems odd that you would fly a zeppelin around a map while it's facing the player.  I think that is just part of an animation of the zeppelin turning around.  If that's the case, I would implement it all with one size (in one state) because the player wouldn't really be moving while the zeppelin is turning and it's much simpler to just keep the same size for all the frames/states so it doesn't jump around while changing.  I don't see why you would need the solidity size to change.  It should just stay the same as the graphics size (assuming all the graphics are in one graphic sheet so some frames have empty space around them).

[Tanja]

i don't want to have an endless discussion. maybe i've chosen bad examples, but this is what they are: just examples.
of course you are right in your thoughts about the zeppelin. but i would have found this option useful, even when it doesn't turn the gameplay around.

My philosophy is don't prevent the user from doing things that work... because I never know when some odd setting might be useful.  Someone's game could maybe take advantage of a negative scroll rate even if I can't imagine how it would be used.  So I don't think I should make up arbitrary rules just because I don't think some setting is useful.  I should leave it open for the user to decide what they want.

we could end the discussion now and wait for the future. maybe someone will have a stunning game idea and will only need this feature to realize it. maybe this will be never the case. we'll see.

[durnurd]

I think the difference between his quote and what you're trying to get across is that he's simply arguing that there's no reason to not accept values outside the "expected" range if it doesn't cause the program to crash.  What you're asking for is a change to the design to create new functionality.