Pink Engine: A framework for using Tiled-created orthogonal maps in Ren'py

[ijffdrie]

Hey everyone!

Here is something I have been working on for the past few months: The Pink Engine. It is an open-source framework for using Tiled-created orthogonal maps in Ren'py. Those are top-down maps that use reusable tilesets to create levels. Think of older Pokemon games, or any game made in RPGMaker.



The Pink Engine is currently still in an alpha state, but it's functionality is expanding at a rapid pace. To see the latest features, you can look at the changelog on the itch.io page.


Tutorials

• Tutorial 1: Making a basic pink engine game
• Tutorial 1.5: The Sprite Collection Editor
• Tutorial 2: More Map Design
• Tutorial 2.5: The autotile translator
• Tutorial 3: Sprite Collections and NPCs
• More Coming...

Differences from RPGMaker
Since RPGMaker is the most prominent orthogonal map creation software to be used by creative individuals on the internet, I figured I should highlight a few distinctions:

• Occultation (whether you are drawn in front of something or behind it) is determined by the map, not the tileset. In RPGMaker, it is defined in the tileset whether an object is drawn in front of the player or behind them. In the Pink Engine, this is instead determined by which layer you put the object on. If you put an item in a 'sub' layer, they are drawn behind characters. If you put an item in a 'super' layer, they are drawn in front of characters. If you put an item in a 'dynamic' layer, their occultation depends on the characters' y position relative to the object. The reason for this is that the RPGMaker setup starts behaving oddly when confronted with characters with unusual sizes, whick the Pink Engine should be able to draw just fine.
• You can diverge from the grid. By making use of object layers, you can map items in any position. The Pink Engine will automatically apply the relevant the object's movement rules to all tiles touched by the image's 'base'.
• You don't have to use the same grid size for every map in your game, and can freely diverge.
• The Pink Engine does not have a maximum number of tilesets per map, nor does it have a maximum number of images per tileset.
• Thanks to Tiled saving its tilesets in .json format, they are easy to share. You won't have to reassign settings every time you use a tileset in a new product.
• The Sprite Collections were created to allow for animation cycles of any length, rather than having to reduce everything to the 3 * 4 grid of RPGMaker. It's also much easier to make objects play specific animations.

Discord
I have now created a discord server for the pink engine. It can be found here. It's a great place to ask a quick question, or get some insight into the plans for the pink engine.

Long-term plans
My end goal is for the Pink Engine to serve as a full-fledged open-source RPG system. In addition to these orthogonal local maps, such a system would include world travel maps (with random events), an inventory/equipment system, a character system, a levelling system and a combat system. However, such a thing is obviously a long way off.

[gas]

I've did a try.
I've experienced some error in the movement buffer, I think is due how the first touch just change facing. Sometime the player move two squares in vertical movement.
I think the facing should change AND the movement should trigger at the same input. Or at least you should include a flag to turn off/on this behaviour.
This is how most of tiled JRPG work, at least.

Also, the movement animation should trigger even if you'll hit an obstacle, or the game seems not reactive to input.
Again, a flag could allow users to set this behaviour.

I've seen that saving is not just "unavailable", it actually throw an error about pickling some class. As this could cause a critical intervention on the module structures and importing, I'll hint you to focus on that before everything else.

[ijffdrie]

I've experienced some error in the movement buffer, I think is due how the first touch just change facing. Sometime the player move two squares in vertical movement.

I have been doing some rejiggering of the way that movement is done, which I think should fix the issues with the movement buffer (as well as allowing me to use it as a basis for future NPC characters).

I've seen that saving is not just "unavailable", it actually throw an error about pickling some class. As this could cause a critical intervention on the module structures and importing, I'll hint you to focus on that before everything else.

Whoops, that's indeed a big issue. Turned out to be an issue with the definition of one of my Named Tuples.

I think the facing should change AND the movement should trigger at the same input. Or at least you should include a flag to turn off/on this behaviour.
This is how most of tiled JRPG work, at least.

Also, the movement animation should trigger even if you'll hit an obstacle, or the game seems not reactive to input.
Again, a flag could allow users to set this behaviour.

Both excellent proposals, which have been implemented. A new file called pink_options.rpy has been added to offer such engine customization.


Version 0.5.3 is now available, including the bug fix, the flags, and the new movement code.

[parttimestorier]

This sounds really useful! Thanks so much for sharing it with everyone. Having played around with RPGMaker a bit, it sounds like it will be great to be able to determine which layer individual objects are on myself, instead of having that be pre-determined by how the whole tileset is set up. I'll have to try this out sometime.

