Quick update

So the meeting is technically over, but I just want to give a quick update.  Right now, I've just finished up the barb animations and the cursor image for when placing a cell.  Berto is working on some placing of sprites in relation to one another (I keep screwing him up by resizing everything), Nik is writing some block diagram functions and Andrew is doing interface functionality.

I'm starting to get a little tired of doing art-like things on the game.  We'll see what othe opportunities I get.  With two more weeks of development, the thing to do is always the most important thing on the list.  It's been clear for a while that we wouldn't finish the game as we initially envisioned, but it does surprise me some of the things that we have been able to do.  Hopefully we'll be able to have something playable and enjoyable at the end of the semester.

I'll try to have more interesting things to say next week.  As for now, I'll just keep chugging along.

I have returned, and with me brought sprites

So it's been over a month since my last post. Spring break fell in there somewhere and there were a few slow weeks. But I was doing stuff. Just not updating :-P. I did some looking into Boost alternatives early on in my disappearance including SWIG. I didn't have anymore luck than Andrew and so I moved on.

In the last week I've learned all about the code that Nik was writing and have been working on implementing a method to instantiate a cell sprite based on any given block diagram configuration. Today, I can finally say that I have a working way to introduce a compilation of individual part images as a cell. The following image shows us displaying 3 separate images (a cell body, barb, and flagellum in tandem.) At the moment they don't animate correctly and so are spit apart. I'll be working on that.

















So, for the next couple of days I see myself fixing the animation problems and moving on to expanding the logic for cell introduction to allow more organelles and to actually decipher block diagram since someone gets those working properly. After that I'll probably move on to writing some of the actions that cells will take based on logic that they have built in (finding food or enemies, etc.)

Write again soon,
Roberto

Never thought I'd animate a sprite

But now I've done two.  They're sort of repetitive to make, but the end result is worth it. The cell from the last screen shot has been improved on.  It now looks beautiful and shimmers in the nebulous agar of the petri dish.  Also it may or may not have a sleek flagellum to propel it through said deeps.  That really depends on the work on Nik and Roberto, who are currently struggling to animate these two things in a way so that they move as a single entity.  So yes, I have been doing art stuff, and will probably finish the last few organelles for the earliest game prototype early next week.

In other news, we moved one of our meeting times to earlier in the day and we have been really working better as a group this week.  I think everyone is more on topic in meetings, and we're all contributing such that every time one of us has a neat deliverable that we can check in and show everyone, there are three other people who have done the same.  Now, these are small deliverables.  First it's rendered, then it plays an animation, then it moves, then it moves in a circle, etc.  But it is cool to see some progress coming out at a decent pace.

Animations

Animating is one of the many things that Pyglet makes it easy to do. Just recently Erik drew a fabulous sprite sequence for the cell, and I spent some time today integrating it into our game.

If this weren't just a screenshot you'd see this cell moving and animated.

Pyglet has helper functions for breaking a grid of images up into different textures, and this is the route we took. Erik drew one picture file with a bunch of different sprites in it in a grid pattern, and then I used pyglet.image's ImageGrid class to split it up. The ImageGrid isn't displayable by itself (unless you want to display the whole grid at once, I guess) but it'll return a TextureSequence, which is basically a list of textures. Then I just keep track of how long the current frame's been up on the screen, and change the frame (increase the index into the TextureSequence) when it's been long enough.

My next plan in terms of animation is to make animations seamlessly integrate into anything that calls for a texture. If I make a wrapper class around Texture, and then have the actual texture itself be hidden within a property, I can selectively return the correct texture whenever an object tries to draw. Most things don't need to animate, though, so that's not a really high-priority task.

Moving onwards

Missed my post last week, so I'll do a quick update right now.  Our meeting times have been somewhat of a problem, so we switched a few of those around so that they work for everyone.  We'll see if we can be more engaged during the hours we're scheduled to meet now.

Also on the positive side of things, our interface is coming along well.  Now that the first revision of art is done for it, we're pretty much just adding in the functionality.  There is a tab control, and Andrew just put in a bunch of work to get that working.  It's pretty awesome.

Sprite progress is slow.  None of us have done that before, so although I've messed around for a few hours, there's nothing too substantial.  Hopefully we can get something good going and finish it.  I think our big problems are going to be placing organelles and things on the outside of cells if they're changing shape and size every frame.  If we then have multiple sizes of cells, things might get a little crazy.  This would be a good problem for us to sit down and talk about as a team.

