After reading Noel’s post on prototyping I realized I was drifting away from that mind set and getting into dangerous territory of just “thinking up a game and running with it.” Tilt to Live itself spawned into a full game from being discovered in a rough prototype. Since then we’ve just had rough documents and ideas that we wished to pursue after TTL. The past few weeks we’ve been gearing up more heavily for our next game and I’ve been getting back into the habit of whipping out fast prototypes.  I finished one prototype for an arcade/action shooter and another one over the past weekend for  a turn-based strategy game. My methods for prototyping each were very different. Ultimately, as I experiment with different tech and methods I’m trying to optimize the time from “concept” to “on the screen and working” so that we can fail quickly or move forward with the idea.

Action Shooter

With this one I had a series of prototypes I wanted to explore before we would deem it ‘good enough’. The first one was trying to see if our tilt mechanic would work. We had an idea that was a slight evolution of Tilt to Live’s controls but allowed for shooting while still avoiding annoying ‘floating D-Pads’ issue. It took about 15 minutes to do the mechanic prototype. After getting it implemented and in the hands of some friends, they actually liked the feel of the controls, which made us pretty excited about it. My next question was whether a scrolling view worked with a tilt mechanic. It made perfect sense to me in my head, but for some reason I felt that not being able to view the whole field while tilting to move (somewhat losing that 1-to-1 feel) would ruin the experience. 40 minutes later I had a camera system and some basic map trinkets scrolling by and it still felt good.

The next several hours became more of an educational exercise by implementing bluetooth multiplayer in it, and admittedly it was wasted hours in the prototype sense but very useful in a general sense. So I did go off track here a bit, but corrected myself soon after indulging in that little fun :). The tech used was the iPhone itself and objective-c as it’s hard to test very device-specific controls on anything other than the device. The next prototype in this series would be player/enemy interactions and seeing if simple enemies would suffice or would we need varied, sophisticated enemy behaviors to make it compelling (a difficult road to go down, as disposable content is not something I’m a fan of), so this’ll be a rather telling iteration.

Turn-Based Game

This was an interesting prototype to make. The game consists of a hexagonal grid where two players have bases, spawn points, and a set of different character classes. The game’s core idea was to make a very simple-to-play turn-based game but introduce interesting twists to the character classes that didn’t require some extra knowledge or rigorous ‘book keeping’ of different types of stats for each pawn to use effectively. So while the action of ‘moving’ a pawn was simple, the outcome would be varied and hopefully pose interesting choices to the players that are playing.

About Friday mid-afternoon I decided I wanted to see this turn-based game idea Adam had in an more automated form so we could give it more play time and start getting feedback from more people. The first prototype of this game was done by Adam in Adobe Illustrator. He did it in Illustrator because he was most comfortable with manipulating graphics in that program, and also (being the artist he is) had some pretty mock ups to play on top of. It was a series of duplicating object-groups to move objects, editing text boxes to adjust hit point values, deleting and adding layers and all sorts of madness. It was slow, tedious, but the game was still pretty compelling. It also goes to show that you can prototype a game with just about anything.

Having only about 3-4 hours before leaving to the beach for the weekend I had to decide what was the quickest way for me to get a more complete version of this game’s rules running on a screen. Ideally I wanted an iPad prototype, but I had almost zero framework to work with (barring using something like cocos2D) and the tediousness of C++/Objective-C slows things down. I opted for writing a prototype in Blitzmax. I ran the simple Blitzmax IDE on my mac (Blitzmax works on mac/pc/linux) and started coding away. No header files, no include dependencies, lots of high level modules to load graphics, draw graphics, draw text, load text, load data, handle mouse/key events. I feel I eliminated like about an hour of working on ‘boilerplate’ code to get a prototype up and running on a laptop.

Not having done a hexagonal-grid based game before, it was time to hit the books and just quickly skim over the basics of how to manipulate objects in that space. This was more of the ‘technical education’ part of the prototype. And this is usually the part that takes the most time in any of my prototypes. Transforming between hex and mouse coordinates, moving and calculating distances took up the rest of the time to develop.

