usfxr now supports BFXR’s advanced audio synthesis features

Posted by Zeh Fernando on 14/July/2014 at 9:03

header_bfxr

In preparation for the next Ludum Dare, I have finished adding all advanced sound synthesis features first introduced by BFXR to usfxr, my own Unity port of the SFXR game audio synthesis engine. The new version is 1.2 and is available as a zip download on the GitHub usfxr repository (the asset store version will be updated later this week).

(If you don’t know what usfxr or SFXR is, this post is less cryptic)

Interface for usfxr 1.2

The slightly updated interface for usfxr 1.2

At first, I wasn’t so sure I’d like to add the BFXR features to my port; I have to confess I always saw BFXR as a rogue fork of SFXR, and the fact that parameter strings were incompatible between the two projects always rubbed me the wrong way. However, after testing BFXR for a while, I came to really like its original features, and decided to adopt them in usfxr. This is what this update is about.

The new features are as such (as described by BFXR’s interface):

  • New wave form types
    • Triangle: robust at all frequencies, stand out quite well in most situations, and have a clear, resonant quality
    • Breaker: a little bit more hi-fiwave type; like a smoother, slicker triangle wave
    • Tan: a potentially crazy wave, tends to produce plenty of distortion
    • Whistle: a sine wave with an additional sine wave overlayed at a lower amplitude and 20x the frequency; it can sound buzzy, hollow, resonant, or breathy.
    • Pink noise: random numbers with a filtered frequency spectrum to make it softer than white noise
  • New filters
    • Compression: pushes amplitudes together into a narrower range to make them stand out more; very good for sound effects when you want them to stick out against background music
    • Harmonics: overlays copies of the waveform with copies and multiples of its frequency;g ood for bulking out or otherwise enriching the texture of the sounds
    • Bit Crusher: resamples the audio at a lower frequency, for that extra retro feeling
  • Expanded pitch-jumping abilities; good for arpeggiation effects

On top of that, this new version is still compatible with previous versions, as well as SFXR itself; instead of starting anew and breaking compatibility, usfxr accepts both standard (SFXR/as3sfxr style) parameter strings, as well as the new BFXR parameter strings. This means old code will still work, but you can also copy & paste effect parameter strings directly between usfxr’s Unity interface and BFXR.

There are a few additional non-core BFXR properties that I will have to add support for in the future, specifically property locking for mutation and the UI. This should be added soon along with other UI updates.

Round-up of usfxr uses from around the web

Posted by Zeh Fernando on 6/June/2014 at 17:09

Now that usfxr has an in-editor window for audio generation right inside Unity, I’m considering it stable. I’ll probably do a few benchmarks in the future to improve any performance bottlenecks I’m able to identity, and maybe add a few more examples to the repository, but for all intents and purposes it is production-ready.

Given that, I figured I’d do a search to see if anyone was using the library, and how. I found quite a few, so I’d do like to share some picks here.

D-Lask has been posting a few interesting videos of Unity experiments into his Vine stream, including one using usfxr with the Playstation move (enable audio to hear it):

