RE ENGINE Philosophy English Edition

832 Views

November 27, 23

スライド概要

■Overview
RE ENGINE has been in development for nearly 10 years now and has been used in many Capcom titles. This presentation will briefly review its development history and touch on the culture of RE ENGINE development.

We will introduce some of what goes into game engine development, including development systems and initiatives that are in place to support game development at Capcom, as well as, how we communicate with game developers.

Note: This is the contents of the publicly available CAPCOM Open Conference Professional RE:2023 videos, converted to slideshows, with some minor modifications.

■Prerequisites
No special skills are required.

I'll show you just a little bit of the content !
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CAPCOM Open Conference Professional RE:2023
https://www.capcom-games.com/coc/2023/

Check the official Twitter for the latest information on CAPCOM R&D !
https://twitter.com/capcom_randd
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Microsoft, Windows, and Microsoft Teams are trademarks or registered trademarks of Microsoft Corporation in the United States and other countries.
Screenshots of Microsoft products are used with permission from Microsoft.

Python® is registered trademarks or trademarks of Python Software Foundation.

profile-image

株式会社カプコンが誇るゲームエンジン「RE ENGINE」を開発している技術研究統括によるカプコン公式アカウントです。 これまでの技術カンファレンスなどで行った講演資料を公開しています。 【CAPCOM オープンカンファレンス プロフェッショナル RE:2023】  https://www.capcom-games.com/coc/2023/ 【CAPCOM オープンカンファレンス RE:2022】  https://www.capcom.co.jp/RE2022/ 【CAPCOM オープンカンファレンス RE:2019】  http://www.capcom.co.jp/RE2019/

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

RE ENGINE Philosophy I will now begin my presentation on RE ENGINE Philosophy. ---Microsoft, Windows, and Microsoft Teams are trademarks or registered trademarks of Microsoft Corporation in the United States and other countries. Screenshots of Microsoft products are used with permission from Microsoft. Python® is registered trademarks or trademarks of Python Software Foundation. ©CAPCOM 1

2.

Table of Contents • History of RE ENGINE • RE ENGINE Development Structure • Role of the Management Unit • RE ENGINE Development Workflow • Final Thoughts The content of this lecture is as shown. 1 ©CAPCOM 2

3.

History of RE ENGINE Let us begin with a brief review of the history of RE ENGINE. 2 ©CAPCOM 3

4.

History of RE ENGINE to Date 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014 Supporting more than COVID Pandemic 20 projects Development support for external subcontractors Cross-site development support Migrated code version control from SVN to Git Started supporting multiple titles RE ENGINE development begins Steadily increasing the number of RE ENGINE titles The development of RE ENGINE began in 2014. Prior to that, we had been developing and operating a game engine called MT FRAMEWORK, and in 2012 we started developing Panta 3 Rhei as a next-generation game engine. However, due to poor development efficiency, development was halted and we began building RE ENGINE while utilizing the assets of Panta Rhei. From the beginning, it was decided that RE ENGINE would be used for Resident Evil 7, so we gave top priority to implementing the features necessary for Resident Evil 7. Then in 2015, other titles were launched and we began to support multiple titles. In 2017, we moved from SVN to Git for code version control and adopted GitLab as our tool of choice. While we had been doing code reviews up until then, the tool support made code reviews easier. This allowed a culture of releasing features after code review to take root. ©CAPCOM 4

5.

History of RE ENGINE to Date 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014 Supporting more than COVID Pandemic 20 projects Development support for external subcontractors Cross-site development support Migrated code version control from SVN to Git Started supporting multiple titles RE ENGINE development begins Steadily increasing the number of RE ENGINE titles In addition, the use of RE ENGINE began to diversify in this year. Within the company, the Osaka and Tokyo offices began to collaborate. The distance between the two locations caused3some problems. It took a long time to access the server in Osaka from Tokyo when acquiring assets, but we were able to solve this problem by preparing a mirror server. We also began to provide full-fledged external support for our external partner companies. We had been providing RE ENGINE to external partner companies for the purpose of creating assets, but it was around this time that we began outsourcing game development itself. The number of titles adopted steadily increased, but the COVID pandemic began to affect engine development in early 2020. In particular, we shifted to online communication, whereas up to that point we had been using face-to-face communication primarily. And as of 2023, we have grown to support more than 20 projects simultaneously. This number includes projects that are not part of game development.Projects such as internal training and testing, but we can say that we are in a position to support that many projects at the same time. ©CAPCOM 5

