Peeker’s advantage is the edge a moving player (P) gains when swinging into line of sight against a holding player (H). It exists in all server-authoritative shooters due to latency. A common claim is that peeker’s advantage depends only on the holder’s connection [1]. That is correct only if the peeker’s latency is uniform. If the peeker’s uplink differs between “peek” and “shot,” the advantage grows.

Mettler, Tang, and Chen [2] provided more detailed explanation of Peeker’s Advantage in symmetrical network conditions.

Setup

One server S, two clients:

• Holder H: uplink uₕ, downlink dₕ, round-trip time Lₕ = uₕ + dₕ.
• Peeker P: uplink while revealing Lps (“peek packet”), uplink while firing Lpa (“shot packet”).

Both have the same human reaction time R. The server resolves hits. First valid shot at the server decides the duel.

Peeker's Advantage

t1 => P swings into sight.

t2 => P’s reveal reaches S afterLps and reaches H after Lps + dₕ. H first sees P at this moment.

t3 => H reacts forR. H’s shot then travels uplink uₕ. So H’s shot arrives at server at

  tH = Lps + dₕ + R + uₕ.

t4 => P sees H instantly at swing time. P reacts for R. P’s shot travels uplink Lpa. So P’s shot arrives at server at

  tP = R + Lpa.

Peeker’s Advantage Formula

Define the advantage D as the time gap between H’s and P’s first shots arriving at the server:

  D = tH – tP.

Case 1. Uniform Peeker Latency

If peek and shot uplinks are equal (Lps = Lpa):

  D = (Lps + dₕ + R + uₕ) – (R + Lps)

  = uₕ + dₕ

  = Lₕ.

So with uniform latency, the advantage equals the holder’s round-trip. This is the source of the saying “only your ping matters.”

Case 2. Asymmetrical Peeker Uplink

If peeker’s uplink while revealing is higher than while firing, define the delta

  Lpd = Lps – Lpa > 0.

Plugging in:

  D = (uₕ + dₕ) + (Lps – Lpa)

  = Lₕ + Lpd.

Result

• Uniform peeker latency: advantage = Lₕ.
• Asymmetrical uplink (Lps > Lpa): advantage = Lₕ + Lpd.

In words: the peeker gains not only the holder’s round-trip but also the extra head start equal to the difference between peek uplink and shot uplink.

Next Steps

• Empirical validation/simulation
• We examined Lps – Lpa > 0 grows peeker's advantage. Naturally Lps + Lpa > 0 shrink peeker's advantage. How about that! Maybe peeker's advantage does have a solution after all (with serious tradeoff ofc).
• People has been using network throttle to cheat for ages, maybe it's time for intelligent network throttle. Maybe they already exist.
• How to mitigate and defend against such cheat.

References

[1] M. deWet and D. Straily, “Peeking into VALORANT’s netcode,” Riot Games Technology, Jul. 28, 2020. [Online]. Available: https://technology.riotgames.com/news/peeking-valorants-netcode

[2] C. Mettler, D. Tang, and Z. Chen, A study on the effects of network latency on peeker’s advantage in FPS games, Interactive Qualifying Project Report, Worcester Polytechnic Institute, 2023. [Online]. Available: https://web.cs.wpi.edu/~claypool/iqp/fps-lag-22/final-report.pdf

Citing This

@article{chen2025peeker,
  title   = {Peeker’s Advantage in Asymmetrical Network Latency},
  author  = {Chen, Yuhao and Yang, Tianchi},
  year    = {2025}
}

Thankfully, I still have the drafts for all published posts on yuhao.app/blog, and I’ll be manually restoring them over the coming days.

I sincerely apologize for this oversight and appreciate your patience as I work to bring everything back online.

References in C++

int        // a normal int type (not an reference)
int&       // an lvalue reference to an int object
const int& // a constant lvalue reference

Both T& ref and T &ref are valid ways to define a reference but the first one is preferred.

int x {5};
int& ref {x};

ref = 6;
std::cout << x << '\n'; // 6

Modify a reference will modify the object it refers too

int x {5};
int& ref {x};

int y {6};
ref = y;
std::cout << x << '\n'; // 6

You can not reseat a reference

const int x {5};
// int& ref {x}; <-- this is not allowed
const int& ref {x}; // this is allowed and preferred way to reference object, unless you explicitly need to modify a value through reference.

