Back when I was a paperboy I started out being pained by the whole ordeal of lugging all those papers around and running up and down all those stairs. Can you imagine dragging a cart up and down hills and running up and down stairs during the Norwegian winter? Jeez. With time though, I was seeing pretty sharp benefits. My physique got awesome (holy hell do I believe in the Stairmaster now), I was making my own money, but best of all, I got extremely skilled at manipulating newspapers one-handed. From rolling them up with a figure-8 flick of the wrist, to throwing them long range horizontally like a Frisbee to softly land right on the recipient’s doormat, every new delivery was like a challenge to figure out the longest possible distance from which I could hand them the paper with the least amount of energy.

Screw the money. Feeling that I was not only mastering a task but actually feeling like I was making innovations in it were the best memories from running all those paper routes. To this day, I think the best thing you can get from anything is that sense of mastery. This is partially why video games that are poorly balanced at higher difficulties piss me off so much, because they’re denying the player the chance to master something that initially feels insurmountable; The best thing you can possibly get from video game mechanics. It’s also why I have a deep respect of anyone doing any job that put in a little extra effort. I watch garbage men and McDonalds register workers and it makes me just warm inside whenever I spot a new “technique” someone has come up with to make their job easier.

I’m a firm believer in programming as an art form. It’s engineering with a sprinkling of genuine authorship. I think a developer’s individual touch is as important as the resulting product, so seeing students be taught Java conventions drives me up the freaking walls; Isn’t the whole JOY of programming the manipulation of language to describe a complex structure? Coding, to me, is about individuals working together, and when I join a team I will bring my individual quirks with me; My naive belief is that individuality will strengthen the group and the project simply by virtue of individuality spawning creative mastery in a way that schooling won’t spark.

I have some features as a developer that I’m very proud of. The biggest pride is that when I write a UI, dimensions are always simply parameters. I feel an itch every time I type in coordinates or rectangles literally. My UI will always flow to the size of the canvas; I make no assumption at a locked resolution. 80% of the time this isn’t very important. But sometimes there is nothing more comforting than knowing that the form factor of the screen displaying the product can comfortably be an unknown variable.

Anyone else out there have developer “quirks” or habits they feel proud of? Specific facets of your “developer’s mastery” you feel makes you a definitive asset?

I have a certain disdain for Apple’s policy of developer lock-in, as well as their entire [blahblahblah catch up with this with me over a beer sometime], so for me the idea of investing so heavily in iOS development was never of any interest. I’m not enchanted with the philosophies that drive objective C, being firmly in the C++ camp, so iOS “development” for me has been limited to design discussions and project planning with my friends who do enjoy working on that platform. I want to stress out that while i think Apple can [Escher-like construction of interwoven expletives], their hardware is good, and their design philosophy is excellent. I’ve been an iPhone owner since the 3GS, and I’ve played a surprising amount of really good games on the platform. It’s solid.

I haven’t played a lot of good games for Android. It doesn’t feel solid.

Which is better?

The discussion invariably becomes a “which is better” question: Should I get an iPhone? Should I get an Android device? From the perspective of one “indoctrinated” to expect Apple-level polish at the expense of features, Android’s good sides will be invisible because you don’t think to look, and its bad sides will be staring you in the face from the get go; Android as an operating system simply feels less responsive. So obviously (literally), iOS is the stronger platform, right? Given the presumption that every Android device is an iPhone competitor, then you may have a strong argument.

However, at this junction, being a Flash developer with a new found fascination for Java and a better understanding of the Android platform, I don’t find myself able to make such a direct comparison. In fact, I think it’s practically invalid; The definition of an “Android device” at this point is incredibly open. Your application, in a single deployment, can theoretically target everything from a tiny-screened uncomplicated Sony Ericsson Xperia X10 Mini to the Samsung Galaxy Tab. You may expect to have access to a joystick, hell, with the Xperia Play, you can expect dual analog sticks. You can assume a single touch screen, or any sort of multitouch input. You MAY be working on a phone.. You may be working on the dashboard of a car.

Android is a very wide canvas, and I feel the idea that Android and iOS are implicit competitors is a misunderstanding.

I believe that an Android developer, to be successful, has to reach a very wide audience, not only in terms of software appeal, but also in terms of hardware optimization; The design must pre-empt a wide array of edge cases. It’s a complicated, arduous task, but the reward, I feel, is that same fuzzy warm feeling I get when a Flash application’s UI flows with the window size. The feeling that your bases are covered. The feeling that you’ve engineered a flexible machine.

And my real argument here is that designing for iPhone with the assumption that you can port painlessly to Android is a grave mistake.

Scale down, not up

At this point, having written an Android app that scales to a subset of devices you are happy with, what’s stopping you from porting to the iPhone with a minimum of change to your design? iPhones have a couple of configurations and little to no change in input capabilities; The biggest in recent times is the addition of the gyroscope with the iPhone 4, easily omitted for the 3G/S at the cost of fidelity, but no actual capability lost. In contrast Android devices have many dozens and more coming, and few input capabilities you can count on.

Being a Flash developer, I’m arrogantly going to assume you are one as well: You are already versed in designing applications with a variable canvas size. You are already used to optimizing to overcome crappy end-user hardware. Designing for a range of Android devices that are comparable to the iPhone will let you write in a language very similar to the one you know, typically with much better performance than you’d expect unless you are forgetting your optimizing lessons. Summary: You already know how to do this shit!

