[Martin Taylor 2104.03.22.10.18]
[From Adam Matic 2014.03.21 1120cet]
In my experience PCT research is vary hard to do. The segment that requires modelling especially so. Programming skills are a must, and they are only one part of creating valid experiments. I think we should try making it easier for people to do modelling, first easier for programmers, and then easier for non-programmers.
W. Zocher's and Bill's SimCon software, if I understood its purpose right, was to be such an environment. It's a simulated analog computer, and with today's programming languages can have a graphical interface instead of the old textual interface, and we could exchange models and compare how they perform, create different input and output functions and so on. Perhaps we could add additional functionality to it, such as 'visualization' of certain variables. Or 'sounding' of them.
Dag helped me locate the source code in the CSGnet archives. It's on my list of projects to make a JavaScript version of SimCon, so it could be both online and offline, on multiple websites. I'll make it a public project on github so anyone who wishes can contribute in programming.
Adam
That sounds like a wonderful project. But the point of this particular message is to let the community know of another similar project that might well be a complement to Adam's. First, a little background.
Maybe 20 years ago Allan Randall and I (really him under contract from me when I was still employed) used a graphical programming language to develop something we called a "Control Builder". Using the Control Builder, you could place icons of control units on screen and link them up to make arbitrary structures of hierarchic or non-hierarchic control. This project was never finished to the degree that it could be made widely available, and until fairly recently it languished in the depths of history.
Three or four years ago, I had a notion to develop a game that could have several skins that made it look like a series of different games. Underlying all of them would be the same basic structure, and that structure would allow for comparisons of players' performance levels against theoretical optimum performance levels based on a PCT analysis of how the game could be played. Allan and I investigated several different programming platforms, and settled on LiveCode as the most suitable. LiveCode is a grown-up version of the old Mac "Hypercode", and is in continued development. Many old Hypercode programs will still run under LiveCode, and most of those that don't require only a little tweaking. It was free for non-commercial use, but was highly recommended even for enterprise programming because of its claims to reduce programming time by a substantial factor. One of its advantages is the ability to run, debug, and fix your program without going through the separated stages of code-compile-run-debug-fix involved in most programming. The other advantage is that LiveCode is free if you don't want to sell your work.
When we got into game design and used LiveCode a little, it seemed that the one thing it lacked for our purposes was a true object-oriented structure, which would facilitate a lot of the programming, such as encapsulating the concept of an Elementary Control Unit. So Allan started a project that we call "Allez-Oop" (Let's go OOP), written in LiveCode, to provide OOP capabilities as a constituent part of the LiveCode system. Last year, we offered to sell what we (or rather Allan) had done to the LiveCode developers, but they asked that we test it by building a substantial project, and come back next year having done so.
That's where the old Control Builder comes in. Allan has resurrected his old program and is recoding a rather better version in Allez-Oop, which we hope to be able to make public in a few weeks. The idea is threefold. Firstly it could be used to model and complex control structure, say for experiments in reorganization such as the Arm Demo. Secondly, it could be used to test models of human performance. And Thirdly, it could be used to create environments that include intentional elements, for the game we hope to build. Most of the user's interface is graphical, but since Allez-Oop is LiveCode, the user should also be able to recode any part of it. I expect it will be rather rudimentary when it first is made public, but we shall see.
If it is possible to get LiveCode and Processing to play nice together, maybe the two projects could be of mutual assistance. Anyway, I though people on CSGnet might like to know of Control Builder, since Adam mentioned his lovely project. I hope we can get a beta of Control Builder out before too long, so you can find all the bugs that will no doubt be in it (or in Allez-OOP).
Incidentally, I do hope to have a revised version of my Flexible Tracker environment for running tracking experiments out for testing before too long. I had expected it to be out months ago, but all sorts of other things and difficult programming bugs have go in the way. It is written in Processing.
Martin