Category: Game Development

My game is about 90% ready for Alpha now. The DB is complete and tested, except for a few bugs. There’s no known significant bugs in multiplayer based on superficial testing. After a real gameplay test I think it will be ready. We have a real map prepared, although it needs polish. The fighters, weapons, items, XP settings all have reasonable settings which can be tweaked while playing. It’s possible to create accounts through the billing provider and I’m in the final stages of setting up a merchant provider. I am able to build on the development server and have a real database and game server ordered and coming. The webpage and forum is setup, although needs content.

I still have to test all the other game modes, fly the carriers around, test actually buying carriers, and importing external objects into levels. Also the explosion effects and other effects were never done well or right for carriers. This should all be straightforward though.

It’s about 2 1/2 months late right now to reach this point, assuming everything from here on out goes smoothly. The next major target is to get the server supporting and running properly with 500 players. Scaling at that point is just adding more servers. After that it’s just polish remaining really.

Games with only a few players (say 8 or less) can send all updates to all other players. In these types of games, most players are usually grouped together anyway, and even if they are not the overall bandwidth is low enough it’s not a big deal. The “wasted” bandwidth isn’t a bad thing necessarily. It makes programming easier, it’s more accurate, and you can do things such as game-level radars easily.

Games with more players, such as your average shooter (32-64) should only send updates to players that are nearby. The way they usually do this is to base frequency of sends on relevance. A player farther away gets fewer sends, a player I am facing gets more frequent sends. This is an O(n^2) problem because for every player I have to determine the orientation to every other player. In the worst case scenario of 64 players, this is 4096 operations. However, since this occurs at a maximum interval of your packet send rate, it’s not a big deal.

MMOGs such as mine, with many players (500 on one server) have the O(n^2) scenario as above, but there are too many players now. This would be 250,000 operations doing it the straightforward way. In my particular case, while I have a maximum send interval, I cheat on this in many ways, so in essence I need to recalculate this every frame.

The solution I came up with is to split up the world into a grid. Every update all objects go into one or more cells of the grid, depending on how big they are. This is an O(n) operation, and a pretty fast O(n). Then for each player, I query the grid to get the nearby neighbors. This goes into a sorted list, which I use to get a list of all nearby neighbors, as well as checking if a particular object is nearby.

Total cost is O(n) for the grid sectorization, and O(n) to go through each player to sort the nearby neighbors. Inserting into a sorted list is slower, but since there are on average only 10 items it’s not a big deal.

An “operation” is a bit misleading since different things that I do have different costs. But for the sake of argument…

500 players each with 10 objects nearby =