Love Connection is a Ludum Dare game by thecodermonkey using the “Minimalism” theme. It’s a great, great entry for Ludum Dare, and it’s not surprising it ranked very well (#8) in the overall Ludum Dare results.

1Fuel is an old Ludum Dare entry by unitycoder_com under the theme “You Only Get One”. It’s a simple game, but one with an interesting gameplay mechanic.

The same developer has a blog with a lot more small examples and tests that use usfxr.

Super Minimalistic Nuclear Space Potatoes! is a Unity game by Hatscat also for Ludum Dare under the “Minimalism” theme.

And finally, a while ago, Jorge Garcia tweeted a picture of the “SpaceGame” example running on a PS Vita, which makes me pretty giddy:

Awesome seeing other people trying it out!

Create 16-bit sound effects right inside Unity with usfxr

Posted by Zeh Fernando on 4/June/2014 at 15:49

It’s been a little more than one year since I introduced usfxr, a Unity/C# version of the well-known real-time procedural game audio generator sfxr. What it has been lacking for quite some time was the ability to generate sound effects right inside the Unity interface; developers were forced to visit an online source like as3sfxr to generate their audio parameters (as a string), and only then use usfxr to play the audio in Unity games.

Well, no more. I finally got around to improving the in-game editor window first created by Tiaan Geldenhuys, and now you can use a Unity tab/window to generate audio parameters, and then copy the parameters so you can use them in code. The sound generating window looks like this:

usfxr Sound Generator

It also plays audio automatically every time one of the parameters is changed, so it’s easy to mess around with it until you get the sound effect you want. The generator window also works whether you’re in play mode or not, so it should make it easier to create sounds on-the-go.

As a reminder, this is how a usfxr sound is played in Unity by using a generated parameter string:

SfxrSynth synth = new SfxrSynth();
synth.parameters.SetSettingsString("0,,0.032,0.4138,0.4365,0.834,,,,,,0.3117,0.6925,,,,,,1,,,,,0.5");
synth.Play();

The new version of usfxr can be found on GitHub.

Implementing Kongregate’s statistics API in Unity using pure C#

Posted by Zeh Fernando on 7/May/2014 at 13:07

After creating an updated version of my latest Ludum Dare game, I decided to use it as an exercise in web publishing of games. To me, the interesting thing about publishing a game on a web portal – even one as simple and rough as one created in a little bit more than 48 hours – is that you can get a community of players to test, rate and give suggestions on your games, as well as get access to custom APIs for things like site-wide high-scores, achievements and statistics.

A website I decided to target for this experience was Kongregate, one of the biggest web game portals our there. A web gaming portal normally means “Flash games”, but like many others of its kind, Kongregate also accepts Unity games.

Kongregate also implements an interesting API that can be used by games when they’re published there. I believe the API is only officially supported for Flash and JavaScript, more or less, but Unity developers can still use it with the help of Unity’s external application interface (which allows for JavaScript calls from the Unity web plugin).

However, when reading on how to do this, I ran into two issues. First, most of the examples on how to use the statistics API from Unity are based on using JavaScript within your game (1, 2), while I was using C# instead; and second, and most importantly, all implementations depended on the oh-so-common pattern of creating an empty GameObject instance in a Unity scene and then attaching scripts to it (then getting a reference to it everywhere else via magic strings), rather than just a pure code-based solution. In fact, the API itself looks for a GameObject when returning the result of calls.

As much as I’ve been trying to give in to the proliferation of GameObjects everywhere that seem to be mandatory in Unity projects, to me the only solution was a clean C#-based implementation of the code – one that creates its own GameObject when necessary. The result is a single class that can be copied anywhere on your “Scripts” folder:

using System;
using UnityEngine;

public class KongregateAPI:MonoBehaviour {

	// Properties
	private bool _isConnected;
	private int _userId;
	private string _userName;
	private string _gameAuthToken;


	// ================================================================================================================
	// MAIN EVENT INTERFACE -------------------------------------------------------------------------------------------

	void Start() {
		_isConnected = false;
		_userId = 0;
		_userName = "Guest";
		_gameAuthToken = "";
	}

	void Awake() {
		// Instructs the game object to survive level changes
		DontDestroyOnLoad(this);

		// Begin the API loading process if available
		Application.ExternalEval(
			"if (typeof(kongregateUnitySupport) != 'undefined') {" +
			"    kongregateUnitySupport.initAPI('" + gameObject.name + "', 'OnKongregateAPILoaded');" +
			"}"
		);
	}


	// ================================================================================================================
	// PUBLIC INTERFACE -----------------------------------------------------------------------------------------------

	public static KongregateAPI Create() {
		// Create a game object with a reference to the API
		GameObject newGameObject = new GameObject("KongregateAPIObject-" + (Time.realtimeSinceStartup));
		KongregateAPI instance = newGameObject.AddComponent<KongregateAPI>();
		return instance;
	}

	public void OnKongregateAPILoaded(string __userInfoString) {
		// Is connected
		_isConnected = true;
 
		// Splits the user info parameter
		string[] userParams = __userInfoString.Split('|');
		_userId = int.Parse(userParams[0]);
		_userName = userParams[1];
		_gameAuthToken = userParams[2];
	}

	public void SubmitStats(string __name, int __value) {
		Application.ExternalCall("kongregate.stats.submit", __name, __value);
	}

	public bool isConnected {
		get { return _isConnected; }
	}

	public int userId {
		get { return _userId; }
	}

	public string userName {
		get { return _userName; }
	}

	public string gameAuthToken {
		get { return _gameAuthToken; }
	}
}

And it works like this:

// Create an instance of the API during setup in your game Main class
KongregateAPI kongregate = KongregateAPI.Create();

// Later, submit stats using it
kongregate.SubmitStats("high-score", 1000);
kongregate.SubmitStats("tanks-destroyed", 1);

I have also added this class and some instructions to a GitHub repository, just in case.

With this implementation, I was able to easily add statistics to the Kongregate version of the game, creating a “high score” table of sorts countint the number of moves performed by players prior to completing each level. I don’t really anticipate any high competition for this. As an exercise in C# and Unity development, however, it was surprisingly pleasant and straightforward to get results.

50 years of BASIC

Posted by Zeh Fernando on 1/May/2014 at 11:59

The BASIC language is now 50 years old. TIME Magazine has a cool article on it and how it came to be.

When I started using computers, first with a ZX81 clone, then an Apple II clone, and then a MSX 1.0 clone, BASIC was the only thing that I knew exusted. It was synonym of computers for me, and for the longest time, the only programming language I knew as I didn’t even know other programming languages existed. I have very fond memories of the Usborne books and its little robots teaching me about arrays. I still remember very distinctly the moment I discovered sprites in Basic; you’d stop your program and the sprites would remain on screen, obscuring your code. I later fell in love with GWBasic, learned assembly through it, discovered how to better engineer programs with QBasic, and learned to create applications with QuickBasic. I’ve never owned an Amiga or a Commodore 64, but I remember finding old magazines dedicated to these platforms (with program sources) and dreaming of the possibilities. One of the reasons I learned English without consciously trying was spending so much time reading and re-reading those magazines. BASIC was the step stone to a dream world.

I’ve used C and Turbo Pascal at the same time I was learning GWBasic, and while those had their advantages – I especially liked Turbo Pascal for its speed – I kept coming back to QBasic just because things were so much easier and quicker. It remains as the only language or platform I’d do development and debugging with breakpoints and on-the-fly changes. The QuickBasic IDE had an awesome help system too, something that made me realize a good reference is fundamental for development and that you can’t know it all on the top of your head. For the longest time, it was the platform I knew and used the most, and that’s what I used even for large database merging when I started working professionally, even if faster runtimes existed: it was just much easier to tinker with. And despite what other well known names might think of the language, it was the gateway drug that took me to greener pastures. BASIC wasn’t perfect, but when used well (especially with QBasic/QuickBasic), it was beautiful. I think the same can be said of most programming languages or platforms.

I don’t think BASIC or any of its alternatives are the best language for first-time programmers anymore; I think Processing is a much better choice for a number of reasons. Still, the immediacy of BASIC is what got me interested in this whole game: I’m not sure I’d have felt the same way with some other platforms that required a massive bootstrap before I saw something on the screen.

So, thanks, BASIC.

Ludum Dare 29 Post Mortem

Posted by Zeh Fernando on 28/April/2014 at 18:14

Once again, a Ludum Dare game compo has ended. This means I spent this past weekend creating a game from scratch, and even though it’s a simple thing, I think this is the first time I can say I created a more well-rounded game experience for Ludum Dare.

The result is called Escape Enclosures Expeditiously (or Escape Drill in the improved, post-Ludum Dare version), and it’s a simple puzzle-like isometric game where the player should to the exit of each map without being touched by one of the enemies.

Escape Enclosures Expeditiously

It’s a short game – only 3 levels (plus an ending level). Here’s a video of a full playthrough with no deaths.

But of course, this being a post-mortem, what follows is some more information about the game development process.

First implementation of the tile terrain game object

First implementation of the tile terrain game object

I started development without much of an idea of what I wanted to create. My initial approach – which is fast becoming my common approach for Ludum Dare compos – is to just try something different for the sake of learning, rather than actually trying to create a full fledged game. This means that my emphasis is normally on the technical side of things – as long as it’s new to me – rather than on the fun. It sounds harsh, but that’s what makes it fun to me.

Getting tile height and color calculation working

Getting tile height and color calculation working

This time around, I had my mind set on using Unity to create a custom level editor to make game creation easier. I was inspired by several different things: Hitman Go, a surprisingly simple but ingenious twist on the Hitman series; isometric turn-based games to the likes of Final Fantasy Tactics, Tactics Ogre and Disgaea; and a series of tutorials of someone recreating Doom’s classic E1M1 level on Unity using a plugin of some sort, something that showed me how powerful custom editors can be in Unity.

Allowing tile heights to be edited in the 3d view

Allowing tile heights to be edited in the 3d view

My goal, however, was not really to create a game in itself, but to learn how to extend Unity in a way that allowed that kind of map to be created more easily. I ended up with enough time to actually create some gameplay, but it’s almost a side effect.

Painting tiles with different surface types

Painting tiles with different surface types

What went right

Using Unity: in a previous Ludum Dare post mortem I mentioned Unity as one of the sore spots of my experience (although it doubles as one of the pros too). This time around, it shows exclusively as a positive point. I was able to leverage my past experience with the platform (as little of it as I have), work on top of what I learned (and side projects as usfxr) and basically spend more time implementing things rather than learning how to implement them.

Design of the first level

Design of the first level

That’s not to say there was not much to learn. Quite the opposite. At any point in development, I had dozens of browser tabs open with the most random items from Unity’s references or random tutorials, blog posts, and questions/answers pages out there.

Testing enemy models

Testing enemy models

What’s more, my conclusion is that Unity is pretty powerful when creating custom editors and elements. I can see how the ability to customize your working environment can be a big boost for developers working on a game, especially on members dealing with content creation such as level design. Even if my level design solution was pretty ghetto (I had the worst method for painting tiles with different terrain types, for example), it was still a pretty important time saver.

Implementing movement and enemy AI

Implementing movement and enemy AI

I still feel a little weird with the platform. Its emphasis on what I can only describe as concrete elements, such as adding scripts to physical objects and using the 3d view for everything, is still what feels strange to me. That, and maybe the emphasis on global access to everything from everything and a lot of helper functions to query the level elements. However, I believe I’m slowly learning to ignore my impulse for abstractionism and just get stuff done as inelegant as I might think it is. My hope is that with time I’ll understand what’s the actual ethos of the platform for performance and correctness, but I know I’m still far from that point.

Making multiple levels possible

Making multiple levels possible

Using simple assets: this time I purposely used very simple assets. The only texture used in the game was a 256×256 noise texture quickly created in Photoshop, and all the 3d models were simple boxes spliced and reshaped into basic shapes using Blender. I get very easily distracted into doing mundane tasks such as making sure none of my vertices are duplicated and everything invisible has a proper name or something of the sort, so I’m happy I managed to not spend too much time doing complicated art. I only had to deal with broken normals twice!

The final game scene with all levels

The final game scene with all levels

Conclusion

Now, what went wrong? Nothing, I think. This was fun, and I learned a lot. Given more time for level design and testing, I’m sure I could come up with more, and better puzzles. But that’s true of every Ludum Dare, so that’s something I can live with.

Firstborn is looking for a senior Flash/AS3 developer, of all things

Posted by Zeh Fernando on 21/February/2014 at 11:28

Just as a heads up, Firstborn is looking for a senior-level AS3 developer for our NY offices. You can find more information about this position here.

We’re still saying to ourselves “I can’t believe we’re looking for a Flash developer”. Truth be told, while Firstborn has established its reputation for visual interface acuity in the heydays of Flash-based websites, the bulk of our target platforms now are HTML and (native) mobile.

When you look at problems in a framework-agnostic way, however, Flash still solves some challenges in a faster and better way than the alternatives. With that said, we’re hiring for a very specific project, and one I’m very excited about; it is a “sister” project to the one I’m currently working on. It’s a commercial thing (not a game), but still one interesting interface and a chance to work on a product-like project.

If you’re interested, please contact us. If you know someone who might be, please forward them the link.

As a side note, this is a full time position for our NY offices. Due to the way this is deployed and tested (it is not a web project), and because it is supposed to take a while, it cannot be a freelance or remote gig.

KeyActionBinder is growing up

Posted by Zeh Fernando on 14/February/2014 at 0:14

After a lot of breaking things, refactoring, and testing, I’ve finally merged the experimental branch of KeyActionBinder into the main branch of the project. The biggest change, of course, is making the functionality of this gamepad support library more automatic, in the sense that it tries to detect whatever game device the user has connected and map its inputs accordingly, so game developers don’t have to care about writing hundreds of lines of code to have their games work when doing cross-platform (or even single-platform) development in AS3 and Adobe AIR.

On top of that, I’ve also started doing a lot more of mapping work (using the test interface I mentioned earlier) and adding them to KeyActionBinder’s new separate list, which is now just a long JSON meant to be easily edited. This is what the library supports right now:

  • Windows 7
    • XBox 360 controller
    • PlayStation 4 DS4
    • NeoFlex (generic Gamepad)
  • OUYA
    • Native controller
    • XBox 360 controller
    • Playstation 3 DS3
    • Playstation 4 DS4
  • OSX
    • Playstation 3 DS3 (standard plugin version)
    • Playstation 3 DS3 (standard plugin version)

However, several other developers started contributing to the project, and I have a long list of mapping that I will be adding soon (I have to adapt them to a new format I’m using in the JSON file).

Syntax-wise, it hasn’t changed much. Usage is like so:

// Initialize (first frame of SWF)
KeyActionBinder.init(stage);

// Create an instance somewhere
binder = new KeyActionBinder();

// During startup, add as many bindings as you want, using your own action ids
binder.addKeyboardActionBinding("move-left", Keyboard.LEFT);
binder.addKeyboardActionBinding("move-right", Keyboard.RIGHT);
binder.addGamepadActionBinding("jump", Keyboard.SPACE);
binder.addGamepadActionBinding("move-left", GamepadControls.DPAD_LEFT);
binder.addGamepadActionBinding("move-right", GamepadControls.DPAD_RIGHT);
binder.addGamepadActionBinding("jump", GamepadControls.ACTION_DOWN);

// Finally, during the game loop, check the values
if (binder.isActionActivated("move-left")) {
    playerSpeedX = -1;
} else if (binder.isActionActivated("move-right")) {
    playerSpeedX = 1;
}
if (isPlayerOnTheGround && binder.isActionActivated("jump", 0.03)) {
    // Will only jump if activated in the last 0.03s
    // This prevents a player being able to press jump while in mid-air
    playerSpeedY = -1;
    // Consume action so it won't be true in next frame
    // This prevents a player from jumping continuously
    binder.consumeAction("jump");
}

There are other use cases, but that’s the basics. See the rest in the project page.

I started this project just as a support system for a game I’m developing in my free time, but considering the complexity of supporting several different devices and their own custom control inputs, it soon became obvious this had to be a more public effort – one that more people could help, and benefit from. I’m pretty excited it’s finally taking form! It still has a long way to go, but it’s quickly becoming a pretty solid solution, in my opinion.

A GameInput testing interface

Posted by Zeh Fernando on 8/January/2014 at 16:19

To build the list of known GameInput controls spreadsheet, I had to build a small sandbox-like application test for controls reported by connected devices. It was my intention to make this available to other people so they could do their own tests, so here it is: just wait for the following Flash movie to load (reload the page if it gets stuck), click on it, then use whatever connected game devices you have to test for input controls, their values, and their injected Keyboard events (if any). The values you see should be the same for both the web version of Flash Player, and Adobe AIR.

It’s a simple application, but it does its job: the first column will list the connected devices, their available controls (buttons and axis), and the state of each of those (including whether granular values were detected for analog buttons and axis). The middle column will show the state of pressed keyboard keys; this is useful when testing on Android and the OUYA. Finally, the third column will display a log of everything that has been pressed, in the sequence it happened; this helps detecting injected keys, especially on mobile versions of AIR.

The embedded version above is provided just as a demo; you can open it in a full page/tab here. An Android/OUYA AIR equivalent can be found here in the form of an APK that needs to be installed to your device (same with the OUYA). Also noticed that the source for the tester interface is available on GitHub; it is part of the KeyActionBinder library. It doesn’t really use the library, though, since it’s more of a debugging and development tool.

In defense of reinventing the wheel

Posted by Zeh Fernando on 5/November/2013 at 16:48

When I am programming something that requires a module or a sub-system of any kind, my first impulse is to always write it myself; sometimes, even rewriting things I had already written before. While there’s a danger in doing too much of this and avoiding well-established solutions to common problems – the syndrome of Not Invented Here is a thing – I have always justified this decision by rationalizing that I have a better understanding of tools I build from scratch than some mysterious library with unknown side-effects, and that it is more fun to do it myself anyway. Obviously, this is not a solution that should be used all the time, as sometimes the time spent building complex systems (say, a rigid body physics system) can easily outweigh the benefits, but it’s one I find myself doing time and time again, and feeling guilty doing so.

In reading Game Engine Architecture by Jason Gregory, however, I ran into the best rational defense of the practice I’ve seen so far. When talking about building custom container classes for certain data structures, the author gives the following reasons why game developers normally choose to do so:

  • Total control. You control the data structure’s memory requirements, the algorithms used, when and how memory is allocated, etc.
  • Opportunities for optimization. You can optimize your data structures and algorithms to take advantage of hardware features specific to the console(s) you are targeting; or fine-tune them for a particular application within your engine.
  • Customizability. You can provide custom algorithms not prevalent in third-party libraries like STL (for example, searching for the n most relevant elements in a container, instead of just the single most-relevant).
  • Elimination of external dependencies. Since you built the software yourself, you are not beholden to any other company or team to maintain it. If problems arise, they can be debugged and fixed immediately, rather than waiting until the next release of the library (which might not be until after you have shipped your game!)

I could not have said it better, and have to confess I felt a bit vindicated when reading it. It’s very often that I have to dig into a certain class to either add a missing feature, or to tweak something in an otherwise unorthodox way to provide some much-needed performance boost for a particular edge case. For good reasons, generalized solutions tend to go against that; and while tweakable, open-source solutions exist, nothing beats knowing the behaviors of a particular system inside and out because you built it.

Joel Spolsky talks a little bit about the subject in much a much better manner than what I’d be able to conjure, and comes up with an advice for software teams (as a short tenet, in true Joel Spolsky fashion):

If it’s a core business function — do it yourself, no matter what.

There’s an advantage in using stuff that has been tested by a big group of people, of course. I probably need to get better at using other people’s stuff. In the meantime, though, I’ll happily continue reinventing when I can. It’s more fun this way.