Flicklikes and Expressive Power

Flicklikes are a collection of engines based on or inspired by Flickgame. Flickgame is a simple game making tool where you draw scenes using a limited pallet. Colors can be made clickable and link to other scenes. The only state Flickgame can express is the current scene.

What interest me about Flicklikes is they invert the typical relationship between art and scripting. In most systems, scripting exist to consume art. But in flicklikes, art exist to consume scripts. Code as become the asset and art is the default unit of work. Flicklikes represent on possible example of art-first interactive development.

This article is an attempt to classify different extension to flickgame into a heirachy of expressive power. For the sake of this heirachy, assume "image" means something fixed in place.

Type-0: Stateless Single-Image Flicklikes

You know, I never got why the chomsky hierachy counts down?

These are flicklikes that stick to Flickgame's design with no extensions to it's state model. The only state the game can have is "current scene". This flicklikes have no mechanism for expressing locks without combinatorially exploding. When a key for a lock is collected, all path reachable from the lock state must be duplicated for the unlocked state. With multiple keys, ever combination they can be picked up in must all reachable paths duplicated.

This class of Flicklikes represent simple decision trees.

Type-0.b: Stateless Multi-Image Flicklikes

This is a simple extention to the Flicklike model: multiple images. Scenes are now composed of many images collaged together. This can save a lot of time when scenes might only need on object changed or removed. However, since this does not solve problem that Type-0 Flickliks have with expressing locks, it is just a subtype of Type-0s. I'd don't think any tool occupies this niche of Flicklikes. Flicksy is actually far far more powerful as it has acces to arbatrary javascript for objects.

Type-1: Stateful Single-Image Flicklikes

These are flicklikes that extend Flickgame with the ability to hold state outside of the current scene. Devine's Flick add the idea of keys. When a scene is visited a key can be given to the user, unlock a pathway for another scene.

Woolietail extends upon flick even further. Every color has a high-state and a low-state. Links can also have a high-state path and a low-state path. This allows Woolietail to make more complex decisions based on the state of the player.

This is the first level where flicklikes can do computations. It's possible to encode things like simple counters and binary to decimal decoders with Woolietail.

This removes the cominatory explosion when needing to implement locks. However, Type-1 flicklikes cannot express things such as "layers". For example, say you had a game where you could dress a character up. If you had shirts and pants, then you'd need a scene for every combination of these two item types. We've defeated one form of combinatory explosion, but yet another remains.

This becomes a problem for something like a persistent UI. The UI would have to be drawn several times over which take substantually longer than scripting the button to behave different depending on what is currently active. Additionally, for things like the clothing example, the work explodes. Ideally, each item of clothing added results in a constant amount of work.

This problem is kinda why I feel so many transformation themed things where you have multiple curses on your character tend to be limited to the realm of text adventures. Even in more powerful tools, this kind of image composition can rapidly spiral out of control. 3D games, I think, are less prone to this thanks to far more powerful blending abilities.

Sometimes I wish 2D systems enjoy the same kind of blendshape abilities that 3D systems can have. Flash games were actually somewhat rich in these systems.

Type-2: Stateful Multi-Image Flicklikes

These are flicklikes which remove the restriction that scenes are only one image. Now, a scene can have many images within it. Two examples of this are Flickscript and Flicksy. Flickscript adds the the idea of scriptable layers. When clicked a layer can trigger a script and make stateful decisions based on the visibility of other layers.

Flicksy goes futher. Flicksy lets you create a library of images that you can compose together into scenes. Each of these images can have a script attached to it. Scripting is done in JavaScript, however Flicksy provides a baseline API it recommend.

However, both of these systems fall short in their ability to relocate images. At the start, I said "assume images are static". This was because so far, every flicklike has had images pinned in place. Say you wanted a character to walk across the screen. In Flicksy, you'd need to make one scene for every location. In Flickscript, you'd need one layer for every step. The final layer removes this last restriction on flicklikes.

Type-3: Stateful Multi-Ojbect Flicklikes

This is the final layer I can think of. At this level we are no longer working with static images with scripts, but objects which can be moved, positioned, and spawned into the world. We essentially have a full game engine at this point. Except with illustration and collaging at its core.

There are a few candidates for this level. A loose fit is Tote as sprites can be offset via it's sprite pinning and relative positioning support. Another candidate for this level is Scratch. It's fully actor oriented with scenes composed of many sprite each able to move and act indepdent of each other.

A final tool I think is a possible fit for this level is Kooltool. It's a 2D game maker with support for very limited scripting. It features the path command which lets you move objects around the world.

Bye

Okay, I think that's basically it? I can't think of anymore levels. Type-3 Flicklikes basically reach "full game engine" levels. You may have noticed the ommission of Bitsy. Bitsy would probably be like Type-3? I can't really see anything that lets you move objects. However, it just feels to much like a typical IDE for me. Same for Decker. It especially shows with editing scripts as you lose the ability to see your art while scripting. I consider that a huge disqualifier from this list.