[isobellesophia]

Thanks for this one, i am going to create a new novel soon and definetely using this one as a RPGMaker style.

I hope there will be more updates soon.

[ijffdrie]

Was busy for a few days, now back in action to write updates. However, before I get started on that, I should probably actually write down some documentation.


Documentation
In order for the Pink Engine to properly read Tiled tilesets and maps of your design, it makes use of a number of custom properties. As such, I thought I’d take a moment to introduce these, as well as explain some other design options, constraints and practices you should keep in mind. Note that this documentation is not an introduction to the Tiled editor itself, and it assumes some familiarity with it. There's plenty of documentation for Tiled available already though.

Tilesets
The Pink Engine only works with ‘Collection of Images’-style tilesets. ‘Based on Tileset Image’-style tilesets are not compatible for the Pink Engine, nor are they planned to be.

movement properties

• move_from (str): This defines the directions that a character can move when standing on the given tile. The first symbol corresponds to the upwards direction, and goes clockwise from there. A 1 stands for a direction you can move in, a 0 stands for a direction you cannot move in. So on a tile with move_from 0010, you can only move left. On a tile with move_from 0101, you can move left and right, 1010 for up and down, 1111 (the default) for all directions, 0000 for no directions, etc. etc.
  move_to (str): This defines the directions that a character can enter the tile from from. Like with move_from, the first symbol matches moving in from the upwards direction, with the rest going clockwise from there.

move_from and move_to rules are together used to create a movement map for the map in question, with move_to overriding the move_from of neighboring tiles. As a result, unless you’re doing something complicated, you can generally get by just using move_to codes ‘0000’ for impassible objects and ‘1111’ for passable objects.

Movement rules are applied to every grid square intersected by the image's 'base'. As such, an image that has a base larger than a single tile, or which has been placed off-grid to intersect multiple tiles, affects the movement on more than one tile.

base_offset properties
Just now, I made a reference to the concept of an image's base. To explain what exactly that is, I should explain a difference between RPGMaker and the Pink Engine. In RPGMaker, all tileset images must correspond to the size of the Grid. In the Pink Engine, this is not only not necessary, but actively discouraged (since it messes with the occultation of larger-than-usual characters).

Let’s take this image for an example:


This image is meant to represent some kind of computer thingie, and is used in the Pink Engine test maps. These test maps are designed for a 64 x 64 pixel grid, with this image occupying 64 x 192 pixels. So, it’s one grid square wide, three grid squares tall.

In RPGMaker, you would implement this image by turning it into three distinct tileset images. You could then give each of these images their own movement rules (typically, you would pick impassible for the bottom one, and pass behind for the other two). In the Pink Engine, the entire thing is a single image, so you can only assign a single set of movement rules to it. Normally, the Pink Engine would then apply those rules to every grid square that the image intersects. However, with the base_offset properties, you can limit those rules to instead apply only to a certain part of the image. For the computer, you would want to apply the movement rules only to those grid squares that are intersected by this particular part of the image:


For that, you use the base_offset values.

• base_offset_x_start (int): The difference in pixels between the left-most side of the image and the left-most side of the base. In this example, that would be 14.
• base_offset_x_end (int): The difference in pixels between the left-most side of the image and the right-most side of the base. In this example, that would be 50.
• base_offset_y_start (int): The difference in pixels between the top-most side of the image and the top-most side of the base. In this example, that would be 140.
• base_offset_y_end (int): The difference in pixels between the top-most side of the image and the bottom-most side of the base. In this example, that would be 180.

Event properties
The Pink Engine currently offers two distinct kinds of event properties, which are used to trigger events.

• event_on_touch (str): This is used to define a touch event, which is an event triggered by the player entering the grid squares intersected by the image’s base. The value of the property is the name of the ren’py label that the engine should jump to for this event.
• event_on_activate (str): This is used to define an activation event, which is an event triggered by the player using the activation key (spacebar) to interact with a grid square intersected by the image’s base. The value of the property is the name of the ren’py label that the engine should jump to for this event.

It is recommended that you do not define event_on_touch and event_on_activate in your tilesets, but instead add the properties to individual objects on your map through the use of object layers.

As with the movement properties, the event properties are applied to all grid squares that touch the image’s base, and are thus affected by the base_offset properties.

The Conditional Property
Just the one property here:

• conditional (str): A string containing a python expression that evaluates to True or False. If the conditional evaluates to True, the object is rendered on the map, and has active movement and event rules. If the conditional evaluates to False, the object isn't rendered, and does not influence movement or event rules. Note that the evaluation is done in the python context, rather than in the ren'py context. That means that if you want to reference a ren'py variable, you need to do it in this format:

  Code: Select all

  renpy.store.__dict__['name_of_variable']

Custom occultation
Added in 0.7.1

• occultates_as_y (int): Sometimes, a single tile in your tileset does not represent the entirety of the object. Even with the pink engine's support for larger tiles, you may want to build some objects out of multiple modular tiles. Think of pillars, or shadows. This can cause some issues with occultation. For this reason, the pink engine has the occultates_as_y keyword, which allows an object to occultate as if it were occupying a different y-coordinate.

Sprite Collection Properties
Since 0.6.5, the Pink Engine supports Sprite Collections. These are objects that can play animations and move around the map. NPCs, openable doors, changing background elements, these can all be implemented using the sprite collection system.

• sprite_collection_path (str): This is the property that determines whether something is a sprite collection object or just a regular object. The sprite_collection_path is the path that leads to the .json sprite collection file that the object will use as a basis.
• ref_name (str): An object with a ref_name will be assigned to a ren'py global variable of the same name, allowing you to address it in your ren'py code. Objects with a ref_name are also consistent, while objects without one reset on leaving a map.
• start_orientation (str): The orientation that the object starts with. Objects try to find an oriented version of their currented animation. For example, if you tell an object to run the 'shimmy' animation, and its current orientation is 'right', it will first look for a 'shimmy_right' animation in the sprite collection, and only look for a plain 'shimmy' if none is available. Valid orientations are 'up', 'down', 'left', and 'right'.
• movement_speed (float): The time in seconds the object takes to consume an element on the control stack (the list of commands that proscribe movements to the object). The lower the value, the faster the movement.
• repeat_commands (bool): Whether the object repeats its control stack ad infinitum or just the once. True by default.
• move_animation (str): The name of the animation used when the object changes position due to consuming elements on the control stack. 'walk' by default.
• stand_animation (str): The name of the animation used when not moving. 'stand' by default.
• turn_on_interaction (bool): Whether the object changes its orientation to face the player when interacted with. True by default.
• stand_on_interaction (bool): Whether the object switches to its stand animation when interacted with. True by default.
• default_control_stack (str): The control stack that the object starts out with. Should be a list of PinkControlCommand objects. For example [PinkControlCommand("go_up"), PinkControlCommand("go_up"), PinkControlCommand("go_left"), PinkControlCommand("go_left"), PinkControlCommand("go_down"), PinkControlCommand("go_down"), PinkControlCommand("go_right"), PinkControlCommand("go_right")] is a control stack that makes a character walk in a circle. The following types of control commands are available:
  • move_left, move_right, move_up, move_down: Makes the object move one square in the given direction. Does not cause the character to turn. Can be passed the pop_invalid_move command. If set to True, the object will not try to repeat an invalid move (when something is blocking the movement route) for its next movement, but will skip to the next command on the stack. Can also be passed the animate_invalid_move command. If set to False, the object will switch to its 'stand' animation if its current movement command is invalid.
  • turn_left, turn_right, turn_up, turn_down: Shifts the object's orientation to the given direction. Can be passed the stand_on_turn argument. If set to False, the object will use its 'move' animation when turning, rather than switching to the 'stand' animation.
  • go_left, go_right, go_up, go_down: Makes the character turn (if necessary) and move in the given direction. Go commands can be passed all the arguments for turn and move commands, as well as the turn_and_move command. When set to False, the object will only either turn or move, not both.
  • go_to: Makes an object go to a given coordinate. Object will move square by square, first along the y axis, then the x axis, until it reaches its destination. Can be passed all the arguments that the go command can be passed.
  • delay: Delays the consumption of the next instruction on the control stack by a number of seconds. The number of seconds can be passed along using the quantity argument.
  • play_animation: Causes the object to play a single animation in its sprite collection in full, once. The name of the animation can be passed along using the animation_name argument.
  • change_movement_speed: Causes the object to change movement speed. The new movement speed can be passed along using the quantity argument.
  • change_stand_animation: Causes the object to change its stand animation to the animation with the given name. The name of the new animation can be passed along using the animation_name argument.
  • change_move_animation: Causes the object to change its move animation to the animation with the given name. The name of the new animation can be passed along using the animation_name argument.
  In addition to the listed arguments, each PinkControlCommand can also be passed the set_movement_time argument. When set to False, this will cause the object to skip over updating the movement time for that command, cause it to immediately execute the next command. Useful for changing moving speeds, animations, and such things.

