PolygonalHell

The holy trinity and MMORPG combat

2011-03-20T13:22:00.000-07:00

Recently I was discussing the Cataclysm changes in WoW with a friend over lunch, he was complaining about the changes in healing and tanking in the new heroics. That coupled with the lack of tanks and healers available for random groups having drained the fun out of the game for him. In particular he was complaining that the new difficulty had created an environment where Tanks would quit any random group they considered even marginal, because they could instantly join another group.

One of the things he suggested was removing the Holy Trinity from MMORPG games. For those who don't know the Holy Trinity is the combination of DPS, Tank and Healer that's become the de-facto design for group based combat in MMORPG's. The first game I can remember using role based groups like this was Everquest (although it wasn't really a trinity at that point). Almost every game since has copied the basic mechanic. WoW did simplify it somewhat reducing it to 3 clear roles, and Blizzard has probably spent more time tailoring content to the pattern than anyone else. Asheron’s Call did eschew the class system all together, but it lead to cookie cutter builds, sure everyone could heal, DPS and take damage, but because there were a certain set of skills that had to be taken in any viable build everyone ended up with the same skills with only minor differences.

Getting back to my friends point which was that 2 of the 3 roles (Tanking and Healing) were more difficult to play or at least had dramatically more impact when performed poorly and almost everyone preferred to play the 3rd role anyway. Looking at WOW for a minute, even with 3 DPS to 1 Tank/Heal ratios, there still aren't enough Tanks or Healers to meet the demand in random dungeon queues, which tends to support his point.

It started me thinking, what would group combat without the Trinity look like? I’m fairly certain there are a number of different viable mechanics, but it’s an interesting exercise to try and devise one, at least at a very high level.

The requirements are relatively straight forwards.

We want to reward coordinated group play.
We don’t want it to become everyman for himself.
We don't want to excessively reward particular class combinations.
The classes still have to feel unique.

After a some though the basic idea I came up with is that combat becomes about handing off threat between the participants in a battle. In long battles multiple party members get to be "it" (the primary target of the mob). While you're “it”, you have several penalties that prevent you from retaining "it" status.

Let’s start with a simple system with one class.
Characters have two resources HP’s and Energy. In practice you could just have one, but it’s harder to sell through game “Lore”.
In addition they have 3 dynamic attributes
Threat Generation
DPS
Damage Mitigation
Imagine these attributes as spring systems with dampers.
These 3 attributes are effectively signed values starting in some neutral state (0) trying to return with some force to that state.

Character skills either directly or indirectly inject impulses or forces (positive or negative) to each of these 3 attributes and there is momentum associated with changes of the values.
The closer the attributes are to the neutral state the faster health and energy regenerate.

Depending on the skills a player uses, they can choose to generate extreme DPS or go with extreme damage mitigation, but will run out of energy and in the worst case gain or lose aggro with no energy to change there current focus.

That’s basically it, players have to coordinate their role changes with others in the party, changes aren’t instantaneous, so it requires a level of skill.

How do you differentiate classes in such a system? well you’ve got the obvious visual differences, Dodge vs Shield vs Magic etc. You can still use mechanics like the WoW rogue action points or the slight variation that Rift uses for Warriors. In addition if you look at what we are trying to do here it’s have the group manage a shared pool of energy/health throughout an encounter, so there is no reason that you can’t have skills that trade them between players. The 0 point of the attributes and the strength of forces could also be changed per class. I think that gives enough leeway for class uniqueness.

What about solo PVE? that pretty much amounts to DPS vs Damage Mitigation and the use of counters none of which are precluded by a change in core group mechanics.

And PVP? This is much harder because there is to way to manage threat with players, but it’s true of pretty much every other MMORPG game anyway, you kill the healers first, then it becomes a game of numbers. At least here the roles aren’t predefined and can change in battle. As to 1 on 1 PVP I think it’s close to impossible to balance a game for it with any substantial class variation.

