image SOS Devblog: Week 4 image SOS Devblog: Week 6

Drop us a line...

If you'd prefer, you can email us directly:

Or give us a call:

(+61) 433 351 425

SOS Devblog: Week 5

Although SOS isn’t a game where the player will be dying frequently (a la Limbo), it remains an important motivator for many puzzle solutions. Now that we’ve finally included the capacity for Sin to die, he dies… a lot. Getting struck by heavy objects, falling too fast, spikes, traps, misplaced gravity shifting, and all of these methods are completely hilarious because there is no death animation and most of the causes can currently only be seen in the physics test bed mode.

All of this abundant dying means that many of the game’s objects are being interpreted correctly from the level files. This week gone by was mostly focused on getting as many of the game’s objects usable and interactive in a quick and dirty fashion, and this means that at this point, the game looks visually atrocious (which I try to interpret as a good thing, because it hopefully means we’ve made some significant progress). There are no visual cues or animations to show the functioning of most of the objects, but it’s been fun messing around with the game’s physics engine and seeing how the objects can interact with each other. It’s been very useful developing a large collection of puzzles ahead of time, because we know how robust each of the objects needs to be to allow for the puzzles we’ve designed to be solvable. It helps us to identify bugs (of which there are many, so many) quickly and inform better functionality.

We’ve also been putting IrrKlang through the wringer this week, testing its functions and quizzing the forums main moderator to see what might be possible with it. Trying to mimic some of XACTs features for DSP effects, I tried to recreate a low-pass filter using IrrKlang’s built-in ‘sound effect’ functions, but found the results a bit so-so, and audio popping was noticeable as the effects turn on and off which we will have to resolve. I’ve successfully been able to recreate most of XACTs cue functionality within a couple of classes, and all of the game’s sound assets are managed through the interpretation of a couple of XML files to indicate cue structure. Features like pitch modulation and instance limiting were negated due to them not being relevant for this project, but I keep making mental notes of what code needs fixing and abstracting so that this structure could be used in our future projects without too much porting hassle.

If you have any questions about our development, please don’t hesitate to contact us at contactus@, or using the comment form below.

About James
I’m deeply passionate about the promoting and developing the social, educational, and creative potential of games. Through my work at Chaos Theory, I have only just started a journey to doing exactly that.
Related Posts
  • All
  • By Author
  • By Category
  • By Tag

Leave a Reply

Your email address will not be published.