const T& also can be init with literal (or other rvalue), for example, const int& {5} where as T& couldn’t. Note that 5, a temporary value, it's lifetime is extended by const T&

What the hell is l-value and r-value?

int x { 5 }; // 5 is an rvalue expression
int y { x }; // x is an lvalue expression
const double d{ 1.2 }; // 1.2 is an rvalue expression
const double e { d }; // d is a non-modifiable lvalue expression

1. More formal explanation:
   • Lvalue expressions evaluate to an identifiable object.
   • Rvalue expressions evaluate to a value.
2. More straightforward (to me) explanation:
   • A lvalue that stands for locate value is a variable that holds a value in memory
   • A rvalue is a variable itself and that it has no memory allocated.

Pointers in C++

Dereference operator *

#include <iostream>

int main()
{
    int x{ 5 };
    std::cout << x << '\n';  // print the value of variable x
    std::cout << &x << '\n'; // print the memory address of variable x

    std::cout << *(&x) << '\n'; // print the value at the memory address of variable x (parentheses not required, but make it easier to read)

    return 0;
}

// 5
// 0027FEA0
// 5

Pointers

A pointer can be declared via T* x, and a pointer declared but not initialized is called a wild pointer. You can initialize a pointer via T* {&x}.

Assignment in pointer

We can use assignment with pointers in two different ways:

1. *ptr = 6; To change what the pointer is pointing at (by assigning the pointer a new address)
2. ptr = &x; To change the value being pointed at (by assigning the dereferenced pointer a new value)

#include <iostream>

int main()
{
    int x{ 5 };'
    int* ptr{ &x }; // ptr initialized to point at x

    std::cout << *ptr << '\n'; // print the value at the address being pointed to (x's address)

    int y{ 6 };
    ptr = &y; // // change ptr to point at y

    std::cout << *ptr << '\n'; // print the value at the address being pointed to (y's address)

    return 0;
}

• &x return a pointer not the literal address to x
• On a 32 bit architecture, a pointer is 4 bits

Null Pointer

When you initialize a pointer like int* ptr{}, you get a null pointer.

You can also assign a pointer with ptr = nullptr to assign it with null pointer.

You **can but should avoid **initialize a nullptr with T* ptr{0}; or T* ptr{NULL};.

You can test whether a pointer is a null pointer by if (ptr == nullptr) or just if (ptr).

• Note: Testing whether a pointer is not a null pointer does not alway guarantee a pointer is safe to deference. A dangling pointer to a destroyed item does not automatically set to nullptr. Therefore it’s your responsibility to detect these cases and ensure those pointer are set to nullptr.

Pointers and const

const int x {5};
int* ptr { &x }; // compile error: cannot convert from const int*

You cannot set a normal pointer to a pointer at a const variable.

Const pointers

A const pointer Is a pointer whose address cannot be changed — T* const ptr {&x};.

You can dereference *ptr and modify the original object x given x is a non constant.

Const Const pointer to a const value

You can declare by const T* const ptr { &x }; even if T x is a non const. In this case the nether the pointer accept assignment nor dereferenced pointer accept assignment.

WTH? Here is a cheat sheet

Even simpler cheat sheet

• *ptr = ... → assigning to the pointee
• ptr = ... → reassigning the pointer itself
• ✅ = assignment allowed
• ❌ = assignment not allowed
• 🚫 = declaration is invalid (compile error)

Pass by Reference and Pass by Address

Passy by reference

void addOne(int& y) // y is bound to the actual object x
{
    ++y; // this modifies the actual object x
}

// int x{5};
// addOne(x);

#include <iostream>

void printAddresses(int val, int& ref)
{
    std::cout << "The address of the value parameter is: " << &val << '\n';
    std::cout << "The address of the reference parameter is: " << &ref << '\n';
}

int main()
{
    int x { 5 };
    std::cout << "The address of x is: " << &x << '\n';
    printAddresses(x, x);

    return 0;
}

// The address of x is: 0x7ffd16574de0
// The address of the value parameter is: 0x7ffd16574de4
// The address of the reference parameter is: 0x7ffd16574de0

