JustinLiew.Com

Long Time No Post

Justin — Sun, 10 Apr 2011 20:12:42 +0000

I guess I can finally admit I can’t keep up with blog entries like I once did. Here’s a quick rundown of some random stuff we’ve been up to:

Had dinner at Vicky’s place with Harvey, Leslie and Shmom. She made some great pulled pork and we watched some hockey.

Ran the Ft. Langley Historic Half 5K with Jess, Fran and her dad. We all did pretty well for our first run of the year and a cold one at that!

Joy & Paul came by for dinner and a nice evening. We’re trying to see them more. Paul is doing well with his contract work with Massive Bear and Joy is enjoying her new school.

Saw August: Osage County at the Stanley. Was a good play but a bit long, and quite depressing.

Went to the Beach House for Jessica’s birthday. Had a great dinner as usual. They seem to be going for a more casual feel but the food is still just as good. Also had a family get-together at Shmom’s place for her birthday.

Jess is going to Presentation House plays with Christina.

Saw Quidam at GM Place. Was good but lost a bit in the arena setting. Also had a family with a young screaming baby in front of us.

Finishing my squash box games every month and trying to get more friendlies in too.

Saw Richard & Stephanie for some Rock Band 3. Hopefully we’ll see them more this year. Steph is great for him and we hope things work out.

Saw Haroon & Raheel for board games at our place.

Christina & Steve are having a baby!

Had a great dinner at The Boathouse for Christina & Steve’s 1000 days of marriage celebration. Saw most of the bridal party and were able to catch up with some awesome people we don’t see enough.

Work’s going well for both of us – I’m starting to get busy with my project, which is announced this week, and Jess is working hard on the school play which is also next week.

Spring break was a mixed bag – I took the first week off and had a great time at the Aquarium, pool and lots of activities. Jess and Z were sick the 2nd week which made things hard for her on her own.

Went to Liyana’s First Birthday yesterday. Was a great time and will have photos soon.

My birthday was last week. Had the day off and took Z to storytime, had lunch with my parents, went to Digger Park, and then watched a 5-0 Minnesota win over pizza & beer. Perfect day!

Go Canucks Go!

Listening to:

Cut Copy.
Tim Hecker.
Trey Anastasio’s Spring Tour.
The Tallest Man on Earth.
New Radiohead.
New Brad Mehldau.

Playing:

Starcraft II (PC)
Fallout: New Vegas (PC)
Rock Band 3 (360)
Angry Birds/Seasons/Rio (iPhone)
Dungeon Raid (iPhone)
Tactical Soldiers (iPhone)
Perfect Cell (iPhone)
Hunters (iPhone)

Watching:

The Tudors.
The Office (American)
Lie to Me.
Criminal Minds (both)
Glee.
The Wire.

Watching upcoming:

Dexter Season 5.
The Killing.
Sherlock.
Battlestar Galactica (finally!)
Generation Kill.
Boardwalk Empire.
Rome.
An Idiot Abroad.

Reading:

Re-reading The Wheel of Time.
Final Jeopardy.
Baby Brain Rules.
Mona Lisa Overdrive.

Book Review: The Little Schemer

Justin — Sun, 10 Apr 2011 17:32:14 +0000

The Little Schemer is a cool little book. It isn’t a traditional programming book for learning a language, but rather uses Scheme to teach programming constructs. In this case, the main topic is recursion. Information is posed in the form of questions and answers, which makes reading it quick and interesting. Typically it presents a function, parameters, and asks what it should return. Then, once the answer is presented, the reader can then surmise as to the meaning or implementation. It presents problems like this, then slowly gives use cases and helps fill in parts of the function. It is a unique, straight forward way to involve the reader without the typical information-then-exercises format of programming books. The topics are fairly simple, but I still felt like I learned a bit, and also re-familiarized myself with Scheme. The method in which the book presented the information was as useful as the topics themselves.

Recommended.

8.5/10

Book Review: Superfreakonomics

