Topic: From Vibe Coding to Building an Interactive Map for Open World Game Development

Speaker: Kim Ki-jin - Nexon Korea

Field: Game Design, Artificial Intelligence

Recommended Audience: Game Designers

Tags: #NDC26 #VibeCoding #LevelDesign

[🚨 Lecture Topic] I succeeded in quickly creating a tool that allows me to look up location-based data like Google Maps, update it instantly, and share it with team members—all without losing time on my core tasks and without knowing how to read a single line of code. I hope this presentation helps you stop fearing AI and start using it as a partner and a useful tool in your work.

In an era where the excuse "I can't build an app because I don't know how to code" no longer holds water, Kim Ki-jin, a lead game designer at Nexon Korea, created a collaborative interactive map editor for an open-world RPG simply by giving instructions as if he were having a conversation, despite not being able to read code. On the final day of NDC 2026, he shared his journey—which he jokingly called a series of "trial and error"—without holding anything back.

Kim joined the game industry in 2008 after dropping out of college, driven by a single-minded desire to make games. He stated that he has long held a dream of creating worlds worth exploring, featuring adventures on 3D maps based on deep stories, noting that "games are the pinnacle of interactive culture and art, combining text, visuals, systems, and sound."

A Designer Who Only Knew 'Hello World' Meets AI

Kim's first encounter with Vibe Coding was through Google AI Studio and Antigravity. Before that, his coding experience was virtually non-existent; he had only ever "printed "Hello World!" once."

What he needed to build was a world map editor for 'Project EL,' a large-scale open-world RPG spanning 10km by 10km. It needed to allow for inputting text and images for vast areas, easy retrieval of information, and real-time sharing of edits among all users. Above all, the goal was to boost development speed by accessing necessary information without having to launch the resource-heavy Unreal Engine.

There had been many attempts before. PowerPoint, a designer's best friend, was fine for small areas but hit clear limits as the amount of information grew, eventually becoming just an intermediate step before uploading to Notion or Confluence. It was cumbersome to re-upload images every time the original was modified. Visio was difficult because it wasn't designed for collaborative viewing, and online Photoshop was too slow for handling a massive map, not to mention the need for individual approvals for team access, making it impractical.

During this process, he opened his eyes to AI. Google AI Studio, which is as accessible as Gmail or Google Drive, was the turning point that taught him he could "create simple programs just by giving instructions as if talking." However, it had limitations, as it was focused on prototyping and didn't allow for uploading custom images.

Antigravity filled that gap. Hearing that the planning team lead for Project EL was using it, he installed it and found it "intuitive, simple, and free, with almost no complex options to worry about." As an agent-based integrated development environment, the ability to leverage PC resources via AI for development was revolutionary to him. Most importantly, he could use the images already on his computer. He recalled, "December 2025 was the turning point when AI became capable of reasonably efficient coding. The timing was perfect."

A 'Hit' Tool Built in a Day, But...

The first prompt he entered to build the world map editor was long. While it was split into two parts during the lecture, it was actually executed all at once. Kim said, "I was a bit nervous, like sending a long text message to someone," but added, "The AI's comprehension and processing speed were beyond my imagination."

The basic framework involved uploading a mockup map image for the 10km area and adding pins for hunting grounds, dungeons, and villages. He then added a distance measurement tool. This was to estimate how many kilometers were appropriate between villages or how long it would take to travel from point A to point B at a mount's movement speed, allowing him to quickly identify and resolve complaints like "Why is it so far?" or "Why is it so close?" He also intended for the tool to look like a game, aligning features at the bottom of the screen so as not to obstruct the view.

At this point, he emphasized 'imagination.' He explained that one must be able to "visualize the process in one's head—wondering if a certain action will lead to a certain result—even if you aren't sure if it's right or wrong." He saw this as the strength of Vibe Coding: "Even if you don't think it will be 100% correct, you can just try it. If it's wrong, you can go back, and the cost is just a few minutes and a few cents." He found the biggest difference between AI and humans in imagination—the ability to let life experiences create a chemical reaction that produces unexpected results, which can be called ideas or inspiration.

He described the team's reaction to the tool as a "huge hit." It was essentially a planning tool that anyone could access and edit instantly just by entering an IP address, and it ran quite snappily. "Everyone was surprised because no one thought a decent map tool could be built in a single day," he said. He analyzed that the success wasn't just due to its speed, but because it precisely addressed the pain points of the planning team.

Of course, it didn't run smoothly from the start. Because he had thought of it as a lightweight tool, high-resolution map images weren't initially considered, leading to user complaints about "low image quality," "blurriness," and "a need for more diverse pins."

The biggest problem occurred during simultaneous work. Even though it was built for real-time editing, other people's work wasn't being reflected properly, and pins and roads would disappear. The cause lay in the server structure. The server created by the AI saved the entire database every 5 seconds, so if someone else was working while another person was saving, the first person's work would be overwritten.

He said, "Since I didn't know server architecture, I was surprised why this was happening when it saved fine on my end." He eventually solved it by changing the method to save pins and roads as individual data points and adding a feature to repeatedly save data every hour for recovery.

Interestingly, he noted the AI's attitude. "The AI didn't just solve problems; it kindly analyzed and explained what the problem was, which became an opportunity for someone like me to learn additional knowledge." There were even times when the AI pointed out the cause of a phenomenon he observed, such as synchronization issues caused by automatic polling. The AI even took care of things not in the original prompt, such as highlighting the outline of an area during editing. He emphasized, "As long as you are clear about what you want, the AI will take care of things you didn't even think of.".

