MicroStudio now supports microScript, Python, JavaScript and Lua(microstudio.dev)
microstudio.dev
MicroStudio now supports microScript, Python, JavaScript and Lua
https://microstudio.dev/community/news/microstudio-now-supports-4-programming-languages-microscript-python-javascript-and-lua/254/
44 comments
If it supports Lua you could always use Fennel, which looks close enough
Where is the runtime for microScript -- is it in a separate GitHub repo or buried in the main one?
Nice!
But why is text selection disabled on the homepage?
But why is text selection disabled on the homepage?
I just fixed it! It was disabled globally because text selection causes different problems with clickable / drawable / draggable parts of the UI. microStudio works as a single-page app.
Text selection is now enabled on the "home page" content.
Text selection is now enabled on the "home page" content.
Thanks! I like to bookmark interesting pages in a notes app, so usually I copy and paste some text from them to go with the link
Yeah, it triggers me since I need to select the text to then have it read to me by my TTS. I blame designers (and sometimes lazy devs), so anyone that does this care to explain why? AFAIK you should only disable text in HTML in your custom widget like if you create your own button or menu.
it's got this css:
html,body {
user-select: none;
}Makes me remember all those blogs disabling text selection to prevent people from "stealing" their work. Which is just terrible UX for people using it for reading, I generally just exit the website immediately.
Please, never do that.
Please, never do that.
yeah I turned that off in dev tools, but why author it that way in the first place, what possible motivation...?
Possibly to prevent fast clicks being registered as double-click user select, but with a too general a target.
Very happy with the development of the engine. Maybe one day it will overtake Unity
If you want something that is trying to take on Unity, I think Godot[1] is the stronger contender. This project seems really cool, but like a different thing.
[1] https://godotengine.org/
[1] https://godotengine.org/
I haven't heard of it before. It looks great! I will definitely check this out with my 12y son.
Just want to say the language looks beautifully simple.
I love how you can move a function definition from a class to outside of a class or even into an object “literal” without breaking syntax.
And same with variables, you can restructure it from a global into a class property or as a property of an object literal.
It looks even more intuitive and forgiving than lua and lua was already a joy
I love how you can move a function definition from a class to outside of a class or even into an object “literal” without breaking syntax.
And same with variables, you can restructure it from a global into a class property or as a property of an object literal.
It looks even more intuitive and forgiving than lua and lua was already a joy
> I love how you can move a function definition from a class to outside of a class or even into an object “literal” without breaking syntax.
Actually more important is, that you can move them into a class of object literal. And way more languages should be designed with that in mind.
> And same with variables, you can restructure it from a global into a class property or as a property of an object literal.
This allows you to just start to write code as a script, and then effortlessly partition it into functions, classes and files as need arises.
Another thing I'd like to see more in languages is keeping consistent interface across various data structures. You should be able to swap out array for a set, hash table, or even something weird without rewriting half of your code that touches it.
Actually more important is, that you can move them into a class of object literal. And way more languages should be designed with that in mind.
> And same with variables, you can restructure it from a global into a class property or as a property of an object literal.
This allows you to just start to write code as a script, and then effortlessly partition it into functions, classes and files as need arises.
Another thing I'd like to see more in languages is keeping consistent interface across various data structures. You should be able to swap out array for a set, hash table, or even something weird without rewriting half of your code that touches it.
The docs, for anyone wondering: https://microstudio.dev/documentation/
Thank you for the link!
Yes and if you click “microScript programming” in the menu you are taken to the language itself.
Didn’t find a way to link to that part but it’s just one click away.
Yes and if you click “microScript programming” in the menu you are taken to the language itself.
Didn’t find a way to link to that part but it’s just one click away.
Now I’m curious how a game engine can handle the performance penalty of using a dynamic typed language
I'm going to ask a different question: so what if it doesn't handle it? Some of the hardware resources would be spent on dynamic shenanigans instead of the actual game content. In contrast a game running on the same hardware but implemented in C++ would be able to handle/offer more of the content of the game.
But then again 5 years ago hardware was worse; 10 years ago even worse; 20 etc etc. Games had less content but there were still good games, as good as modern ones. Game enjoyability doesn't depend that much on the scale of its content. If a dynamic language pulls the resources down to what they were 5-10 years ago you can still make enjoyable games.
But then again 5 years ago hardware was worse; 10 years ago even worse; 20 etc etc. Games had less content but there were still good games, as good as modern ones. Game enjoyability doesn't depend that much on the scale of its content. If a dynamic language pulls the resources down to what they were 5-10 years ago you can still make enjoyable games.
It's a few things really, dynamic languages have been used for a very long time. Even early computers had a bunch of games that ran on interpreters.
* Computers are really, really fast. If you're not deliberately or unintentionally slowing them down even a dynamic language can do an awful lot of work.
* JIT compilation is really good for a couple of languages. LuaJIT has been a popular embedded language for games for that reason for a while. JS JITs are also pretty incredible.
* They're most commonly used for gameplay code which tends not to be the performance bottleneck of a game engine anyway. Where it is you usually have great interop and just rewrite the offending code in the native language.
The interesting choice here is to run interpreter(s) on top of what seems to be a JavaScript (compiled from CoffeeScript) based engine. Although it does look like they want to translate the microScript code to JS.
* Computers are really, really fast. If you're not deliberately or unintentionally slowing them down even a dynamic language can do an awful lot of work.
* JIT compilation is really good for a couple of languages. LuaJIT has been a popular embedded language for games for that reason for a while. JS JITs are also pretty incredible.
* They're most commonly used for gameplay code which tends not to be the performance bottleneck of a game engine anyway. Where it is you usually have great interop and just rewrite the offending code in the native language.
The interesting choice here is to run interpreter(s) on top of what seems to be a JavaScript (compiled from CoffeeScript) based engine. Although it does look like they want to translate the microScript code to JS.
For game engines, point #3 is the most important. JIT compilers tend to do better when the entire codebase is in the same language, because they can't optimize code that is written in C/C++, and have a harder time optimizing code that calls C/C++. However, this is exactly the sort of thing at the core of a game engine.
Another thing is that when making games a scripting language can be easier to use by members of the team who may be good at game design but not good at programming in C++. It is also convenient to be able to edit the scripts without needing to recompile and restart the game.
In the case of Lua, one thing that makes it popular for games is that it is very small and also easy to embed. It was designed for ease of embedding.
Another thing is that when making games a scripting language can be easier to use by members of the team who may be good at game design but not good at programming in C++. It is also convenient to be able to edit the scripts without needing to recompile and restart the game.
In the case of Lua, one thing that makes it popular for games is that it is very small and also easy to embed. It was designed for ease of embedding.
Judging by Godot and the few other dynamically typed languages and how performance isn't much of a concern with them, apparently its not much of a penalty.
That being said, for peace of mind, I do wish engines like Godot had chosen a strongly typed language. I use Godot myself and much prefer it to other engines I've used, but I can't shake the feeling the GDScript sacrifices performance for ease of learning, even if it happens to not be true. I know theres Godot C# as well but that still doesn't feel like first class supported, though maybe I'm wrong
That being said, for peace of mind, I do wish engines like Godot had chosen a strongly typed language. I use Godot myself and much prefer it to other engines I've used, but I can't shake the feeling the GDScript sacrifices performance for ease of learning, even if it happens to not be true. I know theres Godot C# as well but that still doesn't feel like first class supported, though maybe I'm wrong
let me tell you about how we used to type in listings from magazines back in the 80s
Lua has been used in games for decades
Also, I didn't think "In microStudio, the core language is JavaScript and JavaScript in the browser is insanely fast." statements like this were true, but hey.
> “microStudio is a free game engine online."
It's also free software (MIT License) and available offline. https://github.com/pmgl/microstudio/releases
So less like Pico-8 or TIC-80, and more like Quadplay?
https://github.com/morgan3d/quadplay
https://morgan3d.github.io/quadplay/console/quadplay.html?ID...
https://morgan3d.github.io/quadplay/doc/manual.md.html
https://github.com/morgan3d/quadplay
https://morgan3d.github.io/quadplay/console/quadplay.html?ID...
https://morgan3d.github.io/quadplay/doc/manual.md.html
TIC-80 is also libre, though precompiled "Pro" binaries aren't gratis.
https://github.com/nesbox/TIC-80/wiki#pro-version
Edit: actually, reading https://github.com/morgan3d/quadplay/blob/main/LICENSE.md it looks like it's only partially free (not unlike markdeep, another of the author's projects).
https://github.com/nesbox/TIC-80/wiki#pro-version
Edit: actually, reading https://github.com/morgan3d/quadplay/blob/main/LICENSE.md it looks like it's only partially free (not unlike markdeep, another of the author's projects).
Thank you for this. I was frustrated to scan the linked page and still not know what it was.
But I will give them credit: Clicking the top-left icon immediately brings you to a page with that clear tagline and some nice images.
But I will give them credit: Clicking the top-left icon immediately brings you to a page with that clear tagline and some nice images.
Is it faster than LuaJIT?
Can anyone familiar with it give a TL;DR on how it compares to Processing?
Both are FOSS environments that are suitable for quick graphics programming in a minimal language.
Both are FOSS environments that are suitable for quick graphics programming in a minimal language.
Processing is a framework. This is a game engine with an IDE, sprite editing, etc.
I am only barely familiar with both MicroStudio and Processing so probably not the most reliable source, but to my knowledge Processing is for graphics programming whereas Microstudio is for games programming.
Of course theres a lot of overlap between the two, but I'd guess Processing is more powerful (or at least, more easily powerful) for pure graphics rendering than MicroStudio, but MicroStudio can do a lot more (or again, at least a lot more easily), like handling inputs and playing sounds and so on
Of course theres a lot of overlap between the two, but I'd guess Processing is more powerful (or at least, more easily powerful) for pure graphics rendering than MicroStudio, but MicroStudio can do a lot more (or again, at least a lot more easily), like handling inputs and playing sounds and so on
A nice, clean, easy to use game/app development environment that is both online and downloadable as a stand alone program.
This reminds me a bit of PICO-8 but with less restrictions and more languages.
But it's a bit like Love2D with a few language options and batteries included (sprites//etc.)
But it's a bit like Love2D with a few language options and batteries included (sprites//etc.)
I like how they haven't done the blocky "retro font" for their IDE that other such systems like Pico-8 and Tic-80 have. Which actually aren't even historically accurate -- 8-bit computers used reasonable fonts not that different from current monospaced ones.
Pico8 is working with 128x128 pixels, so their choices are limited...
Edit: Working with 128x128 on purpose, for nostalgia purposes. It's a sort of contrived historical machine they are pretending existed. A slick IDE wouldn't fit with the project's purpose. Though you can edit the programs with any external editor you want.
Edit: Working with 128x128 on purpose, for nostalgia purposes. It's a sort of contrived historical machine they are pretending existed. A slick IDE wouldn't fit with the project's purpose. Though you can edit the programs with any external editor you want.
This looks great - I have been looking for a decent online "IDE" for scratching that game development itch for a little while.
One question though if the author is here, looking at the documentation for javascript, it seems very short. Is it all "backwards compatible" (wrong term I know) with microcode? I.e. does the API reference apply as-is to javascript without any other changes? Or perhaps there are new documentation changes pending?
One question though if the author is here, looking at the documentation for javascript, it seems very short. Is it all "backwards compatible" (wrong term I know) with microcode? I.e. does the API reference apply as-is to javascript without any other changes? Or perhaps there are new documentation changes pending?
Author here :-) You access the exact same APIs with all 4 languages. In Python and Lua there are a few differences in how you should call an object method or how you can safely access user input properties (they are detailed in the Python and Lua tabs of the documentation). In JavaScript the API is 100% used the same way.
Can I build a robot with this?
Is it difficult to add new languages? I'd love to see Clojurescript support. :)