Bungie , I hope your wives don't breed stupid children that carry on your legacy. Hopefully, one of your children will smack you in your face and make the light bulb go on.

Is it possible to read this in plain English language with a list of changes, as it appears nothing has been mentioned. It seems BUNGIE want us to play destiny for as long as possible by every delay possible to join a game as an example. I could go on but fellow gamers here have said it all quite passionately. It's time to listen and absorbe not go on a single crusade based on what BUNGIE think should be the way forward! The crusible is broken it's as simple as that!

Here's a thought, Bungie. If you're able to make 1 specific playlist different from others then implement that playlist back to connection based match making and take feedback from the community. Wouldn't it be nice to get positive feedback for a change?

Why ask for feed back when you don't even listen? These matchmaking settings received a lot of negative feedback in July and what do you do? You go apply them to more play lists? Not having fun in crucible. Even more lag now, sweaty matches, playing against more parties and joining more matches in progress, un even teams. The crucible is a mess now.

Feedback - the roster still looks like a christmas tree , all green and yellow and red lights. Laggy matches. I've given up inside, i still play and laughs when i can't kill anyone and cries sometimes when i spawn into ongoing games. But mostly i want to slit my wrists when Bungie descides to put me into matches all to sweaty and extremly laggy because i've happened to win my 2 previous matches.

Just played some games in crusible: 1 game I like sometimes play with 2 snipers, nlb and 1000 yard. But in this game it was impossible, I did headshot with nlb, I saw yellow nubmers under head of my enemy ( It must be one shot kill) and do u know what bungie? Nothing, my enemy stay alive... 2 game Two red bar warriors in enemy team that teleporting and did get any gmg and of course, they are was on top... 3 game Four red bar warriors and one in my team... So bungie I dont like masochism kind of bdsm, becouse this system working in crusible not sbmm or cbmm its really some kind of masochism.

