Greetings from the Holoearth Management Team! For this installment we had a chat with Sandbox Team Director Mori Kohei and Lead Engineer Kai Gai about their work on Holoearth development! We asked all about how the sandbox game is developed and more! Interviewee introduction Mori Kohei-san Position: Sandbox Team Director Date joined: May 2021 Industry experience: 12 years Kai Gai-san Position: Engineering Team Lead Date joined: February 2022 Industry experience: 5 years To start off, please tell us about your primary responsibilities and work experience. Mori-san (hereafter Mori): As director of the sandbox team I decide on content direction and supervise what the team members have to come up with, while helping guide them to make the sandbox experience more and more enjoyable. In my career so far I have worked as an engineer, planner, and director at a mobile game company for around nine years. I was already a fan of hololive and at one point read a post [JP only] by Motoaki Tanigo about the creation of a new metaverse platform that the company was starting to hire for. The content of what he was talking about intrigued me - and at the same time I thought that I could make use of the skills I developed up to that point, so I decided to come over to this company. I had always wanted to create a platform where many users log in every day and enjoy not only games but also interaction with other users and all manner of entertainment content, so I thought, “This is it!" and applied for the job the day after reading the article. Kai-san (hereafter Kai): As the lead engineer for the sandbox team, I am mainly responsible for technical specifications, development workflows and project management, as well as collaboration with other teams for development. My previous jobs included positions such as engineer and project manager. In terms of industry experience, I think I am only in my fifth year now. I was also originally a fan of hololive, and I learned about Cover's new project to build an anime style metaverse while I was already watching hololive content. I was really impressed by the idea of starting something brand new in the metaverse with an anime aesthetic, and the technical aspect of Holoearth seemed interesting, so I decided to apply and be a part of this project. Tell us about your thoughts on Holoearth development. Mori: I find it rewarding to be able to incorporate the things that I want to do. There are certainly significant challenges, but the team members are passionate people driven to create Holoearth. I am able to take on challenges with a go-getter attitude even when the goals seem extremely hard to achieve. Kai: So far not many companies are making open world sandbox games using Unity, so we are going on the assumption that there aren't many people with significant experience in such development. We identify each person's strengths and assign the most appropriate role to them. This further enhances each member's expertise and allows us to resolve technical issues smoothly. In ver. 0.5 we released a room for basic crafting, and in ver. 0.8 the area was made larger and included monsters to fight. What are your thoughts on this kind of incremental release schedule? Mori: When I first discussed this with the producer, I was rather apprehensive. This is because at most game companies, including my previous company, it is typical to release a game after it has been fully developed to a playable state and carefully tested. I wondered if the method seen with overseas indie games, where games are released little by little and improvements are made over a period of years while taking feedback, would really be accepted by fans. We discussed this point with the producer early on, and using hololive as an example - which has grown over the years thanks to the support of all the fans - we decided that even if the game was a bit rough at first we would share the development status and let users try out new features at an early stage to create content that users want to enjoy. This is how we settled on the current style of development. As a result, whenever we release updates we get a lot of feedback and reactions on social media, and hololive talents also stream it on their channels, resulting in online discussions about what features would make it more fun - so I'm really happy with how our style of development has turned out. Kai: Just as Mori-san mentioned, I feel the most appealing aspect of this project is that, even in its unfinished state, we can continue to improve it through a series of smaller releases while reflecting user feedback. Mori: Coming from the gaming industry originally, I think most of us are used to development that is planned out over a period of several years and then followed accordingly. We currently use an agile* approach to development, which was difficult at first, but now we have a system in place that allows us to change direction slightly from sprint to sprint while working closely together. It's good to be able to take in good ideas in real time and change direction quickly if they don't work out. *Agile development is a method of developing software by repeating planning, design, implementation, and testing in short cycles, while responding flexibly to changes. ▲Ver 0.5 (1st img) was released as a basic crafting/building area. Ver 0.8 (2nd img) expanded the area and added monsters to fight Development in a fashion similar to agile seems suitable to creating a service that includes a wide range of content, such as a sandbox game. Mori: Personally, I think it is good that our current style of development allows for changes to be made quickly, as it allows us to feel more at ease when making proposals for new things, creating an environment that allows team members to speak up without hesitation. The engineers can more easily suggest that the specifications be changed a certain way, and conversely, the planners can easily discuss how they would like specifications to be made. Kai: One of the characteristics of our development team is that when each member decides on content for the sandbox game, the engineers also provide a lot of input to the planners. Content is typically decided through mutual discussion. I believe this style of development is why we are able to make such an effort. Having released the current sandbox game version, what are your thoughts on the response from users and hololive talent streams? Mori: When I look at the industry, there doesn't seem to be many people with experience in making solid sandbox games, and I myself was also new to this genre so I considered many possibilities while working on the game. But when we actually released the sandbox game I was pleasantly surprised that the number of players exceeded expectations at this stage (laughs). In other genres, users are often asked to play according to quests prepared by the developers, but in this sandbox genre, users are free to discover their own way to play - so they can spend all their time fighting monsters or just crafting. The game is designed for a variety of play styles, and we felt it necessary to design the game so that players can enjoy it without issues regardless of how they engage with it. ▲Mansion built by users in a team member's room open to the public Is there anything in particular you think went really well? Mori: As a result of users really getting into the sandbox game, they have already created buildings and structures that exceeded our own expectations. When I see buildings that I would never have thought of myself, I know people must be enjoying the game. I'm also concerned with focusing on creating with consideration for scenes and experiences that provide great highlights for those who wish to do streaming in the future. For example, in one of the hololive talent streams a house was attacked and destroyed by wolves, which is the kind of thing we are aiming for. Thinking back to this, we hope to keep creating something that will be a satisfying experience to everyone in the future. How about you, Kai-san Kai: I feel we successfully optimized the multiplayer experience. The Holoearth sandbox game is currently available for up to 20 players in a single room, and when hololive talents were streaming with fans in a full room, all of us on the engineering team were impressed to see how smoothly everyone played without lag issues. We will continue to focus on optimizing for a seamless multiplayer experience so everyone can enjoy the sandbox game even more in the future. Any closing thoughts for us? Mori: Thankfully, many people are enjoying the sandbox game we created so far. We would like to continue developing the game so that it can be enjoyed even more in the future, so we are grateful to hear any feedback on what everyone likes and what could be improved! Kai: I would like to just briefly speak to the environment of the team here. While the development environment for Holoearth is indeed very challenging, we are able to work on things that haven't really been seen or done before. Everyone on the team has a say in what would improve Holoearth, so it is a team effort in making something we want.