Cells that move

If I had to list the three most important things we need in order to get this game off the ground, I'd pick:

• A working GUI that lets us iterate quickly and work with events and the user in a simple but powerful way.
• A dish for the cells to swim around on that keeps track of the cells, light, food, and energy, and can give useful information such as closest neighbors.
• The ability to create, save, and load block diagrams, and for block diagrams to control cells.

So far, I'd say we have the first one of these almost done. The GUI that I've written has an easy-to-use event interface, like all GUIs should, so that new functionality can quickly be implemented.
But the GUI isn't what I'm here to talk to you about today. Just recently I've implemented the third item: functionality that allows the block diagrams - which we've had for a while - to control cells. You can drag blocks around and connect them, and the cells actually move in a way that reflects the diagram.

In this picture, we see an eye and a flagellum controlling a cell (lightning bolt).

In addition to this, the block diagrams can be saved to and can be loaded from YAML. All that's left is to make the buttons at the bottom of the picture work, which shouldn't take long at all.
I really think using Trac has got us back on, well, track. We already have basic functionality, so in a month we should have something far more exciting.

A Complete About-Face?

Good news and mixed-blessings. After several weeks of attempting to wrap C for Python using Boost, I gave up. I deleted everything Boost related and started searching for an alternative. Even after switching to MSVC9.0 Express, using different releases of Python, and rebuilding Boost multiple times with different flags (all of which were recommended in the Boost documentation), it still failed to function as intended. Whatever. Boost has, without a doubt, been the single most un-user friendly library I've dealt with.

So what am I to do? If I can't rely on other people to make it easy on me, I'll just do it myself. I'll preface this by saying I have had zero experience writing dynamic linked libraries, but I felt the simplest and most elegant solution would be to define the set of block classes in a .dll, expose functions to instantiate the blocks into memory and pass the pointer to each block to Python. Of course Python has no clue what this pointer thing is, but if the pointer is passed back to the .dll through other exposed functions, then the block in memory can be manipulated with ease. This can all be accomplished using the ctypes library of Python to return the exposed functions and make calls to the .dll.

This has been finished and tested in much less time than all of the fiddling with Boost.

Currently, I can create a Diagram class in memory, add Block classes to the Diagram, neighbor the Blocks within the Diagram, step the Diagram to pass outputs to inputs of neighbored Blocks, and print out the state of the Diagram (including the state of each Block contained therein). It's pretty sweet, in my opinion. Unfortunately, I forgot about an important detail. The linked library is now kernel32 dependent (though I make no calls to kernel32 or ntdll). We intended to write the source to be cross-platform and using my solution would deny that possibility. In the meantime, Nik has programmed an equivalent set of Blocks in Python to handle parsing the Diagram. It works, but I'm still nervous that once we start including complex diagrams and many cells simultaneously the reliance on Python might bog the game down. We'll see.

I, personally, want to try my hand at writing a Shared Object to fix the cross-platform issue, but seeing as Nik already has working code, my time could be better spent elsewhere to get a working beta out the door. In that light, I've started coding a tab interface to switch between the block diagrams of the different cells currently in the field. Other interface additions will be the next priority.

Textures and Interface

That's pretty much been the name of the game this week-- textures and interface.  In fact, the interface is just about done art-wise.  Programming wise, there's a ton of functionality that we still need to add, including a tab view and tree view controller, which will probably not be fun at all.  Let us know if you've used a good python tree or tab view.

But I've also been hammering out some of the game textures.  New to this week-- we have an improved ocean, a whole bunch of food textures, and some light textures.  I didn't expect to be too much of an artist for this game, but with the programming being a solid commitment, I need to do a lot of art just to keep up.  Nik's been doing a great job with the python development.  This week we've seen the game itself get a lot better looking, both in functionality and art.  We have run a demo where a cell was created from a block diagram.  It then spun in circles, which was actually great, because we just gave it a flagellum with a constant input.

But both programming and art are major tasks.  We're going to have a ton of work in front of us to finish something playable in a month.  If we all put in the time we committed to and, more importantly, care how the game turns out, I think we can still pull things off.

