The History of GWI

The formal goals of the GWI project were:

• to help people garden more effectively and with greater enjoyment by gaining a greater insight into what is going on in their garden by using an open-ended simulation, and
• to help people learn to garden with less environmental impact by helping them explore the long-term implications of their gardening decisions.

Garden with Insight was developed on both the Macintosh and Windows platforms, though the program ended up in Windows only. The project has included work in several development environments, including Smalltalk, Symantec C++, Borland C++, MetroWorks C++, Visual Basic, and finally Borland Delphi, in which the program is written now. (Paul wrote some translation programs to convert portions of source code from one language to another.) The name of the program went from "The Garden Game" to "Garden Simulator" to what it is now.

We worked as a team on most design phases of the project. Paul did most of the low-level coding, the general architecture, the undo/redo system, the file system, the graphical display, and the 3D turtle engine. Cynthia did most of the translation of the EPIC model, the flowering/fruiting submodel, the plant drawing algorithm, the various window designs, and the artwork, music, and documentation.

What went right, what went wrong

We started out wanting to make a garden simulation that was educational, entertaining, and easy to use, that covered all major aspects of gardening, and was accurate. We decided to work with EPIC (Erosion/Productivity Impact Calculator), an agricultural simulation created by the USDA Agricultural Research Service because 1) it was well respected and validated; 2) it covered some of the aspects we wanted to simulate; 3) it came with large data sets; and 4) it was publicly available. At first we tried to use the EPIC model as a reference, but we found that the documentation left large gaps that only the source code could explain, and the source code was so difficult to follow that to understand it we had to translate it. So one of us spent nearly a year translating nearly the entire EPIC model from FORTRAN to C++. In retrospect, translating the whole EPIC model was a wrong turn for two main reasons.

1. EPIC emphasizes water and wind erosion very strongly, and devotes a lot of complex code to detailed simulations of water movement and runoff. But in a small garden, erosion is not important enough to merit all that attention. On the other hand, simulating home gardening does require a fairly complex plant growth model, to harvest individual cucumbers, for example; but the EPIC plant growth model is very simple and has major gaps (no flowering model, for example). So we spent a lot of time translating source code that we didn't need, and had to write a lot of code that EPIC didn't have.

2. EPIC, like most agricultural models in FORTRAN, is extremely difficult to read and understand from a programmer's point of view. And the EPIC source code is about 17,000 lines of FORTRAN. In addition, our backgrounds were not in soil science, so we were learning as we went. The result is that even after translating EPIC and modifying it for the home garden, we still understand it only incompletely and feel that our adaptation of it is barely adequate.

We also made some other mistakes along the way, including: 1) using Windows instead of the Macintosh (we knew the Mac better but went with Windows because of the larger market); 2) using Delphi instead of Smalltalk (which is better suited for creating simulations) because of licensing fees; 3) being too ambitious about what to include in our first version (we should have started smaller); 4) doing too little user testing; and 5) working in too much isolation.

The History of PlantStudio

PlantStudio started life when we were working on GWI back in 1993. We started to draw some plants to use in the simulator at different stages of growth. Here is one of our early drawings of a corn plant, made by working from photographs.

Hand drawings of a corn plant

But we quickly found that drawing plants, especially at several stages, was boring and repetitive. And it seemed like it was going to take forever to build up a whole library of plant drawings. So we started working on a way to automate drawing plants. We looked into L-systems, a string-replacement method. But we wanted something more flexible to draw the wide variety of plants you find in gardens and to show how plants grow when they are stressed for water and/or nutrients. So the "plant drawing algorithm" was born.

Our very first plant drawing algorithm drew only in 2D and relied entirely on recursion (parts drawing more parts) without any object modeling. It produced things that looked like plants in the abstract, but any attempt to make a particular plant didn't get very far.

Very first plant drawing algorithm

The second try at a plant drawing algorithm added a 3D turtle for the drawing, but still used recursion. At this time we had a program called the "plant designer" separate from the garden simulator. The plant designer produced plants like the one following, with some plant form but not enough ability to handle things like inflorescences well. You can see in this image that the number of parameters was considerably smaller than it is now.

Plant designer

About this time (1994-5) we were testing the garden simulator with some users, and we found that everyone tended to like the plant designer so much they wanted to play with it instead of with the garden simulator. We toyed with the idea of coming out with the plant designer first, but we went ahead with finishing the garden simulator.

Our third try at the plant drawing algorithm in 1996 introduced objects to model the major plant parts. We did this partly by starting over with the plant drawing algorithm in Smalltalk and prototyping there. When we had something that held together, we translated our Smalltalk code over to Delphi. The object-oriented plant growth model made it much easier to introduce special structures and to control the timing of growth. Of course it also greatly increased the number of parameters.

Also at this time we brought the plant designer, which had been a separate program, into the garden simulator program. (In retrospect this was a mistake, because the whole thing got much more complicated as a result.) Here is a plant in the Garden with Insight browser, where you can change plant parameters, but really designing plants is difficult.

Browser

In July 1997 we finished our garden simulator. Finally we decided to follow up on the observation we had made long before about the old plant designer. We pulled out the plant drawing algorithm, slimmed down the science, spruced up the graphics a bit, and thought about how people would want to use it to draw plants. PlantStudio is the result of that work.

Possible futures for GWI and PlantStudio

If we are ever able in the future to restart work on Garden with Insight, we would create two new products as follows.

• The first product would be a simple, appealing product that teaches organic gardening. This product would have a graphical interface somewhat like the garden window in the existing product, but would cover more of the gardening experience. Elements would include testing the soil, getting weather reports, trading with neighbors, getting advice from the library, selling produce in a market, dealing with insects and animals (both beneficial and pest), thinking about where food comes from and how it is produced, and seeing the long-term negative effects of pesticide use. The program's models would be very simple, probably combining rule-based systems and fuzzy logic with simple growth functions. We would use what we have learned in making the existing product to create these simplified models.
• The second product would be a simulation development system for gardening, agriculture, and other scientific areas. One of the most important things we have learned while making this simulation is that we have learned more about gardening than anyone can learn while using our program, because we learned by writing the program. The logical extension of the existing program is a modeling environment where the user starts by constructing simple models, then progresses to more complex simulations. The modeling environment would include facilities for graphing and statistical analysis, and a debugger and source code control system.

The state of affairs

What happened to our old software and the plans for it? We spent years working for other people to pay off money (with interest) we borrowed to finish it and free it, we helped take care of elderly parents, we had a kid, and other events came up. Life. :-)