Pixel-Walker v2.0: Testers Needed!

[kylekrack]

A few months ago, I committed to rewriting the Pixel-Walker scripts to be more usable. It's still in progress, but the current scripts have met and surpassed what the previous iteration could do.

The goal of Pixel-Walker is to provide a script framework to replace default grid-based movement with 8-directional, pixel-based movement. It includes as many features of the OHR as possible, such as NPC activation types, NPC movement behaviors, pushable NPCs, etc. Some restrictions are beyond what I am willing to make up for, like A* pathfinding or NPC movement zones. Barring that, Pixel-Walker's limitations should be as unobtrusive as possible.

So how can you help?

First, download the scripts here: https://www.slimesalad.com/forum/viewgame.php?p=130697

From that point, there are a few things I'd like to know. Bear in mind these aren't finished, so things like caterpillar mode and foemaps are planned but not implemented. That being said, there's plenty for me to have overlooked.

As for evaluating how well the scripts work:

• - Are the physics functional to the quality that you expect from a game?
  - Does NPC activation behave as expected for use, stepon, and touch NPCs?
  - What features that you use in the OHR aren't possible in Pixel-Walker?

Additionally, I need feedback for importing the scripts included with Pixel-Walker in other .rpg files:

• - Was including the scripts straightforward; were you able to get the player moving without significant trouble?
  - Do you understand the main game loop script present in main.hss? What is unclear or unspecified?
  - Which customizable constants seem most/least useful to you? Which are confusing/poorly named?
  - What customizable elements are missing?
  - How readable are the scripts in general? Do you feel confident you could make desired adjustments to fit your game without serious emotional trauma?

In short, I'm making these scripts for other people to use. I really don't want them to be an absolute pain to use, because that defeats the purpose. It's hard for me to know what's unintuitive or annoying, though, since I've spent so much time with it. I need extra sets of eyes to help me prioritize, not to mention find bugs.

[kylekrack]

Version 2.1 is uploaded now. Added some features, fixed some bugs.
https://www.slimesalad.com/forum/viewto ... 697#130697

Most notably, there is a new demo scene using Fnrrf's 8-bit graphics set to create a town scene. Hopefully, it more accurately demonstrates what a game made using Pixel-Walker would look like.

I still need outside help with determining the readability and usability of the scripts. I will attempt to make a game using Pixel-Walker myself, but that won't be as valuable as someone unfamiliar with the scripts making use of them. There are details that I'm sure I will simply overlook.

[Bob the Hamster]

I haven't had a chance to check the scripts, but I just played the demo on my phone, and I am impressed! It works really smoothly, and feels nice.

You got me thinking about how pathfinding might work with pixel movement, and I have some ideas. Nothing is possible without adding some more plotscripting commands, but I have *ideas*

[ArtimusBena]

Coincidentally Bob, pathfinding's my number one thing. I will pay you money, my friend. Cold, hard currency.

[kylekrack]

In theory, I could use slices to write at least a BFS algorithm. I'd have to get really bored to reach that level, but I can't say it's impossible.

[Bob the Hamster]

@ArtimusBena: pathfinding specifically for pixel walking? Or some new pathfinding feature to be added to the existing tile-based A-star pathfinding?

@Kylekrack: so here is my idea, a way to tap into the tile based pathfinding but smooth out the corners. Suppose I added a script command to calculate the path from a tile to another tile, and access them from a script.

First you make the character align with a tile. Then you calculate the path. Then you store the X,Y of the next two steps. Let's say step A and step B. For one tick you move them towards step A (this makes sure they get around corners properly) then you move them towards step B untill they reach it. This may result in diagonal walking. After they reach step B you repeat the process, recalculating the pathfinding, and getting the next two steps.

[TMC]

For one tick you move them towards step A (this makes sure they get around corners properly)

Assuming zero friction? Otherwise, yes, a grid-based path can be the basis of diagonal grid-paths and pixel-based paths too.

Since I want to expand the wallmap to 16 bits, I was planning to add a bit to indicate rounded corners which you can diagonally cut across. These will be used both when we extend pathfinding to allow diagonal movements, and also for "move slice with wallchecking".

Actually, maybe we need two bits: one to turn the wall into a diamond shape, and one for approximately circular (octogonal). Circular would let you cut across 5 pixels diagonally, while diamond would cut across 10 pixels (meaning you could squeeze between two diagonally-adjacent walls). Hmm, maybe the diagonal one isn't useful enough to bother with. I think circular corners would be used more often, but that makes following a path more complex.

Here's a proposal for a set of pathfinding commands I wrote a while ago, which gets around the lack of arrays or objects in HS:

-compute npc path (npc, x, y, options)
--Each NPC or hero can have a path attached to it; "compute npc path" overwrites the previous if any. Existing pathfinding commands also overwrite the path.
-delete npc path (npc)
-get npc path length (npc)
-get npc path step x (npc, step)
-get npc path step y (npc, step)
-get npc path step dir (npc, step)
-ditto for heroes

[Bob the Hamster]

That is a great interface! I like the idea of having the paths saved with each NPC or hero. I had been thinking of something like a path handle, but that is a bit clumsy, and I think just attaching one scriptable path to each instance is much better

[ArtimusBena]

@tmc A diamond shape to me would make less sense than a single / or \ shape from one corner to the opposite corner. This would line up with the corners of connecting wall lines.

@Bob: Either one would be great! A serious game changer (pun intended), especially for those of use working on actiony games.

[kylekrack]

Diagonal walls sounds lovely. Would certainly open up a load of capabilities to these scripts in particular. I'll admit fully grid-based walls pose a big limitation on level design and even maptile design.

Having those pathfinding commands would also fix a lot of problems. Overwriting previous paths sounds fine. I can't imagine any situations where it's vital for an NPC or hero to store multiple paths simultaneously. Are you suggesting these commands would provide information usable by a command like "move slice with wallchecking()"? Does "get npc path step x/y" return a tile or pixel distance? I'm assuming it calculates a path based on the tile grid.

[ArtimusBena]

Saving previous paths would be very useful! In my case, anyway. Perhaps if there were a command to save current path, and another to return to it. Then an npc could deviate all they like without saving new ones, and then return to the original.

[kylekrack]

Saving previous paths would be very useful! In my case, anyway. Perhaps if there were a command to save current path, and another to return to it. Then an npc could deviate all they like without saving new ones, and then return to the original.

Why not just recalculate to the previous destination, rather than tracking and managing all those paths?

[ArtimusBena]

Depends on the map topography. If it's a complicated map, the npc may then take a complicated route to the original destination, perhaps even one that loops back some, just because the distance to the particular waypoint was slightly shorter. It's more like common human nature (especially when on a patrol path) to first return to where you deviated, and then continue on the original path.

[ArtimusBena]

Also the reason you may end up with a million paths is that the npc is finding its way to a moving target. You.

So my suggestion was to let us intentionally save one path, let the npc deviate in all manners, but then return to the saved path when a condition is met, like losing track of you.

[Bob the Hamster]

I think there is no functional difference between saving a whole path, and saving the X,Y of the old destination plus the X,Y of the point where you deviated from the old path.

You could resume the old path by pathfinding back to the deviation point, then pathfinding to the original destination