6.

History of RE ENGINE to Date 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014 Lines of Code File Count 12,000,000 35,000 10,000,000 30,000 25,000 8,000,000 20,000 6,000,000 15,000 4,000,000 10,000 2,000,000 5,000 0 0 Let‘s look at the changes in repositories after the move to Git. Comparing 2017 to 2023... The number of lines of code has gone from about 4.6 million to 9.6 million, and the number 4of files from about 11,000 to 25,000. We can see that the size of the code has more than doubled in six years. ©CAPCOM 6

7.

History of RE ENGINE to Date 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014 160 Developer growth 140 120 100 80 60 Now a large group of about 150 people Started with about 20 people 40 20 0 Next, we will briefly look at the number of engine developers. We started development with about 20 people. At that time, MT FRAMEWORK was still in service and we needed more 5people for its development, so we could not allocate too many people to RE ENGINE. Also, the engine developers were not developing the engine independently, but as a section of the Resident Evil 7 development team on the same floor. We were closely involved in the development of features in accordance with the milestones of the title, sharing progress as needed. As game development using MT FRAMEWORK came to an end and new engine developers were hired, the number of team members gradually increased. We now have about 150 people, a more than seven-fold increase. In the past, most of the engine developers were working on a single floor, but since the group became so large, they are now dispersed to multiple locations. I believe that the number of developers will continue to increase in order to develop higher quality games with more advanced functions and greater efficiency. ©CAPCOM 7

8.

RE ENGINE Development Structure Next, I would like to introduce the RE ENGINE development structure. 6 ©CAPCOM 8

9.

RE ENGINE Development Structure AI CI DCC Editor Effects GUI Motion Network Physics Rendering Runtime Security Sound Timeline Tool Each one is a unit Management In RE ENGINE, each area of specialization is called a “unit.” There are various units, such as those that develop functions needed for games, or editors for editing assets, or automation and web services, etc. 7 There is also a Management Unit, which is a different type of unit. The number of people in each unit varies, ranging from 3-4 peoplein the smallest unit to 20 people in the largest unit. By the way, the unit with the largest number of employees is the Rendering Unit. Because rendering directly affects the quality of the game‘s visual appearance, there is a high demand for features to be implemented and people to implement them. ©CAPCOM 9

10.

RE ENGINE Development Structure AI CI DCC Editor Effects GUI Motion Network Physics Rendering Runtime Security Sound Timeline Tool Title A Title B Title C Etc. Management Each unit communicates directly with game developers to support development. This allows for speedy development, from specification formulation to implementation through direct consultation with the developer. 8 Each unit operates independently and has a flat structure with no hierarchical relationships. The Management Unit does not conduct development, but acts as a “jack-of-all-trades” to solve any problems that may arise for units or game developers. ©CAPCOM 10

11.

RE ENGINE Development Structure AI CI DCC Editor Effects GUI Motion Network Physics Rendering Runtime Security Sound Timeline Tool The following is a brief introduction to what each unit does. 9 ©CAPCOM 11

12.

RE ENGINE Development Structure AI • Provide the functionality necessary to realize game AI • Support development using AI knowledge The AI Unit provides functions necessary for game AI. Functions such as Navigation, FSM, and BehaviorTree. They also provide development support using AI knowledge, such as functions to assist in the placement of point cloud information. 10 ©CAPCOM 12

13.

RE ENGINE Development Structure CI • Various Automation • QA Support Tool Development • Visualization • Function development for external subcontractors The CI Unit creates and distributes engines. They automate various systems such as build check systems when title programmers commit scripts. They also develop tools for automatic installation of packages on each platform and support tools such as crash detection, which are operated by the QA team. And finally, they visualize the information obtained from these systems11 using the Web and tools. They also develop systems for external partners to use RE ENGINE, although these systems are not directly related to CI. ©CAPCOM 13

14.

