My personal use case is for a puzzle game to provide daily challenges. Think "Wordle". It could also be used to push configuration based updates to their games, for example releasing additional levels, or tweaking game mechanics.
A single read-only URL is a solution for pushing updates or refreshing data. It is a convenience for users and developers. Strictly speaking, the same thing can basically be accomplished by downloading a new version of the game. (In your case, this would mean preparing the ~30 daily challenges for the next month, pushing an update, and then selecting the daily based on the date. Repeat every month.)
How would this be enforced?
Just have a single publicly facing API call that issues a GET request to the specified URL with preset headers. (Presumably direct calls to the non-publicly facing API will be possible for willing and able parties.)
result = getNetworkData();
I love the idea of Playdate implementing a Gopher protocol client in the SDK rather than HTTP. Gopher is extremely limited in comparison, but honestly it is perfect for the Playdate, which thrives on its quirkiness. I know at least one person at Panic (Steven F) is a huge fan of Gopher.
If you do not know of or about Gopher, this is a reasonable introduction:
I set up a Gopher server yesterday to test it out, after learning of it through one of the Panic podcasts. It falls somewhere between FTP and HTTP (at least that is how it feels to me).
4 Likes
I first learned of the World Wide Web not by hearing about it, but by stumbling across it and browsing around (via Lynx browser). Stumbled across it where? On a DEC terminal running Gopher of course! A Playdate would have been pure sci-fi to me.
2 Likes
Online games, like MMORPGs can be bery fun to play.
I am currently in the process in researching a way for two systems to communicate together without a need for Bluetooth or WiFi using the Audio Jack and a cable.
If all my plans come together nicely, I think its possible for a Playdate to connect to a PC/Mac and send data to a server to connect to another Playdate through the audio cable.
It sounds absolutely crazy. But we still need some killer apps on the Playdate that would get people more social and I seem to be on the right trail. I think?
3 Likes
Exciting @egg! I'd make a 2p game that supports this.
1 Like
Thinking out loud, could an audio cable solution allow "WAN" play, with the right weird cables/adapters and a smartphone call?
As long as you have the right setup.
Basically its just morse code being sent from a audio cable to the computer and into a server / or a Playdate.
Of course, you will need to swap the input and output in order to not mix signals.
I haven't been able to test anything just due to my limited coding experience.
( Let me remind some peeps that pre-public Playdate SDK has an example pdx for networking of many playdates / people.
I really liked the graphics in that as I found them to be very cute.
Its very possible in the future to see networking on Playdate such as local and online play. )
1 Like
Video Example
Morse code could be the best and most effective option in terms of usability and customization. Even SquidGod made a game about it (The Squid), which is where I got my inspiration from for my projects.
I just wonder about error prevention between two Playdates.
Hi all,
If/when we get support for networking would it then make sense to support Bonjour to discover other players on the LAN? Maybe even interact with other devives (same game running on a phone or desktop computer).
2 Likes
I would love any form of local internet. Even with the most limited of cases.
The Playdate isn't supposed to replace current Internet but reinvent old. The Nintendo DS is one of my favorite use cases of local network play where the device creates its own network for other devices to connect to. Suitcase / Streetpass mode is another mode I absolutely want to return on Playdate but I am worried about battery consumption and the fact there isn't many Playdates out there. Whatever we get I am absolutely taking advantage of it in some form or another.
+1, crossing my fingers for this one.
1 Like
I'm interested in same-network communication. i.e. communication with other devices on the same local wifi network, including PC and mobile.
I understand the security concerns with opening up the device to the internet at large, but local communication seems like a fairly tame application.
1 Like
In lieu of live networking in-game, a way to access the /Data/<< my game >> directory through Sideload on the webpage would open up a whole host of options.
The device could "call home" and sync these directories. (cloud backup games saves??)
If there were a 'shareable' URL scheme for this it could be used to share user created content like custom levels via QR code (boogie loops track sharing?).
Personally, I want to make a NSF (NES Sound File) Jukebox app and the ability to load <1MB files from a network source would be a game changer.
3 Likes
+1 for networking access. WRT liability I would propose that this function be opt-in on an app basis. The user would get warnings and agree to hold Panic harmless. This option would open up some fun / interesting options for games / apps.
2 Likes
+1 for networking. Just throwing out what I'd like to see:
I like the idea of a per-app switch for enabling network access to make the user aware of it. Something like requiresNetwork=true in the pdxinfo in order for the network functionality to be available via code. And then inform the user before app launch that it requires network access. (maybe with a selection option to not show the warning again for this app)
SDK wise I'd love HTTP(S) functionality or even low level TCP/UDP access.
[EDIT] As a specific use case I would love to write a Playdate client for https://spacetraders.io/
3 Likes
that is neat, and gave me the random idea of implementing a ChatGPT plugin since they provide an openapi spec!
1 Like
This would be incredibly nice to have. Multiplayer sounds fun!
As for security, I like the suggestion of a "microphone enabled" indicator enforced by the system, and perhaps some permission system that makes the user aware on startup which features (e.g. networking and audio) the game uses.
Let the user make the decision on whether they're fine with the consequences, like Apple and Google do 
I would also love network access!