A Useful Snippet:

A lot of game developers will recognize this line of code:

value = lerp(value, targetValue, 0.1);

It’s super useful, and can be used for all sorts of things. With a higher constant, it’s a good way to smooth out jittery input from a mouse or joystick. With a low constant, it’s a nice way to smoothly animate a progress bar or a camera following a player. It will never overshoot the target value even if it’s changing, and it changes the speed based on how far away it is so it will always quickly converge on the target. Pretty good for a one liner!

BUT!

Unfortunately it has a couple problems that are often ignored. The first is that it’s highly dependent on framerate, but is usually applied per frame anyway. The second is that the lerp constant that you need to use is really hard to control. It’s not uncommon to start adding a lot of zeros to the front of the lerp constant to get the desired smoothing amount. Assuming 60 fps, if you want to move halfway towards an object in a second you need to use a lerp constant of 0.0115. To move halfway in a minute, you need to use 0.000193. On the other end of the spectrum if you use a lerp constant of 0.9 you will run out of 32 floating point precision within 7 frames, and it will be exactly at the target value. That’s a little wacky.

Fortunately, with a little math, both issues are easy to fix.

The Math

Don’t feel bad about skipping this section if you don’t care about the math. The solution at the end works just fine without understanding why. 😉

Think of it another way. Say you are lerping by 0.9 each frame. That means you are leaving (1 - 0.9) = 0.1 = 10% of the remaining value. After 2 frames, there will be (1 - 0.9)*(1 - 0.9) = 0.01 = 1% of the remaining value. After 3, (1 - 0.9)*(1 - 0.9)*(1 - 0.9) = 0.001 = 0.1%. After n frames you’ll have (1 - 0.9)^n of the remaining value. Let’s graph that and see what it looks like.

You can see that this example does close in on the target very quickly. Also, since it’s a continuous function, we can figure out what the value between frames would be. This is how you fix the framerate issue, but we’ll get into that more later.

Since floating point numbers have limited precision, you’ll eventually run out and you’ll “arrive” at the target value exactly. Floats can store ~7 significant digits, and doubles ~16. Here’s a quick snippet of Ruby code to test that out.

value = 0.0
target = 1.0
alpha = 0.9
100.times do|i|
  value = (1 - alpha)*value + alpha*target
  puts "#{i + 1}: #{value == target}"
end

And the output?

1: false
2: false
... (more false values)
15: false
16: false
17: true

It shouldn’t be too surprising that precision runs out after the 16th iteration. (1 - 0.9)^17 is quite small. 1e-17 to be exact. That is so small, that in order to store 1 - 1e-17 you would need 17 significant digits, and doubles can only store 16! More interestingly, no matter what your starting and ending values are, it will always run out of precision after 16 iterations. Most game engines use floats instead of doubles, and those can only store ~7 significant digits. So you should expect precision to run out after only the 7th iteration.

What about for other constants? (Keep in mind I’m using doubles, and floats would run out in half as many iterations.) For 0.8 you run out of precision after ~23 iterations, ~53 for 0.5. With constants less than 0.5 it sort of breaks down and something curious can happen. Say you keep lerping with a constant of 0.5. Eventually, you will run out of precision and the next possible floating point number after value will be target. When you try to find the new value half way between, it will cause it to round up to target instead. If you use a constant smaller than 0.5, it will round down to value instead. Instead of “arriving” at target, it will get stuck at the floating point number immediately before it. Interesting, but not all that important since with a few exceptions it’s not a good idea check floating point numbers for equality anyway. Anyway for a constant of 0.4, the value gets stuck at ~70 iterations, or ~332 for 0.1.

So really all you are doing by repeatedly lerping is evaluating an exponential curve. We can use this knowledge both to fix the framerate independence issue, as well as make the values used more reasonable.

Improved Version:

Let’s replace the simple lerp constant with an exponential function that involves time, and see how it works.

// exp() works just as well, probably with little to no measurable performance difference.
value = lerp(target, value, exp2(-rate*deltaTime))

In this version, rate controls how quickly the value converges on the target. With a rate of 1.0, the value will move halfway to the target each second. If you double a rate, the value will move in twice as fast. If you halve the rate, it will move in half as fast. Couldn’t be easier.

Even better, it’s framerate independent. If you lerp this way 60 times with a delta time of 1/60 s, it will be the same result as lerping 30 times with 1/30 s, or once with 1 s. No fixed time step required nor the jittery movement it causes. However, do keep in mind that if your target value is changing over time (such as one object following another) you won’t get the exact same behavior. It’s close enough for many uses though.

Conversion:

So this new version is framerate independent, and easier to tune. Now how do you convert your old lerp() statements into the new ones without changing the smoothing coefficients that already work so well at 60 fps? Math to the rescue again. The following formula will can convert them: rate = -fps*log2(1 - coef). (Note: Use log() instead of log2() if you are using exp() instead of exp2() in your lerp expression.)

Performance:

I’ve never actually tested it! On the other hand, I’ve never run into issues with it. I’m also pretty sure most CPUs have instructions for computing log2() and exp2() nowadays. Computing exp() is only a couple instructions then. Different systems/languages/VMs vary, but I would not worry about it.

Going Further:

I have on few occasions considered going a step further and putting rate on a logarithmic scale too. The advantage is if you are adjusting the rate value through a UI. Halving or doubling a number by typing it in is easy, but not when dragging a slider with the mouse. You would also have to be very careful not to adjust the rate to be negative. Putting it on a logarithmic scale makes the problem go away. Dragging a certain amount to the left would always mean halve the rate, and dragging the same amount to the right would always mean to double the rate.

value = lerp(target, value, exp2(-exp2(logRate)*deltaTime))

We had a great time at GDC last week! We ended up meeting a lot of new and interesting people. It’s always great because we can chat with a lot of people who are and are not using Chipmunk to figure out how we can make it even better.

Farewell Chipmunk Physics. Long Live Chipmunk2D!

Chipmunk isn’t going anywhere. Just rebranding a little bit to make it easier to search for. Google for “Chipmunk” and see how much of it is physics related. 😉

This was a suggestion that came up a bit before GDC in a Cocos2D thread, but came up a couple times more when there.

On that note, I’ve set up a new URL, chipmunk2d.net (currently just a redirect), and a new twitter account @chipmunk2d dedicated to Chipmunk stuff. Follow us and help spread the word!

Unity3D support:

I was never quite sure how to make Chipmunk fit in nicely with Unity, so it’s been an idea that sat on the very back burner. After talking with people at GDC, there definitely seems to be a nice niche market for a good 2D physics engine. It seems a lot of people are frustrated trying to get the builtin 3D physics to do 2D nicely. I think with a bunch of custom editor components we can get something pretty close to the simplicity Unity provides now and then sprinkle in some of our own secret Chipmunk sauce to make it even better.

Chipmunk provides a number of nice features that PhysX does not (or at least are not exposed). Since Chipmunk isn’t doing all that extra work for a dimension that is just being thrown away it’s also *much* faster. So we think we can go simpler, faster, and more flexible. Seems like a win/win/win scenario if you want to do 2D physics games.

Better JS Support:

Last year, Joseph Gentle made a fantastic port of Chipmunk to Javascript. He’s also done a great job so far of keeping it up to date so far. I don’t do much Javascript myself, but it’s become so much better recently that I’m excited for the possibilities! I’d love to put some interactive stuff on the Chipmunk website and in the documentation.

Anyway, with Chipmunk-JS becoming a more or less standard part of Cocos2D-JS, I’m going to try and make timely patches for Joseph so he’s not stuck volunteering to port all my changes and fixes.

Simplify Simplify Simplify!

