Category: Scripts

A little bit of time has passed since I’ve written an update for this project. It hasn’t been halted in any way, but I’ve found that the further on I get in life (hooray for being 30!), the less time that there is to do things (like updating my site…) that don’t involve maintenance, job-related or game-development related things. But, we march on.

Over the last few months, I’ve touched on things ranging from threading within Python, to command line functionality, to deeper digs into the world of User Interface construction, along with building up knowledge in PHP, Javascript, Node.JS and sockets.IO. User Interface design will come later once things are actually working.

One of the other things I’ve been digging into in relation to this game is artificial intelligence. Eventually, I’m going to need some kind of computer-guided opponents within the races, and it seems like it will be extremely fun to play with. I’m planning on keeping them fairly basic (fixed rays heading out in specified directions) but will branch out from there once I have a workable solution. Whether this yields improvements or new functionality within other places, we’ll see. 🙂

Improvements have also been made in the vehicle leveling functionality. I’ve been bouncing between basing rotation correction on actively adjusting the rotation of the vehicle within the race and functionality that alters the rate of rotational acceleration. I’ve found the benefits of altering the acceleration rate of rotation slightly outweighs having scripted control over the rotation as it feels more “accurate”. Just need to bring the wobble-to-resting-state behavior under control. My grand plan for the vehicle leveling functionality is to find a way to merge the behavior from the two methods to have control and still give the physics system some say in what occurs.

I’ll be working on a video update next so y’all can see what’s going on instead of wondering and waiting with bated breath.

I’ve been playing with the game networking tutorial in the 2nd edition of the Blender GameKit and I found out that in it’s current form, it does not work. After banging on it for a bit, I had seperate scripts for the Game Engine working, a server.py and a client.py with a couple of default values that I had thrown in.

After getting a couple instances of Blender talking to each other (on the same machine for the time being), I felt that it would be better if everything was in one script, and seperate functions were called when needed. That’s what I’ve done, as far as client/server setup and passing data. 🙂

Right now the updateData function only passes location data for two objects, OBClient and OBServer. To use this script in it’s current form , two files will need to be created: server.blend and client.blend, where both objects will need to be present. On each object, there are three sensors required, one always that triggers once, an always that triggers constantly, and a spacebar keyboard sensor.

The always sensor that triggers once is set to run the “universal_networking.networkInitServer” or “universal_networking.networkInitClient”, depending on which one you’re wanting to run. The constantly-triggered always sensor is set to run “universal_networking.updateData”, which exchanges object location data with the other party. The spacebar sensor will need to make it’s way to a Motion controller, where the object is moved in some fashion.

When dealing with connecting the spacebar, only one will need to be connected on each file. For example, on the server.blend file, only OBServer needs to have the spacebar sensor moving anything. Vice versa with the client.blend file.

I’ll be updating this script once I have a method for properly moving different types of data across. For now, enjoy!

DT

networking_universal.tar.gz

networking_universal.zip