This page was machine-translated from Korean. View the Korean original →

← Blog
Game JamReview

Nexon University Student Game Jam JaemitNexon 2026 Participation Review and Retrospective

제세형

Participated in JaemitNexon 2026 and developed a WarioWare-like game where players create history over 3 days and 2 nights, based on the theme of "Context."


From July 24th to 26th, I participated in "JaemitNex 2026," a game jam for university students hosted by Nexon. Although we didn't win an award, it was a truly enjoyable experience developing a game for three full days.

628887450-3f0d1246-b0d9-4d6d-9815-6d6c033472a4.gif

From the Big Bang to the Future — The World You Create

JaemitNex 2026 · Theme 「Context」

The theme for this JaemitNex was "Context." Given the AI era, and the fact that it was Nexon's first AI Native game jam, I thought it was a fitting theme, but it was such an abstract concept that it was hard to get a handle on it at first. Then, I found a team recruiting members with the concept of "History Wario, creating historical and temporal context," and I was completely hooked on the theme and joined immediately.

A Team Composed Entirely of "Computer Science" Undergraduates

As this was an AI Native game jam, there were no designated positions from the recruitment stage. I believe the greatest value of this JaemitNex was that all participants, under the single title of "Game Creator," broke down the boundaries between planning, art, and programming to work together to create the best game.

Although it was a team formed quite quickly (I remember it being the third team formed out of all of them), our team consisted entirely of engineering students majoring in computer science. At first, there was some concern. However, since this was an AI Native game jam, I thought there was nothing we couldn't do. In fact, considering the purpose of this jam, I judged that our team might actually have an advantage in terms of utilizing AI.

BandiView20260729041705.jpg IMG4659.jpg

The Quirky Mini-Games We Created

assetsHighlight.png

We decided on a realistic photo-montage style for the game's art concept. When creating game assets with AI, consistency was more important than anything else. By using the initial output assets as references for subsequent image generation, we were able to maintain a consistent design tone throughout the game. In this way, by combining the assets created by our fifth team member, AI, with our own ideas, we were able to complete some quirky micro-games.

Honeycam 2026-07-30 23-53-29.gif Honeycam 2026-07-30 23-56-17.gif

My Contributions

Implementing the Game's Core System

When implementing the prototype, I initially created the mini-games as individual scenes. However, due to the nature of the WarioWare-like genre, where 3-5 second micro-games need to transition at a fast pace, I judged that implementing every micro-game as a scene and switching between them would have significant side effects, such as micro-stuttering during transitions. Therefore, I decided to implement each micro-game as a prefab, with a central player executing them.

cs /// /// Abstract base class that defines the common lifecycle of all mini-games. /// Created as prefabs, preloaded by , /// played via when commanded, and notified via when done. /// public abstract class MiniGame : MonoBehaviour { //... Omitted...// public event Action Finished;

// ── Derived Class Hooks ── /// Implement actual game start logic in derived classes. protected abstract void OnPlay();

/// Implement logic to restore state to initial values in derived classes. protected abstract void OnStopAndReset(); //... Omitted...// }

In addition to this, I organized and documented the contract requirements that must be followed when creating mini-games. The goal was to ensure that project conventions could be consistently followed across multiple AI sessions, and to increase collaboration efficiency by allowing all team members to create games in parallel.

plaintext

MiniGame Contract

These are the conventions that must be followed when creating a new WarioWare-style mini-game. The common base is Assets/01Scripts/Core/MiniGame.cs, and the player is Assets/01Scripts/Core/MiniGamePlayer.cs. For actual implementation examples, refer to Assets/01Scripts/Minisha/RubMiniGame.cs.

///...Omitted...///

Beyond this, I implemented core features such as the basic system for penalty effects triggered upon mini-game failure, the contract documentation, and a camera effect control manager, creating a foundation that could be easily used when building each mini-game.

Micro-Games Created

제목-없음-1.jpg

  • Dolmen capping game
  • Archimedes bathtub immersion game
  • Witch finding game
  • UFO cow abduction game

I created these.

Post-Processing Shader

제목-없음-3.jpg (Left: Before shader application / Right: After shader application)

Although I hadn't written shaders directly in HLSL before, I had basic knowledge of the graphics rendering pipeline from taking a Computer Graphics course in my junior year. Based on this, I used AI to write a custom shader, which further elevated the game's atmosphere.

The main concept I had in mind was PS1 Aesthetic, the 'PlayStation 1 feel' often used in recent horror games. It refers to a unique audiovisual style born from the technical limitations of the Sony PlayStation 1 console in the mid-1990s, characterized by a dreamy and eerie atmosphere coming from its distinct low resolution and texture jittering. I thought it would act as a kind of "kick" if applied to our game.

Ultimately, I was able to implement and apply effects such as pixelation, color quantization (dithering), CRT-style barrel distortion (concave lens distortion), and horizontal jitter noise.

Regrets

Micro-games playing in a fixed order

Although we couldn't organize the events in a perfect sequence, we arranged the games according to a rough chronological flow, which resulted in the micro-games playing in the same order every time. We couldn't perfectly verify the chronological order of the historical events, and I feel the fun of repeated play was diminished.

In particular, our game had a structure where the success/failure of specific mini-games affected the content of the ending roll and the generated images. The core element was supposed to be the ending that changed every session during repeated play, and it is a great regret that I didn't consider this part sufficiently at the time.

What if we had faithfully followed the grammar of the original WarioWare?

Our game is a WarioWare-like, sharing the same composition as the original in that 3-5 second micro-games pour down, but we decided to make a few differentiations.

  • There are no separate lives.

The original game features 4 lives, which are consumed upon failure, leading to a game over or a revival round once all are depleted. In contrast, our game has no separate lives. This was a design choice stemming from the concept that "time keeps flowing even if you fail a micro-game."

  • Failing certain games leads directly to an ending.

This applies when failing games based on pivotal events in human history. For example, what if prehistoric humans failed to discover fire? The game immediately transitions to an ending where humanity remains in the prehistoric era, unable to light a fire even by the year 2222.

While these unique rules could have been a defining feature of our game, looking back, I feel it might have been a better approach to adopt the rules of the original WarioWare. For instance, we could have randomized the order of games within each era, or separated each era into distinct stages to reinforce the story and narrative.

Could we have increased the volume of micro-games?

While mindlessly increasing the number of micro-games within a limited time could lower the overall quality, I can't help but feel that we could have increased the number of games, perhaps by sacrificing a bit more sleep or by more actively utilizing AI agents.

If the number of games had been higher, we could have divided each era into stages and enhanced the randomness. Instead of seeing the same games every round, we could have allowed players to play 20 randomly selected games out of 30, providing the joy of discovering new micro-games with every replay.

Conclusion

Making micro-games in the early hours of the morning and watching the ones my teammates created made me laugh until my stomach hurt. Although we didn't win an award, I truly enjoyed participating in the game development process for those three days and two nights. If there were an award for "having the most fun," I think our team would have taken first place. It was a truly enjoyable experience. I'm a senior now, so it seems unlikely I'll be able to participate in next year's Jaemit-Nex, but if I don't graduate this year, I definitely plan to participate again.

20260726182704.jpg The teammates who spent 3 days and 2 nights together A12I1658.jpg A12I1735.jpg

🌌 What does your world look like? 🌌

Made with ☕ and 😴 in 3 days · NEXON Game Jam

Keep reading