Not much of a coder (so anyone's experience is welcome) but cozmo, show this to your engineers that write your netcode. Question about netcode and answer: [spoiler] I'm interested in evaluating the different ways that the netcode can "hook into" a game engine. I am designing a multiplayer game now, and so far I have determined that I need to (at the very least) have a separate thread to handle the network sockets, distinct from the rest of the engine which handles the graphics loop and scripting. I did have one potential way to make a networked game entirely single-threaded, which is to have it check the network after rendering each frame, using non-blocking sockets. However this is clearly not optimal because the time it takes to render a frame is added to the network lag: Messages arriving over the network must wait until the current frame render (and game logic) completes. But, at least this way the gameplay would still remain smooth, more or less. Having a separate thread for networking allows the game to be completely responsive to the network, for instance it can send back an ACK packet instantly upon receipt of a state update from the server. But I'm a little confused about the best way to communicate between the game code and the network code. The networking thread will push the received packet to a queue, and the game thread will read from the queue at the appropriate time during its loop, so we haven't gotten rid of this up-to-one-frame delay. Also, it seems like I would want the thread which handles the sending of packets to be separate from the one that is checking for packets coming down the pipe, because it wouldn't be able to send one off while it is in the middle of checking if there are incoming messages. I am thinking about the functionality of select or similar. I guess my question is, what's the best way to design the game for the best network responsiveness? Clearly the client should send user input as soon as possible to the server, so I could have net-send code come immediately after the event processing loop, both inside of the game loop. Does this make any sense? answer: Ignore responsiveness. On a LAN, ping is insignificant. On the internet, 60-100ms round-trip is a blessing. Pray to the lag gods that you don't get spikes of > 3K. Your software would have to run at very low number of updates/sec for this to be a problem. If you shoot for 25 updates/sec, then you've got 40ms max time between when you receive a packet and act on it. And that is the single-threaded case... Design your system for flexibility and correctness. Here is my idea on how to hook a network subsystem into game code: Messaging. The solution to a lot of problems can be "messaging". I think messaging cured cancer in lab rats once. Messaging saves me $200 or more on my car insurance. But seriously, messaging is probably the best way to attach any subsystem to game code while still maintaining two independent subsystems. Use messaging for any communication between the network subsystem and game engine, and for that matter between any two subsystems. Inter-subsystem messaging can be a simple as a blob of data passed by pointer using std::list. Simply have an outgoing messages queue and a reference to the game engine in the network subsystem. The game can dump messages it wants sent into the outgoing queue and have them automagically sent, or perhaps when some function like "flushMessages()" is called. If the game engine had one large, shared message queue, then all subsystems that needed to send messages (logic, AI, physics, network, etc.) can all dump messages into it where the main game loop can then read all of the messages and then act accordingly. I would say that running the sockets on another thread is fine, though not required. The only problem with this design is that it is generally asynchronous (you don't know precisely when the packets are being sent) and that can make it hard to debug and making timing related issues appear/disappear randomly. Still, if done properly, neither of these should be a problem. From a higher level, I'd say separate networking from the game engine itself. The game engine doesn't care about sockets or buffers, it cares about events. Events are things such as "Player X fired a shot" "An explosion at game T happened". These can be interpreted by the game engine directly. Where they are generated from (a script, a client's action, an AI player, etc) doesn't matter. If you treat your network subsystem as a means of sending/receiving events, then you get a number of advantages over just calling recv() on a socket. You could optimize bandwidth, for example, by taking 50 small messages (1-32 bytes in length) and have the network subsystem package them into one large packet and send it. Maybe it could compress them before sending if that was a big deal. On the other end, the code could uncompress/unpackage the large packet into 50 discrete events again for the game engine to read. This can all happen transparently. Other cool things include single player game mode that reuses your network code by having a pure client + a pure server running on the same machine communicating via messaging in shared memory space. Then, if your single player game operates properly, a remote client (i.e. true multiplayer) would operate as well. Additionally, it forces you to consider ahead of time what data is needed by the client since your single player game would either look right or be totally wrong. Mix and match, run a server AND be a client in a multiplayer game -- it all works just as easily. [/spoiler] Blizzard talking about their netcode & the reddit link [spoiler] https://youtu.be/vTH2ZPgYujQ https://m.reddit.com/r/gamedev/comments/4dl4cx/lets_talk_netcode_overwatch_real_good_netcode/ [/spoiler] Rollback [spoiler] http://m.neogaf.com/showthread.php?t=770573 [/spoiler] [spoiler] https://m.reddit.com/r/gamedev/comments/1toutc/what_makes_mmo_networking_code_so_difficult/[/spoiler] Latency sucks. everyone experiences it, it makes games (in general) no fun. Im sure 0.001% of us could actually do what bungie does with the netcode. Its probably hard as shit to solve problems, especially with internet connection. May argueably be the hardest problems to solve. Ofcourse dedicated servers help a ton, but other things help too.

In what formula on cthulhus green earth am I supposed to be paired up with -blam!-ing streamers every 8th match in trials?!?

Matchmaking for Trials should be changed seeing how the only players who actualy seem to go flawless are the competive pvp players.

It seems inconsistent. I have not been having fun, crucible-wise, for a while now.

Yeah this is stupid. I'm bowing out until you guys get this game fixed. Crucible is straight funked up. I don't know what y'all did, but it was a massive step in the wrong direction.

I love the red bar warriors that takes a full clip to kill but yet when I'm red barring which is rarely I can't kill a single sum bi%@h.. I don't get it

I played a lot of the weekend. No doubt, MM is still largely based on skill. Most matches very very sweaty. There are still games with red bars teleporting/taking delayed damage and leading the scoreboard. I've noticed very inconsistent aim assist and damage numbers even on green bars. Also, I'm noticing a horrible sound when certain red/yellow bar players take damage.

How come it seems like every time I turn around there's more matchmaking changes, yet nothing seems to change much besides the salt levels of this community lol

Crucible is ruined again

Hey cozmo. I just had quick question. It says that on your second character, you did the nightfall. Yet, the characters light level is 140. How did it let you do it in the first place?