T funcName(T& x) and T funcName(const T& x) follow pretty much same rule as const T& and T&, a reference to non-const (which can only bind to modifiable lvalues), a reference to const can bind to modifiable lvalues, non-modifiable lvalues, and rvalues. But value modification is not allowed for T funcName(const T& x).

Pass by Address

void addOne(int* y) // y is bound to the actual object x
{
    ++y; // this modifies the actual object x
}

int x{5};
addOne(&x);

Pass by value? By reference? And by address

• Note:
  **Prefer void foo(T* const value) over void foo(T* value). **And yes you canvoid foo(const T* const value) and void foo(const T* const value), it follows the same rule referenced in the cheat sheet.

When to use pass by value vs pass by reference

• Fundamental types and enumerated types are cheap to copy, so they are typically passed by value.
• Class types can be expensive to copy (sometimes significantly so), so they are typically passed by const reference.
  Actually got asked this question in a Tesla interview

Pass by reference vs by address

Pass by const reference has a few other advantages over pass by address.

First, because an object being passed by address must have an address, only lvalues can be passed by address (as rvalues don’t have addresses). Pass by const reference is more flexible, as it can accept lvalues and rvalues.

Second, the syntax for pass by reference is natural, as we can just pass in literals or objects. With pass by address, our code ends up littered with ampersands (&) and asterisks (*).

In modern C++, most things that can be done with pass by address are better accomplished through other methods. Follow this common maxim: “Pass by reference when you can, pass by address when you must”.

Pass by address copies the address

// Consider
void foo(int* ptr)
{
    ptr = nullptr;
}

int x{ 5};
int* ptr{ &x };
foo(x);

std::cout << "ptr is " << (ptr ? "non-null\n" : "null\n"); // ptr is non-null

Therefore reassign a passed by pointer to another address does not reassign the original pointer (because foo() copies reference).

Pass by address by reference

Instead, if you want achieve above, you can:

void bar(int*& ptr)
{
    ptr = nullptr;
}

Return by reference and address

Similar to pass by value, return by value also returns a copy of the object:

std::string returnByValue();

#include <iostream>
#include <string>

const std::string& getProgramName() // returns a const reference
{
    static const std::string s_programName { "Calculator" }; // has static duration, destroyed at end of program

    return s_programName;
}

int main()
{
    std::cout << "This program is named " << getProgramName();

    return 0;
}

// This program is named Calculator

Because getProgramName() returns a const reference, when the line return s_programName is executed, getProgramName() will return a const reference to s_programName (thus avoiding making a copy). That const reference can then be used by the caller to access the value of s_programName, which is printed.

**Using return by reference has one major caveat: the programmer must be sure that the object being referenced outlives the function returning the reference. **Otherwise, the reference being returned will be left dangling (referencing an object that has been destroyed), and use of that reference will result in undefined behavior.

const std::string& getProgramName()
{
    const std::string programName { "Calculator" }; // now a non-static local variable, destroyed when function ends

    return programName;
}

This will result in previous program undefined since programName is now destroyed at the end of the function.

Lifetime extension doesn’t work across function boundaries

#include <iostream>

const int& returnByConstReference(const int& ref)
{
    return ref;
}

int main()
{
    // case 1: direct binding
    const int& ref1 { 5 }; // extends lifetime
    std::cout << ref1 << '\n'; // okay

    // case 2: indirect binding
    const int& ref2 { returnByConstReference(5) }; // binds to dangling reference
    std::cout << ref2 << '\n'; // undefined behavior

    return 0;
}

In this case, a temporary object is created to hold value 5, which function parameter ref binds to. The function just returns this reference back to the caller, which then uses the reference to initialize ref2. Because this is not a direct binding to the temporary object (as the reference was bounced through a function), lifetime extension doesn’t apply. This leaves ref2 dangling, and its subsequent use is undefined behavior.

Don’t return non-const static local variables by reference

You are allowed to do so but will often result in unintended behavior:

#include <iostream>
#include <string>

const int& getNextId()
{
    static int s_x{ 0 }; // note: variable is non-const
    ++s_x; // generate the next id
    return s_x; // and return a reference to it
}

int main()
{
    const int& id1 { getNextId() }; // id1 is a reference
    const int& id2 { getNextId() }; // id2 is a reference

    std::cout << id1 << id2 << '\n';

    return 0;
}