Also the trac ticketing system, which we've started using, is working out great.  It's nice to sit down and see a list of all the things you have to do.  It gives you a greater sense of urgency (which is great, in my opinion), and also helps you to say "good enough, time to move on".  Unfortunately, as  of a few minutes ago, I have no tickets, so I'm going to go bug people until they tell me what they need done.

The great spring break slowdown

At this point in the game design, things are slowing down.  Unfortunately, spring break was something we forgot to take into consideration while making our initial gantt chart.

Right now I am still doing some interface stuff to send to Nik, but thinking about rescheduling the rest of the semester.  I just talked to Mark Chang, our advisor for the project, and he said that we should consider breaking down everything into much smaller tasks, so that people have an accurate idea of how long it will take and we can plan accordingly.  He mentioned that doing this has the benefit of not allowing you to say "yes, I'm done" when you have some large chunk of an ill-defined deliverable done.

In a way, it's sort of like test-driven development for deliverables.  Before you even begin, name each png you will submit to the art directory, write down the names, arguments, and return values of each function in your library.  Block out everything as soon as possible.

But that problem with that issue is a time-based one.  We would rather have a single cell with three organelles in a sparse environment working.  In order to do that, we don't need to spend time planning out all the organelles, all the environments, and all the other details.  However, there's no guarantee that planning out all of those things wouldn't mean some changes need to be made to the first skeleton that we do want to implement, and thus the time should be taken to go over everything at the beginning.

So there are difficulties; this much will be certain.  But I feel right now that my vision for how this game is going to progress to completeness is lacking.  If I felt instead that I had a good vision but we were irrepairably behind schedule, that might mean we needed to cut out features and go straight to the minimum deliverable.  But since vision is lacking, I'm going to use this time, not worry about what deliverables I produce, and instead try and figure out how the rest of the semester is going to be used.

Icon Naming Contest

Hi everyone! In the time between working on wrapping code, I've made a few updates to some of the organelle icons for the game. However, I know many of them still need work.

So if you can help us out by trying to guess the name of the organelle that goes with each icon below that would be great. The person who replies to this post with the most correct names will be immortalized within Intelligent Design.











Remember, think cells and strategy game tactics when trying to name these things. Good luck!

An Overdue Update

I just realized I haven't posted for a few weeks.  So what's been up?  Well I was sick for a good part of last week, which was a huge pain and meant I missed some hours for this project, but I'm back on track now.  I finished up some preliminary png files that Nik is using for the game interface.  Actually, we have a few cute screenshots below.  It's going to get better.  I guess right now I'm sort of thinking about dealing with different screen sizes.  That may be a bit of a pain to deal with, but ultimately things will work out.

Also this week I spent some time thinking about how we want to store information about blocks, and the rest of the game.  I actually spent some time making XML and JSON documents that described some simple functionality in the game before deciding that it would be better in YAML.  I'm kind of excited about using YAML because

a.) it has the minimum "structure" crap.  XML has a bunch of brackets and slashes and equals and quotes.  JSON has some braces and commas and gets really busy looking, but YAML is pretty much all whitespace, colons, and some dashes.  It's super neat.  It's super quick.

b.) Ruby on Rails uses it.  All the cool kids are into it.

c.) It parses really simply into Python.  In general, the ways you outline stuff in YAML translate either to a list (using dashes) or a dictionary (uses colons).

Yeah so that's that.  Also, I'm working on a logo.  Non-essential now, but will be cool to plaster over everything.  There is a non-trivial amount of art that needs to be done for this game.  Better hop to it!

Wrapping: The Devil's Hobby

As Andrew posted yesterday, we have spent the better part of two weeks working on integrating our C block code into the python interface. The first step of this is supposed to be wrapping our C code so that it can be imported into python.

Now you'd expect that this process wouldn't be so bad since I hear its a common thing to do. I have no idea what kind of experience everyone else has with this, but I have worked out that only the wrapping code is what the devil has programmers do in hell.

I've managed to use SWIG (Simplified Wrapper and Interface Generator) to make wrapped files of some of my own C code. However, the point where I seem to fail is when I try to use a python setup file to compile a python module file that points to the wrapped code, enabling it to be called from python.

I've installed mingw and gcc in various ways (on their own, with ide's, etc.) and followed like 5 different example procedures and failed to get it working every time. I am now toying with the idea of getting visual studio which might be able to fix this problem. In the mean time there's a race between Andrew and I to find a way to make this work.

