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