Assigning/initializing a normal variable with a returned reference makes a copy

If a function returns a reference, and that reference is used to initialize or assign to a non-reference variable, the return value will be copied (as if it had been returned by value).

#include <iostream>
#include <string>

const int& getNextId()
{
    static int s_x{ 0 };
    ++s_x;
    return s_x;
}

int main()
{
    const int id1 { getNextId() }; // id1 is a normal variable now and receives a copy of the value returned by reference from getNextId()
    const int id2 { getNextId() }; // id2 is a normal variable now and receives a copy of the value returned by reference from getNextId()

    std::cout << id1 << id2 << '\n';

    return 0;
}

// 12

It’s okay to return reference parameters by reference

#include <iostream>
#include <string>

// Takes two std::string objects, returns the one that comes first alphabetically
const std::string& firstAlphabetical(const std::string& a, const std::string& b)
{
	return (a < b) ? a : b; // We can use operator< on std::string to determine which comes first alphabetically
}

int main()
{
	std::string hello { "Hello" };
	std::string world { "World" };

	std::cout << firstAlphabetical(hello, world) << '\n';

	return 0;
}

// Hello

It’s okay for an rvalue passed by const reference to be returned by const reference

When an argument for a const reference parameter is an rvalue, it’s still okay to return that parameter by const reference.
This is because rvalues are not destroyed until the end of the full expression in which they are created.

#include <iostream>
#include <string>

const std::string& foo(const std::string& s)
{
    return s;
}

std::string getHello()
{
    return "Hello"; // implicit conversion to std::string
}

int main()
{
    const std::string s{ foo(getHello()) };

    std::cout << s;

    return 0;
}

The caller can modify values through the reference

This is very confusing behavior. Hence imho, make you return const *

#include <iostream>

// takes two integers by non-const reference, and returns the greater by reference
int& max(int& x, int& y)
{
    return (x > y) ? x : y;
}

int main()
{
    int a{ 5 };
    int b{ 6 };

    max(a, b) = 7; // sets the greater of a or b to 7

    std::cout << a << b << '\n';

    return 0;
}

Return By Address

Return by address works almost identically to return by reference, except a pointer to an object is returned instead of a reference to an object. Return by address has the same primary caveat as return by reference -- the object being returned by address must outlive the scope of the function returning the address, otherwise the caller will receive a dangling pointer.

The major advantage of return by address over return by reference is that we can have the function return nullptr if there is no valid object to return. For example, let’s say we have a list of students that we want to search. If we find the student we are looking for in the list, we can return a pointer to the object representing the matching student. If we don’t find any students matching, we can return nullptr to indicate a matching student object was not found.
The major disadvantage of return by address is that the caller has to remember to do a nullptr check before dereferencing the return value, otherwise a null pointer dereference may occur and undefined behavior will result. Because of this danger, return by reference should be preferred over return by address unless the ability to return “no object” is needed.

WTH Sheet, again

const std::string& foo(const std::string& s) {
    return s;
}

In short const std::string s{ foo("Hello") }; good as it make a copy before temporary dies.

const std::string& s{ foo("Hello") }; bad because temporary will die after the full expression. The difference is & if you still couldn’t tell.

Ebay later became my Student Assistant in CTIN 534, a class taught by Peter Brinson. One day, I happened to run into him and we ended up having a long conversation. That’s when he pitched me this new game — a journey about a balloon.

The game is called Balloon. You play as a little red balloon floating through the air. You’re light, fragile, and can’t really control where you’re going—just drifting with the wind. All you can do is gently pull on the string to try and steer. The heart of the game lies in how you interact with the people you meet along the way. Like in real life, different people respond differently to hope: a kid might run toward you with joy, a tired office worker might glance up and smile, and a little girl might kick you like a soccer ball. The balloon reflects the people it passes — it’s a simple, poetic way to explore how people feel about hope itself. The whole experience plays out like a quiet, interactive poem.

When I first heard the pitch, it immediately reminded me of Flower by Jenova Chen — one of the more well-known game designers to come out of USC. Fittingly, Ebay later told me the game received a lot of mentorship and feedback from Tracy Fullerton, who mentored Jenova back in the day.