Justin — Mon, 14 Mar 2011 17:08:48 +0000

Superfreakonomics follows on the highly successful book Freakonomics. In this, the authors get into prostitution, the difficulty in rating doctors and teachers, car seats, washing hands and saving lives, and of course the much-maligned climate change section. If you enjoyed Freakonomics, you’ll enjoy this book as it follows in much the same attitude and vein. The stories are entertaining and for the most part informative, but unfortunately their credibility is marred by the vast criticism from the Scientific community about their climate change chapter. Ultimately, this destroyed the book for me as although everything else might be perfectly correct, I cannot take the book seriously knowing that they got things so wrong on the biggest issue in the book.

5/10

Batteries Revisited

Justin — Mon, 28 Feb 2011 18:40:47 +0000

Did some research and updating of my battery needs. With multiple flashes, triggers, and other various devices around the house, here’s what I’m using and why:

1. Alkalines. Sure, we’re not supposed to use them because they’re bad for the environment and they’re not cost effective in the long run. But they’re low dissipation and for things that use next to no power, they’re adequate. I use them for my triggers because with recyclables the AAAs don’t drain from usage, but mostly from dissipation. I could use low dissipation EneLoops instead but for the amount of times I’ve charged my AAAs I feel it’s not worth the higher quality batteries.

2. EneLoop. I’m getting into these now for my flashes, as I don’t use them as much these days. EneLoops hold their charge much better than traditional NiMH batteries, so I won’t always end up with drained batteries if I go out for a quick shoot.

3. NiMh. I still have around 5 sets of 4-AA NiMH batteries lying around. I’ve labelled each set and plan to have 3 sets for my flashes as backups for the EneLoops, plus a couple of sets for various devices around the house such as the 360 controller which we use a lot.

Oh, and I use a Lacrosse BC-900 charger which lets you trickle charge or fast charge batteries and also have discharge/refresh cycles for old batteries. Works like a charm.

What’s your battery setup?

Etymotics

Justin — Wed, 16 Feb 2011 22:51:46 +0000

I picked up a pair of Etymotic hf5 earphones a few weeks back. The decision came down to a few things:

- my work headphones (Grado SR-125) are pretty decent, so I wanted earbuds that provided a similar level of quality. The main thing I found was that the default Apple earbuds were such a step down from them that when I was commuting it was distracting to listen to.

- I decided I would make an effort to take care of them, rather than abusing them like I’ve done in the past. Seems wasteful to me to go through a couple of pairs a year. I chose Etymotics partly for the robustness of cable and earbud mentioned in reviews.

- I wanted something with great noise isolation, as I travel via busy transit and wait on a busy road.

The hf5′s (as most Etymotics) come with 4 different types of buds: small 3 flange, large 3 flange, gliders (similar to your typical in-ear bud) and foam. I initially tried the flange ones as they’re supposed to provide the best noise isolation, but I found them uncomfortable. Plus, they were almost TOO noise isolating and were quite disorienting to use. Eventually I settled on the foam, as they are the least intrusive and once I figured out how to insert them correctly they work like a charm. They provide the perfect amount of isolation – I can’t hear anyone talking but I do have a slight awareness of what’s going on around me. The flange ones seem almost dangerous how isolating they are.

The sound quality once I got everything working correctly is great. They even put the Grados to shame. Much like Grado, they’re more of a “realistic” sound, in that they don’t boost the bass or do anything to artificially create a “better” sound (*ahem* Bose). So things may not sound overly bright, or overly bass-y, but they reproduce the sound faithfully. Makes audience live recordings sound shit, and they’re almost unusable on my PC at work since they tend to sound buzzy due to the electronics. But the main win I’ve found is I can listen to my iPhone at 1/4 to 1/3rd volume, whereas previously I was usually up at 1/2 and above. The quality plus the isolation allows this, and so I feel that they’re (counterintuitively at first) safer for my long term ear health.

Book Review: Life Guide to Digital Photography (McNally, Joe)

Justin — Wed, 16 Feb 2011 22:38:50 +0000

