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.