One of my design goals with Chipmunk is to keep the API as simple as it can be without taking away flexibility. I’ve spent a lot of time thinking about how to avoid thresholds, sensitivity to units and other “tuning” factors. I’ve gotten some very nice compliments on it’s simplicity, so I think I’ve probably done OK in that regard. It could be better though! You shouldn’t need to be a physics engine master to make great games using one. Sometimes I lose sight of what it’s like to be a beginner. I’ve got two particular cases in mind. Simplified object creation and a collision only mode.

Creating a physics object in Unity or Box2D is different than Chipmunk. You lay out your collision shapes and they guess the mass, center of gravity and moment of inertia for you. This takes away some flexibility, but it’s also vastly simpler for beginners. I have utility functions in Chipmunk to help out with that, but sometimes people don’t care or need to know what a moment of inertia is to make a good game. It’s just a barrier that gets in their way.

A lot of people want to make a game that needs collision detection, but don’t really care about physics. It’s perfectly possible to do that with Chipmunk now, but it’s certainly not obvious how for a beginner. I could totally build a simpler API on top of Chipmunk to help with this.

Continuous Collision Detection (CCD):

This is related to the previous point. I’ve tried to make Chipmunk’s API as simple as possible and make it so that things “just work” without having to fiddle with thresholds and scales and such. One thing that doesn’t “just work” in Chipmunk is continuous collision detection. I usually sort of brush it off as being unecessary or usually very easy to work around, which is true, but missing my own point. Collisions should “just work” and not be something that you need to worry about as a designer. Erin Catto made that point in his GDC talk on collision detection, and it really struck a chord. The 6.2 beta branch is already a big step in the right direction.

I’ve been sitting on some ideas for mixing pseudo-velocities and speculative contacts for some time. I think it could work really well and solve some of the things I didn’t initially like about speculative contacts. If it works well, it will be awesome. 😀 If not… then I’ll have to go with something more traditional. 🙁

More Tutorial Content:

Documentation, examples, tutorials… There can never be enough! I try to make as much as I can, but it’s very time consuming to do. I met up with Ray Wenderlich and Rod Strougo (They wrote the book “Learning Cocos2D”) at GDC and they sounded pretty interested in working with us to make more of it and get it out where people can see it. They are pretty active in the books and documentation realms, so I think that can be a great asset.

Great. Can you have it done by Friday?

Oof. So clearly that is a lot of stuff to chew on. Our company mostly supports itself by doing contracting work, but we’ve scheduled a big block of time for enhancing Chipmunk for a while. If there’s something you’re really dying to have in Chipmunk, let me know. It’s good to have some external input when prioritizing.

There are some notable limitations with Chipmunk’s current code that a lot of people run into. Deep poly/poly or poly/segment collisions could produce a lot of contact points with wacky positions and normals which were difficult to filter sensibly. This was preventing me from implementing smoothed terrain collision feature that I wanted (fix the issue where shapes can catch on the “cracks” between the endpoints of segment shapes). Also, until recently line segment shapes couldn’t collide against other line segment shapes even if they had a nice fat beveling radius. They can now thanks to a patch from LegoCylon, but they have the same issues as above, generating too many points with wacky normals. I also had no way to calculate the closest points between two shapes preventing the implementation of polygon shapes with a beveling radius. Yet another issue is that the collision depth for all of the contacts is assigned the minimum separating distance determined by SAT. This can cause contacts to pop when driven together by a large force. Lastly, calculating the closest points is also a stepping stone on the way to get proper swept collision support in Chipmunk in the future.

For some time now, I’ve been quietly toiling away on a Chipmunk branch to improve the collision detection and fix all of these issues. I’ve implemented the GJK/EPA collision detection algorithms as well as a completely new contact point generation algorithm. After struggling on and off for a few months with a number of issues (getting stuck in infinite recursion/loops, issues with caching, issues with floating point precision, suboptimal performance, etc… ugh), it finally seems to be working to my expectations! The performance is about the same as my old SAT based collision code, maybe 10% faster or slower in some cases. Segment to segment collisions work perfectly as do beveled polygons. Smoothed terrain collisions are even working, although the API to define them is a little awkward right now.

Beveled line segments colliding with other shapes!

GJK:

The aptly named Gilbert–Johnson–Keerthi algorithm is what calculates the closest points between two convex shapes. My implementation preserves the winding of the vertexes it returns which helps avoid precision issues when calculating the separating axis of shapes that are very close together or touching exactly. With the correct winding, you can assume the edge you are given lies along a contour in the gradient of the distance field of the minkowski difference. I’ve also modified the bounding box tree to cache GJK solution. Then in the next frame, you can use that as the starting point. It’s a classic trick that makes GJK generally require only a single iteration per pair of colliding objects.

GJK is rather abstract, but it calculates the closest points between two shapes by finding the distance between the minkowski difference of two shapes (the red polygon) and the origin (the big red dot). If you look closely, the red shape is a flipped version of the pentagon with the little triangle tacked on to all it’s corners. It’s one of the coolest and most bizarre algorithms I’ve ever seen. 😀 I’ll probably make a blog entry about my implementation eventually too.

EPA:

EPA stands for Erik-Peterson-Anders… Nah, it stands for Expanding Polytope Algorithm and is a very close cousin to GJK. While GJK can detect the distance between two shapes, EPA is what you can use to find the minimum separating axis when they are overlapping. It’s sort of the opposite of the closest points. It gives you the distance and direction to slide the two shapes to bring them apart (as well as which points on the surface will be touching). It’s not quite as efficient as GJK and it’s an extra step to run which has the interesting effect of making collision detection of beveled polygons more efficient than regular hard edged ones. This is one thing I’m not completely happy with. Polygon heavy simulations will generally run slower than with 6.1 unless you enable some beveling. It’s not a lot slower, but I don’t like taking steps backwards. On the other hand, it will be much easier to apply SIMD to the hotspots shared by the GJK/EPA code than my previous SAT based code.

Contact Points:

Having new collision detection algorithms is neat and all, but that didn’t solve the biggest (and hardest) issue; my contact point generation algorithm sucked! Actually, it worked pretty good. It has stayed mostly unchanged for 6 years now, but it has also accumulated some strange workarounds for rare conditions that it didn’t handle well. The workarounds sometimes produced strange results (like too many contact points or weird normals…). They also made it practically impossible to add the smoothed terrain collision feature.

In the new collision detection code, polygon to polygon and polygon to segment collisions are treated exactly the same. They pass through the same GJK/EPA steps and end up being passed to the same contact handling code as a pair of colliding edges. It handles collisions with endcaps nicely, always generates either 1 or 2 contact points for the pair, and uses the minimum separating axis for the normals. It’s all very predictable and made the smoothed terrain collisions go pretty easily. It only took me about 10 iterations of ideas for how to calculate the contact points before I got something I was happy with. -_- It really ended up being much, much harder than I expected for something that seems so simple in concept.

The implementation works somewhat similarly to Erin Catto’s contact clipping algorithm, although adding support for beveling (without causing popping contacts) and contact id’s made it quite a bit harder. There are some pretty significant differences now. Perhaps that is another good post for another day.

Coming to a Branch Near You!

The branch is on GitHub here if you want to take a peek and poke around. It’s been a pretty big change, and hasn’t been extensively tested yet. I wouldn’t recommend releasing anything based on it quite yet, but it should be plenty stable for development work, and should even fix a number of existing issues. I’d certainly appreciate feedback!

It has been a few months since Chipmunk 6.0.3 was released! We’ve had a lot of contracting work to distract us from core Chipmunk development lately. Even so, we’ve been cooking up some new features and now I’m currently working full time putting the final touches on 6.1. So what’s new to get excited about? Here are a lot of words!