There are almost certainly a lot of other core mechanics that could achieve compelling group play without the split by role mechanic. It requires designers to not start with the premise that MMORPG == Holy Trinity. Unfortunately I suspect that’s easier said than done.

One last thought, possibly the hardest part of all of this would be selling new mechanics to existing MMORPG players, there is a reason most new MMORPG’s follow in the WoW mold, and it’s because wondering too far from it alienates your player base.

3D- as in Stereo

2010-01-18T10:44:00.000-08:00

I've been somewhat facinated with Stereo images for a long time, I owned one of the very first vomit inducing entertainment oriented VR headsets. Although I'll admit I didn't pay the $1000's the manufacturer originally asked for it.

With the sudden resurgence of 3D at CES, I started looking at NVidia's shutter glasses solution. NVidia came in and demo'd an early prototype of the Viewsonic monitor while I was working on Spore. I can go buy a 22 inch 120Hz Viewsonic monitor with the glasses for about $400, which doesn't seem unreasonable. I can buy the monitor alone for about $250 which is competitive with other 2 inch monitors. Then I looked at the price of a second set of glasses (just the glasses not the transmitter), $150 for an additional pair of shutter glasses seems obscene to me.

With HDMI 1.4 and the sudden popularity of 3D at CES, I suspect it won't be long before most panels are 120Hz and support input signals at that rate, so the cost of entry is going to be the cost of the N-Vision kit, NVidia needs to get the price down.

I'm a big fan of surround gaming, it really does add a lot more to games than you might first expect. I use a Matrox Tripple Head To Go (I wouldn't recomend it), and I've been considering "upgrading" (not sure it would actually be faster) to an ATI 5850 GPU hoping that eyefinity" resolves some of the setup pain. I must admit I'm intrigued by the 3D surround Demo NVidia did at CES, but I already own 3 24 inch monitors that I use for surround gaming, and the concept of replacing them with 3 new 22inch monitors and adding a second $300 video card is a little excessive even for me.

Stereo 3D really doesn't add much for the "hardcore" gamer, yes it's more immersive, but it usually makes it harder to play, and performance is reduced by Half because of the 2x rendering. So is it aimed at the less hard core player, if it is the cost of entry needs to drop, probably to less that $100.

DX1 App Update - Macros should now work in more games

2009-11-26T13:50:00.000-08:00

Download DX1 App

I've added support to use ScanCodes instead of VKey codes in macros. Macros that use ScanCodes will work in a wider variety of games. I've tested both timed and multikey macros in Dragon Age Origins where VKey macros do not work ScanCode macros do.

All your old macros should still work fine, you'll have to manually convert them to ScanCode macros if you want them to work in games that use DirectInput. By default all new macros are ScanCode macros.

This is a list of ScanCodes for most of the basic stuff - you'll need to convert them to decimal.

