Monthly Archives: April 2007

IGDA GameCafé Report

Last night I attended the second GameCafé held by the Montréal chapter of the IGDA. Due to the fact that people who ordered food received it a little bit later than anticipated, discussions started an hour late, which meant I spent most of that hour listening to Phil and Antoine trade quotes from Anchorman.

Jason Della Rocca, the IGDA’s executive director, preambled the discussions by relating a recent exchange he had with Jack Thompson, an infamous anti-games attorney, who called him an idiot and a jackass on MSNBC. This was apparently in response to Jason calling him out as a massacre chaser. Anyway, you should check out Jason’s post about his e-mail exchanges with Thompson, for the full story.

Industry discussion notes.The discussions I took part part in were decent, for the most part. Digital Distribution was once again lauded as the exciting new business model that will enable indie developers to carve out a niche in the marketplace, but that super publishers like EA will continue to dominate in the retail sector. *yawn*

Micropayments were mentioned and someone pointed out that Asia is way ahead of the West in this regard. Apparently they have made it exceedingly easy to pay with plastic over there, even going so far as to build card readers directly into laptops. This is pretty interesting to me and I wonder when/if it’ll catch on in the West.

Studio discussion notes. At the table about Studio level Future of Work, there was discussion about whether teams that are geographically separated and communicate only over the internet will become more common in game development. The consensus seemed to be that it could work, but meeting in person at least once goes a long way towards creating team cohesion.

I’m a big fan of long-distance collaborating. I’ve made songs with people I’ve never even met in person. However, I think that with music the medium itself is a kind of communication. It is, in fact, easier to understand what someone is going for if they just record a bit of music than if they try to describe it in words. I think this falls apart a bit when dealing with a game because it is audio/visual/interactive; there is no single medium that can act as an intention carrier. For this reason, it seems to me there will always be the need for teams to work in the same physical space. I find that when I’m trying to figure out a programming problem, it really helps to talk it through with someone in person.

Career discussion notes. At the Career discussion table I felt like there was a bit too much focus on working in a studio. But good things were said about how people tend to be happier when they are busy, even if they are not super thrilled about the game they are working on. On the other hand, if it is clear to everyone that their game sucks, it can be really demoralizing. I floated the idea that studios ought to work it out so that when people finish a project, they just get a week or two of paid time off so that they can recover and be ready for the next project. The way it is right now, people are typically pushed onto a new team immediately after finishing a project, even if the new team doesn’t need them right away. Much twiddling of thumbs follows and people get bored and restless. The only difference from paid time off is that they are required to come in to work and occupy a chair. It was mentioned that at least one game developer in Montréal is trying to implement some training programs, so that people can work on improving their skills during downtime, which sounds like an excellent idea to me, but that it’s not very organized yet.

There were many comparisons to the movie industry made during table discussions and also in the final roomwide discussion at the end. This seems to happen every time developers get together to talk about making games. It’s usually mentioned that the game industry is young and is similar to the movie industry of the early 20th century, mimicing the studio model. This comparison is then used to speculate about the future of how work will be parceled out (i.e. outsourcing) and whether that will be good for the industry. People will point to the movie industry and hold up independent film as proof that a change in the distribution of work can only be good, but I’m not so sure I buy that.

Making games is complicated. Possibly more complicated than making a feature film. Part of that is due to the lack of really good high-level tools for making games, but I think part of it is also inherent to the medium. One can view film production as a series of discrete processes: write the script, shoot the footage, edit the film, apply special effects, record the score and foley. Each of these activities can happen pretty much independently of the others. Also, there is usually no going backward. People don’t often decide to shoot more footage once they are in the editing process. Games don’t really work this way. You can’t really decide if your gameplay is any good until you actually implement it and play the game a bit. So you can’t really separate the design of the gameplay (i.e. scriptwriting) from the implementation of the gameplay (i.e. editing?). You see how my analogy is already falling apart? I think developers would do well to stop thinking about how they need to catch up with the film world in terms of work flow and process and what have you, and start focusing on what is good for the medium of games, specifically. No one knows better how games are made than the people who are making them.

Paradigm Shift?

Ever since reading this post about moving the Start menu to the top of the screen, I’ve occassionally considered it. I’ve also often found myself wishing that the Quick Launch toolbar in Windows behaved a bit better so that I could actually have it set on auto-hide and not have it jump out every time I try to use the scroll bar on a full screen program. In fact, I found myself wishing it would behave more like the Dock on a Mac. Well, recently I came across a program called RocketDock that emulates the Dock on a Mac and also is as customizable as the Quick Launch toolbar (moreso, actually).

My new desktop configuration.

It hasn’t broken my computer yet, so I feel pretty good about recommending it to people who maybe wish their PC was more like a Mac. One nice feature is that you can set it so that when you minimize something it becomes an icon in the dock and disappears from the Start bar. This helps keep the Start bar uncluttered when there are a lot of programs open but many of them are minimized. One down side to this is that when an icon does the little bounce thing to get your attention, it doesn’t bounce onto the screen. This means you have to periodically check the dock to see if any of your minimized windows are trying to get your attention, like an IM window or something.