I immediately expressed interest in working on the project — but instead of taking on my usual role as an engineer, I told Ebay I was more interested in helping design the interactions. Partly because the concept really resonated with me, and partly because the engineering side was already in very good hands. The team had some incredibly talented developers, led by Shuyang — a graphics specialist and recent USC grad who also worked on Myth of Lumi.

Working with Ebay on this project taught me so much, especially because of his incredible attention to detail. He really focused on the finer points, like the exact background setting and the era of the game. We spent a lot of time finding that perfect balance between making the world relatable to a modern audience while also giving it a kind of timeless, almost nostalgic feel.

As an interaction designer, my job was to create detailed interaction design documents. These included everything from how characters look — their height, their clothing, their overall appearance — so that artists could turn those ideas into concept art and eventually 3D models. I also had to document the behaviors of each character or NPC — like what they do when they’re idle, or how they react when they see the balloon. Are they going to jump up and try to grab it? Are they going to tie a message to it and send it along to someone else? All of these details had to be described clearly so that the engineers could bring them to life in code.

But the most important part of this process was thinking about the characters’ backstories and, ultimately, their relationship to hope. Each character’s attitude toward hope shapes how they respond to the balloon, and that’s really what makes the game feel like a living, breathing poem.

But the real heroes of this project were the artists, engineers, and especially my friend Justin, who worked as the level designer. In just about a month, the artists created these incredibly detailed 3D characters with a super charming art style, full of life and personality. The engineers managed to implement a ton of features that brought the story to life, packing all these emotional highs and lows into a simple 15-minute experience. We had moments where the wind would push the balloon, characters would grab it and run off, and obstacles would pop up, all making the game feel dynamic and engaging.

Justin, our level designer, really thought through the emotional journey we wanted players to experience. He focused on how to teach players to interact with the balloon naturally, making sure they understood the mechanics and could enjoy the game fully. And I can’t forget the amazing musicians who created the score that tied everything together and gave the game its poetic heart.

Of course, none of this would have happened without Ebay, who worked tirelessly — sometimes with barely any sleep — to bring it all together. And, impressively, he managed all this while also working as a translator with me during the Seasun Games visit to USC. I’m incredibly proud of what our team created for the game jam.

Update: We ended up receive a nomination from the game jam and the team is invited to see Jenova Chen. Unfortunately, I wasn't able to meet him as I wasn't in China during the time. But here are some fun pictures from my good friend Justin Huang:

Disneyland isn’t just a theme park. It’s structured storytelling. Every object, path, and landmark is placed intentionally. David pointed out the “Weenie” — a visual magnet, like the castle, that pulls guests through space. It’s basic spatial psychology, but executed at scale.

The original park was built at a smaller scale on purpose. Doors, windows, fences—slightly undersized so children feel like they are grownups. Quite cool!

Even old rides like Snow White are built narratively. The queue introduces characters. The ride pays it off. It’s a common story structure—setup, delivery, resolution. But the ride that really demonstrates that is Rise of the Resistance in Star Wars: Galaxy's Edge. Rise of the Resistance is both a technological marvel and a storytelling masterpiece. It employs almost all narrative techniques as well as technologies available to themed entertainment industry.

Underneath Sleeping Beauty Castle is a special spot—where Walt Disney himself once stood.

Walt Disney love trains, and that's why there are so many trains in the park. He also had a model train built at the backyard of his home

You can buy a giant turkey leg in the park, and it's one of the juciest turkey I had (they usually are so dry).

Aaron Sorkin, when asked how to portray a villain characters, says

"You (the author) cannot think of them as a villain. You can't judge the character… You have to be able to empathize with that character. Find something about that character that is like you too. And you have to write that character like they're making their case to God why they should be allowed to heaven. "

There was an attack last weekend at the No King’s protest in Salt Lake City, Utah, where a bystander—fashion designer Arthur Foals An Loo—was shot and killed. The incident received little attention because, over the same weekend, a man named Vance Luther Boelter assassinated Minnesota legislator Melissa Hortman and her husband. Earlier that morning, Boelter had also shot and critically injured State Senator John Hoffman and his wife. Boelter also killed Hortman's family rescued dog Gilbert — a golden retriever, who was ‘too happy-go-lucky’ to be a service dog.