Joe McNally is one of my favorite photographers. He has written a number of books, posts interesting stories regularly on his blog, and can back up his great storytelling and teaching with 30 years of landmark photography. He is arguably the leading ambassador of small flash lighting, and his previous books focused more on this topic. The LIFE Guide to Digital Photography takes a broader sweep and provides a beginner-to-intermediate big picture of photography. Normally I’d pass on a book like this, but his writing combined with his photography, stories, humour, and insight on all things photography make this a worthwhile read for anyone.

He goes fairly deep into lighting – how quality, quantity and colour of light affect a photo. He provides basic info, but also has sections that give exercises or alternative viewpoints into the basic subject, which I found to be the most interesting. For example, he might provide a story of a time he arrived early to get the golden light, and relate that to a suggestion on how the reader might want to try it.

He spends a lot of time on lenses – how telephoto vs. wide angle affect technical aspects like DOF, as well as subjective decisions regarding composition. His section on wide angle lenses in particular was super informative to me, having recently picked one up and struggle occasionally with clutter.

Design elements, colour and composition make up the latter part of the book. These cover basics like texture, pattern, form, and the like, as well as colour temperature, rule of thirds, and types of shots (portraits, detail shots, etc) These chapters read as more conversational which is where the book really shines. The experiences he’s had shooting for National Geographic, People, Life, and more provide a rich background against which he presents examples and teachings.

Overall this is the best “survey” book on photography I’ve seen. The stellar photography, stories and conversational writing make it more than just a pretty manual.

9/10

Friends

Justin — Thu, 10 Feb 2011 21:20:52 +0000

Busy January. Jess back at work, Zayden to my parents every day, plus trying to see friends and the like.

Jon was in town for a couple of weeks with his new girlfriend Carla. We met up with them twice, once to hang out and then we had them over for dinner and games. Was really great to get to know Carla – she seems like a really great girl, and so perfect for Jon. She’s a cook at the River Cafe, likes the outdoors, and has a compatible sense of humour. We played Arkham Horror, a coop game that was probably a bit too geeky for the crowd.

Had a games night with Arieanna, Ianiv, Raheel & Haroon at the Schwebers. Ordered pizza and played a couple of new games: Dixit and 7 Wonders. Dixit is a Balderdash-Apples to Apples hybrid, involving coming up with phrases for abstract pictures and having people choose their interpretation from their hand, and then people vote on which one was the real one. Really fun, but we all wished there were more cards. 7 Wonders is a San Juan-Dominion hybrid that runs fast. Everyone plays simultaneously, so the time to play doesn’t scale with the number of players. Hard to describe, but it’s great fun.

Also had a games night with Arieanna, Ianiv, Nicola and Dave. Did it as a potluck, so we had some great jicama/apple salad, lasagna, and cookies and brownies. We played a couple of more social games, Fluxx and Apples to Apples. Had been a while since we’d hung out with the Beleznays, so it was fun to see them again, and have the 3 musketeers reunited.

Last Sunday we saw Steve & Christina at Tomahawk for breakfast. We never see them enough, so we really want to hang out more, especially since we’re only 10 minutes apart!

Went to Gareth & Karina’s Super Bowl party last weekend as well. Was a good time as usual. We get to see people we don’t normally hang out with, and we always realize we never have enough time to see all our friends. Especially lately, it’s been all about convenience – which babies nap when Zayden does, and who takes care of Zayden. When we get time to ourselves, it’s usually to go out together, for dinner or a movie or something. Most of our current group of friends either has kid(s) or wants to see Z when we get together.

Competitive Code

Justin — Wed, 09 Feb 2011 19:43:23 +0000

I’ve always had in the back of my mind developing some sort of framework for enabling programmers to pit code against each other, similar to Waterloo’s AI Contest. The aforementioned framework had some limitations that hindered development for me, namely that it took an executable but required language support on the server side, plus it ran each executable once per frame of game, so everything was immutable. Interesting, but not flexible enough for me. I’d like to solidify my architecture before starting, so any suggestions on what worked would be nice! Here’s what I’m thinking:

1. flexible enough to support multiple titles. I’d love to see people pit something as simple as tanks in a 2d level, or something more complicated like Dominion AI or Super Mario.

2. always running. This would likely mean some sort of executable/dll upload, so the server could continuously pit code against each other and generate ranks. Then as people updated theirs, it would bubble them up (or down!) the rankings.

3. multiple language support.

4. multiple platform support? I’d love to have an option for limiting memory, or execution time, or something. That’s what we’re faced with in the games industry, so it should be an option. Even running the server on PS3 and making each AI an SPU ELF might be interesting.

Any thoughts on how people would want this to work? Or have people submitted or used something similar that worked/didn’t work? Comments are encouraged!

Debugging Tools

Justin — Mon, 07 Feb 2011 14:00:13 +0000

At a base level, the debugger and print statement are essential tools for debugging features and fixing bugs. They have been around since the beginning and are well understood by programmers from every discipline. In games, however, there are many useful tools and utilities at a higher level that make common cases easier to work with. In no particular order, here are some I’ve found useful throughout the years:

Macro

I’m grouping together a series of tools that provide have multi-purpose use, and do not provide in and of themselves any specific functionality.

Live Tuning

Live tuning is the ability to connect a tool to the game while it is running and utilize bi-directional data to aid in development or debugging.

Examples of data flowing from the tool to the game could be, but are not limited to:

editing world object properties in the level editor and seeing changes in game immediately.
sending commands to the game to carry out tasks such as loading a level or jumping to a location in the world.
telling the game to display certain classes of objects and their properties in game.

Examples of data flowing from the game to the tool could be, but are not limited to:

displaying a list of all NPCs alive in the world in an external viewer.
the state of global objects such as quest states or time of day.
for visual scripting systems, displaying which nodes are currently active and what links have been followed.
debugging script.

Having a common system for connecting which makes it easy for a new tool to add live tuning functionality to tools and the game is key. Having this up and running early in a game’s life cycle enables many more complex tasks to be carried out fairly easily.

Telemetry

Telemetry is the ability for a game to log info discretely as it runs. The first requirement is that telemetry data shouldn’t increase the memory footprint or reduce performance in any substantial way. Another ideal requirement is that it log info to a central database without user intervention, so data can be gathered in the background as the game is developed, and analyzed using the large suite of database tools available. There are two main classes of telemetry data: development data and playtest data:

Development data is useful for fixing functional aspects of the game, and might include things such as: where the game has crashed the most, which asserts have fired the most, which level loads are the longest, where the player got stuck in level geometry, and the like. They are data that can be captured irrespective of the kinds of things developers are doing. Playtest data is useful for experience balancing and tuning, and can include how long quests took, where players stood still the longest, and which dialogue options were chosen. The main point to note is that you don’t want to capture playtest data during normal development, as when testing a bug most developers tend to repeat the same steps over and over again, which skews playtest data.

Logging, including synched logs

Logging is a subset of telemetry. Usually logs are written out to file, and at a minimum should have the ability to write to different channels at different verbosity levels, so gameplay engineers, for example, don’t have to see rendering logs. As well, having a way to merge logs from different consoles when doing multiplayer testing is useful, as a lot of your debugging will likely involve matching up when data was sent from one machine and when it reached another. This merge should take into account some sort of synched time, which is not perfect, but is usually good enough. Another alternative would be to have a tool that can connect to all running consoles and capture data as they run, which gives you the merge for free.

Ini Files, In Game Debug Menu, and Command Console

The ability to change properties of the game is important for debugging. You might want to set the aggressiveness of your monsters, or disable lighting effects to increase framerate, or turn on an unfinished feature for testing. .Ini files let you do this at startup, while an in-game debug menu and a command console provide different ways to change properties or run functions at runtime. Ideally any combination of these systems you implement should use the same underlying system, so you can get access to the same functionality in a consistent manner. Ideally the debug menu and command console are configurable externally, so engineers don’t always have to edit code to add items.

