Most people who discover MiniScript are delighted at its design and feature set. It covers all the important functionality — things like true lists and maps, functions as first-class objects, and object-oriented programming — while still being minimal and clean, small enough to document in a single page.

But there is one omission that is sometimes a source of complaints: MiniScript, as of now, does not have math-assignment operators like += and -=.

A Mini Micro user today asked me to explain why it was designed with sprites that are retained between frames, instead of having users explicitly draw them on each frame. This is an insightful question! It's the difference between retained mode and immediate mode graphics.

The Common Gateway Interface, or CGI, remains a valid and simple way to create dynamic web pages and services. MiniScript is an excellent choice for creating CGI scripts. In this post, we'll go over how to set up your web environment and get started making your own CGI scripts, along with some simple examples.

The import function is not a standard part of the MiniScript language, but it is a feature common to many MiniScript environments, including Mini Micro, Farmtronics, command-line MiniScript, and Soda. In this post, we review how import works, and describe some techniques for advanced users.

Version 1.1 of Mini Micro included a couple of very useful additions to the stringUtil module. If you aren't already using the new fill and match methods, you probably should be!

I was live streaming a coding session today, wrapping up a Tetris clone in Mini Micro. All was going swimmingly until suddenly we noticed a bug: after clearing a line, subsequent pieces would sometimes stop before hitting anything. Upon closer inspection, we noticed that the higher-up lines, after moving down to fill the cleared row, often had blocks in the wrong place.

What ensued was an abnormally long debugging session. I tried confessional debugging; I tried walking through the code; I tried checking my assumptions by having the code print out what it was doing. After 20 minutes of this I was still stumped. In desperation, I reached for a tool I should have brought out much faster: the validate method.

MiniScript is most commonly used either in the Mini Micro virtual computer, or embedded within some other game or application. However it is also available on the command line. A command-line MiniScript user asked me the other day: is there a way to clear the terminal window from code?

The answer is, yes and no. There is no built-in API for it, but in most cases, it can be done with an ancient set of tricks known as VT100 escape codes.

As more and more people discover MiniScript, the question is occasionally asked: why? Why was MiniScript created, and why should someone use it rather than some other language?

It's a perfectly valid question, so in this post I will try to clarify. My purpose is not to convince anyone of anything, but to explain why, after years of using other scripting languages, I felt compelled to create something new. I'll do this without attacking other languages, since every language has its fans and I don't want to kick anybody's dog; instead I'll focus on what I think is really cool about MiniScript, and how it offers a collection of advantages that, taken together, can't be found anywhere else.

MiniScript has been available as a Unity plugin since 2017. But it has been such a success with its users that it deserved wider distribution. MiniScript in Unreal games, MiniScript on the command line, MiniScript in your browser... why not? And while it was great to get a little financial support for working on MiniScript in the early days, in the long run keeping it commercial only slows down its adoption. That's why, as of today, MiniScript is open-source.

I've been doing a lot of development for the Oculus Go lately, which is an absolutely marvelous VR platform — inexpensive, easy to use, and high quality (when the development is done right). For the most part, developing for it in Unity is straightforward; the camera automatically tracks the rotation of the headset, and the OVRInput class provides controller tracking and touch/button inputs.

But at some point you may need to use some part of the extensive "Oculus Platform" SDK. This provides information about the current user, such as their Oculus username, and also provides all manner of match-making and social services, including efficient voice (VoIP) chat. Unfortunately, accessing this SDK isn't nearly as simple as you might expect. This post explains how to do it.

I used to be just like you. I had a Downloads folder full of junk, and a desktop full of clutter. Screen shots, temp files, email attachments, and more filled my computer like leaves on the ground in autumn. Now and then I would try to clean up the mess, but it was a chore that all too often went undone.

Then I made a DailyPurge folder, and my whole life changed.

I have long thought that Unity did not really support configurable input out of the box — at least not without using the ugly default Graphics/Input configuration dialog (which no polished game would ever inflict on its players). Particularly if you wanted to support hot-swappable joysticks or gamepads, I always believed you had to use some third-party plug-in.

