Draco X is created in this way, management method in large-scale game development



What kind of server configuration does Dragon Quest X make to achieve "one world"?So, CEDEC 2012 gave a lecture on how the server system that supports the world view of Dragon Quest X is structured, but what kind of management is needed to create a popular work called Dragon Quest Ryoma Araki belonging to the Square Enix Development Department talked about problems unique to large-scale development and ingenuity to solve it.

Title | CEDEC 2012 | Computer Entertainment Development Developers Conference
http://cedec.cesa.or.jp/2012/program/BM/C12_P0003.html

Araki Ryoma:
Today it is a dragon quest and I am truly honored to have gathered many people early in the morning. I wish I could talk about something that would bring home somehow, so thank you. So today it is a story of Dragon Quest,Yuji HoriiI wonder how many people are doing work in a way, sometimes people are expecting something like Dorakue's behind-the-scenes stuff, but I'm surprisingly doing serious management , The story will be the main.

I forgot to mention important things. In the meantime, there is a material saying "Please do not shoot for today," but since we will publish the document later, there is a page that puts the mark with the batten on the camera on the top of the right end However, regarding other things, I think that it is OK to take pictures freely. Because I think that there are also many people who are told to write reports. Rather than taking notes one time, it is easier for you to take photos with photos as it is easy to take, so it is fine even if you take pictures freely except for the pages with batmarks of this camera. Also I think that people who want to tweet on Twitter or facebook will be more and more murmuring.


First of all, I would like to introduce myself. Co., Ltd.square EnixIt is Araki Ryuma belonging to the development department. After joining another company, I joined in 2003, and the representative work is "FINAL FANTASY XII", Now it is"Dragon Quest X Awakening Five Tribal Online"I'm doing a design section manager. About "Dragon Quest X", I thought that I watched the movie today, I wonder how the game looked like, but I spoke 80 minutes on the company rehearsal. I do not have time for a moment so I would like to cut those movies. It is on sale on August 2, because it is the first online correspondence in the series, and it is praiseworthy now. Those who have not purchased yet, I hope to have it for you by all means. Since detailed information is posted to the web site, if you can go see it.

I'd like to start talking at once, but today's agenda, I think I would like to talk about feeling as you are seeing. This time we are talking about management talks from agile story to workflow etc. and various story of development management management. Method and development method, but rather than digging down the method individually, agile development ...... I talk about an example like "I'm doing this way of thinking" I hope that I can do it.


First of all, I would like to talk about the advantages and disadvantages of large-scale development. Dragon Quest and others FINAL FANTASY seems to be similar, but I will say "Triple A Title", but people of various professions are professional crystals involved in production. The triple A title provides the world feel and play to other customers, which is unprecedented by other companies, so the volume tends to increase for production by all means. Also, the evolution of technology in recent years, the extent of specialty fields, the resources to implement and implement in order to realize that tend to become large scale by all means. So, when the development organization becomes large scale, it will be difficult to get the performance as many people as possible. In terms of image, it is the impression that he will not be the number of people that can be grasped and handled by one person if he / Then it becomes the organizational framework and the ruling, these things become necessary. As it goes beyond 100 people, it becomes difficult even in the part of communication and consensus of production, so that it becomes difficult for the staff to proceed with work while grasping the whole of the project on the project scale think.


Problems that arise at such times include delays due to inconsistency or cognitive mismatch due to the inability to share the schedule or goals of the project, delays caused by differences in discrepancies or perceptions, staff dissatisfaction due to internal circumstances of the project, There are a variety of problems that arise. Risk hedging against risks that can occur with such large scale, risk avoidance, ingenuity to do that becomes very essential. By introducing methods and devising team management, it is the manager 's job to prevent or prevent such problems from occurring in advance. Today, in order to realize what "method is to develop lightly in large-scale development, to develop flexibly," to realize what we are, we are working with a combination of several methods, and to the management in general through this work I think that we would like to send together the idea as well as the consideration including the points that I had difficulties. So I will proceed with Dragon Quest X's project management.


First of all, I will introduce you to Zakkuri about the development system and organization.