Approximate Concave Decomposition (Pro only):

One of the features that has been missing from Chipmunk Pro’s autogeometry is some form of concave decomposition. A lot of people use a triangularization algorithm to solve this. Unfortunately, while triangularization is great for creating perfectly decomposed triangle meshes for rendering, and are pretty easy to implement, they doesn’t work very well for generating collision detection shapes. It tends to create more shapes than you want or need and can produce very small or thin shapes. This can clog up the spatial index, giving you poor overall performance, and cause other frustrating artifacts in the simulation quality.

Instead of triangularization, I’ve been working on approximate concave decomposition (ACD) for Chipmunk Pro. This means that you ask Chipmunk to decompose a concave polygon with a distance tolerance, and it will give you back one or more convex polygons that match the shape of the original to within the tolerance. The ACD algorithm tries to match the most important features of the input first to create a high quality decomposition. Also, because it can stop once it satisfies the tolerance, the performance can be really good and used at runtime even. If you want a perfect decomposition, you can still always use a tolerance of 0.0. Although this can take more time and produce more shapes than you might want.

The ACD algorithm shipping with 6.1 isn’t perfect though. I’m still improving it’s splitting plane hueristic to improve how it cuts the polygons (I’m not too happy with the ‘H’ in the image above -_- ), and it doesn’t yet have options to detect or process polygons with holes in them (like the ‘P’). Lastly, if you run ACD on a self intersecting polygon, it might cause it to over-simplify it because it detects the polygon as having a negative tolerance.

Because we are still working on the quality of the algorithm, and its missing the ability to work with holes, we’ve marked it as being beta. Its usable and stable, but its performance and quality might not be as good as some people want yet. I didn’t want to hold up the release longer while I did more research for this, but at the same time didn’t want to leave it in an unusable state.

Multithreaded Solver (Pro only):

This has been in the pipeline for a long time! There has been early access to this available through the Chipmunk Pro git repository for some time, but the next release will make it official. This complements the ARM NEON optimized solver and works on any platform that supports pthreads. This is an easy way to take advantage of those extra cores that now ship on everything from desktop to mobile machines. The Chipmunk Pro showcase app on the App Store uses the multi-threaded solver and enables a lot of extra objects to simulate on the iPad 2 and iPhone 4s. Check it out!

Convex Hulls:

Since the beginning of time (or like 2006… whatever), Chipmunk has required that you carefully provide it with convex polygon data with a specific winding. Every good graphics API does this too, so people know to expect this sort of thing right? Nope. I talked with Erin Catto for a while at GDC and he mentioned that the winding and concavity of polygon shapes was one of his biggest support issues and that he recently added a convex hull algorithm so that it would “just work”. I’ve had assertions to ensure concavity and winding, but Erin’s solution was better. 2D game programmers often aren’t graphics experts, and they shouldn’t need to be. I’ve had a nice QuickHull implementation sitting around for some time, so I decided to make it more generic and include it with Chipmunk. Nobody will ever have to bother with concavity or winding ever again. \o/

Nearest Point Queries:

The main inspiration for the original point query feature in Chipmunk was selecting shapes with the mouse. Using a single point made great sense for this as mice are very precise devices. With touchscreen devices its not perfect. Using a single point to represent a big fat finger doesn’t work very well. Its very frustrating to try to grab a small shape with your finger only to fail repeatedly. I’ve seen some people doing clever sampling tricks to try and get around it, but we can do better! Nearest point queries are the next logical step. Instead of just a yes/no answer to if a point is inside a shape or not, nearest point queries give you the nearest point on the surface of a shape as well as the distance to it (or the depth the point is inside). Now when you tap a big fat finger on the screen, you can trivially find the closest shape within a certain radius. The ChipmunkMultiGrab class in Chipmunk Pro has already been updated to support this.

Block Iterators:

Almost every language in existence today other than C/C++ has some sort of concept of closures or anonymous functions. One of their uses is to allow you to make some really slick, simple APIs for iterating complex data structures. You just pass a chunk of code to the thing you want to iterate and it will call your code for each object. This is why Chipmunk has so many function based iterators (cpSpaceEachBody(), cpBodyEachShape, cpSpaceSegmentQuery(), etc). Exposing the underlying data structures would be annoying to the user as some of them aren’t simple, and it would mean I can’t change them later if I need to.

Even if you are using Chipmunk from C or C++, most compiler provide some extensions to make your life easier. GCC supports inner functions, and Clang supports blocks. I’ve often encouraged people to use them, as the iterator functions were intended to be used with language features such as these. I started making sample code for a tutorial showing how to use them with Clang blocks, but then decided that I might as well just put that code into the official Chipmunk API instead.

Without the block based iterators, you write code like this:

// Define your callback function somewhere like this:
static void
ScaleIterator(cpBody *body, cpArbiter *arb, cpVect *sum)
{
	(*sum) = cpvadd(*sum, cpArbiterTotalImpulseWithFriction(arb));
}

// ... and then somewhere else use it like this:
cpVect impulseSum = cpvzero;
cpBodyEachArbiter(scaleStaticBody, (cpBodyArbiterIteratorFunc)ScaleIterator, &impulseSum);

With the new block based iterators, its much nicer. You can keep the code all in one place:

__block cpVect impulseSum = cpvzero;
cpBodyEachArbiterBlock(scaleStaticBody, ^(cpArbiter *arb){
	impulseSum = cpvadd(impulseSum, cpArbiterTotalImpulseWithFriction(arb));
});

On the heels of our new web page, we’ve released Chipmunk 6.0! Our press release follows:

 

Howling Moon Software is excited to share Chipmunk 6.0, the latest major version release of their popular physics engine. Chipmunk is a high performance, MIT licensed 2D physics library with all the fixings. Written in C99, bindings and ports exist to over a dozen languages. Including an official binding to Objective-C that makes it fit right in on the iPhone. Chipmunk has recently been seen in many top iOS hits, including Cars 2, Feed Me Oil, I Dig It, Alice in New York, and Zombie Smash! It’s been used on many platforms including Mac/Win/Linux, iPhone, Android, Symbian, DS, PSP, and even the Wii.

We’ve also released Chipmunk Pro, a library with extra features that can dramatically speed development. Chipmunk Pro features an Objective-C binding with additional iPhone specific features to ease things like input handling. Push the envelope with new beta features like multicore support and automatic generation of terrain and geometry based on images.

New features in Chipmunk 6 include many API improvements to aid the clarity and ease of using the engine. Chipmunk 6 now supports multiple spatial indexes and includes a bounding box tree which doesn’t need tuning. Support for variable timesteps and release-mode error handling has also improved.  Chipmunk 6 comes right behind Chipmunk 5.4.3, which featured numerous bug fixes.

New in Chipmunk 6.0:

