Hey Thumby Community!
I'm happy to share my recently completed game. In Beta until I receive the hardware.
Here is a fully playable Tiny Pac Man like game I made especially for Thumby. I tested it at actual resolution on Andriod and made the controls very forgiving.
Should work at Thumby scale. Anyone with a Thumby, feedback would be appreciated. I don't own mine yet. Might need to change up speed, optimize memory or the draw pipeline, etc.


Video:
https://www.youtube.com/watch?v=4zITvR0L46c

Also, made a modified version of the emulator here that only plays PicoPac so you can quickly test it out from your browser. Enjoy!
https://christophercarson.github.io/

Impressive! I like the full-size Pac-Man on the initial screen. While I also have Pac-Man on my list of games that I think would work well as demakes, its need for several functions I'm not yet sure how to implement convinced me to focus on my simpler ideas first: tracking which pellets to disable (my guess would be a dictionary of all pellet locations, though I wouldn't know how to set that up), ghost AI (having each ghost to go to their designated corners and which pixel each should use as a means of tracking Pac-Man), and how to scroll between bitmaps, among other factors.

As pictured below, I came up with a "NanoMaze" mockup a few weeks ago where the regular Pac-Man maze is scaled down as accurately as possible to a point where only vertical scrolling between two bitmaps would be required. A bit more difficult to give the ghosts "character" with such a low resolution, though as indicated by the "sprite list" at the bottom right, movement direction could be indicated at the very least, with the power pellets differentiated by having them flicker, and swapping the pallet when a power pellet is in effect.

While I plan on implementing my various game mockups in an order of increasing complexity (NanoMaze probably being near the top of the list), if you'd be interested in trying to adapt the logic you came up with for Pico Pac to such a design, or perhaps implementing it as an alternate mode, I'd be glad to divide the graphics into importable sprites and create additional ones as needed. While my attempts at creating functions often take a while just for them to break, once I figure out how to implement saving an array of highscore values to a text file for my current projects, I imagine such a function could be easily repurposed for most games where all that needs to be saved from one session to the next are highscore values.

Coolie Coolster,

I really dig your mock up! I also started with a similar design. It looks GREAT when blown up to the scale you have shown. One thing I think a lot of developers are going to be disappointed by is the actual scale of the screen when the hardware arrives. It's TINY. I mean REALLY TINY. We are all seeing video with modern cell phones that are essentially acting like magnifying glasses. I had done some actual to scale testing on Android to get a feeling of what could actually been seen with the naked eye on the hardware. There is a reason why the Thumby team has the text scaled to one third of the entire screen by default. I've attempted to capture the effect of shrinking both your graphics and mine to scale with the attached screen shot from my Android device. Do NOT zoom in, but download and open the image at screen Android size. While it's still blurry (it's not actually blurry in real life), PacMan pellets 1 pixel big blur into the surrounding lines. Text in the range of 4 X 7 or so pixels is absolutely not legible to the naked eye.

If you are interested, I can help you mock up a python program to do scale testing on your own Iphone/Andriod.

Also, you are free to use any function and logic from my code. There is currently no Ghost AI, as the map area is so small, it doesn't take long before random chance sends the ghosts in your direction. So it seemed unnecessary in such a confined space.
Nearly all the logic is ready for re-use in my code though. I made it to accept different maze patterns, so it will be easy to adapt to any pac-man like maze. However, I do have the maze paths hard-coded to 10 pixels across, as after testing any smaller didn't seem reasonable.

It would be nice if a member of the Tiny Circuits can confirm or deny my to scale findings. Until we developers start receiving our devices, it's really hard to estimate what can be seen on such a tiny high-resolution oled screen.

Very impressive! 

I'm not sure how much it would help as it seems that taking accurate photos of the Thumby's screen is difficult due to its size, but here's one of my nearly complete "NanoMem" game that someone with a pre-release Thumby took for me. As I personally find the default font to take up too much space, I've been using bitmaps as a means of using custom fonts, with the "TINYMEM" text on the title screen using the smallest legible font of three pixels tall. As the game's score is displayed via five pixel tall bitmap numbers separated by one pixel wide gaps, I'll ask the person who sent me the picture how legible the score for reference. Also, as the screen only seems to be roughly half the width of the device itself, while I'd have to do a calculation first, perhaps larger screens might not have a sufficient pixel density to be an accurate reference for the Thumby?

Edit: While the pixel density of a smartphone would have to be a multiple of that of the Thumby to be able to accurately represent how a game would look at the scale of the Thumby, as most smartphones should at least have a higher resolution than that of the Thumby, at least an estimate can be determined by seeing how legible the nearest multiples of 40x72 are. Not an exact method, but it should still be informative.

Coolie, you are completely correct on the pixel density. Shrinking a thumby image to scale (18 mm wide), it appears the screen is around 10 mm.
The testing I was doing on my Android came in at a teeny tiny 5 mm. So yeah... The true scale is about twice as large as I was first thinking.
(see attached images)

That's great news for how much more information we can pack onto the screen.

I'm happy to collaborate to get the full version of pacman working. It won't be nearly as much work with all my logic already in place. I believe with such small graphics if we actually draw the characters (pacman, ghosts, etc) with setPixel from the graphics api it should speed up the game since there appears to be more calculations involved in translating the pixels from a bitmap  when I was glancing through the api code.  Just let me know what parts you would like to tackle and I'll support you . I could also just rewrite using your graphics scheme, but don't want to step on your toes.
AND... I'm a full time software engineer and student, so it's been a personal indulgence to code on the side lately.

No worries regarding function implementation; I much prefer to collaborate with others to implement more complex ideas rather than trying to do so by myself without much success, in addition to the benefit that the game concept itself gains with more people working on it. I'll try setting up a basic title screen that takes inputs for a high score screen, settings screen, and "start game". There would also be the potential to implement a multiplayer mode at a later point, but as it isn't yet documented in the API, such an implementation and the associated title screen selection option for it can be saved for a potential later revision. Will probably not be as efficient as can be, but I'll subsequently upload a ZIP file with the PY file and importable gameplay graphic bitmaps that can then have the gameplay functions added to it.

To display the background maze walls, as they could be mirrored across the y-axis, would it be better to implement it as two bitmaps each blitted regularly and mirrored, or divided further into drawing the edges of the maze as lines and blitting the rectangles within the maze individually?

Just send over the map as an entire bitmap. I believe if I simply take the section needed for the screen it will be sufficient, but we can optimize once a runner is working.

I'll have to send it as the bottom half and the top half at the very least as the import utility doesn't accept anything beyond the resolution of the Thumby itself (hopefully a limit that will be increased at some point), but I guess if the values are being blitted 40 lines at a time depending on the vertical coordinate of Pac-Man, the bitmaps could just be combined following the import and then just used as the general background dataset. I'll add the graphic data to the PY file I send, as well as separate image files of the various bitmaps for reference, and then you can subsequently adjust it and let me know if anything else is needed.

Impressive! I like the full-size Pac-Man on the initial screen. While I also have Pac-Man on my list of games that I think would work well as demakes, its need for several functions I'm not yet sure how to implement convinced me to focus on my simpler ideas first: tracking which pellets to disable (my guess would be a dictionary of all pellet locations, though I wouldn't know how to set that up), ghost AI (having each ghost to go to their designated corners and which pixel each should use as a means of tracking Pac-Man), and how to scroll between bitmaps, among other factors.

I've actually written a Pacman on one of the few systems with a lower resolution than a Thumby, the Studio II (64x32) and did it like this https://www.youtube.com/watch?v=6XdxTDsz6Jo&t=91s - the horrible sound is because that's the only sound this machine can make.

I would suggest a similar approach, widening your sprites to make the graphics larger. Because all the sprites (except the collectable) are in permanent movement, they don't blend into the walls.

I would recommend an array and a counter for tracking your power pills, and maybe a dictionary for the power pills. As regards the display, Pacman is easier to program if you forget the final look, almost, and thing of it not as a maze but a grid of rails, so from any point on the grid there is a rail from one power point to the next, and once on it, you can only stay on that rail till the next point.

Your version sort of reminds me of Blinky for the CHIP-8, though perhaps with somewhat more capable ghosts? And yeah; the reason I designed the mockup sprites as they are was to avoid them merging with the walls, but I guess I can try to modify them and see how they'll look in the maze mockup.

Still need to finish with the graphic set, but I was thinking that creating a function for Pico Pac to save its high score to a text file on the Thumby would not only be helpful for the game itself, but also could serve as a base for other developers to implement such functionality? My first game for instance, NanoMem, is ready other than that functionality, which I haven't been able to figure out thus far...

@ccarson81

I hope you don't mind, I edited your original game to work on the latest version of the Thumby API, than created a pull request to have this slightly edited version loaded to the Thumby Arcade.

Please feel free to ask me to remove if you don't approve, or you can make any pull requests you'd like on my Fork.

I credited you in all instances.

https://github.com/TinyCircuits/TinyCircuits-Thumby-Games/pull/32

Let me know if you have any questions, thanks.

-Xyvir

Xyvir,

Thank you for doing that. It has been on my list of things to do, just been busy with school and work.

This is my last reply to close this topic. I have my Thumbys now and have enjoyed playing PicoPac on the device. Games with the smaller graphics give me a headache to try to concentrate on. So I'm leaving this project where it's at with the larger (and more playable - in my opinion) graphics. If anyone else would like to pick it up for the next iteration, be my guest. I hope all who play it, enjoy it! Thanks!