But I recently discovered that this is not true! Making configurable, hot-swappable input in Unity can be done without any plug-ins, and it's not even all that difficult. Read on to see how.

A lot of games in Unity are organized into several scenes, most notably a title scene and a play scene.  If your game has background music, you're likely to want different background music for each scene.

Just sticking a music clip on an AudioSource in the scene would accomplish that, but the music would cut off abruptly when you change scenes, which is jarring and unprofessional.  Much better to fade it out over several seconds.  That requires not letting the object be destroyed when the scene changes, and handling the scene-change event — which thanks to recent changes in the Unity API, is not as easy as it used to be.

A frequently asked question in both the Unity forums and on Unity Answers is: How do I make a projectile arc to its target, like an arrow shot from a bow?  I've seen (and given) lots of different answers to this question, and honestly, most of them are unjustified hacks.

The right (and easy!) way to do this is: just add a bit of arc to your standard movement.  Objects in freefall (ignoring air resistance) follow a parabolic arc, and the equation for a parabola is very simple.  So, we can just use that equation to compute how must extra height we should have, and simply add it to our Y position, and the job is done.

Cheat codes are secret ways to alter the functionality of a game.  It's a term that makes me cringe as a parent, since we teach our kids never to cheat — but once a game starts to grow complex, cheat codes are absolutely essential testing tools.  They let you bypass minutes or hours of gameplay you already know is working, in order to get to the part you're trying to fix.

So, how do you actually implement them?  This post explains how we do it in our Unity games.

One of the most general and common tricks ever to come out of industrial control theory is the proportional–integral–derivative controller (PID controller), sometimes known as a "PID loop."  It is a simple equation that you can use to control any one-dimensional variable, such as a throttle, a motorized hinge, etc.  All it needs for an input is an "error" signal — that is, a measure of how far off something is from where you want it to be, plus three constants.  Most importantly, it does not need any model of how the value it's controlling relates to the output.

In this post, I'll give you well-encapsulated code for a PID controller in C#, and show how to use this in Unity to control the throttle of a hovercar.  The hovercar physics involves momentum, drag, and controls that don't respond instantly, just like a real hovercar!  But the PID controller doesn't care about any of that; once you have the three constants tuned, and hook up the error signal (in this case, the difference between the current altitude and the altitude you want), it does the rest.

In many game projects, I've often found the need to execute some bit of code at a later time.  Often this relates to audiovisual flourishes.  For example, when the player does something scoreworthy, we may want to start a particle effect and sound right away, but then spawn a different effect after a short delay, and actually update the score a while after that.

You could certainly spread the code to do those things out into different classes or methods, triggered by events or other custom code.  I've certainly been known to do that; I love Unity Event, and most of my classes that do anything over time expose events for when they start and finish their work, making it easy to chain them together.

But sometimes, dividing up the logic that way makes the code less clear, not more.  There may be one place in the code that is handling everything related to this set of actions, and the only thing driving the code apart is that you want it to happen at different times.

CallLater was created to handle just this situation.  It lets you write some code, right there in the middle of a method, to actually be run later, after whatever delay you specify.

For our High Frontier video game, we wanted a data file format that would be easy for people to read and write.  This is partly for our own use — we would be hand-editing files defining various parts of the game internally — and partly for mod authors, who would be creating new content for the game.

The big players in the serialization space are JSON and XML.  XML is, to be blunt, horrible.  It's fine for data that is only ever looked at by computer programs, but for anything that might be read or written by a human, it's just awful.  JSON is much better, and it's what we've often used in the past.  But it too has more syntax than feels necessary.  And at the same time, it lacks some features we really wanted, like comments.

So we have designed a new serialization format: GRFON (General Recursive Format Object Notation).  We've been using it for over a year now, and loving every minute of it.  And today, we are making it available for everyone else to use too, under the permissive MIT open-source license.

