It’s been busy, busy, busy as of late. We’re in full swing trying to get Tilt to Live HD ready for the iPad. It’s looking amazing thus far and plays a lot better than just the 2x mode for the original Tilt to Live. Frostbite mode just went out the door a few days ago, and the response has been positive so far. We’ve been getting some responses from users saying the game has become too easy in the other modes. I haven’t tweaked anything in the other modes for ages so my hunches to why users are believing this are:

  • It’s been a while since they’ve played and when they came back it was like riding a bicycle and they instantly got into the flow of the game.
  • Performance has degraded on the lower end devices (particularly when running iOS4), which slows the game down and as a result makes it ‘easier’.

I’ve tested the game on a 2nd gen ipod touch with iOS4 and it seems to run fine performance-wise. So it’s something I guess I’ll just keep on my mind when doing further updates to the game. Maybe revisiting Code Red mode and making it even harder could be a possibility to appease the hardcore users.

Some Reading Links

Whenever I have time to kill I go browsing through my RSS feed to catch up on things. I decided to share a few of my usual reading links. Maybe you’ll find something of interest in this pile as I tried to focus on reading links that are outside the iphone development community. A lot I’m sure are common go-to places for a lot of indie devs regardless of platform.

Cliffski’s Blog

I feel like just about anyone that has any semblance of what goes on in the indie world is at least aware of Cliff Harris and his musings on his blog on both his own games and the industry as a whole.


Steve Gaynor’s [Bioshock 2] video game design blog. Always a good read and has valuable insights into not only the design of mechanics in games but about the medium of games overall.

Shawn Hargreaves

For a time I worked mostly in XNA and C#. While most of his recent posts are about gearing up for windows phone 7 and other XNA tech, his technical but easily readable posts were extremely helpful not just in XNA, but any platform you may be starting out on. Great learning for those that don’t have true game industry experience (like me). His credits include Extreme-G (N64), Moto GP (Xbox/PC), and several other racing games.

Mark Sibly

Ok, not many updates for this blog but that’s not the point. Creator of Blitz Basic and Blitzmax. For those that don’t know anything about it, Blitzmax is a very nice cross platform language (PC/Mac/Linux) for developing 2D (and 3D) games. It’s a very small and friendly community, but one I spent a lot of time in when I first started getting serious about making independent games. The tech he currently is working on seems like really exciting stuff: A language that allows you to target HTML5, flash, XNA, Android, iPhone, native GL for game development. Very ambitious, but very exciting to keep tabs on!

Beautiful Pixels

Great graphics and game development blog. I believe he recently went to work for Google on Chrome OS. Great posts to browser through, and I’m sure some very useful ones in the coming future. Despite having a lot of ‘game oriented’ blogs on my feed, I tend to follow developers outside the game industry as well. And now that he’s at Google, I’m sure lots of good will come of it :).

Game Architect

A great blog on finding the ‘hard to find in a book’ answers to questions that come up during development. Like what’s a good way to keep you from creating a crazy object hierarchy but still have flexibility. Great thoughts on middleware as well.

Grey Alien Games

I’ve been following Jake Birkett for several years now as I was going through high school and college. His success as an indie was very inspiring. Great place to read for motivational and lifestyle posts as well as general independent game development. He was also a very involved community member in the Blitzmax community, writing a pretty successful game framework to allow developers to more quickly make indie casual games on the PC.

Lost Garden

If you haven’t heard of this site and Danc by now, then…I don’t know what more to say.


Andy Patrick’s blog. Great info from an experienced developer. He previously worked at Rare on Kameo and Viva Pinata. Hasn’t had an update in over a year but some good content on programming things like cameras, game programming in a garbage collected environment, and tool recommendations. One article I really liked was going over how to implement infinite undo/redo in an game editor.

Sell More Games

Great site has articles focusing more on the marketing and business side of indie game development. Mostly geared towards the PC market, but I feel all of it is still applicable to the iPhone market.

Make it BIG in games

I believe I’ve referenced Jeff Tunnell’s blog entries before, but it’s worth listing again.

Gausswerks Design Reboot

Another great game design blog. Less on the technical and more on the design and art of games. I’m ashamed to admit I don’t read enough of these articles.

I had seen a few things written about “Everyday the same dream“, a game created by but never took the time to try it out myself until recently. It’s a compelling art game where you try to subvert you’re daily routine. It took me a few minutes to figure out what to do after a few days of the mundane routine, but  that added to the whole experience of the game itself. It’s a very subtle, but clever design that speaks to a wider audience.

Be sure to give it a try. It only takes 5-10 minutes to play through.