When your application is done and deployed, take it to someone else to get it ported, or use the porting as an excuse to learn iOS dev; Java is a very generic language, the API is uncomplicated enough that parallels can be found on most platforms, and if you are a game developer in particular, you’ll barely be using any of the OS-specific integration anyway. Port DOWN to iPhone, which is the more complicated platform but with a better known configuration. Don’t write your iOS application and expect your design to work within the flowing canvas of the Android platform, because they simply are not the same. But the iPhone is in actuality the lowest common denominator.

I see too many people wanting a cross platform framework for smartphone application dev to, I guess, “make the most money”, and some have found success with stuff like Corona. But this is a compromise layered on a compromise. I personally could never feel comfortable with such an attitude, because it not only undersells the platforms you are targeting, but it compromises your design in a way I feel is unnecessary. It also locks you into yet another platform, with another language. How low are you willing to go for a quick buck, guy?

Fun times!

My first Android game targets the Galaxy S in particular. It’ll be free, and will work wonderfully on all comparable devices. It’s a great learning process. 50fps multitouch accelerometer gravity party-time! It will also be ported to the iPhone when it’s done and tested. That’ll be programming and optimizing work. At this point, I’m having fun just playing.

If you’re a Flash developer in doubt, for what this is worth, I really must recommend getting a decent spec Android phone and getting into developing for it before letting Apple shackle you to their platform in a way that denies you flexibility of deployment. Working natively on a device like the Galaxy S is a total joy; This thing is so full of fun sensors and fancy junk, it’s kind of mind-blowing how little you must do before you’re integrating it all into an experience. And you can take that experience to iOS later, when it’s ready for it.

Click for nice sharp pixely bits

Today was the day I finally mustered the courage to push the Doomsday Console 2.0 update to googlecode. It’s not, er, particularly 64 bit. If you get the lame joke in its title, we should have beers. It is not finished by any stretch, but it is mostly feature complete, and in the coming weeks I’m hoping to be polishing it and fixing it up to the point where you can stick it in your games and apps without worry.

It’s got a more elaborate UI, featuring a foldout panel on the left that gives you tabs containing the display list as a tree view, and a matrix of properties on the current selection. More tabs are planned, but damn, need to make these two bug free first; Handling write-only accessors is a really weird problem from a UX point of view. The aim is to marry two often used features of the previous version; the ability to select display objects directly and interacting with their properties, with a simpler method of access.

One of my favorite things about this UI is how it’s greedy for space but relinquishes it as sections become too small to be useful, and fields and components hide and reappear as the console is scaled. There’s also scrollbars now. WILD. So much new small stuff!

Oh, and we’ve shifted the license to MIT, so it should be easier on your clients as well.

I want to stress that this isn’t the final release, but rather us making the development public. You’re free to experiment with the source, of course, but I personally wouldn’t recommend using it in live projects of any importance, or at least jump in expecting a solid product; It’ll get there, but it’s not there yet. Enough apologies. I think this thing is awesome

Grab the swc or join the bug smashing at http://code.google.com/p/doomsday-console-64/

Me + Furu Systems = Yay!

Super stoked about this. I’ve joined forces with two colleagues from previous workplaces who are also freelancing, to form a development and design collective; Furu Systems. These are super talented guys that I’ve known since high school, we’re all really keen on our respective fields, and I’ll be moving most of my business through that name from here on.

I’ll be mirroring most of my technical writing on our (currently blank) blog, as well as do in-depth post mortems of projects whenever possible. I hope to make the work process itself sort of open source, to make sure lessons are learned and shared.

If you’re interested in working with me / dudes that are rad, keep www.furusystems.com in mind.

But this post is not about complex patterns. It’s about a very simple one; The first one I learned that used several classes as well as interfaces. Somewhat infamously at this point, I’m notoriously fond of interfaces and the freedom they offer the developer -which is ironic, because they are about limitations and requirements- and if you want to trace that love to its inception, the “finite state machine” is it.

What is a state machine?

A state machine is a complex (but cool sounding) term for an object that can be in one of a limited selection of states. The typical example is the light switch: It can be in two states; on or off. The light-bulb can be lit or dark. The power can be up or down. Maybe you have poor wiring; the power can be fluctuating as well, a third state. In fact, as a Flash developer, you have probably been working with states and finite state machines ever since you first started playing around with the Flash IDE.  MovieClips are nothing but state machines where every frame is a state. A MovieClip of a walk cycle animation contains a state in which the character’s left foot is touching the ground. It can also be in a state where the left foot is lifted.

If this sounds like I’m overstating the obvious, I really am. A basic state machine is an exceedingly simple concept. Where state machines begin to shine however is in the concept of “transitions”.

What is a transition?

A transition is, as you’ve guessed, the proceedings that take place when a state machine changes its state. We don’t need transitions for a state machine to fulfill its purpose, but they are very powerful. A rule that is important to reiterate is that a state machine can only ever be in one state, and it’s this rule that offers one of the core benefits of the pattern; A sense of clarity.

