Maybe a bit of a strange question, but sharing progress gifs of my game project in some channels has folks wanting it for a steam/PC release. My thinking so for is i'd probably need to re-write it in an entirely different stack. Given the license agreement states we can't distribute the SDK, I imagine a full re-write would be required. But curious if this is something anyone else has approached.
2 Likes
Linked below, but tl;dr is: Releasing via simulator isnt expressly prohibited, but is advised against. Lua games should port to Love2d, C games should port to SDL2. Both should be a relatively low amount of work, depending on how much of the SDK utilized.
It got discussed in this thread (Distributing Playdate games to players without a Playdate)
2 Likes
Interesting thank you. I had done some searching, but didn't find that post. I could see it being doable if I were to segment off playdate api calls in their own layer, so i could have the majority of the code base organized in a platform agnostic way.
1 Like
I'm aware of a couple of efforts/approaches of people writing Lua that can run on Playdate and PC via Love2D.
There's Playbit - a framework for creating cross-platform Playdate games
And Donald Hays (aka Dovuro) wrote a sample game that would run as Playdate or Love2D. I have his permission to rework that into a small test game that is sharable (currently it uses copyright ripped assets) "soon".
This is something i want to do with one of my small games and also something we want to look into for Sparrow Solitaire after final version is done.
3 Likes
porting C to SDL2 might be trickier than it sounds, every game on the playdate uses font's not all fonts have TTF counterparts so how would one use the font files themselves in sdl2, it means you'd have to somehow implement same functionality as the SDK does for the font files.
Another thing i don't immediatly see easily done is the use of Push and popcontext functions, yes they set a target image to draw on which is easily done in sdl2 but it actually does more than just that in the sdk, it also remembers specific "settings" currently in use like for example which font (and much more) which gets restored on popcontext, thats also something you'd have to completely replicate and it is not very well written in the api documentation what exactly gets remembered by calling these functions (like it says graphics context is pushed to stack and new one is created)
The 1st thing about fonts you'll run into with any game not having ttf font counterparts, the 2nd thing less so i guess. But porting to SDL2 is imo not as straightforward as it seems to be (depending on the game)
fwiw I don't think its fair to say every game uses fonts (mine doesnt, it draws text using sprites directly)
and while not all fonts have ttf counterparts, they certainly have suitable substitutes.
re: push/pop I havent used them so cant really comment
ah was not aware of that, that solve's at least the font issues then as one could use SDL_TTF. But the push and popcontext also saving and restoring the graphics context could still pose a problem as you'd have to replicate it then.
I somehow though a replacement sdk library that would use SDL2 so we can just drop our sources inside it and the game would compile and run but it can be a lot of work to get that going. I actually started on it once but almost imediatly stopped after seeing how much work it would be to get it going also not sure if anyone else attempted to (fully) reproduce the same functionality from the sdk with same / simular functions & parameters so it could work as a drop in replacement. But yeah if doing ports milage can vary but you also get more options than trying to create a drop in replacement library