Maps
As with the tilesets, the pink engine is designed to work only with one of the options offered by Tiled: The Orthogonal orientation, with CSV tile layer format. The Pink Engine replicates the Right Down tile render order, so you should pick that as well.

Maps only have two custom properties at the moment, which tell the Pink Engine in what order to render the layers.

• layer_type (str): a string with a value ‘sub’, ‘super’ or ‘dynamic’, which tells the Pink Engine how to occultate the objects in the layer. Layers with the layer_type ‘sub’ always have their objects render below characters (so, you should use this for walls and floors). Layers with the layer_type ‘super’ have their objects render above characters (so, use this for lighting and chandeliers). Layers with the layer_type ‘dynamic’ have their objects occultate according to the character’s position, rendering below them when the character stands in front of it, and above them when the character stands behind it. ‘interaction’ and ‘movement’-type layers are planned additions for non-rendering layers.
• z_order (str): Z_order determines the rendering order within each layer type. A sub layer with a z_order value of 101 will render above a sub layer with a z_order value of 100 (but both are rendered below a super layer with a z_order of 99).

Autotile Translator
To make up for my absence, I'm throwing in a tool. To help me with the creation of the test maps, I actually wrote a bit of code that allows me to quickly turn RPGMaker-style autotiles into Tiled tilesets. Not only does it instantly generate all the legal iterations of that tileset, but it also turns them into wang sets to make drawing maps a breeze, as well as assigning the appropriate move_to and move_from Pink Engine values. You can find the executable source code for the translator (along with some sample input and output, so you should know what it looks like) on the itch page under autotile_translator.zip.

How to use:

1. Put the autotiles in the “input” folder. Autotiles must be RPGMaker-compatible .png files.
2. Rename the autotiles so that the translator can see their type. It separates the input name by underscores, and looks at the second word. So lab_cei_1.png is recognized as containing an image for a ceiling, lab_flo_1.png is recognized as containing an image for a floor, and lab_wal_1.png is recognized as containing an image for a wall.
3. Open translator.py in any text editor, go to last line (line 482) and change “tileset_testlab” to the name of the tileset you want to output. The autotile translator will automatically append the dimensions of the tileset to the name.
4. Run translator.py, and wait for it to finish running. This should only take a few seconds.
5. In the output folder, you now find a whole bunch of .png files, along with a .json file. The .json file is your tileset, and should be put in your game in the pink_engine/tilesets/ folder. The .png files are your tileset images, and should be put in your game in the images/tilesets/<name of the tileset>/ folder. The name of the folder should match the name of the tileset file.

[ijffdrie]

I released version 0.6. This version adds conditional tiles and objects to the engine, as well as using a much better system for calculating the movement rules and retrieving the events for a given coordinate. I've updated the documentation in the post above this one.


Edit one day later: Already on 0.6.1. Saving and loading now works properly, returning you to the tile from which you saved, rather than the start of the map/end of last event.

[ijffdrie]

Version 0.7.5 is now released, finishing full support for sprite collection objects (objects on the map that can change position, play animations and follow movement routes. Useful for things like NPCs). The documentation post (see two posts above) has been updated to include the documentation for the new functionality.

The Pink Engine is now dangerously close to being viable. Only cutscene support is necessary for that, which is what I'll be working on next.

[sapiboonggames]