Until next time.

Wrapping for Python

Oi. I feel comfortable with the current functionality of the block parser, and have begun trying to wrap the C++ files for use in Python. This has not proved to be easy thus far. A quick once over reveals two libraries out there to accomplish this -- Boost and SWIG. I focused primarily on Boost while Roberto has been looking into SWIG.

Up unto this point I had been using Dev-C++ as my IDE of choice. Unfortunately, it hasn't been updated by Bloodshed since early 2005 and is based off of a, as of now, old build of MinGW and GCC. Trying to build Boost for MinGW with Jam has proved to be a less than pleasent experience. After several failed attempts, MinGW and GCC were updated to the latest stable releases with hopes that I would be able to successfully build the libraries without several hundred errors. After exploring with and fumbling around the build arguments, I finally managed to update all 8000+ files. (Of the several times that Boost has been built, it takes ~1.25 hours on a laptop or ~0.33 hours on a desktop). Despite now having a brand new set of header files and libraries even after proper linking, compiling a wrapper for a simple canned class still yields a plethora of errors. Boost looks like it would make everything so incredibly simple, if only it would work. Unfortunately, several other posts on the internet make note of it's less than intuitive setup necessities. I'm considering utilizing a very frequently updated distribution of MinGW that comes with several precompiled libraries (including Boost) that is available at www.nuwen.net. More to follow.

GUI: Selections, Tabs, Sliding

The GUI has seen major improvements over the last week. We've gone from a black screen with a few boxes to the beginnings of the Dish and a drawer that smoothly slides in and out from the side of the screen.

(note: textures are placeholders)

Here you can see some new behaviors that have been added. Boxes are selectable (the lower-left one is selected, as signified by its white outline), and they also react to hovering and clicking—the lower-right block is being hovered over, so it's brighter than the others.

There are also a few things you can't see from a screenshot:

• the sidebar here slides in and out smoothly when its tab is clicked.
• the Dish--the image in the background--can be dragged around to view different parts of the map.
• the code has undergone a major revision to make further development much faster.

All in all, things are proceeding well. Hopefully by next week there will be cells moving around on the Dish.

Block GUI

I've been working on the block GUI, and things are going pretty well. Before I talk about what I've been working on, I'll cut to the chase and include a picture:

Here one can see the current block interface (the graphic was found through a Google image search and is for testing only). Right now you can drag around the blocks, highlight different ports, and create connections by clicking on two ports sequentially.

I've taken pains to make this interface be pretty open to whatever sorts of blocks we want to throw at it: blocks can be represented by any picture or pictures, ports can be any size and can be in any location on the block, etc. The connections between the blocks move in real time as the blocks are dragged, as they should. As of right now there is no way to select or delete connections, but that's coming next.

All in all, the block diagram interface is nearing completion. At some point I'd like to replace the straight lines with nice splines, but other things are more important right now.

High-priority block-diagram tasks left:

• allow for selection/deletion of connections
• allow for selection/deletion of blocks

Lower priority:

• allow modification of block parameters, perhaps through double-clicking on a block
• smoothing the graphics of the connections (using splines or some such)

Handling Behavior

As mentioned in prior posts, a large portion of the game focuses on the development of self-autonomous cells. We intend to allow players as much flexibility as possible to implement creative and unique behaviors. To ensure that players with varied levels of experience can feel comfortable sculpting the personalities of their minions, we have turned to implementing a block diagram interface for controlling logic and behavior.

When players enter the cell creation pane, they will be presented with various blocks all of which describe a specific function, and have the appropriate number of inputs and outputs (example: an 'add' block which outputs the sum of two, or more, inputs). Conceptually, these blocks will be cascaded to form complex logic (for instance: If the cell is 10 units of distance from another cell, follow it, otherwise move along the light gradient to find an area of high intensity light). By exposing the low level logic to players, we hope to see some truly unique (and perhaps bizarre) strategies develop, and the decision to use a block diagram format will hopefully make the act of programming the buggers a little less daunting to those less familiar with controls.

To this end, for the last two weeks I have been developing a block diagram parser. The base code is being written in C++ and will be wrapped for use within Python. As parsing and exacting the logic of the multitude of cells will undoubtedly be the most computationally intensive part of the final game, we wanted to make sure it's fast.

