Neo Sprite

[j]

Hey guys, I'm new to the new GMG, but I was around the old one way back when (dunno if GameSifter rings any bells here). Anyway, less talk, more code.

With the more recent additions (recent for me anyway) to GM's sprite capabilities and keydown, I've set out to create a new GM system for handling sprite movement. As a side goal to this, I'm hoping it'll emphasize some of the more subtle tweaks Al can make to GM scripting in time for 4.0.

The name of the system will be Neo Sprite. Unoriginal, sure, but relevant imo.

From here on out, you can always download the latest build here:

http://www.jadaco.net/neosprite.zip

Documentation is in the form of commented scripts within the GM source file. Right now it's at the "okay, well it works" stage. There are some optimizations still left to do (though I have made more than a few passes at that already) and I know I'm probably overlooking some redundant code. Hopefully it'll be a learning experience for some people as it is already.

Give it a look, tell me what you think, and I'd love to get any feedback on how to improve it and expand it.

[Silverwind]

I'm downloading it now. What exactly is it? Code that makes sprite movement smoother?

EDIT:

Looks great! It'd be perfect for a side scroller. I don't really understand what the problem with changing cards is though. Can't you just put something like "IF playerXYlocation = suchAndSuch THEN GOTOCARD whatever" after each movement routine?

[j]

The problem is with multiple collision boxes. The movement code alone (with only one primary bounding box to keep you from walking off the card) is over 100 lines due to the extra code for animation. With the GM scripting limit of 500 lines, this doesn't leave much room for additional collision (which will be unique for every card), not to mention plot scripting (dialogue, cutscene movement).

I think it's a good start, but so far it declares a need for two things:

1. A more efficient, less extensive way to check collision (which I think is possible). Ideally a way to leave keydown code in card 1 and reference collision variables that are set to each card's unique collision map.

2. The ability to animate sprites in some way (animated GIF, for example), which reduce the current code quite a bit overall.

As for a side scroller, I don't know how well this would work. I suppose it wouldn't be too tough to add in a scrolling background and use SPRITECOLLIDE for obstacles. Still, check out the jump code in card 1 and you'll see that I mention it being little buggy (and you'll see what I mean). I think GM's overall style lends itself more to the overhead adventure game or RPG (Zelda, Final Fantasy) where sprite elements are minimal.

[Tireas Dragon]

It is possible to make it less.
z = 0
REPEAT 3
z = z + 1
IF z = 1 THEN SPRITE 1 x y Shadow:player_left2.gif
IF z = 2 THEN SPRITEPATH 1 x y 10
IF z = 2 THEN SPRITE 1 x y Shadow:player_left1.gif
IF z = 3 THEN SPRITEPATH 1 x y 10
IF z = 3 THEN SPRITE 1 x y Shadow:player_left3.gif
    X = X - 10
    IF X < left THEN X = left
END REPEAT
SPRITEPATH 1 x y 10
SPRITE 1 x y Shadow:player_left1.gif

Get it? It allows you to do all your collision one time and save 100's of lines of code assuming you are making lots of boundries.

[Silverwind]

Just to clarify something: What you're trying to accomplish is merely a smooth animated walk sequence right? I don't see why V6 couldn't do that after a little tinkering with the code. I believe Gan already made a working demo of a smooth walk sequence in a nav similar to V6 awhile ago, and I think it had collision.

The problem is with multiple collision boxes. The movement code alone (with only one primary bounding box to keep you from walking off the card) is over 100 lines due to the extra code for animation.

What? How is that possible? All you're doing is moving a sprite a few pixels in a specified direction, changing sprite pics, and repeating the process half a dozen times. The code should be somewhat like this:

Code: [Select]

walkframe = 0

REPEAT 4
 Â walkframe = walkframe + 1
 Â IF walkframe = 4 THEN walkframe = 1

 Â IF direction$ = "up" THEN
 Â   playerY = playerY - 10
 Â   IF walkframe = 1 THEN playersprite$ = "up1.gif"
 Â   IF walkframe = 2 THEN playersprite$ = "up2.gif"
 Â   IF walkframe = 3 THEN playersprite$ = "up3.gif"
 Â END IF
 Â IF direction$ = "down" THEN
 Â   playerY = playerY + 10
 Â   IF walkframe = 1 THEN playersprite$ = "down1.gif"
 Â   IF walkframe = 2 THEN playersprite$ = "down2.gif"
 Â   IF walkframe = 3 THEN playersprite$ = "down3.gif"
 Â END IF
 Â IF direction$ = "left" THEN
 Â   playerX = playerX - 10
 Â   IF walkframe = 1 THEN playersprite$ = "left1.gif"
 Â   IF walkframe = 2 THEN playersprite$ = "left2.gif"
 Â   IF walkframe = 3 THEN playersprite$ = "left3.gif"
 Â END IF
 Â IF direction$ = "right" THEN
 Â   playerX = playerX + 10
 Â   IF walkframe = 1 THEN playersprite$ = "right1.gif"
 Â   IF walkframe = 2 THEN playersprite$ = "right2.gif"
 Â   IF walkframe = 3 THEN playersprite$ = "right3.gif"
 Â END IF

 Â SPRITE 1 playerX playerY $playersprite$$
