2012-12-14

How to Create Custom Macros in Twine

This post is a technical article for the Twine hypertext authoring system. I will assume a passing knowledge of Twine/Tweecode and an intermediate knowledge of Javascript. This tutorial applies to version 1.3.5 of Twine - and even further still I assume the latest betas.

There is a bug in the current v1.3.5 Sugarcane and Jonah story formats; custom macros will not work during the display of the "Start" passage. The Responsive story format does not have this problem.

I'll start with a simple macro example then explain it line by line. Put this code into it's own passage. The passage title can be anything. Give the passage the tag "script"

try {
  version.extensions['macrodemoMacro'] = { 
    major:1, minor:0, revision:0 
  };
  macros['macrodemo'] = {
    handler: function(place, macroName, params, parser) {
      new Wikifier(place, "Hello World!");
    },
    init: function() { },
  };
} catch(e) {
  throwError(place,"macrodemo Setup Error: "+e.message); 
}

Let's go through the code a piece at a time (not necessarily in written order).

try {
  ...
} catch(e) {
  throwError(place,"macrodemo Setup Error: "+e.message); 
}

This code sets up basic Javascript exception handling to let you know via a popup dialog when there is a problem in the macro code. Custom macros are inserted into the page at runtime so they can be difficult to debug. This exception handler makes things a bit easier. Technically this is optional, but trust me, it's worth adding. Just change the "macrodemo" text to the name of your macro so you can tell multiple custom macros apart.

  version.extensions['macrodemoMacro'] = { 
    major:1, minor:0, revision:0 
  };

This statement registers the macro with an extensions array. This is totally optional and appears to currently have no effect. If you are making a macro for re-use in many stories then it's a good idea to store version information so why not do it here. Maybe one day it'll be useful. I've taken the macro name and appended "Macro" just to be consistent with the way Twine's in built macros are registered.

  macros['macrodemo'] = {
  ...
  };

This creates the javascript object that holds the custom macro. The macro name in this case is "macrodemo" and you should change this to suit. The title of a macro should not contain spaces, double quotes or any characters that might confuse twine. There are two required functions and you can also add any other macro related variables inside the object.

    init: function() { },

This function is called when Twine is setting up the macro object when the story is started. This is where you should also initialise any variables because init() is called whenever the story is restarted. In many cases an empty function (as above) works just fine. There is no guarantee which order init() functions will be called, except that generally the inbuilt macros have their init() method called first.

    handler: function(place, macroName, params, parser) {
      new Wikifier(place, "Hello World!");
    },

This is the actual code that is executed when your macro is called. A macro is passed four parameters, the most important of which are "place" (an HTMLContainer where text is currently being output to) and "params" (any parameters passed to the macro). Parameters are split into an array on space characters except within "double quotes". The macroName parameter is self-explanatory. The parser gives a reference to the current Tiddlywiki parser object - which is useful only for some advanced cases; e.g. if you were writing a macro that has a corresponding end macro: see the inbuilt if, else and endif macros or my while loop macro for examples.

The example code here shows how to do simple text output which is added in place of the macro call. Most Twine macros will want to do something similar to this.

Once the macro is in place then somewhere in your Twine story go:

Custom macro: <<macrodemo>> 

Rebuild the story and you should see Hello World! Congratulations you have written your first macro.

BUG: Backslash characters do not encode / decode correctly from the passage store. Use a workaround such as: String.fromCharCode(92).

TIP: Since the latest betas support multiple source files via StoryIncludes, I like to put macros into separate text (.twee) files just to make organisation and reuse easier.

Macros are a powerful way of adding functionality to your Twine stories. The full power of Javascript is available to you. If you make a good macro then please share.

2012-11-26

Arduino LCD: Defuse

This games is about finding a bomb in a 100 x 100 x 100 cube. That's 1 million possibilities. To help out the player is given a mysterious bomb detector. There is 200 seconds (20 turns) to find the bomb. Each turn the player gives coordinates and the scanner returns a new reading.

