Archive for April, 2007

Working hard, getting nothing done

Saturday, April 28th, 2007

I tend to consider days where I don’t implement major new features wasted days. By that standard I’m working very hard and getting nothing done.

My time right now is split:

15% answer emails (mostly artists)
10% updating the artist Wiki
15% general artist support
30% training & bug-fixing for a new programmer
5% fixing old bugs caused by myself
5% refactoring
5% communication in general (bug reporting, etc).
5% miscellaneous crap (blog, worrying. stress)
10% adding minor features

It’s probably been like this for the last week.

I have a few good things going for me:

1. All the major architectural features are in. It’s just a matter of polishing them and getting them working.
2. My programmer from Portugal is really good. I can assign him stuff and just know that it will get done right.
3. While I don’t like it, I’ve been paying a lot for the best tools. These tools are starting to pay off.
4. I have as many people as I need now working on stuff. So I don’t have to spend time interviewing.

Fortunately, I only have a few major features left. Unfortunately, one of these is splitting the client and server and getting everything actually working over the net. Ouch.

Code replay

Thursday, April 26th, 2007

For several years I’ve been looking for a tool that will allow backwards execution or at the least replay of random bugs. My graphics programmer send me a link to Replay Solutions which offers Replay Director which I believe can do this. He told me he contacted them several times asking for a price and never got a response. Regardless, I sent a no-frills email asking about the price as well. If they don’t get back to me I’ll try to do some research and see what I can find out on my own.

*** EDIT ***

They got back to me. It’s $25,000 per seat. It doesn’t do backwards debugging, but it does do recording, so that you can play through the scene again and repro the bug. For that to be useful you’d have to have some kind of global tick counter so you could stop one tick before the crash.

Too expensive for me now but it would come in handy after I ship.

Correctness > Speed > Cost

Saturday, April 21st, 2007

As the game nears completion I’ve been working with a lot more people lately. If you asked me to sort these people in terms of how useful they are the sort would go first by correctness, then by speed, then by cost. Correctness is something I haven’t considered much until now because I took for granted that people generally got the job done right. While this is true on a very high level, on a low level certain people tend to cause a lot of problems for simple tasks while others can do reasonably complex tasks right the first time.

Some examples over the last week:

Bad: Today I spent the entire day doing level design. This was because the artist who was doing it did it wrong twice in a row, and it was so wrong it was less trouble to do everything myself than to try to explain why.

Average: Three times in as many days I had to have some outsourcing programmers make changes to the GUI for the autopatcher. This cost me a total of about an hour explaining the same thing over and over again (Document, match my coding conventions, no Hungarian notation). It would have cost me a lot of money too, but this was a fixed price contract to another company so it cost them instead.

Good: The sound artists noticed I was using FMOD so asked to use FMOD designer so they could do a better job of starting and stopping sounds on events, rather than just hard stopping as I was originally planning to do. Their solution was more correct than mine, so I ended up with a better game.

When you account for this and for speed, the cheaper guys aren’t any cheaper. You really do get what you pay for.

Angel Script not as beneficial as hoped

Saturday, April 21st, 2007

I spent about a week integrating Angel Script and exposing the Ogre function calls. My graphics programmer spend 3-4 days doing the same. In the end all that got done was billboards from scripts. This is because we had to implement so many work arounds for bugs and missing features in Angel Script that it was faster and easier just to do everything in C++, even not counting the initial setup time. For example, there is no way to have per-effect variables in script, and you can’t return pointers to objects that have member functions. There was no way to know this until really trying to use it, so I don’t place too much blame on myself. It was just bad luck. With more time invested these problems could be circumvented, but considering we already spent 10 days doing something that could have been done in 5 minutes in C++ it’s not worth the additional cost.

Most likely all further graphics work will be done in C++ and this will be revisited after the game ships.

Moving faster in the IDE while programming

Monday, April 9th, 2007

Here’s some possibly lesser known tips to move fast while programming (C++, Visual Studio)

