For showing your tweets (or anyone’s for that matter) in a website, twitter offers two JavaScript files, blogger.js and user_timeline.json. To make it work, there’s three steps to take:

1. Add one specific HTML element as a placeholder for the tweets
2. Embed two JavaScript files into your page
3. Add some CSS to have it show the way you want

Following is a short explanation of how it works.

The HTML

You only need to place one HTML element in your page into which the tweets end up. This element needs to have the id attribute set to twitter_update_list. This is because the scripts need to know where to put the tweets. In the example below I use a unordered list ( <ul> ) as a placeholder. So, somewhere in my page there is this code:

The JavaScript files

The two files can be linked to your page from the twitter server, so no need to host them yourselves. The embedding can be done by copy pasting the following code right below the HTML seen above.

The first can be embedded as is, there’s no settings to it, nor the real need to change it’s code. The second does need some settings. They are discussed after the next section.

blogger.js

The file you just need to embed, nothing more. This file contains two functions to parse the incoming data into chunks of HTML. Each incoming tweet is placed inside a list item (<li>). Usernames (words preceded with the at-char (@)) are made into links to the twitter timeline of that person. Furthermore, all links are wrapped in an anchor tag. Lastly a link to the actual tweet is created from the id of the tweet. The tekst linking to the tweet is the indication how long ago the tweet was placed. This leads to, for instance, the following HTML structure:

Nasty detail IMHO here is the inline styling of the link to the tweet. I guess they had better left it to the CSS of the user. Fortunately there is the !important rule to override it.