Mike Lee, a U.S. Senator from Utah, tweeted, “This is what happens. When Marxists don’t get their way,” baselessly suggesting that Boelter was a Marxist. However, as many people—including Paul Graham—have pointed out, Boelter was actually a conservative who voted for Trump in the last election.

I find it very hard to portray Senator Lee and his friends as villains.

I won't spoil anything, but one of the best moments from the experience was picking up the phone and talking to one of the characters. In a barely lit room filled with detailed props, I was truly transported to the fictional world crafted by the creators. Rest assured, though, The Nest isn't a scary experience at all; it has nothing to do with horror. Nor is it a difficult experience. Right from the start, the staffer told us the experience only has light puzzle elements that mostly serve to enhance the narrative.

But what's most intriguing to me is that its story is actually quite straightforward — no major twists or turns, no complicated plot devices. What the story truly excels at is clearly conveying a simple narrative to the player through innovative means.

As an inexperienced writer, one of my most common mistake is trying to make a story novel but ended up making it complicated. I am fortunate enough to attend writing classes of many great movie/game writers at USC. Many of them say every story is a remix of a handful of stores. What this means to me is that one should tell the simplest version of a story and let the audience fill in the gaps.

Circling back to The Nest, it's an experience designed to last around 90 minutes, with the majority of that time dedicated to players solving puzzles. I'd estimate only about 30 minutes are actually spent on storytelling. Knowing this constraint, the creators wrote a story with the simplest construct. However, by placing this straightforward narrative within a well-crafted and detailed set, the team understood that this was more than enough to truly immerse players.

When I received the news on April 7th, I had already been studying in the U.S. for nearly a decade. I first came here as a high school exchange student and attended Poston Butte High School, a public school in Arizona. I was the only Chinese student at the school, and the cultural shock was intense. Many other exchange students at different schools returned home early, but I barely managed to hang on and adapt.

That year was the first time in my life I discovered my potential. Despite the cultural differences, I found myself better suited to life in America than back home. I decided to continue my studies in the U.S. and transferred to Valley Catholic High School in Portland for the remaining two years. There, I was able to take AP classes and challenge myself academically. Switching from a large public school to a private Catholic school gave me one of the most unique perspectives on American education and culture. I was shocked by how unequal America is, especially given how wealthy the country is.

Ironically, I ended up taking almost all the required courses for a CS degree anyway. But at the time, I lived by the motto “leave no way out,” so I deliberately prevented myself from pursuing a double major. It’s hard to say in hindsight whether that choice was brave or simply naive.

UCSC’s AGPM program turned out to be an incredible experience. It was (at the time) ranked among the top 10 game design programs in the country, with outstanding faculty like Robin Hunicke and Elizabeth Swensen. In fact, when I later decided to apply to graduate school, it was Professor Swensen who encouraged me to apply to USC and kindly wrote me a recommendation letter. I remain deeply grateful to her. At UCSC I made two amazing platformers that I remain very proud of WALL-B and Fragments of You. And a slew of mediocre stub games.

Another Professor I own a lot to is Professor James E Davis. He let me joined his computer graphic research lab - AVIS - as an undergraduate research assistant. He once told me “I have a very promising career ahead of me”. That and what he’s done for me motivated me until today. I had the opportunity to lead an undergraduate student research team under him. He also sponsored me to compete twice in Apple Swift Student Challenge and won both time.

You may noticed I didn’t mention any of my high school teachers. It’s because I became pretty depressed during high school, so I ended up blocking most of my memories from around that time. Sadly, I forgotten most of their name as a result. Thank you! My 10th degree chemistry teacher, you were excellent. My French teacher — thank you for being easy on me. My 11th degree Math teacher Kipp Johnson, I actually remembered your name because how much I revered you. My English teacher, you are so warm and gentle, you are the reason why I still have a habit of reading. My World History and Government teacher, I hate that you made me memorize the name of every country on earth. And my AP CS teacher, sorry I hacked your website and stole the midterm. Last but not least I’d like to thank my host families Jennifer, Jonathan and Veronica.

After UCSC I was admitted to USC as an Interactive Media & Games Division MS student. I was supposed to come to the U.S. in Fall of 2023. But during that summer, I was diagnosed with ulcerative colitis (UC) and had an infection so bad I had to be hospitalized for three months three. I ended up missing the Fall 2023 window.

