Yep. You had the perfect case.
But this I think is just positive … in the end, the quality of the code improves.
I will be pushing the fix to the repo very soon
2 Likes
Thanks Jonne!
I really want this game to have all the help it can have. This and @drummyfish Demo3 really caught my attention.
2 Likes
Thanks, that was fast! I see the update on github, but not on Mbed. I have been using the online Mbed compiler because I never set up anything locally (besides for the simulator, but I never set up a project for this game with the simulator). Is using Mbed still recommended?
Oops! I will update that also. Just a minute!
It’s now also in mbed online ide
@wuuff : Right-Click on PokittoLib folder under your project in the project tree in your mbed online compiler, choose “update”
Your framerate will improve if you don’t use Mbed.
1 Like
I don’t know what the official line is, but personally I recommend PlatformIO with a compatible IDE,
such as VSCode or Atom.
It works better, and there’s no more glitches on the left, but at certain offsets there is still a weird artifact on the right side:
The glitch can also be seen using the sample code I posted earlier, although it’s much less colorful.
3 Likes
Ok! Is it visible all the tine or just at times?
Not all the time, the camera needs to at a certain offset like before.
1 Like
Try to manage, I’ll take another look later today
1 Like
No rush, it doesn’t really impact gameplay, and like @BigBadHodad said, it looks kind of like what old NES games did, which is kind of neat. Of course, I’ll still update the library when you do find a fix, but it’s not a big problem.
New update added to original post! This new version contains a lot of new tiles and a special workbench tile that adds crafting! Tapping A when the cursor is over this tile opens the crafting menu, allowing you to craft new blocks.
This version also adds a few other cool things, but I won’t spoil them all. However, one thing I did want to mention is that now blocks are not picked up immediately after destroying them. The go into a destroyed “floating block” form. This solves a problem I had about what to do when a player’s inventory was full.
Previously, if I allowed the player to destroy a block with a full inventory, it would just vanish forever, making rare blocks potentially unobtainable! I considered not allowing a player to destroy blocks at all if they couldn’t fit it in their inventory, but that could make it fairly easy for a player to permanently trap themselves. This solution allows a player to destroy blocks without having to pick them up, plus it allows for an arbitrary number of floating blocks without using any more map storage, as I store whether a block is in solid or floating form in the high bit of each world tile. Since each world tile is stored as a single byte, I’m now restricting myself to 128 unique tiles instead of 256, so I’m hoping I won’t end up needing more than that many. There are currently 18 unique tile types, including empty tiles.
I’m hoping to add saving to a future release soon, but I haven’t started on that yet. I wanted to get a few more features in first, since any new tiles added to world generation between versions would not be available in an old save, so a new world would have to be made for new versions anyway.
4 Likes
To get around the tile restriction you could make it so the world is split into biomes and each biome has 128 block types (the ‘biome palette’), so the block data is relative to the biome type of the chunk.
You could designate a special “home” biome for player to build houses in so they can use up to 128 types of block from any other biome in their home.
So effectively, as they place blocks they build up their home biome’s block palette.
So essentially you end up with two kinds of block IDs, global and local.
Local IDs are relative to the biome they’re associated with.
Global IDs are the biome ID followed by the local block ID.
(If that’s not clear enough, let me know and I’ll make a diagram at some point.)
2 Likes
Thanks, that does seem like a good idea for chunking up pieces of the game world, although it wasn’t in my immediate plans to add chunks. Right now the entire game world is resident in memory (64x64 tiles). Correction: I meant 128x128 tiles
If I do end up making a larger world, I will need to swap the chunks out and back from the SD card, and I will probably only store smaller chunks of tiles in memory. If I go to the effort of making those changes, I think I would just prefer to increase the number of bytes per tile to 2, which would give me plenty of tile types, plus avoid the restriction of a cap on the number of unique blocks in the player’s home.
For now, I’m not even close to reaching 128 types of tiles, so I don’t want to complicate things before I need to.
1 Like
New version is nice, getting super nice!
1 Like
If you need a few pointers on how to do that, I’m implementing it right now for my Blockitto game; source code should hopefully be up this weekend if all goes according to plan. That approach also allows for an infinite world which is pretty fun. (I haven’t implemented saving/loading chunks yet but it should be fairly simple, just some basic SD file I/O stuff.)
2 Likes
Great game! I found a couple of bugs though, here’s what my session looked like:
- First, I went mining. I went to gold level and picked up some stone, sand, clay, copper, iron, and gold.
- Then I built back up to the surface and made a workbench. I crafted some boards, roofs, bricks, and glass.
- Next I went looking for wood. I fell in a pit with a slime and looked in my inventory.
- The first bug: there was a new block in my inventory that was random pixels approximately 3 tiles wide. When I placed it in the world the pixels would randomly change whenever I moved. It had regular collision.
- Then I built out of the pit and tried planting leaves in the hopes that I could get more wood. I jumped on the leaves and the second bug happened - I launched into the sky and wouldn’t come back down. So I had to end the session there.
1 Like
Fair enough, but be aware that by using 2 bytes per tile you end up either having to halve the chunk size or using double the memory and subsequently it takes twice as long to read a chunk from the SD card.
You may not even get to the point where you have 128 blocks,
but it’s better to try to predict problems before they happen,
otherwise you can end up wasting effort going down the wrong rabbit hole.
1 Like