Author introduction "Yukihiro Nishine" Position: Engineering Dept. Manager Date joined: October, 2023 Industry experience: 11 years of development and admin experience in web services and online games, mostly as a C# server-side engineer. Yukihiro has been the recipient of the Microsoft MVP for Developer Technologies award (2020 - 2022). Hi everyone, my name is Yukihiro Nishine and I’m a manager in the Holoearth engineering team. When speaking of Holoearth’s development, it likely conjures images of the Unity-based client-side implementation, the avatar system, or concert events and the like. But this time around I would like to speak to some of the server-side technology that we put to use. I hope this will be interesting for those of you who are interested in the behind-the-scenes development of Holoearth. Contents ・Programming Languages Used ・Cloud Environment and Tools ・About Cloudflare ・Final Thoughts Programming Languages Used We primarily use Go, with a handful of other languages as well including PHP, C#, TypeScript, and Rust. Rather than a single application, the Holoearth servers are composed of multiple applications that each use a different language. ▼Application segmentation ・Sandbox game ・Lobby (Entrance Hall, Alternative City, etc.) ・Infrastructure for account management, payments, etc. ・Others The server side of the initial sandbox game development was done in PHP. From there, the communication lobby and underlying system was made with Go, and currently Go is the primary server-side language being used. On the other hand, the other languages not used until this point may be used when the appropriate case calls for it. For example, a new system being developed requires in-game logic to be handled in real-time by the server side, so by using C# on the server side as well we can ensure the developers working in Unity can develop the client side in lockstep with the server side. As for other languages, we use TypeScript in Cloudflare’s FaaS (Cloudflare Workers), which works in conjunction with Cloudflare resources, and Rust is used in the communication infrastructure that is currently in development. Cloud Environment and Tools The Holoearth cloud environment predominantly uses AWS, of which the main services utilized include EKS, ECS, EC2, Lambda, Aurora, DynamoDB, and ElastiCache. For storage and CDN we do also use S3 and CloudFront, however, to reduce costs we moved much of this to Cloudflare. For monitoring tools we use Datadog, and Snowflake is our platform for data analytics. COVER may not be a web services and game specialty company, but we are establishing a development environment that can go toe-to-toe with such companies in the industry. About Cloudflare Cloudflare was initially well-known as a CDN service, but these days it offers a range of different services. Holoearth migrated its CDN needs over to Cloudflare to make use of its ecosystem. Besides its CDN service, we are also utilizing Cloudflare Stream, Cloudflare Images, and Cloudflare Workers, among others. In particular, we make heavy use of Cloudflare Stream. The video streaming rooms we made available to users during New Year’s and hololive EXPO were made possible by Cloudflare Stream. I was actually first introduced to using Cloudflare Stream after joining COVER, and I was amazed at both how easy and cost-effective it is to implement video streaming. For those of you interested in video streaming development I definitely recommend giving it a try. Final Thoughts That wraps it up for a brief introduction to Holoearth’s server-side technology stack, which until now hasn’t really been revealed. Our own CTO, Ikko Fukuda, has previously shared that metaverse platform development is a sort of “mixed martial art concerning the world,” which is spot on. Holoearth development is not always straightforward, but that is precisely what makes working on it as an engineer such a rewarding experience. Thank you for reading, and we hope you continue to follow the story of Holoearth’s development!