After I healed, the ensuing year almost became a year of heartbreak. I led a team to raise money from VC, we made it very far only to be excluded at the last round. I was invited to Cupertino by Apple to attend WWDC only to not being able to make it. And throughout the entire year, I was convinced I will not be able to pursue my degree at USC.

When I finally entered the U.S. on August 2024, I cried in the LAX.

When I learned the news that my SEVIS was cancelled few weeks ago, I was furious (I still am) — I have endured so many hardships in the past decade. And throughout the entire time I followed the American law. I had no arrest, no charges, and no criminal history. Only to be cancelled without any notification or reasoning.

I learned about due process and rights in America in 11th grade thanks to my government teacher. I learned the same way all American learned their right.

This year, I learned those rights doesn’t apply to me. As long as the executive branch have the power to arbitrarily terminate any students’ Visa. We do not enjoy freedom of speech nor due process. What happened to me is cruel and unusual.

In fact, the existence of this very article may put myself at risk. But if there is one thing I learned in America, that is — you stand against bullies.

Lastly I like to thank everyone that helped me through past few weeks, it was genuinely difficult, and this time I like to remember them before I forgot. Thanks Professor Danny Bilson, Professor Peter Brinson, Professor Debbie Yuen, Assistant Dean Marcus Anderson, Professor Mark Bolas, Cooper, Justin, Hanwen, Aria, Jerry, E, Chellie, Jason, Ari, Miles, Anthony, Tielong, Xiao, Ebay, Rae, Lisa, Kiwi, Chuke, Olivia, JC, Wenxuan, and everyone else I couldn’t name here. Thank you for making me feel like I belong.

Needlessly to say, Intel had another giant miss during the same era — iPhone. The most common version of the Intel’s iPhone story is Apple has approached Intel to design a iPhone chip and Intel passed/not winning it. Apparently, according to Tony Fadell . This narrative was not true at all, Apple never considered Intel since their chips were so inefficient. But the point still stands, Intel happily stand on the sidelines and let Samsung then TSMC took this one.

Here what happened, Intel saw they had deep moats in CPU for decades. So they ignored all the emerging market segments that had lower profit margins and niche addressable market. And when those segments become too big to ignore, they wrongfully believed they can easily integrate new capabilities (integrated graphics) or easily scale down. They allowed their competitors to survive and strive from below. Ironically, the exact same thing happened to Intel in the 80s. When the Intel had to withdraw from their then main business DRAM and focus on logics. Intel forgot Only Paranoid Survives, and proceeded to getting killed in Mobile, GPU, PC, Cloud, and AI.

Yuhao:

After Peter’s lecture on turning our limitations into features of the game, I realized the best approach is to eliminate any heavy art-related elements. I was also thinking about the mechanics from your previous game, which relied heavily on physics. Right now, in our current design, “physics” mainly show up when a player inputs something, and there’s only minimal interaction with the environment. That got me wondering how we could introduce stronger physics-based interactions between players—and also how to address one of my biggest concerns: finding a compelling gameplay reason for players to move so fast or chain their movements to maintain momentum, aside from just the thrill of speed.

When I look at movement shooters like Doom Eternal or Quake, I notice Doom Eternal doesn’t really emphasize going “very fast,” but rather continuous movement for dodging bullets and chaining weapon usage. Meanwhile, Quake focuses on speed to grab resources quickly and launch surprise attacks. We both love moving fast, maintaining momentum, and especially chaining different movement mechanics to get massive bursts of speed. But I’m still not fully convinced we’ve found a unique gameplay motivation for that speed beyond the usual “surprise attack” or “resource race.”

Then I thought about Ace Combat—the dogfights between two high-speed fighter jets. In those games, you don’t get to fire your weapon too often, and controlling your position is key. That concept of a dogfight reminded me of Smash Bros., where aerial movement is crucial to return to the stage after being knocked out. I started wondering if that dogfight idea could serve as the main goal in our game. It seems promising, especially if we replace the traditional health bar with a knockback meter.

So here’s the idea: a Smash Bros. + movement shooter hybrid. Picture a 1v1 match on a floating island arena with no walls, so players can fall off. Each player has a different ability—say, Player A has a grappling hook, Player B has an air dash—and they only have their bare fists as a “weapon.” Instead of health, there’s a knockback meter that increases each time you get hit, and the higher it is, the farther you’ll be knocked back. The objective is to knock your opponent off the island.

