After day 2 i have a bit better underwater environment and terrain, and the start of basic collision and placement of samples that are sought. I think the challenges will mostly be making this thing not devour poor player's cpus, as I am definitely layering many things on top of each other using blit. Perhaps I might need to do an emergency port to pyglet at some point.. we will see. Anyway, here is where my underwater world stands:

Things are going well! It is something of a joy to be given license to focus so much energy on a game-making project. Yay for programming!

Some additional information could theoretically be found on this wiki page

And remember! When you say ROBOT!, the "!" is not optional!

Celldoku - An introduction to the theory and how it works in the game

Celldoku is based around a area of complex systems research called Cellular Automata. The interest in these systems is the emergent complex behavior that arises from the extremely simple rules that control it.

The system exists as a two-dimensional grid of cells. Each cell has two states, either alive or dead, on or off. The simple rules that control the system are applied to the whole one cell at a time until a new generation or configuration is created.

The rules are applied to each cell individually, and the result of the rule determines whether or not the cell of the same position in the new generation, is alive or dead. Each rule considers the state of the cell which being checked and the state of its eight neightbors. Based on what these values are the rule might determine this cell to either live or die in the new configuration.

Different rulesets cause different behavior to be displayed in the system. One of the most interesting and well known rulesets was created by John Conway in 1970. Despite doing all of his automations by hand on paper he aimed for a truely interesting ruleset and his hardwork resulted in the following three rules:

* A dead cell will birth if it has EXACTLY three neighbors (Nurture)
* A live cell will die if it has 4 or more neighbors (Overcrowding)
* A live cell will die if it has 2 or less neighbors (Starvation)

How does this work in Celldoku?

In Celldoku, each level exists as a broken progression of generations in a Cellular Automata. The player is given an initial configuration on the board and a target configuration is indicated on the board in red. It is up to the player to "fix" the configuration so that when submitted it results in the generation of the target.

In this screenshot the live cells in the player's board are indicated by the dark areas. The target configuration is indicated by redness on the empty cells. If a live cell is currently occupies the target its indicated by a green shading of the cell. A legend:

Clear : Dead cell
Black : Alive cell
Black-Green : Alive cell occupying target
Red : Target

Roadkill and I began programming the engine for our game. Roadkillgrill and ncomption have begun resizing of images. azaran has started developing the gui. Lots of work ahead. yehaw!

Today Morning, My computer wasn't power.!!!
Everything was stoped.
##>

I wrote a quick Python script that corrects images with background colors bleeding through the alpha channel. This problem seems like it can be common to some graphics software, such as sometimes a black halo around antialiased edges. If you are having a similar problem while working with alpha images this script might help. It requires PIL.

#!/usr/bin/python

# Corrects the color of semi-transparent pixels when there is a
# background color bleeding through.

import sys
import Image
import ImageDraw

def help():
	print "USAGE:"
	print "\tfix_img_alpha.py [-o outfile | -b r,g,b | -h] infile"
	print
	print "-o          Out file"
	print "-b x,x,x    Background Color (black by default)"
	print "-h          Display help"
	
if (len(sys.argv) == 1) or (sys.argv.count('-h') > 0):
	help()
	exit()
	
if sys.argv.count('-b') > 0:
	tmp = sys.argv[sys.argv.index('-b') + 1]
	tmp = tmp.split(',')
	back = []
	for i in tmp:
		back.append(float(i))
else:
	back = [0.0, 0.0, 0.0]

infile = sys.argv[len(sys.argv)-1]

if sys.argv.count('-o') > 0:
	outfile = sys.argv[sys.argv.index('-o') + 1]
else:
	tmp = infile.split('.')
	outfile = tmp[0] + '_fixed_alpha' + '.' + tmp[1]

img = Image.open(infile)
outimg = Image.new("RGBA", img.size)

draw = ImageDraw.ImageDraw(outimg)

data = img.getdata()

c = [0,0,0,0]

for y in xrange(img.size[1]):
	for x in xrange(img.size[0]):
		i = y * img.size[0] + x
		# p = (1 - a) * b + a * c
		# c = (p - (1 - a) * b) / a
		p = data[i]
		a = float(p[3]) / 255.0
		if a > 0.0:
			c[0] = min(int((float(p[0]) - (1.0 - a) * back[0]) / a), 255)
			c[1] = min(int((float(p[1]) - (1.0 - a) * back[1]) / a), 255)
			c[2] = min(int((float(p[2]) - (1.0 - a) * back[2]) / a), 255)
			c[3] = p[3]
		else:
			c = [p[0], p[1], p[2], p[3]]
		
		draw.point((x,y), tuple(c))
		
outimg.save(outfile)

So, I'd say I have about 45-50% of the puzzle side of the engine done. I've only got two things that the robot can be used for right now though (as a weight for switches and as a mobile spring-board type of thing). As I create more abilities, I'll probably end up setting myself back further from being complete simply due to their incorporation in actual puzzles. But whatever, it'll work out somehow.

I'm now slightly unsure about the whole combat aspect. I just don't know if I'll have enough time to develop to the length that I want to. If I can crank the puzzle stuff out, then we'll see. Honestly, I'd rather just have a complete game with just the puzzle-based side then a half-done game with both the action and puzzles.

Also, I'm hoping to get some screen shots or maybe a video or something up once I get something other than a square block for my main character, which is the only thing that doesn't have some sort of real graphic right now. I'm doing low-res pixel art to save myself time, so it shouldn't take me too long.

I can't believe the Robot theme was chosen. I don't like it for the same reasons as everyone else who doesn't like it. I could just take the good idea I had for "Formation" and make the character a robot, but I won't do that.

Okay new idea. You people want robots? I'll give you robots. I'll give you more damn robots than every other entry combined! My game is tentatively titled "Gray", and it features 10^20 robots per pixel.

So far, I've got an efficient (enough) cellular automaton that runs in a separate thread using sets. I've never used python sets or threads before, nor have I ever made a CA, so even if I don't do anything else innovative or new, I've already learned three new programming topics, so that's good.

Now I just need some gameplay....

Hello World !

We are writing a strategy game in which you control NetBot in view to control the world ^^. We started coding this evening and now we succeed in scroll on the map.

For those who are interested in following our work :
MonsterBot Mercurial repository

Good code =)

So, Day 2 is over; let's just wrap up the important things:

Done in Art:
- A lot of tiles for levels
- Images/Animations of C.A.T.B.O.T.

Done in Code:
- Implemented the interface/button graphics
- Convinced C.A.T.B.O.T. to actually move


Remaining ToDos:

Art:
- Title Screen
- Splash Screen
- Help Screen
- some additional buttons (about 4)
- more images of various sizes

Code:
- Implementing some new items to the interface
- Loading Levels
- Checking for level conditions
- Implementing Collision detection

Other:
- Music (? Still under discussion)
- Sounds
- Story/Dialogues
- Levels (4-15)

So as you can see not much has changed since yesterday - Gameplay is still completely missing, but hey: we nearly completed the whole interface and I (as non-programmer-but-artist) expect that implementing the gameplay should not be *that* hard within the next 5 days.

And after all, we still were able to create C.A.T.B.O.T. XD