Thanks a lot for making this!
One question though, for some reason I can't "interact" with any of the door in the corridor
(I tried pressing ENTER / Z and a bunch of other keys and can't trigger the event)

[ijffdrie]

Spacebar was picked as the interaction key.

Though now that I say that, I should probably make that configurable.

[sapiboonggames]

Spacebar was picked as the interaction key.

Though now that I say that, I should probably make that configurable.

Oops, I feel so silly now
Anyway, good job on this so far! Can't wait for the finished version!

[anh0814]

Your engine is amazing! Thank you. ❤

I try to fiddle with it and read your documentation, but I'm a just beginner with Renpy so I don't understand much let alone use it. I would really appreciate maybe a tutorial on how to implement Tiled maps onto the Pink Engine, maybe? That would really help!

[Syrale]

I'm really loving this engine, and I'm so glad I found it. Thanks for your amazing work so far!

I've been playing around with the code to add certain features, but I always ended up breaking something different in the process.
I'm not that experienced a coder, so I hope you don't mind if I suggest the things I've been trying to do:

Shift to run. (Or any other button, really.)
While testing things, I caught myself heading to the computer that controls movement speed pretty often.
So having a key that doubles movement speed when pressed (and returning it to normal when released) would be very useful, both for developers and players.
As well as a variable that turns on running by default (which should then no longer take the key press into account).
I also think it would be a cool touch to have an optional running animation, if a corresponding sprite set is specified.

Zooming and scrolling across the map (without moving the player).
This kind of thing would be very useful for cutscenes, or to emphasize certain game locations. Two concrete examples:
Camera zooms in on the player or speaking character during dialogue, and zooms back out when it's over.
Camera scrolls 3 tiles away from the player when approaching a cliff, so more of the background scenery can be seen. Camera centers on the player again when they walk away.

Adjust map screen size.
Right now, the map covers the entire screen. It would be cool if this could be adjusted.
Different games have different user interfaces. If the size and position of the map screen could be customized, that would add a lot more artistic freedom.
Ideally, the map size would be a kind of "crop area" so zooming in or out wouldn't affect the size of the map window. I really hope what I'm saying makes sense.

Player party.
I love when other characters follow the player character, so I think it would be great to specify a party list of some sort.
Customization could be added, such as the amount of visible sprites (usually 1 or 4, but would be cool if adjustable), or the party order (so someone could change the leader if they wanted to).
I'm aware this already enters character system territory, but I still thought I'd mention it.

WASD + Mouse controls.
I think one very intuitive way to control the game would be WASD for movement and click to interact with something. Especially if a game contains point & click elements, it could be a little jarring for the map gameplay to only allow keyboard controls.
I'm aware "A" and "S" are already reserved by Ren'Py, but maybe changing their commands to "shift+A" or a different key entirely wouldn't be too bad?

Button movement controls.
One step further would be adding on-screen Left, Right, Up and Down buttons that control player movement (and repeat the command if held down). I was never a fan of RPGM's "click a tile to walk over there" method, so I think this would be a decent alternative for touch screens.

Gamepad support.
This one is extremely optional, since I don't think many people use gamepads, and it would probably be a hassle to implement, but I'll suggest it anyways.
I just think it would be cool if the game could be played with a controller. That's all.

...Phew, that was a lot. I hope you don't see all these suggestions as an insult, I just figured they would be fun things to consider (or dismiss ).
Thanks again for everything you've done so far. I'm eagerly looking forward to each new update.

[ijffdrie]

...Phew, that was a lot. I hope you don't see all these suggestions as an insult, I just figured they would be fun things to consider (or dismiss ).

No insult taken. I absolutely love getting suggestions, and the ones you offered are great.

Zooming and scrolling across the map (without moving the player).
This kind of thing would be very useful for cutscenes, or to emphasize certain game locations. Two concrete examples:
Camera zooms in on the player or speaking character during dialogue, and zooms back out when it's over.
Camera scrolls 3 tiles away from the player when approaching a cliff, so more of the background scenery can be seen. Camera centers on the player again when they walk away.

The scrolling across the map is gonna be implemented in 0.7.2. I hadn't thought much about zooming, but it does seem like it'd be a very useful function, so I'm gonna try and implement that as well.

Shift to run. (Or any other button, really.)
While testing things, I caught myself heading to the computer that controls movement speed pretty often.
So having a key that doubles movement speed when pressed (and returning it to normal when released) would be very useful, both for developers and players.
As well as a variable that turns on running by default (which should then no longer take the key press into account).
I also think it would be a cool touch to have an optional running animation, if a corresponding sprite set is specified.

I've got this somewhere in the backlog, but implementing it should be relatively simple I think, so I'll throw it in a bit sooner, maybe as early as 0.7.2. It is a pretty standard feature, so it is rather essential

Adjust map screen size.
Right now, the map covers the entire screen. It would be cool if this could be adjusted.
Different games have different user interfaces. If the size and position of the map screen could be customized, that would add a lot more artistic freedom.
Ideally, the map size would be a kind of "crop area" so zooming in or out wouldn't affect the size of the map window. I really hope what I'm saying makes sense.

I never thought about this one, but you're completely right. This is an essential function to have. I'll make this the 0.8.0 functionality.

Player party.
I love when other characters follow the player character, so I think it would be great to specify a party list of some sort.
Customization could be added, such as the amount of visible sprites (usually 1 or 4, but would be cool if adjustable), or the party order (so someone could change the leader if they wanted to).
I'm aware this already enters character system territory, but I still thought I'd mention it.

I did mention in the opening post that I'm planning of eventually expanding the pink engine into a full-fledged RPG system, so having suggestions that enter character system territory is no biggie. It would indeed be a nifty feature to add, though at the moment it's not high priority.

WASD + Mouse controls.
I think one very intuitive way to control the game would be WASD for movement and click to interact with something. Especially if a game contains point & click elements, it could be a little jarring for the map gameplay to only allow keyboard controls.
I'm aware "A" and "S" are already reserved by Ren'Py, but maybe changing their commands to "shift+A" or a different key entirely wouldn't be too bad?

This one I'm a bit unsure about.

On the one hand, the way I tried setting up the pink engine was that it would leave the basic ren'py functions essentially untouched. That way, the engine could be plugged into any random project just by putting in the engine's files.

On the other hand, I'm finding this approach a bit limiting. One thing you've probably noticed is that when you press an arrow key when in a dialogue, ren'py automatically switches you to the quick menu at the bottom of the dialogue, which prevents the spacebar from continuing a dialogue. That's sufficiently annoying that I'm thinking of trying to find a way to shut that off, despite my design philosophy. Adding WASD+Mouse controls would be no more of a breach then that, so I'll keep it in mind.

Button movement controls.
One step further would be adding on-screen Left, Right, Up and Down buttons that control player movement (and repeat the command if held down). I was never a fan of RPGM's "click a tile to walk over there" method, so I think this would be a decent alternative for touch screens.

Another great suggestion. I haven't really put much thought into getting this to work with touchscreens, but this would indeed be a solid solution.

Gamepad support.
This one is extremely optional, since I don't think many people use gamepads, and it would probably be a hassle to implement, but I'll suggest it anyways.
I just think it would be cool if the game could be played with a controller. That's all.

Implementation wouldn't be much of an issue, I suspect. The issue here would be testing, as I don't actually own a gamepad.

Your engine is amazing! Thank you. ❤

I try to fiddle with it and read your documentation, but I'm a just beginner with Renpy so I don't understand much let alone use it. I would really appreciate maybe a tutorial on how to implement Tiled maps onto the Pink Engine, maybe? That would really help!

I'll start writing a proper tutorial after the 0.7.* series of updates.

[Syrale]

I love the new update and I'm really happy some of my suggestions were already implemented. Thank you so much!

I wanted to find a way to prevent the map from getting blurry when zooming in (since, at least for me, 2.0 zoom would be the most common one to use), and I came across a solution that doesn't break anything (I think!):

Code: Select all

define config.nearest_neighbor = True

It does affect all images, so that could be a downside for some people. Nonetheless, I thought it might be a useful piece of code to include.


Late addition:
Is there a way to define sprite collections on a tileset rather than on the map/object layer? This would be useful for things that have the same consistent animation, no matter which map they're on, and don't need to be interacted with (for example water tiles, or trees swaying in the wind).

I've noticed Tiled grays out the property if it's defined on the tileset rather than the map. In this case, the animation won't work. Fortunately, I did get it to work when it's defined directly on the object.
In this example, the left seaweed has a grayed out "sprite_collection_path" while the right one is black:

Another thing to note is that, if the animation works, the object is offset by about 1 tile? Both seaweeds were supposed to have the same Y value. Here's what my map looks like in Tiled:


Also: My player character's walking animation works, but she can't physically move on the new map I created. I didn't change her "move_from" and "move_to" values, the terrain layer is set to "sub" and every terrain tile is set to "1111".
A list of things to keep in mind when creating new maps would be very helpful, but I can understand if that has to wait until the tutorial is out.

Pretty sure these issues are due to me using Tiled/Pink Engine incorrectly rather than genuine bugs, but I thought I'd mention them just in case.

Further addition:
Okay, so I figured out why my player couldn't walk: The map's grid size was too small. I was working with a 32x32 tileset, while the player character is 45x60.

Setting the map's tile size to 64x64 fixed the walking issue, and enables me to now make a specific suggestion:
Would it be possible to allow tilesets that are smaller than the player sprite (and ideally position the player in the center)? I'm assuming the width is the issue, since taller player characters already work.

I also fixed the "1 tile offset issue" by adjusting "image_height" in the sprite collection file. My mistake!