The function that does the parsing looks for an element with the id ‘twitter_update_list’ to place all the list items in. Since the parser places the individual tweets into list items, it makes sense to use a list ( (<ul> or (<ol> ) as this html element.

user_timeline.json

This is the script that does the actual request to twitter. Here you can set a number of options to determine what is retrieved from the twitter server. Here is a short overview:

user_id

The id of the user you want to show the tweets of.

screen_name

The screen name of the user you want to show the tweets of (this is the name that appears in the browser address bar when you view that user’s timeline on twitter). Either this one or the user_id needs to be provided, not both.

include_rts

Show what you retweeted or not. 0 or 1.

count

How many tweets you want to show. 1 or more.

callback

Required. Leave as is or write your own JavaScript to parse the data coming in from the server.

For a more detailed description, see: the twitter docs

All the settings are done as GET parameters on the URL of the script. So, broken into separate lines it reads like:
http://api.twitter.com/1/statuses/user_timeline.json?
screen_name=mannobult
&include_rts=1
&callback=twitterCallback2
&count=4

The CSS

The CSS you want to add is of course entirely up to you. However, knowing what HTML output the JavaScript generates is necessary.
So you may want CSS for the following elements:

• The element you placed yourselves (with id=”twitter_update_list”)
• List items that appear inside it (containing all info of one tweet)
• A span element inside the list items
• Anchor elements inside the span for any links in the tweet
• The anchor element which is a child of the list item (with the link to the tweet)

Below an example of what the CSS could look like (comments in the code):

All the above results in the following:

Disclaimer

I did not get myself a copy of Impact. Just reviewing the book and not the Impact framework I did not see it as nessecary. Had impact been on sale like it was about a month or so ago I might have gotten my on copy (notch, notch, wink, wink).

The positives

Let’s start with those according to the feedback rules…

To me te book feels like a cookbook to get one specific game done (“type this here …”) at times. It however gives a good overview of most if not all ‘classes’ and possibilities of Impact and how to get up to speed with building a relatively small game with it. Using the accompanying level editor called Weltmeister Jesse shows you how to design levels, how to load them in Impact and bring the level to life. What else can you ask for?

Next to that more or less main goal of the book, you’ll get an overview of the whole process of game development. From initial idea to publishing (and possible deployment on iOS with a template Xcode project that comes with Impact). Good insights from someone who knows what he is talking about.

Finally it contains some heads up on HTML5 development. I’m afraid that is still nessecary with the way browser support is at the moment.

The negatives

The subtitle of book is a nice pun (and the name of the game framework is well chosen), but may be somewhat misleading for the less informed buyer of the book. Actually tagging along with Jesse in building your own game will set you back $99: the subtitle’s “Impact” refers not only to the effect games may aim to have on their player, but also to the commercial Impact game framework written in JavaScript. Just a fair warning ahead.

Another downside I think there is to the book is the intended audience as it states. Personally I don’t think this book is much use without having prior programming knowledge. If you have none, you’ll end up with a working game nonetheless, but I doubt you’ll understand why, how to change it or to build your own in any reasonable fashion.

Finally, usage of stats to analyze players behaviors is stressed, however, the examples may have been a bit more clear (I’m pretty much a GA noob)

Impact

Without having used the software, it seems like a real nice environment to work with. It comes with a good map editor, several debugging and profiling features. To help with the game mechanics there’s collision detection and particle systems and most needed features of the box so you can focus on the creative process.

Concluding

I’d by the book if you want to do some JavaScript game dev, especially if it involves platform games. If you have no programming experience I would get some basics done first but I guess it all depends on your individual talent to pick up programming.
It is a quick read and gets you up to speed with Impact in about a day (or two).

Get HTML5 Game Development

Koen and Wouter are developers of AIRKinect of which version two is almost to be released. Unfortunately my lovely new MacBook refused to install some of the drivers despite Wouter’s persistence. Fortunately they had a spare laptop to use (thanks!).

I’d seen demos and fooled around with the depth image before, but the next version of AIRKinect, used as native extension offers lots more then I’d ever seen possible in AIR (may of course be my ignorance).

Some of the features of the 2.0 preview we got to play with were:

• depth image
• point cloud
• point cloud regions
• skeletons
• poses

Depth image

The depth image shows the image the IR camera registers in greyscale. Nearby white, far black. My first ever experiment was that I used this to, pixel by pixel, reconstruct a 2.5D image with Flash’s z-property of sprites. But…

Point cloud

The point cloud is a ByteArray with for each “pixel” an x-, y-, and z-position. This allows for precise tracking of, for instance, the closest thing the IR camera registers. Extend your arm and move stuff around, the famous Minority Report interface in the making.

Point cloud regions

Point cloud regions allow use of hotspots. If a certain region (a box) contains more than a set number of points from the cloud (the count is done by the extension), you could start whatever action you see fit. Du du, du du, du du, du du, ta ta! I can feel it coming in the air tonight … Drum like Phil Collins for instance.

Skeletons

The skeletons you may have seen before. AIRKinect supports 4 skeletons and then some additional center of mass registrations. With the skeletons you have access to the main joints, their position in 3D space, position projected onto the webcam image, orientation and more.

Poses

With the skeletons you can create poses, this is actually not done in the extension, but with a few classes in which you can define poses like assertions: right elbow, above, right shoulder. Combine a few of these rules and you can create complex poses which are easy to check.

There is no doubt more, but the distraction of and annoyance over the failures of installing macports probably made me miss out on some…

All together it requires a somewhat elaborate install sequence (which they will no doubt publish at due time) on the Mac, mine being the odd one out resisting all attempts to get it running. On windows it’s a bit lot less elaborate. Definitely will try at home to get it running on my desktop. When I succeed, hours of fun will be waiting

To limit orientation of the stage on devices you don’t need much. In this example I want the application to only be displayed in landscape mode.

Loop up the aspectRatio and autoOrients tags in the application descriptor file, and make sure it looks like the following:

Then, in the application code, check if the stage is set to auto orient, and if so, listen to the ORIENTATION_CHANGING event:

In the eventlistener, check what the futute orientation will be, it is stored in the event parameter as it’s afterOrientation property. If that orientation is NOT what you would like it to be, call the event’s preventDefault() method. The stage will not orient itself.

Below you see the two orientations defining the portrait orientation, StageOrientation.DEFAULT and StageOrientation.UPSIDE_DOWN. The other two, StageOrientation.ROTATED_RIGHT and StageOrientation.ROTATED_LEFT represent the landscape orientation. Since the latter are what I want, the first are prevented.

You can find more options at: Adobe’s website

(It turned out to be much easier than reading out the accelerometer and rotating the stage yourself…)

Folowing code is a more complete example in case you want to test some code. It is the main (and only) class from a Flash Builder project (uses AIR 3 and Keith Peters (AKA Bit-101) his minimalcomps):

For a current project I need to know what version of the iPad an AIR app is running on. I saw solutions measuring screen resolutions to get info whether an app runs in iPhone or iPad, but no posts on differentiating between iPad 1 and iPad 2. The Capabilities class seems to have the solution. Below is the output of the

property for the iPhone 4, iPad 1 and iPad 2.

iPhone 4 gives you:
iPhone OS 5.0 iPhone3,1

iPad 1 gives you:
iPhone OS 4.2.1 iPad1,1

iPad 2 gives you:
iPhone OS 5.0 iPad2,1

This info breaks down into:

• The OS (the name apparently always is iPhone OS) with it’s version number (the iPad one in my case still running iOS 4)
• The device id which holds the device name and the device ID

The device name and its ID apparently are different as for example the System Status reports. System Status for instance has “iPhone 4″ listed as being the Device and “iPhone3,1″ as the Device ID. The device IDs for the iPad are more descriptive, but once you know what to look for it does not really matter what it lists I guess…

Anyone have the info for the iPhone 3?

With the new GPU rendering capabilities of Flash player 11 and AIR 3, which go under the name Stage3D (formerly known as MoleHill) performance should be greatly improved in … some, all(?) cases. Since it has been a long time I did anything with actual 3D modeling, the logical place to start is 2D. Dreading the complexity of the Stage3D API’s I will focus on the Starling framework. There is a nice example of what complexity Starling hides from you on the Adobe devnet pages. The following links will be my first information providers while experimenting I guess.

Of course the Starling API documentation.

Also: Lee Brimelow has two video tutorials on his gotoAndLearn site. One introducing the Starling framework and one explaining how to use particles in the Starling framework with one by one design’s particle editor. Lee will also host a workshop at Flash in the Can Amsterdam 2012.

The framework was written by the Austrian Gamua, also responsible for the sparrow framework for objective-C (another thing which desperately needs being looked in to) which in it’s turn is loosly based on the Flash display list API.

If you wonder why a separate library is needed in stead of using the standard display list, the following article explains why Starling is a good idea for 2D GPU rendered content.

Imagine (if you can’t, there a picture below doing it for you) one circle in the middle. OK, now imagine another circle centered on the edge of the first. This second circle moves over the circumference of the first, thus describing a circular motion. Now place something on the edge of the second circle and have it move over it’s circumference. Depending on the size of the circles and the rotation speeds the object on the outer circle describes a lot of different motions looking a bit like a spirograph.

The two circles and the moving object (blue)

In the above image, the red circle is the first one. The green one moves over the circumference of the red one. The blue dot moves over the circumference of the green circle. It cannot get outside of the blue circle.

This however is a very regular motion. Not what I had in mind or promised you with the title of this post. There’s no long explanation to it, so I’ll get to it right away: To make the motion random, just have the direction of both the rotations alter at random intervals. Not to often or the final object moves in a jittery fashion (and may not even leave it’s position), not to few or the object moves to predictable. In the example below you can alter the frequency of the direction change as well as the speed of rotation (with thanks to http://www.minimalcomps.com/).

Right-click on the flash file to view the source files.

Situation

You want a Flash file allowing fullscreen playback in the browser. Next to this you have a DisplayObject somewhere on the stage with a mask applied to it by script.

Problem

The mask does not work properly in fullscreen mode. When going fullscreen, the content scales as it should but the mask shows only a portion of what it showed before.

Solution

If you dit not add the mask to the stage (which you don’t really need to do if nothing is about to scale), the mask does not scale with the rest of the content when the StageDisplayState goes FULL_SCREEN. Because of this it reveals the same area in square pixels (w x h), but since all the rest is scaled up, this is only a small surface compared to what it revealed before.

So, the lesson to be learned: If you’re gonna allow fullscreen mode in your application and use masks, add them to the display list. Maybe just add them to the display list, period. The few times not having to type the line:

probably saved less time than I had to spend hunting this error. Below an example showing the error (above) and the proper result (below).

Code

Paul Trani

He showed optimization tips in the Flash IDE. Tips however were more general than that. First thing he mentioned was the huge PPI differences across devices. Ranging from 120 to 300something (a huge difference). Scaling interface elements based on Capabilities.screenDPI is one of the solutions for it: setting an object’s width to the Capabilities.screenDPI makes it one inch wide. Build your own little app that reads the capabilities of a device before you start developing for it. This brings back memories of “best viewed in …” days where cross browser development was not as easy as nowadays, however, Adobe seems to do a good job with the next releases in accommodating for all the different devices. The multi screen development as they call it. It remains a wild, wild world out there however. The examples Paul showed had timeline code (for which he apologized ) but had a nice way of sort of seperating the model and view. His example shooter ran with just one document class for all devices and decive specific code in the document itself.

To save some of the precious screen real estate, you need to make sure you know the capabilities of the device and what the general user expects to use to navigate. You can get rid of a lot of the buttons and let gestures be used for navigation, so like Stacy said yesterday, think really well about what you’re designing for.

Furtermore there were tips on all kinds of performance thingies:

• bitmaps instead of vecors
• blitting for faster drawing (see SWFSheet from Bit 101 or Zoë by Grant Skinner to aid creating spritesheets)
• use cacheAsBitmap for elements only moving (x and y axis only)
• use cacheAsBitmapMatrix for elements rotating and scaling etc
• move displayobjects over whole pixels, not subpixels
• use Graphics over Sprite over MovieClips if you can to preserve memory
• remember to remove (unloadandstop of removechild) ojects when not needed anymore
• take redraw regions into account ()
• Use object pooling

This it can be found too on Thibault’s blog and other places. So much reading to do…

Next to a Space Invaders type of demo he showed, a nice piece of eyecandy shown was Flash Silk (I think only available for Android devices).

Deepa Subramaniam & Andrew Shorten

Paul’s presentation more or less seamlessly went over into the one of Deepa & Andrew talking about the new stuff in Flex 4.5 and Flash Builder 4.5 of which a tiny glimps was already given at the keynote of day one. Here we got the full story. Deepa showed the new templates based on navigation paradigms present on devices, the new versions of the Spark components retrofitted for mobile with separate skins for Android and iOS and the debugging while testing on the device trough either USB or WiFi. The SDK is also improved at several points, more Spark components replacing Halo components (datagrid, form, image, busycursor) as well as local aware formatters, improved modularization to accommodate or speed up development of big ass projects.

Andrew showed some of the new coding features which let it compete with FDT (which already has those features AFAIK). Al kinds of code assist among which code assist for meta tags, even for frameworks like Robotlegs (if they provide the proper XML file). There was a real short part on Catalyst, but to be honest I never used it, so the “NEW!” remarks did not make much sense to me. I understood the “better streamlined, also for use by developers”, but that was about it, sorry.

Alyoka & Jooony Emergence + reflection = emerection

No, not the reflection in a fancy black mirror… The first part done by Alyoka who started with a introduction to the ever mesmerizing Game of Life from John Conway. Next she showed a nifty implementation of some of Wolfram’s rules applied to a combination of byteArrays and bitmapdata (does not seem to be on their blog) to demonstrate the principles behind emersion. The presentation went on to give an introduction into the technical possibilities ActionScript has to help with reflection / introspection like describeType(). Jooony took over with  something that ended in peak & poke for ActionScript. Due to the lack of time and some hard to read sheets the story did not come across as it should have, but the punchline was that he read the bytes of a SWF file and found a way to more or less decompile it. With all the info gathered he was able to alter classes at runtime. Pretty impressive and true emersion but sometimes hard to follow. I wonder what will come out of his experiments.

Richard Jewson & Oskar Sundberg

“Speech” did not really have anything to do with it as the title of the presentation suggested, it was a transcription error from email to program booklet. The presentation was about procedural content and generative art.

Both work at Blastradius. A very brief overview of generative art was given, Islamic art with it’s complicated mathematical rulesets, Mozart’s algorithmic composition with dice and a deck of card to some computer facilitated generative art. Today we can use similar algorithms from long ago to do more with it aided by the computing power of modern times.

Then the procedural content creation of Elite and Exile (Both BBC Acorn, I’m old enough to have seen some working remains of those) was discussed. In Elite the galaxies were generated by algorithms and in Exile the game map. With the use of the proper input for an algorithm (randomseed for instance) you’ll be able to generate the same ‘random’ map over and over so you don’t need to manually define it in the game. It may take a while though before you end up with an acceptable random map.

If those techniques back in the days may have been used to safe memory, nowadays with an abundance of memory, the algorithms can be used to save time (otherwise needed for manual asset creation).

A presentation was given of a Nivea project their company did(for the life of me I can’t find it online…). Users could create a leaf on a tree as sort of a crowdsourced artwork. The tree was created with an variation of an L-System with some wind and dynamics that respond to mouse movements added to it. Added to that were very dynamic brushes inspired by the ingredients of the product.

Finally there were some examples on the more playful side:

• see before reading
• MIT medialab logo
• Wurst apparatus

The introduction of a project in the making of them selves called Binory.com topped it off. For this project they still need input in the form of people that can provide algorithms that create content that people then can order on print. There’s a buck in there for the algorithm owner. Mail:  hellobinory [ a t ] gmail  [ full stop ] com.

Bartek Drozdz

3D workflow for the New Era

Bartek talked about his history in 3D development in Flash and Unity. From his first project in Flash with Papervision to a Unity project with an 80+ inch touchscreen in a 6 company project and the changes his roll as a developer went through. His first project he did everything himself and build the skateboard model from scratch in code, later on he build his own assets in Blender and now he has to let modelers do the modeling since 3D project have become to complex to do on you own. The capabilities have increased so much over the last few years that each part of the project has too much of it’s own expertise that one person can do it alone. He had a nice overview of the work areas involved in 3D application development:

Low level stuff

(what most people will never touch or see) WebGL, OpenGL ES, Molehill

Engines most developers work with

JS engines (Three.js), Unity (C#, js, as3), AS3 engines (Away3D)

Workflow tools

This is the glue between assetcreators and coders ( python, maxscript, unity editor api )

The art / design tools

3D editors (Maya, Blender etc), Gamelevel editors (Unity)

Data input

Generative art, physical input motion data etc.

At the moment Bartek is impressed with Unity, easy in use and coding (C# is a lot like AS3), the API is easy to learn and the coding done only has to deal with game logic.

The case study, done in Unity, he showed was a project that runs at a Swedish airport and is called Woodbot pilots. Quite an impressive project done with 6 different companies and Bartek himself. It involves a portrait positioned touchscreen with a 3D camera (no, no kinetic) above it to capture the movement of the player which is translated to the direction the bot is steered through a rocky landscape, check out the video on his website.

The things he learned from this whole project were (among others):

• Concept art is not to be used in the final product (even if it is 3D concept art). Maybe that was why a lot of concept art is done drawing on paper (although the concept art for Woodbot pilot was beautifull)
• Make prototypes to test concepts and the gameplay. You cannot think it all through, you must experience.
• Talk (a lot) with 3D artists, there is so much that can go wrong and could use extra attention that the artist cannot work out on it’s own. Things to take into consideration are: polycount low where needed, higher where possible, textures & shaders work different in model software and the engine of choice, structure of models (pivots, groups etc) require attention, procedural content could be easier to use, depending on useage and engine.
• Automate the asset pipeline: use editor script wisely to, for instance, inspect models. (After having spent numerous hours inspecting models, Bartek decided to write scripts to do it for him, time investment but in the end saves time and frustration)
• Build levels in game editor, seperate the phase of modeling from level design because then you’ll know what it looks like exactly as well as that you’llbe able to use features specific to the engine which the modeling software does not have.

The conclusion however was that there is no ideal workflow across technologies / tools, just rules of thumb…

Evan Roth

He was last but certainly not least. You really need to look up his work (as advised, a google search for “bad ass motherfucker” will do just fine). His story was about empowerment, open source and open data. This single sentence does not do his work any justice. And since most of it is visual, check out the website. His work can be seen as aesthetic but with substance as his lollypop infographic explained. Sometimes it can be seen as pure aesthetic, sometimes a bit juvenile mischievous, sometimes pretty ‘pofessional’ and sometimes with unexpected backgrounds but always good. Something to think about on the train ride home without any more battery life left

It ware three very nice days with loads of info. Although it costs some, it is definitely worth it. Hope to be able to again go next year!

Kicked off today with Tom Higgins’ Unity 3D presentation. Bit more on the marketing side than I had hoped. Would have liked to see more of the application. Good news, albeit a bit old if you followed the Flash Gaming Summit news from about a week ago is the SWF exporter from Unity. Tom could not say much about it because Flash Player’s molehill is still subject to change. Unity however is aiming for day zero support and the exporter will probably not support as much features as Unity’s own web player. Not that I use Unity but the following items were new to me: The remote ‘player’ for mobile devices will be available on all licences, also the free licence. The remote allows you to test on on a device while working in Unity on your dev machine. There is an in-app store (with free content too) for 3d models and scripts (maybe even I can get some stuff done now). To me there also was a mystery solved: Unity exports an XCode project if you wanna publish for iOS. Probably therefore wasn’t banned like Flash was for a while.

Stacy Mulcahy (bitchwhocodes)

Stacy talked about the design and User Experience (UX) considerations when developing for devices. Next to the obvious of for example screen real estate there were lovely insights to be gained. Fitts’ law passed with the side note that there’s no containing borders on a device (the finger her being the pointer is not restricted to the screen as a mouse is), Stcott McCloud passed with his TED talk about comics, vision and representation of images and stories on new media. Simple tips like larger hit area’s compared to visible size, ‘activity touch zones of a device (near where your hands are when you hold it) but also Skeuomorphic design (which appears to work pretty well), the Uncanny valley applied to UX and we got advised to read the Apple Human Interface Guidelines even if it was just for the good read it is. Like many presentations there wasn’t time enough…

Grant Skinner

He was up next with ADHD FTW, LOL! and got the silent treatment from the audience. Grant: in the Netherlands that means about the same as cheers in the US; awestruck . His presentation was partly flexing AS3 muscle (in a positive sense) like the Hulk could tear his shirt back in the days but good lessons were to be learned too. Take time to experiment, partly by leaving the opportunity open at all times (buy RAM, leave applications open), but also by giving yourself micro rewards (if I finish this in time I get to experiment. This needs small sprints, not week long marathons). Still it may seem like wanting to escape the daily grind, but experiment serves more purposes than escapism: It let’s you work on stuff which you probably are more passionate about than an assignment for a client. Showing off the experiments may however get you the next (assignment that is). Experiments shown were among others: Slot cars with AIR gas pedal, Androideroids, Record player (which fails to load the experiment today?), experiments with light and spheres, far more evolved than these. Furthermore there was a nice lineup of tools created by GS, his company and friends. EaslJS, Zoë Sprite sheet exporter and some impressive exporter from Flash to JavaScript. Inspiring.

Chris Black

Chris Black I did not know, not that I visit these events often but I stalk a lot on whatever webcast there is. A good listen nonetheless (as if me not knowing him would mean the opposite) in the nice setting of the Influxis Voodoo lounge with live broadcast and possibility to ask questions through their chat. You can see Chris’ slides on slideshare. He gave his insights on making money with mobile apps using wit and tools like ad words etc. Funny thing was that target demographics data was collected by experiment, not desk research as often taught where I teach.

Keynote

Quickly ran to the Adobe keynote. Some previews of the next Flash Professional, Flash Builder and Flex. More and more in the direction of mobile development. Testing on devices while retaining full debug possibilities, Flash builder has more features like quick assist which I think FDT already has, Flex has a lot of components updated for use on mobile devices, Molehill was presented (again) as was Mandreel‘s impressive story of a port of a Wii game to the Flash player.

Rob Bateman

He was one before last. The cocreator of Away3D talked about some topics Molehill and Away3D 4.0 make possible: Lighting, textures, millions of polygons and some dynamics. Illustrated by demos and videos. guess you had to be there. OK, here’s some stuff he showed: Richard Feynman about light, simulation in 3D worlds (funny, real or not), crappy human perception shameless abused by computer simulations and the JiglibFlash physics engine that can be combined with Away3D and the Molehill API. Some techniques were illustrated using videos created by The Guerrilla CG Project.

Tom Krcha

Tom Krcha, Adobe platform evangelist talked in the packed voodoo lounge about peer to peer applications ranging from video on demand, file sharing to several game applications. P2p was something I completely missed until now. Something to think about for sure.

Oh my, now I need a beer in the hotel bar. Maybe something stronger with the classic napkin under it