Oh no, so I had no prototype before the weekend! Luckily, trusty Adam was driving so I spent about 1.5 hours just putting together a state-machine type framework trying to get the ruleset and player interaction working. This is one of those dangerous situations as well, as Noel and others mention, that many can get caught up in the “technical beauty” and try to create an all encompassing FSM framework of some sort. Putting a 3 hour constraint on this really helped mitigate that urge.

Then the battery died. Oh well, instead of spending some untold number of hours cooped up in a condo instead of enjoying the weekend with friends at the beach I limited myself to 30 minutes a night right before going to bed to work on it. The awesome part was knowing how little time I had to work on it allowed me to make coding decisions much more quickly. Of course the downside is the amount of ‘shortcuts’ I took code-wise to get the prototype up and running. But the thing for me to remember is it’s a prototype, not  final code. Further practice and experience will yield better code and solutions for quicker turn-arounds in prototypes. I finished that prototype after 2 30-minute sessions, and 2 players can play it on a laptop on mac or windows.

Not having it on an ipad kind of sucked as it does have a certain novel feel to it, but that “feeling” is probably more like sugar on top than having a solid design that works on any screen.

Faster, Faster, Faster!

Indeed, getting something up and running and being able to play with it holds more answers than any time spent thinking about it in your head. Things like the Experimental Gameplay project really shows what volume of ideas can be realized with very focused, short efforts. I had been doing these prototypes all the while working on finishing up TTL HD. With this newly rediscovered “do it as quickly as possible” mentality I may be able to incorporate a weekly prototype into my schedule to break up the week of working (happily, mind you) on whatever our current long term project is. Strangely, both prototypes show promise, but it may come down to how “well” we can make whatever fun prototype we choose in a short development period since we are aiming to release at least 1 more title in 2010.

colestanceI’m currently working on an editor for the next iteration of Gunstyle on the weekends. I find it’s a nice break from iPhone development and lets me start the week with renewed energy to work on Tilt To Live again. I’m using wxMax to develop the UI for the actual editor. It’s not much at the moment but it’s coming together slowly. The editor code architecture is taking a page from the Unreal engine mentality of having your engine and editor be pretty much one in the same. After a little re-jiggering the internals of my framework I can now run a blitzmax game using my framework in a normal graphics window or inside an editor. The code running the actual game logic doesn’t have to know which mode it is in unless it really wants to, so it’s pretty transparent from the viewpoint of game code.

As for the editor code, that’s another beast entirely and it really adds complexity to the code base. I haven’t decided yet how “integrated” I want the editor in the game framework I have. Currently, 99% of the editor code lies on the game code layer, above the framework, and the framework just has some functionality for handling the switching between OpenGL window and a wx Application. The reason it makes this difficult is there are a set of opposing goals I’m dealing with here:

  • If I want to be able to re-use this framework for future projects, I don’t want to pigeon hole myself into a position where the editor is only good at making 2D side-scrolling physics-based maps. This mentality leads to where I am right now with the editor living largely outside the framework and just hooking into it.
  • If I want my framework to have a fully functioning editor, this will undoubtedly turn into a “Gunstyle Engine”. As I will want to make tools to specifically aid in creating Gunstyle maps and objects. Is that a bad thing? From a time and goal perspective, no. From an idealistic point of view, I want the framework to be ‘general’.
  • A potential compromise between the two opposing points above is to create a ‘generic’ editor that exposes a lot of hooks and ability to code in new tools. While a good way to approach this, I’m only doing this for fun and the end goal is to have a fun game to play. As someone with a limited time and constrained resources I cannot take on this approach as it’s a whole project unto itself.

So as a result, I’m left with either:

  1. A one-off editor for Gunstyle. The code from this editor could potentially be re-used for future games but will be specifically designed to work with the Gunstyle game.
  2. An integrated editor in the framework. In my mind, this would graduate the code from “framework” to “engine” code-base as it would introduce not only a set of API’s but a basic content-pipeline for creating content for this code base.

cole2stance
The main reason the one-off editor approach caused me to pause is there have been situations where I want to include functionality in the core of the editor (in the framework layer) but it would require me to pull in a lot of game specific functionality into the core as well. So I’m sure this is leading to several less than optimal code design decisions because I’m trying to tackle a game specific editor while simultaneously trying to develop a bare-bones editor.

