Howling Moon Software

This has been a busy week for us, so I figured it’s better to inform our devoted readership regarding our activities. Plus, it should be interesting.

While we’re not working on Solaro, we take a variety of contracts to make ends meet. While I won’t give out specific details, you’re probably interested to know what sort of things we do.

Our biggest contracts are Unity3D contracts. We provide programming services on fairly large games (probably about 6 month long dev cycles, with up to 5 people working on them). These games are for large media companies that want to promote their products with a game. It’s a pretty good deal, since I’m sure it’s cheaper than a TV ad, and you’re actually engaging children with the brand in a fun way.

We also do a variety of iPhone work- especially work related to Chipmunk Physics. For obvious reasons, we’re uniquely skilled for working with Chipmunk. In the past, our customers have requested also requested sound engines, ragdoll support, vehicle setup and support, chipmunk based scene and level editing software, Cocoa and Core animation based games, and more!

So I’ll end the post with a plug: If you or anyone you know is interested in expert development, especially for physics in games, please contact us, or visit our contracting page.

It may have seemed quiet for the last week or so, but it’s because we’re working on some great new AI behavior for Solaro.

We’ve set up a small test village that is modeled after what we think the starting area will look like. This area has three landing pad, a warp gate, and a few mission related items. We’ve got a set of ships that fly from one landing pad to another, trading commodities between locations. We’ve also got a set of patrol ships. These patrol ships intercept other ships, chosen at random, and inspect the cargo using scanners. If they find any contraband, they attack the targeted ship. So how do we do it? With a state-based AI system:

The States:

• The Seek State: Ships in the seek state simply move towards a specific point. When they get within a certain distance of this point, they will go to the next state in their list. Oh, and we’ve also got some nice obstacle avoidance, so they’ll fly around asteroids and obstacles.
• The Wait State: This one’s easy. They’ll wait a certain amount of time before going to the next state.
• The Pathing State: This is somewhat similar to the seek state, but it allows for flying through a set of waypoints. What’s the difference? With the pathing state, we can specify the desired speed and direction through each point, and the ship can fly through them without stopping at a specific point. It’s more powerful and flexible.
• The Attack State: Kickin’ ass and taking names… and we’re all out of names.
• The Patrol State: Fly around a specific point at a certain radius and certain speed. If enemy ships come close to the point you are patrolling around, attack them. If they flee, go back to your patrol point. (So already this has proved very useful in missions)
• The Intercept Target State: Intercept a moving target, and in this case, scan it’s cargo.

So if you’re not impressed yet, it gets better! We can combine these states for UNLIMITED FUN. For example, our basic trading cargo ships do the following: First they start off in a seek state, going to a random landing approach point. They get there and stop, and they automatically go to the next state we’ve queued up, which is another seek state to land on the actual pad. After that, they go into the wait state for 3 seconds and it loops over. We’ve got a simple “DamagedBy” method that will cause these ships to switch into an AttackState to attack whoever damaged them. So it’s very easy for us to customize these behaviors- to make a trader that will flee when attacked, mission specific patrols, and all sorts of good stuff.

After a little more filtering of the data, I’ve been able to get nearly perfect detection of sharp polygonal edges in an image! The following image has 28 regular nonagons in it and the output is exactly 28 loops of 9 vertexes each (the green outlines) that are nearly perfect nonagons. The original line segment set was 6,884 segments, and this reduced with near pixel perfect results down to 252 segments. This should allow the algorithm to work very well for creating convex polygons for loaded or dynamically created sprites without creating any extra vertexes that slow down the collision detection.

We’ve been working on allowing players to upgrade ship components in-place. Basically, this is an easy way for players to improve their ship, without having to disassemble and reassemble big pieces of it.

A variety of scrap ship parts can be gathered off destroyed ships- so there’s always something to look for when you’re exploring the galaxy and killing pirates (or perhaps you are a pirate yourself!) Different pieces will upgrade different components on your ship; the upgrades will be small, but noticeable improvements to the power consumption, mass, thrust power of engines, fire speed of your guns, turret tracking speed, and more.

Up until now, the AI in Solaro has been pretty simple. It was basically always attacking, and had no concept of avoiding obstacles. Quite often the AI would simply repeatedly slam into asteroids like a fly trying to get out a window. Humorous yes, but it obviously won’t do for the final game. Today I was working on making the AI fly around the asteroids, and I’m pretty happy with the results.

There are 20 ships in that video taking random paths through an asteroid field without looking as though they were piloted by chimpanzees. The algorithm isn’t perfect. It doesn’t know how to avoid every collision, but it should be a nice building block to make more complicated behaviours from.

We’ve recently made some big strides in cleaning up some of the backend code for handling how ships are put together and how collisions are handled. We uncovered a few bugs with calculating the center of mass of a ship and its moment of inertia. It’s now much more robust as you edit an existing ship, or pieces of your ship are destroyed. Now that this is cleaned up a bit, we can start experimenting with some ‘real’ values for engine thrust and component masses.

I’ve found that your ship’s turn speed and acceleration is too easily changed by adding components, and it’s easy to end up with a ship that’s a lot slower than you expected- so I’ve begun a spreadsheet to balance everything out.

We’ve also got a start on the player’s inventory, their hangar, and what sort of things enemies can drop when you kill them. Our main goal here is to keep it simple- we especially want to avoid having the player do much inventory manipulation- we want the player to focus directly on the fun stuff!

One of the features I really wanted to implement in Solaro was the seamless target view. Basically, as the target moves offscreen the target view appears without changing the perspective. When the target moves back onscreen, it simply stops rendering the target view and there is no sudden pop in the target’s shown position.

The game now fades the static effect and the border from the target view and I think the effect really works!

We’ve got a new demo that starts you in a basic ship, and allows you to land and edit the ship or create a new ship. Also check out a few template missions and our turreted weapons.

Click the image to try out our playable demo in your browser.

Controls are on the demo page.

Please share the video with your friends!

Check out the turrets on this ship automatically track an asteroid as you turn! Notice that they track correctly no matter what side you put them on.