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