#define DIK_ESCAPE 0x01
#define DIK_1 0x02
#define DIK_2 0x03
#define DIK_3 0x04
#define DIK_4 0x05
#define DIK_5 0x06
#define DIK_6 0x07
#define DIK_7 0x08
#define DIK_8 0x09
#define DIK_9 0x0A
#define DIK_0 0x0B
#define DIK_MINUS 0x0C /* - on main keyboard */
#define DIK_EQUALS 0x0D
#define DIK_BACK 0x0E /* backspace */
#define DIK_TAB 0x0F
#define DIK_Q 0x10
#define DIK_W 0x11
#define DIK_E 0x12
#define DIK_R 0x13
#define DIK_T 0x14
#define DIK_Y 0x15
#define DIK_U 0x16
#define DIK_I 0x17
#define DIK_O 0x18
#define DIK_P 0x19
#define DIK_LBRACKET 0x1A
#define DIK_RBRACKET 0x1B
#define DIK_RETURN 0x1C /* Enter on main keyboard */
#define DIK_LCONTROL 0x1D
#define DIK_A 0x1E
#define DIK_S 0x1F
#define DIK_D 0x20
#define DIK_F 0x21
#define DIK_G 0x22
#define DIK_H 0x23
#define DIK_J 0x24
#define DIK_K 0x25
#define DIK_L 0x26
#define DIK_SEMICOLON 0x27
#define DIK_APOSTROPHE 0x28
#define DIK_GRAVE 0x29 /* accent grave */
#define DIK_LSHIFT 0x2A
#define DIK_BACKSLASH 0x2B
#define DIK_Z 0x2C
#define DIK_X 0x2D
#define DIK_C 0x2E
#define DIK_V 0x2F
#define DIK_B 0x30
#define DIK_N 0x31
#define DIK_M 0x32
#define DIK_COMMA 0x33
#define DIK_PERIOD 0x34 /* . on main keyboard */
#define DIK_SLASH 0x35 /* / on main keyboard */
#define DIK_RSHIFT 0x36
#define DIK_MULTIPLY 0x37 /* * on numeric keypad */
#define DIK_LMENU 0x38 /* left Alt */
#define DIK_SPACE 0x39
#define DIK_CAPITAL 0x3A
#define DIK_F1 0x3B
#define DIK_F2 0x3C
#define DIK_F3 0x3D
#define DIK_F4 0x3E
#define DIK_F5 0x3F
#define DIK_F6 0x40
#define DIK_F7 0x41
#define DIK_F8 0x42
#define DIK_F9 0x43
#define DIK_F10 0x44
#define DIK_NUMLOCK 0x45
#define DIK_SCROLL 0x46 /* Scroll Lock */
#define DIK_NUMPAD7 0x47
#define DIK_NUMPAD8 0x48
#define DIK_NUMPAD9 0x49
#define DIK_SUBTRACT 0x4A /* - on numeric keypad */
#define DIK_NUMPAD4 0x4B
#define DIK_NUMPAD5 0x4C
#define DIK_NUMPAD6 0x4D
#define DIK_ADD 0x4E /* + on numeric keypad */
#define DIK_NUMPAD1 0x4F
#define DIK_NUMPAD2 0x50
#define DIK_NUMPAD3 0x51
#define DIK_NUMPAD0 0x52
#define DIK_DECIMAL 0x53 /* . on numeric keypad */
#define DIK_F11 0x57
#define DIK_F12 0x58

#define DIK_F13 0x64 /* (NEC PC98) */
#define DIK_F14 0x65 /* (NEC PC98) */
#define DIK_F15 0x66 /* (NEC PC98) */

#define DIK_KANA 0x70 /* (Japanese keyboard) */
#define DIK_CONVERT 0x79 /* (Japanese keyboard) */
#define DIK_NOCONVERT 0x7B /* (Japanese keyboard) */
#define DIK_YEN 0x7D /* (Japanese keyboard) */
#define DIK_NUMPADEQUALS 0x8D /* = on numeric keypad (NEC PC98) */
#define DIK_CIRCUMFLEX 0x90 /* (Japanese keyboard) */
#define DIK_AT 0x91 /* (NEC PC98) */
#define DIK_COLON 0x92 /* (NEC PC98) */
#define DIK_UNDERLINE 0x93 /* (NEC PC98) */
#define DIK_KANJI 0x94 /* (Japanese keyboard) */
#define DIK_STOP 0x95 /* (NEC PC98) */
#define DIK_AX 0x96 /* (Japan AX) */
#define DIK_UNLABELED 0x97 /* (J3100) */
#define DIK_NUMPADENTER 0x9C /* Enter on numeric keypad */
#define DIK_RCONTROL 0x9D
#define DIK_NUMPADCOMMA 0xB3 /* , on numeric keypad (NEC PC98) */
#define DIK_DIVIDE 0xB5 /* / on numeric keypad */
#define DIK_SYSRQ 0xB7
#define DIK_RMENU 0xB8 /* right Alt */
#define DIK_HOME 0xC7 /* Home on arrow keypad */
#define DIK_UP 0xC8 /* UpArrow on arrow keypad */
#define DIK_PRIOR 0xC9 /* PgUp on arrow keypad */
#define DIK_LEFT 0xCB /* LeftArrow on arrow keypad */
#define DIK_RIGHT 0xCD /* RightArrow on arrow keypad */
#define DIK_END 0xCF /* End on arrow keypad */
#define DIK_DOWN 0xD0 /* DownArrow on arrow keypad */
#define DIK_NEXT 0xD1 /* PgDn on arrow keypad */
#define DIK_INSERT 0xD2 /* Insert on arrow keypad */
#define DIK_DELETE 0xD3 /* Delete on arrow keypad */
#define DIK_LWIN 0xDB /* Left Windows key */
#define DIK_RWIN 0xDC /* Right Windows key */
#define DIK_APPS 0xDD /* AppMenu key */

