I just downloaded the SDK today and started reading through the docs. I noticed the JSON support and that got me thinking about web-connected games. I don't see a way to make HTTP requests. I was thinking about making a web-connected game with a leaderboard and this functionality would be pretty sweet if it doesn't exist today.
I was excited to build a reader app for a website of mine (think a hacker news client for example) but was sad when I saw network requests are only available in the simulator.
If it is a privacy issue - I'd be totally fine with it as an option you have to turn on, or even something you can only use on games you make yourself... I just really want to be able to display data from the internet on my Playdate.
Me too! I’ve been entertaining a podcast app and would need a network api. I can understand not adding it for privacy, performance, and battery life though.
I've got some ideas that could be very cool but it kind of requires some sort of network functionality. Preferably something similar to tcp/ip so the playdate could communicate with servers that support tcp/ip.
You could use the /Data folder for that. It's a little janky, but it works. Especially since it'll be a little easier to share whatever puzzle files you have, WarioWare: D.I.Y. Showcase style
I get the impression there's some specific reason networking isn't already provided, and I doubt it'd be because of technical constraints. Could be related to security perhaps, but that's speculation.
It's totally fine if Panic doesn't want to allow networking for whatever reason. If that's the case, I feel like a public statement about it would be appropriate, since otherwise requests for it will be a constant thing.
Also +1 for network functionality. The Playdate is great because it keeps development barriers low. Networked games are a big deal.
Perhaps network permissions make sense? Obviously, any networked application is going to be sending metrics to the server. I think the solution is to make users aware of which apps are networked so that they can decide if they are comfortable with any potential data exchange. If a seemingly offline game accesses the network for no good reason, that is a red flag.
+1 for Network support - I like the SDK especially the c part and would like to get network access in order to create a multiplayer game for the platform - as this would enhance the platform with some social factor. I understand security but shouldnt be that bad.
We want to prevent, say, your Playdate from recording audio of you, then sending it off to some unknown server
I don't think you should worry about that as much if it means we're going to lose out on very useful functionality.
The only way you're going to be able to deal with that is monitor an app if it has both high microphone usage and high transmit bandwidth, then report that to the user
Or simply make us define permissions in the pdx like android, warn us on first boot after installation or an update that changes the permission. Similar to android
I don't think you should worry about that as much if it means we're going to lose out on very useful functionality.
That's an easy thing to say when you're not the one looking down the business end of a liability lawsuit. Most jurisdictions have pretty strict regulations regarding privacy and surveillance. If Playdate is used as the vector for some nefarious deed and Panic doesn't have all their ducks in a row, they could be prosecuted for negligence or worse. Telling them they shouldn't worry about it seems a bit short-sighted.
I'm prepared to go along with the inconvenience of my Playdate software being offline-only. I'm grateful for what Panic has been able to do with the product so far, and I believe in their mission with the device. If they're not comfortable opening up networking access for the time being, then that's fine by me.
Given how niche this device is and apps don't run in the background, it's a terrible attack vector compared to something like a cell phone which everyone owns. Hell, more people own PSP gos and they already have built in mics, internet access, and if they wanted to they can make code that runs in the background. This is a niche within a niche within a niche.
I can see the recording concern. Maybe apps could be allowed to choose whether to support either mic OR networking, but not both? (And not allowed to change with an update unless its user data is wiped?)
Put me down on the list of people that'd love network-access! I'd already be quite happy with some sort of HTTP(S) requests and such- but socket functionality would be fantastic!
If access within to the Wi-Fi hardware would be available within C, I'd be happy to develop some basic socket functionality myself and open source it!
I think a limited gameplay-driven networking API would be cool. For example, I can only set simple key-value types and the values can never be user-generated strings (so no chance of profanity etc.). A way to link Playdates by keys would be cool, so I can e.g. ask my friend for his code, enter it on mine, then he confirms he wants to play with me, then we could start having shared key-values (e.g. my position and his position).
I feel like limitations are a fundamental part of Playdate, and taking the same fun-driven, "constraints breed creativity" look at networking would be in line with that.
Ideally, we can host our little key-value servers ourselves so that when the Playdate inevitably shuts down, we can keep our online experiences alive. It could be the job of the Playdate API to do anonymization/encryption/etc. to protect user privacy without sacrificing functionality.
Another idea is limiting it to LAN only, similar to how you used to have Game Boys with connection cables to play with your siblings/friends. Playdate LAN parties sound fun, and have very little security and privacy concerns since you're face-to-face with the other person, essentially.