MicroStudio now supports microScript, Python, JavaScript and Lua

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.

The docs, for anyone wondering: https://microstudio.dev/documentation/

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

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.

It's also free software (MIT License) and available offline. https://github.com/pmgl/microstudio/releases

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.

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.

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.

let me tell you about how we used to type in listings from magazines back in the 80s

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.

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

Lua has been used in games for decades

If it supports Lua you could always use Fennel, which looks close enough

it's got this css:

    html,body {
        user-select: none;
    }

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.

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.

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

Processing is a framework. This is a game engine with an IDE, sprite editing, etc.

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/