The Game of Life
The Game of Life was invented by Cambridge University mathematician John Conway, probably some time in the late 1960’s. It first gained widespread attention after being mentioned in a 1970 Scientific American column on mathematical games. If you’re interested in the history of it, there is a very good dissertation on Wikipedia, and I have also included some information in AvalonLife’s help file. What we need to know here is fairly straightforward: Life is a cellular automaton implemented on an idealized 2D grid. On each iteration of the automaton cells in the grid are turned on or off according to rules that determine their state based on that of their immediate neighbors. The rules themselves are inordinately simple. They are:
For cells that are ‘on’:
– If the cell has 1 or 0 live neighbors it is turned off
– If the cell has 2 or 3 live neighbors it remains on
– If the cell has 4 or more live neighbors it is turned off
For cells that are ‘off’:
– If the cell has 3 live neighbors it is turned on
That’s it. Just four rules, but the behavior that emerges from these rules can be amazingly complex. In fact, back in the time when computers were new, and still fascinating and otherworldly, this little game spawned such a following among simulation buffs and the mathematically-inclined that its behavior was sliced and diced every which way you can imagine. The various odd patterns of cells that emerge were given names, such as Glider, and Cow, and B-Heptomino, and hobbyists eagerly traded newly-discovered patterns with each other. You can get a good taste of all this, as well as discover a few cool patterns to try, at the Life Lexicon website. You can drag these patterns right off the website and drop them on AvalonLife’s main window to load them. I’ve also included over fifty classic patterns with the game download, in the \models folder, so you can try them out. Among these is Gosper’s Glider Gun, a famous pattern that won Bill Gosper a $50 prize from John Conway for the first infinitely self-replicating pattern. But enough Life trivia. If you’re into simulation programming you can already get a rough idea of what we need to do in this program: we need a 2D grid of binary cells and a means of applying the rules to them (a model), a UI to enable viewing the grid and modifying cells and runtime properties of the sim (a view), and an engine to tie the model and view together and run everything (a controller). I’ve always found the classic MVC architecture pattern to be well-suited to event-driven programming, and of course it is a natural for simulation, so that’s what I decided to go with here.
Much of what is going on in this architecture will be familiar to experienced .NET Windows Forms developers. Data binding is used to tie UI elements to underlying properties of the simulation, UI events signal user actions, and properties and method calls tie the whole thing together. What is unusual, if you haven’t written code for WPF yet, is the fact that the view component is split into two layers. The key evolution in WPF as opposed to .NET 2.0 Windows Forms is the concept of creating a user interface in declarative markup language, and using code-beside to provide the underlying mechanisms. If you’ve been developing ASP.Net applications for the web then you should have just heard a little ‘click’ in your head, and might even be forgiven for starting to feel a little bit of excitement. Unfortunately I’m going to ask you to hold that for a minute. We can’t talk intelligently about how the UI is put together until we do a quick pass over the objects it is layered on top of: the Model and Controller portions of the architecture. In the next section we’ll briefly describe how these are implemented. If you have no interest in the game of Life, or in techniques for programming realtime simulation in an event-driven environment, then skip ahead to Part 4 and dive into the section on XAML.