Generally speaking (both in HCI/UX design and suggested in the Playdate accessibility docs), it's good to give the player as many options as possible for input unless the input is specific to the gameplay (like in Crankin's Time Traveling Adventure, for example).
That said, you're making a relatively complex game, and the Playdate has only so many buttons... so I get it !
Excited to play with the new alpha, let us know when it's ready to test out.
Moving this thread into the Games forum, given the updated classifications.
Alpha 6 is ready to be shared (5 is skipped, had a bug).
Alpha 1 was messing with sprites, Alpha 2 was the proof of concept & demonstration of scalability, Alpha 3/4 was the expansion of the game's internals systems and addition of the save/load mechanics, and now Alpha 5/6 further expands on the game's systems and contains the proper UI system which replaces the temporary dev-UI from the previous iterations.
v6 is now up to 7,039 lines of MIT licensed C code (source above).
New in Alpha 5
World & Navigation
User Interface
Buildings
Note on saves: I was overly optimistic above regarding preserving backward compatibility of saves (at least while the game is still in alpha, and I need to change things around the backend often). So please note that launching v5/v6 will sense and automatically delete any save file present from v4! Without this auto-delete, the game would crash when trying to load the old save.
Next: I will publish a "big factory" save game file for v6 soon, for people who want to look at all the items whizzing about but don't want to have to do the building. The UI work is not finished, there is still an "Inspection" UI and the Setting menu to be added. But soon it will be the time to start massively expanding on the available Crops, Factories and Extractor types beyond the current demonstrators. Also coming soon is the Storage Box Utility object, to act as an item buffer, or store.
After That Player movement and object placement overhaul, graphical consistency overhaul, sounds and music, enter beta for polish + juice + balance + play testing.
FactoryFarming_Alpha_6.pdx.zip (132.0 KB)
GIF showing some of the new menus and the Vitamin Factory.
I've shared my feedback in Discord but I need to say.
The performance you've achieved here is impressive!
This game has quickly moved to the top of my list of most anticipated games.
Can't wait to see what it becomes.
About time for another update. Does feel now like a full playable beta is not too far away.
As some of the change log could start to spoil mid-game revelations, I am starting to use the spoiler tag below.
Factory Farming Alpha 7
World & Navigation
Only one plot may be loaded into memory at any time, but unloaded plots will sill export resources which can be imported into the loaded plot
User Interface
Buildings
Including lake-only and ocean-only plants
Almost forgot the line count! Alpha 7 comprises 11,566 lines of code, that's +64% lines compared to Alpha 6.
Note: No public build of Alpha 7 being posted here, but one more playtest is expected.
Factory Farming just entered Beta! Meaning the game is complete and playable. Next comes more playtesting, more tuning and more polish - but the initial release is now in sight!
The full change set is Comparing Alpha_7...Beta_1 · timboe/FactoryFarming · GitHub
Summary of what's new:
)Beta 1 comprises 14,023 lines of code, a 21% increase over Alpha 7.
A quick tour of part of the first factory which I managed to build up all the way to the end of the game.
(GIF compressed to 16 FPS, game targets 32 FPS on device)
Hey! Really enjoying Farming Factory beta. Nice work! I tried joining the discord channel linked in the first post but it didn’t seem to work. Any tips?
Hi @pietvanzoen - sorry, missed this!
This moved over to here: Discord when the discord re-did its channels.
I am continuing to playtest the game without using cheats, adjusting the balance as I go. Going a bit slowly but I'm making progress here...
With big thanks to some bitmap code from @Daeke you can now take pictures of your factory 
I had thought that I'd filled up this world in my playtesting, but looking at it like this I see there is still room for some more industry here, will get on with filling in the gaps...
So the playtesting and balance-as-I-play is going well, I'm over 16 hours into this no-cheats playthrough and the end of the game is in sight now (if it were factorio, it'd be similar to having built the launchpad - and now needing to fuel it etc.)
Something I noticed with these large factories such as the one above was something was not quite right with the off-screen simulation. As a reminder: the on-screen factory small tick updates 16 times a second, while the off-screen factory big tick updates only twice a second (but the update is 8 times as large, to compensate).
The factory was always functioning, but running around it you could tell that items were not propagating around the conveyors as expected.
To debug I switched everything to the big tick twice-a-second updates to be able to see what was nominally going on in the off-screen parts, the main issue looked to be with the heavy use of mid-game fast conveyor belts which move cargo at two tiles per second, so exactly one tile per big tick.
Because each conveyor is updated in turn, depending on the direction the cargo was moving it could get moved many many tiles in just a single big tick - i.e. if the conveyor belt pieces were iterated over in the same order as the cargo was moving. As seen here in this loop where the chalk seems to teleport from the top left of the cycle down to the bottom right in an instant.
So some belts (E to W, S to N) were moving things normally, others (W to E, N to S) were zipping them around at amazing speed. And it all depended on the direction the belts faced. Not great.
The solution was to flag the target conveyor with the frame number when moving a cargo between tiles. Then when iterating over the conveyors, we skip any conveyors we find which are flagged with the current frame number.
This was super simple and worked perfectly.
Unfortunately though... now I had another, nastier problem. How to move a packed belt? We want to move each cargo by one tile on each big tick, but a cargo can only move if its destination is free. For two cardinal directions it works naturally. But for the other two we end up only half-filling the belt!
The current solution here is a bit more extreme, and I'll need to check its performance on device.
During the iteration phase over the conveyors, any conveyor which wants to move its Cargo to a currently occupied tile registers a Desire To Move in an array. Then, after all conveyors have been updated, the Desire To Move array is iterated over in reverse order and we attempt to move the Cargo once more.
The ones which still cannot move are saved into a second array, which gets iterated over next: either move or save back into the first array...
The procedure is iterated, alternating between the two arrays, until either a) we only moved 0, 1 or 2 Cargo in the previous iteration or b) we have made 8 iterations total. These numbers were chosen to try and balance the CPU load of the function. Here is an excerpt from the debug logs from this running on a single big tick for the above factory, 6 iterations were made on this frame.
A Iteration: moved 322 of 865
B Iteration: moved 33 of 543
A Iteration: moved 60 of 510
B Iteration: moved 7 of 450
A Iteration: moved 21 of 443
B Iteration: moved 2 of 422
With this in place, everything off-screen is back to moving as was intended! (At least, for the vast majority of the Cargo. Most of the 422 Cargo not managing to move here are likely genuinely stuck on a blocked belt, continuing to iterate to zero Cargo moved typically only requires a few more iterations)
Shown here with small tick turned back on in the vicinity of the player. The belts feeding in from far off-screen are all delivering items at a constant two Cargo per second from all four directions.
I'm now of course wondering if there was anything more efficient I could have done to fix this particular issue...?
Next milestone complete - I've finished my first full run through the game!
Total time for this balance-the-game-as-I-go playthrough? A little over 23 hours! And I knew exactly what I was doing. I'm glad I stopped adding content when I did... It's ended up longer than I anticipated.
Few residual things left on the trello to sort out which came up during the playthrough, but it seems like the end is in sight now.
I'm going to post my final world I built up over almost a solid day of gameplay, but note this could be considered a big ol spoiler so I'll flag it as such
Now at release candidate 4, there have been a number of additional quality-of-life suggestions and fixes
I also already binned the "Desire To Move" system I posted about a little over a week ago in favour of a slightly faster and hopefully an overall better solution.
The quick recap of the problem to solve is how to move cargo from A -> B, and from B -> C when A and B are both occupied and C is clear. It works when we first move from B -> C, then move from A -> B, but what about if we happen to iterate over A before we iterate over B? What if it's not A -> B -> C but is instead A -> B -> ... -> X -> Y where there is cargo everywhere except for Y?
The new solution is to harness the power of recursion! If A wants to move to B, but B is blocked by another cargo, then A attempts to call B's update function (there is still code in place from before such that each entity will only run its update function once per tick). B can then try move its cargo into C, or if C was also blocked it could recursively call C's update function, which could call D's etc. etc.. This cascading call will snowball down the conveyor belt until it reaches a dead end, or it reaches a point where the cargo can move into an empty space. At this point the stack unwinds, and as it does so each of the cargo move forward one tile into the newly freed space.
I need to figure out what the stack size is on the PD, but I also set a hard-limit at a recursive call of 128 levels deep which should be pushing something like 1 kB on the stack. Hopefully safe, to be tested...
This alternate approach came with additional bonuses:
It also has at least one downside, a recursive chain starting off-screen (where the updates are infrequent but large) can end up cascading down and finding an empty spot on-screen, causing the visible end of the stack of cargo to lurch forward by one tile! So far this has happened pretty infrequently, though I'm considering what I can do to keep this recursive update method only operating on the off-screen parts of the factory...
My non-device testing suggests this solution is around 1/3 faster than maintaining and reverse-iterating over an array of conveyors whose cargo wants to move, but cannot due to being blocked. With this solution there is no additional chunk of code of logic to be processed after the loop over buildings, but each building can now receive multiple update calls in a given tick (even though they will only action the first, and will return quickly for the later ones).
RC4 is currently under testing over on the discord, with the goal of better stress testing the megafactory on-device. The megafactory was the next thing to be made after the factory posed above on Oct 19th, I wired the screenshot feature into autosave for this one to get a nice time lapse.
Nothing to report from the last month, the game is 'done', but I've been hesitant to release (for money) a complex game like this which is trying to push the PD to it's limits... without having personally given it some proper testing on the actual hardware.
The community has been great in providing testing support, however there is a limit to what can really be achieved this way.
So, the time had come - I fired up eBay and... Hello PlayDate!
I already found one must-fix and a few would-be-nice in the first minutes of playing on device.
More to follow!
Cool! You really went the extra mile to test then. Congrats on finishing it, looks neat!
And it's finished! 
I only needed Sat-Thu with an actual playdate in order to perform the final performance checks, on-device debugging and gameplay testing. While the vast majority of the development went fine on the simulator, having the physical device was invaluable to bring the project up to publication quality.
Some of the things which got updated in this last week:
snprintf with %f does not work on device!Device-specific bugs asside, performance was the key thing to test on the physical hardware.
The simulation performance is good! Only in the largest factories is a small slow-down apparent from the execution of the simulation. 
Too many sprites on-screen will drop the framerate however, especially when the player is moving too. This can happen in areas with lots and lots of full conveyors, but the problem goes away when zoomed-in (which renders 2x2 instead of 3x3 chunks), the new Auto Zoom-In When Moving option can then keep the framerate always high, even in dense parts of the factory.
Release V1.0 is available now on itch: Factory Farming (Playdate) by timboe
Congrats on the release!
I think this is the first time I see a no-music option for download:
FactoryFarming_v1.pdx.zip 19 MB
FactoryFarming_NoMusic_v1.pdx.zip 390 kB
Very interesting to see that size difference! Worth considering for future releases, possibly automated with a bash script to empty the music folder, for example
Thanks, and yes when you break it down, its a huge difference. These are uncompressed numbers.
Game: 152k, sound effects: 216k, graphics: 19k, fonts: 12k, music (6 tracks, mono ADPCM WAV): 22,400k.
There was a little bit of extra code needed such that the game can handle the music files not being present without crashing, but worth it. At release it then is indeed as simple as deleting the music folder from one of the zip file, so easy to automate - yes!
I finished my end-project writeup of the development process of Factory Farming, you can find it over on my site
I still had some small areas I wanted to work on post-launch, and I found a way to further improve the game's performance on the hardware, so I just pushed a v1.1 update.
There are now graphics for conveyor belt corner pieces!
Plus lots of other new features and improvements, full details on: Factory Farming v1.1 Update - Factory Farming (Playdate) by timboe
One more thing - I just released the free Factory Farming Technology Demo! (based on v1.1), you can download it for free on the itch page (just above), I attach it also to this post, here:
FactoryFarmingTechDemo_v1.1.pdx.zip (19.6 MB)
In this technology demo you can explore one of my facilities, see what the game is like and how it performs. You can walk about, interact with buildings and cargo. You can also earn income via selling cargo, and visit the shop. The only things you can't do are build new buildings, demolish existing buildings, or save the game.
You can install the Technology Demo even if you have bought & installed the main game, it's classed as a separate PD application and will get its own entry in your list of games.
Here's the demo-facility I put together. It's not the most sophisticated factory complex - but I wanted to limit myself to using primarily factory buildings and crops up to Tech Tier 3, so as not to spoil the mid- and late-game progression too much.
I expect this will be the final big update here, at least for a while... This has been a fun project but I'm now considering it to be completed.
Huge thanks to Panic! Not just for the device but for all the tooling surrounding it. The C-API had almost everything I needed (thank you for the efficient rendering sprite system!) and I encountered minimal bugs/strange behaviours from it.
I was really not at all sure early on if the PD could run a simulation like this on the sort of scales needed to make a meaningful automation simulation game. Not just due to concern about spare CPU cycles for the sim part, (outside of rendering lots and lots of moving cargo), but things like cache access too - there is quite a lot which could have quickly started to cripple performance.
But in the end the little box more than exceeded my expectations, it's a real joy to be able to plan out then build large-scale processing facilities - all on the tiny little thing!
I have another (non-Playdate) project which is at something like 90%-done levels and needs finishing next. After that... I do have another project in mind (something completely different), unsure yet if it is going to be for PD or not.
