add event_awards table

[Jamiras]

Adds the ability to associate badges to a number of unlocked achievements within an Event game.

For example, for AotW 2025:

This PR only touches the administration side of things. Future PRs will be opened to award and display the badges.

[wescopeland]

I have reviewed all of the code in this PR and it all looks logically sound. I want to steer the conversation towards this migration, as it drives the architectural underpinnings of the PR and could have profound impacts on how the system stores and manages events going forward.

We're creating increasingly tight coupling between events and games, and I'm not entirely sure this is desirable unless we want to establish that events will continue to live on indefinitely as games in the database.

My view could be changed, but I have a feeling that the path we should be driving towards is events existing as their own kind of entity. This would facilitate varied kinds of events, an actual events dashboard / home page, and potentially even a quests system in the future.

I know we don't have an events table yet, but it seems like this may actually be our best opportunity to create one. The migration below is me spitballing and have only thought about this for 5 minutes. The core idea here is Event Awards are associated to a new type of entity -- an Event -- not games:

Schema::create('events', function (Blueprint $table) {
    $table->bigIncrements('id');
    // For now this will always point to a game with ConsoleID 101.
    // In the future this can be made nullable.
    $table->unsignedBigInteger('legacy_game_id');
    $table->string('name', 100);
    // `EventType` enum? achievement_hunt, quest, competition, etc
    $table->string('type', 50);
    // For storing event-specific config/metadata, ie: rules, etc
    $table->json('properties')->nullable();
    $table->dateTime('starts_at');
    $table->dateTime('ends_at');
    $table->timestamps();
    $table->softDeletes();

    // When we're ready to migrate away from events-as-games,
    // we can make this nullable and add games via a proper pivot table.
    $table->foreign('legacy_game_id')
        ->references('ID')
        ->on('GameData')
        ->onDelete('cascade');
});

Schema::create('event_awards', function (Blueprint $table) {
    $table->bigIncrements('id');
    $table->unsignedBigInteger('event_id');
    $table->integer('tier_index');
    $table->string('label', 40);
    // either nullable or defaults to 0? not all events may have achievements required
    $table->integer('achievements_required');
    $table->string('image_asset_path', 50);
    $table->timestamps();
    $table->softDeletes();

    $table->foreign('event_id')
        ->references('id')
        ->on('events')
        ->onDelete('cascade');

    $table->unique(['event_id', 'tier_index']);
});

With this schema, events are still associated to games via legacy_game_id, but event_awards are now associated to events. As more event stuff is built out, it can be attached to events rather than GameData, which will make extraction of events from games significantly easier in the future.

There's both an immediate and long-term benefit of pursuing this path in that we already beginning to break the coupling of events to games while maintaining backwards compatibility through legacy_game_id.

[Jamiras]

While I agree with the idea, I don't think we're in a place where it's practical yet.

The way the AotW2025 event is functioning now, it relies on the player_achievements table to hold the unlocks and the GameMetrics aggregate jobs to track player counts and per-week participation. And because unlocks are associated to achievements, and achievements are associated to games, there's already a tight coupling that will be a lot harder to fix than adding an extra foreign key to the event_awards table to point an event instead of a game.

To do this effectively, we'd have to have a player_event_achievements table to track event achievement unlocks, and EventMetrics jobs to update player counts and participation. Then we'd have to duplicate a lot of the widgets on the game page to query and use the alternate data.

[wescopeland]

I do acknowledge these valid concerns regarding event achievement entities. My suggestion is that we begin taking an incremental approach with the events table:

• We can create the new table now but keep the game-based achievement tracking in place. We don't have to disrupt that at the moment.
• This gives us the foundation to gradually migrate event functionality rather than further tightening the coupling to games. We can do this right now with awards, and later tackle more complex stuff like the achievement tracking and metrics.
• Having events as a separate entity makes each future migration/decoupling step cleaner.

The goal isn't to decouple everything immediately, but to create a path for progressive decoupling as resources allow. Does that seem practical?

[Jamiras]

I'll think about this some more. It's probably reasonable to make an event object wrap a game, so we can keep all the game-derived functionality working while offloading some of the non-game dependencies.