RE ENGINE Development Structure DCC • Tool development for RE ENGINE • Tool development for DCC tools The DCC Unit develops tools that run on RE ENGINE. For example, an asset management tool used by artists called SDM (Scene Data Manager) as well as tools and plug-ins for various types of DCC. 12 ©CAPCOM 14

15.

RE ENGINE Development Structure Editor • Development of various editors for graphic production The Editor Unit is responsible for developing a wide range of editors for graphic creation. This includes, level design, background art creation, and material editing. 13 ©CAPCOM 15

16.

RE ENGINE Development Structure Effects • Development of functions for editors and various expressions The Effects Unit develops editors for creating effects used in games and functions for various types of expressions. 14 ©CAPCOM 16

17.

RE ENGINE Development Structure GUI • Development of functions for editors and various expressions • Per-language text management system The GUI Unit develops editors and functions for creating UI in games and systems for managing text in different languages. 15 ©CAPCOM 17

18.

RE ENGINE Development Structure Motion • Character animation • Real-time preview of motion capture The Motion Unit focuses on... Development related to character animations, such as motion blending and posture control using IK. They‘re also developing a real-time preview of motion-captured data in RE ENGINE. 16 ©CAPCOM 18

19.

RE ENGINE Development Structure Network • Development of features for multiplayer • Development of features available online • Develop networking capabilities for use in development and analysis The Network Unit focuses on... Matchmaking and friend functions required for multiplayer. Also online functions such as rankings and network storage. In addition to developing HttpClient and WebSocketClient, they're developing functions for use play data analysis. 17 ©CAPCOM 19

20.

RE ENGINE Development Structure Physics • Character etc., collision detection and solving • Various simulations The Physics Unit develops systems for character hit detection and position correction, as well as simulation functions for rigid bodies and cloths. 18 ©CAPCOM 20

21.

RE ENGINE Development Structure Rendering • Geometry • Lighting and shading • Materials • Post-processing The Rendering Unit develops various rendering functions such as geometry, lighting and shading, materials, and post-processing effects. It also provides the basis for rendering systems used by other units. 19 ©CAPCOM 21

22.

RE ENGINE Development Structure Runtime • Development of core engine functions • Wrappers for operation on each platform • Tool development, including profilers, debuggers, and packaging The Runtime Unit develops the core of the engine used by each unit, wraps different APIs for each platform to make them easier to use, and develops various tools such as profilers, script debuggers, and package creation. 20 ©CAPCOM 22

23.

RE ENGINE Development Structure Security • Development of systems to combat cheating and piracy in PC games • Develop crash reporting tools The Security Unit develops anti-cheating and anti-piracy systems for PC games, DLC, and other content. They also develop crash reporting tools to collect and investigate information when crashes occur in user environments. 21 ©CAPCOM 23

24.

RE ENGINE Development Structure Sound • Development of in-house sound engine • Audio middleware support • Various editor development The Sound Unit develops in-house sound engines for game sounds, audio middleware, and editors for sound effects. 22 ©CAPCOM 24

25.

RE ENGINE Development Structure Timeline • Key animation function development The Timeline Unit develops key animation functions, mainly for use in cutscenes. The functions are modularized and can be used by editors in other units to handle key animations. 23 ©CAPCOM 25

26.

RE ENGINE Development Structure Tool • Develop UI for the entire RE ENGINE • Development of UI parts • Providing a mechanism for tool development for game developers • Asset version management system development The Tool Unit develops the UI for RE ENGINE as a whole, as well as, UI parts used in the editor created by each unit. The unit also provides macro functions for game developers to create tools on RE ENGINE using Python and automate operations on the engine. Members of this unit also develop version control systems for assets. 24 ©CAPCOM 26

27.

RE ENGINE Development Structure Each unit also conducts research and testing That was a brief description of the main activities of each unit. For convenience, engine developers belong to one of the units, but development is sometimes conducted across units.25Each unit also conducts its own research and verification, the results of which are provided as new functions. Please refer to the other presentations at this conference to learn more about the achievements of each unit, although not all units are represented. ©CAPCOM 27

28.

Role of the Management Unit Here is a more detailed description of the Management Unit. 26 ©CAPCOM 28

29.