An example of this is I’ve added a line tool to the editor this weekend. The line tool creates a physics based line object into the map for Gunstyle. Now, I feel a basic line and box editing tool is something that could be added to the core of the framework. The problem? The framework has no physics functionality. Physics is all on the game-layer. Currently, the 2D rigid body physics engine is home-grown, but physics is one of those things where I would like to switch out from project to project (using Box2D, Chipmunk, or Farseer). As a result, I’ve yet to roll any physics engine into the core of the framework.

After getting all of that written out in front of me, I think I’ll be sticking to the one-off editor route for this project. If anything comes of Gunstyle and it’s editor I’ll probably be more willing to roll more of the game editor into the core and just go the ‘engine’ route in the future. But for now, I’m trying to focus on Getting This Thing Done. And coding a generic solution to a specific problem is not the best way to Get It Done.

I’ve had this issue in past 2D games all the time. The ability to interpolate 2D rotations for basic animations for anyone that doesn’t understand quaternions becomes a rather laborious task. I’ve done messy if-then statements to try to catch all the cases where rotation hits the ‘360 to 0’ boundary and it’s always ugly and seemed like there had to be a more mathematically correct way to interpolate a circular value.

Well for anyone that sticks with it long enough, they undoubtedly run into quaternions. What are quaternions? I’m not about to explain it in detail, but I like to think of them as a way to express a 3D rotations and not having that annoying gimbal lock problem.

So how do quaternions help our 2D rotation needs? Well if you’re in a situation where you need to interpolate between the shortest path between 2 angles then Quaternions can help. You have a few choices to solve this problem:

  1. Use if-then clauses to try to catch all the cases when you hit a rotational boundary if you are rotating from, for example, 300 degrees to 2 degrees. You would want to rotate all the way through 360 instead of going backwards.
  2. Use quaternions, which are more applicable to 3D rotations, to interpolate between to angles using spherical interpolation (slerp for short).
  3. Use spinors, which are a very similar concept to quaternions, except they are more catered to 2D rotations.

You’ll eventually see that using quaternions is somewhat overdoing it as 2 axises are never used in any calculation in 2D. If you eliminate these 2 axises from the quaternion you end up with a spinor! Thanks to Frank, of Chaotic Box, who helped lead me down that direction for my own iPhone game.

To help test out the concept and make sure it’s working I ended up writing a Blitzmax quickie app using what little I know about quaternions. I’m certainly a bit iffy when it comes to dealing with complex numbers, as I don’t fully grok them as I do normal vector math, but I make do. So if anyone reads this post and sees some sort of logical error in my code, by all means leave a comment and I’ll improve the listing.

So to get started I needed a way to represent a 2D rotation as a spinor. So I created a spinor type with some basic math functions (all of them analogous to how quaternions work):

[blitzmax2]
Type Spinor
Field real:Float
Field complex:Float

Function CreateWithAngle:Spinor(angle:Float)
Local s:Spinor = New Spinor
s.real = Cos(angle)
s.complex = Sin(angle)
Return s
End Function

Function Create:Spinor(realPart:Float, complexpart:Float)
Local s:Spinor = New Spinor
s.complex = complexPart
s.real = realPart
Return s
End Function

Method GetScale:Spinor(t:Float)
Return Spinor.Create(real * t, complex * t)
End Method

Method GetInvert:Spinor()
Local s:Spinor = Spinor.Create(real, -complex)
Return s.GetScale(s.GetLengthSquared())
End Method

Method GetAdd:Spinor(other:Spinor)
Return Spinor.Create(real + other.real, complex + other.complex)
End Method

Method GetLength:Float()
Return Sqr(real * real + complex * complex)
End Method

Method GetLengthSquared:Float()
Return (real * real + complex * complex)
End Method

Method GetMultiply:Spinor(other:Spinor)
Return Spinor.Create(real * other.real – complex * other.complex, real * other.complex + complex * other.real)
End Method

