Hi guys, this is the author. (thanks pete for pointing me to this thread
)
There was a problem with the alpha-2 build which made it not work, I uploaded a
newer Windows package which should work.
As a warning, the current alpha release is pretty feature-barren, there's not much of a GUI and it's hard to figure out what you should be doing. Future releases will improve this, so the safest thing to do is wait for the beta release. In the meantime,
this doc is good to read.
though the "live code updates" would be restricted to scripting languages (from the screencast, it sounded like the live-update-supporting bit basically is a scripting language built around some underlying non-live-updatable system that handled persistent state and other such things; did I interpret that correctly?).
Yup that sounds about right. I think pretty much any live system is going to have some "core" code which can't be changed while running. But anyway, a typical user won't need to change the core code; they should be able to write a complete game from scratch without restarting.
For comparison with existing engines, yes it's definitely true that there are some great engines that already have these sorts of features (Unity being one of my favorites). I think the difference is just the style of workflow. With one of those engines, if you want to add new assets or modify configs, you have to click through a bunch of menus to do it. That's a fine way to work, and lots of people prefer it, but my preference is to do everything with source text. And I figured that maybe there are other people who also want to work that way. Life is nice and simple when it's just you and a text editor.
Also yeah, by default it also supports live updating of asset files. The user only needs to write the line:
image:draw("MyImage.png", [x y]) , and the system will automatically reload MyImage.png when it changes. (Although in the current version, the image:draw function doesn't work so good, so don't actually try that yet
)
Like Don Andy says, I don't think Circa+Plastic will be great for any big serious projects (at least, not for a while). Rather it will be more like Processing where it's good for quick experimenting and prototyping.
I'd be curious how this compares to something like
Chuck.
Chuck is cool, their focus is primarily music generation. So they have much better support for things like timing and concurrency, because that stuff is very helpful for their domain. I don't think they have to worry about preserving state as much. Also they don't have as much support for graphics or user input.
Developer