This is the feeling that I'm working on an organization like this in general, but it seems to me that probably it does not change with other companies. The part surrounded by the red frame of the screen is the part where I manage management directly. As an organization, there are programmers, artists, game designers and other producers, directors, and people with a wide variety of other occupations doing it .... When I explain the difficult part to understand, "VW" is written in the company's CG movie special groupVisual WorksHe is making an opening movie. It is a programmer I am managing "GFX", but this is a drawing program. "Character" is making a character, but regarding "motion"NPCAnd monsters and others, including the motion of facials, and also like technical artists belong to motion for the sake of convenience. About "cut scene", it is a real-time event operation. It will be a work making full use of the storyboard, camera work, motion. About "3DBG" 3D background ...... This time we are making MMO so that we can make quite extensive map. I think that we want to talk about things like the problems that occurred around that. As for the "effect" and "BG art" as it is, as for the "menu", it is a UI artist. I am making it with such an organization. In this, I feel that it is managing the progress of the project and making decisions such as organizing the situation. I am doing work resolution building and maintenance, problem solving and coordination which occurred between these parts so that production is smoothly carried out in a divisionalized work. From the objective point of view, we will also take a look at the balance of the products, and we will also choose to pick out what we implement as it progresses in production.

After knowing the premise such as, I would like to move on to the story about development method and method. The story about Agile development is becoming the main, though agile method is originally a method suitable for small scale development, but in recent years high-end graphics and MMO game development projects can become large scale Because it is often used, in this work, I devise a method using several methods. So, first of all, I would like to begin to talk about such things after getting to know about how to treat personal things in the first place.

Although it is about agile, I am doing a broad-ranging way of thinking, I am thinking that it is a method prescribing specifications while making it and assuming it to change in the middle.


In short, it is a development method for uncertain things, especially as games are implemented, and adjustment is repeated to improve quality, I think that the affinity is basically high. In other words, Agile refers narrowly to some methods themselves, but here today we are going to develop a broad sense of "uncertain things with how to feel good while keeping the risk to a minimum" I will call it Agile in such a way that it looks like "?" In particular, the greater the scale of development, the more uncertainty will be raised. The uncertainty is the largest at the beginning and can gradually be reduced proportionally as time progresses, but how to keep this risk to a minimum is the focus of management.


So we will talk about hybrid management. This time we manage the management with four major points, so I will introduce it. Introduction It is a story saying "We manage progress at 15 minutes everyday meeting", in short, I will refer to Scrum.


As I have already understood many things, as a common problem in development, for example, bugs and demands born day by day, new requests born on a daily basis will put pressure on the original task, I think that there are problems such as staffs themselves putting their hands on tasks that are easy to undertake, important ones will be postponed, and afterwards, hands are put on first from the point where the voice is large. If you do not handle these situations, such things will happen, such as being unprecedented and being troubled, "Would you like to proceed with a misunderstanding?"


Daily development As we adapt and control flexibly to the changing circumstances, we need timely and thorough consensus to be able to sense it. The situation changes from moment to moment on a daily basis. It means that we will respond flexibly to changing circumstances by grasping the situation, controlling and managing the situation at about 15 minutes each day. As a point, it is important that it is important not to spare these troubles every day, and after thatIterationI think that it is a milestone, but I think that it is also a point that we decide our goals firmly in that and manage daily activities.

Although it says "a morning meeting", I feel that collecting people as much as 15 minutes to 20 minutes every morning and doing a public meeting, well a scrum meeting for each section. Sometimes I sit down and do something with standing, but if you have not already done so, I think that it would be better to do it with standing. Because I think that it is the feeling that only the minimum necessary story is made when doing with standing, but as I sit down, I develop into various stories and I will start talking quite carefully. So, if you do, you should do it with standing. I am sitting in the photo above, but for some reason, I'm talking while projecting a progress Gantt chart on the projector where I do not see it on the screen. I sometimes do something in such cases. That's about Scrum.

Next, "task management based on priority", this isKano ModelI am referring to the idea.


We will prioritize by assigning ranking to categories such as "If you do not want to implement", "Not complaining if you do not have" or "Better if you have one". Then you will see the difference between what is mast and what is not. Regarding this judgment criterion, it is important for the director to understand what the director wants to realize, and make judgments based on it. To some extent, the managers do handling, but something about the big direction of the project may be asked directly by the director or the art director. As a point about this, we will clarify the process to the last and adjust the disconnection at the time before entering mass production, so that we can focus on what we really need . And as for ideas and additional requests that will come out afterwards, if priority is known in the existing task, it is easier to pick out such things. As for this, we are managing the tasks in the database and there are bug management systems made in-house, but we use that to manage the tasks. In this, I write the title of the task and degree of advancement and retraction, and there is another item called priority, so we take the form of placing an order with that priority. It was supposed to be seen on the web base, it is possible to see it by looking at the list, seeing the priority, squeezing it by iteration and checking it, and so on.

