Announcement

Collapse
No announcement yet.

Why Are Networked FPS Games So Stagnate?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why Are Networked FPS Games So Stagnate?

    Originally posted to my blog but inspired by events here, so posting here as well. Not sure where it fits. It is game related but not specific to any single game; just the genre we love to play.


    When Doom was released back in 1993 one of its biggest features was that it sported 4-player coop and competitive play over IPX networks. In 1996 Quake advanced the FPS genre by moving the games over to TCP/IP and introducing the server browser. 14 years later the graphics, sound, immersion and game play have advance at mind-boggling rates. Meanwhile the tools given to the players and administrators are still stuck in the 1990s.

    My most resent passion is EA/DICEís latest entry, Battlefield: Bad Company 2 (BC2). Released just a month or so ago I am already to the breaking point on the frustration this title has. I play in a community which has strict game play standards. Certain actions are verboten and when other players (especially of that community) is seen engaging in those actions players are encouraged to report them.

    Except BC2 makes it insanely hard to figure out who is doing what. You canít tell a personís name by looking at them. You can hope to kill them. But the best method, really, is to die to their hand and see the kill message. Except in BC2 the kill message is instantly obscured by the UI. So in the end many actions cannot be adequately reported.

    Furthermore BC2 follows a long line of FPS servers which provide the server administrator with an abysmal set of tools with which to maintain their server. Queue handling? I have not been on the server-side of things given DICEís draconian rules for servers but I would be surprised if anything past basic logging is available for researching the incident after the fact.

    But then again, BC2 is a console port so it stands to reason that if they canít do it with a console they arenít going to do it on the PC. I understand. But this problem is not contained in BC2; it is just the latest and most egregious example. Battlefield: 2142 (BF2142), Battlefield 2 (BF2), Team Fortress 2 (TF2), Counter-Strike: Source (CS:S) all exhibit the same problem. Iím fairly certain the Unreal Tournament (UT) line as well as the Quake line do as well.

    There are certain problems that manifest with every game. And while early TCP/IP FPSes such as Quake, UT and Counter-Strike (based on the Half-Life engine, itself a retooled Quake engine) can be excused from addressing them on account of them being the vanguard of the genre. They would have had to anticipate these problems. Battlefield: 1942 (BF1942), BF2, BF2142, UT2k, Quake 3, UT2004, UT3, CS:S, TF2 all should have learned from the problems suffered by those games and addressed them in release. Instead each one has thrown some scripting capabilities into the game and left the respective player communities to solve the problems.

    What problems?
    • Cheating and proscribed actions being the most obvious. Yet I havenít heard of any game engine which has a visual port for admins. To get a visual idea of what is going on they need to log into the game proper. Which brings up the second problemÖ
    • Queue management. It is completely stupid that after a decade of server limitations on slots the developers have invested absolutely no time in addressing how players connect to servers. Every game, at base, leaves it to the player to check the server for free slots and to join. When a free slot is seen you have to slap the join button and pray your machine is fast enough to get that slot before someone else does. Sure, TF2 has an auto-refresh and auto-join, but that changes nothing since you still can be beaten to the slot. Even worse, it fails on servers which leave 1-2 slots free for members. MMOs have had queues for at least a decade now. Why canít FPS servers do so as well? That way the community can address supporting members vs. pubbies in the scripts.
    • VOIP is becoming more ubiquitous but every game seems to want to reinvent the wheel. For example, BC2ís is broken at release. Seriously, game developers, hereís the easy solution. If you can build in GameSpy and PunkBuster, use OGG Vorbis for sounds, license BINK for video, for the love of $deity license Ventrillo or Teamspeak or even just use the FOSS solution, Mumble! It is kinda sad that the open source VOIP option not only works, sounds great, but provides positional audio based on where the players are standing in-game! IE, it is more advanced than the schlock youíre reinventing, use it and concentrate on other things; like queue management and decent admin tools!


    I could go on but my soapbox is starting to creak. The above points are just the major ones that honk me off about every FPS. Itís closing in on 20 years since the first network FPS debuted on the PC. Itís time the developers advanced the tools needed to operate that portion. Iím not asking for the perfect shine like theyíd put into the graphics engine. But a little advancement to help the people who make those games as popular as they are would be greatly appreciated.
    "...the rules aren't there to enumerate what is always correct but what is always wrong..."

  • #2
    Re: Why Are Networked FPS Games So Stagnate?

    I think most game companies have taken a " let someone else deal with it attitude"

    Most times, gamers us TS or VENT or whathaveyou so the game company doesnt see the real "need" to get working VoN. "They have TS so its ok"
    With admin tools alot of times they come from third party devs so the game company can say "Meh, we will just let these guys figure it out"

    I firmly believe that to be the problem. They have concerned themselves with having the pretty stuff and the like being brought to the foreground they forget or neglet the things that really matter to the online communities. I agree with all of your points and have made the same comments myself, but sadly, I dont think they will change. But, we can always cross our fingers and hope that the next CEO has a dab of common sense.

    [unit][squadl][command2]

    KnyghtMare ~You could always tell the person holding the gun to your head you would like to play on a different server...

    Comment


    • #3
      Re: Why Are Networked FPS Games So Stagnate?

      Sounds a little uninformed to me grey. All source games have the best admin tools around. UT3 has pretty good admin tools as well. I'm not sure about quake though.

      Some iterations of cod have had great tools. Where I think you're seeing a problem is simply console games made for the PC. The developers didn't have to make any tools for the community and just dropped the game on the pc market to milk it for money.


      - -

      Comment


      • #4
        Re: Why Are Networked FPS Games So Stagnate?

        Originally posted by Vulcan View Post
        Where I think you're seeing a problem is simply console games made for the PC. The developers didn't have to make any tools for the community and just dropped the game on the pc market to milk it for money.
        IIRC, DICE has always been lacking with admin tools in the BF series. In both BF2 and BF2142, it was third party developers that created them.

        Comment


        • #5
          Re: Why Are Networked FPS Games So Stagnate?

          Originally posted by Greyed View Post
          • Cheating and proscribed actions being the most obvious. Yet I havenít heard of any game engine which has a visual port for admins. To get a visual idea of what is going on they need to log into the game proper. Which brings up the second problemÖ
          Half life TV - (HLTV) allows outside players to watch a half life game in real time. This was enjoyable for Natural Selection, a Half Life Mod, and was widely used for counterstrike.
          • Queue management. It is completely stupid that after a decade of server limitations on slots the developers have invested absolutely no time in addressing how players connect to servers. Every game, at base, leaves it to the player to check the server for free slots and to join. When a free slot is seen you have to slap the join button and pray your machine is fast enough to get that slot before someone else does. Sure, TF2 has an auto-refresh and auto-join, but that changes nothing since you still can be beaten to the slot. Even worse, it fails on servers which leave 1-2 slots free for members. MMOs have had queues for at least a decade now. Why canít FPS servers do so as well? That way the community can address supporting members vs. pubbies in the scripts.
          Half life and HL2 games + TF2 have the ability to join when a spot opens up. Project Reality, a BattleField 2 mod, has this feature and you can even set the number of active players that triggers the join attempt (ie you can set it to 60/64 players for those servers with kick scripts)
          • VOIP is becoming more ubiquitous but every game seems to want to reinvent the wheel. For example, BC2ís is broken at release. Seriously, game developers, hereís the easy solution. If you can build in GameSpy and PunkBuster, use OGG Vorbis for sounds, license BINK for video, for the love of $deity license Ventrillo or Teamspeak or even just use the FOSS solution, Mumble! It is kinda sad that the open source VOIP option not only works, sounds great, but provides positional audio based on where the players are standing in-game! IE, it is more advanced than the schlock youíre reinventing, use it and concentrate on other things; like queue management and decent admin tools!
          I agree on the inconsistent in game VOIP and that most gaming companies fail to implement these features which should be the foundation of multiplayer games instead of just the fancy graphics.
          |TG-6th|Snooggums

          Just because everyone does something does not mean that it is right to do.

          Comment


          • #6
            Re: Why Are Networked FPS Games So Stagnate?

            Originally posted by draeh View Post
            IIRC, DICE has always been lacking with admin tools in the BF series. In both BF2 and BF2142, it was third party developers that created them.
            That's the standard. Developers leave open the game for commands to be implemented by third parties. It's the extent at which they do this that defines how well a game can be run by the players.
            Last edited by Vulcan; 04-16-2010, 07:38 PM.


            - -

            Comment


            • #7
              Re: Why Are Networked FPS Games So Stagnate?

              Originally posted by Vulcan View Post
              Sounds a little uninformed to me grey. All source games have the best admin tools around. UT3 has pretty good admin tools as well. I'm not sure about quake though.
              No, the source games now have great tools. But when Source first hit the scene the admin tools were lackluster at best until the admin mods were written for it. Even now it does not implement queuing or an admin only viewing feature. Furthermore most well run TF2 servers are well run because of the admin mods, not the base TF2 tools.

              Some iterations of cod have had great tools. Where I think you're seeing a problem is simply console games made for the PC. The developers didn't have to make any tools for the community and just dropped the game on the pc market to milk it for money.
              Actually the only game on the list I mentioned which was a port from console to PC was BC2. I pointed that out and even stated it might be why the game's admin side is such crap. The rest I either have first hand knowledge of unmodded admin or have spoken with people who have.

              Originally posted by snooggums View Post
              Half life TV - (HLTV) allows outside players to watch a half life game in real time. This was enjoyable for Natural Selection, a Half Life Mod, and was widely used for counterstrike.
              This is not an admin only viewing port. I am aware of HLTV. However unless things changed recently admin was not available there. Granted, this is easily mitigated by the admin port and a telnet client. Point is that it should be standard and shouldn't require a telnet client.

              The tools should be built in. I should not need to look here, then alt-tab to another screen or turn to my mini and do things there. I should be able to observe anyone at any time and, on the admin port, have key mappings to turn on LOS pointers, toggle first-and-third person, standard warning, kick, and ban not only by name but by user ID, IP or a combination thereof.

              Remember, on most games, even TF2, we have most of that now not from built-in stuff but from admin mods.

              Half life and HL2 games + TF2 have the ability to join when a spot opens up.
              Which I acknowledged. I pointed out the client has auto-refresh and auto-join. That, however, is not a queue. If you have 5 guys waiting on a slot it is whomever refreshed the closest to the slot opening up and then who loads the fastest (fastest machine). Furthermore, as I pointed out, for servers, like our PR server, which keeps slots open for supporting members to join that system fails. I joined, get kicked. So I have to manually refresh for a slot and join.

              Project Reality, a BattleField 2 mod, has this feature and you can even set the number of active players that triggers the join attempt (ie you can set it to 60/64 players for those servers with kick scripts)
              Again, aware of that. It is not a queue.

              Originally posted by Dredge View Post
              Most times, gamers us TS or VENT or whathaveyou so the game company doesnt see the real "need" to get working VoN. "They have TS so its ok"
              For pure shooters like Quake or TF2 that is fine. Even then, however, it requires all players to know the information, join, and get on the correct side.

              For games which implement in-game squads like the BF series, that is a failure as BC2 has proven. For those games by licensing Vent/TS each squad is a channel, moving squads is just a channel change. The mechanics and implementation is all there. No need to reinvent the wheel. With Mumble they can get that as well as positional chatter, too.

              Originally posted by Vulcan View Post
              That's the standard. Developers leave the open the game for commands to be implemented by third parties. It's the extent at which they do this that defines how well a game can be run by the players.
              A point I did touch on. I did say we get to write admin mods. Point is that after over a decade certain features which have been programmed again, and again, and again in mods should be a big red hint to the developers that those features should be built-in. The scripting is fine, and it should remain. But the basic tools need updating from their lackluster '90's roots.
              "...the rules aren't there to enumerate what is always correct but what is always wrong..."

              Comment


              • #8
                Re: Why Are Networked FPS Games So Stagnate?

                A point I did touch on. I did say we get to write admin mods. Point is that after over a decade certain features which have been programmed again, and again, and again in mods should be a big red hint to the developers that those features should be built-in. The scripting is fine, and it should remain. But the basic tools need updating from their lackluster '90's roots.
                I'm glad they don't as are many others. People like to write their own styles and options. That's why it's the standard for most games to only put basic end user tools and leave it open for the community build upon.

                To that end, many user tools have more than made this area infinitely better as each game uses different programming the time and effort needed to build all the options that players now expect takes quite a bit of time and testing. That's why it's perfect for the player base to handle it and they like to do it. It's good experience and inspiration to get people involved in the game. It's basically modding but with admin and player features.

                A game with bad voip to start is pretty lazy though it's not the standard but given a choice during their timeline of making the product, it's definitely on the lower end of priority. That could change for sure. The games in the 90's never had online voice though.


                - -

                Comment


                • #9
                  Re: Why Are Networked FPS Games So Stagnate?

                  Originally posted by Vulcan View Post
                  I'm glad they don't as are many others. People like to write their own styles and options. That's why it's the standard for most games to only put basic end user tools and leave it open for the community build upon.
                  To that end, many user tools have more than made this area infinitely better as each game uses different programming the time and effort needed to build all the options that players now expect takes quite a bit of time and testing. That's why it's perfect for the player base to handle it and they like to do it. It's good experience and inspiration to get people involved in the game. It's basically modding but with admin and player features.
                  I don't disagree. I am not arguing that they should remove scripting in favor of built in tools. I'm saying that they should provide better in-game tools in addition to the scripting we have come to expect. Let me give an example.

                  Right now it is nearly impossible to implement a proper queue for servers. I can see how it could be done but the practical application of it is absurd in the extreme for most communities. I firmly believe that modern FPS developers are quite aware that the servers for well-run and well-liked communities like TG can often times be packed to the giils.

                  Presently the two leading methods the community has devised is pre and post connect kicking. TG uses post-connect kicking. It leaves 1-2 slots open for people to connect and once they are connected and authenticated a non-authenticated person is chosen, by whatever method, and booted. The problem here is that the server is "full" without being full so you just have to know. Otherwise you connect and immediately get booted. Furthermore it ejects people on arbitrary and often unfair criteria. For example, our PR server boots the non-SM who has played the longest. This seems fair in that it rotates non-SMs in and out of the game. However it is unfair in that it punishes non-SMs early on who probably helped seed the server.

                  Pre-connect I've seen on TF2 in another one of my online communities. The member enters a code into a web site which, in turn, uses the admin port to issue a command to a mod that kicks someone to make room for the member. Then they have x minutes to connect during which time if anyone else connects, even another member who has not gone through that tool, they are kicked. In this case the server at least shows full when it is full but it isn't without its own problems.

                  So, enter a proper queue. The player starts the client and wants to connect to their favorite community. They select it and are entered into a queue. They see the countdown as people leave. Already this is better on several fronts. First, people who are playing don't need to be kicked. Second, it completely negates the issues with the TF2 style auto-refresh and auto-join being a race condition. Third, an enterprising developer could have it so a player is in multiple queues at once and on first-connect drops from the other queues. Prefer non-hardcore BC2 but BC#1 and BC#2 are full? Enter the queue for both and when a slot becomes available on either, you're in! Tell me that's not a win.

                  But, as I said, that isn't supposed to be a replacement for community scripts but merely addressing a common problem. It is clear popular FPS servers need queues and it is clear the current scripting capabilities cannot handle it. But implement the queue, let the queue logic be scriptable, then envision what TG's servers would be like. Let's take the PR server.

                  Now: 62 max players, 64 slots. 2 slots reserved to allow SMs to connect. Post-connect script which might boot non-SM seeders. If the server fills with SMs no queue at all, just refresh and join race for everyone.

                  W/scriptable queuing: 64 slots, all usable. Queue hops SMs in front of non-SMs. Pre-connect kicking which could be tied with a message to non-SMs asking one to leave or kick in x seconds. If they built in communication from server to clients in the queue, MOTD w/rules and such could be passed to people in the queue.

                  That is but one example. Now imagine what could be done if developers tackled other areas in a similar fashion but left them equally open to scripting? As I said, I understand where you're coming from and definitely understand the love of scripting (I'm a ex-Perl, current Python hacker myself). So I'm not saying that those capabilities disappear. Just that the base toolbox upon which those scripts are built be expanded to cover the current needs of the community.

                  A game with bad voip to start is pretty lazy though it's not the standard but given a choice during their timeline of making the product, it's definitely on the lower end of priority. That could change for sure. The games in the 90's never had online voice though.
                  In the 90s? Weeeeelllll, technically, they did. Roger Wilco, the first VOIP software aimed at gamers that I recall, was created in 1999. Microsoft's Sidewinder Game Voice (I just tossed my non-functional Game Voice pad yesterday) was released in 2000. So while it is true that 2 of the first 3 games in the first generation pre-date gamer related VOIP it is not true of all three as UT was released the same year as Roger Wilco. However I did explicitly give that first crop of FPSes a pass from the issues I raised in my post.

                  However, it is certainly true that the next generation of FPSes, the ones for which my post is targeted, did grow up in the era of VOIP.
                  "...the rules aren't there to enumerate what is always correct but what is always wrong..."

                  Comment


                  • #10
                    Re: Why Are Networked FPS Games So Stagnate?

                    The queuing is a definately a good thing to have but i'm not sure why developers haven't persued it. You look at the plethora of network innovations they have done and there must be a reason they haven't done it. It's possible the security plays a role in that too.


                    - -

                    Comment


                    • #11
                      Re: Why Are Networked FPS Games So Stagnate?

                      Remember that Marathon had voice, albeit, not the best quality in the world.
                      |TG-6th|SirNerd

                      My Resume includes Pirate, Mercenary, and a Devil Dog, what else do you want.

                      Pain is Inevitable, Suffering is Optional.

                      When you can't run anymore, you crawl and when you can't do that, you find someone to carry you.

                      Comment


                      • #12
                        Re: Why Are Networked FPS Games So Stagnate?

                        What is the up most importance of a literal queue vs an apparent one for the players? Does standing in line for a spot really make a huge difference vs a 'race to join' when a spot is available?

                        For the game companies, a queue is extra effort over simply allowing someone to join when a spot is available. As the usual problem for adding players to a server is that the joining players or admins would need to take a slot because they get the same data exchange as a player to be able to see the game (only a little less for their lack of interaction), so if BF2 added two admin spots for an admin to go into the game and view how things are going it would still take up two of the available slots. The reason that at least one slot is required to be open for a player to join is that the server knows it can only handle so many connections, so it refuses the connection prior to someone joining.

                        So to establish a queue in a normal stand alone game, the game would need to handle the additional connections of the players that are in the queue (so there would likely be an effective limit, even if it isn't zero). If there were in game admin slots there would need to be additional player connections for those slots. This could be done by allowing the servers to set the number of players vs admin/reserve spots but that would work exactly the same as it does now. The only difference is a literal queue which I only see limited use for if the server can handle so many connections to start with.

                        Now the admin tools I agree with, and I think that several newer games have shown that game companies don't care at all about communities and admin abilities. How many of the BF2 vanilla servers have admins vs just being there for people to join. BC2 doesn't even have a console. Game companies have found that people aren't demanding these features so they are simply not putting forth the extra effort to put them in.

                        Could they do so and have a best selling game? Sure, but it just isn't a priority. Most people just want to join random server and have some fun, a well established community or TG type game play is the in the minority and not because of the lack of admin tools.
                        |TG-6th|Snooggums

                        Just because everyone does something does not mean that it is right to do.

                        Comment


                        • #13
                          Re: Why Are Networked FPS Games So Stagnate?

                          Originally posted by snooggums View Post
                          What is the up most importance of a literal queue vs an apparent one for the players? Does standing in line for a spot really make a huge difference vs a 'race to join' when a spot is available?
                          When a spot is available? No.

                          So to establish a queue in a normal stand alone game, the game would need to handle the additional connections of the players that are in the queue (so there would likely be an effective limit, even if it isn't zero). If there were in game admin slots there would need to be additional player connections for those slots. This could be done by allowing the servers to set the number of players vs admin/reserve spots but that would work exactly the same as it does now. The only difference is a literal queue which I only see limited use for if the server can handle so many connections to start with.
                          This is incorrect as it is based on a flawed premise. You are presuming that all connections are equal. This is demonstratively untrue. Open up your server browser, select favorites and hit refresh. You've just connected to every server on the list and obtained data from that server. If you open "server information" you'll get a list of players, their ping times, and so on. In fact on TF2 you get a list of players, their scores, how long they have been connected.

                          Presently these connections are built up and then discarded. There is nothing that says they have to be discarded. They are a simple, text only, communication with, in fact, limited flow control. They are pretty much as simple a connection as you can get. This is not a full playing slot which involves the full protocol of the game as well as an object in the game space. The overhead to maintain these connections is minuscule.

                          All it would take to build a queue at this level is to get the player's unique ID (In Steam it is their Steam ID, other games have their own unique identifiers; any SM is familiar with that concept) and leave that connection open so that the server can communicate back to the client. It is across this low-level connection that the queue is implemented. Instead of connecting and getting the server info like we do currently they can get the player's unique ID. Have the client implement 3 commands on its side; display message, enter game and close connection. Display message can give status updates on the player's position in the queue as well as allow messages, like server rules, to be passed to the player while they wait. Enter game is to tell the client to build up a full connection and enter the game proper (IE, done with the queue) and close connection to force the client out of the queue for whatever reason.

                          Once the players unique ID is obtained at that level, pre-full-slot connection there is no need to maintain admin slots or reserve slots for subscribing members. I am envisioning the logic behind this interface to be scriptable so once the unique ID is obtained it can be matched against lists of admins and supporting members. Admins get a slot ASAP; supporting members jump to the head of the queue and/or someone in the game gets kicked based on the logic each community wishes to implement.

                          Of course 1/2 of the previous paragraph is a non-issue. Remember, I also feel that admins should get their own non-interactive slot as a matter of rote outside the general playing slots. Like HLTV does for non-admin spectators.

                          Now the admin tools I agree with, and I think that several newer games have shown that game companies don't care at all about communities and admin abilities. Could they do so and have a best selling game? Sure, but it just isn't a priority. Most people just want to join random server and have some fun, a well established community or TG type game play is the in the minority and not because of the lack of admin tools.
                          Granted. But it is the established communities which drive the games' popularity. Communities like TG might represent 1-5% of the server population but in terms of playing hours I wouldn't be surprised if they represented 25% or more of the total hours put into the game.
                          "...the rules aren't there to enumerate what is always correct but what is always wrong..."

                          Comment


                          • #14
                            Re: Why Are Networked FPS Games So Stagnate?

                            I really don't think most players care tbh grey. It's probably not a big deal because of that reason. Companies do survey's to try to find out these things. I'd say that players having perfect hit tracking is the most important which is where many mp fps games get their work done in the network code.


                            - -

                            Comment


                            • #15
                              Re: Why Are Networked FPS Games So Stagnate?

                              I've never seen the admin side of the tools so I don't know how good/bad they are. I've heard the occasional admin mention they wished the admin tools could do x or y, because in one or two instances it would have been helpful. I also don't play on a lot of different servers so I don't know about other gaming servers with admins, but with the exception of 1 or 2 that probably come close, I can't imagine another community with so many unbiased admins monitoring the server as often as TG does. So I wonder how many other communities/clans care about features beyond kick/ban. Punkbuster isn't perfect, but they dedicate all of their resources to finding new hacking programs, screen shotting capabilities, if each developer did this, how could they dedicate the time and resources to do this? I don't see it as feesible.

                              You brought up TG and our rule set and not being able to identify someone breaking the rules because of not seeing their name, but I don't see how any of your suggestions would help this. Now 2142 had battle recorder running for a lot of the time, when issues were brought up it was easy to go back and look at the files to watch people, if it only had a rewind button....*SIGH* I think you're trying to get at something similiar with the admin live view feature, but unless there is an admin watching this all the time, and happened to see what happened, how would this be beneficial. Maybe I'm missing something.

                              Queue managmenet: I don't know many people that will wait for a download from a server with a queue, let alone a game that has thousands of open servers. I know a few people at TG that only get a few hours a week to play, including me. If my favorite server had a queue, I'd instantly move on to another server, I can't imagine many people waiting on a server.

                              Vulcan mentioned the admin tools for source and how well they work, to me it looks like you're dismissing this point, by saying that when it first started the source admin tools were lackluster, only later when code was written did they become good, but (barring a live view and queue) isn't that what the point of the post was, that the admin tools hadn't changed or weren't improving?
                              Big-eye101: "A true catman post a day keeps the bad mood away"

                              Please do not take any posts made by Catman seriously. If you begin to take his posts seriously, please seek psychiatric attention.

                              Comment

                              Connect

                              Collapse

                              TeamSpeak 3 Server

                              Collapse

                              Advertisement

                              Collapse

                              Twitter Feed

                              Collapse

                              Working...
                              X