500 operations to place the players into the grid +
500 insert nearby objects. Assuming each insert is O(1) (it’s actually O(Log2(m) + O(m) where m is the number of nearby objects (10)), then this is Sum(1…10) = 55.

500 + 500*55 = 28,000. It’s a lot of operations, but still far less than 250,000, and scales linearly.

I further decrease this by using the fact that network nearby neighbors doesn’t have to be perfectly accurate. It’s good enough to update every 100 milliseconds, instead of every tick. So every 100 milliseconds I do the full-blown update. In other ticks I just cull out the deleted pointers and use the previous list.

This brings it down to an average of 933 operations per tick, assuming we do 33 milliseconds ticks.

Originally, as I implemented the bullet shooting code I would have the client send the bullet’s velocity,position, and orientation to the server. The server would verify these values for sanity and if they were reasonable it would accept them. Otherwise it would reject them.

It occurred to me this isn’t very cheat-proof, especially since I allow modders to change the model. While it would block the most extreme cheats, you could still angle your weapons, shoot slightly faster or slower, or even auto-aim.

I changed it to where I record all fighter positions for the last second in a circular queue. When a shoot packet comes in, I use the timestamp to look back in history to see where the fighter was on the server when the bullet was fired.

This is cheat-proof, pretty accurate, and the only thing you could modify is the timestamp. But there’s really no benefit from changing the timestamp, as any changes will simply make the shot less accurate.

Whoever thought of manifest files for VS2005 should be shot. Right now my artist’s can’t run the game due to this crap. Already wasted 4 hours trying to figure this out, and am getting nowhere.

No longer can you include the necessary DLLs. Now they have dependencies embedded into the assembly, and it checks in weird system paths using the registry. Unless the person trying to run the game has these dependencies already (or Visual Studio 2005 installed) they can’t run it. I can’t actually test since I do have VS2005, so I have to grab people to help me try installing the game.

Your choices: Either (maybe??) use the HORRIBLE installer included with Visual Studio 2005, or … um I don’t know. The reason their installer is horrible is that it’s hard as hell to use, and I have to go through every single file in my game, one by one, and add it to the installer. No way am I going to do that. It also can’t find dependencies by 3rd party DLLs. It also doesn’t generate a single file for the installer, but 2 files (???). So there’s not one download but 2. Forget about it.

I tried copying a .manifest file from another program, along the DLLs. that should work I think, except that I’m using a whole bunch of libraries. Do I need to somehow find the source for those other DLLs and turn off manifest generation there too, and rebuild everything? I’m not sure that’s even possible, and if it were it would take me days to hunt down the source. Anyway, it doesn’t work.

I tried having my testers install the VS redistributable runtime but it also didn’t work.

I’m sort of running out of options here aside from installing VC6, getting things to build there, and using that instead.

Goddamn it. I just want to get this freaking game done and it’s always something to waste my time.

* EDIT *

I finally figured it out. I didn’t know there was a VS2005 redistributable for versions both with and without SP1. I didn’t see the SP1 version on my prior google search, and had my artists install the one without. I had one user install it with the SP1 version and it worked.

I’m also going to distribute the .manifest and dlls alongside the application. This was actually one of the first things I tried, and it didn’t work, so I think it’s more for versions of Windows that don’t have side by side assemblies at all. I saw that FMOD designer and most other installed applications did this, so in all probability it will work.

I lost like a year off my life today in stress.

The first looming disaster of the day was the ongoing problems getting setup support with our billing service provider. It was getting to the point where unless it were resolved immediately, and it didn’t look that way, the project would have to be canceled for lack of ability to take payment and lack of time to write a solution. Ouch. Just by fortunate chance, the CEO of the company had posted on my blog before, back when I required registration to stop spammers. As a last resort I grabbed his email address, shot him an email asking for help, and got a phone call an hour later. I was really impressed by the positive attitude of the new person I was working with at that point. I’m pretty sure things will work out now and this problem is behind me.

The second disaster was, as I previously posted, CEGUI is SOOOO slow at rendering text. It does a full draw call for every letter, recalculating the screen every update. I vacillated between writing my own system, fixing CEGUI, switching libraries, or just bypassing the problem in some other way. There was no easy solution in sight, and they all came with drawbacks. But my programmer in Portugal found a design flaw with CEGUI – we were hiding the root window, rendering the compositor, and then showing it again. Doing this caused a full-rebuild of every element on the screen. When combined with how CEGUI treats every individual letter as a widget, it dropped the FPS between 50%-75%.

I added a hack to System::renderGUI(void) block the variable “d_gui_redraw” from changing between the compositor start and end and that fixed that part. Another problem is that calling setAlpha, setFont, or setText with the same as the current value signals an unnecessary rebuild. So I changed CEGUI to check for that. The last thing is that CEGUI redraws the screen anytime any element changes. So I had to disable the clock, coordinates, and energy text since they update almost every tick. I switched over to displaying them with Ogre overlays instead.

I still have a lot of stress as Alpha is several days late now, but with these problems out of the way, and a few annoying bugs, I can at least start looking at making an Alpha build again.

The last half-week I’ve been working with artists to try to get their levels working right.

Right now this is turning into a big risk for the project. I paid $1200 for an add-on called oFusion so the artists could theoretically see how things look in the game within the modeling program. But support is too slow and the bugs are killing me.

I had a real dilemma yesterday with how to export materials.

I could:

1. Create materials by hand in text files, which is good because they are source controlled and I can easily change common properties. But then, due to bugs, the artists could not see what they are doing in the game. And also as sort of a hack I would have to name materials in the modeler exactly the same as in the text file. This means I have to do everything myself because that takes too much rigor for the artists to handle.

2. Specify in oFusion which material file I am using. This was a feature I requested, but was buggy to the point of being unusable, and caused problems in step 3.

3. Create everything using oFusion’s preferred system, which is basically to program the material in a GUI through MAX. This means every material takes about 5 minutes for me or 30 minutes for an artist to setup because you really are programming the material. Materials cannot be source controlled and changing any common property means every material in the game needs to be recreated. Worse, because step 2 could not be turned off once activated, I had to delete and recreate the object entirely.

I ultimately went with step 3, because this was the only thing that worked at all.

I’ve been waiting for support to get back to me on various bugs for half a week now and so far no response. This is such a critical time I can’t just drop oFusion or I would and ask for a refund and hire someone to program a decent exporter. Maybe the author is ignoring me. I’m trying really hard to keep a neutral tone in my bug reports but maybe some of my frustration is showing through.

End loss: $1200, plus about 200 hours of my own time, 100 hours of artists time.

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.

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.

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.

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.