DEV Community: JoeStrout

The Mini Micro Desktop GUI

JoeStrout — Wed, 01 Jul 2026 23:26:19 +0000

https://miniscript.org/MiniMicro is a virtual home computer with a primarily command-line interface. It boots into a prompt with a friendly blinking cursor, where you can type MiniScript commands or code to navigate around the system and get things done.

But, among the demos in the /sys/demo directory is a program called desktop. You can run it from there like any other demo, or you can use the convenient desktop function, built right in as one of the globals defined in /sys/startup.ms. Just type:

desktop

and Mini Micro will load up the desktop GUI (graphical user interface)!

The initial state has one window open, showing the mounted disks -- in my case that is /sys, /usr, and /usr2. You can drag the window around by any part of the gray border, except the textured lower-right corner, which stretches the window out. You can double-click folders to open them in new windows:

Power-user Tip

If you hold the Alt/Option key while double-clicking a folder, it will simultaneously open that folder and close the previous window. This is known as "Tunneling".

Scrollbars appear on disk/folder windows, which can be used to scroll around the files therein. You can double-click some files (for examples, pictures and text files) to preview them with the view command, or double-click MiniScript files to run them. The desktop acts as a shell, so when the program exits normally, the desktop should reappear. If the program aborts due to an error, or you press Control-C, then you can type exit to return to the desktop (or just use the desktop command again).

The File menu has three commands, all functional: New Window, Close Window, and Exit to Shell (which really means, exit to the standard command-line prompt). Close Window closes the frontmost window; you can also do that from the keyboard by pressing the W key.

The Window menu also works, and provides quick access to any of the windows you have open.

And that's about it. /sys/demo/desktop is more of a demo than a fully functional GUI. But maybe, in Mini Micro 2.0, it could be.

A fully functional desktop?

I have big plans for Mini Micro 2.0... probably too big, if I'm being honest. But among them is the idea of turning this demo into a proper, full-fledge desktop environment you can actually use to browse and manage your files. GitHub issue #61 is all about this possibility, which would include ways to move/rename files, desk accessories you could add to or replace yourself, etc.

But what do you think? Is this worth spending time on, or would you rather use the command line anyway? And if you do want to spend significant time in the desktop environment, what features are most important to you?

Let us know in the comments below, or chime in on on GitHub. I can't wait to hear your thoughts!

MiniScript Weekly News — June 25, 2026

JoeStrout — Thu, 25 Jun 2026 20:50:45 +0000

Development Updates

MiniScript 2 kept moving fast this week, with Preview 5 now available: https://github.com/JoeStrout/miniscript2/releases/tag/v2.0-preview-5. Joe has been polishing error handling, tightening up stack traces, and adding a key module for console input along the way. If you’ve been testing the previews, now’s a great time to keep poking at edge cases and reporting what you find.

A big performance highlight landed with computed lists, which make things like range(...) and list repetition much faster without changing how they behave in normal code. Joe also wrote up the idea in a new Dev.to post: Computed Lists in MiniScript 2.

The key module has landed for console apps too, with .available and .get mimicking their behavior in Mini Micro. That should open the door for more interactive command-line MiniScript tools and games.

Community Projects

Congratulations to Venti for shipping a tutorial update to their game, Observe. It now teaches MiniScript in-game, which is a fantastic way to bring new players into the community while showing off what can be built with the language.

maho_citrus shared Regicide.ms-unofficial, a MiniScript take on the card game Regicide. Joe immediately recognized it as a neat find and even suggested a Mini Micro GUI version—great encouragement all around.

Show and Tell

In #mini-micro, Trey Tomes showed off progress on his SVG renderer, which now handles the <animate> tag: demo/constellation2.svg. It’s a lovely example of experimentation leading to something genuinely useful and expressive.

Meanwhile shellrider has been pushing on 3D rendering experiments, adding a z-buffer and intersecting triangles. Joe chimed in with encouragement and a bit of nostalgia about older software renderers, which feels very on-brand for this community.

Discussion Highlights

There was a lively thread around the new MiniScript 2 previews, including testing on Windows and Linux, stack traces, ANSI terminal behavior, and consistency across builds. Community testing quickly found and helped fix a few early crashes, which is exactly the kind of collaboration that makes preview releases so valuable.

Joe also shared that MiniScript 2 is coming along well for embedding, but he’s recommending a little patience before others start integrating it heavily. In the meantime, he’s working toward a smoother path for raylib-miniscript and other targets, including better build support and more portable tooling.

Thanks for reading, and thanks to everyone sharing code, tests, ideas, and projects. See you next week!

Upcoming Game Jams

These upcoming jams look like a great fit for Mini Micro:

The 52 Card Pickup Jam #1 (starts 2026-06-29 11:00:00) — A perfect excuse to build a stylish card game or clever twist on classic decks, with plenty of room for polished visuals, sound, and inventive mechanics.
KILL YOUR DARLINGS Mini Jam No. 1 (starts 2026-06-26 05:01:00) — A perfect anti-scope-creep jam that celebrates tiny, finished, weirdly personal projects over polish—ideal for making something bold, simple, and delightfully unexpected in just three days.
One Game A Week Jam #8 (starts 2026-06-29 16:00:00) — A fast, small-scope jam built around clever puzzle design and unusual weekly prompts, perfect for making a polished retro-style brainteaser with a striking mirror-and-path twist.
Mini Jame Gam #56 (starts 2026-06-26 11:00:00) — A beginner-friendly jam with a flexible theme, a required special object, and a short prototype-friendly format makes this a great place to build something creative, polished, and fun.
Fake Update Jam (starts 2026-06-29 11:00:00) — A delightfully meta jam where the game itself can pretend to boot, patch, glitch, and rewrite its own rules—perfect for inventive UI tricks, fake system screens, and story-driven surprises.

Computed Lists in MiniScript 2

JoeStrout — Wed, 24 Jun 2026 22:39:19 +0000

Progress on MiniScript 2 has been rapid lately, and it's now in the "final polish" stage. Today that included adding a cool new feature, an optimization that many users will never consciously notice, but which will be quietly improving things in almost every MiniScript program. This feature is computed lists.

Computed What, Now?

Here's the issue we set out to solve: a for loop in MiniScript must iterate over a list, string, or map; and very often, that's a list that comes from the range function. Here's a typical example:

sum = 0
for i in range(1000000)
  sum += i
end for

That range function, until today, would allocate a million-and-one-element list and store the numbers from 1 million down to zero in it, just so we can assign each number to i in turn. And then it would release that list, to be garbage collected at some point. This is a lot of extra work that we really didn't need to do. Instead of storing all those numbers, we could instead just store the information we need to compute any element on demand. This saves a ton of allocation and deallocation, and in many cases (like when you bail out of your loop early) it saves computation too.

Python faced the same problem, and chose (starting with Python 3.0) to make range return an iterable rather than a list. That's fine for cases like the above, but in cases where you actually needed a list, you have to cast it through the list() function to get one. This is a gotcha that everybody trips over initially, and just extra noise in the code even once you're used to it.

Our Solution: Computed List

For MiniScript 2, we have chosen a different solution: a list may, under the hood, be a computed list. Rather than storing individual values, a computed list stores just three: the base, the step, and the count. But unlike Python, this is completely transparent to your code; it is still a real list, and may be used exactly like any other list.

So now when you run the code above in MiniScript 2, it no longer allocates and precomputes over a million elements. Instead it allocates space for just 3 elements. But it acts like it has a million and one elements, in every way (unless you use the info intrinsic to peek at its computed flag).

You get such a computed list, currently, in two ways:

The range function always returns a computed list.
List replication, i.e. [x] * n, returns a computed list if x is any immutable value and n is an integer.

What Stays Computed

There are lots of things you can do with a computed list that leave the list in computed form, and just calculate the answer (very quickly). If foo is such a list, then all of these work directly on the computed data:

foo.len
foo[i] for any index i
foo[i:j] slicing from i up to j
foo.pop (yes, it mutates the computed list!)
foo.sum and other non-mutating intrinsics
freeze foo (making it into a frozen computed list)

That loop above could have been written as simply range(1000000).sum, and it very quickly computes the right answer, without ever allocating a million-element list.

When It Can't Stay Computed

However, unless you freeze the list, it's still a mutable object and you can change its contents. This generally requires "materializing" the list, i.e., at this point MiniScript goes ahead and allocates as much space as needed to hold all the values. (The exception to this rule is pop, which keeps it computed and merely reduces the count.) So, any of these operations will materialize the list:

foo.push x
foo.remove i
foo.insert i, x
foo[i] = x
foo.sort