The technical details follow: Each block contains a number of registers equal to the sum of the block's number of inputs and outputs. Consider that there is a flow downstream from output of the root block to input of the first child, output of the first child to input of the second, etc. During a game cycle, each block in the logic interface will call all upstream neighbors and load their input registers with the output register values from the respective upstream block. Once all inputs have been loaded, the appropriate calculations will be performed on the input register values (i.e. adders will sum the two input registers, Boolean logic blocks will compare the inputs, etc.). The resulting value is loaded into the output register for the next cycle. Thus as the game clock ticks, inputs will be loaded from upstream outputs, appropriate calculations will be performed, and the output register will be loaded for the next cycle.

Currently, blocks can be adjoined to neighbors and values can be passed between output to input registers. The parser works at a basic level and I am able to propagate a signal along a series of logic blocks. More blocks need to be developed to fully test the parser and I have yet to tackle the question of feedback.

A little to my surprise, the parser might be nearing completion already. Of course there will be additional features that need implementing and I'm sure the code can be trimmed a bit. More to follow about further testing.

Putting an intersmile on the your interface

So as you may be able to tell from my clever title, I've spent a good deal of this week nailing down the interface.  Fortunately, at this point, we're ready to go with a first game model.  I've done about 30 sketches for different parts of the interface and made a quick photoshop mockup.  We're actually going to try and go for a minimalist interface.  Unfortunately, we don't anticipate beautiful graphics (at least not at version 1), so there may not be a ton to look at with this minimal interface, but it should at least give you a nice big playing area.  So how are we doing this?

• Optimized quick creator.  All of the cells you create in this game can be stored in your "deck".  Some of the cells you want to create the most can also be accessed from a quick creator menu.  We've made a quick creator menu that allows you to make some of these cells without pulling up another large menu, and also navigate between which type of cell to create in an efficient way that has a neat feature from the iPhone interface.
• Hideable menu.  The cell design menu, which will take up a huge chunk of the screen when expanded, will normally be contracted.
• Replacing buttons with mouse commands.  Right-click, click and drag and double-click will all be used in some controls.  This will allow for a way less cluttered interface, and perhaps a much faster way of designing cells.
• No mini-map.  Yet.  Perhaps.  We'll see.

In other news, our overhaul of the game design document has been completed, and I'm focusing entirely on interface.  I hope to get a working version out of photoshop in the next few meetings.  Right now, Nik is working on our cell creator interface, Andrew is taking care of the cell creator backend, and Roberto is doing some icon work.  We had some passerby's try to identify the icons in the game, which was probably one of the most exciting points of the meeting tonight.  Anyhow, that sums it up for now.

Becoming an Artist

So I've spent this last week becoming an artist. I've never really been artistically inclined. I'm good with straight lines and polygons. I can color inside the lines. The other team members are in similar situations. However, sounds and images are a huge part of video games. You can't make a good game without them. Holistically speaking.

Despite our lack of artistic training, we've decided to produce a game with some form of minimalistic art. A couple of theme songs following basic musical patterns and some drawings that focus on basic form rather than detail. This week I managed to make icons for the different organelles our cells may contain. Here are the oculus (eye), feeler, and flagellum:

Anyway, I think we've done a good job getting the project off of the ground. Now the biggest fear I have is that we get lax and start falling behind schedule. Guess I just need to have faith in the Gantt chart and our ability to keep to it.

Until next time...

New Week; New Stuff

So here's a little update on what I've been up to for the past week.  First of all, last Friday, we completed our initial design document for our advisor.  Although that's not publicly accessible, it is a 15 page description of the game.  I've spent a number of hours this week revising that and integrating it with our wiki.  Hopefully the wiki will take on the role of the design document more and more as time goes on, so that we can keep a living vision of the game somewhere.

That's going pretty well.  Just for the record, some of the things we've covered in the newest design document (and this will make more sense as we release more details of the game on the blog) include play modes and game settings, organelles, logic, "acts of man", landscape, integrated strategy, the user interface, creating units, the flow of energy, a sample game walkthrough, sound and music, engine, and schedule.  It's pretty rockin'.

In other news, I spent some time re-sketching our main game interface, and making a photoshop mockup.  More or less integrated with this was me making my first ever tiling texture for the agar on the petri dish.  That was a neat experience, but I don't know if I'll be doing all of our textures.  Finally, I put together a preliminary list of every sound we'll need for the game, and then wrote some updated stuff on the flow of energy in the game and creating cells.