* API: Chipmunk now has hard runtime assertions that aren’t disabled in release mode for many error conditions. Most people have been using release builds of Chipmunk during development and were missing out on very important error checking.
* API: Access to the private API has been disabled by default now and much of the private API has changed. I’ve added official APIs for all the uses of the private API I knew of.
* API: Added accessor functions for every property on every type. As Chipmunk’s complexity has grown, it’s become more difficult to ignore accessors. You are encouraged to use them, but are not required to.
* API: Added cpSpaceEachBody() and cpSpaceEachShape() to iterate bodies/shapes in a space.
* API: Added cpSpaceReindexShapesForBody() to reindex all the shapes attached to a particular body.
* API: Added a ‘data’ pointer to spaces now too.
* API: cpSpace.staticBody is a pointer to the static body instead of a static reference.
* API: The globals cp_bias_coef, cp_collision_slop, cp_contact_persistence have been moved to properties of a space. (collisionBias, collisionSlop, collisionPersistence respectively)
* API: Added cpBodyActivateStatic() to wake up bodies touching a static body with an optional shape filter parameter.
* API: Added cpBodyEachShape() and cpBodyEachConstraint() iterators to iterate the active shapes/constraints attached to a body.
* API: Added cpBodyEeachArbiter() to iterate the collision pairs a body is involved in. This makes it easy to perform grounding checks or find how much collision force is being applied to an object.
* API: The error correction applied by the collision bias and joint bias is now timestep independent and the units have completely changed.
* FIX: Units of damping for springs are correct regardless of the number of iterations. Previously they were only correct if you had 1 or 2 iterations.
* MISC: Numerous changes to help make Chipmunk work better with variable timesteps. Use of constant timesteps is still highly recommended, but it is now easier to change the time scale without introducing artifacts.
* MISC: Performance! Chipmunk 6 should be way faster than Chipmunk 5 for almost any game.
* MISC: Chipmunk supports multiple spatial indexes and uses a bounding box tree similar to the one found in the Bullet physics library by default. This should provide much better performance for scenes with objects of differening size and works without any tuning for any scale.

Chipmunk Physics is especially popular on iOS devices, and we look forward to seeing even more great games using Chipmunk Physics. Chipmunk is open source, licensed under the MIT License. Basic Chipmunk is free to use, and Chipmunk Pro is available for $200. Howling Moon Software also takes donations to support Chipmunk development and offers contract development services.

The Chipmunk Physics engine now finally has it’s own web page!

http://chipmunk-physics.net/

It’s been a long time coming, but now all chipmunk-related information is on the same web page. Previously we had documentation, downloads, and the forums scattered across different pages. But Chipmunk has been steadily growing, and the time came for it to have a proper page.

We’ve had a lot of high profile games use Chipmunk recently, including the last few #1 iOS games:

Feed Me Oil uses Chipmunk for the non-fluid physics simulation bits. It was the number one game just a week or so ago. Now Cars 2 has hit number one on the store– it also uses chipmunk for it’s side scroller racing action.

 

Times are good for developers using Chipmunk!

As  you’ve probably heard, today is the release date for the Mac App Store. We’ve got Crayon Ball on there, and it’s a discounted price!

http://itunes.apple.com/us/app/crayon-balls/id404081618?mt=12

We only touched on the arenas briefly in previous posts. An arena system allows the player to get right into the game, and it enables an effective risk-reward cycle.

Players are encouraged to choose their own pace and challenge level. Right now, six different arenas make up a zone. Each arena in a zone has a different sort of mission. Some of these are just straight up killing enemies, fighting a few waves of enemies, racing through waypoints, destroying asteroids under a timer, or taking out a big boss ship. Different rewards, in the form of new pieces for your ships, are earned at each arena.

At your option, you may fly to the next zone at any time. Each zone has more difficult challenges, but you unlock new sorts of items for your ship. For example, in the second zone, you unlock two new types of weapons, the thorium engine, the fighter cockpit, and a few new hull pieces.

If you find the game too hard, simply get a few more weapons in an easier zone. If it’s too easy, players will move on to advance more quickly. This isn’t too unique of a concept for games, but I do think it’s underused- it’s a very natural and effective means of difficulty control, and it’s certainly more elegant than a difficulty selector.

Sometimes, a good set of shields is the only thing between your face and the cold vacuum of space.

This ship has been outfitted with two small shield generators. Each shield generator creates a sphere around it, protecting the components it encompasses. However, each shield can only absorb so much damage. Once it becomes red, the shield is expended, and it will only recharge after several seconds of inactivity.

With a system like this, placing your shields becomes a small but fun tactical choice. Overlapping shields provide additional protection, and creating foward/aft or starboard/port combinations of shields allows you to rotate your ship towards the strong shield while in combat. If you’re really skilled, presenting a strong shield can give your damaged shield time to recharge.

Although you can’t tell from the screenshots, there is a really cool plasma effect on the shields. If you don’t want to take my word for it, try out our demo from a few days ago!

http://howlingmoonsoftware.com/wordpress/?p=510

We fixed some bugs with the ship damage stuff- it had to do with how values were recalculated when components were lost. We created a medium blaster, as I’ve been learning how to model a little bit. It’s a slower, but more powerful weapon with a larger energy draw.

I’ve done some visual upgrades to the ship editor, and Scott did some work on turrets that auto-track. We also made quest indicators that show up on your map for active quests.

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.

The last few days I’ve spent on Solaro have been cleaning up the ship editor. I’ve made the editor much simpler, but kept all the features. Reorganizing the UI has eliminated big rows of text buttons that were difficult to mentally parse. I’ve also removed the second “inspection mode” that you would occasionally need to switch to.

Read more…

Here’s a quick art post. We’ve recently licensed a set of buildings for Solaro. Here’s one of them in game:

See all the new buildings!

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!

Just about everybody who’s played a shooting game knows about leading the target. For instance, in Halo, rockets move pretty slow compared to bullets. To get good at the game, you have to learn how far ahead of your target to fire the rockets so they will run into the rocket’s path just as it gets to them.

This isn’t an easy skill to learn as a player, so how do you implement it so that AI players can do it too? It’s easiest to think of this problem in relative positions and velocities. This puts the firing point at the origin and the relative motion of the target is a line. This is of course assuming that the target isn’t changing direction or accelerating.

Because you don’t know which direction to fire the bullet in, think of it as an expanding circle of bullets in every direction instead of just a single bullet. The distance of these bullets from the gun at time t is then simply the absolute value of t times the muzzle velocity. This is good to know, because at any particular point in time we also know the position (and therefor distance to) the target. This is good! When the distance of the bullets is equal to the distance to the target we have a hit. Let’s graph the two distance equations together to see what we are dealing with. In the following graph, the target (blue line) and the bullet (red line) are moving at the same speed. The X-axis is time, and the Y-axis is the distance from the gun. The target starts to the upper left of the gun and is moving right. That is why the line dips downward.

The point where the two equations cross is the point in time where a bullet can hit the target if fired immediately and in the correct direction. However, it looks like the equations could possibly intersect in more places than one. How many times can they cross? In the example graph shown above, the bullet and target are moving at the same speed and the target is moving towards the gun. In this case there is only one intersection.

In the above graph, the bullet is moving faster than the target. No matter which way the target is moving, the bullet will be able to catch up with it and hit it. There are two intersections in this graph and one of them is in the past. How is this possible??? Well, the bullet is moving in a straight line, and for the equation to make sense, it had to have been moving through the gun at the exact time it was fired. So if you could fire a bullet backwards through time, you could hit the target. Not helpful to figure out where we need to fire without a time machine though.

In this case, the target is moving faster than the bullet and the target is moving away from the gun. The bullet is never able to catch up to the target and there is no firing solution.

In this final case, the target is moving faster than the bullet, but starts out moving towards the gun. There are two possible ways to hit the target. You can either fire the bullet towards the target and hit it as it comes towards you. You can also fire the bullet out in front of the target and let the target catch up to and hit the bullet. While somewhat humorous that this is possible, it would be rather daft. It would give the target (either a player or an AI pilot) plenty of time to change direction and avoid the bullet. In the case of a kinetic weapon, it would also decrease the relative velocity of the bullet and target so that it would do less damage anyway.