DX1 macro problems - Dragon Age Origins

2009-11-24T10:31:00.000-08:00

I've been playing Dragon Age Origins and I noted that macros don't work in the app. They work fine in WOW and Torchlight. After a little research I think it's likely that DAO is using DirectInput to read the keyboard.
Apparently SendInput does do the right thing with DirectInput, but you have to use scan code instead of virtual keycodes. My guess would be sending Scan codes with Send Input inserts them earlier in the OS's input chain.
I've recieved email from a couple of people with similar problems in apps I don't run.
If I can get VS2008 installed on my new machine I'll try the change over the weekend and push out a fixed app.

Linux/Open and open source software...

2009-07-21T10:01:00.000-07:00

About once every 12 months I take one of my machines and install various Linux/BSD distributions, mostly because I have a soft spot for UNIX like OS's. Pretty much every time I go through the same set of things that end up with me turning the machine off and leaving it off. It's usually a combination of hardware incompatibilities and poor development tools.

This time however I had an agenda, I wanted to re purpose the machine in question as a media player, the original plan was to install XBMC and be done with it.

OK so I go grab the latest Ubuntu disks, install it, which I have to say was extremely pain free. I install the xbmc package, and play a video, unfortunately it doesn't appear to respect the timer and plays the video very quickly with skipping audio. Hmmmmmm, so I dig around on various boards, the general consensus is it's a pulse audio issue, what's odd is that mplayer doesn't display the issue. OK I remove pulse from my system and try again, same thing. Hmmmmm, I decide to try it with the NULL sound driver to verify it's actually audio and the video plays at the correct speed.

I figure maybe it's a fixed issue, so I pull down the latest build via svn, rebuild XBMC, same issue.

In a fit of frustration I install Fedora and have more or less the same issues. I start looking at the video player inside XBMC, discover what a massive app it actually is. All I want is something basic that lets me browse videos from my server and play them.

So I decide screw it, I wonder what it actually takes to write a video player using some of the open source components all the others seem to leverage. the answer turns out to be not very much the ffmpeg libraries provide most of the infrastructure, and it's relatively easy to get something up and running in a day or so. I did have some issues with the libswscale library, it has a bug where by it incorrectly swaps pixels when it's doing a 1:1 scale and isn't using the MMX routines, but I could patch that locally (I'd submit a fix, but it looks to me like the original author very much intended it to do what it's doing, and I have no idea why).

OK so all's well that ends well?

Not really at some point I decided to take my basic video player and use OpenGL to put the pixels on the screen, all of a sudden I have this issue where I get repeating sound fragments, and since I'm syncing video to the audio clock choppy video.

My first thought was the audio thread starving, but for that to happen the app would have to be eating all the CPU and it's not.

I discover that as I make the target widow smaller it stops being an issue, I know it's not a rendering related issue though, because if I remove the clocksync and just let the video run, it runs faster, so I'm not limited by drawing pixels. So I waste a lot of time looking at various aspects of my code ruling them all out.

