Project Hiddenwood

This years FOTB was special. At the end of my session I showed a sneak preview of project Hiddenwood. I demonstrated complete playback of Audiotool tracks on stage — in a browser. Now that does not sound too special…

But then again, the playback was done using JavaScript only and calculated in realtime.

Audiotool is a complex piece of software so you might ask how one could torture themselves by implementing it in JavaScript? We didn’t. Instead we started building our own vision of a cross-platform application framework a couple of months ago.

Introducing project Hiddenwood.

Hiddenwood is a collection of libraries and tools specifically designed to support different devices and platforms. The core libraries are the “driver layer” and always platform-specific with a platform-independent interface.
On top of that we provide a basic layer of libraries like our UI system, animation framework or managed collections which guarantee 0% garbage collection activity and have been battle-tested in Audiotool.

The framework is all about speed and consistency. The rendering pipeline is optimized for OpenGL and although we offer something similar to Flash’s display list a lot of features are not available because they would compromise the speed.

Speaking about speed: we are always interested in staying as native as possible on our target platform. So for the browser we emit JavaScript, for Android you will get the full DalvikVM performance and for the desktop you will get JVM performance. This approach has also another very important aspect. If you want to go platform-specific for certain features you can do that.
For instance if we want to render Audiotool songs on the server using a fork-join pool for our audio calculation this is possible and might not make sense on an Android device.

You write Java code and the supported platforms are native desktop applications, Android (minimum requirements are Gingerbread and OpenGL ES 2.0) and modern browsers. Now for browsers we even go one step further and support multiple options. That means if WebGL is not available we simply fallback to a normal canvas based render-engine. The same applies to some of the Android drivers.

iOS is of course important as well and we are actively researching the best option that will give us the most flexibility and performance.

We are currently working on two real applications built with Hiddenwood. So far it is a real pleasure to enjoy quick build times and simply test what you want on the desktop with great debugging capabilities. When you are ready you can try the same app on Android or in the browser — which might take a little bit longer to compile.

Because we see Hiddenwood as an application framework there are a lot of goodies built-in like a sprite-sheet based class generator. Think Image mixerBackground = Textures.mixer.background(); where mixer was the folder name and background the name of the file.

We believe that as a developer you really do not care about what kind of technology you are using and just want a great result. We also think that you should be able to reuse platform-independent code across multiple projects. However we do not want to take power away from the developer because if you know what you are doing: go for it.

Of course we are not the only ones with this idea. Nicolas Cannasse saw the signs years ago and invented haXe which gives you a comparable experience and Google released playN a couple of weeks ago which takes a similar approach (and requires another 25 committers :P).

But when we started Hiddenwood we wanted the Java tooling experience and playN was not public at that time. We also think that a game engine is not what you want to use for all kinds of applications. So we like to be able to give people the freedom to build their own game engine on top of Hiddenwood — and calculate physics in a different thread peut-être.
Speaking about threading: the only possible solution that works across all platforms is a shared-nothing architecture which we put in place. However if you write platform specific code you can use of course everything the platform offers and a lot of the Hiddenwood core libraries like the network- or cache-layer make use of multiple threads.

In the end what makes Hiddenwood special in my opinion is that we do not believe in write once run anywhere because that just does not make sense. The essence and philosophy behind Hiddenwood is to write platform-agnostic code using kickass-libraries and being able to reuse that. Audiotool on a tablet would look completely different from Audiotool running in a browser. And Audiotool on iOS would probably be also a little bit different from Audiotool on an Android device because there are simply different paradigms you should respect.

