NC

The TECH TRACK series sheds light on the developers of projects currently under development by NC. Take a look at the various jobs and the career path that has been built to become an expert.

In this episode, we'll be introducing the client programmer of the free-for-all action battle game 〈Battle Crush〉, Lee Yunseok.

Game client programmers implement rules and events that happen between the characters and objects within the game world through programming. I'm in charge of game client content development, and recently, I've been focusing my work on combat logic and the implementation of new characters.

I believe that the fun of games comes from unpredictable gimmicks. In fact, the moments I enjoyed the most while playing games were when unexpected variables influenced my actions and the outcome of the game. And now, as a game developer, I think about how to naturally implement various elements that can provide pleasant surprises to players in the game.

My role involves creating elements that are directly visible to the players and making them closely related to the players' experience. The process of implementing design ideas into code and filling up the screen feels like creating something new, which is truly enjoyable. Just the thought of the devices I implement bringing joy to the players is very satisfying.

I started my developer career at NC. I have been solely working as a client programmer for 12 years now. Starting with tool programming for the casual shooting action game 〈Master X Master〉, I was put in charge of client programming and Unreal Engine porting work. After the service closure of 〈Master X Master〉, I joined the 〈Battle Crush〉 project and had the opportunity to actively utilize Unreal Engine. As a result, I've had experience in tool programming, engine programming, and content programming. And these experiences have greatly broadened my views as a programmer. I believe that having diverse experiences will help one grow into an open-minded programmer.

One may think of programming as something you do on your own, but game development in a company setting involves constant collaboration and communication. You need to match your pace with the team's pace, align your progress with other collaborative departments, and even synchronize with the milestones at the organizational level. Lastly, you also need to align with the overall project's blueprint.

Because of this, it's important to keep the barrier between working alone and collaborating low. Focusing only on my tasks without any mid-progress sharing or reporting can make it difficult to transition into a collaborative mindset when the time comes for cooperation. And the longer you wait to share an issue that requires attention during a collaborative process, the more time and resources it will eventually take to resolve. Communication with the server team is especially important for client programmers. Which is why I occasionally pause and check if I'm on track with the overall project's direction and pace even when working alone. I believe that a good programmer is a programmer who communicates well.

〈Battle Crush〉 is a traditional action combat game that utilizes unique mythological heroes as its characters. The main mode of 〈Battle Crush〉 is the battle royale mode, where battles occur in real-time, and the winners of small skirmishes will get the chance to engage in the final battle. Unlike traditional battle royale games, the battle royale mode in 〈Battle Crush〉 features randomly collapsing terrains during the match.This is the crucial element that differentiates our game from others.

The unpredictable destruction of terrain and the appearance of traps play a vital role in maintaining the "action-packed" nature of the free-for-all combat. For instance, we create random variables by incorporating various gimmicks into levels, such as collapsing terrains, explosions, water areas, and jump pads. This was crucial given the nature of the project, but it was also something I found most gratifying to work on as someone who enjoys dynamic variables.

〈Battle Crush〉 is unique in that the random terrain destruction introduces variability to the gameplay. The most important part of the development of the terrain destruction system was the synchronization between the server and the client. The terrain is where the characters stand, so any malfunction in the terrain could become a critical bug for the player. If there is a discrepancy where the terrain appears intact on the screen but is recognized as collapsed on the server, this can lead to sudden character deaths with the character falling through the ground, or characters appearing to be floating mid-air above collapsed terrain in an inverse case. These problems arise from improper synchronization.

We didn't use the laborious method of working on each individual piece of terrain and synchronizing between the server and the client. This was to avoid unnecessary network traffic. Instead, we calculated the range and timing of terrain collapses in advance on the server and synchronized only the timing and range information with the client. By employing this method, we minimized traffic while ensuring that both the server and the client handled terrain collapses consistently.

Additionally, we distinguished the logic handled by the server from the client. For example, when the terrain collapses downward, the servers, which aren't visible, don't necessarily require the logic to calculate the animation of the terrain collapsing. Therefore, when a terrain collapses, the actual collision area (where characters can stand) is immediately removed from the server, while the client handles the animation logic. As much as the terrain destruction was the differentiating factor of our game, it was the part that we put our greatest effort into.

In the early stages of development, I believe that the team's agility determines a project's overall speed of development and quality of growth. A team that can quickly incorporate feedback with close intra-organizational communication serving as the foundation will experience a smooth development process where new features or content can be developed without obstacles.

Our organization is very agile. Direct communication is easy, and we actively try to coordinate our schedules and opinions, which enables us to implement feedback quickly. In fact, the client and server teams hold daily meetings in the mornings to not only check up on the direction of the overall progress but the progress of individuals as well. It's especially efficient because our company culture encourages us to immediately ask questions without having to struggle with them alone. Communicating in person enables us to exchange much more information within a shorter amount of time than communicating online, and we can also make small talk about our daily lives which boosts the atmosphere even more.

Furthermore, the lengths of our milestones, which average between one to two months (shorter than most other teams), serve as a driving force for the team to quickly adapt to changes and grow. The leader group will present a milestone's goals, and each team leader will outline their team members' schedules. Then, the team members will execute the tasks. A detailed daily schedule has the effect of clearly outlining work objectives.

According to the "one test a day" principle, the planning team and the programming team will conduct a Build Verification Test (BVT) together every day around 10:30 in the morning. Having all the development personnel consistently conduct tests every day is no easy task. But this reflects our organization's unique characteristic of taking short breaths to identify issues and seek improvements.

Through BVTs, we check if the features we implemented on the previous day have been integrated into the build and play the game to identify any bugs. What's important about this is that we can quickly find and fix bugs, and at the same time, have fun. Above everything, the game itself is really fun. When you play with the same people every day, you even get to know everyone's nicknames as well. Even if nicknames are hidden, it's fun how we can identify who is who based on play style alone. Another small but fun thing we do is that since everyone's nicknames are so creative, we sometimes refer to each other by those nicknames when working. Seeing tons of "likes" pop up when the BVT announcement is posted makes me think that a lot of people are also looking forward to this time, as do I.