So now that we have all of these possible cases, how do you know when you can actually hit the target or not and which solution to pick? It turns out that the problem can be reduced to a simple quadtratic equation and solved with the quadratic formula. Solving it isn’t too hard, so I’ll spare the details. You end up with the following coefficients: a = Vr•Vr – Vm^2, b = 2(Vr•D), and c = D•D. Vr is the relative velocity of the gun and the target, Vm is the muzzle velocity (bullet speed), and D is the relative position of the gun and the target. For those who are unfamiliar with vector algebra, • is the dot product operator. u•v is the same as u.x*v.x + u.y*v.y+ u.z*v.z (if you are doing 3D). Changing the quadratic formula around a bit you can solve for the smallest positive time value using x=2c/(sqrt(b^2 – 4ac) – b) (wikipedia refers to this as the alternate form). However, when both solutions are negative, it will return the smallest negative solution. Here’s the C# Unity3D code we use to calculate the time of impact:

// Calculate the time when we can hit a target with a bullet
// Return a negative time if there is no solution
protected float AimAhead(Vector3 delta, Vector3 vr, float muzzleV){
  // Quadratic equation coefficients a*t^2 + b*t + c = 0
  float a = Vector3.Dot(vr, vr) - muzzleV*muzzleV;
  float b = 2f*Vector3.Dot(vr, delta);
  float c = Vector3.Dot(delta, delta);

  float det = b*b - 4f*a*c;

  // If the determinant is negative, then there is no solution
  if(det > 0f){
    return 2f*c/(Mathf.Sqrt(det) - b);
  } else {
    return -1f;
  }
}

We return a negative number when the determinant is negative (not solvable). This works out well because it will also return a negative number when there are two solutions and both are negative. The code that uses the value can simple check if it’s negative to mean that there is no solution.

So now we know everything we need to know except where to aim the bullet at. We started out with the assumption that we could fire out an infinite number of bullets in every direction around a circle and that one of them would hit the target. The only bullet that actuall will hit the target is the one that is aimed at the spot where the target will be at the time of the collision, and because we are assuming that the target moves in a straight line, this is easy to solve for:

// Find the relative position and velocities
Vector3 delta = target.position - gun.position;
Vector3 vr = target.velocity - gun.velocity;

// Calculate the time a bullet will collide
// if it's possible to hit the target.
float t = AimAhead(delta, vr, muzzleV);

// If the time is negative, then we didn't get a solution.
if(t > 0f){
  // Aim at the point where the target will be at the time
  // of the collision.
  Vector3 aimPoint = target.position + t*vr;

  // fire at aimPoint!!!
}

Now you should know everything that you need to implement leading a target for the AI in your own games!

Getting the controls just right for Solaro has been something we’ve put a lot of work into. So we’ve continued to refine how you control your ship in order to maximize the fun for everyone.

We’ve found that choosing just the right control scheme depends on a lot of factors in a game. Different acceleration rates and flight speeds work better with different sorts of control schemes. In Solaro, our zooming system and universe setup differs from other games, so we’ve had to do a lot of experimentation to get things just right.

With the new default control scheme, the flight computer will make the necessary adjustments to keep your ship flying in the direction you’re facing.

This change went hand-in-hand with a change to how the turreted weapons work. We’ve removed the fixed and partially rotating turrets. This greatly simplifies the user interface when the player is making a ship- we’ve removed some buttons and made it easier to use. But more importantly, since all weapons rotate towards a target, we’ve been able to make the changes to the flight controls because strafing is no longer an important part of flying. This lets the player focus more easily on flying and combat and makes it more enjoyable.

The first five minutes of gameplay is responsible for hooking your user. And within those first five minutes you need to teach your player about what’s going on.

Becoming hooked on a game relies on engaging the person. You have to show off the start of the game and show that there’s more, sparking curiosity. Tutorials don’t just need to teach the user how to play, but they also need to quickly hook the user- especially if you’re relying on them  to make a purchase after playing the tutorial.

Read more…

Who says that you can’t be polite and proper even if you are a programmer?


#define please

int a = 5; please

int myFunction(){ return 5 please; }

if(error) abort please ();


Scott and I have spent much brainpower on the matter of deciding what elements of our universe collide with what. Our primary question is: Should ships collide with other ships? There are both gameplay and technical considerations here.

First, we’ll start with some background. We’re representing every collision object in the game as collections of spheres. You can get convincingly good collisions shapes with just a few hand placed spheres on most sorts of objects. Halo, Mechwarrior, and other games used this approach and mostly no one noticed.

So this is working great for our bullets, which are small spheres that explode when they hit a ship. These are fast swept collisions, so bullets never pass through objects. The bullet explosion and smoke more than hides any inaccuracy.

Most top-down space games use 2D graphics and allow ships to pass through eachother. It’s probably best to break down the pros and cons of each approach:

Ship to ship collisions:
Pros

• No clipping! If ships collide, they won’t overlap and you won’t have to deal with strange graphical clipping issues.
• No flying inside huge stuff. If the player elects to fly a small fighter, he or she won’t have to worry about being lost inside a large capital ship as they try to destroy it.

Cons

• Possibly difficult strafing and attacking gameplay? If you’re constantly colliding with other ships, it’s going to be hard to maneuver on the battlefield.. Maybe. It’s hard to tell what the end result will be.
• Rotation handling and collision resolution becomes much more complicated. This is probably the biggest disadvantage. Imagine a player-created ship that is much longer than it is wide. If it moves along side another ship and rotates, what happens? Ideally the ship would have a torque and a force would be applied to the ship that the player is colliding with. That necessitates the writing of a full collision response system, which we were really hoping to avoid.

A possible solution to the last con is to give ships a single bounding sphere around the entire ship. Use this sphere when colliding against other ships or asteroids. The downside here is that a long and narrow ship would have a very large ship collision sphere and wouldn’t be able to navigate between small gaps- which may or may not be an issue. Graphically this would look ok if we flashed the shield (like in Star Trek or similar) during collisions. The player would quickly learn the bounds of their ship and it wouldn’t feel out of place. Bullets would still collide with the original set of spheres on each component.

Ships pass through other ships:

Pros

• It’s easy to implement!
• No accidentally flying into stuff!

Cons

• Graphical clipping may occur. Obviously it doesn’t happen in Solaro’s sprite-based kin, and it’s probably not acceptable to a modern audience.
• Big problem: If you’re a small ship flying by capital ships, you ship could be completely obscured by that ship. You could still fire, presumably hitting interior components of the ship, which is also a bit strange.

So, brainstorming on solutions would be greatly appreciated. Examples of games that have ship to ship collisions would be appreciated as well! Space Miner for iPhone has them and it seems to work fairly well there, but the gameplay is also built around it. Ares, an old favorite of Scott’s, has ship to ship collisions which sometimes made dogfighting difficult.

Scott and I are leaving for GDC in just two days. If you’re going to be in the area and would like to meet up, please give us an email!

This is part two of an overview of cool shaders we wrote for Solaro.

We’ve also got a vertical distortion shader that we can apply to things like in game text, title images, and other billboard effects. Used here on the “Solaro” title, this shader creates a bit of a video interference effect… and again, it looks a lot better in action. We vertically scroll a very tall and wrapping 1×512 pixel normal map, and we use it as a distortion map. This creates a moving pattern over the image that shakes it to the left or the right. This effect can add a lot to an otherwise plain title or static image. The animation brings it to life with a digital sort of effect.

The target view shader is applied to the entire target camera. This inset camera is used to get a view of a targeted ship if it’s off screen. We create an animated noise grain over the image, as a sort of static effect. We also apply an edge burn texture around it, which helps visually differentiate the target view from normal space. Another nice effect of the target view shader is that it allows us to fade the view in and out smoothly. This allows for a seamless transition from a ship on the screen, to one that has moved offscreen and is now represented within a target camera box.