(In this way programming is like maths to me. You know that 1+1=2, and that is a fact of the universe. Doesn’t it feel great to have such a solid grasp of reality?)

So given that a state machine can only ever be in one state, how would we change that state? Let’s go with the MovieClip example for now. Let’s say that MovieClips don’t exist, and we have to design their logic.

Our animation consists of a set of states, each describing a frame, and for a frame of animation the concept of a transition is simple; you simply tell the MovieClip to set its current state to another indexed frame, and the state changes, bam. Right? But even this simple state change has a transition. The previous frame is removed, and the new frame is shown. This transition could be handled by the state machine itself (in this case, the MovieClip), or by the individual frame. In the case of a dumb MovieClip with no logic attached to frames, our hypothetical reinvented MovieClip could handle this state transition just fine:

Let’s assume our frames have content however. Let’s say the first frame has a video player, and that the next frame has a sound to play. The video should stop, and the sound should begin playing. The state machine, in this case the MovieClip, doesn’t need to know exactly what is contained in the frames, but it does need to tell them to shut down and initialize. Again, not hard to imagine.

And voila, we have described the state machine pattern that I have become so fond of, in its entirety!

Applying the state machine pattern

When I first started reading about artificial intelligence for games, state machines were introduced very rapidly. AI behavior could be described as a graph where each node was linked to possible states it could transition to. For instance an AI in a sneaking game could be defined by a graph such as this:

Each box is a state the AI can be in, and the arrows represent possible transitions, each defined by the states themselves. The framework driving the AI only really needs to keep updating the current state, and let the logic of each state define the behavior.

I’ve written a primitive version of this AI using the state machine pattern, defining a simple autonomous agent that can move around the world, and a set of states that define its possible behaviors. Let’s take a look!

Our Agent is a small, overconfident, myopic black arrow. He will hang out for a bit, then wander around at random, pausing once in a while. When the mouse cursor is in front of him within a certain radius, he will chase after it. When he comes close however, he’ll freak out and run away until he reaches a safe distance. Then he will resume his normal behavior again.

This behavior is defined by the following states

Each state implements the IAgentState interface, which looks like this:

The IAgentState interface

This interface specifies 3 methods to be called by the state machine, each taking a reference to the state machine itself. I like to work on this reference because AI states can be treated as largely abstract; It’s not hard to conceive of several different types of agent needing the wandering behavior, and it is nice to be able to reuse the same behavior instance. Let’s look at the Idle state to see what this means.

The Idle state

The wander state

At this point I am sure you are getting the idea; The states themselves contain no data, and are entirely dependent on a state machine instance to interact with. In this case, it’s almost like a set of template methods that are being swapped out. The nice thing here is that instead of creating a ton of state objects for every agent, we can reuse the same states. Click the stage in the above swf to create new agents, all using the same static states.

Finally, we’ll look at the state machine itself.

The Agent class

As you can see, we are still applying the same theory as in our MovieClip example; Close what you had, open what you’re getting, and since we’re doing realtime stuff, update what you got. I’ve put up the source for this example, in case you’re curious to take a peek.

Summing it up

State machines are mechanisms that have their behavior defined by a known set of states. Knowing this, you can easily jot down your application as a state graph and use the state pattern and a rudimentary state machine to throw together a click through for instance, while maintaining scalability. I’m just scraping the surface. State machines have a huge number of uses, from managing visual states, to choosing which game state to execute, such as the title screen, leaderboards, game loop etc, to state machines creating new dynamic state machines during parsing algorithms. States themselves can very well be state machines.

I hope I haven’t bored you to death with my rambling. I’ve used this pattern and variations of it for a wide range of projects. It’s a safe bet for prototyping, almost indispensable for game development, and super stupid easy to pick up. Thank for your reading

Just a quick post to point out how freaking sweet the AS3 Dictionary utility is. They have rapidly become my favorite data structure for the simple reason that they allow you to create a fast hash map of sorts of any key/value set in a way that lets you integrate more elegantly with garbage collection.

The glory of hash tables of course is O(1) lookup speed; The ability to see if an object has been stored and to retrieve it without first iterating over the collection or doing some other search.

The wonderful thing about Dictionaries is how they simplify this process. You don’t need a hashing function anymore: To collect a set of objects, all you really need to do is use the same object for both key and value:

This nets you the O(1) lookup, collection iteration through for..each and for..in, and the sexy, sexy ability to declare the Dictionary “weak”, meaning it won’t stop its key from being garbage collected.

Weak dictionaries are a cornerstone of the DConsole for performance, and to make sure inspecting an object wouldn’t create a strong reference to it. They are also used throughout the autocomplete solution in the form of ternary trees.

Dictionaries let you approach object collections of any time with ease and elegance. I strongly recommend you play around with them if you haven’t already.

Look out for an upcoming post detailing the Notification framework used by Doomsday Console 64, as it offers an excellent use case.

So what would I do with a full hour? The mind boggles! Let’s brainstorm!

1. Hacking your app with AS3
The obvious one, considering my pitch concerned the Doomsday Console, ostensibly a hacking tool. Flash is super flexible, and I’d love to do a session on wringing stuff out of AS3 you wouldn’t expect to be easily doable.

