There are a fair number of systems that can be classified as ``investigative simulations,'' i.e., systems where authors have developed a very complex model of a system that is realized with code and/or equations. Examples include SimCity [Maxis 1989], STEAMER [Hollan, Hutchins and Weitzman 1984], Cyclepad [Forbus and Whalley 1994], and SHERLOCK [Lesgold et al. 1993]. The numerical engine can be often be explained qualitatively to the student, and in certain controlled situations can be used in conjunction with a coaching agent to provide instruction.
The problem is that the simulation engine tends to be very difficult to build and even harder to talk about intelligently. The engine tends to be complex enough that writing a software mechanism to recognize pedagogically interesting qualitative model states ranges from hard to nearly impossible. This means that making the simulation an effective teacher tends to be a secondary consideration to building and tuning the simulation engine. Projects like SHERLOCK show it can be done, but it's a challenge even for seasoned programmers and AI experts.
INDIE has taken a different tack from these systems. Our non-programmer audience is going to have a great deal of trouble building a good simulation. Even if we figured out a good way to let non-programmers construct consistent simulations, for the vast majority of the domains INDIE addresses, such a simulation is more representation than is needed. As mentioned in Chapter 5, we found INDIE 1.0 to have a vastly over-represented experiment model.
Most numerical simulations reflect the domain model as it changes over time, and no time really passes in INDIE's model from the beginning of a scenario to the time the argument is submitted. Thus, we can realize the domain model in a few tests and one or two state variables. This is manageable both to construct and teach around.