Role of the Management Unit Ensure engine developers and game developers can develop without delays and holdups Earlier I described the Management Unit as a “jack-of-all-trades.” Its purpose is to do what it can to help engine and game developers develop without delays. 27 ©CAPCOM 29

30.

Role of the Management Unit • "Inbox" for queries • Various clerical tasks • Formation RE ENGINE development culture The main activities are to serve as a consultation center, to listen to the problems of game developers and units and work to solve them. They also perform various administrative tasks such as organization, and to help create a culture of RE ENGINE development. 30 Next, we will introduce the RE ENGINE development culture in detail. ©CAPCOM 30

31.

RE ENGINE Development Culture • Open environment • Engine developers play a leading role • Relationships with game developers In RE ENGINE development, we emphasize the following three things. We are committed to an open environment, a leading role for the engine developers, and maintaining good relationships with the game developers. 29 ©CAPCOM 31

32.

Open Environment Chat (Microsoft Teams) is used for everyday communication Notification of automated processing results Miscellaneous Consultation First of all, we have an open environment. Capcom uses Microsoft Teams as a communication tool, and in engine development as well, we have created dedicated 30Teams and operate various channels according to their purposes. For example, there is a channel for consultation with each unit and a channel for consultation with the Management Unit, a channel for notification of automatic processing results, and a channel for general communication and general development consultation for the engine developers as a whole. While individual units communicate with each other through the channels for each unit, the general channels are also actively used for daily chat exchanges. ©CAPCOM 32

33.

Open Environment Video chat meetings We also hold weekly video chat meetings for the purpose of disseminating information and promoting communication. Although not everyone participates at all times, more than 100 people attend each meeting. For those who were unable 31to attend, the meetings are recorded for later review. Before COVID, we used to hold meetings in person, but it was problematic to find a space where everyone could gather and to take minutes, so it was a good decision to go online. Agenda items are brought in from each unit, but sometimes the Management Unit asks to share them. ©CAPCOM 33

34.

Open Environment Video chat meetings • • • • • • • Title information sharing Title schedule sharing Introduction of functions being developed by each unit Sharing of precautions and guidelines for implementation Communication of specification changes in engine development Self-introduction Setting goals for each fiscal year and reviewing at midterm and year end We cover a variety of topics in our meetings, but here are some of the main ones. Title information sharing: Although we hear about what titles are in the works within the company to some extent, there 32are not many opportunities to learn about specific game contents. Therefore, we share information obtained by the Management Unit. In some cases, the director of the game title will directly explain the contents of the game to us. Everyone is very interested and excited to hear about new games. Title scheduling: At the end of the month, we share the schedule for each title for the following month. Milestones, QA start dates, etc., are the main topics of discussion. We tend to get a lot of inquiries for engine developers before these events, so we share them in advance. Per-unit feature development introductions: We share information on what features are being developed by each unit, what features are new, and what precautions were taken in their implementation, so that other engine developers can use this information as a reference. ©CAPCOM 34

35.

Open Environment Video chat meetings • • • • • • • Title information sharing Title schedule sharing Introduction of functions being developed by each unit Sharing of precautions and guidelines for implementation Communication of specification changes in engine development Self-introduction Setting goals for each fiscal year and reviewing at midterm and year end Development rules and guidelines: We share basic information such as coding rules that engine developers should keep in mind when developing engines. Especially important matters are shared again each year. 32 Engine specification changes: When specification changes are made to the basic parts of the engine, each unit will be affected. Self-introductions: As the number of engine developers has been increasing and more people have not directly communicated with each other, self-introductions are conducted to get to know each member better. They don‘t have a fixed format, but most people share brief autobiographies, their hobbies, etc. Setting goals for each fiscal year and reviewing at midterm and year end. ©CAPCOM 35

36.

Open Environment Goal setting Mid-term review Year-end review In RE ENGINE development, each unit sets its own goals at the beginning of each fiscal year and reviews them at the mid-term and the end of the fiscal year. The goals vary, but they include: What functions are to be developed, what research is to be conducted, unit management policy, etc. 33 The engine development situation changes from moment to moment, so the goals we set may not always be achieved, But setting and sharing goals has the following advantages: Intelligence about other units' activities, and serving as a starting point for collaboration. Since we usually focus on the development of our own unit, information tends to stay within the unit. Therefore, we create opportunities to learn about other units by sharing various information at meetings. ©CAPCOM 36

