Custom game modes and other such moddery
Fang_Xianfu
Join Date: 2004-09-04 Member: 31344Members
Join Date: 2004-09-04 Member: 31344Members
Firstly let me say I'm <i>so excited</i> about NS2! Every day it creeps closer, like a stealth focus skulk coming to bite off your ankles, except your ankles are your expectations about what modding a game means, and the bite feels awesome. It feels like freedom.
I'd also like apologise if this has been discussed before - one of the disadvantages of podcasts and videocasts is that they're not easily searchable, and I'm not relistening to hours of material. I have three suggestions I'd like to put forward regarding mods; the first is about how custom game modes are handled, the second is about how client-side mods enforced on the server are handled, and third is about how servers communicate to clients that they're running a mod.
1) <b>Incorporate the game mode code (.lua) into the actual map file.</b>
We all know that combat mode won't be included at release - someone's going to write a mod to do it. That mod will have many different versions, and many maps will use all different versions of it. It's going to get very confusing very quickly, having tens of maps all running different versions of the same mod, and all trying not to interact badly with each other. The same will be true for maps that're a skulk race, or siege maps, or whatever.
So, a combat map file should include all the code the server needs to understand what "combat mode" is. At the very least, the .lua file for the map should be kept in the same place as the map, like .res files were for half-life maps, and the server should send it to the client just like it would those files. This makes it as easy as possible for mod developers, level designers, server admins and users.
a) Mod developers can just release their mod. They don't have to worry about maintaining complete backwards compatibility - it won't break existing maps instantly and level designers have a chance to check out the new code and fix any problems before it blows up any servers. They don't have to worry about badgering server admins to update, or that some servers might want to keep using the old version of the mod - if they want that, they just have to not upgrade their map.
b) Level designers are given all kinds of options. They're not limited by things they didn't like in the "combat mode" mod, or things that didn't fit their map, because they can edit the .lua for their map and remove the features they didn't like, or add ones that they did. Perhaps their map is a combat map, but the marines can add time to the timer by completing a secondary objective or something - it'd be easy to add and would only affect that one map.
c) Server admins don't have to worry about keeping a different version of a mod for each of their maps. Each map has its own associated game mode file, and the onus is on the level designer to ensure that his map is compatible with the game mode code he's releasing with it. All the server admin has to do is install a new version of the map when one is released.
d) Clients don't have to do anything. Any files they need to play a map, including any game mode mods in it, are automatically downloaded from the server. Which handily brings me onto point 2:
2) <b>Downloading mods should be automatic for clients.</b>
If a client tries to connect to a server running a mod they don't have, the server should send it to them. I'm not talking about 400mb total conversions, I just mean little mods like one that'll make Scent of Fear change colour the lower the marine's health is, or give the marine flashlight a timer bar, or something. Things that'll change the UI and thus need some client-side changes, but that're only little things. The client should be able to connect to a server running such a mod and have it Just Work, and still be able to connect to servers not running the mod just fine as well.
It always grated on me a little bit that mods like the building and extra levels mods for combat mode couldn't have their own pretty-looking UIs, instead having to rely on quite rubbishy number-menus. Imagine how much easier it'd be to use adminmod, as well, if you didn't have to navigate through 100 menus to do it! The important part is that this stuff should be downloaded from the server automatically on connection, so that the client's mod will always work with the server, with minimal effort.
And finally:
3) <b>For the love of god, allow tags for servers to describe the mods they're using, like TF2 does.</b>
I think that's pretty self-explanatory. It should be as easy as possible for a client to find out what mods a server is running, and to find servers that're running a particular mod, or that aren't. Tags are the best way to do that.
And finally, let me just reiterate how utterly stoked I am about this game. It's going to be <i>glorious</i>.
(Too long? My missus never complains...)
I'd also like apologise if this has been discussed before - one of the disadvantages of podcasts and videocasts is that they're not easily searchable, and I'm not relistening to hours of material. I have three suggestions I'd like to put forward regarding mods; the first is about how custom game modes are handled, the second is about how client-side mods enforced on the server are handled, and third is about how servers communicate to clients that they're running a mod.
1) <b>Incorporate the game mode code (.lua) into the actual map file.</b>
We all know that combat mode won't be included at release - someone's going to write a mod to do it. That mod will have many different versions, and many maps will use all different versions of it. It's going to get very confusing very quickly, having tens of maps all running different versions of the same mod, and all trying not to interact badly with each other. The same will be true for maps that're a skulk race, or siege maps, or whatever.
So, a combat map file should include all the code the server needs to understand what "combat mode" is. At the very least, the .lua file for the map should be kept in the same place as the map, like .res files were for half-life maps, and the server should send it to the client just like it would those files. This makes it as easy as possible for mod developers, level designers, server admins and users.
a) Mod developers can just release their mod. They don't have to worry about maintaining complete backwards compatibility - it won't break existing maps instantly and level designers have a chance to check out the new code and fix any problems before it blows up any servers. They don't have to worry about badgering server admins to update, or that some servers might want to keep using the old version of the mod - if they want that, they just have to not upgrade their map.
b) Level designers are given all kinds of options. They're not limited by things they didn't like in the "combat mode" mod, or things that didn't fit their map, because they can edit the .lua for their map and remove the features they didn't like, or add ones that they did. Perhaps their map is a combat map, but the marines can add time to the timer by completing a secondary objective or something - it'd be easy to add and would only affect that one map.
c) Server admins don't have to worry about keeping a different version of a mod for each of their maps. Each map has its own associated game mode file, and the onus is on the level designer to ensure that his map is compatible with the game mode code he's releasing with it. All the server admin has to do is install a new version of the map when one is released.
d) Clients don't have to do anything. Any files they need to play a map, including any game mode mods in it, are automatically downloaded from the server. Which handily brings me onto point 2:
2) <b>Downloading mods should be automatic for clients.</b>
If a client tries to connect to a server running a mod they don't have, the server should send it to them. I'm not talking about 400mb total conversions, I just mean little mods like one that'll make Scent of Fear change colour the lower the marine's health is, or give the marine flashlight a timer bar, or something. Things that'll change the UI and thus need some client-side changes, but that're only little things. The client should be able to connect to a server running such a mod and have it Just Work, and still be able to connect to servers not running the mod just fine as well.
It always grated on me a little bit that mods like the building and extra levels mods for combat mode couldn't have their own pretty-looking UIs, instead having to rely on quite rubbishy number-menus. Imagine how much easier it'd be to use adminmod, as well, if you didn't have to navigate through 100 menus to do it! The important part is that this stuff should be downloaded from the server automatically on connection, so that the client's mod will always work with the server, with minimal effort.
And finally:
3) <b>For the love of god, allow tags for servers to describe the mods they're using, like TF2 does.</b>
I think that's pretty self-explanatory. It should be as easy as possible for a client to find out what mods a server is running, and to find servers that're running a particular mod, or that aren't. Tags are the best way to do that.
And finally, let me just reiterate how utterly stoked I am about this game. It's going to be <i>glorious</i>.
(Too long? My missus never complains...)
Comments
Personally, I love the idea. I know Charlie has a specific idea as to how the core of the game should be played, and, based on prior comments, I don't see NS supporting a slew of game modes out of the box nor a lot of map side flexibility that is seen in the HL1/2 engines in terms event triggers and entities. Then again I could be wrong.
Looking at NS2's future, this concept would do much for the longevity of the game.
There's a difference, I think, between including game modes and making it as easy as possible for people to make their own, though. Modifiability is one of the famous <a href="http://www.unknownworlds.com/ns2/about/" target="_blank">four pillars</a> and making it possible to make, say, a skulk race map is useless if it's an incredibly complex process.
I tried to focus my suggestions towards things that I assume won't be easily changed by end-users - the way loading of script files is handled, the file formats NS2 uses, the way servers and clients send files and things to each other. I'd assume those things are being handled by the engine code and thus aren't changeable through scripting. I do have a whole host of other questions, ideas and suggestions around mods, but they're all about specifics of NS2's Lua environment and other things that can wait until I actually have the tools in front of me <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" />
<!--quoteo(post=1708512:date=May 30 2009, 11:47 AM:name=MrRadicalEd)--><div class='quotetop'>QUOTE (MrRadicalEd @ May 30 2009, 11:47 AM) <a href="index.php?act=findpost&pid=1708512"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->this concept would do much for the longevity of the game.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm glad you agree <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
If a client tries to connect to a server running a mod they don't have, the server should send it to them. I'm not talking about 400mb total conversions, I just mean little mods like one that'll make Scent of Fear change colour the lower the marine's health is, or give the marine flashlight a timer bar, or something. Things that'll change the UI and thus need some client-side changes, but that're only little things. The client should be able to connect to a server running such a mod and have it Just Work, and still be able to connect to servers not running the mod just fine as well.
It always grated on me a little bit that mods like the building and extra levels mods for combat mode couldn't have their own pretty-looking UIs, instead having to rely on quite rubbishy number-menus. Imagine how much easier it'd be to use adminmod, as well, if you didn't have to navigate through 100 menus to do it! The important part is that this stuff should be downloaded from the server automatically on connection, so that the client's mod will always work with the server, with minimal effort.<!--QuoteEnd--></div><!--QuoteEEnd-->
There should be an option here to download the content from a web server.. sv_downloadurl for HL1/2 is an amazing thing. Included in that should be a referrer stating what server ip/port the request is from (easy to do), and hopefully compression (harder to do)