Method GetNormalized:Spinor()
Local length:Float = GetLength()
Return Spinor.Create(real / length, complex / length)
End Method

Method GetAngle:Float()
Return ATan2(complex, real) * 2
End Method

Function Lerp:Spinor(startVal:Spinor, endVal:Spinor, t:Float)
Return startVal.GetScale(1 – t).GetAdd(endVal.GetScale(t)).GetNormalized()
End Function

Function Slerp:Spinor(from:Spinor, dest:Spinor, t:Float)
Local tr:Float
Local tc:Float
Local omega:Float, cosom:Float, sinom:Float, scale0:Float, scale1:Float

‘calc cosine
cosom = from.real * dest.real + from.complex * dest.complex

‘adjust signs
If (cosom < 0) Then cosom = -cosom tc = -dest.complex tr = -dest.real Else tc = dest.complex tr = dest.real End If ' coefficients If (1 - cosom) > 0.001 Then ‘threshold, use linear interp if too close
omega = ACos(cosom)
sinom = Sin(omega)
scale0 = Sin((1 – t) * omega) / sinom
scale1 = Sin(t * omega) / sinom
Else
scale0 = 1 – t
scale1 = t
End If

‘ calc final
Local res:Spinor = Spinor.Create(0, 0)
res.complex = scale0 * from.complex + scale1 * tc
res.real = scale0 * from.real + scale1 * tr
Return res
End Function

End Type
[/blitzmax2]

One caveat in the above code is that any angle from 0-360 is mapped to 0-180 in the Spinor. What does this mean? it means if I want to represent the angle 270 I need to divide it by 2, creating the spinor with the angle 135. Now when I call GetAngle() it will return 270. This allows us to smoothly rotate the whole 360 degrees correctly. This is explained here in more detail.

So now I want to spherically interpolate (slerp) between 2 2D angles. Well, if I call Slerp() on the spinor type it’ll do just that, giving me another spinor that sits in between the 2 angles. I’ve read a couple of articles in the past on slerp and how to implement it, but in order to get things done I just used a publically listed code snippet and ported it to blitzmax. That whole article is worth the read and recommended, even if you’re just using 2D.

Now that the concept of spinors is encapsulated in the Spinor type I wanted just a basic convenience function that I can feed 2 angles and get another angle out:

[blitzmax2]
Function Slerp2D:Float(fromAngle:Float, toAngle:Float, t:Float)
Local from:Spinor = Spinor.Create(Cos(fromangle / 2), Sin(fromangle / 2))
Local toSpinor:Spinor = Spinor.Create(Cos(toAngle / 2), Sin(toAngle / 2))
Return Spinor.Slerp(from, toSpinor, t).GetAngle()
End Function
[/blitzmax2]
the ‘t’ variable is the time variable from 0 to 1 that determines how far to interpolate between the 2 angles. Giving it a value of 1 means you will get toAngle out, and a value of 0 is equal to fromAngle and anything in-between is just that…in-between.

Now I can call Slerp2D(300, 10, 0.5) And get the correct angle without worrying if I’m interpolating in the right direction :).

Also, I want to point out that the above code was just used in a quick proof of concept app. It’s somewhat sloppy and to be honest, I’m not sure I named the portions of the spinor correctly (real,complex), but it works. For clarity and to save time I didn’t inline the Slerp2D functions or the Spinor type methods, so it generates a lot of garbage. You would need to optimize this to use it in a tight loop somewhere. Any suggestions are welcomed.

As for references, I did some searching and got most of the ‘missing link’ materials I needed to bridge the gap between quaternions and spinors from:

…Adios…

I’ve been using Subversion even as a single developer for several years now. It’s invaluable to me and millions of other developers. If you’re a developer working on any project that lasts more than a couple hours and you aren’t using version control then you are shooting yourself in the foot. As a developer, we’re comfortable with juggling several things in our heads at the same time, it’s a fundamental skill we use everyday when developing software. But when you start to do ‘internal’ version control in your head while developing you are only slowing yourself down and it will ultimately lead to lesser quality code.