Code: http://eturnerx.com/files/arduino/014_defuse_eturnerx_arduino_lcd.html

This time I made some quite big changes to the game. I cut some of the flavour text for illegal moves. For example, if you input numbers too large or small then you'd accidentally step outside the building and fall to your death. Also, the original game uses a fixed algorithm for building the scanner reading. Once you know this algorithm them you can theoretically win in one turn. Instead I made the scanner algorithm change every game. This gives much more replay than the original. It is still very easy to win though and 20 turns is perhaps too many. In my first attempt I won in 8 turns and that included making many errors and inefficient plays.

HINT1: The scanner does not give a pythagorean distance, but it is a strength reading.

HINT2: Get each digit of the scanner to a 9

SPOILER: Each scanner digit is the nine minus the difference between the bomb's position and the scanned position for that digit. The order of the digits is intentionally mixed up. Work digit by digit. Go with "9 minus the most common digit" as your first guess. Once you've located the coordinate digit on the scanner then you can test for value at the same time you locate the next coordinate digit.

Checkout the other games I have converted.

2012-11-21

Arduino LCD: Game Conversion Recap

I have completed converting seven old text based games for the Freetronics 16x2 LCD Arduino Shield. I choose this era of gaming because it was perfect for the LCD Shield and to pay my dues. As a child, I learnt to program by copying these types of games from books and modifying them. It's almost duty to give a new life to these things that helped form me. I got better and faster at making such conversions and learned some good lessons along the way.

A main loop controlled by a switch() statement is a good way to organise a program. They allow extensibility and focus. I already knew this from my other programming experience and it was no different here.

Arduino's have limited heap memory of about 1Kb. You get no warning that the heap is exhausted, instead variables end up with weird values and you won't know why. Text strings use up heap memory too. In a few games I needed to used PROGMEM to get around this limitation.

Showing a routine message on a delay is better than making the user click through them. The earlier games require more clicking and the later games just felt better because they were less "clicky". Of course non-routine messages should require a click.

It's easy to flash the backlight, but it's not always a good idea because it can throw a user's comprehension of text out. Save it for the really important stuff only.

Keep videos short. Everybody loves videos and code, but they won't watch an epic. In later conversions I aimed for a minute and treated it more like a teaser than a play through. Youtube analytics shows this approach seems to be paying off when it comes to audience retention. My skills with Windows Live Moviemaker also increased; it's perfectly fine for this type of work and much cheaper than the pro-packages I have at my workplace.

I think that today's gamers expect more of a challenge. Or maybe that's because gamers are much older than the 1970s. I made Hunt the Wumpus, Acey Deucey, Mugwump and Defuse more difficult than the originals while trying to preserve the original spirit of the game.

It did take some thinking to fit UI onto the 16x2 char screens. Many games had a lot of text and status to show and it became a matter of focusing on the key variables that drive the game. Text lines often needed rewording and this was done to preserve as much flavour as possible. A few of the games (Wumpus, Highnoon, Camel)use a side scrolling menu.

The list of games are:

I enjoyed doing this series but it's now time to move onto other Arduino related projects. I may continue to do old game conversions into HTML using Twine as a break from my other priorities. Keep watching the Games Conversions label on my blog. Thanks for watching.

2012-11-20

Design Demons: The Pragmatist Demon

An earlier post gave an overview of the design demons: Creative, Critic and Pragmatist. This post takes a closer look at the Pragmatist Demon. A designer should develop ability in each of the each of their demons so that the overall team is stronger.

The Pragmatist demon ensures that things gets done. The Pragmatist can be overly economical and un-ambitious in the quest to get things completed. When the Critic Demon is insisting on quality and the Creative demon is insisting on novelty, an overly strong pragmatist can overrule these to complete a solution that is too watered down. The Critic demon is most useful at the beginning of a project (feasibility) and at near the end (deadline crunch). The Pragmatist demon will stifle good ideas from the Creative demon if the Pragmatist is too loud during the concepting phase. The Pragmatist demon's favourite word is: trade-off.