At this point you lose the benefit of having a computed list, but that's OK. You're no worse off than we were yesterday, when we didn't have computed lists at all. And critically, you don't have to think about this. You ask for a list, you get a list, MiniScript keeps it computed when it can and materializes it when it must. Everything just works.

Performance

We built some benchmarks to measure code that relies heavily on big lists without mutating them, as well as code that does need to mutate them (and so can't take advantage of computed lists). This new feature brought about a 100X speedup in the first case, and had no measurable impact on the second.

Of course the improvement will depend greatly on the details of what the code is doing, but the key point is, as expected, this is an overall win. Not only do we avoid allocating and deallocating big hunks of RAM, but also a computed list (which is only 3 elements) fits comfortably into all levels of the memory cache hierarchy, unlike bigger lists. Cache misses are a major bottleneck in a lot of compute-heavy code, so this optimization wins both ways.

Life is Good

I'm proud of this solution because it gives us enormous benefits in cases that were needlessly slow before, but doesn't require the user to learn or remember anything new. I mean, I just told you all about it, but that was for sheer "Gee Whiz"-ism — nobody needs to understand what you now know!

And it does all this in a way that is relatively simple and didn't require a ton of new code under the hood, either.

This new feature will ship with MiniScript 2 Preview 6 (probably tomorrow). If you use command-line MiniScript, or would like to, keep your eye on the releases page, and give it a try!

Announcing MiniScript 2 Preview Builds!

JoeStrout — Thu, 18 Jun 2026 00:03:03 +0000

As announced in our MiniScript Road Map for 2026, the big push this year is working on MiniScript version 2.0. This first major update to the MiniScript language will be substantially faster than MiniScript 1.x, and include some important new language features too.

I'm pleased to say it's going very well -- we have MiniScript 2 written in both C# and C++ now (in a more clever way than before), and it's right on schedule, or even ahead.

If you are impatient and want to download MiniScript 2 immediately, please do! You can find the latest releases here.

Improved REPL

The first thing you'll notice when you run MiniScript 2 interactively (i.e., without giving it a script to run) is a much fancier user experience in the REPL (read-eval-print loop).

There are two main differences from the 1.x REPL:

Every input goes onto an _in list (as a string); every result goes onto an _out list (as whatever data type the result was). You can refer to these in your code, which is often quite convenient when you want to build on a previous result, write the whole input history out to a file, etc.
Terminal control codes are used to display less-relevant text (like the initial version info and input/output labels) in subdued text, your inputs as ordinary text, and outputs as bold text. This helps you focus on the most important info (and is also quite pretty!).

New `error` Data Type

Error handling in MiniScript 1.x was rather weak; mostly it involved functions returning something unexpected when things went wrong, like null or a string error message instead of the usual result map.

After a lot of community discussion (and yes, we did consider exceptions and try/catch), we settled on an approach to error handling that I think is very elegant. There is a new error data type, equal in status to number, string, list, map, etc. Error values have some special behaviors: trying to use an error value in almost any way will terminate your program, but you can inspect it to see what the error is, where in the code it occurred, etc.

Read more about this (and other features) in the Language Changes doc.

Frozen Maps & Lists

Another language enhancement in 2.0 is frozen lists and maps. Lists and maps are normally "mutable," which means they can be changed in place; if you have two references to the same list, and you change the list via one of them, you see the change in the other.

 _in[17]: a = [1,2,3]

 _in[18]: b = a

 _in[19]: a[0] = 999

 _in[20]: b
_out[20]: [999, 2, 3]

This is often exactly what you want. But sometimes you want to build a list or map that can't be changed; i.e. is "immutable". In Python, they have a whole other data type for an immutable list (the "tuple"), with different syntax, just for this purpose.

In MiniScript 2, you can instead freeze a list or map. A frozen list or map is immutable and can't be changed. Some intrinsic APIs return frozen maps now, like version for example.

 _in[21]: version 
_out[21]: {"miniscript": "2.0", "buildDate": "2026-06-17", "platform": 
"macOS 13.6.4", "host": "2.0 Preview", "hostName": "Command-Line (Unix)", 
"hostInfo": "https://miniscript.org/cmdline/"}

 _in[22]: version.host = "2.1"
Runtime Error: Attempt to modify a frozen map

MiniScript will also use a frozen copy of a list or map when you use it as a map key, since mutating a map key is very bad juju.

This is one of those refinements that new users probably won't even notice, but for serious MiniScript users, it will save a lot of headaches.

Function Notes & `info`

Another nifty new feature of MiniScript two is function notes. If the first statement in a function evaluates to a constant string, then this string is stored on the function, and can be accessed via the new info intrinsic, like so:

 _in[4]: f = function(x,y)
    ...:   "Return the magnitude of vector x,y"
    ...:   return sqrt(x^2 + y^2)
    ...:   end function

 _in[7]: info(@f)
_out[7]: {"type": "funcRef", "name": "f", "note": "Return the magnitude 
of vector x,y", "params": [{"name": "x", "default": null}, {"name": "y", 
"default": null}], "closure": 1}

 _in[10]: info(@f).note
_out[10]: Return the magnitude of vector x,y