Next, I will talk about "risk hedging with buffer control". This is a critical chain project management,CCPMWe refer to what is called. As a possible problem, there are problems such as not finishing according to the schedule, being managed accordingly every time a problem occurs, or forcibly putting it on the schedule, the result, in the first place, the aimed quality could not be achieved However, as such a cause, is not it that it is not a schedule drawn on the scratch?


As a cause of such scrutiny of implementation tasks as a schedule, there is no assumption of returning bugs or anything in the first place, hiding more than what can be done in the period, and all the planned things are implemented I think that you think that it is FIX when it is done. Although it seems to be a common problem, in order to avoid such risks, CCPM is adopted. This method is to estimate the task with two points and have a buffer.


As for the estimate, we estimate at the shortest and longest two points. Although it is a viewpoint of the estimate, the number of days for implementation itself is the shortest, including rework and adjustment, bug fixes, etc. Maximizes the number of days such as "This will be possible". The difference between the minimum and the maximum is called a buffer. Programmers are such implementations, but in the case of artists it is the shortest until they are produced and checked for the first check, "If it is about this, you can do it to the quality you can ship" It is making things the maximum. Although we will look at the buffer of that difference, we calculate the buffer for each task, but we do not manage individual buffers individually but manage by buffers for each iteration . By doing so, you can see the sign of the warning that you must reschedule (reschedule, change budget) by how much that summed buffer has decreased. Then you will be able to sense the rescue in advance and take action, so that it will be calm and consistent progress when problems and irregularities occur. In other words, we are doing risk management with buffer management.

What kind of management actually is done, but the blue line is the actual working days. The orange line is one buffer, and the sum of the buffers is the last one. The red line initially has the same capacity as the buffer, but if the task shifts or lags, the red line will feel less and less compared to the orange line. Depending on how much this red line has decreased, you can also judge how much the project or its team is approaching the crisis about the schedule.


When this red line becomes zero, it is late as you are taking countermeasures, so if you have reduced to about half or two thirds then you have to take some measures or you have to postpone the schedule I am starting to talk as if I should not have it, I want to add personnel, I need to organize implementation requests, and so on. This management is to disassemble each task in this way and see the buffer all together, but I think if it is done for all the schedules up to the master, it is very difficult. So in the case of this work, this management is done by iteration. Iteration is every milestone. Every time the iteration ends, we also rework and reevaluate items like implementation requests, so we are doing the operation with the feeling that this management should be done firmly in iteration.

On the line drawing of the actual drawing programmer, tasks are roughly written and there are a number of MS projects that I do not know, but in the end they are consolidated at the buffer management line at the top right By doing that, I try to understand how much the crisis is approaching. Although it is management of this MS project, it is like updating to some extent in the place of exporting to the CSV file from the task DB you saw earlier and importing it.

It is like feeling like that mainly adopting three methods. Also, it is not a method, but there is another big point. About roadmap operation.


This time, the project plan is grasped entirely by the rough road map. The roadmap is that there is a rough writing about who is doing what items on a monthly basis. In large-scale development, always aware of the process leading up to the goal is very important. As for the operation of the roadmap this time, we are going to proceed while rewriting according to the circumstances, unlike ordinary ones. We are operating a roadmap based on the idea that when a large rescale or change occurs, a framework for not easily adding periods and personnel, or reducing it. This table is written on a person basis, and it is a feeling that which place, what period, what work and what period to do in the period is written by month. The timing of the movement of the staff is also checked here. If there is a big change in the project, we will advance the task while checking the plan again with this road map. As a point, we manage buffers here as well. Regarding here, it is to make a risk hedge of the project by having a buffer on this whole road map. If judgment is necessary, we also escalate to the top while watching the degree of reduction of the buffer that how much hazard is likely to occur. However, since the project is proceeding with securing a certain amount of buffer, even if there is some misalignment, the manager can handle the project smoothly to some extent at the hands of the manager without consulting with the producer or the director It has become a kind of thing.

So, if there is something wrong, I will of course make adjustments in big places, but of course it is time to show off to the staff on the latest schedule, as I said before, I will manage it by iteration Because it is, there is a thing that becomes uneasy in such a place as whether it is the end if the present work ends up until this point, or the schedule that will last forever if you see staff only every day there.

In such a place, I feel that it is very important to have a road map even in the sense that the staff will know the schedule of the previous one. As a matter of fact, there are not many people actually going to look at the roadmap actually while looking at it many times, but if there is a roadmap and the whole process is clear, it will play the role of something like security I also do. However, as a reflection point on doing the project this time, there are sections where the roadmap was opened to the staff by section, there are sections that are not so, I feel that there was a big difference in progress I will. Regarding the section on which the task was advanced day by day while exposing the roadmap, although it advanced relatively calmly without any problems, as for the section where it is still difficult to understand somewhere that the target is somewhat dissatisfied, There was a big difference in terms of going up. As for why we did not disclose to the staff regarding the road map, it seems that there were also sections that did not show up in those places, as it was said that mention of staff transfers was quite satisfactory. I am sorry to reflect on that fact that I want to reflect on the roadmap and share it with all as I open it to everyone in the future.

In this place, we are managing buffers for two types of risk hedging. One is buffers management for each iteration. This is management of buffers to hedge the risks of the staff's work. I also manage buffers on the roadmap. This is a way to hedge the risk of the whole project, and we use two types of buffer management differently. However, although it is this buffer, it is important to make estimates and predictions firmly so as not to become excessive. Regarding buffers on staff work, there are places where the accuracy of estimation is somewhat high, but we do estimate from the experience rule almost how much risk management of the project is taken. For example, I kept the period for quality improvement as a buffer to some extent, and I did something like balancing in that period. However, although the buffer was left over this time, there was no possibility that my hands would be empty, but as I had surprisingly kept the buffers, there were things that it was not enough, so more precise management of the buffers in the project I think that how to proceed with progress to make a high estimate of the future is a future task.


I would like to summarize the method with such a method once. Risk hedge with task management according to priority, margin control, buffer control, and progress management in the 15 minute meeting every other day. We manage priority every day by scrum, Kano model thought based on iteration management by CCPM, we do priority management. Who are those who are listening and studying? There may be places to think, though it is not that we fully utilize each method. It is not the point that it fully utilizes its method, it applies stealing, but it is the point that we are managing each necessary combination of parts. Managing daily tasks, milestones, and iterations with hybrids of these methods, and while doing that, it is a concept of management of concepts to proceed while confirming the general rough progress with a road map It is. What you can do is to share goals in the organization, to understand the meaning of tasks in front of you, to work on the work, quality control with large tasks, prevent quality variations in large scale development, there is ........., ........., etc. Moreover, I think that accuracy is improved by devising and combining these methods, such as risk management, measures against a hazard that makes plans fail, and so on.


As for the method talk, it is over. From here I would like to talk to other management work. First we will talk about team operation.

I will tell you about iteration many times, but I think it is almost synonymous with the way of saying milestone, but I will dig into this. Especially this time it has come to mass production time, but it means that we are implementing and evaluating in the period of 2 months.


Particularly in the evaluation, regularly conducting the playing meeting with everyone from half a day to one day, collecting opinions, impressions, evaluations and examining the improvement points, the director will review the things that were scrutinized Implementation with iteration, further review including including those to be newly implemented, priority is given, planning the next iteration is done in such a cycle. In other words, we are doing the cycle of planning, implementation, evaluation, and planning with these contents every two months.

Implementation and evaluation of games of this scale feels that 2 months was the best. This is not a story that was supposed to be "in 2 months" from the beginning, but it seems to have finally settled in this period at the end of trial and error at the project. I will repeat the iteration over the period of 2 months to improve the quality and bring it closer to the master. It is said that about 1 week to 4 weeks is most suitable for general software development, but especially in game development it is necessary to thicken the process of "implementation and evaluation". So, I think that the period will become somewhat longer than general software development. However, as I think that the length of this iteration is completely different depending on the size and content of the project, it is said that while looking at the situation and contents of the project. I think that it will be up to that time to decide whether it will be two months or so when I do new projects from now on.