I hope that we can share more information with you soon. With the news of mobile Flash Player being deprecated and the ongoing demand for cross-platform development we have exciting times ahead of us. I am also super excited about the (beautiful <3) applications which we are going to release in the not so distant future.


  1. Posted Nov 11, 2011 at 2:53 pm | Permalink

    “we do not believe in write once run anywhere because that just does not make sense. The essence and philosophy behind Hiddenwood is to write platform-agnostic code using kickass-libraries and being able to reuse that. ”

    How can I +10.000 that?

    Great work, I look forward to hearing more.

  2. Posted Nov 11, 2011 at 3:45 pm | Permalink

    indeed, that sounds brilliant. next time we meet i’m gonna pull my hat for you.. again :)

  3. rmri
    Posted Nov 11, 2011 at 4:04 pm | Permalink

    Great job Joa as always.
    Looking forward to have my hands on this stuff, please keep us updated.

  4. Rezmason
    Posted Nov 11, 2011 at 6:04 pm | Permalink

    Very nice, Joa. :-) What’s the base language? Java? Scala? AS3? Joa++?

  5. Posted Nov 11, 2011 at 6:20 pm | Permalink

    Java it is. For Android/desktop you could also use Scala but I would not want the footprint of the Scala library in there by default.

    Hiddenwood itself is written in multiple languages. Unit tests are mostly written in Scala.

  6. Posted Nov 12, 2011 at 3:02 am | Permalink

    “we do not believe in write once run anywhere…“ – totally with you there. Doesn’t make sense! Or at least doesn’t make sense if you want to give anyone a good experience.

    Things might work – but they’ll never work nicely because the user-system interaction hasn’t been taken account of.

    I’m with Alan, +10 !

    Now – can I write it in haxe ? :P

  7. Posted Nov 12, 2011 at 11:37 am | Permalink

    Sign me up for the beta, please

  8. Posted Nov 14, 2011 at 11:30 pm | Permalink

    This looks awesome, and I agree with Alan and Tarwin.

  9. Sandro Manke
    Posted Dec 12, 2011 at 1:11 pm | Permalink

    Hey Joa,

    cool to see, that you’re keeping up the good work all the years. Do I understand it correctly, that you are currently not supporting iOS? I understand that using Java gives awesome tooling, but in our choice for building a multiplatform framework we did not find a suitable way to use java with iOS in a suitable and manageable way, that doesnt kick back on maintainability, so i’d be pleased, if you prove us wrong. I hope we can see something very soon!


  10. Delfeld
    Posted Dec 12, 2011 at 9:58 pm | Permalink

    “we do not believe in ‘write once run anywhere’ because that just does not make sense. The essence and philosophy behind Hiddenwood is to write platform-agnostic code using kickass-libraries and being able to reuse that.”

    Well, “-20” to compensate for the fanatical support from 2 commenters (so far).

    This is just a an incautious slurring of the difference between a goal and what is practical. Your goal — your philosophy — *is* actually ‘write once, run anywhere’. However, you (and Adobe, and Grant Skinner et al., and so on) are only able to get so far before you reach what in math is called ‘the least common’. At that point, the divergence between systems is so great that there is no way to match up the coding. You can call these divergent systems “improvements”, if you look at the system with the functionality, or “detriments” if you look at the system without it. You can provide system-specific areas of code in your framework so that programmers can access that system’s feature. As a matter of fact, you *should* provide that code set, as much as it is feasible; in the future, a system (currently) lacking the functionality may provide a similar feature, and you want programmers to be able to access that future improvement.

    So you see the point, I hope. The entirety of why Hiddenwood has *any* value at all is because it truly does believe in the goal — the philosophy — of ‘write once, run anywhere’.

    I feel that the negative press against Adobe is compelling you to avoid adhering to a goal that they have de facto trademarked. But just because the Apple fanboys have tried to make the goal sound unwanted, this does not mean that it is not still the goal for any and all frameworks.

    Keep up the good work!

  11. Posted Dec 12, 2011 at 11:23 pm | Permalink

    Delfeld: Don’t you agree that an application needs to respect the paradigms of its environment? E.g. an iOS application should be different from an Android application. And a mobile app should be probably different from a browser app.

    You want to reuse parts of your code but you should always try and make sure to achieve a consistent user experience. That’s why some people agree and that is our philosophy with Hiddenwood. Of course the actual code follows “write once run anywhere” (sort of) but you have to give designers and developers the power to do custom platform specific stuff.

  12. Delfeld
    Posted Dec 15, 2011 at 8:28 am | Permalink

    The distinction between a designer respecting the app environ vs. programming in a framework was not clear to me, so thanks for making that distinction. Looking at all the recent spate of web pages that have huge buttons because they might be viewed on a handheld, I can see your point: people are writing once, but only thinking of one environ, and viewing in alternate environs suffers. You do point out an interesting side-effect of the WORE idea.

    But many code sets try to manage this problem. For wider displays, more info is shown; for narrower, less; and so on. It appears impressively on all screens. The programmer has to program a bit more functionality in order to create this effect, which does not adhere to the “write once” concept. But it does emphasize my point, I think: the programmer is giving the handful of design patterns to code towards, without knowing at all what the actual device is. Practically, he or she has to write a bunch of code, but philosophically never moves from WORE.

    This is not respect for the app environ. It is done in complete ignorance of the device, and the programmer would prefer it that way. As impressive as any particular screen/environ may be, the programmer has to obstinately refuse to acknowledge how awesome and special it is. Instead, the programmer is thinking about functionality in general, and programming toward that.

    One other point, about ‘consistent user experience’. I assume that this consistency is device defined, not designed by the programmer. The style, skin, timing — or whatever that consistency may be — is the default interactive environ on that device. The programmer should be given a set of tools that accesses this consistency. That is, a “button” looks like whatever it does on a system, but the programmer just creates a ButtonObject, and changes the text and result. It’s only in stepping away from the default interactive environ that programmers start to make things inconsistent. So I am suggesting that to actually achieve a consistent experience requires both the framework and the programmer to adhere to the goal of WORE, in the sense of making the assumption that the framework will make it right for each environ . . . even if in practice that is not achievable.

  13. Posted Dec 16, 2011 at 10:12 pm | Permalink

    Sounds promising, Joa. Excited to see it in action.

  14. Donovan Adams
    Posted Jan 12, 2012 at 6:58 pm | Permalink

    Hi Joa, I’d like to be included in learning more on this project. I agree with your thoughts on being platform agnostic, but respecting the platform context. As tools evolve, this will become more important and should eventually find its way built into the features of the platform.

  15. Posted Jan 31, 2012 at 3:43 am | Permalink

    Did you ever had a look to Xtext ( I think that is beside the multi-platform paradigm the most promising direction. It goes even a step further as you define you own domain specific language and can generate source code for different target platforms (with Xtend). I think a mix of a Hi-level feature language in Xtext and a multi-platform framework and compiler could be an interesting development…

3 Trackbacks

  1. […] Hiddenwwod, like haXe HiddenWood sounds very interesting… but the same doubts it isn’t ready […]

  2. […] did this partly already since 2004, as well as some other interesting moves in this direction (Joa Ebert). Adobe seemed to missed this […]

  3. […] a lot of other people in the audience). He introduced us to what he has been working recently, the Hiddenwood project: a Java based collection of tools and libraries that is platform agnostic and outputs to […]