PETI Roadmap From Now to Firmware 1.0
Last Updated: 2024-02-27 05:00:00 -0600
It’s not just you - for the last several months I’ve been talking about pretty much exclusively the 0.4.0 firmware update for PETI, and with such a close eye on that (admittedly large) prize, it can be hard to see where the rest of the project is going. That’s why, for this week’s blog post, I want to take a step back, and look at the current roadmap for updates that should lead us more or less all the way up to the 1.0 firmware update - the “release” version.
PETI Roadmap as of the End of Winter, 2024.
0.4.0 - The Sleep and Growth Update
If I’ve been putting an unusual degree of focus onto the 0.4.0 Update for PETI, it’s only because this is the first update since last summer that will actually contain anything remotely resembling a new feature for the pet - the currently-released 0.3.0 was strictly about power management features and improvements to the way the firmware uses the MSP430’s various low power modes in order to minimize battery draw. It was only the update before that, 0.2.0, where I added minigame primitives into the codebase and released the “Rock Paper Game” minigame, which hangs for reasons I still haven’t identified.
So to have one update come out that includes two new features is special, even if it is late, and it’s made all the more special by the fact that all my playtesting shows me that these two features make the biggest difference in helping the virtual pet feel alive out of everything else we’ve changed so far. Sure, there’s a lot left to do, but evolution and the ability to sleep are both pretty huge deals. When my local branch is halfway stable I’ve actually been loading it onto my dev kit and carrying the toy around the house with me to play with like it was a real virtual pet, in part because now there’s actually something to play for.
It’s still not perfect and it’s still not done. I’d like to get it done by the end of march, ideally. For the first time, I’m likely to use github’s releases feature to release both the source code and precompiled binaries, a pattern I’d like to use going forward for “real” releases to simplify the flashing process for people who are playing at home with their own development kits.
0.5.0 - The Bathtime Update
The next update on my radar, for which I’ve already started planning a little more comprehensively than we did for 0.4.0 (bearing in mind I originally thought 0.4.0 could be completed in time to release Christmas 2023 which, quite obviously, didn’t pan out), is 0.5.0, the “Bathtime” update. The brief here is simple: I need to add the pooping and washing mechanics to the game. This shouldn’t be a truly heavy lift - the hard part will be balancing the rate of the requests, but since it’s essentially adding one new function to main_game.c and one new scene to handle the animation for watching the pet, most of the work should be visual.
I’m also going to take time during that update to clear up quite a lot of the Pre-1.0 Technical Debt and Unresolved Future Triage boards, but I do want to try and hold this update to a short development cycle - maybe something closer to 3 months instead of 6.
0.6.0 - The Disease and Settings Update
The final update that’s currently planned in concrete terms is 0.6.0 - the Diseases and Settings Update. We have a whole byte to use for handling various game states, such as whether or not the pet is sick (or perhaps just how sick it is), as well as the pet’s weight, which is serving conceptually as a sort of crude proxy on player behaviour as far as meeting the pet’s basic needs. There’s also supposed to be a setting menu where we get things like the actual calendar configuration screen, and some soft options to control things like whether or not to use the LEDs or speakers for alerts.
That latter part is a question of menus and scenes, and so pretty easy to hammer out. Again, I want to hold it down to a relatively quick development cycle.
Future Updates on the Road to 1.0
Right now there are a large number of //Future tags scattered throughout my source code, marking out things that would make for distinctly important quality of life improvements, which aren’t reflected on the two boards I linked above. There’s probably going to be at least one more middle-version (0.8.0) where we clean up the bulk of those, and some minors tacked onto the side of it for additional bug fixing and performance improvements. However, the updates described above implement about 90% of the planned gameplay features - the only thing I’ve conspicuously left out is the still-extremely-nebulous SPI Expansion Port feature. I’m undecided yet on whether or not the firmware to support that feature actually comes out as part of the final 1.0 update, or if we simply lock in the core gameplay features, get the firmware out, and then decide how to do the final “stretch” goals.
Development Kit Housekeeping
I need to bring some information public about the Development Kits. Up until a few weeks ago, the bare-board kits for the Revision C REB Design were in stock on Tindie and available for purchase, and I’ve been saying for quite a while now that once they sold out, I’d be able to release the next revision of the development kit. Quite obviously, that hasn’t happened, and there’s two reasons for that.
The first is purely financial; while another set of boards-alone is cheap, the feedback I recieved from a lot of people was that the kits would be better if they were full kits, including components. That’s fine, but it takes the startup cost from the range of “this month’s hobby budget” to “lay aside for a while”. I’ve been setting aside the donations from our various support streams, and of course kicking in my own funds, but we’re not there yet. I’m hoping some time in the spring, so anywhere from late march through may, to pull this together and get it out the door.
The second reason is technical; while cleaning up the office I found a box of speaker components I had specc’d into PETI precisely because they seemed to be workable at the logic-level voltage most of the system is already running at - around 3.3V. However, I never did get them working during my initial testing, and then ultimately set them aside, lost them, and forget it ever happened.
This has inspired me to take a look at the audio system again. The current part on the BOM is WST-1208T, a 3 volt, fixed-pitch automatic buzzer. That means that while the firmware can control the length of time for which the buzzer is powered, we can’t do a damn thing about the pitch, nor, I suspect, the volume.
I want to have another look at that circuit, at possibly getting richer audio working for the pet. If I can, I’d like to work that into the development kit before I order the new boards, so… keep an eye on us for updates on that front. And if you bought one of the older development kits, don’t worry - I’m going to pay some mind to the idea of reverse compatibility. At the very least, I’ll manufacture some kind of adapter board.
If you wanted to show your support financially for Arcana Labs projects like PETI, but don’t need a virtual pet development kit, your best avenue is through the pathways detailed on our support page.