Great linear downpitched whine from the electric motors throughout the breaking zone. Near-silent whoosh from the diesel at high speed. Tractor-y chug and rumble at low revs. Near-instant hiss from the turbo under acceleration. It is wonderful to hear all these technologies working together in one machine. What an amazing piece of kit.

I’ve been playing with the HTML 5 video tag. I’m trying to get an accurate reading of the frame that the movie is on when it is paused. I’d also like to play the movie until it reaches a certain frame, then pause it.

It seems like both of these tasks are hard using HTML 5 video. You can only ever get the “currentTime” of the movie, which gives you progress in seconds, not frames. With about an hour of experimentation, it proved difficult to translate the time into a frame number in a robust and repeatable fashion.

Also, there is a event fired by the video object called “ontimeupdate”, which I thought I could use to measure if the video had progressed past a certain point, and if so pause the video. It turns out the event is only fired every 0.250 – 0.350 seconds on my testing machine (i7 iMac). This is too infrequent to be very helpful for stopping at a specified frame. I guess you need about 1/(2*frame_rate) seconds between events to be frame-accurate.

For all the things that the web does well, I think audio and video are still fairly new tech. New audio and video APIs are required.

Has anyone got any experience with precisely controlling web video? Can you suggest another approach?

Last weekend was Global Game Jam. Let’s Make Games organised the local party, held at ECU Mt. Lawley. GGJ is a 48-hour event where the aim is to build a game from scratch using a theme as inspiration. This year’s theme was an image of the Ouroboros.

Brave jammers attempt to spend as much of the 48 hours awake and working as possible, I was limited to 8pm-4am on Friday, 12noon-1:30am Sat and 11am-6pm Sun, about 28.5 hours. I joined up with Liza, Minh, Ben and Brock to make a game called “The Crooked Spiral“.

Liza and I had a fairly quick brainstorming session where we came up with the initial idea: The player would decend a spiral dungeon where the end looped back to the beginning. Player would be stuck in the loop until they learned the “trick” to jump out of it.

Here are a few thoughts about my first game jam. I apologise that it is a little programmer-centric.

Good bits:

• Two artists in the group meant that the programming was the slowest bit of the team.
• Final Cut Pro was used to create intro movie. This saved us heaps of time, we could play a movie rather than code timings for swapping between static images.
• We used HTML/Javascript for everything, including “video” tags for the videos. I much prefer to work from scratch than to use a game engine or libraries, but it occurs to be that this may be selfish programmer behaviour, since the end product will be far more limited.
• We used JQuery .fadeIn() and .fadeOut() to show and hide bits of game (intro movie, control screen, hud, game canvas). We did very little management of the “mode” the game was in, we just showed/hid different “div”s and bound different key handlers as required. This ad-hoc code caused zero problems, rather surprisingly, though it is irksome to look at.
• We used two different animation methods. One method used canvas 2d drawImage() to draw the correct sprite from a sprite sheet. The other method used css webkit/moz extensions to animate the image. Ideally we would have used one method for this, but by using two methods, each programmer could use the method with which they were most familiar, allowing faster progress.
• We kept task cards using Trello, it was great for tracking the TODO list.
• Cool group dynamic. Lots of re-imagining and re-designing. Great camaraderie. Group members were patient with my slow coding!
• Our game has a splash screen, intro movie, controls screen, gameplay, 4 endings, GUI, Music and SFX. It is broadly complete, even though the gameplay is SUPER simple.
• I think this is the first game I’ve written with an event loop since ZyberFlux. Not that I wrote the event loop for that either.
• Friday night everything was in one file (main.js). On Saturday morning I spent a little while breaking it up into many files. It wasn’t a task on the board, but was a good thing.

Less good bits:

• Rendering was done two different ways. One way maintained a game-state model using data structures and drew images to a canvas 2d. The other half used the DOM to maintain game state in “div” and “img” positions, moved “div”s around using jQuery.
• My initial choice for the way to store coin positions made collision detection with the player (seem) difficult. I started trying to do collision detection properly on Sat afternoon, but kept running in to troubles that my tired brain decided to avoid. It took a day of adding other simpler features, two discussions with Minh and an A4 sheet of failed trigonometry to figure out the maths.
• Ate crummy food for 48 hours but didn’t feel too bad afterwards. Thanks to the organisers (Minh) for supplying fruit and water.
• We were super-conscious of how we’d have to cut back the idea. Two members of the group were the Chief Organiser and a Videographer, so the end product is very simple.
• The release .zip file is huge (90mb). All we did was zip up the whole game directory that contains Final Cut projects, Illustrator files etc. At some stage I’ll remove all the unnecesary files and produce a smaller release file.
• I remember being pretty grumpy at several points. Luckily my team mates were understanding rather than confrontational
• We didn’t use version control, just a shared Dropbox directory. Good stuff: very quick startup, easy for artists. Bad stuff: One person editing any file at a time, manual coordination. No backups. Dropbox got flakey for 10-20 mins Saturday night.

At times it was challenging, at times I wondered what was so fun about it. But all-up, it was a great experience.