That more or less covers it.  As I type this, Andrew's hard at work coding the guts of cell interaction, Roberto is making some sweet icons for organelles, James is creating sprites, and Nik is on a surprise trip to Washington State that he "swears he told at least one of us about".  So things are going well.  Hopefully we will continue to make progress.  I'd really like to get a "world" done by next week, hopefully with some sort of interface that includes a button that can create a sprite cell.  Nothing more than that is necessary for this preliminary checkpoint, but once you have a cell in the world and an interface, it's a very visual, inspiring, and appetizing way to keep spirits and progress up.

Another Introduction

It's high time that I check in as well and give a small introduction and prospective vision for my work to be completed over the next several months.

I originally joined the project in an effort to further my budding C experience (now wrapping C for Python). November and December of 2008 I futzed with writing my own soft-body physics simulator and collision detector. It worked well enough and given enough time I would enjoy attempting to implement an equivalent design in the game. After several sessions together as the full team though, I suspect the intensity of attempting to compute collisions between partially elastic bodies for, potentially, several hundreds of cells at once might not be a viable option.

In the meantime, I have been helping discuss and elucidate the intricacies of the game with my fellow teammates. I foresee myself helping to discuss further design decisions at a higher level; however, once the backbone has been sufficiently established, I intend to focus primarily on coding the dynamic parsing of the system blocks and constructing the framework to rapidly produce future blocks as gameplay elements are finalized by those devoted entirely to the direction of the game and balancing.

On an aside, the initial design document has been finalized, so we all have a better understanding of the path we'll be embarking upon as well as a rough idea of the time-line to which we will be adhering to ensure completion of important elements.

After the First Week

As was touched upon in the last post, this game is going to be rather rushed in development.   This will be difficult in many aspects, but it's the best way to go if we want to get something done by the end of the semester.  Right now, I'm writing at the end of our first week of development and already we're feeling the burn a little bit.

We've scheduled 10 hours of group meeting time a week, which is more intensive than any Olin course.  However, very little of this game will be developed alone, so this is actually a reasonable schedule for a what's supposed to be a 12 credit hour course.  Our first deliberable is due tomorrow-- the initial version of the design document.  So we're putting in a bunch of work on that.  We actually have a few hours left tonight and then a few tomorrow morning, so we'll see if we can pull this document off by then.

As for my role in the game, I have been doing pretty high level stuff for right now.  I guess that's the case for everyone, but I have been trying to coordinate the making of the design document, prodding and arbitrating dicussion, scheduling meetings and so forth.  Right now, Nik is focusing on choosing an engine and learning it, and (I just checked) he's even working on that right now.  It looks like we'll be going with the pyglet engine.  James has been coming up with a ton of strategy, which guides our ideation of features, because it's really important to think of a feature, then think of the great ways in which it could be used.  The rest of us are doing more or less homogenous work in ideation and design.  Basically, our strategy is to design the game to the point where we can describe it as if we've played it for a week.  The goal here is that if we can get to that point, we'll have a very clear idea of what exactly it is we need to program, and we'll have a good deal of time to do it.

So far there have been no major snafus in the design process.  At least, that's what I imagine, though it might be too early to say.  Hopefully we'll get a document out by tomorrow that lays out our vision for the game and is something we can all be proud of.  It's certainly coming along, but, not surprisingly, there will be a bit of rush before it's done.

Pyglet

The framework we are using for Intelligent Design is called pyglet. Pyglet, in their words, is "a cross-platform windowing and multimedia library for Python".

We picked this framework for a couple of reasons:

• It's oriented toward 2D. Most frameworks, engines, and libraries that exist on the internet are for creating 3D games. We looked into using one of these, and concluded that using a library that's made for 3D would be a bad idea. We'd be fighting the API to make it do what we want, and we'd have to keep track of three dimensions for everything when we would only be using two.
• It's made for Python. As an example, another framework we were looking at was LÖVE. This framework did everything we wanted, even going so far as to have Box2D rolled in. However, the language required was Lua. We looked at Lua, and decided we didn't want to use it. Among other things, Lua starts arrays at 1 by default, which we didn't want to have to deal with for a semester.
• It's simple and clean. There are some game frameworks that seem overblown and kludgy, and this isn't one of those. We considered using pygame, but it's way more complicated and has far too many features that we'd never use. Pyglet is a small download and doesn't even need to be installed to use.