The problem with trade-offs is that the value of a project can be deleteriously compromised if the novelty or quality is watered down.

The underdeveloped Pragmatist demon is unable to set and meet deadlines. The underdeveloped Pragmatist will allow the Creative demon too long to discover the perfect idea and allow the Critic demon to continually nitpick at problems in the design. A person with a weak Pragmatist demon may be full of good ideas and even have some projects started - but little is actually finished.

The strength of the Pragmatist demon can be improved through practice. Set clear constraints (budget, materials, deadlines) for projects and stick to them. Completing work is the life-force of this demon. Any study into process, workflow and project management will permanently strengthen this demon. Writing proposals and problem solving in constrained situations are the Pragmatic demon's gym workout.

The noisy pragmatist will unnecessarily hurry the Creative and Critic demons into doing substandard work. The noisy Pragmatist will discourage the Creative demon by saying the ideas are impractical. By prematurely constraining the Creative demons then concepts might be unnecessary weak. The noisy Pragmatist might overrule the quality decisions of the Critic and this could ruin the polish of the project. However, a noisy pragmatist that gets work out the door is probably the least worst noisy demon because getting stuff done matters most.

A noisy Pragmatist demon can be taught to speak only in turn. Force yourself to use a standard process for projects and do not deviate from the standard process without permission from a mentor. Allow the Creative and Critic demons space to speak before applying "practical" constraints.

A weak Pragmatist demon is best trained through the successful completion of many projects. One way to do this by setting constrained projects (time, budget, other) that must have an output. This will improve the Pragmatist's ability to estimate feasibility going into a project and the constraints will force the Pragmatist to balance priorities in the later stages.

A strong Pragmatist demon is important for a designer to select good projects and complete them on time and in budget. Working to improve the Critic demon will give long term benefit to the designer because completed projects are better than incomplete projects.

2012-11-18

Arduino LCD: Nicomachus

This is a game that is a simple "guess your number" game based on an algorithm published in 90AD. Think of a number between 1 and 100 then answer three questions about it. The original BASIC game is by David Ahl.

Code: http://eturnerx.com/files/arduino/013_nicomachus_eturnerx_arduino_lcd.html

This was a pretty quick conversion. I cut much of the flavour text - including a taunt to recheck your arithmetic if you disagreed with Nicomachus' answer. Having said that, I was surprised at how often people would get a remainder wrong during testing. Maybe the taunt should've stayed. If you'd like to play a more faithful conversion then try my online playable version of Nicomachus.

Checkout the other games I have converted.

2012-11-11

Arduino LCD: Camel

This is a game that is kinda like a cross between Oregon Trail and Highnoon (arduino, html). Make your way 200 hundred miles across a desert without dying in deliciously anachronistic ways.

Code: http://eturnerx.com/files/arduino/012_camel_eturnerx_arduino_lcd.html

I had to alter the text to suit the smaller screen, but did try to preserve the tone and flavour. There are some minor differences to the original game. I used the PROGMEM technique used in my Highnoon conversion to fit all the text into memory. See my Camel Conversion for Twine writeup for more details on the game logic changes and information about optimal strategy.

Checkout the other games I have converted
I have also converted an online playable version of Camel.

2012-11-08

How to Simulate for, while or do loops in Twine


UPDATE:I have written a proper <<while>> macro. The techniques below will still work but you'll probably find the new macro much easier.


Tweecode (used by Twine) does not have any notion of a loop but they can be simulated with <<if>>, <<set>> and <<display>> macros. The trick is a computer science trick called recursion where a piece of code repeatedly calls itself. So just think of passages as pieces of tweecode (functions) and the <<display>> macro as the "Call Function" command.