Our shield shaders are used in a few different places. This is our PlanarShield effect. It takes one base texture, but samples it twice at different points, each changing as a function of time. The resulting effect is a smooth wrapping animation of movement in the shield. When it’s applied to a sphere, you get a very cool plasma-like effect. This shader also modulates the intensity as a function the y position of the UV coordinates. With the way our sphere is unwrapped, this makes our shield more transparent at the top and bottom, so you mostly just see the shield around the edges of the circle. This allows you to still see your ship through the center of the shield.

We do a similar animation effect on our warp gates. However, we adjust the falloff differently so the visual effect is strongest at the center. This hides the y=0 line of UV coordinates at the center of the sphere, since it’s fully opaque there. You then see a swirling vortex animation centered around the middle of the warp gate.

All ships in Solaro are equipped with these deflector shields. They activate and pulse once each time you bump into a solid object with your ship. They have a similar animation, but they only show up at the point of impact. These last three images show how you can get a lot of milage from a custom shader with only a few changes.

I don’t know how it happened, but Solaro has 37 custom shaders in the project!

We’ve got a lot of variety in our shaders; some are full screen effects, many of them are for special UI effects or weapon effects, and we’ve also got special shaders for weapon and shield effects. So it’s time for a short pictorial tour of the shaders in Solaro! Most of our shaders are customized to make cool animated effects, so I’ll do my best to capture them in a way to show off in screenshots.

Read more…

Since we’ve been pretty busy these last few months, we wanted to share what we’re currently focusing on with Solaro. Solaro: Skirmishes is a space flight simulator action game that focuses on arena based combat. As you win each arena, you are awarded new components, such as weapons, shields, missile launchers, and hull pieces to add to your ship.

This gives us a great testing ground to see what kind of combat is fun. We can test the balance between different weapons and shield setups. Our previously mentioned mission system allows us to easily create a variety of different sorts of arenas.

Right now, we’re just showing off the basic framework of the arena combat system. We’ve retooled controls and redone a lot of artwork. There are still a few rough spots that we’re redoing, but this is a good example of what’s to come.

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

Controls are on the demo page.

Please share this blog post with your friends!

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.

Great things happen on a great canvas, right? Scott’s been working furiously on some neat effects for drawing backgrounds in Solaro. Coloring the nebula in the background differently based on the area you are in is a great start in keeping the world memorable (which was one of our key goals). We want that world to be open and seamless too, so that means some kind of crazy zooming in on a huge colorful nebula. The graphics look great when you’re zoomed out all the way, or when you zoom into 13,000x to see your ship against a still clear and textured nebula.

Click the image to try out our playable demo in your browser. You’ll need the Unity 3D web player to try it out.

Keys: Plus and Minus to zoom in and out. This demo features our 13,000x zoom system, our dynamic level-of-detail nebula, and it also shows off zooming to target and some rough HUD radar icons.

Scott and I have been chatting a bit about economic simulation trading games. DrugWar style trading games are popular in space- buy low, fly somewhere else, and sell high. Sometimes, as you buy and sell goods, the prices fluctuate. But I got to thinking about what is intrinsically fun about these systems and figured we could improve on them.

Trading is often looked at a means to an end. Players will engage in it as a way to make money even if they don’t enjoy it. The players that do enjoy it consider finding the good trade routes to be the fun part; it’s a bit of a discovery. Theoretically, the execution of the trade could be fun, evading pirates to get to the place to sell the goods, but I’ve never seen that work out. (I’d love some examples if anyone has some). Instead either the risks were way too high and the rewards were small, like in Eve Online, or most routes were basically riskless, like in Escape Velocity. I guess this is compounded by the fact that the ships with sufficient cargo space to trade profitably also were nearly weaponless and too slow to really evade any enemies in a fun way. Anyway, once you found the profitable path, you’d mindlessly repeat the route, not really generating any fun.

So our ideas centered around making trading into a mechanism that was fun by itself. How could we make something like trading an active action that feels like a minigame?

A few possibilities include:

Players killing pirates and other ships can occasionally collect special items that can be sold somewhere in particular for pretty good profit. So you can farm these faction ships and get a decent profit per hour. These might include killing pirates for the “Bavarian Flu Antidote”. If you mouseover this item (or something) it will direct you to the planet of Bavaria, where the antidote sells very nicely! In this case, you can probably figure it out planet it’s from given the name. You’re basically unprompted here, but there’s still a clear thing to do.

We can also do lightweight quests involving item exchanges. You might stop at a station where a man says he’s looking for some Belgian Crystals. You don’t have any, but the spot is marked on your map. Later when you find the Belgian crystals, you’ll know where to deliver them later. This is much more lightweight than traditional quests: “Start text at a location, specified action, return to location, quest completion paragraph.”

I am also still thinking about other mini-game like activities (although I think thats a poor way of explaining what I have in mind). I wouldn’t want to actually incorporate a separate puzzle game into the game, but something we can integrate with the game itself. I’d love to hear more ideas of tightly integrating trading and quests into the action of the game.

With the large and dynamic scale that we have planned for Solaro, the game is going to need to work with relatively high velocities. We’ll want to allow ships to travel fairly fast so that they can get around the world, and bullets will have to travel even faster so that you can hit things. This means that we will need to support swept collisions, the bane of collision detection.

The easy implementation of collision detection is to move all the objects in the system and then check to see if they are overlapping. This simple but effective algorithm has worked great for decades. As long as your objects are relatively big or slow, the player isn’t going to notice that Mario overlapped a goomba by 2 pixels when he dies right away anyway. The problem with this technique is that if you have very fast moving objects (like a railgun bullet fired from your ship) it could move a huge distance in between individual timesteps. So on one frame, the bullet might be 100 meters in front of a ship and the next frame 100 meters behind it. This won’t do for Solaro.
Read more…

A while ago we purchased a really nice set of turrets from 3dRT, and we’ve got them in game now as our weapons! They’ve all been fitted to work on our rotating turrets and fit nicely on our ships!

One other advantage of these models is that they all share the same single texture. This saves us texture memory and context switches within Unity. It also allows us to combine several meshes into a single mesh that uses the same material. This can significantly save on draw calls and allow us to draw an impressive number of highly detailed custom ships.

View them all in a Unity scene: http://kortham.net/temp/upshot_bcBqiEvY.png

Another nice feature is that we can swap out the texture to reskin ships by their faction. The above graphics show off the “red” look, and we can adjust this highlight color. For example, here’s the same weapon with a grunge look:

Announcing the sequel to the critically acclaimed game ScribBall:

ScribBall 2: Redrawn will feature the same addictive game play from ScribBall and much more. It has been completely rewritten and now includes:

• Three Unique Gameplay Modes
• Beautifully Hand Drawn, Painted, Crayoned, and Inked Graphics
• Unlockable themes
• Gameplay Statistics Tracking
• Improved Performance and graphics

Right now, ScribBall 2 is just a few weeks away from completion. After a short beta release, it’ll be available on a Mac near you! Stay tuned for more updates, including lots of sneak peeks as we finish up various features.

 

We are proud to announce the newest game that is currently under development at Howling Moon Software.  Pirate Golf promises to deliver a plundarin’ good time for you an yar’ mateys.  So grab yar’ grog bottle, hoist yar’ sails, and scally yar’ wags because Pirate Golf is coming to a port near you.

Please enjoy some free booty for yar’ desktop:

[1680×1050] [1600×900] [1280×800]

We stay in touch with a lot of different developers both around Minnesota and the world, and one of our buddies is BravoBug Software. BravoBug specializes in Mac software, especially handy little utilities. They have a lot of great freeware apps that are worth checking out.

