Hello everyone!
Me and my friend have started working on our first game for the playdate. It is a game we have tried to create before for android, but it was put on the back burner for a while. But as the playdate SDK came out and we started thinking of game ideas, we thought that it will be a perfect game for the playdate and started porting what we had to it.
It is a farming game inspired by a game jam devlog we once saw (https://www.youtube.com/watch?v=qh7MCQzjH08), with a mix of Stardew Valley and Minecraft. You start with a floating island of a thew blocks to plant crops on. As you harvest your crops you level up, which unlocks more block to place to expand your island (or create a new one). You also unlock new crops, machinery to produce more goods, and decorations to decorate your farm.
The game is still in really early stages of development and planning is still being done. We have implemented a start of the framework, but as this is the first time we are developing something on such limited hardware, we are quite unsure how it performs. We would love it if someone could run what we have, as it's quite a wait before ours are shipped (group 5 ). And if you could also tell us how the camera movements feels, as we don’t know if we have the best approach to isometric movement.
Hey! Just installed the game on my playdate and unfortunately on the actual device it's pulling like, 1-2 fps. I tested it on the simulator and it runs at a clean consistent 30 fps there, so it's definitely something to do with how the physical hardware is pulling/reading data from the pdx/code.
Sideload install also didn't work. I could drop the pdx manually onto the device via USB and that worked fine.
I had the same issue, had to manually sideload and getting less than 2fps. I can't seem to move at all in the game, its like its almost frozen and hops around sometimes. Looks cool but can't really do any inputs on my playdate while running
Thanks for trying it out. That was what we were afraid of. What we sent is the worst load the game will experience, but there is a lot of optimizations that needs to be done. As we don’t have a unit to test on it’s been quite hard to find out what works and not, as nearly everything we have tried runs smoothly in the simulator. Its most likely the crops that have the heaviest load, but can you try this version as well which only has the isometric tile map and see how that runs? We needed to implement our own tile map as the one in the sdk doesn’t support isometric tiles. If you can also check how big the tile map is before the fps drops that will also be much appreciated.
Okay, tested. So, zoomed out all the way it's at about 10-11 fps. Zoomed in all the way it's about 3-4 fps. This scales as you zoom out obviously, from 3-4 to 10-11.
Drawing it fully every frame will be quite wasteful. How much of the screen flashes orange when you enable Highlight Screen Updates in the Simulator? I'm guessing all of it?
Alternative ways to draw
Draw it all to a sprite and the system will make sure only changed pixels are sent to the display, though this would still be wasteful with drawing calculations
make every tile a sprite, this would be the best way as drawing would be totally optimised and as long as nothing changes on screen then no pixels would be updated. This should be able to run at 30fps or higher!
Yeah, we are rendering the whole screen every frame. We did try to only draw the necessary part once but struggled with z-indexing the tiles so left as is and decided to come back to it later. Saw in the docs that sprites have a z-index so we will go for your second tip. Thanks a lot!
We have made some changes to the tile map. Now all the Tiles are individual sprites as per @matt’s suggestion. If someone could test it out and see if it runs smoothly, it would be much appreciated.
I'm getting about 8-12fps and am able to move the cursor around and highlight tiles. I can zoom in and out, its a bit slow here and there but a lot better than the initial version I tried. Still can't sideload via the website, it will download and install but error at 100% so have to sideload via USB. It doesn't seem like pressing A or B do anything currently but I'm assuming that's intended at the moment
edit: I took a peek inside your .pdx and it seems you have an entity component system and are using lots of Lua libraries. My feeling is that whilst this is OK on Desktop, it is perhaps too much for Playdate. I would be happy to be proven wrong on this.
Using the profiler I see that 35% of CPU is spent on field update. 20% on animation. 17% on setImage, 10% on tile update. Why are these so high?
Our plan was that the player started out with around 9 tiles to begin with and as they levelled up new tiles are unlocked for the player to place within the world grid. What is in the demo was what we hoped to achieve when the player had unlocked all tiles, but it seems that this is a too ambitious number. Do you have any idea of how many sprites the playdate will be able to handle at once?
As for the 35% CPU usage in update is most likely because I forgot to disable the updating of the non-animated tiles. Which should be fixed now, but the game should be able to handle that all the tiles are animated and have their own update as that will be a worst-case scenario in the game. When I have a look at the profiler in the Simulator all I get is this (not very helpful):
I have added the function to change the size of the tile map by pressing A and B. And by holding down A the tiles are toggled between animated and non-animated tiles. This was implemented as a quick hack, so it is most likely quite slow. If some one could run it and see how many tiles (both animated and non-animated) it is possible to have before the fps takes a hit it would be a big help.
As for it not being possible to sideload via the website, I’m not sure why. Is it a different build procedure when building for the playdate then for the simulator? (I’m running ‘pdc MyGameSource MyGame.pdx)
This is running significantly better now. It boots to a stable 30fps.
When pressing A or B to change scale fps can drop to 8fps but typically between 12-25fps. After the size has transitioned, frame rate goes back up to average which is 25-30fps.
Zoom works as it should, when zoomed in the frame rate is a more stable 30fps. When size changing and zoomed, it only drops to 20-25fps.
You can navigate between tiles much easier and inputs are more responsive.
Edit: Still can't load via website, it errors on install. I sideloaded this via USB, which I have done for the previous versions that were listed.
Thanks for testing it out! Good to hear that it’s a lot smoother. Did you by any chance try to change the tiles to animated tiles by holding down the A-button?
Hi again, it’s been a while. I have had a little break due to exams but working on the project again. I decided to recreate what was implemented, but in C, to try and get a larger number of animated sprites. I have gotten a system implemented and would really appreciate it if someone could test it on actual hardware and report the performance for different numbers of tiles (or if I have even managed to build it properly for hardware).
The controls are the same: D-pad for movement, A to increase number of tiles and B to decrease. (Zooming hasn’t been implemented yet)
Hi, I would really appreciate it if someone could test the latest build I sent a few days ago. I really want to see how it preforms before I continue working on it to make sure I have a proper foundation before I start adding more.
). And if you could also tell us how the camera movements feels, as we don’t know if we have the best approach to isometric movement.