I finally got rid of the stupid…

"ld: warning in <foo>.so, file is not of required architecture."

…warning when using iSimulate. If you’re not using iSimulate or a similar technology you’re losing valuable time even if you don’t use the accelerometer or GPS functions. Then again, I might not be the best spokesperson on time since I spent the weekend re-inventing the wheel.


I have this need to make sure my projects compile w/o warnings. I let it sit for a while because I’m not an XCode expert so I knew I wanted to conditionally link it in but I couldn’t find the UI for it. The process in which they suggest you integrate iSimulate into your XCode project truly is easy, but I felt icky when it came up with warnings when you compile against the actual device.  There are better ways of doing that. Namely, conditional build settings. Of course, it requires a few more steps and a bit more knowledge of the XCode environment so I suspect that wouldn’t help their marketing. Regardless, having the iSimulate linker flags and library search paths only be added when you’re compiling for a simulator is relatively easy to setup.


Every now and then I come across a game that is rather inspiring. Strangely, a lot of them come from the flash community. I really like it when someone can take a game mechanic that is so utterly constrained and create something so enjoyable out of it. The epitome of these design challenges might be the ‘One-Button’ games. I just recently came across Canabalt, and it had me playing for a while despite the need for sleep.

The sense of urgency and the whole atmosphere implies a bigger and more ominous ‘universe’ than what the gameplay focuses on, and is a treat. I’ve died several times trying to figure out the fleeting images in the background only to slam into a wall, haha!  I’ll be checking it out on my iPhone later this week. Hats off to them for getting it onto the App Store and good luck!

I’ve been working on a few projects that require blitzmax and a web-server (php/mysql) to communicate. Along came the need to hash files. This code archive entry was very useful :). I decided to wrap it into  an object and add a new method to it. Even though it’s a series of functions I still tend to make types with functions in them to help me organize them (it’s like a cheap way of  namespacing). I needed the ability to hash a file using Sha-1 hashing. Seeing that php has a function called sha1_file($pathToFile) I figured I’d implement the equivalent on blitzmax. With this THasher type, I’ve added a SHA1_File(path) function also.

Why hash files?

There are many reasons to use hashes, but recently I used it to check for file changes. If you’ve ever wanted to find out if some arbitrary file has ‘changed’ since the last time you’ve opened it this can prove to be useful. If you save the hash beforehand then recompute the hash now and if they are different, then something’s changed! Some applications of this are:

  • Write a file-updater to quickly find out which new files need to be downloaded. Just comparing hashes would be sufficient in most cases, instead of having to go individually byte-by-byte or traversing the file structure to find a difference.
  • help stop cheating. If you don’t want users changing texture files to gain an advantage or don’t want them ‘mucking’ with any other data file. If you check the current hash against a previously approved one and it doesn’t check out then the file has more than likely been tampered with.

How Do I Use THasher?

If you want to hash a string using SHA-1 then:

Local hashedFoo:String = THasher.sha1(“Foo”)

Want to hash a whole file? Then:

Local filehash:String = THasher.SHA1_File(“someFile.txt”)
Keep in mind you can hash any file, not just text files like in the above example.

Anyway, read on for the whole file. With the exception of SHA1_File() I did not write these hashing functions for Blitzmax. They were simply taken from Yan’s very helpful code archives post :).
Continue reading

Yes, yes I know the documentation is lacking at the moment for Farseer.BMX. I’m still working on it on a few fronts. First, I’m trying to do api documentation (bbdoc mostly). Secondly, I’m trying to write tutorials/guides that help show how to use some of farseer’s features. I had hoped that releasing the demo application source code would’ve covered this aspect as the demos cover pretty much each feature, but I guess since the demo source is a bit more complex in design (handling a lot of graphics related mumbo jumbo), the actual ‘needed content’ wasn’t particularly easy to find. So I’m going to try to write up very simplified versions of some of farseer’s basic features (minimal graphics, minimal code).

I’ve uploaded the first of these tutorials to the articles section. It covers creating concave polygons in farseer :). More to come soon…

So far feedback has been great on Farseer.BMX working in Blitzmax. Some users have tested Farseer.BMX on Linux and Mac and it works without a hitch. Farseer.BMX is officially cross-platform between Windows, Linux, and Mac! That’s great news seeing how widely available the Farseer engine is becoming. It’s now available on:

  • Windows
    • C# – XNA
    • C# – Silverlight
    • Blitzmax
  • XBox 360
    • C# – XNA
  • Linux
    • Blitzmax
  • Mac
    • Blitzmax
  • Your Toaster
    • ???

I’m curious if Jeff has any plans on bringing it to Zune…hehe.