But, we’re writing to point out a special sale at BravoBug: the Funbox bundle! It’s six piece apps for $29.99, so check it out!

We’ve spent well over a thousand hours over the last few years developing our open source Chipmunk Physics library into what it is today. We are now taking donations to help support further development. If Chipmunk has worked well for you and made your life easier, please consider donating. We’d be thrilled!

Donate using PayPal:

Get a free pre-release copy of Twilight Golf; we’re giving out promo codes for Twilight Golf- one day before the big release on October 21st!

We need your help to get the word out about our new iPhone game. So we’re asking you to Twitter about Twilight Golf or to join our Facebook group. In exchange, we’re going to give promo codes out a day before the game is released. You can use them immediately and get the game before it even appears in the App Store (yeah, we tested it).

On October 20th, we’ll go through the list of fans and choose 10 randomly and send them promo codes- easy!

Or, twitter about us and include the hashtag #twilightgolf. On October 20th, we’ll search for that hashtag, make a list of names, and give out another 10 promo codes randomly. Feel free to link to this thread, or whatever.

You can enter the drawing twice, but if the same person wins we’ll give the second prize to someone new.

You can find out more from our webpage:
http://howlingmoonsoftware.com/twilightGolf.php

Finally, we’re also looking for more reviews. We’ve got some press resources on our webpage at http://howlingmoonsoftware.com/twilightGolfPress.php and we’d be happy to give out promo codes to reviewers. Email us at admin at howlingmoonsoftware.com and be sure to include the name of the site you represent.

Finally, a huge thanks to everyone participating in this giveaway and helping get the word out. We can’t make it as indie game developers without your support, so it’s really appreciated!

Andy and Scott
Howling Moon Software

One issue we have been running into as part time developers is that we don’t always have the time to build the tools that we’d like in order to build our games. Level editors in particular can be tricky if your game needs a non-trivial one where you can’t just define levels in text files.

The solution we are going to try to allow us to easily generate intricate levels is an algorithm called marching squares. Funny name yes, but very useful. Basically it lets us turn a black and white image into a collection of lines that trace the edge. The image above was generated by tracing a 512×512 image to generate over 13,000 tiny line segments (shown in grey). As that is far too many to use in a game, I run a simplification algorithm to generate the red lines consisting of 1400 line segments.

While there are still a few bugs (half way down on the right side 🙁 ), I’m pretty happy with the results so far. Hopefully this will allow us to make far more interesting games given our limited resources!

A lot of developers have been publishing their sales information, and we’ve found it very helpful to get that information. We’re showing both the desktop version of ScribBall and the iPhone version. In blue, we’ve plotted the number of website hits as well, just for fun. We’ve definitely found that sales slump off pretty quickly if there are not regular updates. Most of the ScribBall spikes seemed to link themselves to specific events, but looking back on the dates and reviews I found, I can’t account for those two big spikes in desktop sales on 6/8 and 7/6, but the data is not that granular anyway. We will begin keeping track of daily information at some point here too, I think.

All numbers are weekly.

 

 

Click the image to enlarge it.

I know many have been waiting for this for a long time! As a developer with a full time day job, it can be hard to keep on top of many projects in your spare time. Fans of the game should be happy to hear that I’ve been working on an update for the past week or so.

So far most of the work has been going into rewriting the graphics code. Along the way, I’ve made it quite a bit faster. This allowed me to increase the physics quality and add a ton more particles! It also gives some more room to add new features and effects.

The desktop version of ScribBall had a number of different types of powerup balls that added some interest to the game. While there were a number of different reasons why the powerup balls didn’t make it into the iPhone version, the biggest was that I decided that I really liked the simplicity of the game without them. On the other hand, many people really seem to want powerup balls and an extra game mode or two can only increase the replayability. Thanks to the reworking of the graphics code, this should be relatively easy. We’ll have to get a bit creative with the small screen size, but that’s never a bad thing.

Lastly, iPhone users will appreciate that we are adding game saving. No more calls interrupting your game!

Stay tuned for more.

Verdant Skies is now at 1.4.0! This huge update has major new features for mod makers and mod enthusiasts. We’ve also reworked romance events for Sasha, Yuki, Rosie, Wyatt and Miles. You’ll now have new flirting options with these characters, and if you’re not hinting at a relationship, they won’t confess their love for you.

Styling your own hair at home can feel like a nightmare, but it doesn’t need to be. if you look for the help of professional, will have beautifully style your hair every time.

Verdant Skies is on sale 65% off on Steam! Now’s the perfect time to gift it to a friend! We’re also on sale on our itch.io store, where you can get a DRM-free version.

Have you played the new teenager update yet? Version 1.3 allows you to choose one of your children to grow up. Guide them through boarding school and interact with them once they return to the colony. A new set of Quantum Technology events tie into the growth of your child and provide high-priced end-game goodies! There’s even a new vocal music track in a special ending event!

Major New Features in 1.4.0:

• The Mod Uploader tool is now built into the game, making it easier than ever to share your mod.
• Create and view waypoints for custom dialog events, schedules, and more.
• A large amount of documentation for modding has been added to the wiki!
• Rework character events for Sasha, Yuki, Rosie, Wyatt, and Miles. These characters have a few flirting questions, and won’t confess their love to you unless you hint pretty strongly that you’re interested. If you don’t hint to them, you’ll have the option to confess to them.

New Changes:

• More changes to support stranger aspect ratios.
• Intro now has an animated starfield. This might help with a few people who got stuck on black screens on the intro.
• Redo the mod list to better show mod information.
• Modders can use the “talkTo” element when defining event triggers to specify which person’s friendship is checked with minFriendship.
• Better logging for potential audio engine issues.
• Minor typo fixes and text improvements, like telling you which inventory is full when you get seeds.
• Add a dropdown list to choose your resolution.
• Yuki fan art dialog added.
• Lots of new Yuki daily dialog if you’ve had a commitment ceremony with her.
• Clean up save file format- it’s now easier to browse and debug.
• Save files track which mods were used in their creation. It will warn you if you’ve loaded a save and might not have the correct mods.
• Ratchet up the compression quality on a few assets.

Fixes:

• Items mounted on bookcases, etc sometimes would end up on the floor until you re-entered your house. This is fixed.
• Fix Miles’ shipping quest value calculation being off by one.
• Fix typo in Rosie’s marsh boots dialog and Jade’s 4th heart event.
• Mouseover icon could sometimes be incorrect if you’re the keyboard and mouse at the same time.
• Wyatt now gets a big bed, just like everyone else.
• Sometimes greyed out buttons wouldn’t highlight. This is fixed now.
• Some waypoints were incorrect in Wyatt’s 8th heart event.
• Prevent a weird case where you could move items during the shipping animation and lose them.
• Fix the JumpIfOutdoors modding command.
• Fix an issue where baby rename events might happen even if you don’t have a baby with that person (save migration issue prior to 1.3.0).

We’ve been busy on a lot of projects lately, including updates to our Super Fast Soft Shadows system, but today I’d like to announce our newest game: Verdant Skies!

Check out our teaser trailer on the Verdant Skies Blog.

And follow us on Twitter or Facebook for regular updates.

Hi everyone- We’ve started a 2D soft shadow system and we wanted to share some screenshots and in-progress videos of how it’s going. The goals are:

* Speed on mobile platforms
* High number of colored lights and shadowed objects
* Flexibility in light size and softness of shadows

Super Fast Soft Shadows uses a unique shader based algorithm: Shadow projection occurs inside the vertex shader, not on the CPU.

Shadow mask generation occurs in a single pass – it doesn’t use expensive image filters or pixel shaders to soften the shadows. This means it runs great on mobile!

