Slashdot Mirror
The Minerva Half-Life 2 Mod
Via GameSetWatch, an interview with Adam Foster. The creator of the Minerva Half-Life 2 mod talks about the reasons he's putting time and energy into a fan-made labour of love. From the article: "Single-player mapping ...does have quite a tradition, and sadly it often seems to be looked down upon by many gamers. It's somehow regarded as 'easy,' with multiplayer maps being the only true form of expression. I suppose the countless fullbright cubes packed with zombies must put off a lot of people, as do the endless bare BSPs which need to be run from the game console..."
As the chief coder for a singleplayer mod for the first-generation Unreal engine, I have a few things to say about this.
Singleplayer and coop support are a lot more feasible for developers than people would expect, compared to multiplayer. For one thing, MP is usually implemented on top of the SP infrastructure anyway, meaning that coop is not really a big stretch after basic multiplayer is added. In many cases, it would actually be more efficient to implement coop MP first, and then build competitive and team-based MP on top of that. The decision to do otherwise is a marketing strategy, rather than a technological one. SP usually sells the game, and competitive MP keeps it alive and builds a community around it. Coop has less success with this.
As far as design is concerned, it splits into two major fields: netcode and AI. First, your netcode must be as efficient as possible, which means being VERY selective about what type of data your game server spends bandwidth on, which means using a lot of simulated stuff. For example, I personally believe that trying to get map data a piece at a time while the player is playing the map is a serious no-no. The client should be forced to download the map and supporting files such as sounds and textures (preferably from a dedicated mirror), have them verified, and then run this local copy before he is allowed to log into the server as a player.
Netcode must also be built into each object created in the game, which is probably the hardest part. For example, the client doesn't usually need to know a monster's health unless the player has the ability to ask. It's the server's job to keep that information. If a monster's behavior changes because of an increase or decrease in health, then the player is sent THAT information rather than the health. Also, as far as explosions and gratuitous special effects are concerned, the server should usually just say the equivalent of "A rocket just exploded at these coordinates. Render it yourself." to the client. And one player doesn't need to know that another has a shotgun hidden in his inventory, unless he pulls it up as his active weapon.
Then there's the matter of relevancy culling, to decide what is not a priority for transmitting. The monster you're fighting right now is relevant. The flags in a CTF team game are always relevant no matter where they are. The appearance of your teammate's HUD is not relevant. The guy who just got himself fragged on the other side of the map is probably not relevant, unless you saw it through the scope of your sniper rifle at the time. The straight-flying rockets you just fired are not relevant except as they first spawn, because their physics is simulated on the client, and the server will tell you if/when they hit something.
The second part of this design is the map itself, mostly relating to AI. The policy of "stupid code + smart data" has never been so important here. If your bots don't know how to use a weapon, then it's usually the WEAPON that's badly coded, not the bots. The same is true for maps. Only the most bare minimum AI code should exist in the code for bots and monsters (though this is still usually quite a bit). Anything "special" that they need to do should usually be a feature that is scripted by the mapper using custom or preexisting actors, rather than hardcoded into the game's AI by the coder. As an example, the Unreal engine has always relied on AI navigation of its maps through a network of "PathNodes" that mappers place throughout all the reachable areas in the map. This is what enables a bot to concievably navigate a maze-of-the-minotaur style map better than a typical Human player could. (I do not know enough about other gaming engines to comment on them.)
As a result, reasonably selective netcode combined with gametype- and map-centric AI is the most effective way to design a game engine. The kicker is that most of this is not really even a programming endeavor, but is better considered to be an extension of the d