However, no framework is perfect, and pyglet is missing a couple things we'd like to have. It doesn't do collision detection, and it has no built-in networking. Using pyglet with Rabbyt, a 2D collision detection library, seems to be a popular option, and we may do that. And Python already has a socket library with which to do networking, though we may look around for a networking library to avoid programming at such a low level.

At the moment, I am working on creating the cell programming interface. The player should be able to drag and drop and connect different blocks in order to program the cell to have different behaviors. So far I've got the dragging and dropping, and I'm going to be adding the connecting part shortly. Then we'll be moving into the exciting world of parsing! I'm excited.

Design Document Excerpt

So we thought it'd be nice to give some sort of introduction to the game on the blog. Here's an excerpt from the design document we've all been working on.

Game Summary

What is Intelligent Design?

Intelligent Design is a video game for PC being developed by a group of students at Olin College of Engineering. A first-release playable version is scheduled to be out in May 2009.

Intelligent design is a sandbox/multiplayer strategy game where you define the logic of and build single-celled creatures that fight for dominion of the petri dish. Guide their evolution from above, but be prepared for unexpected mutations, viruses, and enemy cells.

Customize your cells with signaling and sensing organs, energy processing organs, weapons and protection and other special abilities. Also, define the logic that governs how the cells function and interact. With blocks that specify cell organelles, priorities, values, random numbers, and algebraic operations, you can relatively quickly put together creatures that attack, patrol, follow, guard, forage, circle, and sabotage. The real strategy begins when cells combine multiple functions, choose priorities in behavior and start showing teamwork.

This game will have two modes of play. There will be a multiplayer mode where you can connect with up to three of your friends (or: one), choose the environment and gameplay settings, and settle your differences on the agar. But in preparation for the showdown, it may help to try out some pre-defined creatures, or test out the more complicated logic of your own custom creatures in a fully-controllable sandbox mode. Create some cells of your own, a few opponent cells for them to battle, and help yourself to as many resources as you need to perfect your strategy. But after this, it's back to the petri dish, where your perfected micro-army will literally either sink or swim.

What isn't Intelligent Design?

Most game design firms will build a game in 9 months with 5 to 40 people working 40 hours a week. We have 5 people, but we're really lacking in the months and full time labor departments. To make up for this, we're making it clear up front that this is not your full-featured, beautifully rendered, 3D, major studio release. In fact, we want to cut out a lot of things standard to many modern games, including

• the z-dimension
• a single-player mode or campaign
• an in-game tutorial (any tutorials will be written out in document form)
• more than minimal attention to graphics
• more than minimal attention to sound and music
• a help section, packaging, marketing, localization.

Because of this, we're making a concerted effort to design a game that has the maximum player enjoyment to development effort ratio. A strategy game seemed the ideal way to go in light of this goal, because once a framework is set in place and tweaked, it's up to the players to push the game to its limits.


Hope this peaked your interest,

- The Management

Roberto and Intelligent Design

After a couple of long weeks preparing the initial design document, I finally have some time to update this post with some actual information about my role on this design team.

I came onto this project with the goal of designing a successful video game. When I say successful, I don't mean monetarily or that it works perfectly right off the bat. I mean that I want to make a game that is enjoyable.

In order to further that goal I've spent a lot of time looking into what has made video games successful in the past. I've looked at Mario, Zelda, Final Fantasy, and many, many other games.
I will bring this knowledge and my experience in design to help refine Intelligent Design: The Game into something very fun.

As for specific tasks, I will be helping out with high-level coding of some organelles and logic. However, my main work will be in refining the game design and control interface as we learn more about interactions between cells and how people wish to play the game.

First Post

Our blog is now up and running.  This will be the official development blog of Intelligent Design: The Game, a strategy game that pits you as a scientist trying to breed and create micro-organisms that can rule the petri dish.

The development team consists of five students at Olin College of Engineering-- Erik, Roberto, Nik, Andrew and James.  We should all be posting in here about once a week, or else we're not really doing our job.  Feel free to drop us a line, or if you're at Olin, check out our wiki: http://foxtrot.olin.edu/trac/game/.