Nature Of Code Final: Game Of Lifetris

As I originally outlined in my proposal, for my Nature Of Code final I decided to create an implementation of Conway's game of life, and combine it with the classic computer game Tetris.  The result was one that, while not terribly fun to play, actually does go a long way in demonstrating that the game of life is more complex than it appears, and despite its simple rules, offers of a large degree of randomness.

I started by trying to discern the basics of the game, and came to the conclusion that I would need to start with some pieces/organisms already on the board.  The game of life tends towards decimating populations, so having no starting population lends itself to a quickly emptied (and boring) board.  Moreover, given the game's natural tendencies, I decided that I would make the aim of the game to allow pieces to live, rather than to destroy them (as was true in the original tetris).

I took this implementation and coded a simple version that was in black and white and played out a generation of the game of life after each tetris piece was dropped.  Once this was complete, I noticed a major problem:  Despite my hopes for the contrary, there's little way to discern what will happen in the next round of the game.

To work my way around this, I next tried implementing a "future" system, where the game would calculate the results of your current piece placement ahead of time, and attempt to show them to you in a translucent clear projection on top of the current board.  The problem with this is that, while interesting, it's still extremely difficult to tell whether you're creating or destroying pieces.

Continuing on my quest for at least some level of usability, I reached for one final implementation.  This time I maintained the "future" board concept, but also colored the tiles more strategically.  This time I made tiles that stayed alive black, tiles that died red, and tiles that were born green.  In this way, it's easy to try and maximize green and minimize red as you place your piece.

Once the interface was intuitive, I added a scoring system based on how many organisms were alive after each turn, and played the game a bit.  The unfortunate result is that it's not very fun.  While tetris allows you to create strategies and begin to intuit moves, the game of life is simply too random to be able to do anything but try and pick correct placement on a turn by turn basis.

Despite this fact, I think there could still be room for using the game of life mechanism to make for a fun game implementation.  Some cases that still seem to hold water did come to mind:  a game where there was a desire to finish with a very specific number of organisms, a game where all the organisms needed to be eliminated in a certain number of turns, or basically any game where the strategy was less about time and movement, and more about specific placement.

In short, the game of life is too random of an algorithm to function desirably in a time and movement based game.  I believe it would hold up far better under slower, ore strategic circumstances, and that tetris is certainly not.

Nature Of Code: Final Project Proposal, Tetris and Conway's Game Of Life

Our Nature of Code final project is about as abstract as you can get, with the option to leverage just about any and all sides of the various phenomena.  What's more, the visualization (or lack thereof) is also completely open ended.  In short, we were asked to look at the huge amount of material covered this semester, and get inspired.

For me, that meant childhood video games - Specifically, Tetris.  While reading this article on Conway's Game Of Life, I was struck by how similar the cellular shapes were to Tetris pieces.  This got me thinking as to whether there might be a way to combine the two into a video game that yielded novel game play, driven by cellular automata.

While I'm still fleshing out the idea, you can check out my thoughts so far in the proposal below.

ppt: Nature of Code Final Project Proposal - Tetris and Conway's Game Of Life

Nature Of Code: Midterm Proposal

For the Nature of Code midterm, we were asked to do the following:  

Develop a proposal and a prototype for a "midterm" project. The scope of the project can be quite large (trial idea for a final, for example), however, you will not be expected to implement the entire project. For the proposal, include a description, relevant links, and a quick Processing sketch of the first step towards the idea. Link your proposal from the wiki. Next week, we will look at a selection of proposals and then on Mar 2/3, the results for all midterm projects will be presented.

As such, I've decided to continue my work on modeling popcorn using the Box2D library.  While the original attempt was moderately successful, there are a number of aspects that I'd like to modify and enhance so that the simulation will be more realistic.  Specifically, they are to:

• Enhance the geometry of the popcorn so that the kernels and popped corns are not uniform in shape and size.
• Work with density variables to create more realistic behavior as the corn pops and expands out of the kettle.
•  Work with kernel placement and velocity so that the kernels don't breach the kettle walls upon popping.
• Allow for user interaction and variability with the simulation, including: amount of popcorn, turning the kettle on an off,
• Create more realistic visualizations to associate with the simulation as a whole.

These changes will also serve to further familiarize me with the Box2d library, and its ramifications for geometry and particle systems in a modeling context.  The project will not be the prototype for a final project, but rather the final iteration of an earlier project before I embark on a final.

Nature Of Code: Popcorn Modeling

This week in Nature Of Code, we were asked to use the Box2D library to implement a model of some real world phenomena.  Box2D is a physics system that manages the physics of a given system, which you can add various physical "bodies" to.  This allows you to create a realistic physics model for a given 2D system with very little coding overhead.  For whatever reason, when I heard this, my mind immediately went to popcorn.