The main reason I’m posting an update is to let everyone know that the download for Farseer.BMX has been updated to include a ‘module’ version of Farseer for those that like to have all their code in ‘module’ format for easy use across projects. So if you were wishing for a module version of Farseer.BMX, you’re wish is granted and you can go ahead and re-download the package. The package contains the original source layout for those, like me, who like to have all their library source code next to their game code, and additionally a that you can extract to your “Blitzmax/mod/” folder.

So with the module installed you can now just do this in your code…

Import aco.farseerphysics
‘Weeeee physics….!

… and off you go!

Please let me know if you run into any issues with the module.

*…wonders how he’s going to get up tomorrow morning for class….*

And there was much rejoicing! It does feel great to finally ‘finish’ something. I started out this project as something to give me a foundation to code my own game project on, and now after 110+ hours of coding there is a 2D physics library for Blitzmax :)! I hope it proves useful to those that end up using it. While the engine hasn’t been tested for ‘real-world’ use it I think the demos do a good job of putting it through its paces. It’ll very soon have a good test through a ‘real world’ application once I get it integrated with my own game project. Anyway, Farseer Physics for Blitzmax is ready for download. The zip file contains:

  • A compiled version of the physics demo application with 4 new demos!
  • Ready-to-compile source code for both the core physics engine and the demo application
  • A ‘quickstart’ application that shows someone how to setup a basic physics scene with minimal code.
  • a ‘quick start guide’ that pretty much is a walk through of the quick start application. Which can also be found online.

For those eager to get their hands on it:

Download: Farseer.BMX

Since the last update, things came together rather quickly. I finished up the last of the classes that needed to be ported earlier in the week, which I then spent the rest of the week adding in demos to the demo application. This port is a very close implementation of the original Farseer in C#. The only times the source would deviate in any major fashion were in time-critical algorithms where optimization needed to be done differently considering how different C# and Blitzmax handle things (particularly garbage collection). With that said, you may find it helpful to visit the codeplex site of the C# version of the engine if you find yourself wondering how to do something in Farseer. While the answer you get may be in C#, keep in mind the methods, functions, and variable names are similar, if not identical, in Blitzmax. I’ve also implemented additional demos on top of the standard ones that came with Farseer to show the use of most of the available types in the engine. So if you wish to know how to implement a certain feature, try looking at the source code of one of the demos that does the said feature.

Here’s just a quick run down of what was added/updated since last post:

  • Added Demo 11 – Slider and Pin Joints
  • Fixed a minor bug in the main menu causing the about screen to stick
  • Sweep and Prune Collider implemented (not completely optimized)
  • Bilinear Interpolator
  • Added the Convert Units class for easy transformation between screen and world coordinates
  • Added IFluidContainer
  • Added onEntry and onExit event handling for fluid containers
  • Added Collision event handling
  • Added Demo 12 – Fluid Drag Controller
  • Added Demo 13 – Collision Event Handling

The fluid container objects turned out to be a bit cooler than I expected it to be. Not only did it simulate buoyancy but there was a controller that simulated wave formations on the surface of a container. Cool stuff indeed…

Pictures don’t do it justice so here’s a video…

By default Farseer doesn’t come with any code that allows geometry to create disturbances in a fluid container, but it comes with a nice, easy to use Disturb() function along with handy callback events for when a object enters and exits the container. With this I threw together a basic water container class that does some very ‘rough’ interaction between geometry and the waves. It’s far from realistic, but still yields an interesting effect I think. Someone could easily take this code and improve upon it. I’ve kept it outside of the ‘core’ physics engine and put it in the demo source since it was something that was kind of thrown together last minute (you can tell that by the rather rushed rendering code).

So that’s about it for now. I hope this engine finds some use in the Blitzmax community. Thanks to those on the blitz forums that provided feedback and data to help me optimize the engine. An especially big thanks to Jeff Weber for writing such a robust 2D physics engine to begin with!

*Crosses fingers and hopes the code will compile without issue on OSX and Linux*… 😉

