Ozone Forces

From Physics Simulation Wiki

Jump to: navigation, search
June 26, 2006: Keep It Simple, Stupid
June 26, 2006: Conveyor belt platforms.
July 2005:An NPC hard suit in progress.
July 2005: Two instanced cannons with unique targets.
March 2005: A much later version of the engine and texture set.
July 2004: Making a Maze Game with 2 Levels: Ozone Forces' origins.




July 07, 2006: VIDEO! and FORUM! watch the video leave comments

July 06, 2006: The revalation of OR versus AND: I don't know why it took me so long to figure out. I blame my favourite book for leaving me mentally (and thus logically) damaged. I'm talking about Chapter V, section 3 "The Illogic of English" sub section 1, entitled plainly "Or" Confusions. The reason I bring this up is because Blender's logic bricks offer two very common operators for the controller. AND and OR. I was never sure what either meant over the other. Now I know from getting terribly unbelievably frustrated while trying to explain the illogic to my girlfriend.

To quote the book a bit: ...for example, we can connect 'Bernadette is in the pub' and 'Bernadette is in class' to make 'Bernadette is in the pub or Bernadette is in class.' This sentence is true if Bernadette is in class, not in the pub; and it's true if she's in the pub and not in class. But what if the class is being held in the pub, and both parts are true? ... You might be tempted to say that the sentence is false. 'Or,' it seems, means one or the other, but not both. but it's not completely clear that 'or' always means this. Suppose somebody served you coffee, and told you, "You can have sugar or cream." This sentence seems to imply that it's possible that you have sugar and cream. 'Sugar or cream' here means either one or the other, or both. It's for these reasons that programming languages typically include the operator "xor" to distinguish the one but not the other.

The Answer: Using the AND controller requires all Sensors connected to be giving a "true" signal for it to proceed to actuation. The OR controller conversely doesn't give a rats butt if any of the sensors are true, as long as one of them is. Used in some plain english: (1) "The ball must touch grass material AND The keyboard has to have Shift held down if I'm going to move this silly block up 0.1 units"

I would preffer having a new default controller be an "OR" beacause its more friendly. (2) "The ball must touch grass material OR The keyboard has to have Shift held down if I'm going to move this silly block up 0.1 units. Either one is fine, thankyou!"

July 05, 2006: Where's the time gone? And how come I can't figure out constraints... STILL?! Oh well. I worked on textures for a long time last night. I like texturing. The UV-unwrap in 2.42RC3 is strange though, and I havn't been able to figure out how to use just a regular per-square UV assignment in the case that I accidentally use the silly super-LSCM. Then there's reflections with GLSL. How come the cube map is relative to the camera? That's a waste. Anyhow, with all of these weird obstacles, I compensated by simplifying the level design by a lot just so I can make the deadline. Hooray for being a one-man army! Oh, and I made a pong game... I'm not sure if Erwin wants it since its not exactly Club SILO. Speaking of which, yes, I'm intimidated because it getting screenshots on the bullet homepage and an article in blendernation says to me that the winner has been picked before the deadline; and that sucks a big one.

June 26, 2006: The margins aren't bugging me anymore. Erwin wnet through the trouble to fix them but its not such a big deal. Now I'm concentrating a lot more on level design. I've got half a plan on paper, but I need a more solid level that will be playable to an end for at least 5 minutes... Trouble is the ball moves wicked fast.. So, I designed an elevator and some other strange things to make it more interesting like the conveyor drums. I'd really like a REAL conveyor blet, but constraints are still tough for me to grasp. Maybe soon.

June 20, 2006: I always knew that the GE wasn't "time-based" what what I didn't suspect is that a variable of the "timer" type doesn't synchronize with anything at all -- not even frames. So now that the official test build is out, and "enable all frames" is forced to be on all the time, and I can't measure freakin' TIME with a regular timer, I'll need to code my own timing system converting regular clock readings into miliseconds or something like that. But here's the best part -- since the GE isn't time-based anyway, even something like this wouldn't be useful either as the GE isn't synchronized with real time... So right now I'm working on a fake timer using an IPO. Broken so far.

June 18, 2006: I'm presently battling with these funny things called margins. When objects get too small, below 0.4 meters, bullet has a really hard time registering their existance. Secondly, even if you're within the 20cm radius(?) limit, there is a 10(?)cm "margin" or "buffer space" as I like to call it. Now dynamic objects in my latest version appear to be moving with large gaps of air beneath them. The only solution I know of right now is to scale everything back up to non-realworld sizes and try adjusting gravity and air resistance to reflect those changes. It's a shame too because I'd just made some changes to the key control engine that look beautiful and will only work on a smaller scale because Blender's "Camera" logic brick doesn't allow you to go over 20.00 units.


The controls in Ozone Forces is what makes the game special, and different from any other game -- not just other entries in this contest. I developed the control system over a very very long period of time to make it as perfect as possible. I can't stand poorly designed human-computer interfacing. So here's how the controls work...

  • Camera-Angle-Dependent Direction: Press forward. You'll go forward in the direction that looks like "forward" depending on what direction the camera is currently facing. This operation uses some simple trigonometry so the forces of "up and right" don't add together to give you more speed like some sloppy methods will do.
  • Sticky Controls: Let's say you're going forward. Press backwards and hold it. Don't let go. The ball will slow to a stop, and start going towards the camera. The camera will get pushed back and then turn around to follow the ball. You are now going "forward" again but you're still holding the "down" button. You will continue in this way until you let go. This makes controlling a ball in a 3D environment much easier because there's no fishy buisness about where you're going. It also makes it easy for me to do things like add cinematic camera angles for loop-de-loops. All you have to do is never let go of forward ---- sort of like Sonic Adventure for DC.


I'm trying my hardest to make original music and use a nice mixture of sound effects with appropriate volumes. For my submission, I will have to give you mp3s since making the MOD counterparts would take waaaay too long though that's what I want to do in the end to reduce file size and enable "synamic music". 13 full tracks have been written over the past year for Ozone Forces. The demo at present includes the theme song (bass part is a WIP). The necessary pygame files are included as long as you get the supplemental zip file. Note that you may have to press PKEY a good number of times to get it to work. I'm not sure why.


DOWNLOAD prerequisite pygame, SDL, and python 2.42 DLLs

DOWNLOAD version 1 (2006-06-26)

Back to Game Contest Entries

Personal tools