Queues II: Electric Boogaloo

Lead: Hey, so I came up with a scheme to add packets to the queue every frame but the queue is getting full!

Me: So... what's the issue here exactly?

Lead: Why is the queue getting full if I'm adding only one packet a frame? It sends a packet every frame!

Me: Packet loss?

Lead: [Doesn't get it]

Me: So if there's packet loss, it won't get an ack and it'll try to resend the packet. If there is a lot of packet loss, the queue will be full.

Lead: So I should put a cooldown on adding packets to the queue?

Me: No, that would only defer the problem.

Lead: Why?

Me: ... Why don't you just add the additional packets after the messages are acknowledged and you know the queue is no longer full?

Lead: Won't a cooldown be better?

Brain.Queue.IsFull() == true

Lead: Hey, do we have two queues for sent and received messages?

Me: No, we only have one for sent messages. Because of the hardware, we can only receive one message a time.

Lead: So we have 2 queues?

Me: No, just one. For sending.

Lead: So wait a second... what do we do for receiving?

Me: We receive a packet and process it and then it goes away?

Lead: What about sending?

Me: There's a queue.

Lead: So... we DO have 2 queues?

Why you should never play video games

Boss: Man what's this {famous game} that everyone keeps comparing our game to?

Me: It's pretty popular; maybe you should play it to see why they say what they're saying.

Boss: No, we shouldn't play that because then any ideas we may have will always be re-examined to see that they're not too similar to that game's ideas.

Me: ... so I should stop playing games then?

Do authors not read books? Do filmmakers not watch other movies? If you cannot draw the line between inspiration and plagiarism, rest assured that someone in the media will let you know when you cross it.

A Comment on Thinking

Lead: Hey I think I found a bug.

Me: Okay.

Lead: Can you look at line 4029?

Me: Uh, what file?

Lead: Oh yeah, {file}.cpp.

Me: Alright...?

Lead: It looks like you want to call FunctionX() instead of FunctionY() even though the comment above it says that you intend to call FunctionY().

Me: Well, as the comment says, I do intend to call FunctionY() and not FunctionX(). I didn't make a typo twice.

Lead: Oh, really? Uh, okay.

A Division of Brainpower

Lead: I cut the size of the network packet and now the game doesn't seem to work.

Me: Let me see. Oh, yeah, here it is. You're probably running out of packets we've allocated in the queue. You need more of them.

Lead: Why would we run out?

Me: ... because you changed the packet size and now they're smaller?

Lead: If they're smaller, aren't we reducing the data size?

Me: ... nooo, because the amount of data you're sending is the same, but the capacity of the packets is less. So you need more packets.

Silence.

Lead: Ohhhh, I see what you're doing.

What was I doing? Was it "division"?

Reducing Brain Size

What if we used conditional goto's to reduce our code size?

OMG hax!

Looks like we used to use a m_Data array to store data... now we're writing over m_Data itself

Wait, what? m_Data stores data!? And... whatever the second part of that quote is all about...

ToggleBrain()

Lead programmer indicates a function in the code.

Lead Programmer: This function is calling Toggle() which is hiding our text.

Me: Yep.

Lead Programmer: The debug menu is not showing up anymore because of this.

Me: This function is only called when you choose to connect online. How did you get this problem to happen? Were you trying to go online?

Lead Programmer: No, I wasn't going online. I didn't say that I saw the problem when the code got there.

Me: So... why is this code the reason behind your problems?

Lead Programmer: I... just thought... you were... toggling... something...

Lead programmer walks away.

Probabilities

While discussing the game's rarity system:

Designer: So the game will feature 12 different objects that appear at random based on set probabilities.

Lead Programmer: Do you think we should keep track the number of times we've seen each of those objects?

Me: Why?

Lead Programmer: So you can know which object to spawn.

Me: ... well there are probabilities in the tuning...

Designer: Yeah.

Lead Programmer: But if there's a 1% chance that something will show up, you may never see it!

Me: ... yeah. That's how probability works. It's independent of the last time you did something. What would the point of different levels of rarity be if you just weighted unseen objects more heavily?

Silence.

Me: You do realize that if you flip a coin 50 times and get heads each time, it doesn't mean that you're more likely to get a particular result the NEXT time, right?

Silence.

It looks kinda obvious to me now

Oh, I see what you're saying! Start() will call Finish(). It looks kinda obvious to me now.

On repetition

While explaining packed animation data:

Programmer: If, in an animation, all the upper nibbles have the same value, it's a 16 color animation. If not, it's a 256 color one.

2 minutes later

Lead Programmer: I guess you could check whether the upper nibbles are identical.

A facade of programmer knowledge

What if we used a facade of virtual functions to solve this?