Windows

  1. Add explorer to the quick launch bar. Under target, use “%SystemRoot%\explorer.scf”. Under start in, use “%HOMEDRIVE%%HOMEPATH%”. Both without the quotation marks. This way you can get to C: with one click, rather than starting at My Documents
  2. Similarly, in explorer, you can add local directories to the favorites list. I added the base directory to my game there.
  3. If you don’t have the show desktop button in the quick launch bar, add it.

Visual Studio

  1. Hit ctrl-tab and hold down tab to go between the most recent windows
  2. ctrl-minus to go back to the last cursor position (can be done repeatedly). ctrl-shift-minus to go forward
  3. ctrl-shift-v to get a list of recently copied items.
  4. Memorize and use the hotkeys for find in files.

Visual Assist

  1. Use alt-g to goto on a keyword or token. If the results are wrong, right click, go to definition or declaration. Between the two you can get to where you need to be.
  2. Use VAssistX under the menu bar, then go to refactor. Renaming there is very useful. You can also get this by getting a tooltip for a variable or function, then clicking the down pointing black arrow that usually comes up.
  3. Shift-alt-o to bring up a list of files, searchable by name.

UltraMon and multiple monitors

  1. Under options, select Smart Taskbar, use Smart Taskbar, and Mode: Standard. This gives you two task bars.
  2. Under options / Hotkeys / Move window to next monitor, I’ve bound alt+n. This way I can view 2 fullscreen documents without reaching for the mouse
  3. Both of my monitors run at 1600×1200
  4. When multiple copy/paste isn’t enough, I open UltraEdit as a notepad and can move quickly. UltraEdit also has a more powerful find/replace tool than Visual Studio and is better for dealing with multiple line replaces.

Script system done. But useful?

Saturday, April 7th, 2007

So I spent the last 5 days week implementing and exposing all of Ogre 3D to AngelScript, and I’m starting to feel it was a mistake. All I’ve gained is the ability to run code in text files, and reload them at run time. But that benefit is very limited – slow, hard to debug, less capable than the compiler. And for what I’m using it for I could have programmed it in C++ directly in 15 minutes. As a long-term solution, like if I had a year to develop this, this is a good solution because these text files could serve as data files as well and be output and worked with from an editor, with the ability to debug the script itself. But as a short term solution I’m feeling I wasted 5 days. I have nothing visible to show for my work and it’s not like I have plenty of time to spare. And the worst part is I’m not sure it’s going to work. Angel Script is pretty hard to use and understand. The forum support is good, and what they are doing is a difficult task so understandable to an extent. However, me figuring out means stuff takes twice as long as it should. For example, how do I handle casting references to pointers, or vice-versa? Why does declaring a parameter list of (void) not work, but () does work? Why did they decide not to support pointers, but to require reference counted objects? This means not only do I have to declare script classes for all my game classes, but I have to do it duplicate again for the pointer to that class as well.

If I could do this week over again I should have just hardcoded everything.

Indian outsourcing and literalism

Wednesday, April 4th, 2007

I had a guy from India call me today. He runs a programming company there that offers game related outsourcing for $25 an hour and offered to take on any tasks I might have.

I probably shouldn’t have said this, but the first words out of my mouth were “That sounds good, but I have very high standards about who I will work with, and I don’t work with junior guys.” I then went off on a short rant about how I hired guys from India before and everything got screwed up due to mindless literalism. I gave the example of how I asked for shader light support in my game, so my Indian ex-programmer implemented a shader that only supports one non-directional light ever. And although I said it in a nicer way, I ended with “I don’t know if all Indians are like this or not but if they are I don’t think your guys can do the job.”

Now that I reread what I wrote, it comes off as a lot meaner than how I said it, but the essence is correct. I’m just sensitive right now because I was really screwed by that whole ordeal. I lost 6 months of graphic development and over $10,000 paying the guy, not a line of code he wrote is still used, and now at the very last minute before shipping I have to hire someone really expensive to salvage the situation.

Anyway, we agreed they can start with a smaller task and see how it goes.

I sent them the spec to implement the Autopatcher GUI interface for Windows, for RakNet. This one got screwed up by mindless literalism about 6 months ago. This was back when my ex-programmer from the Ukraine was working for me. While he literally did design a GUI interface, it was the simplest thing you could do and still call it a GUI. It totally ignored the intent of the task, which was to make a nice looking interface with a graphical background, buttons, etc. that the artists could fill out. I was actually better off with the original console window than what he did, and it wouldn’t have costed me 3 days of pay and development time for nothing. On top of that he used some proprietary libraries with incompatible licenses with RakNet without asking first. Even if he had done something acceptable, I wouldn’t have been able to use his work.

