The second day of FITC Amsterdam was another day full of great presentations. This is what I saw (and remembered).
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
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:
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.
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
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)
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…
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!