@spacemario IV dipped my toe into python and a few other languages but as it stands Fuze is just the most user friendly but to be fair it is a newer tailored system as python (thonny) seems a bit dated, IV managed to make different sized game screens with varying colours but past that it's hard to translate what I'v already learnt.
I am going to invest in a newer pc and decided to take a course in Computing IT and design which would attribute towards my current sign writing qualification so it wouldn't mean shooting off in the wrong direction as far as my interests.
It's only Open university but means I can work and study, the only down side is less time to use Fuze lol..
I believe if you watch a YouTube video by the creator dani, you might understand what he means. Dani uses Unity which has a built in system like the one requested. Just make sure you watch one of his videos on ai, not the others. Hope this explains it better.
The problem I see with that is, if you only look at the for loop (without the define statements), then it looks like Lobj, Obx etc. are simple variables. There is no way to tell what any code does anymore, unless the code editor has good color coding and you're not color blind.
So it might make writing code quicker. But it will make reading code more difficult.
So in my opinion, a language change that would make your example more efficient would rather be a foreach iterator. Not that I'm expecting anything like that in Fuze, but it could look something like this:
foreach var o in objects loop
o.x += 1
o.y = cos(o.x)
o.size = o.x * o.y
By such a change, it's still clear from looking at the code, what is supposed to happen, and you don't need to think about the type of collection you're iterating over. In case of Fuze, there are only arrays, so in my opinion, a change like this doesn't need a high priority :)
I mean, I wasn't kidding about Fuze Fit Adventure 3... If we get Ring-con support I will make it.That's a promise.
Yea, just noticed 2 in the showcase. Definitely seems like a shoo-in. I'm also imagining racing games (MK8 can be played with it) or rail shooters (which arguably is what the base game is already), or some rudimentary VR-like experiences.
Thank you both for the stimulating discussion. To clarify something here - I did not say that the team are "thinking about implementing a proper file system". I said that the file system functionality will likely see some improvements in the future.
While I won't go into too much detail here, there are more considerations than just what Nintendo may or may not let us do. That certainly is one, yes. But we are still a very small team currently, and we cannot do it all at once. Patience here is much appreciated.
I like this idea. Reason being you can make notes of solutions you've done pertaining to say. "Getting keyboard intput without the input() function". The great idea for me about this though is that when it is published to the public, people can learn from your solutions and try them out for themselves. All in all, a full circle of learning.
The Map Editor is a good start, but I think a fundamental requirement would be to provide some kind of visual clue of the drawing dimensions that fit on the Switch display, especially since dimensions are not displayed in the program.
I think showing a customizable passepartout around the center of the camera view would be a useful feature. If you're making a game that runs at 960x540 resolution, you would set it to that size and it could display a rectangle representing the boundaries of your game area. The next best thing currently is to do ZL+R3 and set the camera zoom to your game resolution (if listed). Then you can see what fits on the screen at that resolution.