It looks like part of your issue with pixel perfect is that you made it so that the actual player position and other non rendered data was pixel perfect, which made it so you could only move at pixel size increments. Pixel perfect is only for the final render position on the screen. Even retro games like the original mario stored positions in what they called subpixels(we would use floats nowadays), so that you could have smooth movement.
Interesting point, I wonder if I could have had better results if I wasn't rounding values myself and instead just relied on the roundPixels config which perhaps would have achieved that effect of snapping to a pixel perfect position just for the final render, but still allowing for subpixel calculations. In any case, I'm happy with the result now but perhaps I'll play with that in the future.
This is the way, in my game i use floats (vector2) for movement and ints (gridpoint2) for anything not moving, but mine snap to a 16x16 pixel grid, sounds like your not using a grid system, if you are going to be adding pathfinding for enemies/animals later i would consider a grid system that isnt 1x1 pixel
@@byronmorley2907 I'm using a 16x16 tilemap, and for various features in the game I also have a "proximity grid" which allows me to do some things more efficiently (e.g. I can check just the grid spaces near the player for collision checks, spread fire to only nearby items etc). I'll probably utilise that proximity grid for some animal behaviour (e.g. scaring fish/birds away if the player gets close) but at least for now I don't think I'll need any pathfinding
@@joshmoronypixelsYou can add a virtual grid after the fact for pathfinding, in my experience, especially in Phaser due to performance constraints, a big loose grid for pathfinding is okay and use more direct methods like distance between for range and tracepath for line of sight for enemies to navigate or affect their behavior etc when close. Unless you need things to navigate around physical objects smartly over a longer distance than say 1/4 screen, then its not always necessary.
this is the first video of this game ive seen, so sorry if i end up asking something that youve explained in a different video, but would it be a smart idea to use the arrow keys to select an object that is also within the same distance as the drop radius? this was you can basically "scroll" through your options by highlighting each one. this would make absolutely sure that any item that is able to be picked up can be
the water looks so much better!
this is so cool. I am a beginner and didn’t understand what u talked about, but the game is so cool
Looks cool! Keep it up!
Add some colored noise to the ground/sand/grass. A multi-octave perlin will do the trick.
i like calling him adam chonies
It looks like part of your issue with pixel perfect is that you made it so that the actual player position and other non rendered data was pixel perfect, which made it so you could only move at pixel size increments. Pixel perfect is only for the final render position on the screen. Even retro games like the original mario stored positions in what they called subpixels(we would use floats nowadays), so that you could have smooth movement.
Interesting point, I wonder if I could have had better results if I wasn't rounding values myself and instead just relied on the roundPixels config which perhaps would have achieved that effect of snapping to a pixel perfect position just for the final render, but still allowing for subpixel calculations. In any case, I'm happy with the result now but perhaps I'll play with that in the future.
This is the way, in my game i use floats (vector2) for movement and ints (gridpoint2) for anything not moving, but mine snap to a 16x16 pixel grid, sounds like your not using a grid system, if you are going to be adding pathfinding for enemies/animals later i would consider a grid system that isnt 1x1 pixel
@@byronmorley2907 I'm using a 16x16 tilemap, and for various features in the game I also have a "proximity grid" which allows me to do some things more efficiently (e.g. I can check just the grid spaces near the player for collision checks, spread fire to only nearby items etc). I'll probably utilise that proximity grid for some animal behaviour (e.g. scaring fish/birds away if the player gets close) but at least for now I don't think I'll need any pathfinding
@@joshmoronypixelsYou can add a virtual grid after the fact for pathfinding, in my experience, especially in Phaser due to performance constraints, a big loose grid for pathfinding is okay and use more direct methods like distance between for range and tracepath for line of sight for enemies to navigate or affect their behavior etc when close. Unless you need things to navigate around physical objects smartly over a longer distance than say 1/4 screen, then its not always necessary.
you could make item flinging a thing by "dropping" the item while inheriting the speed of the mouse when it exited the grab radius lol
could be fun!
this is the first video of this game ive seen, so sorry if i end up asking something that youve explained in a different video, but would it be a smart idea to use the arrow keys to select an object that is also within the same distance as the drop radius? this was you can basically "scroll" through your options by highlighting each one. this would make absolutely sure that any item that is able to be picked up can be
That is definitely an approach I could take too, though I think the approach with the mouse feels more intuitive to me at least
Remember me when u go to the moon!!
wish you good
this is heaps good