Community Libraries
-
@petermeisenstein I didn't say it was the best way just the easiest!
-
My view on things to consider with this:
-
Introduce tabs to the code editor, to maintain separate source files
-
Only allow imports of sources that are in your project, with the ability to "download" them into your project (locking in their version) from other projects that are on your Switch
-
Make conflicts manageable by limitation, a direction I'm thinking in:
- maybe don't allow
import
within in source that is imported itself - give imported source their own global scope (no use of global variables from the source that imports this source)
- when you import, assign the global scope of the imported source to a namespace
- maybe don't allow
One way to implement this (allowing nested imports here), would be the example below (where you would have the tabs "main", "template_menu" and "template_choices" in your project.
/// content of "template_menu" file ns choices = import("template_choices") function open(options) // although result isn't declared here, the risk of it being used globally would be limited to the template_menu scope result = choices.pick(options) return result /// content of the main program file: ns menu = import("template_menu") // will only have menu.open and menu.choices.pick loop clear() result = menu.open( menu.choices.createOptions(["Play", "Options", "Exit"]) ) print(result) update() repeat
Anyway, I'm sure there are plenty of other problems to keep in mind with a feature like this.
Also in my opinion, before allowing dependencies, you'd need better version management. This could be on project level: for example when you have shared a project, you can use a similar feature to label the current source with a version. You'd then be able to roll back to such a version of your project (maybe limit number of versions that are stored if necessary). Also it would be cool if people who have downloaded your project, would be notified that the project they have downloaded has an update (and may allow them to download major versions only, giving the developer opportunity to back-up their projects with minor versions).
The reason why I think good version management should come first, is because with the introduction of dependencies, you might get dependencies that depend on a specific version of code that might be hard to find back otherwise...
Anyway, it's a long post this way, and as I said, the things that need to be considered around these type of changes might be quite a bit more than I come up with in a forum post :)
-
-
I honestly don’t think we should go down this road.
-
This could massively increase the size of projects. Making it more complex to update or maintain dependencies. And if "bad code" gets popular, it would be hard to get rid of that.
On the other hand, by reusing code you don't need to "reinvent the wheel", and by putting it in different files, you have more focus on the relevant logic per file (less searching around for related code).
I think this is one of those things that needs to be well thought out, but adds value if it is included. I've responded with my view on it, because it's on topic, that doesn't mean that I think it should be top priority.
I'm happy with what Fuze already provides, and even if just the instabilities and inconsistencies get ironed out, that's already great. When it comes to commercial potential, I'd personally think towards supporting online multiplayer (if that would ever be possible on the Nintendo). Imagine Twich and Youtube streams where influencers can play with viewers for free using the FUZE Player....
-
I think the issue with online multiplayer has a lot to do with security. It would probably have to use p2p (peer to peer) as a server would get quickly overloaded. It seems like the kind of thing where Fuze would need to handle most of the implementation, or else people could be very vulnerable. That could even come down to just having a line of code at the beginning that says online() and then doing the code for syncing between players and that, but locking away all of the actual set up. Thats up to Fuze, but I can see nintendo not being too stoked if Fuze suddenly opens up a bunch of security vulnerabilities in the switch
-
That's true, Fuze would need to do the heavy lifting, and it would be easy to cheat if multiplayer is enabled anyway (just modify the code, right?) :P
Also I don't see support for modern technologies that would make sure everybody is in sync happening (for example: the sever decides where the players are). So with a shooting game, you'd probably have issues with disagreeing who did and didn't die.
From a Fuze user perspective, I'd imagine a simple interface like the one below, but I realize that it's not easy to provide something like that and having Nintendo to agree on it as well:
connection = connect("username") // or maybe use nintendo username automatically, combined with the game code id as the type of connection while connection.online loop // might not be online if username is taken, or if there is a network problem messages = connection.read(); // returns array of struct: [id:"other username", message: "data from other user"], connection.send("e8Q", ["other username"]) //chess move, promoting pawn to queen. "other username" would receive: [.id="username", .message="e8Q"] connection.keepAlive() // keep calling this to make sure the connection doesn't time out. repeat
-
I asked for include files on day 1...
-
@Martin Do you mean librarys or external stuff ?
-
@petermeisenstein I think that we are talking about libraries of user defined functions
-
@pianofire Yes i was wandering what he meant with include files
-
@petermeisenstein Well that is how it works in c include "filename"
-
@pianofire Ok now i understood he meant example #include <linux.kernel.cpu>
-
I meant multiple editor tabs with the ability to somehow call one from another in whatever form. Don't hold your breath, it's not likely to arrive any time soon. Same with libraries - there are more important priorities right now.
-
@Martin Ok thanks for sharing your opinion and experiences