I was hoping to have an update a little earlier than this, but decided to hold off and throw together at least a bit of content with the update. I’ve added a slew of joints and controllers into the Farseer engine for Blitzmax (which I think I’ll just start referring to as just Farseer.BMX to save my poor little fingers). Below is a list of stuff I’ve added since the initial post:

  • Angle Limit Joints (featured in the youtube video below) – this allows you to do some interesting joint behaviors that could potentially allow you to create a 2D ragdoll of sorts with limb constraints.
  • Fixed Angle Limit Joints – Same as above except instead of linking two objects together, only one is used and it’s angle is limited.
  • Fixed Angle Joints – Allows you to make an object always point in a certain direction. You can think of it as a way to disable ‘rotation’ for a particular object, and it will always be set at some angle from some anchor regardless of where it is in the world.
  • Angle Springs – You can link two bodies and they will attempt to align themselves to a certain angle using spring physics to give a bouncy effect.
  • Interactive Angle Joints (untested)
  • Circular Interpolator (untested)
  • Pin Joint – This one allows you to choose an anchor on two bodies and a distance, and the two physics bodies will always stay that distance apart, but still tumble and interact with other bodies realistically.
  • Slider Joint – Same concept as a ‘Pin Joint’ except now instead of a concrete distance apart there is a minimum distance and a maximum distance these two objects will stay within.
  • Brute Force Collider – Just another broad phase collider you can use instead of the default one. I may dig up a forum post by Jeff and others that describes the advantages/disadvantages among the different colliders you can choose from in Farseer.
  • Some getters/setters for the physics debug viewer class – Makes the debugger class a little easier to use.
  • Fixed a few minor bugs

Anyway, the video I posted isn’t that impressive but shows you that Farseer makes it pretty easy to setup different types of constraints and scenarios with just a few classes. There’s no new demo application to download for this update as I’m pretty close to finishing up the rest of the port, and would rather just wrap up a few more demos and get the code out there for others to use. Hopefully I’ll have more in a week or so!

Hurray! Finially got to a stable stopping point in porting over Farseer Physics from C# on XNA to Blitzmax! Farseer Physics Engine is a 2D physics engine originally written by Jeff Weber who develops XNA/Silverlight games over at Farseer Games. Much thanks to him for creating a great physics engine and for allowing me to move it to another language, which once done, I hope will help others create fun physics games in Blitzmax.

I’ve ported the ‘core’ features of the engine which now would allow you to use the basic features of the engine. If you head over to the Codeplex Farseer Physics Page you’ll see a list of the features in the C# version of the engine. Right now the things that aren’t implemented in the Blitzmax version:

  1. Fluid Drag and Buoyancy Controller.
  2. Slider (Prismatic) Joint
  3. Pin (Distance) Joint
  4. Broadphase Colliders: SweepAndPrune, BruteForce
  5. Collision Callback Mechanism

Currently, the Blitzmax version is using the ‘SelectiveSweep’ Broadphase collider that is the default collider in Farseer, and is supposed to have the best performance in a wider range of scenarios. The others have their advantages and disadvantages based on specific situations in the physics environment. I’ll be implementing those as well along with the rest of the list, but they weren’t used in the current build of the C# Farseer demo application so I chose to focus on the needed classes first to get an identical demo app running in Blitzmax.

Just some metrics you may find interesting (as I’ve noticed typical Blitzmax users have a very different way of developing their games):

84 .bmx files used for the physics engine and the demo application
7957 lines of code (blank lines not included)

Sounds like it may be a lot, but in reality it really isn’t much compared to a full relatively complex commercial Casual, Indie, or AAA game. But the reason I put that up there is to illustrate a point. I feel like if I was using the default Blitzmax IDE I would’ve have one hell of a nightmare just handling these little files. Having a project of a much bigger scale in BlitzPlus in the past, I know from experience the headaches of a large monolithic code base. You spend a lot of time scrolling and searching through files because the IDE promotes that type of behavior from the get go. Using BLIde, a very flexible editor created by Manel Ibáñez, productivity went way up and I was able to get more done on the physics engine. Not to mention built in Intellisense support is a god-send, which lets you spend more time coding instead of reading API docs. Just that feature alone I think is enough to abandon the default IDE and stick to BLIde. Anyway, if you’re a Blitzmax user I highly recommend that you take the time to learn to use BLIde and support Manel’s efforts for an outstanding product!

I’ve uploaded a demo video showcasing the same demos available in C# running in Blitzmax. I also added a new and original demo by me showing the use of concave polygons, which is one feature many 2D physics libraries lack. With other physics engines you can emulate concave shapes by putting together a bunch of convex ones, but it’s still a cumbersome and tedious task. The ability to create concave shapes with minimal hassle is a great productivity boost for content creation in your game. Below is a video of the physics demo app, along with a download link to the demo app itself so you can run it on your own PC. Hope to have more info posted with updates in the coming weeks!

To download the demo application shown in the above video click below:

Download Farseer Physics Demo


– Windows XP/Vista
– Direct X 7 or higher capable video card
– Minimum supported screen resolution: 1024 X 768

Known Issues:

– In Vista the fps are lower (and in some demos locked to 60 instead of 100 fps).