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.