VectorStorm Blog

I mentioned a few weeks back that I’ve switched to using Vim as my main editor, and couldn’t be happier.  A lot of that was due to my personal dislike for features which are becoming increasingly common and difficult to disable in popular IDEs, and which I can completely disable within Vim.  But to be honest, most third-party editors would work just as well;  Vim just works for me.  Others can (and do!) prefer Notepad+, Emacs, TextEdit, SublimeEdit, and others.  The key point I wanted to make to other programmers is that it’s worth experimenting with text editors — there’s no need to lock yourself to the one that came with your IDE!

Anyhow.  At a similar time to when I started using vim, I started experimenting with using git, rather than subversion, for source control.  This wasn’t for any special reason, just that I’d been learning a little git (since it’s very popular amongst vim users), and wanted to make a lightweight repository for tracking changes to my Vim preferences.  And then for fun, I imported the MMORPG Tycoon 2 history into git

For me, the best feature of git, compared against subversion, is the ease with which it handles branching and merging, which were always at least mildly painful under subversion.  With git, though, it’s so easy to maintain separate streams of development that suddenly, I’m finding that I can work on several features at once, each separately from each other.  The screenshot above shows a graphical view of the current MMORPG Tycoon 2 codebase.  Right now, I have four different feature branches running, some for core features (“context” is for figuring out how to handle the context actions which I’ve previously shown in a “context matrix”), and some experimental (“duothreadman”, which is doing comparitive performance testing by maintaining two separate pools of threads, so that a glut of low-priority tasks can’t clog up the task queue).  If a feature branch works out well, I can merge it back into the master branch.  If not, I can just delete it and it doesn’t clutter up my repository any more.

Under git, it takes a fraction of a second to create a new feature branch, or to switch from one to another.  These operations would have taken several minutes each under subversion, and been major undertakings which had to be carefully considered and executed.  But they’re trivial now;  not even worth spending time thinking about.  Just make the branch, and delete it later if it turns out to have been a bad idea.

This sort of flexibility means that when I’m feeling blocked on one task, I can easily set it aside and work on a different task, without having to struggle to keep the two sets of changes distinct from each other.  And that’s tremendously freeing.

In between work, home projects, and other things, I’ve also been spending some time playing L.A. Noire, and trying to fit it into my worldview of the current state of the video game industry.  The following is going to be completely spoiler-free, so do feel free to read it whether or not you’ve played or are planning to play the game (and I would absolutely recommend anyone interested in the current state of the video game industry to play this game)

To begin with, I should again mention that I’ve been in the commercial video game industry (with one recent six month break) continuously for the last fourteen years;  that’s more or less since the first accelerated 3D cards hit the market.  My comments in this post (and indeed, all the rest of this site) reflect only my own opinions, and not those of any of the fine people who have employed me or with whom I have worked in this time.

I should also mention, just as full disclosure, that there was a point where I might have gone to work on L.A. Noire during the latter half of its seven year development timeline, and that I now know and work with people who did work on various parts of this game.  I’m not going to go into any of those details, but I thought I should put it out there just as fair warning, so that people can take the following comments with any grains of salt they feel are deserved.

Full discussion is below the fold.
Continue reading “L.A. Noire is Babylon 5″

As a lead programmer at Krome Studios, one of my Key Performance Indicators (which, sadly, was never enforced or even encouraged in practice) was to give a minimum of one master class per year, to pass on acquired knowledge from the old-timers to the newer employees.  I think it’s a real shame that nobody ever followed through on that, as it was a really good idea.  It was always something that I wanted to do, but under the realities of (often extreme) deadline pressure, it was difficult to find time to prepare and arrange during work hours.

It’s something that I’ve always wanted to do, and have been thinking about more and more since leaving Krome.  As somebody who’s been a gameplay programmer for more than twelve years, I think I’ve accumulated some insights over that time, which might be of use to other game makers out there.  So far, when I’ve posted things like this, they have been in the form of essays posted to this blog, but they’ve always felt really dry to me.  A podcast might work better, but in this field many concepts need to be accompanied by animated visual aids.  So a vodcast might work, perhaps.  I don’t think that my internet connection is up to attempting a live ustream show (although if it was, that would probably be the ideal forum, so the thing could be a little more interactive).

If I do this, it wouldn’t be a “how to create a game” tutorial; instead, it would be targeted at people who can already make games (or are learning via some other avenue), and would be about the more nuanced craft involved, regardless of what platform, language, or toolkit you’re working in.  It would cover the principles of camera behaviour (in 2D and 3D), the design of control schemes, user interface issues, general fit and finish, and so forth.  And of course, it’d be available for free to anyone who was interested, whatever form it eventually took.

What do you guys reckon?  Is this something you think people would be interested to see?

Latest new thing to go into MT2:  Support for status effects.

In MT2, “status effects” are implemented as little blobs of code that can be attached to individual characters.  They get run periodically, and can affect just about anything on a character.

For example, right now I’m using them to implement Damage over Time (“DoT”) and Heal over Time (“HoT”) effects.  In the future, I’m planning to use them for movement speed adjusters (for roots/stuns, mounts, travel powers, etc.)  Eventually, you’ll be able to set whether or not they should be allowed to “stack” (although that’s not yet been implemented).

Continue reading “DoT, and Reach”

On Monday of this week, my employer Krome Studios shut down.   This is the mug that I used for most of my career in the video games industry.  It seems wrong to have it at home, or to drink from it here.  So it just sits on a counter and collects dust, now.

Continue reading “There are many like it, but this one is mine”