Category: Blender development

My travels through the world of Blender game development.

Blending for Charity!

NOTE: The stream will be starting shortly! Woohoo!

——————————————

Tomorrow, Saturday 25 October 9AM CDT, I’ll be tearing apart and building up a small game that I’ve been working on over the last month. This is being done for the Extra Life charity, which I’m doing with a bunch of people from where I work, WP Engine, as part of a 24-hour gaming marathon. All proceeds will go to Dell Children’s Medical Center of Texas.

The focus of the demonstration isn’t going to be heavy on video game art, but more on what goes into the logic of a game, and being able to get one up and running with Blender.

The entire game is driven using Blender’s logic bricks, for ease of development and relatively instant gratification. Python code will not be involved in this demonstration, as not everyone watching may be a programmer.

But… if this influences one to want to learn Python to do more with the Blender Game Engine, or just to learn code to do fun things, no complaints here. 🙂

Those watching will be able to follow along by downloading a copy of Blender for their computer (Win/OSX/Linux), then downloading my game project from GitHub. It’s licensed under the GPL, so you can take the game and make your own with it!

Links to necessary things:

Blender
The game
The WP Engine team website
My sub-site for donations

Any size of donation is accepted and appreciated. Doing it  🙂

A little stumble from yesterday.

Looks like a bad copy of Overboost went out for Mac OSX, due to not being in a .dmg, which introduced issues with permissions on the executable. It wouldn’t have shown up when running it via Finder, but you would see this via Terminal:

$open overboost.app
LSOpenURLsWithRole() failed with error – 10810 for the file /Users/*removed*/Downloads/overboost_alpha0_osx/bin/OSX_10.9/overboost.app.

There’s a dmg.gz now available that should resolve that problem:
Overboost Alpha 0 For Mac OSX (DMG.GZ)

EDIT:
Once it’s unzipped, Finder drops the .DMG extension. Rename the file and add the .DMG extension to the end, then mount the image and play the game.

Let me know if you encounter any issues, and thanks again for trying out my game! 🙂

And we progress.

Today’s a… big day.

TL;DR: Demo’s at the end of the post. Please read the included readme, as there are important notes included. Also, let me know what you think about the game. 🙂

Up to this point, one of my goals has been to have a nice framework to build my game on. I believe I’m well on my way to achieving this.

That said, I’m giving everyone a chance to play my game as it stands. The one big thing that’s been cut out is the networking functionality, mostly because I’m not ready to kick that out as a part of my game. In the middle of getting it stable-ish and secure enough so that open UDP ports aren’t left open on random computers.

This game is not stopping here. Too much to do, too much to learn, even in the middle of messing around with a Raspberry Pi, roller derby and rebuilding an engine soon. As this project progresses, some of those external activities will probably make their way into this game, and some of the stuff I do here will make it’s way out. To a certain extent, it already has.

I want to thank everyone that’s given me props, sent energy my way, put up with my stubbornness, weirdness, potential anti-social tendencies, what have you. All my Guildhall peoples, my Capital Factory peoples, my family (love y’all!), my friends (love y’all too!), Dorothy (goes without saying <3), my roller derby peoples and my work peoples who have been asking me for a copy of this thing ever since I mentioned it. 🙂

Seriously, thank you all.

Please enjoy, and feel free to spread the link to this post with awesome people.

Overboost Alpha 0 For Mac OSX (DMG.GZ) (Updated)
Overboost Alpha 0 For Windows 7
Overboost Alpha 0 For Linux x86_64

EDIT:

I see that there’s a permissions issue with the Mac OSX copy of my game where it’s unable to run from the directory the .app is housed in. I’ll be checking into this tonight and posting an update once it’s fixed.

Big ol update.

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.

Game Project: Overboost

What’s Overboost?

Overboost is a racing game that’s currently being built within the Blender Game Engine. It’s going to be awesome.

Why make a game?

Originally, Overboost started as an experiment I was playing with the idea of starting a racing game, then mission creep kicked in and I started working on other things (surface alignment script that’s still in progress, experiments with writing GLSL filters) that were tangentially related to a racing game.

After doing that for a bit, and a new year had started, I jumped back on the racing game idea by looking into various ways of walking the freedom in the physics engine back, since it’s somewhat open when left to it’s default settings. From there the controls developed and became a bit better, I had created a handful of other assets to use for testing while improving my python skills with help from the BGE Python Support forums. Other things have come along as well, such as a basic HUD for the game along with adding variation in the vehicle’s performance, depending on the current speed.

Who’s working on this?

At this moment, Overboost is a one man show for the art and programming/scripting of the game. I’m undecided how sound will be done, since that part hasn’t been a big focus lately.

How’s it being made? What’s it going to look like?

For my development process, I’ll be switching from periods of programming to periods of art. There is a game design document floating around on my hard drive that hasn’t been touched for a bit, but I don’t have any concrete timeframes for milestone completion just yet. At this time, I’m shooting to have the game released around the beginning of next year.

Since I’m nearing then end of a period of programming/scripting soon, the art will be picking up, since I’ll have enough to work with as far as putting different vehicles and effects into the game. I intend on putting out a small demo of the game at the end of the programming period, so I’ll be posting a special update once that milestone is reached. Other updates will be coming at semi-regular intervals on my website.

As for the look of the game itself, it’s still in some limbo as well, but I’d like to think that humanity isn’t going to be stuck on Earth forever, will get it’s act together and see the stars up close. Along with that, humanity working with nature instead of against it, is part of the themes I’ve been tossing around mentally.

Where’s it going?

I plan on targeting Linux, Mac OS X and Windows for the time being. Mobile platforms may come later, once I learn how to port the game to an appropriate engine, or Blender gets ported to Android and runs nicely.

I’ve included a video of where things stand at this moment. Thanks for checking it out!

 

Python, sockets and the Game Engine!

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