When doing rapid iterations of an app (a cornerstone of agile development), testers sometimes find themselves with an older version of the app.  This could be because they didn't get the update email, or they clicked the wrong link, or DropBox didn't sync like it's supposed to, or something got cached along the way... whatever the reason, there are few things less helpful than getting a bug report for something you've already fixed.

In C/C++, it's easy enough to use the standard __DATE__ macro, which the C preprocessor fills in with the actual build date.  You can just display this on the title screen or wherever, and testers can easily see whether they're running the latest build.  But, surprisingly, C# doesn't have any such feature.  This makes displaying the build date in a Unity app a bit harder.

Fortunately, it can be done.  Here is the arcane magic you need.

I've been a cross-platform developer for many years.  Lately my development tool of choice is Unity, which makes it trivial to build Mac, Windows, and Linux apps right on my Mac.

However, there is an important step that Unity doesn't do for you: code-signing your built apps.  If your apps aren't signed, then recent versions of Windows (or Mac OS X, for that matter) will throw up scary warnings and make your users jump through extra hoops to run them.

I'm currently doing a job where I need to take 3D polygon data and display it in Unity.  These polygons are planar, but oriented arbitrarily in 3D space.  Moreover, they can contain holes (possibly multiple holes).  Think of a building wall with window cut-outs, and you'll get the idea.

This turns out to be a surprisingly thorny problem in Unity.  There is a simple script on the Unity wiki called Triangulator, but it only works with Vector2D and doesn't support holes.  I found a blog post on Advanced Triangulation in Unity, but it was neither sufficiently advanced (only works in the XY plane) nor actually in Unity (it wrote each polygon out to a file, invoked an external command-line tool to do the triangulation, and then read the result back in).

The utility referenced in that blog post is called Triangle, which is widely regarded as a very good triangle library.  It's open-source C code, so one could make a Unity plugin out of it.  But it's not licensed for commercial use, which is a problem for this project.  Also, making a native plugin means setting up a build chain for every platform you want to support.  For both reasons, I kept looking — I really wanted something in pure C#.

Unity has provided a built-in state machine editor for managing animations since version 4.  This is the officially recommended approach to animating a game character.  However, it often leads to game logic being divided between code and the animator state machine.  I would prefer to have all my game logic in one place, to simplify development and debugging.  Moreover, in some cases — especially simple 2D sprite games — the Animator can seem like more trouble than it's worth.

To help clarify the pros and cons, I built a 2D game character using three different approaches:

1. A simple home-grown animation system that eschews Unity's built-in animation support completely.
2. Use of Unity animations, but without using the Animator state machine; instead each animation is invoked directly from code.
3. Full use of the built-in Unity components, with all game logic in the state machine, and only minimal supporting code.

For the rest of the story, see the full article on Gamasutra!

Unity had a "Live Training" demo called Events: Creating a Simple Messaging System.  This is often pointed to as an example of using the UnityEvent class that was introduced in Unity 4.6.

While this was a fun and educational video, it uses UnityEvents in a very odd way, wrapping them in a string-based notification system and hooking everything up in code. Honestly, you could have done exactly the same thing using standard C# events, and it wouldn't have made any difference. (Indeed, prior to UnityEvent, many Unity developers — myself included — did exactly that.)

So I decided to make my own video, accomplishing the same demo but using UnityEvent the way nature intended. The result is a lot less code, easier to maintain, and harder to screw up.

I've  been teaching my son C# programming lately.  This is a great choice, because it's the best language to use with Unity, and with Unity, he can make games for virtually every platform under the sun. With some luck, he'll be able to make enough money in the various app stores to pay his way through college (or at least pay his own car insurance).  And as a bonus, when you know C#, you can also develop native apps for Mac, Windows, iOS, and Android, using various toolkits (such as MonoTouch for example).

However, the code-run-test-debug cycle is slower in Unity than I would like for his purposes.  Learning a language is easier when you can play around with it interactively.  This is especially true when you're working through small programming problems like those at Project Euler.

Our popular drawing/painting application, InkPaint, has been updated to version 1.6 today.

The new version contains an important fix for problem on iOS 6 that would cause it to abruptly exit.

Also, if you're running on iOS 6, we now use Apple's new standard sharing dialog to share your drawings via Facebook, Twitter, email, etc., as well as copy them to the clipboard or send them to your network printer.

The new update is recommended for all InkPaint users.  And if you're not using InkPaint already, please check it out — we are sure you will love how easy and fast it is to create professional-quality drawings.

We've been delving into Coroutines in Unity lately, and ran into a strange behavior today that took all morning to sort out. In brief, a routine we thought we were calling never got called at all -- a Debug.Log as the very first line of the function never logged anything.

We've had a lot of rather philosophical blog posts lately (mostly related to the BOSS text searching system). It seems time to put that aside a moment and get back to some nice, solid iOS coding.

A common pattern for iPhone apps is a tab bar on the bottom, with a navigation stack on each tab. Today, we'll look at how to set up such a structure in code.  (And we'll do it in pure, unsweetened Cocoa for that nostalgic old-school feel.)

Last week, we gave a sneak peek of BOSS, a new approach to string searching. We mentioned a "bit of magic" with regard to the repetition modifiers, * (0 or more) and + (one or more): these would do a lazy match, except at the end of the search pattern, in which case they would be greedy.

We expect this to be the most controversial feature of the whole BOSS design, so it's worth some time to explain all the considerations behind it, why we made this decision, and what the heck "lazy" and "greedy" mean when it comes to string searching anyway.

In the last couple of blog posts, we first reviewed some of the shortcomings of regular expressions (RegEx). We then took a look at parsing expression grammars (PEGs), which are a new formalism that has a lot of advantages for defining (and more importantly, parsing) computer languages. But while they're great for that, using them directly for string searching is a bit of a square-peg-round-hole situation.

So, we at Luminary Apps have begun work on a string matching library that combines the best features of PEG and RegEx. This blog post is the first public discussion of that library. It's called BOSS, and I think you're going to love it.

In our last entry, I bemoaned the shortcomings of regular expressions for complex tasks. (This was after spending a day wrestling with a three-page-long RegEx pattern for finding functions in a C# TextWrangler language module.) I sketched out what I thought an ideal string-matching system would look like.

Well, that was three weeks ago. I've had time to do some more serious research, and it turns out that there is some modern work that is very relevant. It almost fits exactly what we were looking for — but not quite. It's a new construct called Parsing Expression Grammar.

RegEx is handy.  I use it all the time.  For simple tasks, it's quite pleasant to use.  For intermediate-sized tasks, it's acceptable.  But for complex tasks, it is a nightmare to write, read, and maintain.

So, I'd like to suggest that it's time to design an alternative -- something that works just as well on complex tasks as it does for simple ones, and stays readable and maintainable.  I agree with not reinventing the wheel... except when our current wheel is square and lumpy.

New interactive Chess books provide a unique learning experience

FORT COLLINS, July 20 - Luminary Apps today announced version 2.0 of Newbie Chess, a chess program for iOS devices (including iPhone, iPad, and iPod Touch) designed especially for people new to the game.  Version 2.0 adds a big new feature: interactive books by renowned chess authors.

Last week, we presented a method for playing videos that supports external monitors (like the Apple VGA Adapter). But we left out a few finishing touches.

We have a client project that, at several points in the iPad app, displays videos that were embedded into the app. This is an older app, originally written before there were such things as iPad VGA adapters. One might hope that, in the absence of any programming directives telling it otherwise, the iPad would simply mirror its entire display to the video port. Failing that (as Apple in fact has done), you might hope that the MPMoviePlayerController would automatically support the external display. But that fails too.

Since I've been using Unity, I've loved it for the most part. Sure, it leaves a few socks on the floor, such my inability to post to their forum without pestering a moderator for help, or the way an infinite loop in your code locks up the whole Unity environment. But on the whole, it's a really great development system.

Last week, we presented the String class, which gifts the standard Cocoa NSString class with such modern conveniences as operator overloading, allowing the developer to focus more on clearly expressing the intent of the code, and less on arcane 1980s syntax. Today, we're going to look at another Cocoa class in dire need of some help: NSNumber.

We've spent the last month or so considering all the interesting ways that one can use Apple's Objective-C++ compiler to improve Cocoa code. But so far, we've ignored perhaps the most interesting way: using C++ wrappers to improve the standard Cocoa classes.

For the last several weeks, we've been going over how C++ can be mixed with the traditional Objective-C to make your Cocoa even sweeter. But today we're going to cover a somewhat different recipe: mostly C++, with just enough Objective-C to make it work on iOS.

In the last couple of blog entries, we talked in general terms about how you can sweeten your Cocoa with a bit of C++, and covered a bit of history to help us understand how Objective-C and C++ are related.

Now it's time to get serious about actually applying this stuff.

Last week, we gave an overview of how a little sprinkling of C++ could make your Cocoa programming a lot sweeter.  At the end we promised to delve more into details in future blog posts.  So, here we go!  We're going to begin with a little bit of relevant history.

In 2002, Apple quietly introduced the Objective-C++ compiler. Almost nobody noticed. This is a shame, because adding a little bit of C++ to your Objective-C programming can make your code shorter, clearer, more type-safe, faster, and easier to read and write. It is nothing short of revolutionary.

Not too long ago, we were working on an iOS project that involved drawing some custom content that the user can pan and zoom using a UIScrollView.  Because all our drawing was done with CoreGraphics vector-based calls (that is, we're not just blitting any image maps), we thought that it would zoom up smoothly.  Unfortunately, that's not the case; it appears that, under the hood, UIScrollView draws the content to a pixel map, and then just pans and zooms that.  The result is, when the zoom scale is greater than 1.0, the content looks all pixely and ugly.

We have just posted a new demo video, this one introducing Hush For Now, our Android utility for automatically silencing and unsilencing your phone.

A recent study by analytics firm Blaze Software found Android's web browser to be an average of 52% faster than a comparable iPhone.

But as this article points out, they weren't actually using the web browser app on either platform -- they wrote a custom app that used a WebView control on Android, and a UIWebView on the iPhone.

We're working on an application that makes extensive use of Box2D to simulate not just rigid bodies, but also things like ropes, springs, rotary joints, and more.  But we kept finding ourselves frustrated because the joints didn't appear to work as advertised.  Rotary joints were easily pulled apart; weld joints didn't stay welded; distance joints didn't maintain distance; and in many cases, the whole simulation would simply explode, with parts flying everywhere at high speed.  It was like what Egon said would happen if you crossed the streams.

Reducing the timestep didn't help much.  Google searches turned up nothing useful, and poring over the manual didn't provide the clue we were looking for.  But we did finally find the problem, and -- no surprise here -- it wasn't really Box2D's fault.

Following on last week's release of an introductory demo video, here is a more in-depth tutorial video for InkPaint.  Watch over the artist's shoulder as he inks and paints a complete drawing.

Well, we should have done it months ago, but in the spirit of "better late than never," here is a video demonstrating all the key features of InkPaint, the innovative drawing app for iPad.

Luminary Apps is pleased to announce InkPaint version 1.2, available now in the app store.

InkPaint has two new tutorials on drawing fantasy characters, by Sebastien Dardenne.

The Association of Computing Machinery is currently holding a neat programming contest.  Competitors write a program to control a team of virtual children engaged in a snowball fight withan opposing team.

[View in App Store]

Today we released a new version of InkPaint for iPad.  We're very pleased with InkPaint 1.1, and glad to get it to our users, but behind its release is an interesting story — and a cautionary tale for other developers.

Why Unity is my new favorite development tool

Welcome to the Luminary Apps blog!

I know, these "welcome" posts aren't terribly useful, but they're customary.  So, since you're here, let me tell you a bit about who we are and what we do.