So I come up with a new theory, the audio driver is missing interrupts when the onboard video is busy for extended periods. To test my theory I try subdividing the single large polygon I'm using for display into 1024 small polygons and miraculously the issue goes away. Even doing a glClear is sufficient for the issue to return.

So now I'm at a loss, I can't easily establish if this is a hardware issue, or a driver issue, and if it's a driver issue, if it's a video driver or an audio driver problem, or even a chipset driver issue.

FWIW I believe it's an audio driver issue, I've tried the code with both an A2DP sound driver and I've put in an external sound card, and as long as I'm not using the internal sound card (NVidia MCP51) the issue doesn't present. I've tried setting various driver options with modprobe without success.

So I'm left with ignore the issue and just leave the sound card in there (which irritates me because it should work). Or start digging through the ALSA driver code which I really don't want to do.

Ugh!

Minor DX1App update

2009-03-01T13:27:00.001-08:00

Updated DX1 programming App

I made a small change to the way multikey macros are processed to fix an issue I was seeing with my own use in WOW. It turned out to be an issue with the plugin I was using, but the fix is the right thing to do.

Added support for 64bit App switching, I've had to use the process name instead of the app name for the switching code. You need to create a ".pgm" file in the Macro directory (not the app's directory) named processName.pgm where process name should be the name of the process. Usually the process name is the same as the app name.

I've tested this with the 64 bit version of media player, by creating a file called wmplayer.pgm in the Macro directory.

The issue is that a 32 bit app (which the programmer is) can't look at the process info for a 64 bit app. It's not trivial to build a native 64 bit version of the programming app because of the data marshaling for the native windows calls, so I've added the work around.

DX1 App update

2009-01-11T12:38:00.000-08:00

I've updated the driver and source code drop.
This drop only affects the app and the source code, no changes to the driver.

I've fixed the problem when mapping the 9 and Z keys from the main keyboard. The code that built the table that converted the windows key code to driver HID codes had a couple of typos.

New 32 and 64 Bit Ergodex DX1 drivers

2009-01-03T20:05:00.000-08:00

As promised a 64 bit version of the DX1 Driver and app.
This drop also includes support for multikey macros and various fixes.
Also included is the source code for the programming App, hopefully someone with more desire can build something a bit more user friendly.

This was more work than I expected, the code was easy enough to fix, but I had a somewhat subtle error in my ".inf" file that was only causing an issue on my 64 bit machine. It's also possible it was causing issues in the 32 bit version so you might want to grab the new drop.

At some point I renamed a number of classes in the application, and I don't remember if it was pre or post the last drop, that invalidated saved macros and key bindings, so you might want to delete any if you have a problem running the App.

http://www.polygonhell.com/DX1Release3264Bit.zip

Bah Humbug

2008-12-23T15:33:00.000-08:00

The delivery of my stuff was delayed by the inclement weather, so it'll be the new year before I can get an updated drop of the driver out.

Quick Update

2008-12-16T09:14:00.001-08:00

I've had a number of requests over the last week or so for 64 bit binary versions of the Ergodex driver, and the possibility of a source code drop.

I'm currently in the midst of relocating to the Seattle area, and I don't have access to the computer with the driver source code on it. I should have access after the 22nd.

Once I have access to the computer I'll build and release a 64 bit version along with an updated programming app, as I've made several fixes since the release here.
I will also release the source code for the programming app at that time.
I will not release the source code to the driver itself until I've had a chance to poor over the licensing restrictions and figured out exactly what license I can release it under.

Ergodex DX1 Driver Vista

2008-07-14T15:15:00.000-07:00

You can download a binary release of my Vista 32 DX1 driver below

DX1 Driver

If there is any demand I guess I can compile a version for Vista 64 but I have no way to test it currently.

Writing a DX1 device driver for Vista

2008-07-08T15:46:00.000-07:00

I recently upgraded to Vista after an incident involving a replacement video card resulting in a lost hard drive (don’t ask), for the most part I actually prefer Vista to XP. About the only real downside (other than the stupid security escalation dialogs) was the lack of a driver for my Ergodex DX1.

