Community Libraries

[PB____]

In my opinion, this is the best idea I've heard from you so far. You're not the first to mention it, but it's a good idea non the less :)

But for the moment, it might be good to know, that it's possible to copy and paste code between projects. So if functions are shared via a project, you can copy them into your program :) I would agree that is not ideal, but for now it's what we have, so I thought that info was worth sharing.

[petermeisenstein]

@PB____ I hope you guys understood what i meant. But sure you can copy them but why you should copy the stuff always if you could import the entire "framework".I mean It also would make the code in the projects smaller.But if you would share a programm they maybe had to deal with dependecies.Or maybe it would be nice to have the "frameworks" in the assets.I mean the place where you can get all the sounds i think you know what i mean

[pianofire]

I think that libraries are a good idea too. I think that the main issue is around sharing. At the moment the projects are self contained. All of the user created assets are included the project and all of the built in assets are common to everyone so it is easy to share a program with anyone. If you are referencing an external library then that needs to be shared as well and then you get into the whole issue of library versions. I am not saying that it is impossible just tricky.

[petermeisenstein]

@pianofire Especially if you have a librarie who then is imported by another librarie.But it would make fuze on the one hand a bit more smaller but on the other hand there is the probleme with dependencies.But I mean its maybe not the best way to always copy entire code.

[pianofire]

@petermeisenstein I didn't say it was the best way just the easiest!

[PB____]

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

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 :)

[PickleCatStars]

I honestly don’t think we should go down this road.

[PB____]

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....

[Retrocade_media]

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

[PB____]

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

[Martin]

I asked for include files on day 1...

[petermeisenstein]

@Martin Do you mean librarys or external stuff ?

[pianofire]

@petermeisenstein I think that we are talking about libraries of user defined functions

[petermeisenstein]

@pianofire Yes i was wandering what he meant with include files

[pianofire]

@petermeisenstein Well that is how it works in c include "filename"

[petermeisenstein]

@pianofire Ok now i understood he meant example #include <linux.kernel.cpu>

[Martin]

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.

[petermeisenstein]

@Martin Ok thanks for sharing your opinion and experiences