As the match starts, both players dash toward specific areas to pick up weapons or equipment—things like an air-blast gun (similar to Lucio’s right-click in Overwatch), a grenade that creates walls (like Sage’s wall in Valorant), or a throwable jump pad to alter the level for the whole game. Each item has limited uses (maybe 1–3), so players have to keep searching for more. You can only carry one or two at a time. The “first phase” is grabbing these items, and the “second phase” is the dogfight, using everything you’ve collected. If we make the movement system flexible and momentum-based, I think we’ll see a lot of cool, emergent plays.

The game cycles between these two phases—collecting and fighting—until a “knockout phase” occurs. For example, if Player B’s meter is high and they get knocked off, they’ll have to use every ability and gadget to get back. That tests how well they know their own tools. If they recover, the fight goes on; if they fail, they fall and lose, or we could do a Smash Bros.-style stock system.

I believe this setup is straightforward and addresses my concern about motivation for fast movement. I’m not entirely sure if everything will work perfectly, but it combines what we both love, and it seems like a fresh take. I don’t know any shooter that does this, and it fits our goal of pushing everything to the limit instead of making something mediocre.

Coop

In software, testing usually happens in productions, either during official or beta releases. These tests are highly data driven, large scale, and often invisible to the participants. Takes A/B testing for example, a method that compare two (or more) design variations, rolls out to hundreds of thousands of live users; key outcome metrics like conversion, click rates, and etc. are measured to highlight any statistical significances. And afterward product manager would analyze these data and provide insights and assumptions into potential behavior changes, as well as actionable decisions and tasks. While these testing are great at revealing users preferences. They often fail to provide larger context in design; require you to have a sizable audience to start with; and they can stifle innovative idea as user preferences could be wrong. For example, another form a testing common used in software is user testing, And if we had conduct one of this on smartphone users back in 2007, asking whether they preferred BlackBerry’s physical keyboard or newly created iOS’s on-screen keyboard. Odds are, the physical keyboard would have won by a landslide, given its familiarity and track record. But had those early tests dictated the product direction, the breakthrough of the modern software keyboard might never have taken off.

Which is why I believe that playtesting—the favorite methodology of game designers—should be adopted in software development as well. The goal of playtesting is to provide designers with an empirical understanding of their product. Playtesting begins as soon as you start building and continues throughout the entire development and design process.

These tests are conducted on a very small scale, often involving colleagues, friends, and family members. The rules are straightforward:

1. Think Aloud: Testers need to verbalize their thoughts while using the product.
2. Minimal Guidance: You refrain from explaining or guiding them throughout the process, unless they become truly stuck.
3. Inquire About Decisions: Ask them how they think and why they clicked one button instead of another.
4. Regular Sessions: Conduct playtesting sessions regularly and frequently—weekly, every other day, or even daily.
5. Open to Feedback: Be open to disagreeing with what testers say.
6. Team Involvement: Ensure that you and everyone on your team are present to observe the testing.

That’s all there is to it!

For those immersed in data-driven design, it will be difficult to wrap your head around why playtesting is an effective tool without actually trying it. However, I can share why I believe it’s invaluable:

1. Identify Design Flaws: Watching a user struggle with your design makes the issues painfully clear and obvious.
2. Discover New Ideas: You often uncover new ideas by observing how others interact with your product.
3. Enhance Team Engagement: Your team becomes more engaged with the product through the playtesting process. I can’t tell you how motivated it is to watch user responds to your work. And it lights people asses on fire when they realize the product have major flaws.

Simply, it will just tell you which design needs more work and motivate you to do it. Moreover, the 3 points I just gave you are what I personally found valuable. If you want to learn more I recommend this video by Game Maker’s Toolkit:

I learnt this definition from my Professor Peter Brinson, and he was teaching about game production process. For example, a narrative game would often be a more complicated process and is difficult to pivot once you get started. You can’t really pivot a story and expect to keep most of the script. Whereas, a platformer would be complex and easier to pivot half-way through. You can change your core mechanics and rest of your system would work just fine.

But I found these concepts are useful for other process too, like startups. Generally they can be divided into two categories. Those who tackle complicated problems (like semiconductors), and those who tackle the complex problems (like software).