Physically realistic penumbra, umbra, and antumbra rendering is based on configurable light sizes. This produces accurate rendering when the light source is larger than the objects casting the shadows.

 

It can produce nice, accurate penumbras, and even antumbras when the light source is bigger than the object casting the shadow. This is because we are calculating the actual occlusion percentages when casting the shadows instead of applying some sort of blur or other image based effect. Blurs are incredibly bandwidth intensive, and this is especially a problem on mobile. Even though the occlusion we calculate is per pixel, it’s a pretty short fragment shader and most of the math is done in the vertex shader. You are really just paying for the fillrate to blend the visible parts of the shadow masks and lights.

 

The Chipmunk 7.0.0 release is complete!

Most notably, we’ve decided to integrate all of the Chipmunk2D Pro into the free and open source version of Chipmunk2D. We want the ARM NEON optimizations and autogeometry code to be in the hands of as many people as possible. This also allows these features to be integrated into popular engines like Cocos2D.

Have fun!

What’s new in 7.0.0:

• All features from Chipmunk Pro are now free and open source! (threaded and NEON solver, autogeometry)
• API: Lots of cleanup to the API naming for better consistency.
• API: Renamed nearest point queries to simply point queries.
• API: Removed many deprecated functions.
• API: Struct definitions have become fully opaque instead of mangling names with the CP_PRIVATE() macro.
• API: Replaced templated accessor functions with concrete ones. Should be simpler to deal with for FFIs.
• API: Optional automatic mass properties for shapes. Calculates the moment of inertia and center of gravity for you.
• API: Optional anchor point for bodies that is separate from the center of gravity.
• API: Added radius parameters to many functions dealing with shapes (moment calculation, initialization, etc).
• API: The convex hull and winding is automatically calculated when creating a poly shape.
• API: Added a cpShapesCollide() function to check overlap of arbitrary shapes.
• API: cpShape filter property to supersede layers and groups.
• API: Collision handlers now return a collision handler struct to make it simpler to set up callbacks.
• API: Wildcard collision types.
• API: The cpArbiterTotalImpulseWithFriction() function was renamed to cpArbiterTotalImpulse(). The old useless cpArbiterTotalImpulse() implementation was removed.
• API: Contacts now store the colliding point on the surface of both shapes.
• API: cpArbiterIsRemoval() to check if a separate callback is called due to a removal and not a true separating collision.
• API: Arbiters now only store one normal per pair of colliding shapes.
• API: cpBBNewForExtents().
• API: Added a concrete kinematic body type to replace the confusing “rogue” body concept.
• API: Added a 2×3 affine transform type, cpTransform.
• API: Added a new debug rendering API.
• MISC: Numerous improvements to the collision detection.
• MISC: cpPolyline structs are passed by reference instead of value. (I’ve regretted that decision for years!)

The last few weeks we’ve been working on Chipmunk bindings for Unity! If you’d like to stay up to date on our progress, follow us on Twitter:

http://twitter.com/kortham
http://twitter.com/slembcke

So far we’re finding a lot of challenges, but we’re really trying to go the extra mile to make it feel Unity-ish. And very early performance tests put it simulating over twice as many objects as PhysX, in spite of our need to cross the managed/native barrier each frame for each object!

I finally joined the 21st century after buying a smartphone, an iPhone 5. (Woo I guess?) Anyway. One of the only interesting things that changed with the iPhone 5 was the CPU. It’s supposed to be much faster and uses an new instruction set with extra registers for the NEON vector unit. I was curious to see how much faster it was compared to our iPad 2 at running Chipmunk so I ran the benchmark app and crunched the numbers. It’s certainly a nice leap in performance!

These aren’t conclusive results, but they do paint a nice picture. Normally I run each set a few times and pick the lowest time for each benchmark to remove outliers due to being scheduled on a multitasking OS.

Comparing the iPhone 5 to the iPad 2:

speedup: 2.72x (benchmark - SimpleTerrainCircles_1000)
speedup: 2.60x (benchmark - SimpleTerrainCircles_500)
speedup: 2.50x (benchmark - SimpleTerrainCircles_100)
speedup: 2.68x (benchmark - SimpleTerrainBoxes_1000)
speedup: 2.57x (benchmark - SimpleTerrainBoxes_500)
speedup: 2.55x (benchmark - SimpleTerrainBoxes_100)
speedup: 2.64x (benchmark - SimpleTerrainHexagons_1000)
speedup: 2.63x (benchmark - SimpleTerrainHexagons_500)
speedup: 2.53x (benchmark - SimpleTerrainHexagons_100)
speedup: 2.56x (benchmark - SimpleTerrainVCircles_200)
speedup: 2.62x (benchmark - SimpleTerrainVBoxes_200)
speedup: 2.62x (benchmark - SimpleTerrainVHexagons_200)
speedup: 2.60x (benchmark - ComplexTerrainCircles_1000)
speedup: 2.62x (benchmark - ComplexTerrainHexagons_1000)
speedup: 1.95x (benchmark - BouncyTerrainCircles_500)
speedup: 2.10x (benchmark - BouncyTerrainHexagons_500)
speedup: 1.77x (benchmark - NoCollide)


If you want an idea of what these benchmarks do, the Chipmunk Pro page has little animations of them.

I was also curious how much the extended NEON register set improved performance. It’s been a while, but from what I remember of looking at the disassembled output, the NEON solver in Chipmunk Pro did run out of registers and push values to the stack. So it was possible that the extra registers would be able to speed it up more. It was initially a pain to support armv7s as it was sprung on everybody unexpectedly. All projects were automagically upgraded to build for armv7s when Apple released the new SDK which was annoying for library developers. Having had bad experiences with compiler bugs in Apple’s Clang, I wasn’t willing to release an armv7s build without being able to test it. Anyway, it turns out it was worth the hassle with a decent little performance boost.

The speedups for armv7s vs. armv7 are as follows:

armv7 -> armv7s Speedup:

speedup: 1.23x (benchmark - SimpleTerrainCircles_1000)
speedup: 1.32x (benchmark - SimpleTerrainCircles_500)
speedup: 1.24x (benchmark - SimpleTerrainCircles_100)
speedup: 1.17x (benchmark - SimpleTerrainBoxes_1000)
speedup: 1.17x (benchmark - SimpleTerrainBoxes_500)
speedup: 1.18x (benchmark - SimpleTerrainBoxes_100)
speedup: 1.13x (benchmark - SimpleTerrainHexagons_1000)
speedup: 1.14x (benchmark - SimpleTerrainHexagons_500)
speedup: 1.15x (benchmark - SimpleTerrainHexagons_100)
speedup: 1.23x (benchmark - SimpleTerrainVCircles_200)
speedup: 1.18x (benchmark - SimpleTerrainVBoxes_200)
speedup: 1.15x (benchmark - SimpleTerrainVHexagons_200)
speedup: 1.18x (benchmark - ComplexTerrainCircles_1000)
speedup: 1.13x (benchmark - ComplexTerrainHexagons_1000)
speedup: 1.03x (benchmark - BouncyTerrainCircles_500)
speedup: 1.03x (benchmark - BouncyTerrainHexagons_500)
speedup: 1.00x (benchmark - NoCollide)


That’s about what I expected to see. It was able to speed up a lot of the benchmarks that were using the solver heavily while the last 3 benchmarks that attempted to stress the collision detection performance instead were mostly unaffected. A 10-30% speedup is pretty nice for something as simple as a recompile.

I wonder how this would compare to performance on similar Android devices like the Galaxy S III or Nexus 7. I’ll have to get my hands on one of them and try it.