37.

Open Environment Internal website for information sharing Debugging tips In-house site (RE:Dev) Guideline page Another initiative are internal sites dedicated to RE ENGINE developers. While it is sometimes okay to share temporary information at meetings, it is necessary to leave important information34 in an easy-tounderstand manner. Especially in the early stage of RE ENGINE development, the number of staff members was small, and there were many cases where information was shared only verbally. However, as the number of members increased, the number of unstated information increased and it became a problem, so we started to operate this site. The site includes: Video of meeting, outlines of each title, a setup manual for newcomers, guidelines for development such as coding rules, various tips, and pages for each unit to freely post information. This site is editable by anyone and is actively being updated on a daily basis. ©CAPCOM 37

38.

Open Environment All of this is for engine developers, but it can also be viewed by game developers The environment described so far is naturally intended for engine developers. However, there are no restrictions on viewing, so game developers can also easily view the site. 35 In fact, many game developers participate in the chat. Currently, there are about 200 game developers participating in the chat versus the 150 engine developers, so clearly many people are interested in engine development. ©CAPCOM 38

39.

Open Environment Anyone can browse RE ENGINE source code A repository of engine code is also available in-house. Game developers may obtain the code and use it to debug their games. 36 ©CAPCOM 39

40.

Open Environment Anyone can acquire the development environment of each title Any developer or game developer can acquire the development environment for any title developed with RE ENGINE. Game developers can use the assets of various titles as reference for their own games. ©CAPCOM 37 40

41.

Engine Developers Play a Leading Role Discussions between engine developers determine things Management Unit solves problems from engine developers • Consultation • Conducting surveys Next, the engine developers are the main actors. Various discussions take place in the chats I mentioned earlier. Engine specifications are also often decided through suggestions and 38 discussions in the chat. Various problems are raised on a daily basis, and the Management Unit sometimes takes countermeasures. We are often asked for advice on how to do something, and we respond to such requests. For example, when we received a comment such as, “there is not enough disk space to acquire the assets for each title,” we purchased and installed new SSDs. In addition, the Management Unit sometimes conducts various surveys of engine developers to identify hidden problems. ©CAPCOM 41

42.

Engine Developers Play a Leading Role Discussions between engine developers determine things Management Unit solves problems from engine developers • Consultation • Conducting surveys For example, when we received comments such as, “We need a place where we can easily ask for help,” we created a channel on Microsoft Teams. When we received comments such as, “It takes too long to build the engine,” or “It takes too long to convert certain assets,” we encourage the unit in charge to improve it. 38 In addition, in order to spread knowledge of useful functions that are not well known to the entire team, we have also asked for people to share tips and tricks that they might be the only person aware at meetings. The engine developers play the leading role in engine development, and the Management Unit's role is to support their development. ©CAPCOM 42

43.

Relationships with Game Developers • Game engine that fits our company's needs • Quick response time and resolutions • Accumulation of technology Next, we will discuss the relationship with game developers. There are several advantages to developing a game engine in-house. The engine can be specialized to the company‘s 39 needs, issues and requests can be dealt with quickly, and all technology developed becomes part of the company’s assets. The first two of these advantages are born from the fact that the game engine developer and the game developer can work closely together in the same company. These advantages should be maximized. ©CAPCOM 43

44.

Relationships with Game Developers Support from title startup to release Start up Development QA Release For this reason, creating a game engine is not just a matter of implementing and releasing it; it is also important to provide support for successful use. 40 We provide titles with support from the initial kick-off, throughout development, and to the release of the game. ©CAPCOM 44

45.

Relationships with Game Developers Kick-off meeting at the time the title is started Confirm: Game content Schedule Target platforms Technical challenges etc. When a new title is started, a kick-off meeting is held with key members of the title and the Management Unit. In this meeting, we will discuss the game, identify technical challenges, and provide advice on potential problems before 41 they arise. This information is shared with the engine developers. Depending on the technical challenges, the relevant unit may conduct consultation with title members directly. This is the first step in building a relationship from the early stagesof game development and facilitating subsequent support. ©CAPCOM 45

