Jump to content

GT Phantom

Member
  • Content Count

    10
  • Joined

  • Last visited

    Never
  • Medals

Community Reputation

0 Neutral

About GT Phantom

  • Rank
    Private
  1. GT Phantom

    State of OFP...

    Thank you, whisperFFW06, for your excellant description of how mult-player works in OFP. Now, let's look at this from a slightly different perspective. Â I am a serious gamer and over 40. Â Golden Triad is currently #1 in the OFP League - and many members are older than I am. Â At 1 million copies sold (plus additional addons, etc.) times (I'll guess $10 as Codemasters' "cut" of the purchase price) we have a pretty good indication, in dollars, that people are primarily happy with this game. Â This also means that there is probably SOME money available to enhance the game, either as is or as a re-release (more revenue). Â I know that no company can survive providing indefinite support and enhancement after product release. Â Speaking for myself and (if I may) many other serious on-line gamers, I believe that many of us (with real lives) would pitch in for a re-release that contained this improvement. I understand your quandry in developing - I too manage a multi-million dollar development staff, and there are always some hard decisions to be made in the features to be added, tradeoffs in stability (it's a little broke, but people can live with that more than they can WITHOUT x new feature). So, looking at it as a business, the single biggest complaint I hear (after the "just getting the game started" problem, which I know you are working on) is not so much that people want to start mid-game as that they would like to be able to re-connect to a game in progress if (this is reality, now) they get unavoidably disconnected. Â After 20 minutes marshalling the players & getting started, NO ONE is ever happy missing out on 50 minutes of a 1 1/2 hour match! Â Without looking at your code (which, by the way, I would be happy to have the opportunity to do) but just by your description of "how it works," I am led to believe that it WOULD be possible to synchronize game state EVEN WITH COMPLEX SCRIPTS. Â The way to do this, of course, is to implement a game journal on the server just like Oracle databases create activity journals in case of a server failure - go back to the last backup (in this case, the basic mission file) and then apply the journals. Â At game start, all players would be registerd into the game server by their CD key / game name. Â In essence, if someone re-connects (and, by the way, I too think that gameplay would be diminished if non-starters were allowed to enter mid-game) an asynchronous thread on the server would connect to the client and start running the re-connected player in fast-forward. Â PLEASE make it an asynchronous thread - so it will not kill the game performance of those already connected! Â Only world-state would need to be updated; the very last task would be to update unit positions. Â Player "arrival" would occur as an "insertion/respawn." Â This is all existing code. Â On the client side, receiving the "game journal" would be just like running a testing application script (without the graphical portion being invoked) - the synchronizer robot would trigger each script event just as if the player had been attached in-game, in sequence, thus assuring that all scripting variables were fully synchronized. Yes, this is still a significant chunk of work. Â However, I believe that a good business case can be made for incorporating this into the networking re-write that you have already undertaken. Again, I still think you guys have done a fantastic job so far, and this is the most kick-ass game going!
  2. Spectating as an option would be nice, but should never be allowed automatically. In competition matches, many groups use 3rd party software to communicate (BattleCom; RogerWilco, etc.). Spectating would allow an unfair advantage in intelligence. Also, spectating puts an additional load on the server which could adversely affect the contestants.
  3. GT Phantom

    Multi-player Connectivity and Performance

    Ah, the forum is back up! One thing I didn't see in y'all's posts: with the new multi-player code, are you already planning on allowing mid-match rejoin?
  4. GT Phantom

    BIS' Recommendation for SoundCard

    I have an Audigy, run on Win2k, and am very pleased with it. I have all accelleration on but turn OFF the "Special Effects" in the SoundBlaster Creative Taskbar. I don't know if that means that EAX is actually disabled, perhaps just no special bells and whistles. In any event, I DO hear footsteps and, closer in, breathing. Some people call this a bug or a cheat - it's a mixed blessing. In large games you can get overwhelmed by the number of sounds and can't tell distance, but overall I think it is good to hear SOME clue to the enemy's position since visual cues are not always as good as real life. I can locate direction (with headphones on) to within about +- 3 degrees.
  5. GT Phantom

    Multi-player Connectivity and Performance

    DarkJedi, Thanks for joining the discussion. I think if they were to consider a feature like that then they should also make the option mission-selectable. For instance, in many competition matches teams use a 3rd-party voice program (to distribute the server loads). If a team member killed in a no-spawn game (or simply not included in a match to begin with) were to exit then rejoin as a bird, then they would become an extremely effective spy changing the outcome of the match. I think that many people would be upset in those circumstances.
  6. GT Phantom

    Multi-player Connectivity and Performance

    Suma, Sorry for addressing that last post to PitViper - I see now he was quoting you!
  7. GT Phantom

    Multi-player Connectivity and Performance

    PitViper, Thanks for joining the conversation! Â The news that you are already working on improved multiplayer performance is terriffic! Â I did not start this post because of a specific "problem" with my server (although I HAD hoped my server would be able to support larger matches!) - my HOPE for this post is that CodeMasters will address several issues which will enhance overall multiplayer performance and playability (see detailed list, first entry in this thread). Â Primarily I would like to see improvements in people's ability to connect and stay connected (which it looks like is already being addressed); Â enhance the program to permit re-connection during a match; and increase the total number of players which a server can reasonably support in one match (currently most people agree that the game becomes unsatisfactory and drop rate increases when over 20 people are in the same match, even on a powerful server). Â My long-winded dissertation on HOW to do all that was just a suggestion. Â Once again, I LOVE Â Â this game and it is far and away better than other multiplayer games of it's genre. Â Keep it up, guys!
  8. GT Phantom

    Multi-player Connectivity and Performance

    Suma, Thanks for responding! Â Yeah, I had guessed that the program was running single-threaded - hence my suggestion to thread out some of the sub-processes. Â I understand the problem (I manage a Java shop): Â you all did not probably set out to allow asynchronous threads in your archetecture (harder to code; uses more memory; adds overhead and slows single-player game for users with slower machines), and adding it now would be problematic. Â If I could chat with you and / or your fellows perhaps we could devise a simple strategy which would not require a lot of recoding but would make the SERVER much more scalable. Â My frontline web app has to handle 10,000+ simultaneous users with realtime database updates, so I understand the problems facing you (especially the ugly Budget Monster!!! Â ). In answer to your specific questions: - We run EVERY mission! Â And, we use lots of Add-Ons. - Server Framerate as reported by #monitor rarely drops below 15 unless there are one or more particularly bad connections or when we have 20+ players connected. - We are not memory bound: Â I rarely see > 256MB of RAM used by app (until the memory leak sets in - but that's a separate issue...) - We are not bandwidth limited. My basic thought is this (and I'm guessing here, so don't slam me too hard if I'm off base): Â the server performs several functions, among which are arbitration and connection communication. Â Now, you (Codemasters) chose not to allow UDP; commendable for reliability and trying to be "fair" to all parties, but reduces the game to the "least common denominator" of slowest connected user. Â I also suspect that each connection is processed sequentially, which is why the Red Square comes on for everyone when one machine is not responding in a timely manner. What I might propose would to make each connection an asynchronous object with communication functions between the server (arbiter) and client. Â The benefit here woud be threefold: Â A) Â The arbiter function would have much less to do, so a much larger game could be processed by the same CPU; Â B) Â If done with native threads (I also presume you used C++), XP or 2000 should be smart enough to load balance the separate threads across all CPU's (thus gaining cheap scalability); Â C) Â Â The clientConnection class could have limited smarts - it could do a quick stress test on connection for client ping and bandwidth - and might intentionally drop or average frame information to a particular connection based both on server and client available bandwidth. Â An asynchronous connection would not bring the game to a halt for everyone while waiting for a slowpoke to "catch up." Each clientConnection class would be persistent for the duration of a match, thus allowing the object to negotiate reconnection with the original player mid-match in the event of a dropped connection. Â In the event of a disconnect, an instance of playerAI could be seamlessly substituted for the connection to the player; on re-connect (if the mission allows) the process could be reversed. Â For fairness to players with slower connections, "hits" might be recorded based on the client "view of the world" at time of impact (i.e. if it "looks" like you hit it, then you did). Anyway, that's all based on speculation about how you architected the server and the bottom line is I LOVE THIS GAME! - and want to see huge 50v50 matches! Â I have antied up a good server, and I would be willing to bet that (without compromising the integrety of proprietary portions of the game engine) Codemasters could EASILY solicit some help from the gaming community to reconstruct one small area of the codebase if it would improve the online experience! Thanks for taking the time to read all this!
  9. GT Phantom

    Multi-player Connectivity and Performance

    On 10 Feb. RN Nalboeuf said: "if your having problems it sounds like your servers are just not up to the task this game requires higher end servers over 1 ghz" Hmmm, Mal, are you one of Codemaster's guys? Either you didn't bother to read my post, or you are trying to draw attention away from the problems. So let's clear this up. Server Specs: Motherboard - Tyan Thunder K7 dual Athalon MP -- latest bios -- latest drivers -- 1GB Registered ECC DDR RAM -- 2x MP 1600+ Athalon processors -- Volcano cooling fans - temp never goes above 110F Windows XP Professional -- All critical updates -- No unnecessary services -- Basic TCP/IP Only Radeon 8500 AGP -- latest drivers, but shouldn't matter since server is non-graphic 3Com 9xx NIC -- Latest drivers -- attached to T-1 with no other load during gaming times -- latency to Denmark about 50ms -- latency to New York about 40ms -- located in Atlanta Now, since we've ruled out lack of horsepower, here are some log results: -- Bandwidth used NEVER exceeds 20% T-1 capacity -- never goes above 53% CPU, even if the process priority is set to "Realtime" If anyone out there has some USEFUL feedback, PLEASE resopnd!!! Otherwise, I would REALLY appreciate it if Codemasters would consider these issues.
  10. Dear Folks at Codemasters, I, Bill Reister aka Phantom, am a member of "Golden Triad", an online group dedicated to both competitive and recreational multi-player gaming and currently ranked #1 in our competition league. We represent a significant number of purchasers of your game, and would like to request a few specific enhancements to the dedicated server which would both enhance our multi-user gaming experience while providing you great appreciation and loyalty from your customer base. CONNECTIVITY, COMPETITION & PERFORMANCE: Oftentimes our players have difficulty connecting or get disconnected before or during gameplay even if they have stable machines and good connections to the internet. We would like your help with the following: 1) Publish (not "refer to user groups") a specific set of recommendations for your users to help insure the maximum likelyhood of obtaining / retaining a connection to the server. 2) Publish (not "refer to user groups") a specific set of recommendations for server setup to help insure the maximum likelyhood of obtaining / retaining a connections with players. 3) Enhance your code (perhaps using multi-threaded / asynchronous processing?) so that if a player is having difficulty connecting / remaining connected that that does not cause performance degradation amoung the remaining players (i.e. everyone gets the Red Square). 4) Enhance your code so that if a player with the SAME NAME and SAME LICENSE OR PLAYER ID loses connection during a match that they might re-connect to the server during the same match, subject to limitations described below. 5) Enhance your code so that match reconnection parameters may be set/specified at the server / mission level. Some possibilities that come to mind are: A) If a player disconnects, the avatar is ... - replaced by AI (current default) - removed - frozen in place "invulnerable" - frozen but vulnerable - won't respawn if killed - frozen and teleported to the respawn area B) ...within the playing field until / unless the player reconnects, at which point the player will - reconnection may be disabled (current default) - reactivate in original position - reactivate, reappearing teleported a random distance / direction from original position - respawn - be allowed to observe the remaining game as a "bird" 6) Enhance your code so that the full power of multi-processor servers is harnessed (or provide instructions as to how to accomplish this - our dual XP 1600+ server running Windows XP never goes above 53% CPU, even if the process priority is set to "Realtime") 7) Enhance your server code so that the final scorecard may be automatically saved to disk (in case the final screen is closed too quickly - people are currently relying on "screen shots" of the scoreboard, which also fails if there are too many players for one "screen") 8) Provide instructions to run the dedicated server as a service while writing the screen log to a file. We thank you for the tremendous job you have done so far at creating an excellant game! Bill Reister Golden Triad
×