Re: Pink Engine: A framework for using Tiled-created orthogonal maps in Ren'py
Posted: Thu Aug 13, 2020 3:12 pm
Apologies for the delay. Off-grid movement turned out to be trickier than I thought, and the heat wave murdered my productivity for a bit. Should have the new release ready by tomorrow.
edit: Turned out that when identifying whether something should be a sprite collection object, it only looked at the object's properties, not the parent tile's properties. It will be fixed in the next update.
I'm trying to fix the centering of bigger-than-grid characters before the release. I already did smaller-than-grid player characters last update, so I can just integrate it into the same function.
EDIT: Actually, what you should consider doing is making the character's 'base' fit the grid. Without the base being specified, a character is considered to occupy all the grid coordinates that intersect with its image. When the pc thus occupies more than a single coordinate, pathing and interaction become kind of a massive pain.
To make the 45x60 character's base occupy a single grid in the 32x32 grid (aka, make it move like it was occupying only a single coordinate), add the following properties to all the animations of the character:
{"name":"base_offset_x_start", "type":"int", "value":7},
{"name":"base_offset_x_end", "type":"int", "value":39},
{"name":"base_offset_y_start", "type":"int", "value":28},
{"name":"base_offset_y_end", "type":"int", "value":60}
(I've started learning tkinter so I can eventually make a nice, visual editor for the sprite collection jsons. Having to edit the .json files directly results in a rather opaque system.)
I tested it a bit, but it does seem to cause some minor side effects at default zoom. For instance, the pink diamond things get a slightly irregular outline. Still, it is handy if your game is heavy on close zooms, so I added it to pink_config.Syrale wrote: ↑Tue Jul 28, 2020 2:43 pm 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.
Okay, yeah, that one there is a legit bug. I'll go fix it.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:
edit: Turned out that when identifying whether something should be a sprite collection object, it only looked at the object's properties, not the parent tile's properties. It will be fixed in the next update.
Good news: I'm starting on the tutorial right after this next update. I've got a couple of requests for them over discord, so I'm prioritizing it over adding sight events.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.
Yeah, I ran into this one myself while making the next update. The long and short of it was that a model's movement-blocking rules also applied to itself. So a character wasn't able to move in any direction that caused any part of it to occupy a position currently occupied by another part. It should be fixed now (a moving object now considers any tile already occupied by itself as passable).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'm trying to fix the centering of bigger-than-grid characters before the release. I already did smaller-than-grid player characters last update, so I can just integrate it into the same function.
EDIT: Actually, what you should consider doing is making the character's 'base' fit the grid. Without the base being specified, a character is considered to occupy all the grid coordinates that intersect with its image. When the pc thus occupies more than a single coordinate, pathing and interaction become kind of a massive pain.
To make the 45x60 character's base occupy a single grid in the 32x32 grid (aka, make it move like it was occupying only a single coordinate), add the following properties to all the animations of the character:
{"name":"base_offset_x_start", "type":"int", "value":7},
{"name":"base_offset_x_end", "type":"int", "value":39},
{"name":"base_offset_y_start", "type":"int", "value":28},
{"name":"base_offset_y_end", "type":"int", "value":60}
(I've started learning tkinter so I can eventually make a nice, visual editor for the sprite collection jsons. Having to edit the .json files directly results in a rather opaque system.)