An example while loop

::Start
You knock at the door; <<display "WhileLoopDemo">>
The door is answered by a sleepy giant.


::WhileLoopDemo
<<if Math.floor(Math.random()*100) lt 70>>
knock <<display "WhileLoopDemo">>
<<endif>>

The Math.floor(Math.random()*100) code selects a random number from 0 to 99. See how the loop passage keeps on calling itself, until finally there will be a random number 70 or greater and the passage will exit back to where it left off in the start passage.
Demo, Code: .tws | .twee

An example for loop

::Start
Example for loop demo. <<set $i = 0>><<display "ForLoopDemo">>
Done!

::ForLoopDemo
<<if $i lte 5>>
<<print $i>>... <<set $i = $i + 1>><<display "ForLoopDemo">>
<<endif>>

The for loop example is slightly more complex because it must setup a counting variable and increment this on every iteration of the loop.
Demo, Code: .tws | .twee

Note: The double-colon :: denotes the start of a new passage. The rest of the line following the double-colon, up to an option opening square bracket [, is the passage title. This text following the start of passage (until the passage start) is a the body of the passage.

It is possible to create custom macros that would make loops in tweecode much easier; I might even do this one day. However, if your Interactive Fiction work is relying heavily on tons of loops then it is probably time to look at implementing that functionality in JavaScript directly for efficiency reasons.

The Nicomachus includes a demonstration of a loop in a fairly simple piece of code. If you're a JavaScript wiz then you might be interested in how to create your own macros. Let me know in the comments if there are other Twine related topics you'd like covered.

2012-11-04

Joust Conversion for Twine

Here is a conversion of Joust. This is another one of those games I copied from source in a book to learn how to program as a kid. Bringing these old games back to life is like paying my dues.

This is not a difficult game - you will play through it in just a few minutes. There is also not too much in the way of flavour text compared to other games. I'd rate it as about the same as Highnoon in terms of depth but the game play feels much less varied.

SPOILER: Once you work out a winning attack / defense combo then keep repeating it and let luck do the rest.

The game logic is entirely implemented in Twine/twee code. This could've been much simplified by using custom javascript macros to handle the logic branching or even by coding a "switch...case" macro system for twine to substitute for "ON X GOTO line, line ..." code from the original. I used if, else, endif blocks and despite being a bit complicated and verbose they did handle the task well enough.

Debugging something with such tricky logic wasn't easy but I used a couple of tricks. These might be useful to other Twine/twee code authors too.

TIP1: Debug nested if, else, endif blocks by copying into another text editor and indenting like a regular programming language.
Complex nesting of if, else, endif blocks can be annoying to debug. The are formatted in non-obvious ways to suit the needs of end display, not the programming. So, just for the purposes of debugging, try indenting it as if it is a programming language.

TIP2: Debug nested <<display>> chains with html comments. e.g. <html><!-- PassageNameX --></html>
Chasing around through multiple display macros gets hard. Add html comments to insert invisible stuff into the code so that you can inspect the page and track where the display macros are leading. It helps narrow down where the bugs are really quickly.

Checkout the other games I have converted

2012-10-28

Camel Conversion for Twine

Here is a conversion of Camel. I can vaguely remember coding and playing this game as a kid in the early '80s. If it left that kind of impression then it must've been a fun game so I decided to give this a shot for a Twine conversion. It is similar in many ways to Highnoon in that there is an underlying game system represented by some quirky text.

The game play can be frustrating! Oases appear frequently enough that water is almost never a problem (just don't forget to drink). The biggest problem is the pygmies. They have a 10% speed advantage on your moderate speed, but running your camel at full speed burns it out three times faster.

SPOLIER: The mathematically optimal strategy is to go full speed twice, moderate speed once then rest. Drink when warned (actually the turn after). If you are captured then wait for the ransom. Even with an optimal strategy a win is not assured. In this game the player loses more often than not. Prepare for frustration.

I made extensive use of the custom macro <<randomp>> that I made for another project. This simplified a lot of the handling where things were triggered by random events.

I intentionally left as much logic in place as it is in the BASIC code with a couple of small changes. The capture submenu display the request for sub-command before the menu and the "Miles travelled" text appears more than in the original. There was also something where asking for a status report would fall through to also taking a drink. I assumed that this was a bug and changed status report to not force a drink at the same time.

From the viewpoint of 2012 the text could appear offensive. I prefer to think of it is ironically anachronistic because there are many obviously mismatched facts and intentional mispellings. Many of the other books edited by David Ahl do contain some quite detailed information about the historical context of the games so I do not assume the authors of this game were naively flavouring the game they way they did.

Checkout the other games I have converted

2012-10-22

Nicomachus Conversion for Twine

Here is a conversion of Nicomachus for Twine. This was a much simpler program than Highnoon so I further restricted myself to making all program logic happen in Twine's tweecode.

Twine surprised me with its arithmetic handling. Up until now I had been ducking into Javascript for all but the simplest of expressions. Twine was easily able to handle an arithmetic statement with three sets of parentheses and about six terms.

Twine does lack a loop function (like a while). I was able to simulate this with an if, else, endif macro that keep displaying another passage (itself) until the condition expired. You can check the code for how I implemented this. The technique is known in computer science as recursion.

The verdict; A fun quick conversion.

Checkout the other games I have converted

2012-10-21

Arduino LCD: Mugwump

This is an old game I never recall playing but it was one of the inspirations for Hunt the Wumpus and it has some elements of a game I was thinking of writing. There are four mugwumps hiding at random locations in a 10x10 grid. The user supplied an x & y coordinate to scan and is told if they have located a mugwump. The user is also told the distance to any mugwumps not yet found. The game ends after all mugwumps are found or then turns.

Code: http://eturnerx.com/files/arduino/011_mugwump_eturnerx_arduino_lcd.html

Mine differs from the original in a few minor respects; distances are rounded to the nearest integer in order to fit the display. Distances over 9 are simply not given. These small changes only make the game slightly tougher and most games can be completed in seven turns.

This looked like an easy game to convert; and it certainly is much less complex than many others. The kicker is that much of the supporting historical information is not in place and the game is kinda tough. I spent more time writing a wikipedia article and creating an HTML5 based game cheater *cough* helper than doing the Arduino code.

Checkout the other games I have converted

2012-10-15

Arduino LCD: Acey Deucey

There's something satisfying the challenge of fitting games into the limits of a 16x2 character display. This week I did a version of a card game called Acey-Deucey. The basic rules of the game are: first the player antes into the pot. Then two cards are dealt. The player may then bet on whether or not a third card will be between the first two cards. All you need to do is outlast an Arduino-AI opponent.

Code: http://eturnerx.com/files/arduino/005_acey_deucey_eturnerx_arduino_lcd.html

I did make some small changes to the game as it is played live:

  1. Ace is always higher than King and never lower than 2
  2. Pairs do not result in an automatic penalty
  3. The ante increases every few turns

A player can pass by betting "0". A player's maximum bet is limited by the size of their stack and the amount still left in the pot. The AI will bet only when the spread (distance between the two cards) is seven or greater. The AI bets more with wider spreads but will bet only up to half its stack. This is not a bad default strategy.

Since this game is mathematically solveable for optimal long-term play I intentionally made the Arduino-AI a little stupid; the AI does not count cards. There is a single standard 52 deck (4 suits, 13 ranks) being tracked and you are told when the deck is reshuffled.

You can gain a big advantage by simple card counting. Counting 234|QKA versus 6789T should do better than chance. You gain even more of an edge by tracking ALL cards and counting the ratio of good vs bad cards; Just how poker players count "outs". If you're really nerdy you might even try Kelly betting. Hey, whatever you find fun :)

Checkout the other games I have converted

2012-10-07

Highnoon Conversion for Twine

This week's creative project is a conversion of Highnoon for the Twine interactive fiction system. While I was converting/reimagining for Arduino I had two thoughts. The first was that I'd like to do a more faithful conversion with the original dialogue and secondly that such a conversion would be a way to demonstrate the power of Twine.

So, you know the game; You're in a showdown with Black Bart. You each have four shells and are 100 paces apart. In this original version there are more win/loss conditions than straight death.

Twine allows quite a lot of expressiveness and flexibility when writing interactive fiction. It also outputs the results to a single .html file that require no supporting libraries or other files. If you are interested in the basics of Twine then I'd suggest looking at this tutorial.

The conversion to Twine was fairly straightforward. I used the Jonah Story Format because it places passages one after the other without clearing the screen like Sugarcane does. I made a few tweaks to the inbuilt functions; the first to totally suppress the output of passage titles and the second to totally deactivate old choices. This was not difficult; it was more a matter of removing the bits of code from existing functions that I did not need.

I also based passage names around the line numbers in the original code. This eased moving from the GOTO style of the original code to the structured coding style of Twine.

The verdict; a very playable old-style game.

Checkout the other games I have converted

2012-10-01

Arduino LCD: Highnoon Conversion

This week is a conversion (strictly a re-imagining) of a game from 1970 called High Noon. Try to kill Bart in a shoot out! Your have a range of options that can be accessed using the left, right and select buttons on the Freetronics 16x2 LCD shield. After your turn Bart has his turn. The video shows only a few of the things that happen in the game.

Code: http://eturnerx.com/files/arduino/004_high_noon_eturnerx_arduino_lcd.html

The AI is probably tougher than the original. The text prompts were shortened to fit the screen and a few new things added for flavour though the essential game is the same. A few edge cases (running away) were changed and the being shot in the back was also changed. Any action the fails, standing still or walking/running 0 paces results in a penalty making you easier to hit.

The implementation uses a state machine in the main loop in the same way that the Hunt the Wumpus conversion did. In addtion, the static string data grew too big for the working memory on the Arduino so I needed to use the PROGMEM trick and create a string table.

If you are interested in a more faithful, online playable version then check out my HTML conversion of Highnoon.

Checkout the other games I have converted

2012-09-24

DPI & Compression Problems - demo PDF

Seasoned print designers know all about DPI, but it is difficult to convince design students unless they are shown an example as to what can go wrong. I made this sheet where the same image is shown at the same size except in 300dpi, 70dpi and 30dpi. I also included a badly compressed JPEG so that students will know what to look for.

The correct DPI to use will always depend on the printer that is being used so ask! If the DPI is too small then some blurring and pixellation will occur. This can be seen where the text is not clear and where there are square step blocks.

The poorly compressed JPEG shows how the textural detail in the wall and sky are flattened out and bruising artefacts appear where there is a change in contrast (e.g. around the text).

Having a poorly compressed JPEG and DPI that is too low is a double blow to the quality of the output image.

Feel free to share the document. Link: The DPI Problems PDF

Note
maximum_display_size_in_inches = pixel_size divided by the DPI
   (there are 2.5cm in an inch. So, approximately 4 inches in 10cm)

2012-09-23

WorkOut Poker Episode 3: HUD

Continuing on with first steps towards an ExerciseUI, this episode adds on a HUD to give stats that help decision making while playing.

The HUD shows VPIP / PFR & AGR / 3Bet stats. These are only basic but there was not much room for any more since the size of the numbers needed to be increased.

I had the dreaded problem where the Kinect would stop updating in FAAST. It turns out that the shortcut I was using to launch FAAST lost "Run in Administrator" mode and you should disconnect the Kinect power USB converter from the computer after a reboot. It was fiddly but once it was running it was rock solid.

Getting the HUD running was not trivial. It causes a huge load on the computer to run FAAST, PokerStars and Holdem Manager 2 at the same time (while I was recording). The FAAST display would sputter and gestures would not be recognised. The solution was to use ImDisk and move the HEM2 database into RAM. I also made a different ImDisk RAMdisk and recorded the video straight to that. Time to buy an SSD.

The HUD stats were useful. There were not many hands on the other players but even still some information was better than none.

Episode List
Episode One: Basic Functionality
Episode Two: Bet Sizing
Episode Three: HUD

2012-09-19

A Question of Professional Ethics and Friends

Professionalism and ethics questions between two parties are fairly cut and dried. However, things can very quickly get murky when muliple parties are involved. Justice asked me to advise on a situation.

Justice works for DesignStudio and they have a large client account BigClient. Recently BigClient employed an in-house designer called Riley. Coincidentally Justice and Riley happen to be friends who both move in the same active social circles. One day Justice overhears the DesignStudio execs wondering why they are now getting less work out of BigClient than before. They are discussing the latest design outputs of BigClient and wondering where they are coming from. Justice knows from social conversation with Riley that Riley turned out better than BigClient expected so BigClient is giving more work to Riley instead of taking it to DesignStudio.

Should Justice tell the DesignStudio bosses or not? I would say no.

Telling DesignStudio bosses might win some brownie points and demonstrate loyalty towards DesignStudio. But Riley probably did not intend the information about extra work to go any further than the social group. If DesignStudio bosses acted on this information and spoke with BigClient then that might make things difficult between BigClient and Riley.

One could think that Riley should be more careful with what they say but add in a couple of drinks and people toasting each other's accomplishments for the week and it's easy to let things slip. Telling the DesignStudio bosses is acting in the employer's best interests but loyalty between friends should count too.

There needs to be some leeway and forgiveness between friends. Firstly it would be a sad world where friends could not privately discuss some aspects of their work out of fear of being taken advantage of. People need safe places to vent their excess emotions; happy or sad. Secondly this time Riley let slip some information, next time it could be Justice innocently doing the same. Friendship is not about one-foot-wrong and you get taken advantage of. A good friendship will outlast a job.

For these reasons, if I was Justice, I would not tell my bosses about Riley. DesignStudio's Account Managers will probably be told if they contact BigClient directly and ask.

(Scenario based on a true story, real names not used)

2012-09-16

“Should I study graphic design?” Jobs, Career, Money

Having a suitable personality is only one part of the decision to study design. In these economic times (Economic Crisis during 2012) students thinking going to design school need more certainty that there are jobs, careers and money after graduation.

There are jobs in graphic design in the skills NZ employers want. These are; advanced web, mobile, and cross-media design. There are some jobs in other media and the competition for these jobs is fierce.

In 2012 Web design is no longer a specialist role – it is now part of the overall package expected of an entry level designer. Many first jobs expect a cross-media designer who can apply a consistent visual look across many mediums. Specialist web design roles require advanced HTML/CSS with at least one of the following; mobile design, front-end development (such a jQuery), serverside skills or CMS skinning.

The NZ Government Careers advice section now says:

Number of design graduates increasing, which has created more competition for jobs. Because of the high numbers of design graduates, competition for most entry-level design jobs is high. Employers often prefer to hire people who have specialist knowledge and/or experience with design programs. People wanting to enter design jobs may have work on a short-term or freelance basis, or volunteer their time, before they can get full-time work.
Why is website gloomy? Their definition of graphic design is narrow and outdated. Print is seen as key and web only gets the barest mention. This does not reflect the reality of the job market.

Now entry level jobs pay less, expect more and require new hires to be immediately profitable. There is no time or patience to train because employers can be choosy. A new entrant designer might earn just over minimum wage until they have proven themselves. Employers now use word of mouth to fill entry-level positions because they do not want to deal with the hundreds of unsuitable applicants who apply to any and every design job ad. How does this affect the decision where to study design?

Does the design school have specific training in the skills, mediums and technology that are currently employing. One red-flag phrase you might hear is: “Technology changes but good design does not”. This view ignores the rising role of the aesthetics of time and interaction and neglects how a viewer's relationship with a medium affects communication. Each medium has its own peculiarities that require specific skill masteries. Furthermore, that red-flag line would be unaffected if the students were trained in more employable mediums. It is simply no longer enough to hope an overall strong aesthetic sense will be enough without employable media skills. Consider also how the school is working with future technology. Graphic design and technology have always gone hand in hand and big changes are coming.

A good design school will have a strong visual culture. Most will claim they do but check the work by attending their graduate exhibitions. Look at the typography. Look for a variety of work in different styles. Look for consistency of design across mediums. The work should be aesthetically rounded and conceptually pushing boundaries.

How successful are graduates of the school jobs in design? While finding you a job is not the design school's role, the percentages of graduates transitioning from study to jobs in graphic design within six months of graduation can be telling. Beware of the super-star stories; “Famous Person studied here”, "we have graduates working for Famous Company". A few super-stars is not a good indicator of an excellent course because some people will just succeed despite their education. Instead look at what happens to the average graduate. How are the B students doing?

There are far easier ways to make a living than graphic design but it is a very rewarding field full of change and challenge.


Read more articles about graphic design careers.

2012-09-15

WorkOut Poker Episode 2: Bet Sizing

Continuing on with first steps towards an ExerciseUI, this episode makes some improvements to existing gestures and adds gestures for bet sizing.

Some of the existing gestures needed a bit of fine tuning so that they would trigger more reliably and not trigger at unwanted times. The gesture for fold changed into three raises of the knees in either a left-right-left or right-left-right pattern. This is to allow some variation in the marching step used to fold. The previous left-right pattern just didn't quite feel right when playing.

In the last episode the Kinect would stop updating in FAAST. This was edited out of the video, but having to restart FAAST every seven or eight hands was tiresome. To anybody else having this problem, the answer is to run FAAST in administrator mode and to plug the Kinect into a USB that connects directly to the motherboard. Usually these will be on the back of the computer. It seems that the Kinect does not play nicely when going through intermediary USB hubs.

There are four betsizing actions for 33%, 50%, 75% and 100% of the pot. It was ticky getting the 50% and 75% actions to distinguish from each other. Doing cross hand above the shoulders move would trigger both the 50% and 75% pot size bets. I did manage to get something workable, though some care must be taken such as; squarely facing the Kinect camera, pausing after raising hands and pausing after hands are crossed. I hope to make this even more robust in future.

The increased stability meant I got in a 50min poker session. I ended this voluntarily - the software was rock solid this time. The activity level is still very low but it does beat sitting around. The next episode will experiment with multi-tabling to see if that improves the activity level to something more resembling a workout.

Episode List
Episode One: Basic Functionality
Episode Two: Bet Sizing
Episode Three: HUD

2012-09-09

WorkOut Poker Episode 1: Basic Functionality

In a previous article "The ExerciseUI" I explored the idea that exercise should be something integrated into our daily workload. Technology is becoming cheaper and easier to use. Here are some baby steps.

I happen to really like Poker, so I made some custom gestures in the FAAST Kinect software for PokerStars. The three man gestures are: fold, check/call and bet.

Playing one table of Zoom poker creates a low tempo of activity. The most common poker action is folding so this is linked to the most common exercise: walking on the spot. The other actions require big hand movements with energy levels that correspond to the severity of the action.

This is early days yet; there is much more to do. While the activity levels are low, making this control more than one table will improve the tempo considerably. I also hope to estimate loads placed on different muscle groups to vary the gestures for actions to meet exercise goals. In this way we can work AND exercise.

Episode List
Episode One: Basic Functionality
Episode Two: Bet Sizing
Episode Three: HUD