After rummaging through the Ergodex forums and waiting for them to actually provide a driver, I ran across this site http://ergodex.hydraproductions.com/wiki/ since Dom had already reverse engineered the USB protocol I thought I’d try writing a driver for the device.

I think the last time I wrote a device driver of any description for windows might have been circa windows 3.1. I have a pretty good understanding of the hardware and the underlying protocols, because Consoles usually don’t make much of an effort to hide the nuts and bolts, but my Windows skillz leave a bit to be desired.

I downloaded the windows DDK, scanned the examples, and started messing around with the Bulk USB sample. After a while it became obvious I was going to have to install another copy of Vista on a second box in order to debug anything or at least use my laptop as the target. I was scanning through the docs and I came across the WDF doc, it seemed that the UMDF provided everything I needed to write a USB driver in usermode and allowed me to debug just by attaching Visual Studio to the running device process.

So on Sunday night I started experimenting with one of the samples, by Wednesday Night the driver was basically functional. It’s changed a bit since then because I changed my mind on how to communicate with the programming/macro playback software. Since then I’ve put together enough of a programming/macro app to do what I need.

There are two things that jump out at me from this experience,

The first is how well designed at least the UMDF portion of the WDF is, the reason I could write a driver in literally 3 or 4 evenings, was that the base functionality just does the right thing most of the time just leaving you to marshal data and pass it on.

The second, is how frustrating it is that a company like Ergodex still can’t get Vista drivers out, the vast majority of the work for the suit is in the programming tool and I’m sure the XP one Ergodex has could just be dropped on Vista, just leaving the part that took me 3 or 4 days.

I’ll release the driver here along with my horrible programming application when I get some time to make a pass on the code. I’ll also release the source code for none commercial purposes.

WOW Multimonitor and Vista

2008-05-04T13:16:00.000-07:00

Consider this a Howto. (with a bad picture)

1. install WOW and get it running.

OK now we find that since Vista has removed the Stretch window option we can only run on one monitor. There isn't much we can do about full screen mode, but we can run in a Window and stretch the window across the monitors. This works, but the window grows in height as we stretch horizontally, since WOW is trying to maintain the aspect ratio.

To fix this, edit your config.wtf file and edit the gxResolution line, it's important to note that if either the width or height specified on the resolution line exceed the resolution of your primary monitor, it will just be reset. All that matters for now is that you pick something with the correctaspect ratio.

I'm using a pair of widescreen monitors, with a final resolution of 3840x1200, so I set my gxResolution line to one quarter of that 960x300.

SET gxResolution "960x300"

Note that under vista if you don't run WOW as administrator, it seems to ignore the settings in Config.wtf, so run it as administrator.

OK at this point, you should be able to stretch the image in the correct aspect ratio accross the two monitors.

I was almost happy with this but I really hate the stupid window border, I really wanted the equivalent of the maximised check box in the graphics options. i.e Maximised across both monitors with no border. Unfortunately setting the Miximized option will of course maximize to just one monitor.

I messed around with various multmonitor utils and none of them did what I wanted, so I wrote a program to do exactly what I wanted to the WOW window.

http://www.polygonhell.com/wind1.exe

It's a command line utility, and has to be run as administrator (since it needs to modify another processes window), basically it finds the first window with the start of the title "World of Warcraft", changes the stype flags to remove the window border and then resizes the window to the specified size.

There is minimal error checking since it was a quick hack, it takes upto 4 parameters, x, y, width and height (see below). if you omit the arguments it defaults to 0,0,640, 480

wind1.exe -1920 0 3840 1200

That's the command I use, the X is negative, because it happens my primary monitor is to the right of my secondary monitor, you can run it multiple times to move and resize the window, but there is no functionality to restore the border.

This is not a keylogger, and for the overly paranoid the source code is below if you want to build it yourself.