END REPEAT

Something like that would slip into the V6 collision engine easily.

I think it's a good start, but so far it declares a need for two things:

1. A more efficient, less extensive way to check collision (which I think is possible). Ideally a way to leave keydown code in card 1 and reference collision variables that are set to each card's unique collision map.

2. The ability to animate sprites in some way (animated GIF, for example), which reduce the current code quite a bit overall.

Animated gifs would certainly be helpful.

I think GM's overall style lends itself more to the overhead adventure game or RPG (Zelda, Final Fantasy) where sprite elements are minimal.

I agree.

EDIT:

Ah, TD beat me to it with another simple explanation.

[Tireas Dragon]

Thats what I said at a larger scale. I only did 1 direction.

[GMG Tim]

Hi Jadaco, nice to see you here! I'm Ghost from the ezboard/GMG days. It's cool to see other old GMers out here on this forum

Ghost

[j]

Okay, cool, thanks for the awesome responses. After checking out V6, I think I'm gonna try and modify Neo Sprite to use the gridlayout$ system. I've been looking for a way to store unique card collision within each card (instead of inside the keydown command). I'll give that a whirl.

[EqwanoX]

hey jadaco whats up. yea the system you posted is way outdated dude, you need to have a grid to locate things. but other than the navagation technique animateing the character is pretty simple

the nav system in gandolfs game is based on sprite collision . i developed it a few years ago

http://www.silvercreator.net/cgi-bin/yabb/YaBB.pl?board=sccode;action=display;num=1164845614

[alias]

I think animated sprites are the key here. It would save the need for a "moveframe" variable or REPEAT steps, thats how it was done in Zelda i believe (but not using a gif file obviously).

Also, if your not using many sprites, you could use the SPRITECOLIDE command to detect collisions with boundaries etc. Or just have a mini invisible grid.

[j]

I think animated sprites are the key here. It would save the need for a "moveframe" variable or REPEAT steps, thats how it was done in Zelda i believe (but not using a gif file obviously).

Right. That's the idea.

Also, if your not using many sprites, you could use the SPRITECOLIDE command to detect collisions with boundaries etc. Or just have a mini invisible grid.

SPRITECOLLIDE doesn't interest me so much because of all the broken up external resources you'd have to deal with, plus the fact that GM would have to draw the sprites each time you load a card, giving you a slight glimpse of an otherwise blank card before all the collision details get filled in. Yeah, I'm picky about small things, I know.

Still, this is all theory, I haven't actually sat back down to apply anything and I'm probably pretty bad at trying to visualize code (I know I'm bad at doing math in my head).

Also, it would be nice if all these sprite engines and modifications (like V6 and the animated variant) had a common and prominent place they could be posted for download. I haven't been to these boards until recently and part of the reason I set out to make this is because I didn't think there was something in its place.

[Silverwind]

Also, it would be nice if all these sprite engines and modifications (like V6 and the animated variant) had a common and prominent place they could be posted for download. I haven't been to these boards until recently and part of the reason I set out to make this is because I didn't think there was something in its place.

Most open source engines can be downloaded from the Articles & Tutorials section. Admittedly the grid nav is outdated, (it's V5) but the updated version which demonstrates V6 is downloadable from the Roguesoft homepage: http://www.roguesoft.co.uk

EDIT:

Wow, the grid nav downloadable from the A&T section is actually V4. Time for an update Ghost!

[j]

Btw, just so I'm understanding V6 correctly...

For the purpose of Neo Sprite, where the Shadow sprite is 20x30, I'm going to make the grid space size 30x30, making a 600x320 grid. This should mean, if I'm understanding it all right, that my gridlayout$ variable requires 240 grid coordinates (479 characters with spaces). I'm assuming I'll have to modify V6 so that gridlayout$ doesn't have any spaces in order to fit them into the 255 string limit.

Once I nail this down though, I imagine making a level designer app wouldn't be so hard. Just something that lets you click grid spaces on (travel) or off (no travel) and returns the gridlayout$ value so you can copy and paste it into the actual game.

[Tireas Dragon]

It seems you have forgotten the important update silverwind, Jadaco the new V6 doesn't use spaces. It does grids like this 1111000010010001010101010100101001010010101010011010010100101
The update I came up with uses the command MID$ instead of the command WORD$ so you can hit that 240

[j]

It seems you have forgotten the important update silverwind, Jadaco the new V6 doesn't use spaces. It does grids like this 1111000010010001010101010100101001010010101010011010010100101
The update I came up with uses the command MID$ instead of the command WORD$ so you can hit that 240

Doh, well that's what I meant anyway, good to see the fix already applied. =B