Foraging into embedded lands - (the path to) writing Playdate games in Scala

Let's write a game in Scala Native, for Playdate (https://play.date)!

It's a tiny console with very limited hardware and a 1-bit black&white screen. Having a well-documented C API, it's a perfect candidate for playing with using Scala Native! What could go wrong...

Turns out, it's quite challenging, especially for someone mostly working in the safe haven of the JVM.

In this talk, I'll share with you:
- What I've learned about Scala Native as part of this journey
- Problems I've stumbled upon on my way to run SN on an unsupported platform
- A demo on the actual device.

Transcript

1. Jakub Kozłowski | Scalar Conf | 22.03.2024 Foraging into embedded lands (The path to) writing Playdate games with Scala
2. Who am I? • Technical team lead @ • OSS contributor, smithy4s maintainer • Working on Scala/Smithy tooling on a daily basis • Spending most of my free time dealing with this demon This was in June, she's so much bigger now 😭
3. ... • I'm also working on a game about my pup's eating habits • ...but it's in C so I won't talk about that today 💀
4. Part I: Prelude
5. What is the Playdate?
7. The Playdate • Small, handheld game console • 16MB RAM! • 168MHz 32-bit ARM CPU! • 400x240 1-bit screen! • No backlight! • O ff icial SDK!
8. Making games for the Playdate • O ff icially: C or Lua API • Uno ff icially: Rust, Swift, C++, Fortran, Nim, Typescript, D...
10. Mixing Scala and the Playdate (Why this talk exists)
11. Why use Scala? • Typed functional programming • ADTs, pattern matching, lambdas, collections • GC • Because I like a challenge! (For game development)
12. Now it's time to analyze our options, right? • Consider GraalVM Native Image, or other Embedded Java implementations? • Nah, I just want an excuse to use Scala Native.
14. Build target choice Can be executed directly Needs to be loaded at runtime Baked into another library / application at linking (build) time
15. Which one shouuld we use? • PD games are built as dynamic libraries • Dependencies on other dylibs not allowed • To call Scala, you need to call ScalaNativeInit() f irst • Thus, we'll need a statically linked SN library
16. Part II: The actual devil
17. The plan 1. Generate API/SDK bindings 2. Run a Scala game in the simulator 3. Run a Scala game on the device, no GC 4. Add GC 5. Move on to the fun part
18. Step 1: bindings • Using sn-bindgen • 🙂 Mostly a breeze • 😐 A couple unnamed structs/unions, simple f ind/ replace to resolve that • 😕 no continuous updates because of the manual step
19. Step 2: run in simulator • Pladate SDK includes a simulator (not an emulator) • Runs natively on your platform • On Mac, this is built purely with Clang! • Device builds use arm- speci f ic GCC • Built and ran Scala in one day
20. Step 3: run on the device for 32-bit support
21. Step 3: run on the device
23. Step 3.1: Understanding what's wrong Build steps of a Scala Native program (vastly simpli f ied)
24. Step 3.1: Understanding what's wrong • Main sources of errors • Atomics • Delimited continuations support • Stack traces • POSIX APIs • Networking • cwd/pwd/uid • threads • C++ std APIs • GC
25. Step 3.2: f ixing the errors
26. Step 3.2: f ixing the errors • Atomics • single-threaded environment, shouldn't be necessary (replace with normal swaps and assume it's successful f irst time)
27. Atomics - ✅
28. Step 3.2: f ixing the errors • Delimited continuations • Just commented out
29. Step 3.2: f ixing the errors • Stack traces • I decided to ignore them for my own sanity • Stub out • As a result, any stack traces I see will be useless!
30. Step 3.2: f ixing the errors • POSIX APIs • Networking: not used, remove/stub out x20
31. Step 3.2: f ixing the errors • POSIX APIs • Cwd/pwd/uid: used when System is initialized. Hardcoded arbitrary values
32. Step 3.2: f ixing the errors • POSIX APIs: threads! • Technically, we're single threaded so shouldn't need it... • But MainThread needs to be initialized on startup, e.g. for ThreadLocals which are used even by decoding bytes to String
33. Step 3.2: f ixing the errors • POSIX APIs: threads! • MainThread: hardcode identi f ier (it's not gonna be used anyway) • Platform-speci f ic Thread implementation (WindowsThread/ PosixThread), methods can be stubbed as we're not using them
34. Step 3.2: f ixing the errors • C++ APIs • SN uses some C++ types (exceptions) • PD SDK doesn't support C++ by default (unde f ined symbols) • For speed, started from playdate- cpp and backtracked to "pure" C with stubs for C++ symbols courtesy of the project • It worked pretty well!
35. Step 3.2: f ixing the errors
36. Step 3.2: f ixing the errors
37. Step 4: GC (long story short) • GC was being a problem • Wojciech Mazur agreed to pair on this, he quickly found the culprit(s) in my changes. • Problem: I had replaced the missing mmap with malloc, meaning the GC couldn't assume allocated memory was contiguous. Solution: allocate all memory in one go. • He also made f ixes to 32-bit GC in the upstream! That f ixed pretty much everything. • Massive thanks, Wojtek!
38. Part III: Finale
39. Scala gamedev on the Playdate
40. Demo time! I hope you've seen Michał's talk...
41. I also live in Wrocław And trams are only one of our problems
42. Demo
43. Scala dev on PD: basic idea • build a datatype that describes the screen state / events in "game code" • Interpret to side e ff ects in "library code"
44. Scala dev on PD: implementation • Split out state updates from rendering • Heavily inspired by Indigo / Tyrian / the elm architecture • No abstraction on top, to allow quick experimentation
45. Scala dev on PD: implementation • All functions receive an immutable game context
46. Scala dev on PD: init • Init returns a Resource, similar to Cats E ff ect but synchronous • Composes monadically,gets allocated once at startup and cleaned up at shutdown • Haven't needed dynamic resource allocation yet, but I'm looking forward to exploring that space functionally! • Assets are stored in game state, as pointers. Could easily be hidden behind opaque types
47. Scala dev on PD: update • Update receives the previous state and the game context • State directly stores events, so update has to clear them by itself • Events are added as part of the update sub-steps
48. Scala dev on PD: render • Render receives the state and returns a Render • Just a data structure • (for the most part) • Events such as playing sounds have to be turned into a Render explicitly by render code
49. Roadmap • Upstreaming patches to Scala Native • One day, hoping to run without a fork • Cleaning up the build process to remove playdate-cpp • Packaging everything in a library and optional sbt plugin • Expanding and publishing the game
50. Summary
51. I was (still am) very new to this • I only had surface-level experience with Scala Native before • Had to learn a lot of new tools and their f lags (clang, ld, objdump, readelf) • Wouldn't have made it if not for the help of many amazing people (SN and Panic side)
52. My takeaways • Sometimes there's only one way to f ind out if you can: try • Don't be afraid to ask for help • You don't have to be an expert in XYZ to make use of XYZ in a unique and novel way
53. Links • Slides/contact/YouTube: linktr.ee/kubukoz • Playdate: https://play.date • Scala + PD: https:// devforum.play.date/t/scala- native-on-the-playdate/15814