I have mixed feelings about Android Studio, Google’s new IDE for Android development.

On the one hand, the official Eclipse-based ADT has always been pretty bad. Performance is terrible, memory consumption is insane, it breaks down all the time, and I have persistent issues that force me to “clean” projects and restart the application dozens of times a day (literally). It always felt to me like was a very ghetto solution, even if it was one that was (slowly) improving.

I don’t hate Eclipse per se. FDT, the IDE I use for developing ActionScript 3 content, is also based on it, and it flies (very smooth; I never get any problems on it at all). So while I don’t doubt Eclipse was the main source of the clunkiness of ADT, I’m pretty sure solutions existed.

That’s why I’m kind of puzzled that instead of taking a good, hard look at ADT, and in cleaning up stuff that they don’t need, they’ve chosen to go with a completely new IDE based off another solution.

I do love IntelliJ, at least from the limited experience I’ve had with it through WebStorm, which is my HTML/JS development IDE of choice.

But frankly Android Studio feels kind of crappy.

I know it’s a beta, or alpha, or preview, or whatever they’re calling it to mean it’s not a complete or stable application. I get that. But judging from most of the interface and how some thing are still so broken, and so slow, I fear that they’re switching from one semi-broken development solution to another semi-broken development solution of a different flavor.

Android development really needs a better environment. As it is it works, but in a very clunky fashion. We did need a refresh of some kind.

I just hope Google is as serious about Android Studio as it needs to be, and that the current build is not indicative of the target quality they want to achieve.

The 26th edition of the weekend-long competition Ludum Dare is just wrapping up. The theme this time around was “Minimalism”, and as I had decided to create something for the Oculus Rift, I decided to re-create a scene of the movie 2001: A Space Odyssey: the scene where astronaut David Bowman has to rescue Dr. Frank Poole.

In a way, this wasn’t an idea I wanted to go with at first – while the space theme (and the feelings the movie bring as a whole) can be seen as related to minimalism, there’s no real game on it. I normally use Ludum Dare to learn, however, so I thought it was a good enough reason to use the movie as a context in the absence of brighter game-like ideas.

The result is called 2001: A Space Oculus. It’s available for Windows and Mac, and requires the Oculus Rift to be played. Source code is also available.

In this “game”, you have to rescue an astronaut that has been floating in space by taking him to the front of the space ship. I also wanted to try a simulator with a difficult control – QWOP-style – so controlling the pod is admittedly hard.

It was certainly an interesting learning experience. While I’ve been toying with Unity for the past few months, I hadn’t created a full game-like experience yet, so there was much I had to research.

The good

Using Unity

Using Unity is certainly interesting. In a way, it’s very easy to get a game running with very little. It reminds me of the days of using the Flash IDE: you could just plop some content on the stage, add just a little bit of scripting on top of it, and get it doing all kinds of crazy things right away. I wonder if that kind of easiness served as a guide to the Unity developers when creating their IDE.

Because of that, starting the game was a breeze. I opened the Tuscany demo (available as part of the Oculus SDK), changed a few assets, and was running around in a space-floating Tuscany set in no time. It went from that, adding one little thing at a time.

Doing the jam

I decided to do a more relaxed entry this time – as part of the slightly-less-restricted jam, rather than following the compo rules. This allowed me to use third-party content on my entry, which was necessary since I wanted to reproduce a famous movie set (fan-made props were likely to exist as 3d model somewhere else).

The bad

Using Unity

While it’s certainly a great tool (and my game-like thing wouldn’t be possible at all without it), there’s a catch to it, and maybe it’s a more personal one.

Over the past few years, I’ve evolved as a Flash developer into someone who would not only use a different IDE for code writing, but also a much better managed project structure that was entirely based off pure ActionScript code (with resource loading or embedding as needed). As a result, none of my projects were based off the Flash IDE, and I would never run it anymore unless I needed to export some vector art. I felt that kind of workflow much better in the long run, and much easier to work around in complex situations.

Hence why going back to the stage-drive approach of Unity made me feel… dirty. Going back to hacking stuff on the stage and adding scripting to it.

I’m trying not to be judgmental, and of course I’m not a proper Unity developer, so maybe it’s just my temporary impression. But while getting things started was easy, getting things to a point where I was happy with where harder than I thought. I’d constantly run into seemingly bizarre engine problems that forced me to deviate from the easy path for a while and implement some script meant to patch over the problems, or look for a hack online.