2. Why OOP is the absolute bomb and everyone should be head over heels in love with it
OOP is why I’m a developer. Not because I want to create objects all day (oh but I do), but because it is what enabled me to actually fall in love with programming in the first place. I have written a post on this in the past, and I’d love to do a beginners/for designers session on how OOP allows us to be free, comfortable and creative with our language, even though we are still telling a computer where to put bits.

3. Stop trying to make the internet boring!
This is the one I want the most to do I think.. I’ve written a huge rant on this topic in the past, and I still burn for it. Nerds and businessmen are trying to steal the internet away from its rightful owner – the people – and we have to stop them by getting fucking crazy up in here! An hour long discussion/rant paired with content dug up from the weirdest bits of the web.

Any of these sound interesting to you? Then I’d be honored to have your vote this year

One of the things that have bothered me about them though is the necessity for adding boring boilerplate code, such as the ubiquitous getInstance() or its younger brother, the static instance getter. For projects using a lot of singletons, such as states for state machines, this is the most boring shit ever.

Enter the instance map.

Short and sweet. The difference is you no longer request your instance from the class itself, but from this manager, using the class type as the argument. If one has been created before, you get that instance. If not, a new one is created and cached.

Downsides are obvious; You lose some benefits of strong typing (easily overcome), and the verbosity of your code increases quite a bit;

Benefits are grand however. *Any* class can be handled as though it were a singleton, you maintain a localized cache of all singletons making disposal fast and easy, and the contains() method allows easy testing to see if a singleton has been instantiated or not.

I’m quite enamored with this approach. How do you guys feel about it?

If you’re wanting to listen to MOUSE_DOWN events from an AIR HTMLLoader, and want any and all mousedowns, not just HTML link clicks and the like, simply use the event’s capture phase:

Bam, problem solved. I read some posts online about this issue and no good solutions, so here you have it

Jamie’s interview cements the notion of a duct tape programmer; A developer who understands that in real life, the work is WORK, and problems need to be solved pragmatically for deadlines to be met, paychecks to be cashed in and children to be fed. He’s an autodidact, he has worked with people “smarter” and “dumber” than himself, but none of that fazes him. It’s work, and he does it well. The goal is to finish something that works according to expectations.

Reading this interview I personally felt a huge relief. I’ve worked with others from designers who can barely understand why curly braces exist to having my code reviewed (and panned) by university computer science graduates. On one end of the spectrum, I am a wizard, where I enable things others can’t even understand is possible. It feels fantastic. On the other, I’m a heathen. Why all these singletons? Why no dependency injection? Why not this? Why not that? “Over there”, I don’t know what’s what.

But, you know, for the most part, I simply do what is necessary to meet the demands within the alotted time frame, and to be able to adapt quickly when changes are inevitably requested. It makes for code that is often ad-hoc and cobbled together. I have never regretted this; My work can turn on a dime. I refuse to let someone geekier than me kill my personal joy in programming; Creating things.

Compared to Zawinski, Crockford and Eich are almost polar opposites, and their interviews, side by side, read like an argument and its rebuttal. Crockford is, from what I can tell, a programming “geek”. We should all know the geek-nerd-dork-dweeb venn diagram by now:

Crockford and Eich disagree strongly on the ECMAScript 4 specification, which Eich designed in committee with Adobe and others. ECMA4 is, as we know, ActionScript 3. Crockford spends his interview first acknowledging the problems of ECMA3 in its JavaScript implementation; Reliance on a global object and resultant issues with the security model. Beyond that, JavaScript is apparently a godsend by virtue of being a true “lambda language”.

Let’s digress for a minute or two.

“Lambda”

If you’re not familiar with this incredibly geeky term, in terms of ActionScript and JavaScript a “lambda function” is best understood as a function that isn’t declared a class or instance function but rather kept in a variable and passed around, or just called right then and there and then left to garbage collection. Here are some examples:

As you can guess, lambda functions are hugely powerful. Passing references to functions around with adjustable scope is a fantastic tool, and though I personally feel like anonymous functions drastically reduce the readability of the code and introduce complexity where reusability should be preferred, I still use them from time to time.

Back when I first started learning object oriented programming, it was in Flash 5 ActionScript 1, which adhered closely to ECMA3. I wanted to learn game programming, and here was a language that didn’t offer almost any of the terminology every book and article I read was referring to. Classes, inheritance, interfaces, none of that. Flash developers struggled to adapt to a market that demanded larger and more complex applications in a language to which the closest parallel was one that barely could scale an image or change the value of a form field.

The Flash community, like the JavaScript community, became home to some seriously clever hackers. There was a lot of crossover as coders in either camp struggled to wrangle some order into the languages they were bound to. Soon, I was taught how to create classes in Flash, but our classes were simply anonymous functions.

This approach necessitated judicious understanding of scope, and resulted in more this-keywords than you ever see in modern programming. Yet we had no inheritance. I don’t even want to write about the boring, convoluted boilerplate code we had to write time and time again to approximate a simple “class Foo extends MovieClip”. Everything that now is nice and orderly was a hack then.

Of course there were boons still. We grew accustomed to manipulating the prototype chain, by which we could give any object new properties by way of manipulating its prototype. For instance.