Replay

The ability to rewind and fast forward your game is vital to fixing sequencing bugs – animation state changes, for example. Anything with states can really benefit from replay, alongside having debug output of the state for each character involved. That way, when playing through a game, you can rewind and replay a boss battle in slow motion to see what conditions caused changes in state. This is also good when getting a bug from QA, as you can see the last few moves that were performed before a crash or anomaly. The main consideration for replay is balancing the size of the replay buffer and quality of replay (what is saved). The actual technical details of replay are an article unto themselves, so I will not go into it further.

Crash Dumps and Auto-Reporting

This is a no brainer. When the game crashes on a QA or content creator’s machine, having the callstack of the crash is of vital importance. Ideally, this hooks into the telemetry system and/or the bug tracking system and automatically logs the crash, along with the crash dump, callstack, and info about what level the player was in and other game-specific data. Ideally, your telemetry system or auto-reporting handler can filter on duplicate callstacks and group them together. Perhaps in your bug database the “repro rate” or “occurrence count” can be updated so if a crash is happening frequently these numbers will go up and the priority can potentially be automatically raised.

Soak Tests

When finaling a game, it is always those pesky soak test crashes that only happen after 8 hours of gameplay that threaten the patience of the SE team. Having a soak test system in place that makes it easy for everyone on the team to run them on their machines every night, as well as gather pertinent data about the run, is of vital importance. Having some of the above tools, specifically telemetry, logging, replay and crash dumps, will enable SEs to see what happened throughout the run and work backwards to figure out the problem. Logging info such as memory highwater marks, fragmentation and the like can be useful for out of memory conditions. The type of data you save during soak tests is endless! Soak tests can run pre-recorded replays, or they can randomly press buttons either in-game or in the UI. These button presses can be configured for frequency so that more common buttons (A/Cross) can be pressed more often, while directions can be held longer to simulate more common human control.

Micro

The functions below are more specific, and usually utilize a feature from the macro section above.

Skip X

The ability to skip various portions of your game is key in saving time. Skipping the front end, for example, and directly loading into a level can make it faster to run tests or reproduce bugs. Skipping the bootup screens can let you test the UI quicker. Just make sure everyone tests features within the context of the entire game before deeming them fixed or finished.

Auto connect for online

When developing a multiplayer title, a lot of time is spent navigating the matchmaking or invite flow, getting players into game, only to test a bug for 30 seconds. Added up over the project, this is a huge time hit. Using various macro tools, the ability to configure the game to launch as a host and start up a multiplayer game, and launch on another console as a client and connect to the host, can be a huge help. Just ensure that you’re doing final testing through the proper UI.

Teleporting Players/NPCs

I’ve seen this useful in a couple of instances. When doing multiplayer testing, especially for coop games, it’s sometimes useful to be able to bring the other coop player to the current player’s location. When testing locally, it can help avoid having to move both players manually to locations in the world. Instead, just move one player, then use a debug key combo to teleport the other player(s) to where you are. The second instance is when you want to interact with an NPC, but their spawn location isn’t fixed in the world. It might be easier to teleport them nearer to the player, if applicable. Obviously for a boss who uses its environment in some meaningful way this isn’t cool, but for a generic battle or conversation it can speed up testing.

That’s all I have for now! I’m sure readers have other great ideas, so let’s hear them in the comments!

Book Reviews Going Forward

Justin — Thu, 27 Jan 2011 21:10:24 +0000

I’m going to try doing more detailed book reviews going forward. I’m not reading as much these days, so my goal is to try to encapsulate more information in my reviews so I remember more about what I read. I’d like to have a “review” as well as a “what I learned” and a “further reading” section, as I often struggle between giving away the plot or salient points in my review vs. being more informative. I’d also like to have a little blurb that I can put with the facebook/twitter link to provide a teaser, as I’ve seen this done recently on Twitter to good effect.