So Everybody Knows

I’m working on Blender pretty hardcore, right now. To get the best performance out of the engine, I’ve had to scrap everything I knew about game-development and start from scratch.

Once I get to a point where I’m comfortable stopping, I’ll do some big write-ups for you all. Blender really doesn’t like to be pushed around, but it’s very cooperative when you give it the proper space to work.

Good night~!

Here’s what I’ve got so far.

The Loader

def load(filename):
	ini_file = configparser.ConfigParser({'x':0, 'y':0, 'a':0})
	if not ini_file.read(filename): return

	try: name = ini_file.get('header', 'name')
	except (NoSectionError, NoOptionError): name = filename

	_FRAME_REPOSITORY[name] = ini_file

The Setter

def set(repo_name, num_str):
	if repo_name not in _FRAME_REPOSITORY: return
	rf = _FRAME_REPOSITORY[repo_name]

	self.clear()
	hb = 1
	while True:
		sect = num_str + '.' + str(hb)
		if not rf.has_section(sect): break
		hb += 1

		bpy.ops.object.add()
		box = bpy.context.active_object
		box.parent = self.origin
		box.select = False
		box.worldPosition = self.origin.worldPosition
		box.worldOrientation = self.origin.worldOrientation
		box.applyMovement((rf.getfloat(sect, 'x'),
		                   rf.getfloat(sect, 'y'),
		                   0), True)
		box.applyRotation((rf.getfloat(sect, 'a'), 0, 0), True)
		try:
			pass
			#box.dimensions[1] = rf.getfloat(sect, 'w')
			#box.dimensions[2] = rf.getfloat(sect, 'h')
		except NoOptionError:
			pass

Yeah; I mix tabs and spaces in multi-line statements. Wanna fight about it?

What’s Left

  • I’ve got to write a little something to allow for dimensions to be set: I’ll probably just hack the scale of the hitbox by leaving the depth at 1 (since this is for a 2D fighter) and using it as the base for multiplication or division or whatever the hell I gotta do to get the relative scale.
  • Set the rest of the hitbox-properties
  • load via os for multiplatform functionality
  • asd;fkldasfj;asogfhagfohaewrewragfr3eojirgfaefiroirgafert4kji

Dude, what?

I'm gettin' too black for this shit.

Fuck it, I'm out.

It’s beddy-bye time, bitches. I am out this piece.

I’m thinking of making a setup where loaded INI-files are used to hold the collision-frame data. It’d look something like this:

collibo.load('filename.ini')
body = collibo.Body()
body.spawn()
body.set('name specified in file', 1)

Here’s what the INI-file’d look like:

[header]
name: Bob Saget

[1.1]
type: cat
weakness: dog,water,noise
onhit: scratch
shape: square
solid: 1
x: 0
y: 0
w: 0
h: 0
a: 0
[1.2]
type: dog
weakness: water,newspaper
onhit: bite
shape: circle
solid: 0
x: 0
y: 0
w: 0
h: 0
a: 0

Collibo (“collision” + “[little black] box”) would have a global repository that it would keep to itself, to store these files, of course.

Selecting Objects in Blender, from Python

I’ve been working on how to clear a body-origin of its child hitboxes, and encountered a weird error: the clearing-method would remove the hitboxes, but then the destructor wouldn’t delete the origin! What I discovered was that the one hitbox I was making took away the focus from the origin, and I never returned it. Luckily, there’s a boolean property in the body-object, select, that makes such work child’s play.

After some tweaking, here’s what the clearer looks like:

def clear(self):
	for hitbox in self.origin.children:
		hitbox.select = True
	bpy.ops.object.delete(use_global=True)
	bpy.ops.object.select_all(action='DESELECT')

The constructor has a fancy new line, too!

self.origin.select = False

And, lastly, the destructor has a little more bulk:

def __del__(self):
	self.clear()
	self.origin.select = True
	bpy.ops.object.delete(use_global=True)
	self.origin.select = False

The lesson here is to always be mindful of Blender’s selection-mechanic. I personally am going to make sure that every dynamic object I create is deselected from the get-go, and to use bpy.ops.object.select_all(action='DESELECT') to clean up massive operations.

I advise that you do the same.

Baby Black Box, Revisited

Man, this feels so good. I’ve been thinking that it was impossible to make and control logic bricks from within Python for a while, but now I’ve got it figured out:

def spawn(self):
	bpy.ops.object.add()
	bpy.ops.logic.sensor_add()
	bpy.ops.logic.controller_add(type="PYTHON")
	bpy.ops.logic.actuator_add()

	self.origin = bpy.context.active_object
	c = self.origin.game.controllers['Python']
	c.mode = 'MODULE'
	c.module = ''
	c.link(self.origin.game.sensors['Always'],
	       self.origin.game.actuators['Motion'])

This is what I’ve changed since my previous post on the matter, hence the title. Since logic bricks exist within an object-bound namespace, I can run this little number as many times as I want. The shortcut, ‘c’, is just to keep inline with the Official Python Style Guide without having a mass of multi-line statements; also, I figured it’d be slightly faster than having the system run through self, origin, game, then search an index of controllers.

Blender’s documentation isn’t for programmers.

I’m trying to write my little collision/physics-module, and figuring out how to create objects (and, currently, parent them to each other) from within Python is proving arduous.

Steady progress is being made, so hey. Whatever.

Update: Apparently, I just set the parent-variable in an object. Well.

Modular Physics and Collision

I know that I want to make a “little black box” for hitboxes to use Blender’s built-in physics-engine, but I’m not sure how I want to handle it. Here’s what I’ve got bouncing around in my head right now.

  • First, a sprite would request a main body, which’d be a sphere.
  • The sphere would have a fixed rotation.
  • What the sprite would handle is a Python-object written around the sphere, that would have functions to add/remove hitboxes to the sphere, and to poll them for collisions.
  • The sprite itself doesn’t give even the slightest damn about anything the main body does or what the hitboxes do: it just wants to mess with their indexing and ask ‘em what they’re touching.
  • If the body’s Python-object has a function that parses fighter-data about what shapes to load, I could just have the function parse a text-string that that sprite doesn’t even look at.

Here’s what I think the functions would look like:

  • collision.Body
  • collision.Body.add_hitbox(coord_string, hit_type, weaknesses, *affects)
  • collision.Body.reaction()→ returns the first hitbox with a collision it polls
  • collision.Body.flip()
  • collision.HitBox
  • collision.HitBox(coord_string, hit_type, weaknesses, *affects)
  • collision.HitBox.striking() → returns boolean
  • collision.HitBox.flip()

That’s where my thinking has brought me, thus far.