46.

Relationships with Game Developers Performance review Performance review description page Example of review results Performance reviews are then conducted at fixed points in game development. Each unit examines the performance related to the features they have provided. We look for areas that are using too much 42 memory or performance bottlenecks, and provide feedback with pointers and suggestions for improvement. ©CAPCOM 46

47.

Relationships with Game Developers Performance review Examples of improvements found This has a secondary effect. By checking how a developed function is actually used in the title, inefficient parts of the engine can be found. Of course, 43 performanceconscious implementation is done during feature development, but at that point it tends to be a simple check. Profiling the functionality used at the product level also serves as an opportunity to correct any problems found and improve the engine. ©CAPCOM 47

48.

Relationships with Game Developers Stronger performance improvement support In some cases, despite both the engine and game developers conducting performance reviews and working together to improve performance, the target performance may not be reached. 44 In such cases, the engine developer and game developer may form a group dedicated to performance improvement and work more closely together to make improvements. Together, they work on the final push to achieve the target performance without compromising quality. Up until this point, I've talked about providing direct support to games' development. ©CAPCOM 48

49.

Relationships with Game Developers Support by chat Example of an inquiry Example of communication from an engine developer We also provide support independent of the game development process and specific titles. We use Microsoft Teams for that day-to-day support as well. We operate a Teams team for game development support, 45 which over 1,300 of our game developers participate in. We receive inquiries from a wide variety of people every day, mostly questions, consultations, and bug reports, but sometimes we also chat with each other. We have created channels for each engine function and purpose, but some people are not sure which channel to post in. In such cases, we ask them to post in a general-purpose channel and assign them to the target unit as appropriate. We do not have elaborate rules on how to post, and we are conscious of not raising the threshold for inquiries. The engine developers also use the channel for various types of communication, and communication is very active. ©CAPCOM 49

50.

Relationships with Game Developers Support by chat 600 500 400 300 200 100 0 January-23 February-23 March-23 April-23 May-23 June-23 Monthly inquiry trends Here are the monthly inquiry counts for the six months from the beginning of this year until the end of June. Roughly, on average, we have received about 20 inquiries per day. 46 There are teams that have their own support systems as well, but those are not included in these counts, so the actual number of inquiries is probably a little higher. ©CAPCOM 50

51.

Relationships with Game Developers Conduct regular webinars to explain engine functions Survey content Example of a webinar RE ENGINE has a wide range of functions. We have prepared a manual, but it is difficult to say that it covers everything. For this reason, we hold webinars to introduce features, 47 tips and tricks, and other useful information on a regular basis. These webinars are open to all game developers. We don‘t keep track of how many people attend each webinar, but we have had more than 400 attend our most popular webinars. We regularly survey our participants to help us improve the information we provide. ©CAPCOM 51

52.

Relationships with Game Developers Issue • Increased number of titles and lack of detailed trend tracking Periodic status checks and interviews Direct communication with title staff As I have mentioned, we are building relationships with game developers in various ways, but it is not without its challenges. Thanks to the increasing number of titles using RE ENGINE, it has become difficult to keep track of the trends of each and 48 every title. There are cases where game developers are having issues with RE ENGINE that we don‘t know about. Therefore, we feel that we need to communicate more closely with game developers. As a way to improve communication, we are regularly checking with each title to find out what is troubling them and what they want from the engine developers, and we are trying to have engine developers on the floor of each title to communicate directly with developers. We believe that having younger engine developers visit the title floor in particular provides them with an opportunity to learn more about the game development process. ©CAPCOM 52

53.

RE ENGINE Development Workflow I will also talk about the workflow of engine development. 49 ©CAPCOM 53

54.

Development Workflow When you become an engine developer Setup instructions page I‘ll first explain the onboarding process for a new engine developer. The basic information and setup can be found on the information site, and you will be asked to build your environment 50while reading through it. Note that, as you can see in the image, the official name of RE ENGINE is mentioned at the beginning of the explanation. The correct name is RE ENGINE in all capital letters with a space after RE. The first step is to make sure that the correct name is used. ©CAPCOM 54

55.