EDIT -- Fixed a problem in identifying the correct window, under some circumstances it would find the button on the Taskbar instead of the window and just do nothing. Revised code below, also updated exe at the above link.


// WOWFullScreen -- Hack to maximise the window with no border to an arbitrary area
//

#include "stdafx.h"
#include "windows.h"


int _tmain(int argc, _TCHAR* argv[])
{
    WCHAR *match = L"World of Warcraft";
    int x = 0;
    int y = 0;
    int width = 640;
    int height = 480;

    if (argc > 1)
        x = _wtoi(argv[1]);
    if (argc > 2)
        y = _wtoi(argv[2]);
    if (argc > 3)
        width = _wtoi(argv[3]);
    if (argc > 4)
        height = _wtoi(argv[4]);


    WCHAR name[1024];
    HWND wind = 0;

    HWND window = GetDesktopWindow();
    HWND child = GetWindow(window, GW_CHILD);
    child = GetWindow(child, GW_HWNDFIRST);
    while (child)
    {
        GetWindowText(child, name, 1023);
        unsigned int  style = GetWindowLong(child, GWL_STYLE);
        if ((style & 0x160f0000) == 0x160f0000 && !wcsncmp(match, name, wcslen(match)))
        {
            wind = child;
            break;
        }
        child = GetWindow(child, GW_HWNDNEXT);
    }

    unsigned int  style = GetWindowLong(wind, GWL_STYLE);
    unsigned int  styleEX = GetWindowLong(wind, GWL_EXSTYLE);

    style = style & ~( WS_CAPTION | WS_THICKFRAME);
    SetWindowLong(wind, GWL_STYLE, style);
    SetWindowPos(wind, HWND_TOP, x, y, width, height, 0);

    return 0;

}

Thoughts on development tools and the future

2008-01-12T11:34:00.001-08:00

I had a conversation with a friend recently about why Sony had really failed to match the quality of Microsofts devtools.

The answer is pretty simple, for the most part they are hacking their devtools into Visual Studio and copying what MS already has. At some level it's all they can do, as a developer I don't want two different dev environments for two different consoles, I have to switch back and forth too often for that. The reason I finally gave up on my seperate text editor and started editing files inside Visual Studio was because the VS brief emulation was bad enough that editing files in both places was inconsistent and irritating.

But the conversation got me thinking about how tools like Visual Studio haven't scaled well with the size and complexity of modern games, andin fact how much more painful development is now (despite the infinitely better tools) than it ever has been.

The issue is the cycle time, I make a change/add a feature, compile, link run and test. For me currently excluding the editting that's at least 3 minutes, and as much as 20 depending on what files I touch in the codebase. That makes any sort of itterative development hideously painful. We work around by having hot loaded tuning files, and exposing variables that we want to itterate on in those files, but that doesn't cover a lot of code specific cases.

Some of the pain is self inflicted, our startup time to get into the game on dev builds is pretty bad, because we generally develop with thousands of "loose files", loaded off the disc to make changing them easier, where as we ship with them packed into larger packages.

But a big chunk is in compilation and linking.

We use incredibuild, though it's only really a win in a rebuild all case. We could probably improve link times some by cleaning up some of the dependencies between source files and we do sweep files for un-needed header dependencies on occasion. Making some of our libraries DLL's would probably help the link time. But why is it even necessary?

In the Genesis/SNES days, for the most part I could edit, assemble and run in less than 10 seconds. OK I'm comparing less than 100K lines of assembler to over 1M lines of C++, but we need to find a solution.

And it's not just the compile/link time, managing all the files in the project becomes a challenge, I use Visual Assist and would recommend to to others, it has tools that help navigating code bases, but the some of the more useful ones like goto symbol really only work about 1/2 the time on large codebases.

I've championed the idea of providing artists and designers with powerful tools that let them itterate quickly, even at the expense of runtime performance (although that's a fine line to walk) for probably 10 years now. They produce better content and that makes the technology look good. We need to apply the same sort of thought process to engineering.