In retrospect, was jerking off the prototype chain worth the syntactic mess we were dealing with? Personally, I would rather forget those years. Learning was slow, development was convoluted, and mastery always seemed far away. It was difficult to settle into a comfortable groove. On larger projects (I worked on an AS1 MMO at one point) code maintenance was almost completely unbearable. Reusability was a joke.

Long story short, 2 years into my career as an ActionScript developer, I had an ulcer, and I had gallstones the size of my thumbnail (bybye gall bladder). The stress and discomfort associated with AS1 development made me swear off the industry altogether at one point. It took nearly 6 months to reel me back in. Thank god I was met with AS2 and concessions towards traditional coding practices. When AS3 landed, my world snapped into place. Now I could work. Thank you ECMAscript 4.

Mommy, don’t make me go back there!

Reading Crockford’s arguments for ECMA 3.1 as he simultaneously decries the dominance of C++ over Eiffel is terrifying, simply because the man has real power. He’s a JavaScript evangelist (of all things) who, to my ears, sounds more enamored with the technicalities and THEORIES than the real world applications. He’s clearly intelligent, clearly obsessive, and clearly out of touch with the fact that thousands of people make their living using and loving a programming language he condemns for its “complexity”.

I’ll reiterate my strong respect for the JavaScript community; They have taken a language that literally made me cough up blood and have to give up fatty foods and wrangled it into shape with frameworks like jQuery and Prototype which finally allow developers to do real work. But this doesn’t change the fact that the fundamental language was painful enough to necessitate this sort of wrangling. Hell, jQuery syntax barely resembles JavaScript. As CSS3/JS/HTML5 looms ahead, the notion that the future of the base language is controlled at least in part by people who actually LIKE the bits the community has done its best to override. As a consequence, the Flash community as well are collateral damage as Adobe need to defend their “flawed” language.

I can’t recall the ActionScript community complaining about the complexity or verbosity of the language itself. We have our issues more with the lack of complexity, such as lack of abstract keyword, or in some cases with the verbosity of the flash framework, ie addEventListener, but are we really bothered by how “complicated” it is?
Anyone wanting the loose anarchy of AS2 can switch off strict mode and prototype and dynamic type and lambda the shit out of anything all they want.

So the argument seems to be then that those of us enjoying the complexity and verbosity are somehow wrong.

And that’s the crux of the problem for me. Programming languages should be judged by their merits, not their subjective aesthetic qualities.

After years of ECMA4, and a blooming, prosperous Flash community being the testbed for that language, how can we call it wrong?

If any of you have been following our googlecode repository, you have probably noticed a lack of significant updates . There is a simple reason for this; We are giving it a pretty serious overhaul, so much so we have decided to move development to a closed repository until we feel a publication of the new codebase is worthwhile. Central to 2.0 is a new emphasis on usability. I’ll use this as an excuse to effectively re-announce the Doomsday Console, and outline the strategy we are undertaking henceforth.

What is Doomsday Console 2.0?

1. A logger

The Doomsday Console is a hidden debugging utility you can easily include in your Flash or Flex application. At its most basic, it offers an output text field for logging/tracing purposes. You “print” to this field with a static method. The print method takes a number of arguments, endowing printed lines with various functionality. For instance, you can simply print out a text message, but you can also color code it, or make it a hyper-link of sorts to related objects, or even the method that caused the print to begin with. Printed messages can be filtered by source, color, arbitrary flags, and searched quickly. With the DDConsole, a printed message is no longer just a bit of information; It is a bit of information you can respond to, and use as a basis for further runtime investigation.

This is the first pillar of the design of 2.0: A context-aware output window of user-configurable granularity, allowing any number of appended metadata of any type.

2. A command-line interface

The Doomsday Console is a command-line interface with a simple syntax, robust self-documenting auto-complete and persistent command history, ensuring every time you rebuild your app, you can continue right where you were. Built-in console commands nets you application introspection, allowing you to traverse the application structure much like the file system on your computer, calling methods with variable arguments, altering exposed variables, and even instantiating new objects and altering the display list.

New commands are easily created through a static “createCommand” method, allowing you to call any method in your application from any context; Invaluable for on-site debugging or game testing. Through custom commands, you can easily create full command-line applications; Excellent when developing remote APIs or networked apps; For instance, an IRC or Twitter client can easily be thrown together with no other front-end whatsoever.

This is the second pillar of the design of 2.0: Direct, responsive access to method testing, and a comprehensive set of tools for navigating and altering your application at run-time. The previously overly verbose syntax is altered significantly in 2.0, incorporating a proper lexical parser to allow for a more natural, robust ECMA-style syntax. If you’re familiar with JavaScript, there isn’t much of a learning curve.

3. A scalable collection of visual developer tools and gadgets

In its early development, before going public, Doomsday Console was a collection of every single visual utility I ever wrote for myself. This included measuring brackets, line guides, wireframe drawing tools, “controllers” letting you visually access all properties of a visible DisplayObject, graph charts and the like. The intent was to allow a developer to test out visual changes before committing them to code

For 2.0, this sort of functionality is separate and defined as “plugins”. Plugins implement an interface, and are mapped as singletons through a static method. The intent is to create a framework where anyone can design any sort of visual utility, and we can include any old kind of rambling coolness people create without “polluting” the core functionality. This also introduces a level of scalability; Prior versions of the console bloated with these utilities, that while useful to some were largely useless to most. Conceivably, this allows for a minimum configuration of the console that shouldn’t impact the size of your application as dramatically as it has in the past.