And although I am talking about the whole play meeting I mentioned earlier, I think that it is highly effective. Pretty much, if you are proceeding with the production with a large number of people, you will be unable to make things while grasping the whole of the game, being chased by the work of the part you are making. Even in such a meaning, doing evaluation with all members feels that merit is great. As a merit, it is possible to realize that you can grasp the part other than your own part by doing the evaluation by all, then again how the work of yourself reflects in the game. Also, since multiple directors perform judgments on judgment, all of them can share and grasp the project priority and thought. Also, we can not get up to the point that the whole staff is engaged in games, so by giving such timing we can get opinions closer to the customer's point of view than the staff. So, as a game designer it is possible to draw effective opinions at that timing. As a disadvantage, we restrain the time of all from half a day to one day, so I think that it is actually costing considerably in terms of cost. However, even if pushing the cost, I would highly recommend that everyone at the evaluation stage do a playing meeting. It feels like it has such an effect.

By repeating such iteration, we are developing it while improving quality. However, there are pitfalls in long-term development.


It is difficult to see the goal in the early stages of long-term development. Resources produced by large-scale development are enormous, and its implementation and evaluation iteration is definitely increasing the accuracy, but the evaluation at the initial stage makes the goal feeling very difficult to see . Also, the direction in the evaluation is very important, so if it seems to be judged by a long term span, it will lead to a stray of the whole project. Actually, I have spent a good deal of time in making Dracoa X this time, but in the early stages everyone could not easily have the image of the completed form. There was a time when I thought that I might be honestly completed, saying the real intention. It is a period of such a period, as the last year or one and a half years, resources are gathered and they are coming up and it is a feeling that they have been showing excitement as everyone at a stretch as they have begun to see the whole thing. In such early stage, aiming not to aim and not to hang around, it is very difficult to proceed, and I feel that the skill of the director is quite questioned in the vicinity. Regarding this time, it is director Hitoshi Fujisawa, but I could not share the image which he himself had with all of them quite easily, but by stepping through iteration and developing the image itself all by all means I think that I gradually shared it.

Although it is about the summary here, the flow of planning, implementation and evaluation is very important in large-scale development as well. I also recommend a playing meeting with everyone, so I think that you should do it at each timing.

Next, I will move on to discussing task management. I talked about buffer management in iteration ...... I am talking about the concrete thing, but I would like to talk about some schedule of schedule that is easy to fail this time. Since I have been trying various things from the initial stage, there is a way to draw a schedule that I do not recommend much. First of all, it is a bad example 1 that you should not do, but let's let go of each task with a margin.


It is similar to the buffer management just before, but by giving each task a margin, it will become like "Do not do it as long as this will end," At first glance I have a margin, so it seems like it will be going smoothly if I take this period as a job, but when I do this way of drawing it is easy for the staff to cause disconnection . Although it depends on the person, the difference between the person who finishes properly and finishes properly ahead of schedule and the person who does not go forward becomes severe. As humans usually give up, they will take care of themselves, so we can not afford to schedule, we have plenty of work to themselves, actually ahead of schedule, but we have not done shipment yet Such a trouble will occur if you do poorly. Commonly sayStudent syndromeIt is what is called. So, this drawing method seems to have a margin, but we do not recommend it because it does not work out actually.

Although it is a bad example 2, "Because I will summarize this period, please do your best with this task".


Since it is a story saying that you are doing your best while managing it on an individual basis, if you do well with this in the first place, you do not need a manager's job, it is a dollar. Normally, there is nothing going to work. There are plenty enough to have deadlines after many tasks have crawled around if it is not well. However, depending on the person, this management, the management which should not do also has the reverse effect. Especially for people who are craftsmen, it may be better for you to do this kind of way. If you decide to leave it to discretion in the period given the quality improvement, it may be a good idea. Wherever you are doing such a schedule, you will always be hearing or checking the situation, but in cases where you leave it to individual discretion, you can get the most out of your ability to have it. In order to tackle the quality improvement in the extra time after finishing the task with ahead of schedule, separate the paragraph from the next sentence. Semantic chunks make it easier to read if you divide it to some extent. Although it can be said commonly, taking this into consideration that it is a few elite when doing this, and that it is a team with a high craftmind temperament. For the project this time, though, for example, the art director is a person who would be able to self-manage. Of course it is also the owner of the ability to say that there is not anyone who can draw quality and quantity on the right in drawing work. So please make sure to finish this task in this period, so we are doing what we are doing to leave quality upgraded at discretion among them. Also, in this work, for example, it is an effects team, and the rest of the monster 's motion team is doing what it says to minimize the number of people and arrange genuine specialists, and such a craftsman For a small number of teams gathered, I am doing how to schedule such as "Please improve your goal, including quality improvement within this period". However, it is very difficult to determine this point. Basically we do not recommend it. Still, this place that I have been particularly striking a sharp quality at Dragon Quest X this time is this kind of operation, so I can not miss this. Personally I am aware that it is a very interesting case. I think that it would be incredibly worthwhile to bet on such management if there is such expectation that they would do such a job if they were aware of such kind of things.