Don’t think you’ll need this chunk of code, but you’re not absolutely sure? Did you just rewrite method X but you want to keep the previous iteration around as a reference? And more relevant to me: Are you making a bug fix but are mentally keeping in mind how to revert that fix in case it doesn’t work?

All of those questions are red flags that you aren’t using your version control system (if any) to a meaningful capacity. That last question came up earlier this week when I was wrapping up the first alpha build to start testing with a small group of testers for my iPhone game, Tilt To Live. I wanted to implement a new collision algorithm in the game so the higher difficulty levels would run much more smoothly. Wanting to get this right ‘the first time’ (hahah ya right, another lesson learned) I first mocked the algorithm up in Blitzmax, optimized there and debugged it there. Of course, any debugging done in a different language for a mock up is fixing purely conceptual bugs rather than implementation bugs.

The Wednesday night deadline was quickly approaching and I just finished implementing the new algorithm. I start play testing for 5 minutes. 10 minutes. 15 minutes. 20 minutes, wow the game is performing really well! 25 minutes, CRASH! WHAT?! How can this be?

So I quickly restart the game to see if I can figure out any clues as to why it is happening. 5 minutes in I crash again, but it’s still seemingly random. And the debugger isn’t spitting out any useful information to help pinpoint the bug. Knowing the only code I had introduced was replacing a call to the new algorithm I knew just replacing a single line of code would revert me back to the ‘previous version’ (this should have been red flag #1). I start debugging for hours to try to find the cause of the ‘BAD_ACCESS’ fault that is most likely coming from a null pointer somewhere in the new collision algorithm, that seems to still happen ‘randomly’.

Anyway, hours pass and then the next day I spend a few more hours on it to try to see if I can fix it before I start trying to compile an alpha build. Failure. I simply just need more time to get this fixed without releasing the alpha build with a critical bug (red flag #2).

In the end, I had to revert to the slower n-squared collision algorithm for the alpha build. Using SVN, it was trivial to revert back to the previous version, quickly test it, build, and release. Yet, there is a much better process to avoid this very time-sensitive issue of getting bug fixes into a build without compromising the stability of the build. It’s called branches.

Now, I’m no stranger to branches, as I use them to catalog releases, but to incorporate them into my daily development routine is new and is something I’m going to try to implement to avoid this issue in the future. Jeff Atwood, co-creator of StackOverflow.com,  has a rather good summary of different branching patterns for on-going development. As a single developer I’m going to try to adopt the ‘trunk is sacred’ (Branch per Task) method and try to merge features into it from development branches.

What’s the benefit? Always being able to release something that is relatively stable regardless if you’re in the middle of something or not. And you don’t have to worry about ‘auxiliary’ changes you made leading up the current fix that may also break the build. I’m finding that as I draw closer to a more complete game, I need to be able to release builds on a weekly or bi-weekly basis for testers to play test. Knowing that there is some glaring bug that is a showstopper is a head ache for you and your testers.

I’ve been researching different version control systems outside of SVN to see if there’s something that could make branching and merging more seamless and integrated into my work-flow. I’ve found that distributed control systems such as git, and Bazaar, supposedly make this fast and easy. Although,  I’m not ready to give up subversion yet; mainly because it is working. But I may test those systems out in the future for smaller projects. TortoiseSVN’s merging dialog can be a little more clearer, as it stands now it is rather confusing the first time you use it. I’m currently testing out Versions (Mac Only) since I’m developing mostly on the Mac for the iPhone game, and it seems to be a little more intuitive in branching, but can’t comment on merging yet as I’ve yet to look into it.

And now I’m off to enjoy the rest of my weekend :).

Update: Looks like Versions won’t suit my needs. Neither will Cornerstone. SyncroSVN Client seems to support basic things like switching, merging, and branching while the other more ‘fancy’ looking apps don’t do anything beyond committing/updating/branching. Except that SyncroSVN’s GUI isn’t any easier than the command line for merging/switching. Looks like I’m going to the command line or revert to using Tortoise SVN (on windows) for the time being while these Mac apps sort themselves out and mature a bit…

It has been a while since my last blog post :(. If you’ve been following my twitter account though you’d know it’s still been a busy last couple of months. I’ve been developing things on several fronts lately. For one, I’ve been busy developing some supporting code to hook Opensteer into C4 in a more seamless matter and work with C4’s constructs in mind. It’s a project related to some school work, which has proven to be challenging and fun. Hopefully the students in the video game design class that I did this AI library for will find my work at least useful for their games.

In other news, I had a inspirational fever lately as I’ve come to understand a lot more of how physics and animation work due to a class I’m attending. I decided it’d be a fun spring break project if I could apply what I’ve learned to a simple 2D physics demo. Maybe it’ll grow to something more, but for now it’s more of an exploration and an excuse to work in Blitzmax again.

I’ve started the registration process for developing on the iPhone and it’s proven to be rather headache inducing lately with trying to get all the paperwork in order. After yet another delay, I won’t be able to start deploying apps on my iPhone for at least another 2 weeks. Damn. The iPhone game development venue seems promising, but the window is closing fast for anyone wishing to make a decent amount of money with minimal marketing effort. With the announcement of iPhone OS 3.0, and all the new features it’ll boast it makes the platform even more exciting to develop for. One of the more interesting development I think is the ability to ‘subscribe’ to apps and also buy additional content for particular apps. This type of business model would maybe give way to the first true ‘MMO’ (and I use the ‘Massively’ M loosely here) on the iPhone that can sustain itself? Interesting indeed.

Finally, I’m still chugging away at my Xbox Live Community Game. No idea when it’ll be done and there is no name for it yet. All I can pretty much say is it is a stylistic platformer. I recently got a parallax system working that I’m finally satisfied with. Also spent a couple of hours with Adam browsing music sites for potential audio soundtracks and we came up with some interesting possibilities. A lot of our musical choices leans more towards the ‘classical’ genre, so it’s not your typical uppity/pop/techno game music. I really hope as things solidify I’ll finally be able to post some media to show off the progress of my games. Until then, I’m focusing on finishing my last semester in school, looking for a developer job (preferably game industry related), and working on these game projects in the meantime.

I was made aware of a serious issue with detecting collisions between TGeom’s recently. While it did not affect anyone who was using the engine and letting the TPhysicsSimulator run and manage collisions and dynamics, anyone who wished to use Farseer.BMX’s collision routines separately by calling TGeom.CollideWithGeometry() ran into issues. The code has since been fixed and updated. Please update your Farseer.BMX module so you can continue using it without this annoying bug.

Download: Farseer.BMX v1.1

What if I made customizations to the Farseer.BMX code already?

Well thankfully, the bug was isolated to only one file, and in particular one method. If you wish to keep your custom build of Farseer but want to fix the issue then simply download this new version and take the Collisions/Geom.bmx file from it and place it in your corresponding Farseer.BMX directory.

If you happened to make changes to the Geom.bmx file itself, then simply search for the method ‘CollideWithGeometry()’ in the new version and place it in your current version. For those that simply want the code that’s changed (since this is a small change) I pasted it below:

[blitzmax2]
Method CollideWithGeometry:Int(geometry:TGeom)
For Local i:Int = 0 To _worldVertices.Count() – 1
_vert = _worldVertices._vecArray[i]
If geometry.Collide(_vert) Then
Return True
End If
Next

For Local i:Int = 0 To geometry._worldVertices.Count() – 1
_vert = geometry._worldVertices._vecArray[i]
If Self.Collide(_vert) Then
Return True
End If
Next

Return False
End Method
[/blitzmax2]

This was a minor update that I thought was critical to getting out there for those that may be experiencing problems, so there aren’t any ‘extras’. Documentation is still a WIP.

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:

[blitzmax2]
Local hashedFoo:String = THasher.sha1(“Foo”)
[/blitzmax2]

Want to hash a whole file? Then:

[blitzmax2]
Local filehash:String = THasher.SHA1_File(“someFile.txt”)
[/blitzmax2]
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 farseerModule.zip that you can extract to your “Blitzmax/mod/” folder.

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

[blitzmax2]
SuperStrict
Import aco.farseerphysics
‘Weeeee physics….!
[/blitzmax2]

… 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*… 😉