콘텐츠로 건너뛰기

Lineage2m Unreal Engine Announcement of use cases.

Written by JP.Lee
心动的 Technical Art team leader.

Epic game UnrealSubmit 2019 .

Lineage2m UnrealEngine Announcement of use cases.


Presentation: Jonghyun Kim, Client General Manager.

Theorem: JP.Lee


Observe the contents and organize the context more easily.

Using Lineage 2M Unreal Engine4.

This was announced before the completion of development.

I hope you will listen with comfortable heart.

Briefly introduce the Contents.

About the project and why we chose Unreal Engine.

I will talk about how we chose ue4 in this project and overcame the challenges we faced in a number of directions that we are worried about using Unreal Engine.

Speaker introduction.

Jong-Hyun Kim, 20 years of experience, and head of Lineage 2M’s client division.

Brief project team introduction.

We will exclude game content.

The big technical feature is the seamless open world game of a single channel server.

It is a server technical story, but it should be implemented so that 1,000 to 1,000 people can fight in one channel in one single channel without being serviced in multiple channels.

Actually, 10 km * 10 km of terrain must be implemented and seamless.

The average age of the programmer team is 37.7 years old.

Motivation to choose Unreal Engine.

Originally Lineage 2 used Unreal 2.

There is no reason to use Unreal in the sequel, but using Unreal Engine in context seemed justified.

The best thing about Unreal Engine is that it is open source.

In the case of Unity, you can’t see the source inside the engine, but if you pay about 1 billion won in license fees, you can also view the source code.

There are a lot of problems in development, but there is no promise even if you go to the Internet or make a request to the support team.

The main reason I chose Unreal Engine was because I could see the source code.

The vast source code is so large that I can’t see it all, but the fact that I can see the source code in my field was also the biggest advantage.

I had to build a big open world that I talked about earlier, but the landscape toolset has been good from the past, and the continuously updated World Composer also had a great influence on the technical choices that would be good when constructing a seamless world.

Next, I will talk about the challenges, anguish, and worries that occurred after choosing Unreal Engine.

The first thing I worried about after selecting one day was to select people.

The project started a year and a half ago.

Good developers don’t blame tools. There is a saying.

I felt this was definitely true.

At that time, few people had ever developed mobile games with Unreal Engine.

In the process of finding people, most of the good people used Unity, but they had never used Unreal Engine before, but after joining, they all adapted to the development of Unreal Engine and were able to proceed without any problems.

After all, a good developer quickly adapts to any engine.

Apparently you have to be lucky when you get someone.

What I was worried about next.

Will the engine be modified?

Because it is an open source concept, there is a point that you can view the source code and make changes, but it is different from being able to make changes and developing while making real changes.

Once you start modifying the engine, there will be a tons of extra work to keep pace with engine updates.

That’s why it will be a part of worry.

We have established a policy internally that only allows minimal modifications.

However, if you look at the engine source, it is natural that there will be a desire to fix the source.

For example, while using the engine API, some functions or variables are blocked privately (why I don’t know why …), so I think that you can use them conveniently by turning off one of them.

As you work, it is easy to overflow the vastly modified sources if you start to touch the engine source once.

However, I think that controlling such desires is one of the best ways to use Unreal Engine well.

Build and deploy.

Either way, the engine has been modified, so we need to build and deploy it.

There are two methods, the source build distribution method and the installed shield distribution method.

We chosen the install build method.

Since the number of people is put into the MMO development system, stability is adopted rather than deployment speed.

Build using Unreal’s XGE.

If you don’t use this, the development speed will drop too much, so please use XGE.

Shader compilation is 100 times faster.

Be sure to use Shared DDC.


The CI tool is a must.

However, Jenkins is not recommended. It wasn’t good for mental health, except it was free.

Just pay for tools like Team City.

It really eases.

Version update?

The update will be sent to you by e-mail every time it’s time.

If you look at the contents, a lot of good things are updated, so there is an urge to update.

But be patient.

If the major build has been updated, do not update it immediately, but wait a week or two, and if the hotfix version of the major build update comes up, then it is not too late to update.

In practice, if the major version goes up, do not update it, but evaluate the update function separately.

If it works normally, the next update point is reviewed.

It is decided to update our development team’s policy in ~.3 increments.

Simple retrospective.

We started out with version Unreal Engine 4.17.

There was a 4.19 version of the landscape LOD or such improvements, but there were many updates in Unreal Engine 4.20 and Unreal Engine 4.21.

There have been many updates since the release of Fortnite.

The above two versions of the mobile game part have been updated a lot.

However, as you can see if you actually update it, it was bothering me because it was too much.


Let’s briefly talk about PBR.

The goal was to show that the PBR was properly implemented on mobile.

In the figure above, the left is a version of Unreal Engine 4.17 shader that we directly modified to meet the needs of the art team, and the right is the result of applying ES-3.1’s unreal engine’s pure mobile shader.

If you look at the two images, the general public may not know well, but if you look closely, there is a lot of difference in the light processing part.

The pure version of the shader (on the right) was handled a bit briefly, so the light processing was not correct.

All of the things that blur lightly or disappear from the dark areas have been improved.

