Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Byte-Sized Swift: Building Tiny Games for the Playdate (swift.org)
211 points by rauhul on March 12, 2024 | hide | past | favorite | 39 comments


Tangentially related, but Lucas Pope's new game, Mars After Midnight, just released for $6 on Playdate. Played it for a bit during my lunch break and it's really cool and creative.

I had read a few of his devlog posts[1] from a while back and it's really cool to get an insight into his process. A while back I had also gotten into reading his updates on the process as he built his last game, Return of the Obra Dinn[2]. Only got 10 pages or so into the thread but again, his talent and attention to detail are incredible.

[1] https://dukope.itch.io/mars-after-midnight/devlog/261758/mar...

[2] https://forums.tigsource.com/index.php?topic=40832.0


Papers Please and Obra Dinn were outstanding! Hopefully this one makes it onto PC.


A Vision for Embedded Swift (https://github.com/apple/swift-evolution/blob/main/visions/e...) has the details on this new build mode and is quite interesting.

  Effectively, there will be two bottom layers of Swift, and the lower one, “non-allocating” Embedded Swift, will necessarily be a more restricted compilation mode (e.g. classes will be disallowed as they fundamentally require heap allocations) and likely to be used only in very specialized use cases. “Allocating” Embedded Swift should allow classes and other language facilities that rely on the heap (e.g. indirect enums).
Also, this seems to maybe hint at (most of?) the Swift runtime eventually being reimplemented in non-allocating Embedded Swift rather than the C++ (?) that it uses now:

  The Swift runtime APIs will be provided as an implementation that’s optimized for small codesize and will be available as a static library in the toolchain for common CPU architectures. Interestingly, it’s possible to write that implementation in “non-allocating” Baremetal Swift.


Yes, the long term roadmap for Swift is to bootstrap it, minus the LLVM backend, which is always a matter of not re-inventing the optimization algorithms that half of the world is putting into LLVM, whose contributions are at similar level as the Linux kernel.


This is great to see more resources being made for the Playdate. It is such a fun little console and the games made for it are such a breath of fresh air

I hope Panic is able to either retrofit or make a v2 with a backlight. I realized how low the contrast on the screen was after my cataract surgery and seeing details in some of the games becomes near impossible in less-than-ideal conditions.


The Sharp Memory LCD screen is opaque, unlike most other LCDs, so can't work with a backlight. It could work with a front/edge light but the results are not what you'd hope for.


How does the screen compare to the original Game Boy, or even the Game Boy Pocket?


Much much better than both.


As far as I can tell it works if you've got basically any amount of light at all, though it might involve tipping the display around until you catch a reflection at the right angle. It's more E-paper-y in looks than LCD-y, though the reflectivity is fairly unique.


Recently: Embedded Swift on the Raspberry Pi Pico https://news.ycombinator.com/item?id=39611111


Associated discussion on the swift forum: https://forums.swift.org/t/byte-sized-swift-building-tiny-ga...


Feeling pretty craft-y recently, huh?


Pretty cool. Swift is such a great little (little?) language, I'm always thrilled to see more of it outside of Apple stuff (which is not to say I don't also love it on Apple stuff)


I enjoy programming in Swift but it hasn't felt like a little language for quite some time now. It's a complex language with a lot of features and a powerful but elaborate type system.


I agree. I mostly meant little as in having a somewhat niche adoption due to its close relationship with iOS and Apple frameworks


I haven’t seen playdate before. Looks cool and I appreciate people doing things like this, but $200 seems like a lot! Compare to android phones for half the price that also function as phones. I realize things without mass production will be more expensive, but I wonder what part(s) the device are the biggest contributor to the price?

(Also, more to the point of the article - kudos to Swift team. A nice language I hope becomes more widespread)


I was kind of interested in the Playdate but couldn't bring myself to buy one. Last summer I stayed at my brother-in-laws place for a week and did some DIY work around his house, and while I was there played with his Playdate. Really enjoyed it, but still couldn't bring myself to "pull the trigger" on buying one. I'm really busy with work and life these days and don't often find I have time to game.

3 months later a package arrived from Playdate; as a thank you for the DIY work my BIL bought me one.

It's a very well designed and executed device, the crank handle is well used in many games, and it's nice to have a device that just does one thing and does it well. It can be a little tricky to play depending on ambient light.


Props to your BIL! You're lucky to have family like that.


I think the biggest contributors to cost are the Sharp Memory LCD screen, custom built crank, and the fact that you get 24 games included with the device. Regardless, it's absolutely worth it without a shadow of a doubt. There's nothing else like it.

Plus, it's the only way to play exclusive games of which there are many. My game YOYOZO was listed in Ars Technica's "Best Games of 2023" alongside several games by Nintendo.


Thanks for the info. I think if Playdate could be significantly cheaper without the included games, it could bring in more people who would then buy games if interested (as well as potential developers). But, I understand it’s hard to say - they need to make money on the device too.


It's a neat device but I hesitate to say it is worth it, the lack of backlit screen makes it mostly unplayable to me :/


Have you played on one? I didn’t find the lack of a backlight a problem when you’re in reasonable light.


I have one on my desk right now, and I have played it. It's just difficult for me (bad eyesight? I do wear glasses) because of the lack of backlight.


Ah cool. I messed around with this a while ago: https://github.com/ericlewis/swift-playdate


This sounds like a cute project but it's a nice tour of cross-compiling and C inter-op that proves Swift could not only be usable for myriad devices, but will likely make them much more accessible with ergonomic safe API's.

Swift's inter-op story with C now is that most things are automatic, some things are configurable, and some just not. Clang supports multiple ABIs and calling conventions, giving control over optimizations, and linkers should work when the object files are valid. But tying it all together takes some detailed work in make. So the generality of clang and the linkers makes the potential reach large, but each new target combination will require some work.

I can see how individual developers might scratch an itch, but I'd be very interested to see if platform and library providers start supporting Swift directly. A bit of configuration could lower adoption costs, increasing uptake.

But where does that happen, and could that work be shared? Apple will continue to focus on Xcode, and most of this is out of scope for the Swift Package Manager. Swift support in CMake helps at the lowest level, but there's no dominant integration platform (like Eclipse was for Java) for contributors to share work.

Sharing experience is another thing. The blog author had internal experts at Apple available, but it's something of a black art to assess compiler work-in-progress and workarounds, and particularly to assess likely progress in a company that follows the first rule of fight club. That makes a blog entry of a successful port all the more valuable!


Nice job!

Not being much of a swifty, I didn't know anything about that API Notes thing. I like it a lot!


I recently watched a neat conference presentation[0] about generating Game Boy Advance binaries using LLVM – I wonder how difficult it would be to use that ARM7TDMI toolchain with Embedded Swift.

[0]https://www.youtube.com/watch?v=Q-Woh_Uzw5g


I also created the same Break game on a Bare-metal microcontroller in pure Swift, including all the logic and draw implementations We are serious about Embedded Swift programming.

If you want to know more, plz visit my Twitter[1], or visit our website[2]

[1]https://twitter.com/madmachineio [2]https://madmachine.io


I'm interested in a performance comparison between Swift, C, Lua, Nim. The post says Swift is performant, but offers no data or reasoning to back up that claim. I'm sure it is, but it would help to see data.


I don't think the post was trying to prove that fact, just explaining a personal choice. I don't think every Rust project should have to include benchmarks to prove that Rust was the right choice.


The post stated Swift is performant, and I just wondered was that claim referring to this embedded version or was it a more general Swift assumption.

Anyway, the Playdate community has done some testing and the Swift code for the Life example, as released in the blog post, runs about 60% the speed of the C example it was based on.

So it seems the claim was an assumption that it must be performant because it's Swift, rather than the result of any comparison or testing. It looks like I was too optimistic :)


Swift can be written in many ways with different performance tradeoffs. The slower ways looks like Objective-C or functional programming. The faster ways look like ergonomic C or C++.


That's exactly it. It seems this example is not optimised in any way, so in my testing it performs worse than the C version. I'm hopeful that won't be the case for very long.


https://github.com/attractivechaos/plb2 - limited but broad comparison across a large number of languages. Swift and Nim both compare favourably to C.


Right, but that's not this specific embedded version of Swift which currently has many compromises and omissions.


Sure, the more complex language features, which those basic benchmarks aren’t really looking at.


Swift is love, Swift is life. Wonder how well it would run on the new Arduino (r4 afaik)


Wonder if Panic will switch to an LLVM-based toolchain moving forward.


Us$200 … a bit stiff.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: