- [DevLog] Spider Webs - 3 August 2026
(Automatically translated from Korean) Hello! Today, we would like to share the process of creating spider webs for our game. Spider webs are obstacles placed on the map that hinder players, but can be easily destroyed. Initial Version This is the initial version of the spider web. This is a version with slightly improved visuals. We created it out of necessity for level design, but it didn't look very good. Rather than a spider web, it felt like an unidentified sticky substance. So we decided that a fundamental improvement beyond simple image changes was needed. Spider Webs in 'Webbed' Around the time we were pondering over this, a game called 'Webbed' became a hot topic for its amazing visuals and gameplay. An acquaintance even demonstrated a similar spider web implementation inspired by the game. Inspired by this, we came up with the idea of implementing a spider web similar to 'Webb…
- [DevLog] Introducing the Vertex-Based Level Design Tool - 5 July 2026
(Translated automatically from Korean.) Hello everyone! Last time, we introduced the tile-based editing tool we use. This time, we'd like to introduce another tool our team utilizes for level creation: the vertex-based editing tool. To briefly compare the two tools... Tile-Based Tool - Edited in standardized tile units - Fast creation/editing/iteration - Primary tool Vertex-Based Tool - Allows for highly flexible terrain creation - Slow creation/editing/iteration - Auxiliary tool These are the differences. Examples of Where the Vertex Tool is Used When you look at terrain like this, the castle wall part is actually just a 2D decoration. Visually, it looks like there is a flat surface on top of the wall that is parallel to the ground, but in reality, there isn't. Because of this, shadows are not cast properly, and the wall is rendered in front of or behind the character depending on the…
- [DevLog] Introduction to the Tilemap Editor - 31 May 2026
(Translated automatically from Korean.) Hello everyone! Today, we'd like to introduce our team's internal tile-based level design tool we use for our game development. Our game features a top-down perspective with varied heights and 3D terrain. These landscapes are made up of tiles, and each tile helps generate the terrain based on data like height, corner shape, and type. Early Development In the early stages of development, we had to manually input this information for every single tile. The workflow back then was... 1. Place tile pieces to create the 'visible part'. 2. Enter the tile type (floor or wall) and height for the wall and ground parts of the tiles. 3. Enter wall or cliff information at the edges of the floor area, matching the tile shape and direction. Early in development, the terrain was relatively simple and the data required to build it didn't change very often, so this…
- [DevLog] Flight - 8 March 2026
(Automatically translated from Korean) Hello! In this devlog, we'd like to introduce how the flight system in the game has been improved over time. 1. Early Version The early version was implemented by simply applying force using a pre-made graph. At this point, it was impossible to set a desired flight path, and the character would often land too early or overshoot the destination. But it wasn't a major issue, so we just went with it... 2. Intermediate Version As development progressed, more and more parameters were added to overcome the system's limitations. We started reusing code from the combat AI for cutscene choreography, and that's when problems arose. - Since it was controlled physically, different results appeared each time - The character couldn't land at the exact position and would land slightly off - Tightening the landing conditions to improve accuracy caused the characte…
- [DevLog] Weapon Rotation - 4 January 2026
Hello! This time, I’d like to write about how we improved our weapon rotation handling. In our game, weapons rotate for various reasons, which means they can be seen from many different angles. To represent this, we sometimes draw pre-rotated sprites, and other times we rotate images in code. But as these two approaches mixed together, the code gradually became more complex. Angle Mapping To simplify the code, we chose to record the rotation value for each image. It has the downside that when the artwork changes, the value needs to be updated too—but compared to drawing the sprites, it’s a small task. So we created a tool that maps rotation and offset values to each pixel-art sprite. Thanks to this, we were able to remove and simplify many parts of the code. And with this data mapping, we were also able to implement several additional features. 1. Motion blending When a motion cancel ha…
- [DevLog] Pathfinding System - 2 November 2025
Hello! Today, we'd like to introduce our game's pathfinding system. Our first system was a simple tile‑grid approach. With the A* algorithm, it explores the terrain in eight directions: north, south, east, west, and the four diagonals. In the early game the terrain was simple, but in the new levels ropes and humans appear. So we thought AI should also be able to make use of ropes. To make pathfinding efficient, we needed to incorporate these features into the system. We decided to build a navigation mesh to store such points. Navigation Mesh Here is the navigation mesh we completed after lots of coding. For debugging, additional detailed information is shown in the editor. Ropes are mapped as shown above. We calculate positions where you can jump onto a rope to connect the terrain. Based on this, we run pathfinding. Each path contains information about different movement modes such as w…
- [DevLog] Dynamic Pixel Object Rendering - 7 September 2025
Hello! Today, I’d like to share the process of dynamically rendering pixel art. The reason for implementing this at first was for a newly added monster. It needed to smash the ground around it freely with its head, which was hard to express with simple images. So I used RenderTextures to draw pixels. The initial implementation was heavily hardcoded, and the algorithm was unstable at times. But I wrapped it up roughly for the first attempt. Later, I came up with a new monster design. This required using dynamic rendering again, and I decided to refine it for broader applications. New Implementation In the new method, I switched to mesh rendering. It’s more stable in various situations. To do this, I first implemented the ability to draw pixelated shapes onto a RenderTexture. At first, I tried checking each pixel one by one. Implementation was simple but very slow. I thought it might be d…
- [DevLog] Door Improvement - Editor Edition - 3 August 2025
Hello! Today, I’d like to talk about the work we did to make placing doors (and windows) easier. In our previous game, placing doors was relatively difficult. The reason it was difficult was because you had to create a hole in the wall before placing a door. The pain of placing doors and windows Since our game is tile-based, holes also had to be made in tile units. However, doors are not sized exactly to fit a tile. In other words, the door image inevitably had to include graphics to fill the wall gap. Also, to finely adjust the position of a door, we needed another version of the image with a different background. To support placing a door offset by half a tile, we had to create both versions like above. Still, we developed while enduring this hassle. Game development produces mountains of issues, and unless they’re critical, we often overlook them. The door issue that finally stood ou…
- [DevLog] The Feeling of Passing Through Doors - 6 July 2025
Hello! Today, I’d like to talk about how we improved the feeling of passing through doors in our game. Actually, this was something we worked on quite a while ago. Initial State of the Door This is the door we originally made. How does it look? At the time, we didn’t feel anything uncomfortable or strange about it. We only recognized the issue by chance, when we saw the door from another game. This is from a game called Causality. Compared to our game, doesn’t the door-passing feel look much smoother? Seeing this made us realize we needed to improve our own system. Improving the Door Transition Feel We made a number of fine adjustments, but the core goal was: “When passing through a door, it should never feel like control is interrupted or the character stops.” - The character shouldn’t stop when passing through a door. - Minimize fade-to-black time. - Camera should follow smoothly. Fin…
- [DevLog] Grass Movement - 8 June 2025
Hello! Today, I’d like to briefly share how we improved the movement of grass. Initial Version This is the grass that existed in the early stages of development. When we placed it in the game, the static appearance looked dull, so we tried adding a wind-swaying effect. To achieve this, we pre-baked tilted versions of the grass generated via code. While the added movement was nice, the auto-generated visuals weren’t particularly appealing. Hand-drawing everything was too much work, and it didn’t seem like it would be much better anyway. Also, having to re-bake the textures every time we modified an image was a hassle. Still, since we couldn’t come up with a better solution, and it looked much better than static images, we just stuck with it. New Method We happened to see a scene from the game Eastward. There was grass swaying in the wind, and even though it was rendered using mesh bendin…
- [DevLog] Bridge - 4 May 2025
Hello! Today, I'd like to write about how we improved the bridge in our game. In our game, terrain objects like the bridge shown above appear frequently. Although it looks simple, it was outside of the in-game tile system, so placing it required unnecessarily complex work. Manual placement was required to position the asset properly in 3D space, and various exception cases had to be handled. But even when the bridge had no special gimmick, it still felt good as a decorative element, so we wanted to place more bridges. So, we decided to systematize the bridge. 1. Plan First, we sketched a concept design for the new bridge. One thing we had in mind when drawing the concept was a game we saw long ago called Princess Blitz. It’s something we saw quite a while ago, but it sometimes popped into our heads. We thought it would be great if the newly created bridge could move dynamically. In the…
- [DevLog] Terrain Lighting Effect Improvement - 30 March 2025
Hello! Today, I'd like to briefly write about how we improved the terrain lighting effects in our game. Our game's original terrain lighting was implemented by storing light information in screen space. This means that the light was just a simple flat image blend effect. This implementation behaves differently from real physical light, resulting in a slight awkwardness. However, since it is hard to notice unless you pay close attention, we kept using it. 1. Problem Occurrence One day, we placed a light that illuminated a cactus inside a cave. And as a result, the shortcomings of the original lighting method became prominent. Take a look at the picture. Can you tell what the problem is? The light coming from above only illuminates the bottom part of the cactus. A problem that was not very noticeable before became apparent due to the cactus's height. 2. Problem Resolution Fortunately, our…
- [DevLog] Terrain Height Differentiation Display - 2 March 2025
(Automatically translated from Korean) Hello! Today, we'd like to briefly write about a graphic effect for differentiating terrain of different heights. Our game features the concept of elevation in its terrain, and landscapes of various heights appear. However, due to the nature of the Orthogonal view which lacks perspective, heights are often difficult to distinguish. We had been designing levels by avoiding the creation of such varied terrain altogether, but this had the drawback of reducing freedom in level design. Then, while talking with a former developer of Chrono Sword, we learned that they applied fog to terrain of different heights to create color differences. Thinking it was a great idea, we also implemented this method. Simply hazing the terrain's color seems to convey a much better sense of different elevations. Of course, even with this implementation, the principle of ca…
- [DevLog] Rope - 2 February 2025
Hello! Today, I'd like to talk about the process we went through to create the initial rope in our game. What is a Rope? In our game, the rope is an object that players can grab and hang onto. It is mainly used to diversify the terrain by placing it on cliff areas. The idea for the rope started as a simple decorative element. In the early stages of development, we created chains as decorative background elements. After making them, we thought it would be nice if they could move physically. So, we used the game engine’s physics features to implement realistic movement. Later, as time passed while creating mountain terrain levels, we were pondering what to fill into the sub-route. At that moment, the idea of a rope – resembling the chain we had made before, but one that a character could hang from – came to mind. The Initial Rope Since it was just a matter of adding the hanging functional…
- [DevLog] Shadow Map - 5 January 2025
Hello! This time, I’d like to share the story of how we created the shadow map. Our team consists of just two programmers, so the game tends to look visually plain. As such, we’ve been thinking a lot about how to make the game visuals feel richer. One of the ideas we came up with was to add shadows to the edges of tiles. The mockup we created before making it seemed promising. So, we decided to implement a feature to automatically generate these shadows. First Implementation The first method we tried was to draw a black line along the floor edges and then blur it. We tested this idea on the floor sections first, and it looked fine initially. But when we implemented shadows for the walls and applied it to actual maps, issues emerged. Shadows didn’t form adequately in map corners, and they didn’t generate correctly near objects like doors that alter terrain shapes. Improvement After much…
- [DevLog] Dialogue System - 8 December 2024
Hello! We are Team OOPArts, currently developing Frostory. This time, we’d like to introduce the dialogue system of our game. At the beginning of development, we were quite inexperienced in optimizing our workflow. We even made a very inconvenient editor and kept using it, unaware of how uncomfortable it was. The old dialogue editor is one such example. Old Method First, we created a dialogue style. A dialogue style includes data such as fonts, text colors, text appearance speed, and speech bubble images. Separating these elements was one thing we did right back then. Next, it was time to display the dialogue. To display a single speech bubble, we had to input ①, ②, and ③ every time. Here’s an example of how the text data looked back then. In the early stages of game development, this method seemed fine. We were busy implementing the game’s system and didn’t think the existing dialogue-…
- [DevLog] #05 Considerations about pixel-perfect graphics - 4 November 2024
Hello! This is Team OOPArts, currently developing Frostory. This time, we’d like to discuss the considerations we had about pixel-perfect rendering in the early stages of development. At the beginning of development, we didn’t pay much attention to pixel-perfect rendering. (In fact, we didn’t even know the term "pixel-perfect" back then.) However, as development progressed, we came across the concept of pixel-perfect rendering. We found that various approaches were used in different games. Perfect Pixel-Perfect Rendering When Pixel Snap is not applied (slight misalignment between background and character) Allowing pixel rotation and scaling Each approach has its own advantages and disadvantages. The first method offers the best presentation when stationary and has a strong retro feel. However, when forced to render rotating objects in pixel-perfect units, the pixels looked broken, which…
- [DevLog] #04 Aseprite Art Resource Creation Process - 29 September 2024
Hello! This is Team OOPArts, currently developing Frostory. Today, we would like to briefly introduce how we create art resources in our game. Please note that our team uses the Unity engine and Aseprite for creating pixel art! 1. Pivot Issue The biggest issue when creating resources using Aseprite is setting the pivot. The pivot refers to the center of an image, which is used as a point when rotating or scaling the image. However, Aseprite does not provide a way to set the pivot when exporting images. So... initially, we manually edited the pivot by opening the meta file. But of course, this was not a sustainable solution. At first, we attempted to modify Aseprite itself (since it is open-source) to resolve the issue. We tried to add pivot data to the ase file format. However, we soon faced the issue of having to merge the latest commits each time, so we had to come up with another sol…
- [DevLog] #03 Object Sorting in Top-Down View [2/2] - 1 September 2024
Hello, this is Team OOPArts, currently developing Frostory. During the game development process, we often encounter unexpected problems. The object sorting method mentioned in a previous post was one such issue. In this post, we will discuss how we resolved this problem. 1. Issues with the Previous Method The previous method had issues handling sloped terrains. While splitting terrain tiles and sorting them based on the y-axis and z-axis was effective on flat surfaces, it showed limitations in more complex terrains. In a terrain like the one above, where the player (A), monster (B), sloped terrain, and ground need to be drawn, we must decide the criteria and order for drawing these four objects. In the old system, the order was determined based on the y-axis and z-axis. Simply put, the closer the object was to the bottom of the y-axis or the top of the z-axis, the closer it was drawn to…
- [DevLog] #02 Object Sorting in Top-Down View [1/2] - 4 August 2024
Hello! We are Team OOPArts, developing Frostory. Our game is a top-down view game, a perspective widely used in game development for decades. Therefore, many of the technical issues we faced with the top-down view were unexpected. The first challenge we encountered was the issue of object sorting. This is a fundamental element to ensure that the game world is correctly represented in a top-down view. 1. Basic Sorting Issue Resolution We started with the most basic method of sorting by comparing y-values. This means that the larger the y-coordinate of an image, the farther back it is drawn. This GIF shows how y-value sorting works in the actual game. Even with just y-value sorting, you can see that the overlapping of characters with other objects is naturally handled as they move. 2. Adding the Concept of Height Introducing the concept of height to the game complicated the situation. In…
