Visual Studio Community 2013 - Available Today!.Smart Unit Tests (Preview) and Conway's Game of Life.More Smart Unit Tests (Preview): Guard Clauses.Still More Smart Unit Tests (Preview): Exploring E.Property Injection - Additional Unit Tests.Yet More Smart Unit Tests (Preview): Fix and Roadb.A Last Look at Smart Unit Test (Preview): Square P.This lets us focus on things that we care about (such as parallelization) and also work our way out of problems that we might create for ourselves.
Sometimes that means taking a well-known problem and implementing our own solutions (even when there are lots of implementations already). As mentioned, I'm not a big fan of having the nested "for" loops in so many methods, but we may be able to take care of that as we look at things further.
#Conways game of life command line output update
In implementing the UI for Conway's Game of Life, we had to take a look at how we are storing the grid data, how we update it, and how we display it on the screen.
#Conways game of life command line output windows
In addition, I'd like to support some different UIs (like a WPF or Windows Phone application) that we could make a bit prettier. This means that if we run this method on different threads with different parameters, we don't have to worry about them interacting with each other.īut to take advantage of this, we'll need to make some changes to how we are updating the state in our LifeGrid class. We will always get a new copy of the value (even if we don't change it in the method). Next, since CellState (the type of our return value) is a value type, I don't have to worry about accidentally modifying state of the parameters. The result is that we don't modify any shared state in this method (good). I created this as a static method: that means that we're not allowed to interact with any instance objects that are part of the class. Then we just need to add a reference to our Conway.Library project. As you might imagine, this is a console application. To create this, I just added a new project to our solution called "Conway.ConsoleUI". This will output the cell state as dots or Os. We're going to start out pretty simple: we're just going to hook up a console application to our grid. We'll make a few adjustments to it so that we can have an arbitrary size, but this is enough for us to hook this up to a UI. This completes the implementation of our grid. Then we just return the total when we're done. If so, we increment our liveNeighbors count. Once we've validated that we're looking at a cell that is a neighbor of the current cell and not off the grid, we check to see if it is alive. So we check to make sure that the X-Y values are greater than 0 and less than 5 (our current grid size). The next trick is that we need to make sure that the neighbor cell is still on the grid. We want to skip this, which is why we check for "i = 0 & j = 0". These "for" loops will hit the current cell. It does this by subtracting 1 and adding 1 to the current position.īut we have a problem. Then it has nested "for" loops to go through the cells to the left, right, top, bottom, and diagonals. The method takes the X-Y coordinates of the current cell. There are a lot of nasty conditionals here. That's because I wanted to try to figure things out and then optimize as needed. I'll admit that I haven't looked up other implementations of Conway's Game of Life for this coding session. With the grid in place, we need to run the rules on all of the cells. I expect to do a lot of refactoring of this code, so I might end up doing that later.)
That way it would automatically be in that state when it's instantiated. (An easier way might have been to flip the enum so that "Dead" comes first (i.e. You can think of this as similar to the way that we used to double-buffer graphic animations to make them faster to load.Īfter instantiating both of our states, I initialize the current state to all "Dead". We could do this by taking a snapshot, but I decided to create "current" and "next". That means we can't change the state of any of our cells until after we've processed the rules for all of the cells. When we get the rules for a single cell, it depends on the current state of all of it's neighbors (8 neighbors in our case). The reason that I have a "current state" and "next state" is to make it easier to run the rules. To make things easier to start out with, I hard-coded the dimensions of the grid to 5 x 5. I don't like the idea of dealing with a multi-dimensional array (If you know anything about me, you know that I love generic lists).
0 kommentar(er)