Author introduction "Shoichiro Inoue" Position: Engineering Dept. Client Team Date joined: February, 2021 Industry experience: Three years Getting Started Hi everyone, my name is Shoichiro Inoue from Holoearth's engineering client team. I'm mainly responsible for implementing the building mechanics in Holoearth. Many games in recent years have included building and housing mechanics, and windows are an integral part of this kind of mechanic. However, in many games windows can only be placed in specific places, such as on a wall with a hole specifically made for window placement - but we want to place windows wherever! I'll introduce the solution we worked out for this problem in this development blog. But first, here's a short video demonstrating the end result. https://holoearth.com/wp-content/uploads/2024/04/mado_setti.mp4 As you can see in the video, it is possible to freely place a window wherever you want! The part of the wall where a window is placed disappears, revealing the outside. But in addition, it is also possible to cut a hole in the wall's collider as well. This allows for the possibility in the future to have battles where, say, arrows can be shot through windows that were installed. Here, I explain the process of how we approached the problem. Solving the Problem Requirements The wall has to be in place first to install a window, the window must be installed such that it's flush with the wall, and the window's rotation must adjust automatically to the proper orientation with respect to the wall. I won't go into detail about this part. The window "prefab" must include the following information: Collider (to use collisions to detect which wall it is being placed on) Window width and height Workflow 1. The window contains a collider and retrieves which wall it is to be placed on. 2. When colliding with a wall, the window passes its position and size data to the wall and requests to make a hole there. 3. The wall in question executes scripts to change its shader and collider values to create the hole. And if the window is destroyed it asks the wall to restore those values. I'll talk about the shader that creates the appearance of a hole and the script that makes a hole in the collider later on. So far the scope of this mechanic is limited as follows: It doesn't take into account how the window's edge protrudes from the wall, so we use raycasts to make sure all four window corners are on the same wall. It can't allow for multiple windows on a single wall, so if a second window is added it will destroy the first window. Using Shaders to Make the Window's Appearance In essence, the wall's shader will not render where the window's coordinates overlap the part of the wall being rendered. This means the sides of the model will be empty, revealing the reverse side of the wall's mesh, but this is covered by the 3D model of the window frame on the sides of the window. (Left: Wall being overlapped by a window is removed by the shader. Right: Placing a window frame over the removed portion.) A surface shader is created to grab the coordinates of what is being drawn. The window's center coordinate and size (width, height) are obtained from its script. Making Calculations We split the problem into the two parts below. 1. Whether the coordinates being drawn are in the window on the horizontal plane, and 2. Whether the coordinates being drawn vertically are in the window. 1. Horizontal plane We make a line on the x-z plane using the formula: z = kx + b. Let k be the slope of the line perpendicular to the window when viewed from directly above. Then there are two lines, b, which are the lines passing through the front and back edges of the window, respectively. Let us denote them as b1 and b2. There's no need to draw within the yellow area bounded by lines z = kx + b1 and z = kx + b2. That is, if the coordinates we are drawing now are x1, y1, and z1: kx1+b1 < z1 < kx1+b2 Then the coordinate is in the window on the horizontal. *k can be obtained from the window's y-axis rotation = rotY. *Since the tan of 0 is undefined, we need to set up a branch process to avoid specifying 0 as the argument of the tan function. k = tan(rotY/180f * π + 0.5π) *b1, b2 can be obtained from the coordinates of both ends of the window b = z / kx 2. Vertical Direction Now, the Y axis: In Holoearth, the window rotates only on the Y-axis, so the equation is simple. _windowBottomY < position.y < _windowTopY We know that we are in a window in the vertical direction if the above is true *The _windowBottomY and _windowTopY can be obtained by adding the window width to the window center point Y coordinate. Taking all the above into account the code looks like this: bool isInsideWindow(Vector3 pos) // pos: world coords of point to be drawn { 　　// Is in window on x-z plane 　　var isInsideXZ = _k * pos.x + _b1 < pos.z && pos.z < _k * pos.x + _b2; 　 // Height is within window 　　var isInsideY = _windowBottomY < pos.y && pos.y < _windowTopY; 　　return isInsideXZ && isInsideY; } *The actual shader was created by the same team. They are modified and shown here for clarity. *To reduce processing loads, _k, _b1, _b2, _windowTopY, and _windowBottomY are calculated when the window is placed. Future Endeavors Right now this can't support shapes other than rectangles. To accommodate other shapes, the area of that shape needs to be calculated. For example, a circular window can be implemented by projecting the drawing coordinates onto the x-y plane and then making sure the distance between the point being rendered and the center point is less than the radius of that circle. Making Openings in Colliders Now I'll explain more about creating an actual hole, rather than just in appearance. The wall collider consists of a single box collider. The original collider is replaced by four box colliders to avoid the window part, each of which is divided to avoid the window section to represent a hole in the wall. The way to do it is pretty simple: we attach a new four-box collider after deleting the original collider, which requires computing the center coordinates and size of each collider. This will result in the following variables: A 3-dimensional vector (vector3) for the size of the wall, wallSize Relative coordinates of the window to the wall in another vector3, windowCenter Length of one side of the window in a vector2, windowSize The actual calculation is as follows: *The collider is a local coordinate system, so rotation doesn't need to be considered. *The origin of the wall is at the center of the bottom surface, and the origin of the window is at the center of the length and width ▼Upper collider var sizeX = wallSize.x; var sizeY = wallSize.y - (windowCenter.y + windowSize.y); var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = 0f; var posY = wallSize.y - sizeY/2f; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼Lower collider var sizeX = wallSize.x; var sizeY = windowCenter.y - windowSize.y/2f; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = 0f; var posY = sizeY /2f; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼Left collider (The x-axis is zero at the center of the wall, so the coordinate of the left end of the wall is -wallSize.x / 2f) var sizeX = - wallSize.x/2f + windowCenter.x - windowSize.x/2f; var sizeY = windowSize.y; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = -windowSize.x/2f + sizeX/2f; var posY = windowCenter.y; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼Right Collider var sizeX = wallSize.x/2f - (wallCenter.x + wallSize.x/2f); var sizeY = windowSize.y; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = wallSize.x/2f - sizeX/2f; var posY = windowCenter.y; var colCenter = new Vector3(posX , posY, windowSize.z/2f); Set these values to position the collider so that it doesn't cover the window area. Future Endeavors With the process described here, it is difficult to make holes in the collider with non-rectangular shapes. At the moment windows of different shapes can't be made, but there are possible ways to accomplish this: Increasing the number of box colliders and arranging them like an integral, which could make shapes really close to circles and triangles. But this drastically increases the number of box colliders as accuracy increases. Preparing colliders with triangular or circular holes in advance. After making holes in a rectangle, place these prepared colliders inside the holes. It takes time and effort to prepare colliders with special shapes, but it might reduce the number of colliders necessary. Final Thoughts The combination of shaders and collider management allows us to create an experience where windows can be placed freely on walls! We hope to create more and more awesome building features! If you're interested, definitely give it a try in Holoearth!