Friday, April 24, 2009
Friday, April 17, 2009
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,
Tuesday, April 14, 2009
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.
Monday, April 13, 2009
Friday, April 3, 2009
- 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.
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 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.
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.
Friday, March 27, 2009
Tuesday, March 10, 2009
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!
Thursday, March 5, 2009
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.
Wednesday, March 4, 2009
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.
Tuesday, March 3, 2009
- 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.
Tuesday, February 24, 2009
- allow for selection/deletion of connections
- allow for selection/deletion of blocks
- allow modification of block parameters, perhaps through double-clicking on a block
- smoothing the graphics of the connections (using splines or some such)
Monday, February 23, 2009
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.
Thursday, February 19, 2009
- 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.
Friday, February 13, 2009
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:
Thursday, February 12, 2009
Monday, February 9, 2009
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.
Thursday, February 5, 2009
- 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.
Tuesday, February 3, 2009
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.
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.
Hope this peaked your interest,
- The Management
Thursday, January 29, 2009
I came onto this project with the goal of designing a successful video game. When I say successful, I don't mean monetarily or that it works perfectly right off the bat. I mean that I want to make a game that is enjoyable.
In order to further that goal I've spent a lot of time looking into what has made video games successful in the past. I've looked at Mario, Zelda, Final Fantasy, and many, many other games.
I will bring this knowledge and my experience in design to help refine Intelligent Design: The Game into something very fun.
As for specific tasks, I will be helping out with high-level coding of some organelles and logic. However, my main work will be in refining the game design and control interface as we learn more about interactions between cells and how people wish to play the game.