In the end I had to import, write, or edit several editor scripts meant to do little things to my meshes in an attempt to solve some of the shortcomings I’d run into. While the availability of the editor script is a strong positive feature for the platform – you can tweak the editor to your heart’s content, and do some pretty complex content manipulating with it – it also means that I spent a lot more time fiddling with content fixing and creating editor features rather than proper game content creation. I wonder how complex the editors of seasoned Unity developers look like; they probably had tons of additional commands to solve common issues they run into.

I also had trouble changing much of the Oculus Rift support scripts. While the Tuscany demo works very well if you want to get a 3d first person shooter going, it can be hard to wrap your head around it if you want a more unorthodox control. For example, I initially wanted the pod to be able to rotate around in space in all axis – for true space flying. However, I had a lot of trouble fixing the code so you could rotate around and, say, be upside-down, and in the end opted to freeze the user’s X and Z rotation. This is mostly due to my lack of proper understanding of quaternions and Euler angles, I suppose. Given time, instead of reusing existing code that has been put together in a way that “just works”, it would have been better to start something fresh with a proper understanding of the Rift’s SDK’s internals (and Unity’s 3d space coordinates).

Using third-party content that’s not ready for a game

Again, my project wouldn’t be possible without third-party content, so I don’t mean to imply that’s a bad thing. The problem with using content found elsewhere is that while they may look right, they may not perform the way you wanted it to.

I had plenty of problems with the spaceship Discovery’s meshes – they were all using weird origin points. I had to write a script to reverse the normals of a few select meshes. The internal unit scale was all goofy, and it had some hidden meshes that exploded or moved around when imported.

The rescue pod had no interior. Parts of the arms where attached to the hull, even though they were a separate mesh (which took me down a spiral of trying to fix it in Blender, only to realize Blender didn’t support the original mesh smoothing groups, forcing me to export the model as an OBJ from within Unity using yet another script, then spending hours getting the arms split).

The list goes on.

It’s certainly amazing that fans find the time to model movie content as well as they did. I’m very grateful for the fact that I could be flying around a ship from a movie in 3d space in no time – that was a delight. But one has to consider the problems with adapting content such as this. Given time, I’d have spent a good amount of time tweaking the models in something like Blender, and getting it in a state the Unity platform would be happy with. As it is, I’m surprised it worked.

Conclusion

Overall, this was again a great learning experience. I’m happy my “game” has a final objective this time around too (as hard as it is, given the physics and the complex control). And while I don’t think it’s super fun as a game, hopefully more people will enjoy floating around in space and simulating that scene from the movie. I was certainly overjoyed. There’s some things you can only experience with the Oculus Rift.

Finally, I ended up not using usfxr, the sound generator library for Unity that I had created with Ludum Dare in mind. In the end, though, Ludum Dare is about experimenting and having fun, so I don’t feel bad about changing my goals halfway through the competition. I’m sure I’ll be using it in the future, however.

If it’s not obvious by previous posts or some of my posts on Twitter, I’ve been playing with the Unity platform for a while. The idea is to learn enough of it to be able to create a Unity game for Ludum Dare (which, incidentally, will take place again this weekend).

My previous Ludum Dare games where created in Flash, and while I was somewhat happy with my coding effort, the games didn’t have any audio. I decided to make things different next time, and have some simple audio feedback on whatever I built.

To get myself acclimated with the language, I decided to port Thomas Vian’s as3sfxr to Unity. What’s as3sfxr, you ask? This short video from Flash on the Beach 2010 has a great explanation:

In a nutshell, sfxr is an engine for dynamic generation of game-like audio effects. Thomas ported Tomas Pettersson’s original sfxr to ActionScript, creating a nice API for dynamic audio generation. This API was the basis for usfxr – and really, much of the code in usfxr is a direct translation of as3sfxr, albeit in a more C#-friendly, Unity-happy way.

In practice, what does usfxr do, though? It allows you to publish a game with no static audio assets (all effects are defined by a parameter string), and to generate small variations of the same audio in real time, thus making the audio playback a bit more colorful.

Code for a normal audio effect looks like this:

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();

While “mutated” versions of the audio can be played like so:

synth.PlayMutated();

