New usfxr release (1.3)

Posted by Zeh Fernando on 8/August/2014 at 17:02

I have just published release 1.3 of usfxr on its GitHub repository. This is a small update, but it provides some important fixes (especially when publishing on mobile platforms) and adds the option to export your audio as WAV files (similarly to other SFXR ports). I have to thank Michael Bailey and Owen Roberts for their help with bug detection and fixing in this version.

The Asset Store version should be live some time next week is also available now.

Presentation: Using Unit Testing

Posted by Zeh Fernando on 7/August/2014 at 14:35

Every Thursday morning at Firstborn is “Scrummy Thursday”. For one hour, Firstborn developers present random topics to each other. Those are usually little, 15-minute presentations on projects we’ve worked or things we discovered, and it is meant as a way to share knowledge among the development team. It’s a nice idea, and it has been working well for a while.

Today I had a little presentation on how I used Unit Testing to help me refactor a part of Pepsi Spire (my most recent project) with some confidence. I’ve made the slides available publicly, and you can check them below.

Click the slideshow and press “S” to show the presentation notes, which will help make sense of what’s being displayed.

The content of the presentation is not anything groundbreaking (there are better unit testing introductions out there), but I thought I’d share it nonetheless. For the longest time, I’ve looked at unit testing with some contempt; it normally wouldn’t work with the kind of UI-heavy, animation-heavy, short-lived code I had to create. Still, this was an instance where unit testing helped me avoid trouble and surprises, and save time in the long run. And while this particular project was made in ActionScript 3, this is a tale that can be repeated on any given platform.

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.