The conclusion he drew from this experience is 'iteration.' It's the process of discovering a problem, reviewing the situation, asking the AI for a fix, and verifying if it was done correctly, repeating this until it's satisfactory. He said, "This is a principle that applies not only to Vibe Coding but to everything we create. The more familiar you get, the fewer trial-and-error cycles you need, and you get good results on the first try."

"Even with a powerful tool, you don't know what to build"... The 'Benchmark' is more important than tokens'

So, what counts as 'good enough'? He compared this to drawing. Some people move on once the rough sketch composition is done, while others consider composition 80% of the drawing and keep fixing it endlessly. The standard varies from person to person.

Here, he directly contradicted conventional wisdom. While it might seem that using higher-performance AI or more tokens and agents (like 'Claude Max') would allow anyone to get good results quickly, that is not the case in reality. He pointed out that "even if you run thirty agents, the results vary wildly," and "there are more people than you think who don't know what or how to build, even with powerful tools."

In games, even a simple jump by a character feels completely different depending on how you tune the acceleration, gravity, airtime, and landing timing. Without accumulated play experience, you can't even set a benchmark. He said, "Use what you've built through your own experience as an asset, but to go beyond that, you must constantly raise your benchmark." He added that this benchmark is far more important than AI technology, tokens, or models, and it's something many people overlook.

The evolution of the pin feature is a good example. At first, he was satisfied with just placing and deleting village, hunting ground, and boss pins. But as he built it, his ambition grew. Because he chose to work on things one by one and check the results rather than using the trendy 'one-shot prompt' method, his desire as a user kept increasing.

The standard rose from 'it just needs to work' to 'it just needs to not be inconvenient,' and then to 'I want it to be prettier and more intuitive.' Features like opening a separate window with a right-click to change content instantly, diverse appearances so you know what a pin is just by looking at it, and click-and-drag controls were added one by one.

He pointed out, "Users don't know exactly what features they want. They only know if it's convenient or inconvenient. The ability to catch that is the benchmark." The hassle of managing pin descriptions and Notion planning documents separately was solved by fetching the Notion API for automatic updates, and the tool continued to evolve by adding concept images like village artwork.

He summarized the three necessary conditions: a 'clear goal' of knowing what you are building and what benefit it will provide, a 'clear benchmark' to visualize the form even without knowing the details, and 'excessive greed.' He emphasized, "Not just greed, but excessive greed," adding that "greed is synonymous with a desire for improvement."

This desire for improvement elevated a toy project into a core function. Since complex dungeons with 3-4 levels inside a mountain were hard to represent on a single map, he naturally introduced a feature to upload floor-by-floor images, move with WASD, and switch floors with Q and E keys. He also imported vast play data obtained from FGT (where players died, what their movement paths were, where they got items, where they jumped, etc.) into this tool, which shared the same coordinates as the game, to analyze it.

There were hurdles. Dealing with data in subtly different formats was the most difficult part, but because he had played the game himself and understood how the data worked, he kept playing ping-pong with the AI, saying, "It should work like this, but it's not." Crucially, data over 500MB couldn't be read due to Chrome's web limit, but the AI eventually identified the cause and provided a breakthrough solution: "You can stream it in 10MB chunks using a Web Worker."

His ambition extended to 3D. Since he had XY coordinates, it was only natural to bring in Z-axis (height) data. By importing the game's height map and expressing it in 3D like voxels, he completed a world map that could toggle between 2D and 3D. It became possible to intuitively check exactly how high a NPC was or where a village was located in a valley with a single shortcut key. This coordinate information was also linked to AI-based test design and placement tasks he was researching at the time, leading to an "unexpected collaboration."

The final step was super-resolution. For designers frustrated by blurry mockup maps, he applied a super-high-resolution feature reaching 16K (16384 pixels). However, since it was too heavy to display such vast images at once, he optimized it by splitting them into multiple tiles like Google Maps, loading only the tiles currently in view. He added that "sites that share open-world maps actually work this way," noting that this was only possible because he had domain knowledge and experience with Unreal Engine.

There were goals he couldn't reach in the end. Handling vast open-world data and filling content quickly is usually a battle against budget, manpower, and time; the ultimate goal of the world map editor was to focus only on the core of planning and automate the rest. Although it wasn't fully achieved by the time the project ended, he said, "The attempt itself provided great inspiration," adding that "there was a huge appeal in having users, immediately reflecting their needs, and consistently servicing and upgrading something that actually works."

"Technology is no longer a barrier"... How, Why, and Try

He defined Vibe Coding not as a specific technology like Antigravity, Claude, or Codex, but as a 'kind of approach.' Many people are intimidated, thinking they need to equip themselves with tools like prompt-enhancing agents, but the tool he showed was built solely with pure prompts like "make this, make that."

"The most important thing is not the technical approach, but what you need to build and why. In the AI era, "how" you build it is meaningless. Technology is no longer a barrier"

He said that whether someone here is a programmer, designer, artist, writer, or an aspiring student who hasn't found their dream yet, "there is something that can only be created through your own unique experience." Just as he, a game designer and level designer, created a collaborative world map.

The final keywords he left were 'How, Why, and Try.' The most important thing is not 'how,' but 'why you need to build it,' and above all, the most important thing is the 'Try'—starting right now.

Lead Designer Kim Ki-jin concluded his lecture by saying, "There is a lot of talk about AI stealing people's jobs or stealing data. But I see AI as potential. The knowledge humanity has accumulated will become a new power for you. Don't be afraid; start tomorrow. And I hope you will materialize your own wonderful visions."