4. Discreet

The Doomsday Console has been engineered from the start to carry as small a performance footprint as possible. When hidden, it doesn’t actually do anything at all. The console can be locked with a number of methods, including key sequences, passwords or keystrokes, ensuring it will remain hidden from end-users until needed, allowing you to go live with it embedded with no fear of security hazards. All references stored by the console are weak, and no events are ever dispatched by default.

5. Neat lookin’

Spartan and clean but with an eye for detail, the Doomsday Console should sit pretty on any application. Thoroughly themeable, you can configure it to fit with your company profile should you see fit.

6. A hacker’s dream

The Doomsday Console offers near absolute control of your application. Built-in commands allow you to carry out extensive changes to an application at run-time, from creating graphics and assigning event listeners to creating and positioning new text fields with new textformats. Strings of commands can be run as batch-files, allowing a form of monkey-patching.

Who would dig it?

Game developers, developers of on-site applications such as kiosk apps, visualization or art installations, Flex RIA developers wanting extensive runtime debugging utilities. Anyone with a love for Terminal or CMD. Anyone tired of making black box sprite buttons or stage click handlers to test methods. Anyone tired of the compile-trace-rewrite-compile loop.

When can you get it?

You can grab 1.0  of the console and do most of this already. Go get it!
2.0 will be in concentrated development throughout July by a team of 3, and we’ll be publishing in anticipation of Flash On The Beach 2010.

My session will be about my ongoing Doomsday Console project, or more specifically the next iteration of it (which is under super secret development by TOP MEN). I’ve tried many debugging tools before but none have helped me as much as the DConsole has. It’s traditionally a very tough sell though. Hope to build some more interest and perhaps cause some thinkings about writing your own tools to enhance your workflow?

3 minutes.. My presentation will need TDSI.

As a developer, I’m utterly blown away that this thing is running in the plugin as well as it is. It’s a massive feat in terms of engineering.

As a musician however, I find it absolutely infuriating to actually use, to the point where I literally can’t even grit my teeth and brute force my way through making something musical in it. I find it absurd that I am being offered such a suite of interesting and useful tools, yet interface choices and device design niggles consistently impede my progress.

I need to stress that I am a huge fan of the research and work being undertaken by these guys, and I think what they’re doing is absolutely integral to the future development of the Flash platform.

A little background.

I’ve been using various software sequencers for about 20 years, from ProTracker to Screamtracker, Emagic MicroLogic through Cubase, PlayerPro, Rebirth, Fasttracker 2, MadTracker, Modplug Tracker, Reason, Ableton Live and now most recently having landed firmly on Renoise. If there are any specific features of a sequencer I am after it is accuracy, speed and clarity, which so far has meant returning to trackers time and time again. In other words, I am partial to a keyboard-driven interface, and I don’t much like scrolling around a window to find what I’m after.

As for hardware and devices, I currently own and use a Korg R3 and Z1, a Nord Modular G2, a Nord Micro Modular, a Waldorf Blofeld and, oddly, a Theremin. I have been using VST plugins for about as long as they have existed, and I have used both PureData and Max MSP; I am used to cable spaghetti, both virtual and physical.

Musically, I’m much more of a “tinkerer”. I produce few tracks, but I experiment and create patches and loops near constantly. Over time, I’ve become very interested in synthesizer and sequencer UI.

Now, I’m well aware that the Audiotool is not intended to replace any of the above mentioned products. It is an educational community oriented tool that offers a sizable subset of synthesis and sample based functionality in the context of a modular “studio” environment. It opts for a “physical look and feel”, presumably to inspire play and lower the level of abstraction.

So take the following list of issues with a big pinch of salt; These are my personal geeky gripes, but I still feel i should get them out there.

Effect unit GUI design

This is my biggest gripe overall, and it may be the most personal; I have no idea why these devices have to take up this much screen real-estate, yet use so little of it on actual GUI, only to maintain a kind of pseudo-simulation of real world devices. Some devices are more guilty of this than others.

For instance, the Kobolt 16 channel mixer pulls it off just fine.

I’m of the personal faith that virtual knobs are a deadly UX sin, being much more in favor of sliders or even value input text boxes, but in the context of a device with this many controls, knobs actually allow for more GUI in less space. The device is obvious and well designed, it looks physical, and uses its real-estate effectively.

However the effects are where things start going downhill.

These things make me absolutely crazy. You look at that “effect pedal” and you think hey,  even if it’s a 150×256 area used to show a total of two knobs and a button, that’s not THAT bad is it?

This is a single effect chain for compressing, filtering, driving, low gaining and delaying a single drum instrument. Actually setting it up, connecting it and using it is no effort at all, but it takes up a chunk of workspace larger than a 16 channel mixer, and 60% of that lost space is just a row of big on/off toggle buttons. The pedal metaphor simply falls flat on its face here. Imagine having 8-9 of these chains in addition to your actual instrument devices. You are constantly scrolling around trying to orient yourself as to what goes where. The teensy tiny pixel text labels on the tiny knobs are like a slap in the face of UX conventions as well.

Suggestions:

• I strongly suggest ditching the antiquated pedal metaphor. Redesign the devices to sit more comfortably in a row, taking up only the space they absolutely require. Alternatively, introduce a Reason-style combinator unit.

Modularity and the Splitter device

At the heart of Audiotool is the user’s ability to connect devices through a series of inputs and outputs. Devices are placed on the “table” by drag and dropping instances from a bank. To get audio output from a device, it must be connected to the audio chain by way of cables, which are created by dragging from a port to another. This sort of setup is quite common, used in visual programming languages like PureData and Max MSP, but also in virtual modular synthesizers like Native Instruments’ Reaktor or the Nord Modular series of synthesizers. Compared to its peers, Audiotool’s implementation suffers tremendously.

Ports are categorized into inputs and outputs. Logically, an input can only have one source, and this is enforced. However, outputs are only allowed one connection, forcing you to set up a series of splitter/merger devices. These devices have idiosyncrasies of their own, for instance splitting an input into three outputs, specifically. So if you need 4, you need to chain one of those outputs into a new splitter. Each splitter takes up another chunk of screen space for seemingly no reason at all; I have yet to encounter an instance where I actually needed a complicated signal mixer for a split signal, and I’m not talking about Audiotool. I’m talking about every other modular system i have ever used. The Merger device is much, much more useful than the splitter, since an input can only logically take one source unless you do some kind of automatic mixing behind the scenes (which wouldn’t be cool from a UX pov, muddling the user’s expectation of what will happen). There is however no good reason why you can’t simply drag multiple cables from the same output to several inputs. The splitter device ends up becoming a huge speedbump I find myself forced to cross time and time again, contributing further to the screen clutter, and is probably the single biggest interface impediment to a quick modular workflow.

The beautiful thing about modularity is the playfulness it inspires. If it won’t cost you extra effort to make that extra connection and see what happens, why don’t you just go ahead and try it? Currently, the Splitter sits squarely in the way. There’s certainly a use for the functionality offered by the Splitter and Merger, but in my mind, having written rudimentary modular systems before, there is no good reason why you’d impede the user’s playfulness in this way. As it is, Auditool replicates the worst of real-life cable spaghetti. That’s a physicality I’d much rather leave in the past.

Suggestions:

• Allow multiple connections per output.

The layout grid

When you drag a device onto the workspace, a grid of sorts appears, allowing you quick and easy alignment of new devices. This is brilliant. However, the layout engine doesn’t allow you to drag and drop a device “between” existing devices, moving them to either side. Instead, you must move the devices apart manually, then move your new device in between. With the aforementioned considerable screen clutter, this quickly becomes an absolute nightmare.

Suggestions:

• If the current system makes this form of automagic difficult to implement, I suggest modifying the layout engine to use a looser spring constraint based layout where device bounds, weighed by size and using connections as additional springs, push against one another until there is no contact.

The Pulverisateur device

This thing is fantastic. It is, as I understand it, Andre Michelle’s first “real synth”, and it does a ton right, including often forgotten features like oscillator sync, optional keyboard tracking, audio input and a filter envelope with an interesting and powerful loop toggle. However, it can also be very difficult to use for anything precise. The biggest culprit is easily the LFO waveform knob. Since there is no pitch envelope generator (argh), if you want to use the Pulverisateur to create analog kick drums that go beyond the limited capabilities of the two supplied drum machines (more on the 808 later), tweaking the LFO to perform as you wish feels like a total crapshoot.

Suggestions:

• For morph knobs, allow clicking on the symbols to set the knob precisely to that value.
• Introduce a pitch envelope

The Beatbox 8 device

Less critical this, but I’m a TREMENDOUS 808 fanboy. This should have been my absolute favorite device. I have sat night after night working on an accurate 808 emulator patch on my Nord Modular, so BE IT if it consumes 99% capacity, and it is bloody hard to do, so I can see why this unit isn’t feature complete. The 808 is one of the dirtiest, grimiest drum machines around, and the first unit I drop on the Audiotool workspace. You drive this thing through a few effects, and every single instrument on it can be a monster. I implore you: Finish this device!. The lack of settings on some of the drums absolutely cripple it, and actually enforcing the If you want this to be a real 808 tribute, please include feature parity of some sort, especially on the kick drum and snare. The Beatbox 8 is a pale shadow of the 808, yet close enough to frustrate. To spend this much time on recreating the UI and sequencer, only to leave out integral drum part features is really cruel! Actually enforcing old flaws of the unit, such as the need to sacrifice the hand clap for maracas just adds insult to injury. There is no “lesser” drum on the 808, and denying users the full palette is.. Let’s just say there are unhappy kittens out there

Samples

I’ll be frank; I can not stand the samples on offer. I have made a huge effort to explore them, but it is utter sample-CD drivel. I’m sitting on harddrives worth of personal sample collections; Why am I not offered the ability to upload?

Suggestions:

• Offer users 100 megs worth of sample space or use local file paths. If copyright infringement is called into question, block the associated song or user, and allow users in the community to tag songs as questionable.

Summary

Audiotool team; As a musician I would love to make music and share it with others using your tool, but as it is, I feel my ambitions get truncated by the UI choices you have made. I can stomach a lot of odd choices, but the moment something stops me from doing what I want before I do the truffle shuffle it wrecks my inspiration.