The library is a pure code port, with no GUI whatsoever (you can generate audio strings in as3sfxr‘s GUI, copy it, come back to your C# code, and paste the string). Other than that, the biggest difference is that audio data is (almost) always generated on a separate thread, so the need for pre-emptive caching is diminished.

I have an example of usfxr in action in a (terrible-looking) Shmup example (requires Unity web player):

The full code is available on GitHub. I’ll probably fix a few more things – mainly write proper documentation, add a different sample, and maybe make it faster – but overall it’s working. And obviously, I’ll be using it on Ludum Dare this weekend.

Some input would be welcomed, of course – I’m not a experienced Unity developer.

This video has been making the rounds recently. It is somewhat longer than it could have been, but I still think every web developer should watch it.

Loading a web page is a slow affair, especially on mobile devices. Everybody knows that. The important point, explained in the video, is that there are techniques that can make this faster. It is surprising how easily some of the solutions can be applied to a website: it appears to me that in our effort to stack feature over feature on a website, we tend to forget about performance.

I’ve recently applied some of the lessons reinforced in this video to this very own blog, reducing the page load times by half on the desktop (on average) and making navigation much more responsive; and it’s just the start. I’ve also came up with some other small things in the process. So, in a practical sense, I’d recommend everyone who manages a website do this:

• Double-check to see if you’re not loading any useless or near-useless stuff on your pages. This includes third-party extensions or plugins that are seldom used. In my case, WordPress’ semi-mandatory plugin JetPack was doing a lot of load hogging, including loading third-party analytics scripts I did not want. I only used JetPack for statistics – something that was somewhat redundant, since I already used Google Analytics – so turning off JetPack was a no-brainer.
• Run Chrome audits on the website to determine what are the major loading bottlenecks. This is a great tool that will give you an easy, itemized list of things you could do to improve page loading; here’s a good tutorial on using audit. In my case, I identified a few CSS files that could be combined or have their loading order changed, and this was enough to provide some additional load boosting. The audit goes much deeper, though, including listing you individual CSS properties that are never used or the caching settings of individual files.
• Start using Google Analytics Site Speed. This is a somewhat new, but invaluable tool on Google Analytics, as it can measure load times of pages for your users. One slightly tricky thing about it is that if you have a low number of visitors, you may need to boost the tracking sample rate to get meaningful results – this can easily be done by editing your Google Analytics embedding code.

It’s interesting how often and how easily websites don’t take any of that into consideration. It’s easy to find websites loading dozens of third-party scripts (mostly for tracking and ad-serving) synchronously, slowing down the user experience in unnecessary ways. Maybe I’m more aware of it now since I started using Ghostery on my desktop browsers to list (and, sometimes, block) scripts that are useless to me, but it’s still surprising how some websites are designed with a kitchen sink approach when it comes down to extensions.

Here’s to hope things like Google Analytics Site Speed and Chrome audit will make web developers more aware of the problem.

Facebook has just announced their new mobile initiative on Android, called Facebook Home.

After much speculation from the tech press predicting anything from a Facebook phone to just an update to their existing mobile app, the real deal seems to be something in the middle: a mix of new applications that work on top of any standard Android installation.

I’ve seen a lot of confusion online over what Facebook Home actually is, especially because users more familiar with other platforms doesn’t really know how the Android ecosystem works. Obviously I’m not a Facebook employee, and I have no additional information on this project other than what’s publicly known, but as an Android user and developer, I figured I’d try clearing some of that confusion out.

First, Facebook mentions Home is a family of apps. This should be a big enough clue on what the project actually is: a group of applications that, when used together, create a completely different experience on Android phones. How those applications operate is probably what’s hard to comprehend to non-Android users, or even some more casual Android users: one can easily replace core applications of the Android system, and in Facebook’s case, it seems they’re choosing to replace the system’s lock screen, launcher, and messenger apps.

On Android phones, the lock screen is the screen that shows when you first turn on your phone. On stock Androids, that shows you the time, gives you the option to unlock your phone, and on most recent versions of Android (4.2), allows you to switch to a number of lock screen widgets (called “daydream”) where you can perform certain tasks without unlocking your phone.

The interesting part is that like many other things on Android, you can completely replace the lock screen with a third party-application (with no unlocking or rooting required). And, of course, a plethora of third-party lock screen applications can be found on Google Play.

As such, Facebook is introducing their own lock screen called Cover Feed.

What Cover Feed does is replace the traditional lock screen with direct access to your normal Facebook stream, as well a list of the messages you receive on your phone. A privacy concern for many, I’m sure, but a great solution for users that use their mobile device as a Facebook device.

Some kind of unlocking gesture is probably available on that screen too. Doing so would take users to the phone’s application desktop, something called a launcher on the Android ecosystem (much like the lock screen, anyone can install a third-party launcher on their Android device, and sure enough, many such apps exist).

Facebook Home calls their launcher simply App Launcher.

The app launcher doesn’t get a lot of screen time both on Home’s launch video and on the website, but it seems to be a standard, icon-based launcher – you select which applications to see and where, and can launch them. Interestingly, you can perform Facebook actions – such as posting a status or a photo – straight from the launcher interface, which reinforces the idea that your phone is now a Facebook device.

Widgets – a powerful Android feature – are surprisingly absent from the custom launcher preview screens, which leads me to believe Facebook doesn’t want people to use them. A bold move, if true.

Finally, an integral part of the new Facebook Home seems to be their messaging application, apparently called Chat Heads.

This seems to be a mix of the user’s friends’ list with the system messenger – which can also, guess what, be replaced by third party apps. The interesting thing about this application, from my point of view, is how well it integrates with the rest of the system as a whole: rather than adopting the standard Android notification system for messages, where new messages are queued up on the notifications bar, new messages float on screen, on top of your current application. This is a feature that I know is available for Android apps, but I’ve rarely seem it used – it can be very intrusive. If done well, this is probably the best justification for the feature.

Given what I’ve observed, I believe Facebook Home is just a group of applications designed to work together in transforming the user’s phone into a Facebook device; I haven’t seem anything that indicates a custom Android build or system-level hooks (it seems to use at least one custom system hook on HTC First). Still, they just seem to be a group of beautifully well designed apps that take advantage of what the Android system offers best, as well as their interoperability, to transform a device into the ultimate Facebook client.

In my opinion, that’s the perfect solution for a platform like Facebook. The more I think about it, the more it makes sense. Rather than announcing a proprietary Facebook phone – where they would ultimately have to deal with carriers, and risk fragmenting the Android system even more – they are simply announcing a collection of applications that are supposed to run on any Android device, without artificial, bureaucracy-driven constraints. While I’m sure Facebook Home won’t be available on every Android phone – they do mention a few specific devices on their website, and they’re helping HTC ship one of their new phones with the applications bundled – it wouldn’t make a lot of sense for them to outright block users out of their new playground. They probably have system requirements in place, however; I personally believe Home will only be available on Android 4 and above, perhaps Android 4.1.

Obviously, the whole privacy discussion is a huge topic in itself, but one that is beyond the scope of this post.

For Android developers, interestingly, Facebook Home is great news. While I know I won’t install any of these applications (I don’t even have the standard Facebook app on my Galaxy Nexus), I expect a move like this to motivate some social media consumers to finally upgrade their phones. Maybe that’s just wishful thinking, but personally, I can’t wait to see Android 4+ becoming the standard on the platform.

Update (April 05): differently from my first impressions, apparently Facebook Home does have system-level hooks on HTC’s new phone, the HTC First. At least one custom system API is provided to the application: the one that makes Android notifications available to the Facebook’s Cover Feed, so it can display any system notification on its lock screen (instead of just messages). This is not a showstopping feature that would prevent Cover Feed from being used in other, non-customized devices, but it raises one interesting point: it shows Facebook is not afraid to request custom functionality from phone manufacturers, and fork Android somewhat. Whether this is good or not in the long run is another matter; developers are not happy. I’m pretty sure Facebook has other priorities in mind, however, and I can see this application being successful with its target audience regardless.

Still, Android’s feature history is also one of convergence and adoption of new ideas first proposed by manufacturers with their own custom OS chrome. If the new hooks provided to Facebook Home by HTC’s phone turn out to be a good idea, I can only see them being rolled into an official system API in the future.

Since I’ve had my first web server set up – somewhere around the year 2000 – I’ve been running tools to analyse my logs daily and generate statistics of visits such as referrers, browser versions, screen resolution, and other useful data. I have tried several different tools since then, but the one I’ve been using for most of that time is AWStats.

I’ve usually preferred that kind of tool over analytics systems like, say, Google Analytics, simply because it’s as close to the metal as you can be when analyzing web access. It doesn’t require JavaScript support on the client side, or any set up on your web pages; it would therefore detect all visits to a website, regardless of the page visited (it would include access to links that don’t exist, and detect common 404 URLs, for example) or the client’s technology.

Today I was having a look at the statistics of one of my websites to try and make sense of how many mobile users I had, and their operating system breakdown. This is what I had for OS under my (newly updated) AWStats:

This is not very helpful; it doesn’t list any mobile OS (it is probably folding them under their original desktop counterparts, or under “Unknown”).

The browser statistics fare a little bit better:

But it is still a little awkward to read; and I don’t think the “IPhone (PDA/Phone browser)” statistics seem very accurate either.

I had a look at Google Analytics’ stats, instead, and this is what I found, for OS statistics:

And for browsers:

Although the date range used in the statistics above is different, the list seem more accurate (at least for what Google Analytics has access to, which is my main WordPress install), and it lists all modern OS and browser variants correctly. And, of course, I also have advanced parameters I can add to my list (like OS version, or even device types) that are not pictured here.

What happened?

It would be unfair of me to say AWStats is just a bad, or outdated, product. But the truth is that it is still a leading log analysis tool whose results don’t come close to the ones produced by a snippet-requiring, JavaScript-component-based tool like Google Analytics.

Despite being closer to the metal, it seems to me that log analysis tools are at a disadvantage simply because they don’t have as much access to the client machine as a JavaScript-based solution does. Maybe what’s at fault is their reliance on nearly useless user agent strings, and while I do believe AWStats could do better in that regard (I believe it’s detecting a lot of false browser matches), it’s also true that they can’t use some small JavaScript code for better browser type and version detection – which, I’m assuming, Google Analytics does for increased accuracy.

Log analysis tools still have their place for detecting, say, 404s or direct links to raw assets (like images) coming from third-party domains. But for page access and audience analysis, it seems their days are long gone. They died a while ago, but I suppose I only noticed it now.

This morning I was thinking to myself, “I wonder if you can create models dynamically in Unity in order to develop a game with procedural assets”. A quick search led me to Unity’s reference page for the Mesh object, and to my surprise, this is the description of the object:

A class that allows creating or modifying meshes from scripts.

Meshes contain vertices and multiple triangle arrays. See the Procedural example project for examples of using the mesh interface.

The triangle arrays are simply indices into the vertex arrays; three indices for each triangle.

For every vertex there can be a normal, two texture coordinates, color and tangent. These are optional though and can be removed at will. All vertex information is stored in separate arrays of the same size, so if your mesh has 10 vertices, you would also have 10-size arrays for normals and other attributes.

And then it delves into code examples of the three most common tasks one would use a Mesh for (building a new mesh, modifying vertices of a mesh, and replacing mesh triangles). It’s simple and short, but it probably answers many of the questions that brought a developer to that particular reference in the first place. It’s not a full tutorial – and it doesn’t have to be. In fact, in many cases, just reading a short snippet of code is enough to understand the whole deal behind a class, method, or property.

Contrast this to many of the platform and framework references that are out there that simply list properties and methods while stating the obvious. When you write your documentation to human eyes, and you want to be helpful, you end up with something like what Unity has done.

Much has been said about testing your Android applications on several different devices , and several different services exist to test deployment of your application if you want to make sure it runs on certain devices. But in my opinion, nothing beats releasing beta Android applications on Google Play.

To illustrate what I mean, a couple of days ago we released a version that had code similar to this:

public boolean shouldOverrideUrlLoading(WebView __view, String __url) {
	String myPrefix = "internal://getDataAndDoSomething?data="
	if (__url.substring(0, myPrefix.length()).equals(myPrefix)) {
		// Called fake protocol, so grabs data instead
		String data;
		try {
			data = URLDecoder.decode(__url.substring(myPrefix.length()), "UTF-8");
			doSomethingWithTheData(data);
		} catch (UnsupportedEncodingException __e) {
		}
		return true;
	}

	return super.shouldOverrideUrlLoading(__view, __url);
}

This Java function intercepts URL calls executed on an Android WebView, such as when the user taps on a link to a different page. It is displaying a normal web page that may have a link to a hard-coded URL – the one that starts with “internalProtocol://”. Thus, when the user taps links to that URL, my code should grab the command and data passed, do something with it, and then return true – meaning that the WebView itself won’t try to do anything with it, like opening a new page. The tap is essentially intercepted by my code (taps on all other links should behave normally; this same WebView is used for visiting normal websites).

Can you spot the problem with the code?

One day after the application was released in the wild, I started seeing a few error reports on Google Play’s Developer Console (in case you don’t know, Android applications normally send a crash report to this console, including a stack trace of the error). They looked like this:

java.lang.StringIndexOutOfBoundsException: length=31; regionStart=0; regionLength=37
	at java.lang.String.startEndAndLength(String.java:593)
	at java.lang.String.substring(String.java:1474)
	at com.mypackage.MyApplication.activities.web.WebActivity$2.shouldOverrideUrlLoading(WebActivity.java:170)
	at android.webkit.CallbackProxy.uiOverrideUrlLoading(CallbackProxy.java:231)
	at android.webkit.CallbackProxy.handleMessage(CallbackProxy.java:331)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:137)
	at android.app.ActivityThread.main(ActivityThread.java:4697)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:511)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:787)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:554)
	at dalvik.system.NativeStart.main(Native Method)

