So here's my first post and my first shot at the start of a PICO-8 game. I had run through an adventure game tutorial with 8x8 pixel sprites a while back, but never went further with it. Recently, I was buying game assets that I'll never use, and I saw a neat 4x4 pixel set of assets (by an artist called Vexed). Intrigued, I started on a wee framework for it. You don't get actual 4x4 pixel tiles, but each 8x8 tile has 4 collision quadrants that you mark with the first 4 flags for each tile. So you can kinda fake it.
What I want is a mellow little adventure game with low stakes and low stress.
It's just a testbed right now. You can move the player around. There are 3 enemies that will come after you if you get too close. They're easily evaded and easily killed. You can draw your sword with the X button, but if you run into an obstacle, it'll sheath itself. If they hit you, you'll lose a heart. Lose all 5 hearts and you'll die and need to reset the cart. Wee first aid packs will each gain you a heart up to 5.
There are gems and wee piles of gold to collect. There's a key in the NW corner that'll open a door to a tiny graveyard off-screen to the SE. There's some space off-screen to the east and south to test screen scrolling.
There are a couple test signs you can read. Either X or O will dismiss them.
Sounds are extremely rudimentary, and there are only 2 of them.
While I'm writing this mainly to play myself, comments and suggestions are welcome, keeping in mind that this is literally my first PICO-8 game, beyond some minor modifications to a tutorial a year or so ago.
Forgot to add that the latest version will always be playable here:
https://tomcarlson.org/nybble-quest/
This looks extremely promising.
The 4x4 sprites create a contrasted effect : on the one hand, it's even more retro looking than a lot of early 80s games, yet at the same time, you have a huge 32x32 tiles of visibility, witch is more than a lot of modern tile based games.
I think the camera could be improved as most of what you see on screen is behind the player. You could reduce the size of the inner camera square, or keep it as big as it currently is, but start to scroll 2 pixels per frame after a certain time the player is moving non stop in the same direction, until the player touches the camera square with most of the screen showing ahead of the player, in with case you revert to 1 pixel per frame.
About movement speed : the diagonal movements feel much faster than the horizontal ones. You can fix this if you want by using update60 instead of update, and move orthogonally if the frame number is even, and diagonally if the frame number is a multiple of 3.
That makes the diagonal movement 6% slower than the orthogonal moves, instead of 41% too fast, while still dealing with integers only.
About the map : you flag approach is very original, but if you have more tiles you want to use, you may want to implement your own version of map that would use a string as the level, and a sprite sheet of 32x32 tiles of 4x4 pixels. sspr can help you display a 4x4 from the tile. This way your walls+grass would take a two 4x4 pixels
tiles in the spritesheet instead of 64, for example.
About death : rather than having the player restart the game with the pause menu, you can restart it programmatically with extcmd('reset')
Wow! That's all great advice! Thanks for taking the time!
I'll try increasing the edge buffer. I'm trying to strike a balance between seeing enough of where you're going, but also not having the map scroll all the time.
I'll give the diagonal movement change a try for sure. The extra speed is a problem to which I didn't have a good solution.
I'm trying to keep to the built-in tools with the map, but that's a really interesting idea.
Forcing a cart restart on death is just a kludge for now. Thanks for providing the command. My plan there is a secret Easter egg. If you leave the player dead for a little while, it'll turn into a ghost that you can freely move around, but can't interact with anything. Not implemented yet.
[Please log in to post a comment]