Very much looking forward to your next version! You guys are champs.

Click to run app

This is obviously not a tool for public consumption: The designer was sitting across the table from me and could ask questions and get support/new features whenever. The point is, we met our goal, the designer was happy with the result, and the effect was exactly what we hoped for.

Taking the time to throw down a tool like this is a real boon to us as developers, allowing designers to get intimate control over aspects they might otherwise consider too technical. And getting them off of our backs as a bonus.

Here’s a modest attempt. Max Richter’s ‘Autumn Music 2′ set to a swarm of particles, with the music swell and rhythm driving emission and color.

]]> http://www.doomsday.no/esn/2010/04/synesthesia-experiment-1/feed/ 5 http://www.doomsday.no/esn/2010/04/painting-with-time/ http://www.doomsday.no/esn/2010/04/painting-with-time/#comments Thu, 22 Apr 2010 22:29:57 +0000 Andreas http://www.doomsday.no/esn/?p=908


Largely unoptimized proof of concept.

Paint to reverse time

Spacebar to pause image capture and alpha buffer fade

p to generate perlin noise

There are some seams off into the distance, but overall I reckon it’s quite compelling.

• Choose the node name of your root node (“data” is typically it though)
• Choose the node name for file nodes (for instance, “sound” or “movie” or whatever)
• Choose whether you want the path/filename to be placed in a “path” attribute or in the node innertext
• Choose if you want the file path to be Absolute, relative to the starting directory, or just include the filename
• Enter the file extensions you want included, separated with spaces (“mp3 jpg avi”), or just leave it as a wildcard
• Select the starting directory for the crawl
• Check whether you want to include subdirectories, meaning a recursive search. Included subdirectories will be placed under nodes with the directory name.
• Click “Generate”

I threw this together to quickly build a list of sound files for a project where I had no CMS to help me out. Maybe you’ll have use for it too? I am never fucking ever copy pasting file info into XML again. Ever.
You can grab the air package here

With that mindset, the current religious war in the web development community (though commonly propagated mainly by Angry Internet Men of unclear merit) about the relative merits of HTML5 vs Flash has grown tremendously in scope with the launch of the iPad and Apple’s latest changes to the iPhone 4 SDK agreement.

Suddenly, it’s no longer about Steve Jobs’ hissy fits and Apple/Adobe’s past. It’s now about what it means to be a developer, the tools you choose, the platform you wish to work on. It’s another apocalypse then; The corporations are taking away our anarchistic developer rights to go anywhere, do anything! Time to wave banners, and while we’re at it, choose sides. You know, good/html5/css/js, evil/plugins, or any combination thereof. Whatever.

Holy hell guys! Isn’t this the most BORING shit ever?

Listening to knowitalls babble on about standards and “what’s right” and future proofing, Jesus, how boring can you get?! Stop being so damn boring! Stop saying boring things! Go make some cool shit! Bouncing fucking gradient balls man, let’s go! HTML5 dudes, Flash dudes, jQuery dudes, all of y’all, go make some god damn gradient balls! Make some shape tweening text! Make text adventure games or drawing apps or art or music tools or publishing tools or an awkwardly animated horse that sings or something.

One of the best things about maturing as a developer is watching your horizon broaden.

Man, I love being a developer. I love looking at a screen and an input device and think about what I can do with them. I love digging into frameworks. It’s a ton of fun! It’s engineering, right? You put the thing in the place and pull that string over there and put some tape on the stick and push that and the wheel spins and goes buzz, it’s awesome! It’s the joy of making a thing. It’s why Lego is such a popular toy.

It’s when you start out with JavaScript and realize the similarities to Python and you start tinkering just to see how similar they are. Maybe you fall in love with Python. Maybe you feel straight Java is the next step, or maybe you go low level and dig into C or Assembler. Regardless, you can choose which way you want to go. In this day and age, rarely is there a point where what you made can not be moved to another platform in SOME way shape or form.

Why are there people out there so religious about their choice of language or platform? So jealously defensive about the way they feel things should be done? If there is any argument I have for Apple opening up its platform it would be this: Stop making development boring.

The more these beardy thinky-men are ARGUING over the politics of this shit, the less I wish I’d spent the last decade embedding myself in the business. Every time I hear a pro-apple or pro-Flash argument now, especially retarded shit like this; THAT is what makes me worried about the web as a platform.

More plugins man. More non-standard bullshit. Bring it on. Let’s get this diversity party started.

Some players want this Internet game to stagnate in the ankle-deep murky lukewarm waters of HTML/CSS/JS. For those about to rock that shit, in all honesty, I salute you; You are true, professional masochists.
For those about to raise that flag and proclaim it the future however; come over here, Buzz Killingtons, so I can punch you in the collective mouth, and I’d be honestly surprised if any of you have any real development experience; You’d know how much greener the grass can be.

The only player in this game that currently gets it is Google; The problem with plugins isn’t the notion of a plugin. It’s the framework, and the end-user experience. The end users people! Don’t you want to make cool shit for them to play with? Don’t you want them to open a website and be like..

WHOA. What the hell is this SHIT that’s going on in my browser window!?

Don’t you want to give them a sense of wonder?

Technology is magic guys! Why the hell are some of you so god damn obsessed with codifying it?!