MS has made some efforts in this direction, Compile and Continue, is an incredible tool, unfortunately it seems to just stop working on large codebases. They have mechanisms to lookup symbols and go to them, but using it on large codebases leads to huge random pauses when editing.
What's worse is that because MS has concentrated on the feature set of Visual Studio, dealing with large codebases in visual studio has actually gotten worse as it's moved forwards. VS6 is better in this regard than 2003 and 2003 is better than 2005. My understanding is that 2008 is starting to move towards improvements in this area, but I haven't had a chance to test that.

All a user can really do to alleviate the situation is work with less source code. There are ways to do this if you make the right set of design decisions, but when you start making technical decisions based on the inadequacies of the development environment there is something very wrong.

The majority of programmers I know bitch about Visual Studio on a daily basis, most of what it does, it does just about adequately. If someone like a Sony or Whoever really wanted to compete in the devtool arena with MS I think the window is there to do so. For Sony they'd have to stop thinking in terms of PS3 tools and start thinking in terms of core development tools for multiple platforms, cross platform development is not going away and the cost of having to use two dev environments is just too high. You don't need the feature set of Visual Studio to beat it, you just need to do the useful things well, and let people do all there work inside it. If it were me I'd concentrate on any mechanism to let programmers itterate quickly on large codebases, and make it your differentiating feature.

Developing games with large teams

2007-09-09T10:02:00.000-07:00

As the video game industry has grown, so have the the expectations of the customer and accordingly product complexity. Time pressures however have remained more or less constant, while there are a few products that ship "when they are ready", most still have to ship for Xmas, for the end of a fiscal quarter or the start of some sports season.

As a result team sizes have ballooned over the last 5 years or so, it's a predictable solution to the problem, with predictable problems of its own. The old adage that 9 women can't have a baby in 1 month is pretty much understood by everyone involved, having said that there are plenty of people involved who still believe that 20 women can have a baby in 5 months.

There are some things you can do on a large team, that small teams simply can't do you have resources to burn, so you can do experiments or add features that a smaller team simply couldn't afford too. However the cost of this is extreme, when lots of people are contributing to a codebase, the codebase will be necessarily larger for the same functionality, larger means more complex and more difficult to maintain, engineers generally have only local knowledge of the codebase, often coupled with an incomplete or inaccurate understanding of the rest. Because of the increased engineer count, there is a tendency to have a disproportionately high number of inexperienced engineers. Code quality becomes difficult to police and you start to suffer from "death by a thousand cuts" in both performance and memory.

The mistake that is commonly made is to believe that you can control this from the top, by adding separate engineering/project management and tracking the project at a finer granularity. This IMO as two fundamental problems with it, project managers staring at there planning tools start to look at engineers as work units, and the completion tests look at features in isolation rather than in the context of the game as a whole. This leads to a loss of ownership by the individual contributors and a lot of unscheduled time to take the collection of features built this way that have to be cut/fixed or reimplemented before the game actually ships.

Now I'm not advocating no planning or tracking, they are both very valuable tools in managing any project. But it's important to do everything in the context of the game, and understand that estimates are estimates, rather than pressuring an engineer to deliver something inside a milestone, pressure the engineer to deliver the right thing and understand that milestones are about gut checks and tracking. Give the people on the ground ownership for large scale features, let then see them through from start to end. Listen to your senior engineers, they've been through it before and they are going to give you as valid a read on the project state as any tracking tool.

The real solution though is fewer, more experienced people over a longer timeframe. Start with small teams, give them ownership and grow them as the resources are needed and can be used. If your a large company, start more projects, experiment, evaluate the projects regularly and kill the ones that aren't working out. The idea here is based on the model used by investors for every 10 projects you back your looking for 1 to make it big and cover the costs of the others.

The biggest problem I see with a setup like this is people quitting because their project is cancelled, but this is really about setting expectations, yes you'll loose some people but you'll attract just as many with the opportunity to own and contribute to something.