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.