Can you spot the problem now? It made me feel really stupid once I saw the stack trace.

The problem is that line 3 – the one that checks whether the URL starts with the internal prefix String – is trying to compare the prefix with a String of a similar length extracted from the URL. If the URL is shorter than the prefix, however, it will fail, since there are not enough characters to satisfy the substring() call (to my defense, I wrote the code in a hurry, trying to replicate a pattern I had from my ActionScript days).

The fix, of course, was simple. The somewhat convoluted prefix check above can be replaced with this new line 3:

public boolean shouldOverrideUrlLoading(WebView __view, String __url) {
	String myPrefix = "internal://getDataAndDoSomething?data="
	if (__url.startsWith(myPrefix)) {
		// Called fake protocol, so grabs data instead
		String data;
		try {
			data = URLDecoder.decode(__url.substring(myPrefix.length()), "UTF-8");
			doSomethingWithTheData(data);
		} catch (UnsupportedEncodingException __e) {
		}
		return true;
	}

	return super.shouldOverrideUrlLoading(__view, __url);
}

This is a problem you would hardly catch on any testing – no matter the number of devices you have been testing. It was made possible by having someone testing the application in the wild and an error being reported by the developer console (and also only because some specific users of this application were redirected to a very short URL based on their account name).

I wrote the fix and released an update to the application – with other fixes and features rolled in – the same day.

