Fresh.

Can you name the members of the largest world economies?  Introducing a Silverlight app that tests your knowledge of the "G-20" members.

Take the quiz: http://www.kindohm.com/g20

The quiz features a world map (developed by Imran Shaik) that highlights your choices and provides feedback on your results.  It also has a statistics view that displays a real-time summary of quiz responses from all people who have taken the quiz. 

What better time than now to take this quiz with the upcoming G-20 summit in London in April 2009!

Thanks to Nikki, Lori, Kris, and Kristen for providing input for the app!

Download source code for this post: PhysicsChunks.zip (190k)

Try out the example app: http://www.kindohm.com/sl/physicschunks/testpage.html

During development of the Turrets game, I've spent time optimizing the time it takes to load a "map".  A map is simply the terrain that defines the playing boundaries for turrets, projectiles, or any other physical object in the game.  I've found that large geometries, particularly ones that are concave shaped, take a lot of time to load.

My terrain geometry is relatively large and is built to fit a base screen size of 3000 x 2000 pixels.  All of this is scaled down depending on the user's screen size, but the large base size is nice because it prevents me from having to use decimal values to get the granular geometry that I want.  However, the large base size does increase the complexity of the physics geometries and the computation required for collisions.

In addition, my terrain has cliffs, walls, and other shapes that create concave shapes.  An easy way to imagine this is a slab of ground with a bounding wall on the left and a bounding wall on the right.  You now have a big, U-shaped, concave bowl. 

Here's an example of one map that has a cliff overhang and wall that create a concave, sideways "U" with the ground:

A simple U-Shaped bowl that fits in a 3000x2000 screen takes forever to load by the Farseer engine (using the default collision grid size).  This has to do with collision detection computations that happen when geometries are created.  In my estimation, the large concave shapes take longer to compute because the center of gravity lies outside of the physical geometry, but that's just a guess.  The collision grid for an object has to be small enough to be realistic.  You can increase the collision grid size in Farseer to make your objects get built faster, but then you run the risk of collisions being less realistic.  In order for my collisions to be realistic enough to satisfy my needs, I needed a small enough collision grid that was causing my terrains to take a terribly long time to load.  You can read all of the details of collision grids in the Farseer documentation.

One way to address this long load time is to break down a large geometry into multiple smaller geometries.  In the above screen shot, you could potentially break down the terrain into 1) the ground, 2) the right wall and 3) the cliff overhang. 

I decided to test this out (unscientifically) in a simple example.  I created a Silverlight app to host a Farseer Physics environment and created two "maps" that both defined the exact same shape: a large, U-shaped bowl.  The first map used a single Farseer geometry to define all points of the container, and the second map broke it down into three chunks:

For those of you who have used Farseer and are paying attention, I used a collision grid size of .5 in my app for both maps.

In the app, you can choose to load either the single path map or the multi-chunk map.  With one test run, here were my results:

• Single Path, Large Geometry: 59.791 seconds to load
• Multiple Chunk Geometry: 7.307 seconds to load

You can try out the app here: http://www.kindohm.com/sl/physicschunks/testpage.html

It's remarkable how much faster multiple, smaller chunks load than the single large geometry. 

Again, I'm only speculating that the concave shape also has something to do with the slowness.  I haven't come up with a good test that could determine if it doesn't have an effect on the load time. 

In summary, try using multiple geometries to break down a larger one if your Farseer geometries are taking a long time to load.

About a month ago, I released TANKS into the wild.  While it was a fun experience, the focus of TANKS was more about exploring the Farseer Physics engine and doing some complex development with Silverlight.  The focus was not on creating a great game.  Today, it drives me insane that the game doesn't have that game "polish" that it deserved. 

Now that I've explored Silverlight and Farseer far enough to my liking, it is time to move on...

Enter Turrets - the sequel to TANKS. 

Turrets is under development and is being created with a game focus.  It is a game and is being treated like a game. 

So what are some of the characteristics of Turrets that make it a little different than TANKS?  Well, there are a lot of actual game features that are different, but there are also some more subtle UI changes as well:

1. New terrain design.  TANKS ended up looking very cartoony.  Nothing wrong with that, but for the next game I wanted something that looked sharp.  With inspiration and blessing from Jeff Weber at Farseer Games, I went with some new game terrain that is crisper and also introduces the perception of a much larger game environment.
2. Multi-threading.  Perhaps the most annoying thing about TANKS was how the game locked up when loading more complex maps.  The new game utilizes background threads to improve the user experience while time-consuming operations occur in the background. 
3. Particle effects.  The explosions rock.  Debris flying everywhere.  See above screen shot.  Thanks to Robby Ingebretsen's Silverlight Particle Generator.
4. Different weaponry and items.  There is less emphasis on different weapon types and more emphasis on one-time power items in the new game.  Cluster bombs and shields are complete.  An "EMP" item and a repair kit are in the works. 
5. Upgrade purchases. Instead of shooting powerups falling from the sky, the new game introduces an Upgrade Store that you can buy upgrades from at the end of each round.  You gain cash for each point you score in the game.  Upgrades are given in levels (e.g. Damage Level 1, Damage Level 2, etc) and increase in cost as you go.
6. Competitive computer opponents.  The same computer AI's follow you through the game levels and compete against you.  You can play against one to four opponents.  In the old game, computer opponents were defined per level.  Now they are defined at the beginning of the game. 
7. Turret types.  Standard, heavy, and light.  Heavy is more resistant to damage and doles out more damage, but reloads much more slowly and has fewer hit points.  Light tanks shoot and reload faster, but are less resistant to damage.
8. AI plugin architecture. From the start, Turrets was designed to be able to plug in any AI code.  Obviously, this makes it easier to maintain AI code without mixing it with other game code, but it also introduces the ability for other developers to implement their own AI.
9. New base AI. The base AI in the game is smarter than in the old game.  It picks on weak opponents.  It tries to buy upgrades that will help it succeed, rather than shooting down powerups by chance like in the old game.
10. "Assassin" opponents.  There are computer opponents who are just there to be annoying and pick on both the computer and user players.  They attach themselves to walls and overhangs and pepper you with ammo.

I can't list these features without thanking Neil for suggestions and other inspiration.

I don't have any plans for a specific release date or completion date for Turrets as this is being done all in my spare time.  There are a lot of loose ends to tie up to complete the game experience, and then there will be a lot of play testing.

Overall, developing Turrets has been a lot of fun so far (especially the particle effects).  I hope to produce something really cool in the near future.