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.