Pixel-Based walking with dwimmercrafty (etheldreme!)

Make games! Discuss those games here.

Moderators: Bob the Hamster, marionline, SDHawk

User avatar
kylekrack
Liquid Metal Slime
Posts: 1240
Joined: Mon Jun 16, 2014 8:58 am
Location: USA
Contact:

Pixel-Based walking with dwimmercrafty (etheldreme!)

Post by kylekrack »

Along with the new stable release came a wide variety of awesome new features. I took some time today to play around with one of those in a way that hopefully others will find useful.

Using the "move slice with wallchecking()" and "check wall collision x/y()" on a walkabout sprite, you can create a smooth, pixel-based walking system in about 200 lines of code. In my experience, collision checking was the most difficult part of designing a pixel-based movement system. These commands take almost all of that off your hands and leave you with a relatively easy way of moving your characters in 8-directions off the grid.

https://www.slimesalad.com/forum/viewgame.php?p=130697

This tech demo comes with the scripts file that anyone can feel free to use, alter, or do whatever you want with. They're pretty basic, so I can't justifiably claim much ownership of them. Features include a simple, 2-frame walking animation, speed adjusted for diagonal movement, and (this isn't really a feature, but) a fix that allows you to slide against walls that are blocking you. If that last thing doesn't make sense, I'm sorry. I don't really know how to explain it succinctly. If you want clarification, ask and I'll provide, but I am very sleepy at the moment.

Main things this tech demo lacks is friction and NPC interaction/collision. However, since I figured there were multiple ways of implementing that, I left that to the user to customize. However, if anyone wants it, I'll add it and reupload it.

This is exciting to me because compared to other systems I've seen before, these scripts are super simple, easy to incorporate into other scripts. For example, since these scripts load a walkabout sprite instead of using a hero, implementing a walktall script would only require changing one line.

If there are any bugs or things you'd like to see that you don't want to add yourself, I'm happy to help.
Last edited by kylekrack on Sun Dec 17, 2017 5:43 am, edited 2 times in total.
My pronouns are they/them
Ps. I love my wife
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Great! I'm glad this exists for other people to build on top over. Sidescroller 101 was hugely successful in allowing other people to make side scrollers (and this is very similar).

As you noticed, there's a bug in the new wallchecking commands where you can pass through a corner if you come in at exactly the wrong pixel. That's a bug I want to fix quite soon; I just started writing testcases for it.

Sliding along walls is a really important feature that's missing from the builtin commands, which will be added. You mentioned friction, which makes me realise that friction is just part way between sliding along walls and stopping dead (which is what the builtin commands currently do). So rather than an on/off parameter to enable sliding, I should add a friction parameter (0 to stop immediately, 100 for sliding), which will let me support all three behaviours at once.
Together with an animation system, I'm hopefully that the next engine version will reduce the size of the scripts to well under 100 lines :)
Last edited by TMC on Wed Sep 06, 2017 2:05 pm, edited 1 time in total.
User avatar
SwordPlay
Chemical Slime
Posts: 966
Joined: Sun Jan 22, 2017 9:32 am
Location: London, England
Contact:

Post by SwordPlay »

Really neat, and I'm playing around, trying to add some features to it. I would love to use this as the basis of a game, it feels and looks amazing.

NPCs
If you add (put hero (slice x(player), slice y(player)) then you can activate NPCs with "Touch" and "Step-On".
Kinda finnicky but it works.
Last edited by SwordPlay on Sun Sep 24, 2017 1:31 am, edited 5 times in total.
User avatar
Spoonweaver
Liquid Metal King Slime
Posts: 6461
Joined: Mon Dec 08, 2008 7:07 am
Contact:

Post by Spoonweaver »

I'm glad you're playing around with these new script commands, but honestly I'm not seeing the value here.
I really don't want stifle any sort of creativity or anything but I feel the need to say some things about this.

I've seen a dozen pixel based movement scripts for the ohr. This one doesn't really seem to offer anything new and is actually more limited in several ways, such as not being able to limit the character's hit box so they can actually touch walls going left or right or being able to have half tile walls.

The size of the script, 200 lines, is actually pretty big considering it's only pixel based movement. There are older scripts that are half that or less.

Anyways, as Virtuous Sword said, you really do need some sort of npc activation if you want this script to be useful.
Last edited by Spoonweaver on Sun Sep 24, 2017 2:35 am, edited 1 time in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Edit: whoops, Spoonweaver pointed out that I replied thinking this was the thread about kylekrack's sidescroller scripts, not the pixel-based walking ones. So parts of the following are irrelevant, and yes, I guess for pixel-based movement these scripts do little at the moment, so they're not terribly useful except as a starting point
Spoonweaver wrote:being able to limit the character's hit box so they can actually touch walls going left or right
Actually, you can adjust player/NPC hitboxes. You need to put the player slice in a container (and update the 'check cardinal direction' script).

As for half-tile walls, I think Mogri created one or two sidescrollers that had half tiles or slopes, which is really neat, but I've never seen anyone else do it. Have they? It's true that using these script commands limits you to the engine's built-in walls and for advanced stuff that's a problem.
However, these are the only sidescrolling scripts that support heros/npcs larger than 20x20. They might also be the only ones that handle side-on (thin) walls.

Also, the length isn't bad. Baby bob, after stripping out all comments and blank lines, was still 300 lines. The equivalent SS101 scripts (part 3) were 206 lines, but they have significantly worse wall checking than this. I don't remember seeing any sidescroller scripts as short as you say.
Most of the length is due to working around that engine bug, and due to the rather complicated animation system.

I've actually been meaning to try to write a simple sidescroller in the minimal number of lines, I bet I can get it under 50 :)

But yes, you're right that these scripts are just a start, they don't have as many features as others. SS101 is still the best start.
Last edited by TMC on Sun Sep 24, 2017 7:03 am, edited 3 times in total.
User avatar
kylekrack
Liquid Metal Slime
Posts: 1240
Joined: Mon Jun 16, 2014 8:58 am
Location: USA
Contact:

Post by kylekrack »

I definitely need to revisit these scripts and add several things if they're going to be useful at all. I kind of abandoned these ones for the sidescroller scripts because the 8-directional walking wasn't as successful. With a little bit of work, I could definitely make these scripts worthwhile, though. I left them as a proof of concept, and I really should take it further than that. I just haven't set aside time to do it. I just moved, and that's taken a lot of my attention.

First of all, NPC activation, of course. That's really important. I still need to do that in the sidescroller scripts as well. Difficulty is not the reason I've neglected it. I should be able to get it done in no time.

Second is making the movement more fluid. Right now the sprites move at a set velocity in all directions, rather than having any acceleration. I'd like to fix that. I made that work in the sidescroller, I just have to transfer over some lines.

Then, and this is a bigger add, is giving NPCs the ability to have pixel-based movement, as well as the player. I'm thinking of essentially writing each move type described in custom but using the pixel-based scripts, then check each NPC's movement each tick. I don't know about that, though. That'll take some messing around.

Ultimately, the point with these scripts was to show that these script commands allow for really easy collision-based slice movement with only one known bug, that I imagine will be fixed soon-ish.
My pronouns are they/them
Ps. I love my wife
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

OK, I've finally fixed the bug! It was pretty gnarly, took me about three attempts to find a fix that worked in all cases, each time covering more obscure situations.

I didn't get around to implementing friction though.

(Wait for nightlies)
User avatar
sheamkennedy
Liquid Metal Slime
Posts: 1110
Joined: Mon Sep 16, 2013 9:29 pm
Location: Tama-shi, Tokyo, Japan
Contact:

Post by sheamkennedy »

This is incredibly well done! I think my only criticism is that the camera movement is jarring for my eyes. This is because the drawing style has a decent amount of detail and the camera is centred on the hero. I think having a chunkier drawing style would relieve the strain on my eyes. Or you could simply add some sort of invisible buffer area which only allows the camera to move when the hero is running against it.

One of my favourite games for platformer camera movement is Super Mario World. This is a bit complex as there are multiple camera movement types which are triggered based on player behaviour but it's really neat to hear it explained and the end result is very appealing. Here's a video on that:
https://www.youtube.com/watch?time_cont ... CIMPYM0AQg
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

Switching to a higher frame rate might also help make the scrolling less jarring
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

That video's very interesting, great find! I never realised there were such complicated rules around camera movement. However, the more complexity you introduce, the more edge cases you'll create, which will require even more rules to fix, ballooning into quite a headache. At the end of the video you can see a case where the camera movement is broken.
That's something that often makes apparently-simple features in the OHRRPGCE turn out to be a great deal of work (wall collisions being one example - the wall collision commands are waaaay more complex than how it would normally be scripted in side scroller).

I don't know if I'm looking at the latest version of the demo, but I think that giving the player acceleration will help a lot to make the movement feel smoother, probably the camera movement too. Should have a look at what other RPGs do with the camera.

In other news, last month I added friction arguments to the wall collision commands, so you should be able to remove a bunch more code. I think it's still not good enough for walking though; fitting a 20 pixel hitbox through a 20 pixel-wide hole is very difficult. So I also want to add some kind of option to make it move around corners. ... See, a neverending headache!
Last edited by TMC on Wed Oct 25, 2017 1:56 am, edited 1 time in total.
User avatar
kylekrack
Liquid Metal Slime
Posts: 1240
Joined: Mon Jun 16, 2014 8:58 am
Location: USA
Contact:

Post by kylekrack »

This little demo is far from being usable. I really need to revisit it. I just have so many other things queued in front of it that I also need to finish. If you want to see a more complete use of the new plotscripting commands, I used them to make some sidescroller physics as well. The demo (without full mechanics implemented) is here.

A more polished version of these scripts was used for a game I'm working on, Beat, which can be found on GameJolt. This is actually one of the things ahead of the original 8-direction walking scripts on my things I need to finish.
My pronouns are they/them
Ps. I love my wife
User avatar
SwordPlay
Chemical Slime
Posts: 966
Joined: Sun Jan 22, 2017 9:32 am
Location: London, England
Contact:

Post by SwordPlay »

I love looking at videos like that. Seeing good game design inspires me.
Japanese game design is deep.
Having multiple camera behaviours is a genius idea.

You might check this out (about 2 minutes in) though I can't say this is a great implementation, it is certainly very unique.
[yt]STkXgQ[/yt]

It has a fascinating camera system, and to be frank, very interesting other mechanics too. I have no idea what became of this game. But it's cool.

I still think about pixel-walker. It has a few issues, but it's cool. I would like to use it to make a game (or 2)

My thoughts on Pixel Walker:
Things happen quickly and gameplay feels more fast-paced and fluid.
You can't really use NPCs, but that's okay because it can happen automatically.
Having to worry about being close enough to mash the Use button isn't as good as simply moving to a location and having it done automatically.
Different NPC activation methods handle events admirably. Other things can use slice collision detection.

I think proximity-based gameplay automation are the way to go rather than the use button and long lists. Using slices other than walkabouts helps.

It would speed up lots of tedious things (pick items up when you step on/near them. step on an object to use it)
and it lends itself to slices very well too (displaying the name when you are close by)
In all, it is a much more flexible and quicker system than the default tile based system, and gives a much more different feel.

If you want the player to be able to "Use" it is good to include an indicator (like in the video). It is not always obvious where boundaries or collisions are, especially if you are using non-centred sprites, unusual hitboxes, or invisibly aligned
Last edited by SwordPlay on Wed Oct 25, 2017 5:42 pm, edited 5 times in total.
User avatar
kylekrack
Liquid Metal Slime
Posts: 1240
Joined: Mon Jun 16, 2014 8:58 am
Location: USA
Contact:

Post by kylekrack »

Oh wow! It's cool to see someone using this. Now I really feel pressured to make them worthwhile to use :zombie:

My plan was to write movement and activation styles for each one defined in Custom. The pathfinding... maybe not. I already dove down that rabbit hole and didn't come out alive. But touch, stepon, and use activation are all going to be usable. In the sidescroller scripts, this can be seen in action, except for "touch" I think. I didn't know how that would be treated differently from stepon in a platformer. You can specify how each NPC behaves the same way you do without plotscripting. I think you're right about using NPCs from a design perspective. If you're picking something up or hitting a switch, it feels more organic for it to happen organically, rather than having to push a button.

That being said, NPC collisions are handled much better in the sidescroller scripts. There is an indicator above the player's head when you can use an NPC. The player and NPC sprites are actually container slices with sprite children. Because of this, you can adjust the hitboxes of players and NPCs. I will transfer this over to the 8-directional movement scripts eventually.

I had prioritized the sidescroller scripts because that interested me personally, but if multiple people would want to have a full, usable version of these pixel-walker scripts, I could definitely prioritize that. It wouldn't take long to get them to a stage where they have enough features to be worthwhile.
My pronouns are they/them
Ps. I love my wife
User avatar
sheamkennedy
Liquid Metal Slime
Posts: 1110
Joined: Mon Sep 16, 2013 9:29 pm
Location: Tama-shi, Tokyo, Japan
Contact:

Post by sheamkennedy »

@Kyle:
I have an interesting idea and wanted to try it out. It involves using your pixel-based movement system in a small map that has "wrap" enabled such that when the hero crosses the edge boundary of the map, the map repeats. I think something was overlooked in your code which is not allowing the code to work on a "wrap" map.

I'm pretty sure slices wrap just fine as I remember playing around with this awhile back but when I use your pixel-based sprite the sprite slice disappears as I cross the edge boundary of where the map wraps. The sprite slice reappears as soon as I enter back into the default map area (within the wrap boundaries). I'm having trouble figuring out why that is.

I'd like to get to the bottom of this so I can continue with my idea! Please let me know if you have any clue as to why this might be happening.

EDIT:
-I've decided to start manipulating your script a bit. It seems as though when I comment out "set parent(player, lookup slice(sl:walkabout layer))" it causes the sprite slice wrapping to happen properly but with one ridiculous flaw... it also causes the hero to maintain their velocity and by holding down a direction they will gain so much speed that the are able to escape the camera's view and cause the screen to do all sorts of fun stuff. I suggest you try it, it's pretty neat but undesirable haha.


EDIT #2:
-After playing with this more and more I think that the issue is not with the code. I think it has something to do with "wrap" relying on knowing the hero's (x,y) position. Since this remains unchanged I think the solution might have something to do with parenting the hero to the player slice then the hero will move along with the player slice. I'm not sure how to do this though.
Last edited by sheamkennedy on Fri Nov 10, 2017 3:56 pm, edited 2 times in total.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
User avatar
kylekrack
Liquid Metal Slime
Posts: 1240
Joined: Mon Jun 16, 2014 8:58 am
Location: USA
Contact:

Post by kylekrack »

I'll get on that right now. I think I can work out a solution.
My pronouns are they/them
Ps. I love my wife
Post Reply