Also, supplementarily, of course, there are all special people in other sections as well. However, if there are many people, it will inevitably lead to personal differences in work and skill differences. In such a case, it is fundamental that it is no less necessary to take control with uniform management. And, although it is a summary here, sometimes I think that flexibility to tackle with the opposite idea according to the situation is also necessary.

As you are talking about from the last time, there may be people who are totally aware of it, but designers, well artists are very professional craftsmanship or professional race. It is harder than actually managing the programmers actually to lead such people who are not easy to do. From here I will talk a little about designer management.

It is a story that the operation differs depending on the section. As for the estimate of the designer and the buffer, operation is considerably different depending on the section.


Operation is different between sections that are easier to disassemble tasks and sections that do not. For example, with regard to characters, we will produce one character in about a few days. Work content is modeling, UV, texture etc. If it can be decomposed in stages, it is easy to manage in relatively day by day. Regarding motion, it will be like production of one motion from several hours to several days, so it is possible to schedule a detailed schedule with high precision, but at the same time management costs are high if it is too small There is a danger of getting into it. So, in the case of motion, we manage some things together to some extent where it is too fine. Also, if you evaluate the buffer of management of tasks of one motion time in increments of two months, it will be hard to evaluate the buffer for each task, so in case of motion it will be 2 Even within the iteration every month, we will further implement, implement and produce and evaluate every two weeks. I felt that it would be just right to split it in units of two weeks if the motion was about 3 motions per day. If this becomes a weekly unit, the span is a bit too short,Plan Do SeeThere is the impression that it will take time and effort on the other hand. Even in the sense that the two weeks evaluate the result of the task, I feel that it was a good period for motion.

Regarding cut scenes, although the number of days required is large, it is easier to disassemble work, so it is relatively easy to manage. However, as one person is in charge of one scene, the production is like making the scene by a few months alone. So, I think that the shake of the work efficient part between the staff is large, and I think that we still have to look closely in terms of management on a daily basis for management. It is management concerning 3 DBG, but this time it is called MMO this time and I am making a fairly vast map. Therefore, the period is long, and the production stage is roughly separated, but it is a little difficult to operate with task disassembly every day in management. Things like characters are easy to manage tasks on a daily basis, but how to disassemble and adjust long-span jobs like BG is what I did hard this time though , There were some things that did not go well until the end. I regard this as a future issue. In BG, it seems to be necessary to define the task decomposition at another angle for daily task management.

Although it is a subdivision of task decomposition, how to subdivide and how to operate depends on the target at that time, the amount and contents of the task, the resource to do it, and how much manpower is managed I think that it will be different. It is a matter of course that it will be different from such occasions, rather if we do not decide the operation method by adding a factor of such complexity, "Since we divide iteration by two months, we will do it every two months. Somehow, if you do it too uniformly, you will be frustrated in the middle of the operation, or you can not manage it any more and eventually the management itself will become sweet, As for disassembly and operation of tasks by such a section, I feel that I have to make various adjustments here.

As for future tasks, one task is about how to manage what is called a long span, but while thinking about disassembly of tasks as future tasks, by organizing workflows this time, We are making ingenuity to smoothly advance things like work progress.


It is about that workflow, but if you say that you are paying attention to the long work of span, it is said not to waste unnecessary wait and so on, so that the downstream section is not easily affected We are located. Such a story is conscious of a flow that draws a flow that can do parallel work and concentrates on that work without worrying about the work of other sections. As an example, I will introduce a workflow of BG, workflow around the cut scene a bit. Although I was roughly proceeding with such a workflow roughly this time, we are progressing according to the phase of BG, respectively. As I said earlier, BG has a long production span and it will tell you when it is waiting for the finish, when will it come up. It will be production in several months, so it will not go waiting for several months until it comes up. For that reason, we draw production based on a flow divided into four phases. It will be in the status "Rough Map" "Template Map" "Collision FIX" "FIX" It is written in the middle.