This provides a standard, convenient place to give a little hint or reminder to users about what the function does. (Note to self: I'll need to go through all the /sys disk modules and add function notes!)

Improved Performance

I already discussed performance in our March update, so I won't repeat that here. Suffice to say, MiniScript 2.0 is many times faster than 1.x, comparable to Python, and we still have plenty of opportunities for pushing it further.

Right On Track

The schedule from December laid out these milestones:

Date	Milestone
2026 Q1	MS2 compiles & runs a subset of MiniScript
2026 Q2	MS2 feature complete (whole language implemented)
2026 Q3	MS2 testing, refinement, & polish
2026 Q4	MS2 released 🥳

We're at the end of Q2 now, and the first two steps above are done. A lot of stuff in the "testing, refinement, & polish" category has already been done too (for example, the terminal colors/styles and in/out value lists in the REPL). So we're actually a little ahead of schedule. It's time now for some serious testing -- but we're also going to start in on Raylib bindings within the next month, which wasn't expected until Q2.

Please Help!

Did I mention that it's now time for some serious testing? That means you! I will do what I can, but I can't do it all by myself.

(Indeed, we wouldn't be where we are today without some very helpful testing of Windows and Linux builds by Discord users BibleClinger, minerobber, shellrider, and MoTrix -- thanks guys!)

So please download the preview release for your platform, and take it for a spin. Throw some of your older scripts at it. Write some new scripts. Explore the new language features. Try to break it! This is a large amount of brand new code, much of it quite complex, so there are almost certainly bugs to be found.

When you find a problem, either bring it up on Discord (in the #miniscript-2 channel), or file an issue on GitHub. Do the same if you have some suggestion or feature request -- we're mostly feature-frozen at this point, but it's not too late for small refinements, especially if they bring important quality-of-life improvements.

I hope you're excited as I am for this major milestone. MiniScript 2 unlocks all the other cool stuff in the Road Map. Let's go!!

MiniScript Weekly News — June 05, 2026

JoeStrout — Fri, 05 Jun 2026 18:12:46 +0000

Development Updates

MiniScript 2 kept moving forward this week with a solid round of cleanup and polish. The dev log mentions Unicode improvements, faster string handling, O(1) intrinsic lookup, a !help metacommand for the REPL, and a few opcode / naming cleanups to make the internals more consistent.

Dev log: JoeStrout/miniscript2

There was also useful progress on cross-platform builds. After some back-and-forth with compiler quirks, the project is now building on more than one platform, and Joe is weighing the best Windows strategy going forward: MSVC, MinGW-w64, or potentially clang-cl.

The Mini Micro sysdisk also got a nice little refactor. The LCARS demo now has its app modules split into /sys/lcarsApps, and the new structure can also load modules from /usr/lcarsApps, opening the door for community-made add-ons.

Commit: Extract LCARS app modules into sys/lcarsApps

Community Projects

Trey Tomes has been building a Mini Micro SVG experiment, and it’s looking really fun. He shared parser and renderer work for circles, colors, and XML handling, along with a constellation-style SVG demo — a great example of diving into a new graphics idea in MiniScript.

Parser: parseSvgColor.ms
XML helper: xml.ms
Renderer: render.ms

We also saw a new MiniScript-powered game called Touhou Creator on Steam, which is exciting news for the ecosystem. Huge congrats to hachimi for sharing it — always wonderful to see MiniScript reaching a broader audience.

Steam link: Store page

Community & Discussion Highlights

A few newcomers stopped by looking for tutorials and next steps, and the community had some good recommendations ready. Joe pointed people toward the Mini Micro getting-started guide, the intro-to-programming resource, and the language try-it page, while also reminding everyone that MiniScript is best learned by doing.

There was also some useful discussion around tooling and distribution. People talked about a potential Lutris runner for Mini Micro on Linux, and Joe clarified that a Mini Micro mobile version is still on the roadmap, just not ready yet.

Roadmap update: MiniScript roadmap update — March 2026

Events & Outreach

A new Micro Jam was announced with an ANIMALS theme, which sounds like a great excuse to explore Mini Micro’s built-in sprite resources. If you’ve been waiting for a gentle prompt to make something small and playful, this is a lovely one.

Jam: Micro Jam #059 — ANIMALS

On the outreach side, Dat_One_Dev reported encouraging movement on getting Mini Micro covered by GameFromScratch. It’s always great to see community members helping spread the word beyond our usual circles.

Channel: GameFromScratch on YouTube

That’s it for this week — thanks to everyone building, testing, sharing, and welcoming new folks. See you next week!

Upcoming Game Jams

These upcoming jams look like a great fit for Mini Micro:

Slop Jam 2: Electric Boogaloo (starts 2026-06-12 22:00:00) — An anything-goes, low-pressure jam with no engine restrictions and a theme revealed at the start, making it a great place to whip up a quirky 2D, pixel, or text-based game over a weekend.
The Demo Jam (starts 2026-06-07 23:00:00) — A strong fit for a retro-style, bite-sized vertical slice with lots of room for polished presentation, teaser content, and playful demo-only limitations like locked features or a mock ‘full version’ hook.
Turtley in Love - Pride 2026 (starts 2026-06-12 20:00:00) — A one-week Pride-themed jam with a cozy, celebratory vibe and an open theme makes this a great chance to create something heartfelt, playful, and approachable.
District Jam VII (starts 2026-06-12 23:00:00) — A relaxed, short-form jam with any engine allowed and no technical constraints, making it an excellent chance to build a pixel-art, tile-based, or text-driven game in a friendly community setting.
Tiny Game, Big Twist Jam (starts 2026-06-08 11:00:00) — A 3-day jam built around small, surprising games with a meaningful twist, leaving lots of room for clever mechanics, experimental storytelling, and memorable genre shifts.

MiniScript Weekly News — May 27, 2026

JoeStrout — Thu, 28 May 2026 02:05:15 +0000

Development Updates

The MiniScript 2 work continues to move forward at a brisk pace. Joe’s latest dev log shows major progress on shell intrinsics like file and import, plus support for RawData and GCHandle, while also tightening up compiler behavior around globals, super, short-circuiting, and error handling. The recent commit trail is especially busy, with fixes for function storage, variable naming in conditionals, and a cleanup to remove extern "C" from CS_value_util.h for better compiler compatibility.

There’s also been a healthy round of real-world testing against existing demos and code. In particular, superstartrek has been a great stress test for edge cases, helping uncover and resolve a cluster of bugs that made the system stronger overall.

Community Projects

A quick update from Redspark on Emberfall: the engine has nearly been converted to Raylib-MiniScript, and work is underway on the 3D renderer. That’s the kind of behind-the-scenes momentum that makes a future show-and-tell post especially exciting.

A big shout-out to everyone helping push MiniScript 2 across different platforms. MoTrix and minerobber have both been digging into build issues, with fixes and PRs emerging for Linux, Ubuntu, and Windows/MSVC compatibility — a fantastic example of community-powered portability work.

Discussion Highlights

The community had a lively discussion about decorators and argument unpacking in MiniScript. Joe floated the idea of a “decorators in MiniScript” article, and the conversation turned into a practical look at wrappers, apply-style functions, and how argument packing/unpacking might work without too much syntactic sugar.

Mini Micro users also weighed in on documentation ideas, with suggestions ranging from a “Getting Started” guide to a whimsical 1980s-style manual for the virtual computer. Separately, Joe is exploring hardware possibilities for a future “hardware Mini Micro” setup, including Intel N100 mini-PCs and Orange Pi options.

Community Notes

Welcome to all the new folks joining the server this week! It’s always nice to see more people arriving with game-dev ideas, curiosity about MiniScript, and interest in helping shape what comes next.

There were also some fun project ideas in the mix, including a sci-fi cloaked-ship combat game and even a tongue-in-cheek dystopian tale about the “Spacers” versus the “Tabbers.” That kind of playful creativity is exactly what makes the MiniScript community so enjoyable.

Around the Community

Joe also shared a fun new mini-project on DEV: Where in the World Am I?. It shows how to use web services and simple 3D rendering to pinpoint your location on a rotating globe.

And on the Mini Micro side, Joe’s been thinking about future documentation and accessibility features, including possible TTS/STT support for Mini Micro 2. A promising model was shared here: Supertonic, with voice samples at supertone-inc.github.io/supertonic-py/voices.

Thanks for reading — happy scripting, and keep sharing what you’re building!

Upcoming Game Jams

These upcoming jams look like a great fit for Mini Micro:

YOU CAN PLAY THIS GAME JAM (starts 2026-05-30 04:00:00) — A highly accessible, beginner-friendly jam centered on pitching great ideas and designing for inclusivity, with no requirement to build a full playable prototype.
smilejam (starts 2026-05-17 23:00:00) — A perfect match for quick, intimate, experimental games: short playable pieces, strong mood, prose, collage, and low-pressure creativity all line up beautifully.
Cute Girls Doing Cool Things VN Jam 2026 (starts 2026-06-01 04:00:00) — A strong fit for a story-first project: the jam’s visual novel focus, cute-character premise, and summer-blockbuster energy all lend themselves to expressive 2D scenes, branching dialogue, and stylish presentation.
Never Joined A Game Jam Game Jam (starts 2026-05-29 14:00:00) — A beginner-friendly, no-theme jam focused on learning by doing, with plenty of room for a straightforward top-down shooter, simple UI, scoring, and extra polish like particles or enemy variants.
Trijam #374: The 3 hour game jam (starts 2026-05-28 21:00:00) — A fast, friendly jam built around making something fun in just 3 hours, with flexible rules, room for pre-made assets, and an emphasis on simple, playable ideas that are perfect for quick 2D projects.
Romance Game Jam #01 (starts 2026-06-01 06:00:00) — A very welcoming romance-focused jam with a four-week window, no voting pressure, and plenty of room for anything from sweet SFW stories to weird, esoteric love games.

Where in the World Am I?

JoeStrout — Wed, 20 May 2026 23:09:33 +0000

There are so many fun things you can do with web services, and most of them are trivial to use in Mini Micro. Today, let's use a couple of these together to plot your location on a map of the world!

Finding Your Place In the World

...begins by finding your external (or public) IP address. This is the Internet Protocol address by which you are seen on the internet, outside your local network. It's probably different from your internal (or private) IP address, which is what probably appears when you look at the network settings on your computer. We don't care how your computer is known to other computers in your house or neighborhood; we only care how packets are routed to it from the great wide world beyond. Fire up Mini Micro (available free here, and type:

http.get("https://api.ipify.org")

This should return an IP address, something like 66.212.203.27.

Now, to get information about that IP address, including the city it's in and an approximate latitude/longitude, we'll use a different web service:

http.get("http://ip-api.com/json/66.212.203.27")

You can replace the IP address above with whatever you got from the first query. The result will be a string of JSON code that contains your city, region, country, latitude, and longitude, along with the name of your internet service provider (ISP) and other details.

Putting this all together into a little program. Use edit to enter the code editor, then paste in the following:

import "json"
import "stringUtil"
clear

// What's my external IP address?
myIP = http.get("https://api.ipify.org")

// And where am I?
locJson = http.get("http://ip-api.com/json/" + myIP)
locInfo = json.parse(locJson)

pprint locInfo
print "You are in {city}, {region} ({country})".fill(locInfo)

Run this, and it should tell you where you are (along with all those other details). Neat, right?

Don't Tell Me, Show Me!

But we can make it more fun. Let's pinpoint you on a map of the Earth! edit your program again, delete the last two lines (pprint and print), and add in this additional code:

mapImage = file.loadImage("/sys/pics/earth_day.jpg")

// Find the pixel coordinates of our lat/long in this image
px = (locInfo.lon + 180) / 360 * mapImage.width
py = mapImage.height - (90 - locInfo.lat) / 180 * mapImage.height

// Draw a marker (using an offscreen PixelDisplay)
g = new PixelDisplay
g.clear color.black, mapImage.width, mapImage.height
g.drawImage mapImage
g.line 0, py, g.width, py, "#00FFFF88", 3
g.line px, 0, px, g.height, "#00FFFF88", 3
g.fillEllipse px-10, py-10, 20, 20, "#00FFFFFF"
g.drawEllipse px-15, py-15, 30, 30, "#00FFFFAA"
g.drawEllipse px-20, py-20, 40, 40, "#00FFFF88"
markedMap = g.getImage(0, 0, g.width, g.height)

// And draw the mapImage, fit to the screen!
scale = 960/mapImage.width
gfx.drawImage markedMap,
  480 - mapImage.width*scale/2, 320 - mapImage.height*scale/2,
  mapImage.width*scale, mapImage.height*scale

s = "{city}, {region}, ({countryCode})".fill(locInfo)
text.row = 2
text.column = 34 - s.len/2
print s

The result, if you happen to be my neighbor right now, should look like this:

The trick here is knowing that the map image uses a standard equiprectangular projection, where longitude and latitude both map linearly to x and y. That lets us convert from lat/long to pixel coordinates with some reasonably simple math. Most of the code above is then drawing the pinpoint lines and circles on top of the map.

(Note: if you are reading this in the future and live somewhere other than Earth, this code will need adjustment.)

Now in Animated 3D!

Let's take it one step further: combine what you've done so far with the globe demo! Follow these steps:

Save your program, if you haven't already.
edit "/sys/demo/globe" to load the globe demo code.
Select All (^A) and then Copy (^C).
Exit the editor, then edit your program.
Scroll to the bottom, and Paste (^V).
Find the line (at the top of the pasted code) that says bigMapImg = file.loadImage("/sys/pics/earth_day.jpg"), and change it to just say bigMapImg = markedMap instead.

That's it. Now run your program, and you should see your location on a beautiful rotating globe.

Never Be Lost Again

The http module is an often-overlooked gem in the Mini Micro APIs. With one little call we can get our external IP address, and with a second little call, get all sorts of information about that, including the info we need to place ourselves on a map. We also looked at how you are able — nay, encouraged! — to steal from the demo code and make it your own.

What do you think of this? Let me know in the comments below!

MiniScript Weekly News — May 14, 2026

JoeStrout — Thu, 14 May 2026 20:24:30 +0000

Development Updates

MiniScript 2.0 saw a bunch of steady progress this week, especially around garbage collection and string handling. Joe landed a new gc intrinsic with gc.collect and gc.stats methods, plus fixes for runtime error reporting and several VM/refactoring issues in the miniscript2 branch. The dev log and recent commits are worth a look if you enjoy following the architecture work: DEV_LOG, recent commits.

A notable performance decision also got locked in: separate int storage was removed, and all numbers are now double. Joe reported no meaningful benchmark difference, so the simpler design wins here — a great example of keeping the internals elegant without sacrificing speed.

Community Projects

If you’ve been meaning to get started with Mini Micro, Joe’s been actively pointing newcomers toward the quickstart and the built-in demos. The best launch point is still the getting-started guide: How to get started with Mini Micro, and Joe specifically reminded folks to try running things like run "asteroids" in /sys/demo.

There was also a fun new wave of interest around MiniScript on Godot. Community members shared the extension repo Godot-X-MiniScript and a broader GitHub search for related projects: MiniScript + Godot repos.

Discussion Highlights

Several great technical conversations happened this week around embedding and runtime design. People asked about using MiniScript as an embedded language in games, and Joe pointed to the Unity package while noting that the Unity plugin is a bit behind and may need the latest source folder from GitHub. He also shared the language quick reference: MiniScript QuickRef PDF.

On the Mini Micro side, there was a lively discussion about performance benchmarks, palette handling, and low-level 6502-inspired hardware ideas. Joe also highlighted a useful public API list providing online services usable from Mini Micro apps: public-apis/public-apis.

From the Blog

Joe published a new Mini Micro tutorial, HWYDT: Turning the Page, showing how to build a convincing page-flip animation using nothing but math, sprites, and texture mapping. It’s a fun, practical example of what Mini Micro can do — and a nice companion to HWYDT: Swinging from Vines.

Thanks for reading, and happy scripting!

Upcoming Game Jams

These upcoming jams look like a great fit for Mini Micro:

Make Literally Anything Jam '26 (starts 2026-05-15 04:00:00) — A wildly open-ended jam with a loose theme and total freedom to make almost anything you want, perfect for experimenting, getting weird, or shipping something small and fun in just a week.
Micro Jam 058: Tides ($400+ Prizes) (starts 2026-05-16 02:00:00) — A highly approachable theme with lots of room for clever interpretation, making it ideal for a compact 2D game built around atmosphere, movement, or shifting conditions.
ARCADIA JAM #4 (starts 2026-05-15 17:00:00) — A short, open 48-hour jam with permissive rules and no engine restrictions, making it a great chance to build a polished web-friendly game and compete on art, gameplay, and originality.
The Shorter, The Better (starts 2026-05-15 17:30:00) — A very friendly fit for a compact, story-driven game: the 5-minute limit encourages tight pacing, a single ending keeps scope manageable, and web playability makes it easy to share and test.
MVM 32 - Super edition (starts 2026-05-16 02:00:00) — A long-running metroidvania-focused jam with a relaxed three-month window, open engine rules, and room to iterate on exploration, abilities, and level design.
Campfire Creators Jam #2 (starts 2026-05-21 21:00:00) — A highly flexible jam with a retro-friendly campfire theme, welcoming everything from cozy story games to survival, puzzle, and strategy concepts while only requiring a single animated campfire sprite.

HWYDT: Turning the Page

JoeStrout — Wed, 13 May 2026 17:23:37 +0000

On the MiniScript Discord this week, one of our users (Luckythespacecat) shared an animation he made for his Steam game Wishlist Boreal. It looks like an open book, with the page turning as if advancing through the book, including a nice paper-ish curl as it goes. That led to another user (@dslower) pointing out this Instagram reel in which somebody makes a texture-mapped page flip animation, also with a nice curvy page.

And then he had the audacity to opine that you couldn't do such a thing in Mini Micro.

Challenge Accepted

In fact we can do such things in Mini Micro! The trick is just to break the curving surface up into flat quadrilaterals, and then render each quad as a Sprite.

Normally in these tutorials I walk through developing the code step by step — build a little, test a little. But this program is short enough that I think I'll try the opposite: present the full code, and then just explain how it works.

So, for maximum fun, fire up your copy of Mini Micro, edit a new program, and paste in the following code.

import "mathUtil"

clear
display(2).mode = displayMode.pixel
gfx = display(2)
gfx.clear color.clear
debug = false

pageTextures = [
  file.loadImage("page1.png"),
  file.loadImage("page2.png")]

pageWidth = 250
pageHeight = 400
xDivs = [0, 0.025, 0.05, 0.1, 0.2, 0.3, 0.4, 0.5, 0.7, 1]

pageSprites = []
lastU = 0
for i in range(1, xDivs.len - 1)
    sp = new Sprite
    sp.image = pageTextures[0]
    sp.setUVs [[lastU, 0], [xDivs[i], 0], [xDivs[i],1], [lastU, 1]]
    pageSprites.push sp
    lastU = xDivs[i]
end for
display(4).sprites += pageSprites

getPolarPoint = function(pagePt, t, forward=true)
    radius = pageWidth * pagePt * (cos(t*2*pi)*0.2 + 0.9)
    if not forward then
        t2 = t^pagePt
        angle = mathUtil.lerp(0, 180, (t+t2)/2)
    else
        t = 1 - t
        t2 = t^pagePt
        angle = mathUtil.lerp(180, 0, (t+t2)/2)
    end if
    return [radius, angle]
end function

polarToXY = function(polarPt, baseX=480, baseY=320)
    radius = polarPt[0]
    ang = polarPt[1] * pi/180
    x = baseX + cos(ang) * radius
    y = baseY + sin(ang) * radius
    // apply a minimum representing the thickness of the pages
    // underneath, leaving a "dip" at the binding in the center
    thickness = 16
    q = abs(x - baseX) / pageWidth * 10
    if q < 1 then
        thickness *= sqrt(1 - (1-q)^2)  // (section of a circle)
    end if
    y = mathUtil.max(y, baseY + thickness)
    return [x,y]
end function

framePoly = function(corners)
    for i in range(-1, corners.len-2)
        p0 = corners[i]
        p1 = corners[i+1]
        gfx.line p0[0], p0[1], p1[0], p1[1], "#FF00FF", 2
    end for
end function

render = function(t, forward=true)
    if debug then gfx.clear color.clear
    topPts = []
    botPts = []
    for pagePt in xDivs
        p = getPolarPoint(pagePt, t, forward)
        topPts.push polarToXY(p, 480, 50 + pageHeight)
        botPts.push polarToXY(p, 480, 50)
    end for
    for i in pageSprites.indexes
        pageSprites[i].setCorners [
          [botPts[i][0], botPts[i][1]],
          [botPts[i+1][0], botPts[i+1][1]],
          [topPts[i+1][0], topPts[i+1][1]],
          [topPts[i][0], topPts[i][1]] ]
        if topPts[i+1][0] >= topPts[i][0] then
            // front surface
            pageSprites[i].image = pageTextures[0]
            u0 = xDivs[i]
            u1 = xDivs[i+1]
        else
            // back surface
            pageSprites[i].image = pageTextures[1]          
            u0 = 1 - xDivs[i]
            u1 = 1 - xDivs[i+1]
        end if
        sp.setUVs [[u0, 0], [u1, 0], [u1, 1], [u0, 1]]
        if debug then framePoly pageSprites[i].corners
    end for
end function

pageState = 0  // 0: page on the right; 1: flipped to the left
render pageState

turnPage = function(toState=1)
    delta = sign(toState - 0.5) * 0.02
    while pageState != toState and not key.available
        yield
        outer.pageState += delta
        if pageState < 0 or pageState > 1 then
            outer.pageState = mathUtil.clamp(pageState)
        end if
        render pageState, toState
    end while
end function

// Main loop
while true
    k = key.get
    if k == char(27) or k == "q" then break  // Esc or Q to quit
    if k == "d" then
        debug = not debug
        gfx.clear color.clear
        render pageState
    end if
    if k == char(17) then turnPage 1
    if k == char(18) then turnPage 0
    if k == char(10) or k == " " then turnPage not pageState
end while

You'll also need two page images: one for the front, and one for the back of the turning page. You can use whatever you like, but to match my demo, download these and save them as page1.png and page2.png:

Now run the program, and press the left/right arrow keys to flip the page. It should look like this:

Neat, right?

Carving up the Page

The secret sauce here is to divide the page into vertical strips, each of which is flat. In the demo, if you press the "d" (for "debug") key, it will actually draw the outlines of those quads, so you can see them.

You can divide the page however you like, but in my animation, I found that the curvature is much greater near the book binding (the left side of the original page) than on the outer (right) side of the page. So I made the divisions smaller on the left, and larger on the right. If we use 0 to refer to the left side of the page image, and 1 to refer to the right, then a sensible set of key points (dividing lines between the quads) might be:

xDivs = [0, 0.025, 0.05, 0.1, 0.2, 0.3, 0.4, 0.5, 0.7, 1]

...which in fact you will find as line 15 in the code.

To render any textured quad in Mini Micro, just make a Sprite, set its image property to the texture image, and then use setCorners and setUVs to position the quad on the screen, and select what part of the texture it displays. setCorners takes a list of four [x,y] pairs, in screen coordinates. setUVs takes a list of four [u,v] pairs, where u goes from 0-1 horizontally across the image (exactly like our xDivs values above), and v goes from 0-1 up the image vertically.

If you need a review on setCorners and setUVs, play around with the spriteStretch demo found in /sys/demo/.

In our page-flip demo, you'll find a loop at lines 17-26 which prepares our sprites based on the xDivs we defined above.

pageSprites = []
lastU = 0
for i in range(1, xDivs.len - 1)
    sp = new Sprite
    sp.image = pageTextures[0]
    sp.setUVs [[lastU, 0], [xDivs[i], 0], [xDivs[i],1], [lastU, 1]]
    pageSprites.push sp
    lastU = xDivs[i]
end for
display(4).sprites += pageSprites

Later (starting at line 65), we have a render function that updates those same sprites to reflect the current state of the animation. It begins by building a set of x,y coordinates for the points along the top and bottom of the page:

    topPts = []
    botPts = []
    for pagePt in xDivs
        p = getPolarPoint(pagePt, t, forward)
        topPts.push polarToXY(p, 480, 50 + pageHeight)
        botPts.push polarToXY(p, 480, 50)
    end for

The heavy lifting here is being done by getPolarPoint and polarToXY, which we'll get to in a moment. For now, just understand that we're taking our xDivs points along the page, and converting them into screen coordinates for the top (topPts) and bottom (botPts) of the page. Then we just use those to update the corners of each corresponding sprite.

    for i in pageSprites.indexes
        pageSprites[i].setCorners [
          [botPts[i][0], botPts[i][1]],
          [botPts[i+1][0], botPts[i+1][1]],
          [topPts[i+1][0], topPts[i+1][1]],
          [topPts[i][0], topPts[i][1]] ]
    end for

If we wanted to show the same content (but reversed) on the back of the page, this would be all we need. But really we want to show a different image on the back of the page, and because the sprites are flipped horizontally by that point, we need to invert the U coordinates as well. So we need to insert some extra code into the above for loop to update the image and UV coordinates:

        if topPts[i+1][0] >= topPts[i][0] then
            // front surface
            pageSprites[i].image = pageTextures[0]
            u0 = xDivs[i]
            u1 = xDivs[i+1]
        else
            // back surface
            pageSprites[i].image = pageTextures[1]          
            u0 = 1 - xDivs[i]
            u1 = 1 - xDivs[i+1]
        end if
        sp.setUVs [[u0, 0], [u1, 0], [u1, 1], [u0, 1]]

Now each section not only draws in the right position, but also shows the correct part of the right texture, depending on whether it's flipped.

Computing the Page Shape

For me, drawing the texture-mapped quads was the easy part. The hard part was actually animating the shape of the page throughout the flip.

You could just use keyframe animation: that is, make a tool (similar to that spriteStretch demo) that lets you drag the top and bottom points around by hand, and record the correct position for key frames throughout the flip. Alternatively, you could use some external animation tool that writes to a file you can read in your Mini Micro program. Then just play those positions back, interpolating as needed for in-between frames.

But I didn't have the patience (nor, most likely, the art skills) for all that, so I went for a more mathematical approach. Since the page is essentially rotating around its attachment point (the left side of the unflipped page), I found it easier to think about it in polar (radius and angle) rather than Cartesian (x and y) coordinates. Some trial and error led me to this function.

getPolarPoint = function(pagePt, t, forward=true)
    radius = pageWidth * pagePt * (cos(t*2*pi)*0.2 + 0.9)
    if not forward then
        t2 = t^pagePt
        angle = mathUtil.lerp(0, 180, (t+t2)/2)
    else
        t = 1 - t
        t2 = t^pagePt
        angle = mathUtil.lerp(180, 0, (t+t2)/2)
    end if
    return [radius, angle]
end function

getPolarPoint takes:

a page point, i.e., one of those xDivs points along the page from 0 (left) to (1) right
t, how far we are in the flip animation from 0 (starting position) to 1 (complete)
forward, which is true when flipping forward (right to left) and false when flipping back the other way.

The first version of this function had just radius = pageWidth * pagePt; angle = mathUtil.lerp(0, 180, t) -- that is, a constant radius, and an angle that interpolates smoothly between 0 and 180 degrees. This creates a stiff page that flips without bending. The rest of the final code was just to fancy it up: make the radius a little smaller towards the center of the animation, and add a bit of curl by changing the angle based on how far along the page we are (and how far we are in the animation).

But to actually use this, we have to convert from polar coordinates back to XY coordinates. The basic function for that would be:

polarToXY = function(polarPt, baseX=480, baseY=320)
    radius = polarPt[0]
    ang = polarPt[1] * pi/180
    x = baseX + cos(ang) * radius
    y = baseY + sin(ang) * radius
    return [x,y]
end function

But while I was at it, I decided to have this conversion function also apply some "thickness" to the book, by calculating a minimum Y that varies with our distance along the page. This was to make the endpoints of the animation include a bit of a curl down where the page connects to the rest of the book, so it looks like an actual book with a binding, rather than a thin magazine or something.

The code for this (inserted into the function above) is:

    // apply a minimum representing the thickness of the pages
    // underneath, leaving a "dip" at the binding in the center
    thickness = 16
    q = abs(x - baseX) / pageWidth * 10
    if q < 1 then
        thickness *= sqrt(1 - (1-q)^2)  // (section of a circle)
    end if
    y = mathUtil.max(y, baseY + thickness)

Incorporating Into Your Game

That's all our demo does. To incorporate this into a full game, you would need to draw the "rest" of the book (the open cover and pages underneath the turning page, and ensure that your page sprites are topmost.

Also, you'll probably have more than just one (front and back page). You might have lots of pages in your book. I would implement that with just three sets of page sprites:

one that shows the resting right-hand page
one for the resting left-hand page
one for the actively turning page

At rest, you don't actually need the third one. But as soon as it's time to turn the page, you would add it to the view. If advancing through the book, the right-hand page is going to flip left. So you would set your third page with the content on the right, plus the subsequent page as its back; and update the resting right-hand page to show the page after that. Then animate. At the end of the animation, update the left-hand page to show the same thing as the animation page, and hide the animation page. If going backwards, you'd do something similar, but animating from left to right.

I toyed with the idea of making this into its own little library on GitHub that manages multiple pages, provides different ways of specifying the page animation, etc. But maybe it's not worth it; the core ideas are in this demo, and you can take it from here. Let me know what you think in the comments below, or join us on Discord to discuss more. I can't wait to see what you do with it!

HWYDT: Swinging from Vines

JoeStrout — Wed, 06 May 2026 16:23:32 +0000

The Venerable History of Vine-Swinging

Swinging on vines has been a favorite game mechanic since 1982, when both Jungle Hunt (a thinly disguised Tarzan arcade game) and Pitfall! (on of the Atari 2600's best-selling action games) hit the market.

Since then, swinging from vines, ropes, webs, grappling hooks, extensible bionic arms, etc. has been a recurring staple (including in such modern hits as Spider-Pig!).

But how can you actually do this in your own games? Let's dig in and find out!

The Big Picture

We're going to implement a vine-swinging demo in Mini Micro. Our vines will be composed of five or so straight segments, connected like links in a chain. These will oscillate back and forth, using some simple trigonometry (don't worry, I said simple and I meant it!) to update their positions and rotations. We need a sprite image for each vine segment; this should be a thick line with rounded ends (so they join neatly together), and for decoration, I've added some leaves:

Go ahead and save this image as VineSegment.png, and fire up Mini Micro (download it here if you don't have it already). Notice that the image is mostly empty on the left; the "pivot point" (around which the sprite rotates) in Mini Micro is always in the center of the image, so we've simply offset our drawing so that the center of the image is at one end of the visible segment.

Our hero (Kip) will be, at any given moment, either attached to some vine segment, or flying ballistically through the air. When attached, we just need to update his position along with the vine segment he's clinging to. When flying, then Isaac Newton is in charge, and fortunately his equations are even simpler.

Preliminaries

In Mini Micro, enter edit to start a new program, and then paste in these preliminary steps to clear the screen, get a handy reference to the sprite display, and load some sounds we'll need later.

import "mathUtil"

clear
spriteDisp = display(4)
jumpSound = file.loadSound("/sys/sounds/pickup.wav")
catchSound = file.loadSound("/sys/sounds/swoosh.wav")

Then, we're going to need a bit of math to convert between local and world coordinates. By "local" coordinates, I mean coordinates relative to a sprite — for example, the pixel coordinates of some point in its image; those are local to the sprite. "World" coordinates are basically positions on the screen, except that we're going to be scrolling the view our hero progresses, so it's more accurate to say they are positions relative to the sprite display. We need to convert back and forth: converting from local to world in order to position each vine segment relative to the previous one, or Kip relative to the segment he's holding; and converting from world to local to see if Kip is close enough to grab a vine when flying through the air.

This is where the trigonometry comes in. Honestly, I don't memorize or derive these equations; I just google 'em when I need them. You can just copy and paste this into your program:

// Set the x and y values of the given map to
// the world position corresponding to the
// given XY local to this sprite.  In other words,
// assume targetMap is attached to this sprite
// at local position localX, localY; update its
// x and y accordingly.
Sprite.setXYtoLocal = function(targetMap, localX, localY)
    radians = self.rotation * pi/180
    cosAng = cos(radians)
    sinAng = sin(radians)
    targetMap.x = self.x + localX * cosAng - localY * sinAng
    targetMap.y = self.y + localX * sinAng + localY * cosAng    
end function

// Get the local [x,y] position of some world object
// relative to this sprite.
Sprite.getLocal = function(worldXY)
    radians = self.rotation * pi/180
    dx = worldXY.x - self.x
    dy = worldXY.y - self.y
    cosAng = cos(radians)
    sinAng = sin(radians)
    return [dx * cosAng + dy * sinAng, -dx * sinAng + dy * cosAng]  
end function

Save your program as swing.ms (or whatever you like), and run it just to be sure you haven't made a syntax error. If it seems to do nothing, you're doing great so far!

Swingy vines

Now let's add the code that actually makes a vine. We'll have a Sprite subclass called Segment, just to give them all a common image and length; and then we'll have another class called Vine, which encapsulates a list of segments and knows how to update them.

Segment = new Sprite
Segment.image = file.loadImage("VineSegment.png")
Segment.length = 64

Vine = {}
Vine.angRange = 55  // how far to swing from vertical (degrees)
Vine.period = 2  // how long a full back-and-forth takes (seconds)
Vine.Instances = []

Vine.Make = function(x=480, y=640, qtySegments=5)
    vine = new self
    vine.segments = []
    for i in range(0, qtySegments-1)
        seg = new Segment
        seg.x = x
        seg.y = y - seg.length * i
        seg.rotation = -90
        spriteDisp.sprites.push seg
        vine.segments.push seg
    end for
    Vine.Instances.push vine
    return vine
end function
Vine.update = function(time)
    t = 2*pi * time/self.period
    for i in self.segments.indexes
        seg = self.segments[i]
        ang = -90 + self.angRange * sin(t - i*0.2)
        seg.rotation = ang
        if i < self.segments.len-1 then
            seg.setXYtoLocal self.segments[i+1], seg.length, 0
        end if
    end for
end function
Vine.UpdateAll = function(time)
    for vine in Vine.Instances
        vine.update time
    end for
end function

The key bit is of course the Vine.update function, which iterates over its segments, setting the angle of each, and then the position of the next using that setXYtoLocal function we prepared before. The angle is set according to the time (divided by self.period, which is how we make vines swing faster or slower), and subtracts a little factor of the segment number, i * 0.2. This makes the end of the vine lag a bit relative to the top of the vine, making it look like a rope/chain rather than a rigid bar.

To test this code, let's add a simple main program that creates one vine, and updates it:

Vine.Make
while true
    yield
    Vine.UpdateAll time
end while

Now run, and it should look like this:

Challenge: Add a second vine, at a different position. Double challenge: give it a different period, so they're not swinging in perfect sync!

Our Hero, Kip

Now we need a player character to jump from vine to vine. We'll use our hero Kip (fresh from the Caves of Lava), since his sprites are included with Mini Micro. Delete the mini-main-program you added above, and paste in the code below.

kip = new Sprite
kip.image = file.loadImage("/sys/pics/KP/KP-jump.png")
kip.grabbed = null  // Segment he's hanging onto
kip.grabPos = [0,0] // grab position local to that segment
kip.vx = 0; kip.vy = 0  // velocity, in pixels/sec

kip.update = function(dt)
    if self.grabbed then
        // Stick to the vine, updating our velocity as we go
        lastPos = [self.x, self.y]
        self.grabbed.setXYtoLocal self, self.grabPos[0], self.grabPos[1]
        self.vx = (self.x - lastPos[0]) / dt
        self.vy = (self.y - lastPos[1]) / dt
    else
        // free flying!
        self.vy -= 1000*dt  // gravity
        self.x += self.vx * dt
        self.y += self.vy * dt
        // Try to catch any vine except our last one.
        for vine in Vine.Instances
            if vine == self.lastVine then continue
            if self.tryCatch(vine) then break
        end for
    end if
end function

kip.jump = function(extraVx=0, extraVy=100)
    if not self.grabbed then return
    jumpSound.play
    self.grabbed = null
    self.vy += 100  
end function

kip.tryCatch = function(vine)
    for seg in vine.segments
        localPos = seg.getLocal(self)
        if (0 <= localPos[0] < seg.length) and
          (-12 <= localPos[1] < 12) then
            // Valid catch!
            self.grabbed = seg
            self.grabPos = localPos
            self.lastVine = vine
            catchSound.play
            return true
        end if
    end for
    return false
end function

As you can see, Kip's update method has two modes: it does one thing when he has grabbed a vine, and something else when he is flying through space. Both cases are pretty simple. An important trick in the first case is updating kip's velocity (vx and vy) based on how the vine is causing him to move. That matters because when you jump, you want to continue with (more or less) that same velocity.

In the free-flying case, we just apply some gravity to our vertical velocity (vy), and then update our position according to current velocity. The only tricky bit here is checking to see when we're close enough to another vine to grab it — so I extracted that into its own method, kip.tryCatch. This iterates over the segments of the given vine, and sees what our position would be local to that segment. If it's close enough, then we do the catch. (Who says MiniScript doesn't have try/catch?!)

Camera, Final Setup, and Main Program

Our demo is almost done, so let's press on with the final bit: a function to scroll the display so that the "camera" stays centered on the current vine; some code to create a bunch of vines, increasingly far apart; and the main program.


updateCamera = function(dt)
    // try to center the active vine on the screen
    targetX = kip.lastVine.segments[0].x - 480
    spriteDisp.scrollX = mathUtil.moveTowards(
      spriteDisp.scrollX, targetX, 200 * dt)  
end function

// create the vines
x = 300; dx = 400
while x < 4000
    Vine.Make(x).period = 1.8 + rnd*0.4
    dx += 35
    x += dx
end while

// place Kip on the first vine
kip.lastVine = Vine.Instances[0]
kip.grabbed = kip.lastVine.segments[-2]
kip.grabPos = [40, 0]
kip.update
spriteDisp.sprites.push kip

// main loop
lastTime = time
jumpWasDown = false
while kip.y > 0
    yield
    now = time
    dt = now - lastTime
    lastTime = now
    Vine.UpdateAll now
    kip.update dt
    jumpDown = key.pressed("space")
    if jumpDown and not jumpWasDown then kip.jump
    jumpWasDown = jumpDown
    updateCamera dt
end while
key.clear
text.row = 1
print "Game over!"

And that's it! Run now and you should have a simple but playable game. How far can you make it before you fall?

Full Program

Here's the whole program in one big listing.

import "mathUtil"

clear
spriteDisp = display(4)
jumpSound = file.loadSound("/sys/sounds/pickup.wav")
catchSound = file.loadSound("/sys/sounds/swoosh.wav")

// Set the x and y values of the given map to
// the world position corresponding to the
// given XY local to this sprite.  In other words,
// assume targetMap is attached to this sprite
// at local position localX, localY; update its
// x and y accordingly.
Sprite.setXYtoLocal = function(targetMap, localX, localY)
    radians = self.rotation * pi/180
    cosAng = cos(radians)
    sinAng = sin(radians)
    targetMap.x = self.x + localX * cosAng - localY * sinAng
    targetMap.y = self.y + localX * sinAng + localY * cosAng    
end function

// Get the local [x,y] position of some world object
// relative to this sprite.
Sprite.getLocal = function(worldXY)
    radians = self.rotation * pi/180
    dx = worldXY.x - self.x
    dy = worldXY.y - self.y
    cosAng = cos(radians)
    sinAng = sin(radians)
    return [dx * cosAng + dy * sinAng, -dx * sinAng + dy * cosAng]  
end function

Segment = new Sprite
Segment.image = file.loadImage("VineSegment.png")
Segment.length = 64

Vine = {}
Vine.angRange = 55  // how far to swing from vertical (degrees)
Vine.period = 2  // how long a full back-and-forth takes (seconds)
Vine.Instances = []

Vine.Make = function(x=480, y=640, qtySegments=5)
    vine = new self
    vine.segments = []
    for i in range(0, qtySegments-1)
        seg = new Segment
        seg.x = x
        seg.y = y - seg.length * i
        seg.rotation = -90
        spriteDisp.sprites.push seg
        vine.segments.push seg
    end for
    Vine.Instances.push vine
    return vine
end function
Vine.update = function(time)
    t = 2*pi * time/self.period
    for i in self.segments.indexes
        seg = self.segments[i]
        ang = -90 + self.angRange * sin(t - i*0.2)
        seg.rotation = ang
        if i < self.segments.len-1 then
            seg.setXYtoLocal self.segments[i+1], seg.length, 0
        end if
    end for
end function
Vine.UpdateAll = function(time)
    for vine in Vine.Instances
        vine.update time
    end for
end function

kip = new Sprite
kip.image = file.loadImage("/sys/pics/KP/KP-jump.png")
kip.grabbed = null  // Segment he's hanging onto
kip.grabPos = [0,0] // grab position local to that segment
kip.vx = 0; kip.vy = 0  // velocity, in pixels/sec

kip.update = function(dt)
    if self.grabbed then
        // Stick to the vine, updating our velocity as we go
        lastPos = [self.x, self.y]
        self.grabbed.setXYtoLocal self, self.grabPos[0], self.grabPos[1]
        self.vx = (self.x - lastPos[0]) / dt
        self.vy = (self.y - lastPos[1]) / dt
    else
        // free flying!
        self.vy -= 1000*dt  // gravity
        self.x += self.vx * dt
        self.y += self.vy * dt
        // Try to catch any vine except our last one.
        for vine in Vine.Instances
            if vine == self.lastVine then continue
            if self.tryCatch(vine) then break
        end for
    end if
end function

kip.jump = function(extraVx=0, extraVy=100)
    if not self.grabbed then return
    jumpSound.play
    self.grabbed = null
    self.vy += 100  
end function

kip.tryCatch = function(vine)
    for seg in vine.segments
        localPos = seg.getLocal(self)
        if (0 <= localPos[0] < seg.length) and
          (-12 <= localPos[1] < 12) then
            // Valid catch!
            self.grabbed = seg
            self.grabPos = localPos
            self.lastVine = vine
            catchSound.play
            return true
        end if
    end for
    return false
end function

updateCamera = function(dt)
    // try to center the active vine on the screen
    targetX = kip.lastVine.segments[0].x - 480
    spriteDisp.scrollX = mathUtil.moveTowards(
      spriteDisp.scrollX, targetX, 200 * dt)  
end function

// create the vines
x = 300; dx = 400
while x < 4000
    Vine.Make(x).period = 1.8 + rnd*0.4
    dx += 35
    x += dx
end while

// place Kip on the first vine
kip.lastVine = Vine.Instances[0]
kip.grabbed = kip.lastVine.segments[-2]
kip.grabPos = [40, 0]
kip.update
spriteDisp.sprites.push kip

// main loop
lastTime = time
jumpWasDown = false
while kip.y > 0
    yield
    now = time
    dt = now - lastTime
    lastTime = now
    Vine.UpdateAll now
    kip.update dt
    jumpDown = key.pressed("space")
    if jumpDown and not jumpWasDown then kip.jump
    jumpWasDown = jumpDown
    updateCamera dt
end while
key.clear
text.row = 1
print "Game over!"

Taking it Further

This simple demo could be quickly expanded into a more engaging game:

Keep a score, adding points for every successful jump, and/or for reaching new vines.
Add hazards (water, alligators, whatever) below to heighten the tension.
Add platforms/ground with traditional platformer mechanics (e.g. running and climbing).
Enable Kip to climb up and down the vine he's on (this makes it a lot easier!).
Improve the vine physics, allowing stretching, slinging, and other fun effects, much like Spider-Pig.

Can you think of other good uses for this sort of mechanic? How might you apply this in your own games? Share your thoughts in the comments below!

MiniScript Weekly News — April 30, 2026

JoeStrout — Thu, 30 Apr 2026 23:08:43 +0000

Development Updates

MiniScript 2 got a solid round of command-line quality-of-life improvements this week. Joe added editable input history, searchable REPL history (!? foo style queries), and a new _in / _out history model; he also fixed some extra blank lines in the REPL.

On the raylib side, raylib-miniscript moved forward nicely with raylib now pinned to 6.0 as a git submodule, plus a bump to version 0.3. Even better, every API now has a code example in the wiki, along with a new Raylib Types page to help map Raylib structures into MiniScript.

In the Mini Micro channel, Joe explained display layering and mode switching in detail, and users kicked around some "worst sorting algorithm" ideas just for fun.

Community Projects

Zaxabock shared a playful MiniScript experiment called PseudoLambda: GitHub repo. It defines lambda-like expressions using Joe’s eval support, and it looks like a fun little throwback while waiting on more language features.

𝔇𝔢𝔞𝔱𝔥 has been building an ambitious project, Ultimate Space Odyssey, and shared a deep dive into Mini Micro display management while working through layered UI, sprite displays, and planet generation. The repo is here: Ultimate_Space_Odyssey/Game — great to see someone pushing the display system and documenting what they learn along the way.

Joe also highlighted a great visual idea for the community to try: a Mini Micro kaleidoscope built from sprites and animated UVs. He posted the write-up here: Make a Mini Micro Kaleidoscope, and it sounds like a fun little program to play with for anyone looking for a colorful weekend project.

Discussion Highlights

There was a lively thread about how MiniScript fits into game architecture, especially around threading and when to use install versus simply switching display modes. Joe’s advice was consistent and reassuring: MiniScript is already thread-safe, and in most games you’ll be happier treating install as a special-case tool rather than a default workflow.

Another useful discussion centered on REPL smart quotes and paste behavior in Mini Micro 2. The conversation surfaced a real tension between convenience and control, with several community members offering thoughtful use cases; it was a nice example of the group thinking carefully about developer experience.

There was also some cheerful design brainstorming in #game-ideas, where Midsubspace floated the idea of making a MiniScript Mancala game. Joe gave it an encouraging “go for it,” which feels like the perfect nudge for a good community project.

Thanks for reading — happy scripting, and keep sharing what you’re building!

Upcoming Game Jams

These upcoming jams look like a great fit for Mini Micro:

Mini Choco Jam (starts 2026-02-28 23:00:00) — A romance-focused, story-first jam with 2D-friendly requirements and no need for 3D or networking is an excellent fit for Mini Micro, especially for visual-novel or text-based games.
16bits 2nd Caravan Jam (starts 2026-05-05 13:30:17) — A great fit for a fast, score-chasing arcade game: the jam is built around short, easy-to-pick-up runs with high skill ceilings, especially in the spirit of classic Caravan-style shoot ’em ups.
Three Button Jam 2026 (8 Bits to Infinity) (starts 2026-05-08 17:00:00) — A highly accessible restriction jam with a fun twist: build a complete game using only three buttons, making it perfect for inventive controls, tight design, and clever feedback loops.
Ak Gaming Game Jam #6 — A very accessible jam with free engine choice, no 3D or networking demands, and a strong emphasis on playable, theme-driven entries—great for retro 2D or text-based game ideas.
AEIOU GameJam 2026 (starts 2026-05-01 03:45:00) — A creativity-first jam with a clever twist theme, encouraging illusions, hidden mechanics, and unexpected gameplay that fits retro 2D experimentation perfectly.

Make a Mini Micro Kaleidoscope

JoeStrout — Wed, 29 Apr 2026 20:11:14 +0000

You have got to try this.

Inspired by a Facebook post, I decided this morning to make a kaleidoscope demo for Mini Micro. And man, this thing is trippy!

There are a lot of knobs to tweak and settings to explore, so fire up Mini Micro (download it free here if you don't have it already), and follow along!

The Big Idea

A kaleidoscope is a set of mirrors that reflect onto some interesting "stuff" (traditionally, colorful little bits of plastic at the end of the tube) to provide a multiple views of the same content. In Mini Micro, we're going to provide those views by using Sprites, each using the same image, and stretched out to a diamond shape. Those are arranged in a circle, providing a star shape overall, like this:

I've made the diamonds smaller, and shifted one of the diamonds out a bit so you can see it in the image above. In the real program, we'll scale these up enough that they fill the screen without gaps.

Then, we set the texture coordinates or "UVs" on each diamond to the same portion of a colorful texture, which represents the "interesting stuff" at the end of the tube. Importantly, the UV coordinates are flipped on alternating diamonds. That causes the texture at the edge of one diamond to match up perfectly with the texture on its neighbor, and results in the trippy symmetrical patterns.

Finally, we just move those UV coordinates around on the texture, causing the pattern to whirl and change. It's mesmerizing!

Getting Started

Start by downloading one or both of these images:

‹ ›

I called them "kaltex1.png" and "kaltex2.png". Save them to whatever folder you want to do this project in. Then launch Mini Micro, and mount that same folder (using the disk-slot icon below the screen; or on Mac/Windows, you can just drop the folder onto the Mini Micro window to mount it).

Type view "kaltex1.png" and press Return in Mini Micro to verify that you're set up with everything in the right place. Then use the edit command, and paste in this code:

clear
texture = file.loadImage("kaltex1.png")
cx = 480; cy = 320; r = 600  // screen center and radius
n = 6  // number of wedges

for i in range(n-1)
    sp = new Sprite
    sp.image = texture
    a = i * 2*pi/n
    a1 = a + pi/n
    a2 = a1 + pi/n
    sp.setCorners [[cx, cy],
      [cx+cos(a)*r, cy+sin(a)*r],
      [cx+cos(a1)*r*2, cy+sin(a1)*r*2],  
      [cx+cos(a2)*r, cy+sin(a2)*r]]
    display(4).sprites.push sp
end for

Save that as "kaleidoscope" (or whatever you like), then run it. It should fill your screen with repeating copies of the full texture.

This code mostly just figures out the angle (in radians) to the corners of each diamond, and then calculates the positions of those using cos and sin. If you need a review of how angles, sin, and cos work, run /sys/demo/angles. (And you thought you'd never need trigonometry in real life!)

Setting UVs

edit your program again, and append this code:

uvs = function(t, flip=false)
    cx = 0.5 + 0.25 * sin(t * 0.13)
    cy = 0.5 + 0.25 * cos(t * 0.17)
    a = t * 0.21
    r = 0.25 + 0.08 * sin(t * 0.31)
    result = []
    for i in range(0,3)
        result.push [cx + cos(a)*r, cy + sin(a)*r]
        if flip then a -= pi/2 else a += pi/2
    end for
    return result
end function

We're just defining a function here, not actually calling it, so if you run now it shouldn't behave any differently. But let's take a moment to understand what's going on.

This code is somewhat similar to the diamond-positioning code we had before. It's basically defining a four points arranged in a square that moves around, scales, and rotates, sampling different areas of the sprite texture.

First we calculate a center (cx, cy) position that depends on the value t (representing "time"). When you read cx = 0.5 + 0.25 * sin(t * 0.13), think "cx is going to vary around 0.5, by up to 0.25 in either direction". The factor 0.13 controls how quickly cx varies with time. cy is similar but varies at a different rate.

Then we calculate an angle a, as a straight-up multiple of t. This makes our square rotate steadily with time. (What would happen if you threw a factor of sin in this one too?) Finally, we calculate a radius r that uses the same sin trick to vary by +/- 0.08 around 0.25.

With our center, angle, and radius ready to go, the for loop just calculates each point and stuffs them into result. But note the if statement that adjusts our angle after each point. When flip is true, we subtract pi/2 (90°, or a quarter circle) as we go; otherwise we add it. This is what flips the texture on every other diamond, so that they mesh properly at the edges.

Animation!

edit your code again, and paste in this final piece:

while not key.pressed("escape")
    yield
    t = time
    //t = mouse.x/100 + mouse.y/71
    for i in range(n-1)
        display(4).sprites[i].setUVs uvs(t, i%2)
    end for
end while
key.clear

This is the main loop. We start with a yield, as all good main loops do, fixing the animation rate to 60 frames/sec. Then we choose a t value equal to the time (or, if you uncomment the line after that, a t value that depends on the mouse!). Then we just call setUVs for each of our diamond sprites, passing in t, and with flip set to true (1) for the odd-numbered diamonds.

That's it. Run the program now, and you'll be in trippy kaleidoscope land! But you're not done. Now you get to do the fun part:

Tinkering

This is code that just begs to be played with! Here are some places to start:

Change the texture loaded at the top of the program! This makes a dramatic difference in the overall feel. Try both of the ones above, or try making your own. (Or ask an AI to make one for you.)
Change the value of n (number of diamonds) at the top. 4, 6, 8, and 10 all work well. But push it till it breaks! What happens if you use 5 or 7 or 30?
Uncomment that t = mouse line, and instead of animating with time, you can actually control the thing by moving your mouse around. Play with the constants on that line. Or, can you think of useful ways to combine time and mouse position?
Change the constants in the uvs method. Can you find values you like better?
Throw a .mp3 or .ogg file of background music into your folder, and have your program load and play it.

It's such a small program, but so fun to mess with. There's a good chance this will end up being one of the built-in demos in Mini Micro 2, but for now, only those sharp enough to follow this blog post will get to have that fun. Enjoy!

DEV Community: JoeStrout

The Mini Micro Desktop GUI

A fully functional desktop?

MiniScript Weekly News — June 25, 2026

Development Updates

Community Projects

Show and Tell

Discussion Highlights

Upcoming Game Jams

Computed Lists in MiniScript 2

Computed What, Now?

Our Solution: Computed List

What Stays Computed

When It Can't Stay Computed

Performance

Life is Good

Announcing MiniScript 2 Preview Builds!

Improved REPL

New error Data Type

Frozen Maps & Lists

Function Notes & info

Improved Performance

Right On Track

Please Help!

MiniScript Weekly News — June 05, 2026

Development Updates

Community Projects

Community & Discussion Highlights

Events & Outreach

Upcoming Game Jams

MiniScript Weekly News — May 27, 2026

Development Updates

Community Projects

Discussion Highlights

Community Notes

Around the Community

Upcoming Game Jams

Where in the World Am I?

Finding Your Place In the World

Don't Tell Me, Show Me!

Now in Animated 3D!

Never Be Lost Again

MiniScript Weekly News — May 14, 2026

Development Updates

Community Projects

Discussion Highlights

From the Blog

Upcoming Game Jams

HWYDT: Turning the Page

Challenge Accepted

Carving up the Page

Computing the Page Shape

Incorporating Into Your Game

HWYDT: Swinging from Vines

The Venerable History of Vine-Swinging

The Big Picture

Preliminaries

Swingy vines

Our Hero, Kip

Camera, Final Setup, and Main Program

Full Program

Taking it Further

MiniScript Weekly News — April 30, 2026

Development Updates

Community Projects

Discussion Highlights

Upcoming Game Jams

Make a Mini Micro Kaleidoscope

The Big Idea

Getting Started

Setting UVs

Animation!

Tinkering

New `error` Data Type

Function Notes & `info`