|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
  Behold my inventive-osity! | 
Posted - 1/28/2008 2:46:14 PM | According to my cursory Google search, I have officially been the first person to use the term "reductio ad halting-problem" to describe the common class of proofs that collapse onto Turing's well-known result.
I offer the following as proof of my usage.
No, this has absolutely no significance whatsoever. Let me have my moment, dammit.
| |
| Wednesday, January 23, 2008 |
| A Recurring Whinge | |
Posted - 1/23/2008 7:15:09 AM | A few minutes ago I finished watching the season finale of Six Feet Under. (Yes, I'm going to catch hell from my doctors for being up at this hour.) The show is basically a dark comedy centered around a family that runs a funeral home in California. The thing that originally led me to it is the fact that it was done by Alan Ball, the same guy that did American Beauty, which is one of my personal favourite films.
I've never really been much of a TV watcher, mainly because I find the vast bulk of TV to be utter banal crap. (Of course, the same goes for most films, too.) So instead, I wait to hear about potentially good stuff, then rent the DVDs courtesy of Netflix.
I like the approach because it lets me absorb the content at a controlled pace, without commercial interruptions, and in a seamless progression. It's taken a few weeks, but I worked through all five seasons of Six Feet Under more or less to the exclusion of anything else.
In stark contrast to most television programming, the show is really pretty powerfully written, and draws on some fairly deep human themes. By the time the series finale came around, the show had thrown some hefty punches - some predictable, and others not so much. But, in classic Alan Ball fashion, it left just enough open to interpretation that it inspires a lot of introspection, even while (from a narrative perspective) pretty much every loose end was tied up in a remarkably elegant way that exploited the show's recurring mechanics for great effect.
At the moment I'm wishing I could spontaneously start channeling Oluseyi so I can do the whole film-critic thing and actually sound like I know what I'm talking about. Anyways, the upshot of all this is that it got me back to thinking about something that's bothered me for a long time about games as a medium.
There just aren't too many games that embrace storytelling and character development to such a degree of depth that they can achieve the same kind of emotional response as a good show or film (or a book for that matter). Back in the days of heavily text-centered RPGs and epic point-and-click adventures (thinking of games like Dreamweb, The Dig, and so on) we got a little bit more of that, but still not nearly as polished or brilliantly executed.
When was the last time you sat down and played a game that was so evocative you actually felt genuine emotion for the characters? Has a video game character's death ever really succeeded in making you cry? (There's a couple legendary ones that always get mentioned - Baldur's Gate comes to mind - but that's about it.) Has a game's plot ever truly moved you to feel despair or exhiliration?
I can only speak from my own experience, but I just don't get that kind of depth from gaming. At best, there's an adrenaline rush or the joy of defeating a difficult challenge. Maybe some frustration or a little disappointment. But not emotion. Even games that are renowned for their storylines generally fail to nudge the needle much.
Personally, I think that's a shame. I'd dearly love to sit down with my 360 and play interactively - even if the degree of interactivity is limited - with a universe that is as compelling as what guys like Alan Ball can create on the screen.
I've spent enough time in the game development world - professionally and otherwise - to understand why this doesn't happen real often. It's a hard sell; the target market is ill-defined and publishers and investers are (rightly) wary about dumping cash into a product that may not attract any customers. It's technically difficult to achieve a game that meets today's quality demands and still has much depth of any kind, let alone sophistication.
Trickier still, it takes a very rare combination of skills. You'd need great writers, great artists, and a solid technical team to be able to do something like that. The isolated studio model of the game industry is not well suited to such a thing; Hollywood has a major advantage here in that you can cherry-pick the best talent. Hire this writer, that director of photography, this lighting guy, and that other crew to do the audio work - et voila, you have a great production.
Game developers can't do that. If your staff writer is mediocre - he can push out dialogue and sells boxes, but isn't exactly Kurt Vonnegut - then you're screwed. What are you going to do, try and get him fired? "Hey, boss, we could make these other kinds of games that are totally kind of cool except nobody's tried them before, oh and we'd have to fire Alfred and hire some crazy genius writer instead for ten times the cost."
Good luck with that.
I think the industry would have to change substantially to make such a thing truly possible. This is fortunate, because I also happen to believe that the industry (and most of software development in general) is going to change dramatically in the next decade or so, as it finally dawns on the population at large that the current models just aren't efficient or particularly effective.
So while it's sometimes painful to compare the deficiencies of gaming to other media, it's also worth remembering just how young the medium really is - and how long other media have required to become polished and start producing true masters.
I'm looking forward to the days when we really get game development right, and the true masters begin to emerge.
| |
| Thursday, January 17, 2008 |
| This is your brain on Bawls. Any questions? | |
Posted - 1/17/2008 2:06:59 PM | So I finally picked up the Orange Box and played through Portal, pretty much entirely in a single sitting. I was up until 6 AM and therefore obviously didn't get a whole lot of sleep last night.
As a consequence, my brain has reverted to a more primal, unfiltered state, wherein all manner of absurdity spews forth unbidden and befouls the earth at large.
For example, earlier, I made up a joke. Due to sleep deprivation and excessive use of caffeine-based stimulants, I cracked myself up.
The downside is, this joke only makes sense if you both understand topology and are familiar with astrology. A good appreciation of homophone-based puns in English helps, too.
You have been warned.
Quote:Q: When is flatbread no longer flat?
A: When it's made between April 20th and May 20th. |
I am truly sorry for the horrible thing I have wrought upon the world.
| |
| I have no life, and I like it that way | |
Posted - 1/13/2008 9:10:56 PM | This has been the first weekend in, well, probably months that I've felt like spending on hacking around with code. There have been a few niggling little issues in our code base that I've wanted to clean up for ages, but haven't ever really quite had a chance - especially considering that there's a billion other things to do which are much higher priority.
So I've had a downright enjoyable evening of ripping out old legacy half-C and C-with-classes code and modernizing it, which has eliminated a lot of cruft and fragility. This makes me deeply happy.
It's also been a great experience with mucking around with template magic. At one point I got side tracked and just started playing with a half dozen ways to solve a fairly simple problem using template metaprogramming. I've never really gotten too deep into template metaprograms in C++, mainly because I've never needed to; but once I found an excuse, I had a lot of fun with the whole thing. Of course, all of the stuff I did was way too arcane and magicky to be used in production code, but it was great to stretch my brain all the same.
The entire incident takes me back to the oft-revisited notion of code kata, or exercises, or drills, or whatever you want to call them. I used to do a lot more of that kind of thing, but I've slacked off a lot in recent years. At the risk of making myself sound stupid (or, more accurately, making myself sound a lot smarter than I really am), I think it's because it's gotten harder to find problems that I've never solved before.
In some way, shape, or form, I've approached and at least reasoned through the vast bulk of the sort of little mini-puzzle type problems that usually populate lists of kata and the like. I'm certainly not trying to say that I've figured every single problem out, or even necessarily come up with optimal (or good) solutions for the ones I have done. It's just that when I find a challenge problem of some kind, 9 times out of 10 I look at it and go, "Oh, yeah, I remember doing something a lot like this once," and then I just forget it and move on.
(The other time out of ten, by the way, I'm just too damn lazy to care.)
While in some ways it's nice to have a lot of experience to draw on, it's also a little worrying. It means - in my mind, at least - that I'm not making sure I'm as sharp as I think I am. What if I actually have to implement one of these problems one day, and realize that I've spent years thinking I knew the answer but really didn't?
I think I'd feel like a world-class moron at that point.
I've dabbled in several major programming paradigms. I've worked on technology ranging from embedded systems - literally on bare metal with PICs - to highly abstract enterprise systems that barely even seem to be connected to actual code anymore. I've done assembly language, managed languages, functional languages, a few completely pathological languages... hell, I've written a few scripting engines and demented little VMs in my time. (I just wish, in retrospect, that I'd realized how smart it would have been to keep them.)
I know there are plenty of places yet to explore... it's just that they're very esoteric lands indeed, and the sheer amount of energy it takes to explore things arcane and off-the-beaten-path makes it hard to continue to explore in my free time.
And in a lot of ways, I kind of regret that.
| |
| Wednesday, January 9, 2008 |
| Wherein I pretend to have good advice | |
Posted - 1/9/2008 6:31:45 PM | Random advice for working on team development projects
This is just some assorted stuff that's been on my brain the last couple of weeks, which probably everyone knows already, but I feel like saying anyways. And, hey, it's content, right?
1. Use continuous integration
Every single person on your team should be doing continuous integration. Added a few lines of code? Make sure they compile and function correctly, check them in to source control, and continue. Tweaked a few textures on that model to make it look a bit better? Check it into the asset repository so everyone sees the updates live.
This has a few benefits. First, it's a great motivator - everyone sees constant forward progress, which is good for team morale, and great for making your managers and other stakeholders happy. Second, it forces you to have an infrastructure in place that can handle it. No source control? No asset management system? You can't do CI. And if you aren't doing CI, I promise you that your project's development is a lot more painful than it has to be.
As another perk, it keeps your programmers from taking huge chunks of code and breaking them, and leaving them in a broken state for days - or, worse, weeks. Most development shops have a policy against breaking the build - if your code causes the automatic daily build to fail, you're in trouble. This should go beyond just compiler errors or invalid data; if you break a feature or cause the overall level of "finishedness" of the project to regress, it's a bad sign. People should get in trouble for making things go backwards instead of forwards.
2. Tell everyone what's going on
A mistake I've seen a lot lately (and, consequently, am very sick of) is limiting the scope of knowledge. Games are big projects, and obviously no one person is going to know every detail about everything. However, it's far too easy to overly restrict the flow of information.
For example, suppose Bob and Fred are working on the sound system, and they decide they need to change the way sound files are loaded. They tweak a few things, which, incidentally, requires a change to the assets. They fix the three or four assets that they're using, but forget that Joe has a couple of his own that he's using to test the link between the physics engine and the sound system.
Joe shows up to work the next morning and suddenly the physics isn't making sounds anymore. He fishes around a while to find out what broke, and finally notices that it's because his sounds aren't loading correctly. Depending on the quality of your codebase, this might mean it took Joe 30 seconds, or maybe he wasted all day - either way, he's lost valuable time for no good reason.
Bob and Fred should, at the very least, send out a team-wide email that says, "hey, we changed the way sound files load, make sure you do blah blah foo to them so they still work." This spares everyone a lot of trouble. Suppose Joe hadn't tried his physics stuff the next day, but in fact came back to it six weeks later? Now the odds that Bob and Fred even remember the change have dropped severely, and it'll take even more time to solve the issue.
Keep everyone up to date when significant things like file formats, code interfaces, and so on are changed. Yes, you should try and get these things nailed down as early on in the dev cycle as possible; but changes are more or less inevitable, and they must be handled cleanly.
3. Before solving a problem, always ask if someone else has solved it yet
As code bases get large, it becomes increasingly hard for people to track what code has been written and what hasn't. This means that, as code base size and number of programmers increase, the chances of duplicate code appearing increase as well. Right now, our project is plagued by this nonsense.
What's worse is that usually someone has done a really good job solving the problem because it's in the part of the code they are most familiar with - and then someone else comes along who is less familiar and reinvents the wheel, except their new wheel sucks for whatever reason. When you get to the point of having three or four wheels in the same codebase, you have a serious problem.
The first and best defense against this is to have more or less clearly defined "areas of expertise" for each programmer. That is, everyone should know that Bob and Fred are the audio guys, Joe knows the physics engine, and George is in charge of graphics. So when Ed the AI guy wants to have his little bots play scream effects when they die, he should go talk to Bob and/or Fred and see if they have a good way to accomplish what he wants.
There is an important corollary to this: If you have a programmer who is just reimplementing things whenever he needs them without consulting the knowledge of anyone else on the team - or, worse, changing code without understanding the designer's intent - he needs to be slapped around.
Of course, past a point, you're going to get some accidental duplication anyways. And there's always the cases where you only realize in hindsight that two things can be collapsed into a single solution. For those cases, your team should have at least one programmer - preferably one who is known to have good design skills - who is more or less dedicated to factoring out such duplication and cleaning up the code overall.
Some teams are tempted to just do this kind of refactoring "between projects", and only worry about code that carries over across products. This is not really wise. Never underestimate the value of cleaning up code while you are still working on it. You may spend a week getting things tidied up, but that may well save you a month's worth of ugly debugging.
4. Keep a cool head
There will be someone on your team who is markedly less skilled and/or sensible than yourself. (Of course, the standard poker-sucker rule applies here: if you don't know who the dumb guy is, it's you.) You will have to deal with this person, possibly in a close capacity.
Whatever you do, suppress your urges to stab him through the eyes with a rusted spork and spit on his corpse repeatedly. I know it's tempting - believe me, I know - but it's not really all that useful.
If you have enough patience, try and help train up his skills and get him to improve. This way, you gain (eventually) a more valuable team member. If you don't have that much patience, just stuff a sock in it and find a good stress-reliever for after hours.
So how do I know this stuff?
Why should you listen to me? How can you trust that this advice is good, and will guide you away from the thorn-choked path of failure and doom?
Because I can tell you, from experience, that not doing each of these four things leads directly to lots of pain.
| |
| Wednesday, January 2, 2008 |
| Hey look, the little number changed | 
Posted - 1/2/2008 12:09:52 PM | Yayy, new year, blah blah blah. I've never really cared much about New Years, aside from the minor annoyance of having to retrain my brain to write a different number down.
Lately I've been casting about a lot for something of actual substance to be filling in here. It kind of bothers me that there's so little content here when I used to write so much. Frankly I think part of the problem is just that I've lost a lot of my will to think. Being cerebral used to come so easily for me; I'd spend hours just pondering a certain problem or exploring some concept that seemed interesting. Now, though, it takes a huge amount of effort just to focus long enough to do something like write up a shopping list.
It's affected my work, too; it used to be that I'd just look at a problem for a while until I understood it, and then the solutions would pop into my head fully formed. Once I got to grips with a domain, I could move freely and explore all kinds of alternatives and approaches with ease. That's gone now entirely. I've spent long spans of time just rereading the same notes without even comprehending them.
Sadly, this is a pretty unavoidable side effect of the medications I'm on. The idea is that the drugs are supposed to keep me stable enough to stay alive. Trouble is, the quality of life is utter shit. I've lost most of the freedom and spontaneity that I always prized, because supposedly they can trigger episodes. I can't think properly or work the way I used to, so I'm mainly frustrated all the time at my total lack of productivity.
The coup de grace is that I have a worsening tremor/spasm thing going on in most of my muscles, so my back is constantly sore and my fingers shake like crazy. Kind of ironic that one of my meds is supposed to act as an anticonvulsant.
I have another head shrinking session consultation coming up soon, so I'm hoping very much to get switched to a different course of treatment. It'll cost a little bit of time to adjust, but if I can get my brain back, it's definitely worth it.
So 2007 wasn't really my favorite year ever, and I'm not sure '08 is going to be a whole hell of a lot better. I guess we'll know for sure in another 360 days or so.
| |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | | | 1 | | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12 | | 14 | 15 | 16 | | 18 | 19 | 20 | 21 | 22 | | 24 | 25 | 26 | 27 | | 29 | 30 | 31 | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
