First game release jitters

[VanVeleca]

I can't help but check over and over again for bugs or any issues, I've been stress itching all day because people might be playing it right now

Wheter they like it or hate I can't help but feel nervous...I almost don't want anyone playing it at all...

Is this normal to feel?

[Gimmick]

It's only natural to want to do as good a job on your first few games, and have others enjoy it. Cherish that feeling while it's still there, you'll grow out of it as you make more games and a) start to care less about what others think, b) realize that not everyone can (or should) be pleased and/or c) in the event of bugs and glitches, you can patch things but what's done is done -- and to focus on doing the best you can before release rather than after the fact.

[detergent1]

At 5/19/24 11:16 AM, VanVeleca wrote: I can't help but check over and over again for bugs or any issues, I've been stress itching all day because people might be playing it right now

Wheter they like it or hate I can't help but feel nervous...I almost don't want anyone playing it at all...

Is this normal to feel?

There are two ways to build trust on code: verification and testing.

I have quite a lot of experience with verification, and unfortunately very little with testing. personally, both testing and verifying games feels daunting, since games are so dynamic. I think that is actually the case, considering the amount of exploits discovered in speedruns, and the never-ending war against hackers in multiplayer games.

Verification boils down to assertions and end-to-end testing (E2E), and more recently, advances in stricter strongly typed languages.

Assertions are used to state impossible things inside a code, then when any of these impossible things happen, your software crashes!! But this is useful, because you can open a debugger and investigate what events led to the impossible situation. Assertion is the core behind design-by-contract (DbC), the oldest software development methodology. Inside DbC there are many viewpoints of what and how much you should assert. Most common assertions check function arguments and before returning from functions. One must never write assertions for normal erros, however! One should never, ever, assert against file or socket errors, against memory allocations errors, against user input etc.!

E2E testing leverage assertions by running your software with trash input generated by a fuzzer, or running it for a very long time using a monkey; the longer it runs, the more robust it is! otherwise it crashes after failing an assertion. Some say you should ship production code with assertions, then let users report you back crashes; others prefer to strip down all assertion code when shipping, to increase performance.

Languages can facilitate verification by being stricter. Being strict basically prohibits entire ranges of errors. Personally, stricter is objectively better. However, relaxed languages are still very popular, because they are "beginner-friendly" and more forgiving, doing "useful" (but surprising) things when you error. Bullshit. Strict languages prohibit many kinds of casts, they have exhaustive switches and exhaustive pattern matching, they check ranges and bounds, they prohibit identifier shadowing, they prohibit confusing overloading, they prohibit referencing undeclared identifiers, they prohibit reading unitialized objects, they have obligatory exception catching, they don't have string execution, they prohibit returning automatic objects, they prohibit incorrect covariance and contravariance, etc. However, some restrictions are annoying and can degrade productivity and efficiency, such as banning return statements in the middle of code, obligatory immutability, banning goto, banning variable capture in closures, banning side-effects, banning native APIs etc.

Testing is very varied: unit testing, integration testing, beta-testing, continuous integration (CI), code coverage and others.

I know nothing about integration testing, but beta-testing is well known by everyone.

Unit testing is about writing hundreds or thousands of small test cases for each module of your software. You write one test case for every bug that has ever happened, you write one test case for every CVE that is related to your domain, you write test cases for every behavior known for an API. Unit testing is the core behind the courage of Extreme Programming (XP), which a software development methodology which tackles both refactoring legacy code, for which you need to preserve old behavior, and writing new software, that has to adhere to expected behaviors. If a test case fails, you know you have broken something!

Related to unit testing is CI. Some people run test cases only before shipping. CI is about running test cases every time you edit code or commit, so you know you broke something as early as possible. Some projects prohibit merging code if any test case fails. Code coverage is done by the compiler, which instruments software to measure if every line or every branch is executed. You measure as you execute the software. The mainstream strategy uses unit testing to exercise code and obtain these statistics. You never ship production code instrumented for code coverage! Projects must strive for 100% code coverage, which combined with unit testing, means 100% of your code is tested and exercised. Consequently, CI and code coverage are essential for XP and related methodologies who want to refactor and implement fearlessly.

Verification and testing share similarities, but do differ. Verification is explained by hardcore theoretical computation and its formalisms. Testing is more external and ad-hoc, where being sure is a best-effort. Both are required simultaneously for maximal security and robustness, but only high-profile projects have time to achieve that. Although I've spoken a lot, my lack of experience developing games cannot tell you where initial efforts should go for, so I can only guess. Games are not life-and-limb software, after all. One thing we know, is that at least beta-testing has been the way to go for most games, so getting a couple of people to play might uncover the most critical bugs. It is also interesting to trust libraries, so if a library handles an entire problem for you, it is one less thing to worry about. Also using strict languages, which stop you from making common mistakes. And finally, people will talk about bugs in comments and forums, so it is another place to keep an eye at.

anyway, I started to type a lot for some time, I dunno what advice are you really looking for, so, cheer up!?

[detergent1]

I love assertions, so lemme exemplify with C:

// Return true if target died, false if still alive.
bool attack_spell(Character *attacker, enum spell spell, Character *enemy)
{
    // Ensure attacker is not frozen or stunned.
    assert(0 == attacker->frozen);
    // Ensure both are alive.  
    assert(attacker->life > 0);
    assert(enemy->life > 0);
    // Ensure enemy cannot attack enemy, or player cannot attack ally.
    assert(attacker->role != enemy->role);
    // If negative, attack can unadvertedly heal!
    assert(attacker->intelligence > 0);
    assert(enemy->magic_resist    > 0);
    assert(spell_damages[spell]   > 0);

    enemy->health  -= spell_damages[spell] * attacker->intelligence / enemy->magic_resist;
    attacker->mana -= spell_costs[spell];

    magic_effect_apply(spell, enemy);

    // Ensure there was enough mana.
    assert(attacker->mana >= 0);
    // Since the entire software will crash, sometimes we can assert after doing crazy bad things.

    return enemy->health <= 0;
}

asserts should be self-explanatory, so comments are unnecessary.