I actually said in an interview a couple of days ago “I don’t like coming to people with problems, I like them coming to me with solutions.” That’s why my programmer from Portugal is so good. He thinks about the intent of the task (to make a good game) and tries to do a good job, rather than the bare minimum. So I can be confident that the final solution is smart and usable. It really helps having someone I know can do the job, and moving the schedule forward.

Somewhat related, so far I like outsourcing so far more than hiring people, except for programming:

1. I don’t have to spend time recruiting and interviewing
2. If they screw up, it’s their time and money loss, not mine
3. The pressure is on them to meet the agreed deadline, rather than on me.
4. It’s actually cheaper when you consider that I don’t have to train people, I can hire around the world, and I don’t end up with the situation of paying someone for days/weeks/months with nothing to show for it.

It’s a good way to go for art and sound.

Third (and last?) architecture for the effects system

Monday, April 2nd, 2007

My first attempt at an effects system was to assign it to my graphics programmer, who decided to define effects in an XML file. The theory was that you could do something like

[Effect]
– [Particle “fire”]
— [Play for 5 seconds]
– [Particle “smoke”]
— [Play for 2 seconds, delay start for 1 second]

This didn’t work out, in part because the implementation was mindlessly literal so didn’t solve the fundamental problem, and in part because of a lack of flexibility to begin with. As the system became more complex, more and more parameters have to be exposed and you just can’t do certain things.

The second approach, which I came up with, was to tag 3D models with triggers and effects based on locators. So you would place a locator in a file and define in the object properties an effect and a trigger. For example, on the thruster of the fighter I would have “Trigger=ForwardThrust Effect=ThrustParticle” This works, and is good for placing simple location based effects, but is not a complete solution and is hard to use and inflexible.

The fundamental problem, which I didn’t consider sooner, is that effect is such an open-ended term. It would be like if I asked you to write an effects system for a magic based RPG. No matter what system you came up with, I could come up with a reasonable counter-example as to why your system isn’t flexible enough. Effects (especially magic) do everything from lights that spin around the character, to glowing a specific part of the character, to time based events, to modifying and creating meshes, to reading specific game properties. You can’t really apply constraints to a fundamentally unconstrained system. Essentially you see stuff, and stuff happens, based on other stuff.

My third, and I think final approach, is to implement effects with scripts. So I’ll specify triggers in an XML. Each trigger references a script. And the script does all the effects, whatever that may be. If I need to tag specific points on a model, I will just lookup the locator in the .effect file. This should give me the flexibility I need, while still being easy to use and work with.

It’s one of those things that sound obvious when you hear it but wasn’t so obvious to begin with.

AngelScript integrated in half a day

Monday, April 2nd, 2007

I wrote about AngelScript a while back yet never had a reason to put it in the code up until today. This morning I was thinking about how to go about a general effects system for my game and concluded that the only thing flexible enough was either code or script. I specify effect files in XML settings, and those can’t refer to code (easily) so that left me with script. Plus this is really one of those rare times when scripting makes good sense:

1. Used in a limited fashion that won’t require much debugging
2. Extensible by modders in a situation where I don’t want to give out the source code
3. No better solution. I could make a full-fledged editor if I had the time and money, but I don’t.

I started on this about noon, went out for a good chunk of the day, and finished integrating it into the game now. I also created a sort of script instance system, where a script module (one or more related script files) is treated as a mini-program, with a per-tick update function, and a query function to indicate when the program was done. The script manager automatically handles tracking the pointers, and I did a pretty good job with the architecture the first time through for once, partly because my wife made me get the laundry and that 5 minutes away from the computer helped me solve problems in my head before I spent a lot of time coding. So this instance system will be perfect for effects as they update every tick doing stuff, and end after some amount of time.

I think it’s pretty good work that in one day I went from the vague problem of how to implement effects, to a working script framework for it.