This may not be the best release approach for all applications; some times, it makes more sense to have a very solid release rather than expecting your users to act as beta-testers during the first couple of weeks or so of an application release (since you risk alienating users that run into showstopping bugs). However, if there’s something to be said about the Google Play publishing model, is that it offers developers easy discoverability of errors – or at least, of errors that generate actual crashes – and fast reaction times for fixes. And while the number of different devices and configurations one has to test may negatively impact development time, it’s good to know that some more positive features are in place too. This is some times overlooked when compared the Android ecosystem to the other players in the mobile field.

One of the best things to come out of CES 2013 was Qualcomm’s bizarre attempt at giving a keynote. Here’s a video of the highlights (which are also covered in this article at The Verge):

Other than the standard amount of cringeworthy moments – as a gamer, I could not stand more than 2 seconds of Tornado92 – what really pushed my buttons is the company’s attempt to create catchphrases like born mobile, or worse yet, Generation M (which, I suppose, is another way to say Generation Z, or something). They probably feel that if they create a buzzword and repeat something often enough, it’ll stick.

Coming to think of it, Fast Company did the same thing. The magazine coined the term Generation Flux in a decent article, but their insistence on using this term on every issue from that point on makes me believe they have something at stake in spreading its use. I am assuming they have registered the term, and much like the disputes over the term Web 2.0 (where’s that term now?), expect it to get some traction so they can bank on it or something.

My opinion? It’s OK to come up with a term from time to time, but pretending it’s a common term only makes you look like a fool.

Last weekend was the 25th edition of Ludum Dare, the online 48-hour game development competition. My entry was called Fry Fleshlings Fast, a somewhat constrained effort due to time restrictions (but still a fun effort, of course).

I have just published a post-mortem about its development on Ludum Dare’s official blog denoting what went right and what went wrong, and what I’ve learned from it.

Finally, of course, you can also play any of the thousands of other game entries created for this competition. Some of those are really, really brilliant. From our very own Firstborn, Rick Van Mook and Mike Roushey, both Ludum Dare veterans, also had awesome entries of their own.