First of all, although it is a rough map, this map is a very rough map for checking the size of the map, its positional relationship, and its appearance. I actually walk in actual condition with this kind of polygon condition, and planning and verifying the picture etc are carried out. I would like to show you the map that was reconsidered. This is an option called Glenn Castle of the auger which has already been published, but it may be understood that it is a customer who is actually playing, but at first it is quite different from this and the current structure . Although it is what, although it is a map which is slightly rougher by verifying the structure with the rough map, it is structurally in a state that it is almost the same as what has already been released at this stage . By proceeding to this point at the stage of rough map, we are doing to carry out the work afterwards smoothly. Then, at the stage of putting in the rough map, the next will be the status of a template map, but this is the same arrangement as the basic structure for the production model is FIXed. Since the shape is determined to some extent here, for example, it will be in a state where you can arrange NPCs when you are in town, and in the field it is in a state where level design such as placing monsters is possible, so template maps calling. After that status, next collision FIX, this is the status that it is making the shape FIX of the moving range of the PC well, and at the stage of FIX, the perspective model and the texture are finished, I will continue.

Although it is a point here, the status called a template map has become a liver, this is where the shape and planning etc. are almost fixed here, it is said that it is possible to transfer from BG to another section at this stage The state is important. By passing it to the layout design of the level designer and the cut scene here, with the status after this template map, each section concentrates on each work and it is structured like this. It is like this when completed. After designing the rough, in FIX it will be such a design. Also I will do parallel work on characters as well. In the flow after modeling, texture, motion and sequence work can be done in parallel.


In short, it is a point about flow, but let's say that we will make a decision with a high priority first so that we can come back to the next one at an early stage.


It is necessary to devise such that you can concentrate on work in parallel as much as possible. However, if this flow goes well with something, it is not so. In doing this flow, I wonder if the flow is running smoothly and smoothly "with no problem" There is reflection on the point that it is necessary to make adjustments that have a new role, such as checking and correcting if there is any. When you do this kind of work, tasks in those places also occur, so when you do a new flow as a cost effect, I feel that you need to be careful in those places.

In the place where it got a little less time, I would like to talk a little more about the other ingenious ideas etc. It is said that each staff 's role is taken. This is a story of team operation, but if you stay on a team for a long time, work becomes mannellised, if it is a big project, it tends to be just a work of flowing work. As such things continue, the staff themselves will stop thinking. You just become a person who is doing stream work. As a result, the motivation will come down and the efficiency will be worse. This is quite likely to happen if it is a large-scale development, and eventually it does something that goes out of the office and leaves the company, so in order to prevent such things as much as possible, the role for each staff Would it be necessary to devise a way to have you have it?


By doing so, you can have a sense of how much you are involved in the team. This is a very important thing, because any part can be the first thing, it is necessary to put on what is in charge. By having a responsible person, you will create a sense of responsibility for the person him / herself. Also, by attaching a charge, the number of interactions with other sections will increase, so you will realize how your work will live in the project and will actively move on your own. Just enough people to make what I said is going to stop thinking. I feel that it is extremely important to have roles and responsibilities in order to always actively capture things and work on the work. Such a little consciousness reform also changes the atmosphere and consciousness of the team. Although I tried such experiments in some sections experimentally this time, it was very expensive as an effect and it was also good as the atmosphere of the team, so in the future I will take responsibility for each project as a whole I think that I would like to have it.

I will talk a bit about Scrum.


I do not talk about the effect of Scrum anew, but I have the impression that it was quite difficult to get started. Persuasion at the start is particularly difficult. As for the scrum, since it is something that the effect is required continuously, I think that it is difficult to devise how to devise it. Even if you are a programmer and you explain it objectively as you explain it "Effective" and actively incorporate it as well, it is in the case of an artist, but do not look around the job well Since there is a nature of concentrating on my work, I wonder if there is a place like to persuade, or to have it forcefully top - down done. As for the scrum which the designer as a whole was able to introduce, there was also a section which could not be introduced to the end easily. Or, although I could introduce it, I can not see the scrums of all the sections, so if you notice it you need to have a bit distracted, skills to manage and facilitation skills as well What? Well, it is insufficient. I also realize such a place. I feel like I'm going to have to do a bit of work as an organization after all. However, with regard to the introduced sections, communication has been enhanced, making it easier for them to communicate as a team. Problems are more likely to occur as the awareness is thinner, and delays in work are likely to occur. As I see it on a bird's-eye view, the effect of Scrum is still high, so I think if you could do it to all of you. It is somewhat challenging to make preparations and securing resources for that purpose penetrate the site of large scale production.

