A project like Stacksmith is a huge undertaking. To make it achievable, it will be split up into smaller milestones that should result in regular releases that will already be useful to a subset of its target audience.

Road Map

Game Engine

The first milestone is intended to be a simple 2D game engine. Enough to create a point-and-click adventure, a train set, or maybe a tower defense game. HyperCard already is very graphical, so lends itself to such games, and most games live in a single window and have little platform-native UI, which means most of that can be postponed for a later milestone. Main features needed for this are:

  1. The editor needs to allow creating and assigning icons, and resizing and positioning elements has to work well. We need working undo. Otherwise creating a game with Stacksmith would be a chore.

  2. We need animation. This includes just flipping through icons with code, visual effects for navigating cards and hiding/showing objects, but also bezier paths so we can move an object along its points.

  3. We need sound output. Ideally a bug-free “play” command that plays melodies, but just playing a sound sample would be enough for this milestone. We’d also need support for importing sounds in the editor.

  4. We need support for saving state. Either by implementing file access, or by saving changes to a stack (which would be un-editable in a shipped game) as a diff somewhere, or by making sure a second stack can be created and accessed using scripts.

  5. This could include support for draw graphic objects (see below)

Personal Database

The next milestone would be to make sure Stacksmith is suitable for use as a database.

  1. Most of this would probably just be performance optimizations to stack navigation and loading. Also over the web.

  2. We’d need a fast search, probably using an index.

  3. We’d need a working “sort” command

  4. We’d need to make sure the “mark” and “go next marked card” etc. commands work reliably and quickly.

  5. We’d need support for the user changing media used by parts (e.g. to make an image database that either imports or references images or sounds)

  6. This could include support for showing lists based on contents in cards.

  7. This could include support for printing.

  8. This could include support for generating reports that can be printed.

Standalones

  1. We already have support in Stacksmith that it opens any stack named “Home.xstk” in its Resources folder. Now we’d need UI for building a standalone from a stack by creating a copy of Stacksmith itself and copying the file into it. Bonus points if we’d then properly codesign it.

  2. We’d need support for creating your own menu bar full of menus. This includes an editor as well as syntax and saving the objects to the stack and to make a menu bar current in some way.

  3. We’d need support for customizing the about screen at the least, multiple windows (i.e. multiple stacks per project) at best. But the latter would require some hard decisions about syntax.

Drawing Application

  1. We need vector shapes like ovals, rectangles, rounded rectangles, lines, bezier paths (= polygons, too), images, groups.

  2. Vector shapes would need to be optimized so you can have many of them and they’ll still load and draw quickly, e.g. by only creating one actual UI object for a sequence of draw graphics that don’t have scripts anyway.

  3. Boolean operations? Clipping?

  4. Add UKPaintView back in, both for the card picture and for editing images in-line?

  5. Export of graphics (both the entire card’s appearance, or individual images to write them back out after editing)

  6. Filters?

  7. Groups should work with all objects, not just with graphics.

Custom UI elements

It should be possible to create your own custom UI elements and replicate them without having to update each manually whenever you fix or extend them. This should include buttons, fields (in-line objects, but I doubt we can allow customizing the text layout engine), and list/table cells. Ideally also custom menu item views.

Bootstrapping

Eventually, it would be great to have a version of Stacksmith that could be used to build Stacksmith. At the least, any bit of UI that Stacksmith has built in should be possible to implement using stacks and scripts, but then be customizable. Selecting buttons and showing selection handles should be scriptable and it should be possible to extend the “fake editor” UI built this way by looking at properties and handling messages.

Advanced IDE

All during this process, we will try to add modern IDE features.

  1. More graphical programming (a la Prograph/Marten, Scratch or Automator, with an eye towards Button Tasks and SuperCard’s ClickScript)

  2. Support programming by discovery by adding small iPhoto-style pop-overs that help you experimentally find out what messages to handle to get a certain result, show you what messages are happening in the app etc.

  3. Focus on forgiveness. Add code that copes with less logical but more human expressions like “add 15 to the selectedLine of me” instead of “add 15 to line (the selectedLine of me) of me” etc.

  4. Add a “stack canvas” that shows the entire project and all objects in it, but can also be locked down and filtered to be a quick game map.

  5. Add more “programming by example” stuff, if we can come up with stuff that we can detect and offer to do for the user.

  6. Add more feedback to the code editor, including parsing the code, showing all variables, and showing results of the scripts in a nice way (without actually executing the scripts and thereby modifying the user’s stack). Like Bret Victor’s stuff.

HyperCard Clone

At some point, we might put an effort into making Stacksmith more compatible with HyperCard stacks.

  1. Special modes for imported HyperCard stacks that switch rects to being comma-delimited lists, styles in fields to be more like the old ones etc.

  2. Special visual appearance for parts so they look more like they did in HyperCard

  3. We could even add modes that anti-alias old icons so they look better, or that don’t anti-alias any of our part graphics (including text!) so they look more like the old stuff.

  4. Add the AddColor command (as a built-in command, we already parse the data in our file format), so old color stacks look right.

  5. We could implement compatibility code for certain popular XCMDs.

  6. If we want to go overboard, we could add a minimal OS 9 “emulation” that would run XCMDs.