A Strategy for Writing Simulations:
experiment, have fun and learn.

There are many strategies for writing simulations. The trick is to find a way that works for you. The technique I find most useful is to engage in an ongoing dialog with your computer. What I mean is this: compose a small piece of code and try it out. Check to see that your application is doing what you intended it to do. Write a little, run it and debug it. Creating a program procedes in incremental steps. Programming is simpler when you work in a visual development environment. You don't have to worry about building things like Windows, buttons and track-bars; you just drag and drop them on your screen. You can devote your full attention to the logic of the world you are building. As you assemble your model it is important to see how it behaves at every step. Create a color graphic visualization of each important part. To see what is going on you need to create a clear window in order to see into your synthetic world. Sometimes known as a Graphical User Interface, it is the GUI (pronounced "gooey") that presents you with the ever-changing color map of this virtual reality. As you write the logic of your artificial world, you should also write your interface. If you can see what your code is doing as your write it you will reap two benefits. You will see how your world behaves, and if it behaves badly you can lean why. You will gain experience and confidence through your failures as well as your successes. Start with little steps. Try little things to see what they will do before putting them together into larger things.

Save all your project files every few minutes. That way if you add code that stops your computer dead you can easily go back to where you were before it crashed.
Copy all your project files to your ZIP disk before leaving your desktop machine. If the workspace is erased, which happens regularly, your files will be destroyed.

What are the objects in the world you are modeling? How will you represent them in C++?

• Agents? How many? What characteristics do they each have? (You will probably store this information in one or more arrays.)
• Space? How big is it? What will be in it? Is it continuous or broken down into cells? (You will probably store this information in one or more arrays.)

How will you visualize and render your world?

• Build a quick-and-dirty GUI!
• Draw a birds-eye view of your artificial world.
• Fill it with different colors to represent the different states of different spaces and agents.
• Drop in a button that will initialize the simulation.
• Drop in a button that will render that initial world to the screen.

How will your world unfold through time?

• The real world is parallel, meaning that things are going on all at once at the same time.
• Although there are parallel computers in the world, we cannot afford one. So somehow we have to find a way to simulate a parallel computer in our serial desk-top PCs.
• There are several ways of doing this. Each different way may lead to differing results.
• We could simply let the players, the agents, each take turns. We could run down a list, but sometimes this creates problems since each player is always behind the same someone else. We could select each player at random, but sometimes this creates problems since some players will have more turns than others.
• We could simply scan across the world's space and let each player move as we encounter it. This can create the same kinds of problems as above: some players always get to move before the same other players, some players may get repeated moves while some may get left out.
• Or we could call "time-out!" We could simply stop time, the way it is stopped in a frame of movie film. While it is stopped, we could figure out what each object should do in the next frame. We could resolve any problems and conflicts before we actually create the next frame. Once we are happy with the results, we could create that frame. Then we could restart time and progress, frame by frame, through the simulation like a movie. This is probably the least biased way to do things, but it is slightly more complex.

As time unfolds, how will your agents interact with one another and with other objects?

• Interactions are described as processes, which can be thought of generally as inputs, states and outputs.
• For human or robotic agents, these processes may be thought of as sense, think and act (STA).
• For human or robotic agents, the objects that to the processing may be thought of as sensors, cognizers and actuators.
• We can represent these real-world processes by analogous processes in computer language:
• In programming, Windows Objects have characteristics similar to these: events, properties and methods.
• In programming, C++ Functions have characteristics similar to these: parameters, code blocks and return values.

Step through one round of the simulation:

• Drop in a button that calls a function that will step through one frame, or
• Drop in a button that calls a function that will give each player the opportunity of one turn, or
• Drop in a button that calls a function that will scan through the entire world space.
• Write some code to render HOW the world has changed. Rendering is slow, so you can speed things up if you DO NOT redraw the entire world each time. Only redraw the changes.
• See if things behave the way they should. If not, change them. Try and try again.

Drop in Run and Stop buttons:

• Drop in a RUN button and link it to a RUN function.
• Write a run function that will repeatedly call the STEP function as long as the STOP FLAG is not raised.
• You will have to tell this function to look for the STOP FLAG every time it calls step.
• Modify the RUN button so that it toggles to STOP and alternates between raising and lowering the stop flag.

Weave back and forth through all the steps above and below:

• Check your program's operation and debug it.
• Add comments to your code before you forget what functions do and what variables mean.
• Add functionality to your simulation.
• Add visualization to your simulation.
• Modify the sizes, colors and positions of items in your Window to keep your GUI intuitive.
• Rename objects, functions and variables so that they still make sense after all the changes you have made. Do it carefully.
• Regroup event handlers so that buttons, track-bars and edit boxes appear in logical or alphabetic order.
• Be cautious if you regroup functions, since each cannot call a functions that has not previously appeared.
• Tidy up. Once you have written a working program, it may take you again as long to edit it so that someone else can easily understand the code you wrote.
• Don't think for a moment that the source code and Window examples that you see were written only once. They were all repeatedly revised.
• Create an Icon for your application.
• Save all the project files on your ZIP disk.
• ZIP only the necessary project files together and export them to a floppy.
• Print an image of your Windows application on a cover sheet of paper.
• Print the source code of your application and staple it behind the cover sheet.
• Turn in disk(s) and paper(s).

Most of all, experiment, have fun and learn.