Development Workflow Conducting training Training description page Once setup is complete, you will receive training specifically for engine developers. In this training, you will work on basic implementation issues related to the runtime, tools, and integration of the runtime 51 and tools. Code reviews are conducted for each assignment, so that the trainees can ask questions and receive pointers to deepen their understanding of the subject matter. For new hires, the volume of work is usually completed in about two to three months. We also have younger employees, mainly in their second or third year, help with the code reviews, which also serves as training for those who conduct the reviews. When employees are actually assigned to a unit, we also provide training specific to that unit's field. After this kind of training, you will start your career as an engine developer. ©CAPCOM 55

56.

Development Workflow Feature implementation flow Discussion Implementation Review Check Engine developers‘ work generally consists of getting requests from game developers and then implementing those requests, so I will introduce that process. 52 Of course, in addition to these tasks, we also conduct research and testing, and implement functions that are proposed by the engine developers, but I won't go into that here. ©CAPCOM 56

57.

Development Workflow Feature implementation flow Discussion Implementation Review Check Chat consultation example The first step is to discuss with the requester what kind of functionality they want. It is important to confirm the purpose of the project, not only to find out what functions are needed, but also what the53 requester wants to achieve. Of course, the requester has a vision of the function they want, but it may not necessarily be the most appropriate function for the purpose. By asking them about the purpose and workflow of the function, we may be able to come up with something more optimal. In such cases, the engine developer needs to make suggestions. Sometimes, existing functionality can already solve the problem, and other times, when digging deeper into the purpose, they may decide they don't actually need it. ©CAPCOM 57

58.

Development Workflow Feature implementation flow Discussion Runtime code is C++ Implementation Tool code is C# Review Check Once the content is decided, we proceed with implementation. As implementation proceeds, we will communicate with the client as necessary to confirm any details that may arise. The 54 programming languages used for development are C++ for the runtime part, and C# for the tools. ©CAPCOM 58

59.

Development Workflow Feature implementation flow Discussion Code review Implementation Review by requester Review Check Then, after implementation is complete, a review is performed. There are two types of reviews: Code review, and a review by the requester. ©CAPCOM 55 59

60.

Development Workflow Feature implementation flow Discussion Implementation Review Check Code review request screen Code reviews are generally conducted by members of the same unit, but may be requested by other units when a cross-unit feature is developed. 56 Reviewers use GitLab‘s MergeRequest function to review out code and behavior. We also use GitLab’s Pipeline function to perform build checks, and we sometimes incorporate automatic checks on a unit-by-unit basis. ©CAPCOM 60

61.

Development Workflow Feature implementation flow Discussion Implementation Review Check Experimental version creation dialog The purpose of the review by the requester is to try out and confirm that what has been created is as intended, and this is where one of RE ENGINE‘s unique mechanisms comes in. 57 You only need to specify which branch of Git you want to use to create the engine for which title, and RE ENGINE will create and provide an engine version for the check. We call this checking engine version “Experimental.” The Experimental version system was created about two years ago, but previously, we had to release the feature once to check it with the client. In the early stages of implementation, the functionality was often unstable, and we had to re-release it many times if there were problems. Also, since the functionality was released for all titles, there was a risk that someone other than the client would accidentally use it. With the introduction of the Experimental version system, it is now easier to have people check the functionality before releasing it. This reduces the risk of misunderstandings after release, such as being told, "This isn't what I wanted!" ©CAPCOM 61

62.

Development Workflow Feature implementation flow Discussion Implementation Review Engine generation Code push Automatic generation by CI Check Check Auto-check & Manual check After the code has been reviewed and imported into the master branch, CI will automatically create the engine to be released. Once the engine is successfully created, a check is performed. 58 This check is done in two ways: automatic and manual. In the automatic check, the game is played from start to finish and checked for crashes and game progression problems. Since the automated checks are not sufficient for non-crash problems such as visual defects, manual checks are performed with the help of the QA team. ©CAPCOM 62

63.

Development Workflow Feature implementation flow Discussion Implementation All past titles must ensure that the game runs on the latest engine and compatibility must be guaranteed Review Check By the way, this check uses titles that have been released in the past. In other words, we are using the latest engine version to run titles ade with assets from the past. 59 This is because RE ENGINE has a policy that all past titles must run on the latest engine to ensure compatibility. At first glance, this may not sound so strange, but in fact, it can be very difficult. ©CAPCOM 63

