Microgame compiler experiment (early WIP)

I really like WarioWare DIY but it's got a lot of limitations I don't like, such as a lack of integer variables and no buttons, and it'd be nice to have something that wasn't as limited. I also feel like the NES would be a cool target for playing microgames on (and it'd be awesome to have a big 512KB cart stuffed with tons of microgames as a community project).

I've been working on an experimental compiler specifically for making microgames with, where you define a map, define a list of actors, place the actors on the map in locations and describe the behavior of the actors, primarily through chaining together premade behaviors.

So far it's actually looking pretty feasible? I've got things to the point where this:


gets translated into this:


and I've got a whole bunch of behavior primitives written, though the actual rest of the engine is far from done, as is any actual stuff to put the microgames together in a ROM, though I imagine that wouldn't be hard. The rest of the sample file I'm using is here with the output here. That shows off some math (including optimizations to use INC and DEC when possible), and conditionals using OR and AND, and other features.

I guess the question is, is this worth doing? Expressing it through JSON like this doesn't really seem that much easier than just writing the instructions yourself, though it could probably benefit from being able to accept a file that's in more convenient-to-write form, where you could add comments. I'm not really interested in making a GUI editor for this, but maybe an existing one could be tweaked to work with this?

I like this idea. The Json like dialect may be good 'cause it can be produced easily by a GUI driven application (even visually) if somebody is willing to create one in the future. I find it cumbersome to write it myself, but it's easily understandable and parseable by machines, so why not?

If you don't mind reinventing the wheel (writing your own parser) once you have the workings well defined, a VRML-style syntax would avoid quoting everything, comma separation between properties, and the need to put code in strings.

Some alternatives for the syntax are YAML (which is a superset of JSON, so JSON code can still be used too), or RDF, or Lisp.

I also notice the 6502 code could be optimized in some ways, such as a tail call optimization to WinGame.

So I actually went and wrote more of the stuff to actually make the compiled microgames runnable. Observe this test "game" that just lets you run away from enemies that mostly target you but sometimes go off in random directions. I don't have actor+actor collision in yet (or the concept of winning or losing a game at all) or I would also have them react with the player.




(using sprites from Chase and other things from http://wiki.nesdev.com/w/index.php/File ... et.chr.png for placeholders for now. I should draw some of my own simple premade graphics for this)

I actually wonder how hard it would be to make a simple clone of the Scratch UI in HTML5. I might try to do that later on.

I've started using YAML in place of JSON for files that I want a human to be able to edit, and it's great from that perspective. It's just a lot easier to read/write manually. This might be a good idea.

Honestly anything I can still get a Python dictionary out of can be easily swapped in where JSON was. A lack of comments in the input game sounds like it'd be a huge pain for more complex games which is another reason to move away from JSON.

That's what made it easy for me to slowly swap in my current game. Just replace a json parse with a yaml parse (of which there are python libraries for both) and be done with it. My one beef is that the default python yaml parser is fairly sensitive about whitespace details. I've had a few yaml files that validated with every yaml validator I tried other than python.

That's a very interesting experiment.
Its declarative format could easily be generated with a tool such as Blockly, owl-bt, Edgy, Waterbear or RPD.

I figured there was probably a tool out there that I could use! That would be a lot better than making my own, and I could focus on the actual engine and the compiler instead.

I'm glad to help.

I also just found something that could maybe be adapted for the task: Mobile Microgame Maker
Whether this one would require more or less work than the alternatives, it would be up to experimentation.

Here's the above code but in Blockly. It took a long time to define all of the blocks but I should have all of them in so far and it probably won't take much longer to actually get the game defined here into the JSON format.

I think I'll probably have the actual art aspect and the actor placement in a separate part of the tool, instead of being inline with the code.

This is awesome. Congrats.

I find it really striking how similar that looks to ZZT's or Megazeux's built-in programming languages.

The tool seems to have great potential. Can't wait to see it working!

This is what I've been expecting from many "no coding required" game engines. Basically, be able to set the actors' movements and collission events without too much complication having to write my own code from scratch. Game Maker promised no coding and only drag and dropping, but for a platformer, you always have to code either way. This seems to be like my dream come true! But then again, if it's GPL, I better move on.

Remember that the intended scope of the project is still just making simple non-scrolling games that last 4 or 8 seconds, though I really want to make sure that everything within that scope is done as well and as friendly as possible. The time limit won't be mandatory and you'll be able to try to make more complicated things if you want, but it's going to be a much better fit for a Pac-Man than a Mega Man.

There will be no restrictions placed on games made with the tool, and the game engine itself will be under a permissive license, but I don't know which one would be the most applicable. I dunno what I want to do for the compiler but I don't really have a good reason not to just go ahead and make that permissive too.

The main reason for excluding scrolling is it pretty much requires 16-bit numbers, and then you've either got a situation where the tool is more complicated and the user and the compiler both have to care about the difference in two different number sizes, or where all numbers are 16-bit and that sounds really inefficient. Maybe something where you move from room to room could work? People seem to be putting up with it for NESmaker and it was fine for Zelda. :p

You can make great one-screen-at-a-time games, see Battle Kid games for a nice example

Does this sound too limiting? I'm trying to figure out how actor graphics should work, and a hardcoded 16x16 image per actor type probably isn't the way to go.

• List of up to 64 animations per microgame
• New variable per-actor named ActorAnimation that points to one of these, but also specifies horizontal/vertical flip
• "Set animation" action to set this variable, used by each actor's Initialize routine as well as whenever else wanted
• Animations continuously loop; game's frame counter is used to choose the animation frame
• Animations can be 1, 2, 4, or 8 frames long, and run at 60, 30, 15, or 7.5 fps
• Animations use a single palette throughout all of their frames
• Animations consist of a series of tile numbers
• Animations separately set a width and height (8, 16, 24 or 32) used for collision boxes as well as the number of sprites to use

Abusing animations as a delay for game logic like in WarioWare DIY would be out of the question and you could just use a per-actor variable as a timer for a delay instead. You could also change animations in response to pressing keys.

Here's an example of how changing between animations during an actor's behavior will look. I'm just gonna go ahead with this and I think it'll be fine. A very nice attribute of the whole compiler and abstraction stuff is I can change stuff without breaking old games if I ever need to. Don't know how I want to define animations but I'll figure that out or put in a temporary solution for now to get things working.

Sample assets! It's a mixture of graphics I reused from games I released, games that never saw the light of day or made any real progress, and new stuff. Probably good enough for people to play around with defining their own actors before diving in and actually drawing custom graphics for their games.

As much as I think and have observed, the two best permissive licenses are the MIT license and Apache License 2.0.

The assets look cute and very good for a start.

If this compiler and an NES emulator are bundled as an Android app, I think this would be a nice portable tool for making quick games.