Since I now I have Dock-like shortcut bar, I thought I’d just go whole hog and move the Start bar up to the top of the screen. It’s a little strange, but not so bad. I’ve locked it so it doesn’t have the funky looking beveled edge that it does when it’s resizable. The other thing I’m trying to retrain myself on is using the button on the side of my mouse to bring up an the application switcher instead of mousing up to the top of the screen and clicking on the program tab, or worse, mousing over to make the dock appear so I can click on a minimized window. If I’m switching back and forth between two programs, which is often the case when I’m working on the port or the unit test suite for the port, all it takes is two clicks of the mouse button to switch to the window I want.

I’m not entirely sure what it means to be rocking such a faux-Mac desktop. Maybe it just means that OSX has a better UI. In any event, it’s a nice change of scene and will hopefully reduce some unecessary mousing around and clicking.

Barcamp Montréal 2

I will be giving a 15 minute presentation about Mujax at Barcamp Montréal 2 this Saturday, April 28th. It takes place at the SAT and starts at 9:30 am. Other topics range from “taking photographs with cheap drugstore cameras”, presented by Simon Law, to “everything you wanted to know about the sex trade in Thailand but were afraid to ask”, an already controversial presentation by Madame Woo.

Barcamp is an unconference where all of the attendees are also participants. If you attend Barcamp you must either give a presentation or contribute to the event in some other way (like helping to set up).

The Dreaded Double Diamond

So I’m porting the graph packages from Ptolemy II to C++ and I’ve finally gotten to the point where I can unit test some of it. I was going to start writing tests for the Graph class but when I ran the suite I got errors about some missing implementation in the graph library. A couple of those were methods I did actually miss, but one of them turns out to be the result of multiple inheritance. When you read about multiple inheritance there’s always mention of the dreaded diamond. Well, after sketching out the inheritance tree I’ve discovered I have a case of the dreaded double diamond!

The Dreaded Double Diamond!

This is what the Java inheritance tree looks like. However, it should be noted that all of the Analyzer classes are Java interfaces, which means it makes perfect sense in Java. However, porting this over to C++ is a bit stickier. My initial response to it was “this is silly”, so I broke the Analyzer-Strategy connection and the CachedStrategy-GraphAnalyzer connection. This prettied things up quite a bit. However, now it’s come back to bite me in the ass!

Analyzer defines a pure virtual toString() method. CachedStrategy implements a virtual toSting() method but it is not overriding Analyzer’s because it is no longer deriving from Analyzer. SelfLoopStrategy also implements a virtual toString() method and I thought that this would work not only as an overriding method for the implementation in CachedStrategy, but also as the implementation required by Analyzer. But this is not the case. As it happens, elsewhere in the code, toString() is invoked on a GraphAnalyzer and it doesn’t know where to find the implementation. This makes sense after reading about the subtleties of multiple inheritance. The question I am faced with now is whether I want put the double diamond inheritance scheme back into the C++ code. It makes me a little uneasy is all, there’s this little voice in my head saying, “there’s got to be a better way!”

If I was to use the double diamond, I’m pretty sure the way to handle it would be for Strategy and GraphAnalyzer to inherit Analyzer virtually and then for CachedStrategy and SelfLoopAnalyzer to inherit from GraphAnalyzer virtually. This would give SelfLoopStrategy the responsibility of calling the constructors for GraphAnalyzer and Analyzer. Oh multiple inheritance gurus, have I got that right? Is there a better way?

Live Code v01

Last night I was thinking about live coding and also about how Java has reflection built into it. So, even though there is a forum topic about live coding with Processing, I decided to code up a simple sketch that evaluates a single line of Processing code and continually draws the result. There are drawbacks, of course, namely that you can’t specify fills or stroke colors and you can’t change the background color. However, in the next iteration I plan to ditch the textfield being used and instead use a textbox that will be evaluated in draw without the user having to press the enter key. Probably I should check out the tools talked about in the forum topic, but I like the idea of having a sketch that is itself an interpreter, rather than using a more generic tool for evaluating Java. Then again, I may discover that building something even marginally useful is more complicated than I care to implement, at which point I will probably turn to an existing tool. In the meantime, please enjoy:

Live Code v01

Code Highlighting Is Go!

It’s really great when you discover that people have already done exactly the thing you wanted to do. I went from thinking I needed to write my own code highlighting plugin for WordPress to not only finding out that someone has already written one, but that it is also built on a generic code hightlighting engine that is easy to add new languages to. Then I figured I’d need to add Processing as a language to GeSHi, or at least add to the Java file. But someone already did that, too! So now I have lovely, simple code highlighting that is the same as the code highlighting in the PDE.