There are big differences between OpenGLS-2.x and OpenGLS-3.1.

In OpenGL-2.x, I couldn’t express the desired result, so I was worried.

At this time, we had a lot of discussions with the executives and business departments of our company, and we came to a good conclusion, and boldly abandoned gles-2.x and took the direction toward high-end mobile hardware.

  • Upgraded the ES-2.x level mobile shader to the level that makes the most of ES-3.1.
  • The result of working in Substance is set as close as possible to the state shown in the game.
  • Basic and common materials are made as simple as possible.

An important point when using PBR is that it should be used as simple as possible, rather than using different types of materials.

  • Buy real-world art assets like MegaScan as much as possible.
  • Engine programmers can help, but the art team’s understanding and skills are important.

In my opinion, the better you use PBR, the less shader programs have to do.

The left is a Unreal Engine 4.17 PBR mobile shader without modification and the right is a Lineage2M PBR shader we modified.

The texture resolution of both results is the same.

Based on this version, after consulting with art directors and art team members, Engine team got feedback that it is okay to proceed with development, and I started to develop in earnest.

At the time of Unreal Engine 4.17, there were many problems because the feature level was not saved.

It is mostly updated now.

I made this part myself.

Modifications due to limitations of Landscape Layer and development of additional shaders that were not available at the time.

The SSAO part, which is difficult to use in mobile games, has been optimized and developed as an option.

And don’t use lightmaps.

In the open field, the effect of light maps was insignificant, and when considering shader capacity or other factors, we decided to develop without light maps.

At the time of development, however, there was a lot of controversy over what to do with the lighting effect of the dungeon. At first, I thought to use a light map in the dungeon development part, but I decided not to use the light map because the development process was complicated.

However, this part has been implemented so that developers and artists can get similar effects without a light map by thinking and worrying a lot.

Since our game is a wide open world, the LandScape quality had to be good.

The goal was to secure a wide field of view like the screen you see now.

The field of view is about 1.5 km.

Normally, I didn’t use Landscape very well in other projects.

However, we used Landscape and now many updates are enough.

have a big world, but usuall user have to move to teleport eventually, but I have to handle the loading part well.

Our company’s request was to eliminate loading from the game.

If you think about it again, you will get rid of the feeling of loading.

To do this, break the loaded unit into pieces, most importantly.

However, since it is a wide world, it is difficult to work with it.

This part must be able to be automated.

In addition, although World Composition does not usually do much, it is necessary to automatically process the fragmented data when developing Open World.

For reference, there is a problem in the persistent level part, and switching to a new persistent level is very expensive in a mobile game environment.

So we chose to create one root persistence level and use the rest of the data by loading the asset inside.

It’s a summary of the blueprint.

It is a personal idea.

Blueprint is a catastrophe.

  • Difficulty in collaboration.
  • Difficult to structure.
  • Bad readability.
  • Programmers hate it.

Blueprint 는 축복.

  • Easy access for everyone.
  • Fast compilation speed.
  • Fast development cycle.
  • Game designer will like it.

So, as a policy, Blueprint was used to a minimum.

Essentially used BP was used (there are BPs that must be used such as ANIM BP or Widget BP).

I didn’t even want to use it personally at all.

If there is a situation to write, I decided not to add complicated logic.

I only use it occasionally to prototype features quickly, but rarely.

It is only used in minimal terms as a policy, except when adding simple tools or simply implementing prototyping.

We chose this policy, but the situation is different for each team, so each team can make a judgment that suits the situation.

The official support of Unreal Engine is C ++ 14

In our case, 14, but the latest specifications did not go well with Unreal Engine.

For example, if you compile in Visual Studio, it works well. When compiling in GCC or CLANG, there were a lot of problems that couldn’t be done anywhere, especially the template aspect.

So we decided not to use the latest C ++ Standard as a policy.

In Unreal Engine 4.21, STL was rarely used, it was used only in the experimental class, and almost STL was removed at build time.

In conclusion, it was decided not to use STL.

If you have to use STL, you should connect the locator to the Unreal Engine memory manager correctly, so there will be no problem.

I talked about the update history a while ago, but after the success of Fortnite, a lot of updates were made in the mobile part.

The engine has also improved performance, but the hardware has evolved a lot in a short time.

The software may slow down depending on how you use it, but the hardware is fast enough to be trusted.

I still have no choice but to compare the Android phone with the iPhone, but the iPhone’s hardware performance is good.

Even this was acknowledged by Samsung Galaxy phone developers.

The iPhone is better for the OS as well as the hardware.

However, Android developers are also trying to upgrade it as stably as the iPhone.

In general

Since Unreal Engine 4.21, it can be said that it is certainly a useful engine for mobile game development.

Before this, I think Unity was very lite in the mobile field, but I would like to remark that it has become a good enough engine in mobile game development after Unreal Engine 4.21.

This presentation was made with reference to the contents announced by the NC-Soft Lineage 2M development team at the Epic game Unreal-Submit 2019 announced in April 2019.

The latest updates from Unreal Engine are not included.

End of content.


댓글 남기기

%d 블로거가 이것을 좋아합니다: