ProcGen

Windows: http://clydeshaffer.com/downloads/Icosphere/Icosphere-Windows.zip

OSX: http://clydeshaffer.com/downloads/Icosphere/Icosphere-OSX.zip

New level added, for a total of 4! With scenery inspired by Columnar Jointed Basalt formations, and a friendly sub to escort through a minefield.

+Pause menu +Menu on mission fail instead of immediately reload level select +Title/Map screen music playback time persists +Automatic navmesh creation for friendly sub

Artillery math! Here’s the work I did to aim the cannon enemy in my submarine game. 

Happy 2015! Here's a preview of what I'm working on now, and what surely will be the topic of my next "tutorial" post.

This is extraordinatily simple compared to the usual ProcGen content, but I still wanted to share a fun little snippet I threw together just now. Drop this piece of script into your webpage or HTML5 app and you can trigger an "easter egg" function with the Konami Code, or whatever other cheatcode sequence you want to use.

var specialCode = [38, 38, 40, 40, 37, 39, 37, 39, 66, 65, 13]; var specialCodeIndex = 0; var specialCodeTimestamp = 0; var specialCodeMaxDelay = 500; var easterEgg = function() { alert("INFINITE LIVES UNLOCKED"); } window.onkeydown = function(e) { var ts = new Date().getTime(); if((((ts - specialCodeTimestamp) < specialCodeMaxDelay) || specialCodeIndex == 0) && e.keyCode === specialCode[specialCodeIndex]) { specialCodeIndex++; specialCodeTimestamp = ts; if(specialCodeIndex >= specialCode.length) { easterEgg(); specialCodeIndex = 0; } } else { specialCodeIndex = 0; } };

Other cheat codes can be used by changing the specialCode variable. For instance, IDDQD from Doom would be [73, 68, 68, 81, 68, 91].

Recently I've gotten into answering questions on Stack Overflow, and sometimes I have a lot of fun answering a question.

For instance, the problem of naturally moving a computer player in a tennis game is a fairly interesting application of the kinematic equations for single particles.

This is fairly basic high school physics, but for some programmers this sort of math can be intimidating, so I'd like to try to explain this and make it easier!

First, let's outline the problem: You are making a tennis game and want to create a reasonably okay "AI" opponent. If you simply have the opponent try to position itself under the ball at all times, it might not be able to keep up very well. Ideally, you'd like to have the opponent look for where the ball will land, like a human player naturally would. But how can you program the opponent to know this information?

Solving this can be done in two steps:

Figure out when the ball will land

Figure out where the ball will be at that landing time

Figuring out when the ball will land is pretty straightforward, as it can be directly calculated from the distance between the ball and the ground, its current falling speed, and the strength of gravity.

For simplicity's sake, I'll be assuming that gravity is entirely vertical and the ground is located at Y=0.

STEP 1: "When"

The kinematic equations tell us that an object moving at speed V, and changing its speed at rate A, for duration T, will move a distance of V times T plus one half of A times T-squared.

We already know the distance we're covering, since it is the distance from the ball to the ground. We also know from our game settings the acceleration rate of gravity, and the current falling speed of the ball. The rest is a bit of algebra, which I've already plugged into Wolfram Alpha for you:

If you're programming this in C# for Unity3D, it would look like this:

float v = rigidbody.velocity.y; float a = Physics.gravity.y; float d = transform.position.y * -1; float t = - (Mathf.Sqrt(2 * a * d + Mathf.Pow(v, 2)) + v) / a;

Step 2: "Where"

Now that we know when the ball will hit the ground, what do we do with this? We already know the Y-coordinate of the landing position... it's zero! What we need to do now is figure out the two lateral, or non-vertical, parts of the landing point.

Since gravity is entirely vertical, we know that the lateral part of the ball's speed will remain constant until it hits something. This makes it easy to predict the lateral position of the ball, since we know the current speed and the time until landing!

If we take the current speed of the ball, multiply that by the time until landing, and add it to the ball's current position, we'll know the lateral parts of the landing point.

In Unity, this part of the code would look like

impactPos = transform.position; impactPos += rigidbody.velocity * t; impactPos.y = 0;

Step 3: Usage

In the example code, impactPos is a public Vector3 variable of the prediction script attached to the ball. If you wanted to use this to control a computer player, you would write a script that accesses this impactPos variable and moves towards that position.

Since the predictor is attached to the ball, the control component on the "catcher" character would be set up somewhat like this:

In this code, I've added an if-statement that checks whether the ball is on the same side of the "net" as the character, where I'm using the Z=0 line as the net. This makes it so that the character only attempts to catch the ball if isn't already headed towards the opponent's court.

Using Unity's built-in physics without any drag on the ball and bounciness set to 1 for all colliders, pitting two of these "catchers" against each other results in an automatic approximation of a two-player volleyball duel.

P.S.

Since I've already given a screengrab of the catcher code, here's the code for the landing predictor! As you can see, it's actually pretty simple.

Have you ever looked at a claw machine and thought "Wow, that machine sure does exhibit controlled movement on multiple axes. If it had a tool attached, it could be a CNC machine."?  Me too! So I bought a cheap toy claw machine and started hacking on it. Writing control code for a real motorized machine is not all that different from writing movement behaviors for game characters. If you can detect where you are, and know where you need to go and how fast you can move, you can just head in that direction! The picture shows the laptop connected to the arduino, but I have since added an SD card reader for reading instructions independently of the laptop. The gantry has an LED attached on top and a Pixy module is suspended over the whole setup. The Pixy is an easy solution for a hobbyist to do basic computer vision, because it can connect to the arduino and provide coordinates for colored areas it has been told to look out for! Neat stuff! I use this data to control the movement of the machine. With this code: https://github.com/clydeshaffer/AgumanderCNC I've also attached a 2W infrared laser to this, so I wouldn't have to deal with tracking vertical motion. I'm terribly lazy. I wonder what kind of procedural geometry I could program this with?

I made a game for LD30! This is my first Ludum Dare entry that didn't get preempted by school, life stuff or sudden creativity blank-out! Hooray!

The game is called Operation: Ad-Hawk, though there are unfortunately no hawks, fortunately no ads, and not much in the way of an operation. It's mainly about plugging in a LAN and avoiding angry small furry creatures. It's got Windows, Mac, and Linux versions. I opted not to immediately export a webplayer version this time, but I might later.

More of my latest project: An effort to combine everything I love in both Kerbal Space Program and Minecraft*. (*Well, Industrial/Buildcraft to be precise.)