For a smaller number (100) of kernels, my model (with a small amount of tweaking) actually works quite well.  The kernels pop somewhat naturally, and the system generally handles the physics of the situation how you would expect it might:  just like a real popcorn popper!  You can see the effect of 100 kernels in the first two illustrations of this post.

However, from there I started adding more kernels, and got into some trouble.  At 150 kernels (above) the physics started behaving a bit erratically, and areas with a lot of popping density would cause kernels to move through solid objects.

When I increased the number of kernels even further, to 300, this behavior became almost ubiquitous in the system.  Kernels were popping out of the kettle left and right, and the walls of the kettle seemed almost meaningless.

I have yet to discover what the cause of this behavior is, but my guess is that it's an inability of Box2D to handle the sudden transition from kernel to popped kernel.  A few ideas I've had include increasing the time of the "pop" from one step of the physics engine to say, 3 or 4.  This might allow the engine to handle the change more intuitively.


One of the challenges of Box 2D is that it has no graphical output, so everything you draw is based upon a Box2D object, but isn't actually a Box2D object.  What this means is that errors in one's graphics code can appear to be Box2D errors, when in fact they are coding errors on the users end.  This is unquestionably one of the downsides of using a "black box" engine, but hardly enough of a problem to avoid using such a versatile tool.


source: Popcorn Model

Nature Of Code: Flower Modeling Mk. 3

The image above is a screen grab of the third revision of my flower-based physics model, last mentioned here.  Since then, the model has gone through a number of iterations.  The first modified the graphics to be slightly more refined, and more successfully integrated a wind force, as well as a flower "wobble".  The initial issues I had with the wind being too uniform were resolved by putting a limit on the force vector, as opposed to the resulting velocity vector.  The velocity limit had been causing all of the flowers to share velocity and direction.  I intriduced the "wobble" in an effort to give each flower its own movement, in spite of the shared wind vectors.

This revision, the third, takes the second revision and adds the concept of thermals.  The thermals can be seen in the regions defined by white lines above.  These thermals provide a third, largely upward, force that is defined by the developer.  When blooms cross them, the addition of the thermals can result in spontaneous upward movement, ostensibly due to air current resulting in difference from temperature.  From here, I think the next logical step is transferring the wind force from a single shared force screen-wide into an array of wind vectors, varying based on screen location.

Code:  Flower Modeling Mk. 3

Nature Of Code: Flowers and Wind

For our first week in Nature Of Code, we were asked to do the following:

Find an example of real-world "natural" motion and develop a set of rules for moving the Walker. Can you do it without using any random whatsoever? Without changing how the square looks at all (changing size or rotation is ok), can you give it a personality or make it appear to have an emotional quality? Create a second version with the same behavior, but with your own non-square design. Feel free to design an environment for the Walker to live in as well. We'll compare the versions in class next week. Can we create something natural through algorithmic behaviors alone? How much does visual design play a part?

Inspiration.
I took my inspiration from the PlayStation 3 game Flower (see video above), and attempted to model flowers (namely, dandelions) being detached and floating in the wind.  As per the request, I created two versions, one that used pure geometrics, and one with more visualization.

Implementation.

The first visualization uses squares and lines (along with modeled wind) to gradually harvest the dandelion buds from their stems.  While the representation is geometric, I actually think the visualization has enough clarity, or familiar layout, that it's pretty clear what's happening.

 

 

The second animation uses the same code, but with color and small dandelion gifs to create a better sense of what's going on.  While the original visualization creates a semi-clear representation, the second implementation unquestionably does a slightly better job.  The colors and gifs create and animated, cartoony feel that successfully portrays the objects in question.

Challenges.
Both implementations use the same modeling for the wind, which uses vectors and random numbers to specify when buds disconnect, and how they move once disconnected.  Coding the disconnect was simply a matter of randomly disconnecting at a pace that was seldom enough to feel natural.

The wind was far more of a challenge, and required figuring a pace of wind change that didn't seem too fast, or too slow.  I eventually managed to stumble upon a combination of changing acceleration, changing direction, and avoidance of downward wind, that seemed to grasp the idea well.

My main challenge (which I still have yet to solve) is that the iteration over the flower array to update each vector results in an occasional pause in the motion which is highly unnatural, and definitely not desirable.  I need to investigate this further, and determine if there's a more efficient way to update the objects, or if I need to reduce something algorithmically within the update.

Takeaway.
Short version: making things move naturally is hard.

Long version: I had difficulty implementing any kind of movement that felt natural without using randoms.  Even once I started using randoms, the implementation was largely one of trial and error, seeing what looked and "felt" natural, and elaborating on that.

Source Code: Zip File with Source Code and gif (Please note that the sketch is done in eclipse, and will not work in a regular Processing environment.)