Time is close, is not it? The rest is about the estimate, but I will skip a little. There is a story saying that it is important for the workers themselves to make an estimate.


While confirming the task with the leader, this will reduce the difference between the estimate and work balance. Therefore, I am satisfied when conducting analysis later.

In addition, there are places I thought about doing management in this way, but this time I will tell you a bit about the point that I, in particular the designer, managed the programmer. As a good thing, I knew everything about the designer, so it was very great that I got work priorities. By grasping the task of the drawing programmer, the work of the designer has become very smooth. On the other hand, as a bad thing, since I am not from a programmer, I am lacking in the judgment power of the programmer 's estimate of the task, so when I make an estimate, I accompany the programmer' s chief and talk with the staff While doing the task to decide. In such a situation I eventually take time for the chief, so I feel like it is a reflection point.

Then what kind of skills are required for managers? It will be said that.


Since it is necessary to control the progression of making progress without progressing the production without lowering the quality, setting up the actual workflow, and controlling the progress in such sections, if there is no field experience in the first place, the job manager is a little I feel that it is difficult. Management is closely related to cost and budget. Sometimes it is sometimes required to have a higher judgment ability than a person who is part-leading, so it is good flow for humans who aim for managers to take the experience of the workplace and go to the management path first, And I feel it again this time again.

In that place, the time is over but it is a story of today's summary. Software development is uncertain. It is impossible for me to finish with what I decided at the beginning as it is implemented. Bugs and unexpected problems are also occurring. In order to implement even in terms of quality, we will change it and achieve it to the ideal quality. Although such uncertainty will decrease in proportion to the progress of the project, it is very important to understand it and operate the project. In other words, the schedule management should be a premise that it should be rearranged in a sense. Either way, something that happens somewhat, especially when it is large, unexpected and irregular cases often occur in a long development span, and management that is easy to rearrange is desirable. Among them, there is a negative image that it will deviate from the initial schedule when it comes to talking about rescheduling, but it is important to recognize that the schedule will be advanced with the premise of changing the schedule. We believe that there is schedule management in order to deal correctly when irregular events occur and to hedge risks to minimize the impact on project progress.

Therefore, project management is risk management. It is important to assemble the method that suits the project. As it is a method for hedging such risks, it is going to introduce something more suitable for the project, but, however, it is a light objective development that places much emphasis on methods, so-called flexible development Or, by the fact that it becomes a burden on the site, it is toppled over. It is not the purpose of applying the method, it is aimed at how to reasonably proceed the project in the framework of limited budget and period. I think that it is important to build method, team management, workflow idea in a way suited to the project. Even though I can not complete the method perfectly, I am working on a way of thinking that it would be OK if the operation is good. In the management industry, it is necessary to reconfigure the method to make the best use of the operation itself, but the way that such application is difficult.

I think that management will be exhausted to this point as to how rational development is done. Why do we need to do reasonable development? Although it is an important goal to protect period and cost, it is only for superficial purpose, to improve efficiency, for example to make power a quality By guessing, I think that staff have peace of mind by improving brand power, after that by securing time, they will work with result motivation, that place is important It is. The larger the scale, the more difficult the rational development will come up. Depending on the circumstances, the measures to do so will vary widely. I think that I would like to continue to make efforts to improve the work flow smoothly and maximize the capacity of the organization. The development of Dragon QuantX in the future will shift not to develop new titles but to develop services to be offered to customers on operation. So, I'd like to continue my efforts and devises from those perspectives in particular.


By the way, today I said almost what I said. Finally adding only one, management is done with people. I feel that it was only when professional assistance, genius programmers, and game designer's sense got the release of Dracue X successfully. I would like to make everyone of the staff involved in the project cooperate as a whole in this project with the greatest respect and respect as the shade of today's lecture. More about the lecture. thank you for listening.

in Coverage,   Game, Posted by darkhorse_log