64.

Development Workflow Feature implementation flow Bugs need to be fixed Discussion Implementation Review Check Title assets can be modified Title assets cannot be modified Modify assets LegacyFlag support For example, if a bug is found and fixed, the released title is still running assuming that the bug exists, and fixing it might change the behavior of the game. 60 While it is often possible to modify the program or assets of the title so that the behavior of the game itself does not change, this may not always be feasible. In such cases, it is necessary to maintain the past behavior, i.e., the bug. In this case, a flag is added to reproduce the past behavior, called a LegacyFlag. By setting the LegacyFlag to On for released titles and Off for titles under development, it is possible to switch between different behaviors. The same problem occurs not only with bug fixes, but also with specification changes. Despite these hassles, released titles are still stable on the latest engines. This allows us to check the content of previously released titles at any time, and lowers the cost of releasing titles on new platforms, making it easier to reuse assets from previous releases. ©CAPCOM 64

65.

Development Workflow Feature implementation flow Discussion Day 0 Day 1 Implementation Build with CI & check Code push Review Release Check After these checks, the feature is released. Every day in the evening, the day‘s updates are due, CI builds are performed, and a full day is spent checking. If there are 61 no problems, the feature is released that day. If it is a small feature addition, we can implement it immediately after the request and deliver it to the game developer the next day. This is our basic release flow, but occasionally a bug slips through that has a serious impact on development, such as an engine crash. In such cases, we make corrections immediately and, as a special exception, release the game on the same day without going through the checks. ©CAPCOM 65

66.

Development Workflow Feature implementation flow Discussion Implementation Review 100 90 80 70 60 50 40 30 20 10 0 Check Number of changes Including feature additions, bug fixes, and changes that do not directly affect game developers, the average number of updates is about 40 per day. 62 As you can see from the graph, there are fluctuations, but you can see that updates are actively being made on a daily basis. Incidentally, I noticed when preparing this data, but the number of updates is the lowest on Mondays, increases as the day of the week progresses, and is the highest on Fridays. ©CAPCOM 66

67.

Development Workflow Engine provided per title Engine code Engine for Title A Title A Engine For Title B Title B Engine For Title C Title C This is how we provide the engine to the titles, but let me introduce a little more about the provisioning part. As explained in the previous sections, the engine code is integrated into a single branch. However, each title uses different 63 functions, so we build and provide an engine for each title. ©CAPCOM 67

68.

Development Workflow Engine provided per title Engine for Title A Engine code Module configuration for Title A This is achieved by dividing the functionality of RE ENGINE into modules, and setting which modules are used for each title. By eliminating unnecessary modules and using only the necessary modules, unnecessary processing and memory allocation can be 64 avoided during game execution. ©CAPCOM 68

69.

Development Workflow Git branch operation Functions for Title A Functions for Title B Functions for Title C Master branch Bug fix Bug fix Title A branch Let‘s also look at it from the perspective of Git operations. Once the requests for additional functionality for the engine have been settled on the title side, the next step is to ensure 65 the stability of the engine’s operation. However, if the engine is still affected by the engine using the master branch, the engine will be provided with features for other titles. Therefore, when a title approaches the end of its development cycle, a title branch is created from the master branch. The title branch is basically used only for bug fixes to increase stability. This has been a rough introduction to the engine development process. ©CAPCOM 69

70.

Final Thoughts Now, for some closing words. 66 ©CAPCOM 70

71.

Instead of saying "The engine developer just makes the engine, and the game developer just takes it and makes the game," RE ENGINE is built with close collaboration between the engine and game developers As I have mentioned, we are making various efforts for engine development, but the most important thing is that we are working together with game developers to create RE ENGINE, rather than just having the engine developer create the engine and the game developer receive the engine and create the game. 67 The engine developer and the game developer are in constant dialogue to create a game engine that is suited to Capcom‘s games and workflow. This is the soil that Capcom’s game engines have cultivated since MT FRAMEWORK, and we believe it is something we should continue to treasure. ©CAPCOM 71

72.

That's all This concludes this lecture. Thank you very much. 68 ©CAPCOM 72