Good afternoon, all. I’m Magne “Meneth” Skjæran, the programmer on CK2. In the past I’ve written dev diaries about modding, optimization, and quality of life improvements.
Summer has started, and most of the office is gone until the end of July, including the majority of the CK2 team. However, the show must go on, so for these four weeks I’ll be writing all the CK2 dev diaries.
Since most of the team being on vacation means that little development is happening, that means that these four dev diaries will be pretty light on info about the upcoming expansion and patch, but I hope to provide you with some interesting insights, info, and tidbits regardless.
For today, I’ll be writing about the different roles people on the team have, and what each such role is responsible for.
At the time of writing, the core CK2 team consists of: one creative director, one project lead, one designer, two content designers, one programmer, one artist, and two embedded quality assurance testers.
Beyond the core team, we also have the support of our central quality assurance unit, a 3D artist, and a number of external contractors, as well as a number of publishing roles.
So let’s start from the top, with the creative director.
Game Director
Person: Henrik “Doomdark” Fåhraeus
Our creative director has since CK2’s inception been Henrik Fåhraeus, though at the time the role was combined with the Project Lead role and Programmer role, and simply called Project Lead.
The role of the Creative Director is to provide the overall direction for the game. The main way the director does this is by writing the overall vision for each expansion, and provides guidelines and a framework for the designer to work with, which is collected in a vision document. This document outlines each feature the expansion and patch is supposed to have, with descriptions of what each feature entails, its purpose, how important it is, whether it’ll be free or not, and what professions will be involved in implementing it.
The game director then monitors the state of the game to ensure that it is staying in line with their overall vision and concept; that features are implemented in a way compatible with the needs they wanted to address, and working in the manner they expected.
Designer
Person: Alexander “rageair” Oltner
Next, we also have a designer. While the game director focuses primarily on the overarching vision, the designer focuses more on fleshing out the details, though there’s significant overlap with the game director sometimes fleshing things out, and the designer sometimes being responsible for parts of the vision.
The designer turns the vision document into a design document; a document fleshed out enough that it can be implemented by the programmers, content designers, and artists without having to constantly make assumptions about how something is meant to work.
The designer also serves as the primary point of contact between the people implementing the design, and the design team (the creative director and designer). If the design is unclear, ambiguous, or the implementer sees a potential issue, the designer is the person to ask in order to resolve such issues.
Project Lead
Person: Anna “Anona” Norrevik
While the design team decides what the goal of an expansion/patch is to be, the project lead figures out the “how” in order to make the release as good as possible, and to ensure the schedule is kept. As part of this, the project lead keeps track of the progress made towards the release to ensure that it is kept on track, and ensure that new features don’t creep into the project plan without good reason. If the project is lagging behind schedule, the project lead is also responsible for getting it back on track. There are three main ways for the project lead to do this:
Estimation meetings
At the start of each expansion, the project lead meets with each implementation profession (art, content design, and code). In these meetings each point of the design is gone through, and the profession identifies any tasks that relate to their job, and how long it is likely to take to implement.
Based on this, the project lead can see from the start if it is actually plausible to complete the project on time, and determine if anything needs to be cut already.
If new features are added to the design later, shorter estimation meetings or estimations by the profession lead will also be undertaken for these features so that they can be fit into the project plan.
Task sprint distribution
Based on the estimates and the time available, the tasks are distributed across a number of sprints. Each sprint is four weeks long, with the first three being dedicated to new functionality, and the fourth week being dedicated to fixing issues introduced during the first three weeks. The tasks are split so that each sprint has roughly the same amount of work, but with tasks with more significant risks scheduled early so that the team can eliminate the risks as soon as possible.
Task distribution and prioritization
When a profession has more than one member, the project lead is responsible for assigning individual tasks/bugs to each member, or delegating this responsibility to someone within the profession.
The project lead is also responsible for assigning priorities to tasks and bugs so that the rest of the team is aware of what order they should work on the tasks.
Scrum meetings
As the CK2 team uses the development methodology Scrum, there’s three Scrum meetings: standups (AKA “morning meetings”), sprint reviews, and sprint retrospectives.
Content Designers
People: Milla “IsakMiller” Isaksson, Joel “Divine” Hansson, and until recently, Drikus “Bratyn” Kuiper (who is now on HoI4 instead).
Joining us for the summer, we also have Matthew “blackninja9939” Clohessy from the Game of Thrones mod team
Content designers are part of the implementation team. In the old days, this position was simply called “scripter”, but the name was eventually changed as while “scripter” does capture some of what a content designer does, it leaves out quite a lot of it.
Content designers are essentially responsible for creating the actual content of the game, as opposed to code functionality and art. What is to be added is determined by the design team, but the details are generally delegated to the content designers, which is why they’re no longer called “scripters”; content design entails not just implementing a specification, but creative writing, research, game balance, narrative design, and so on.
For example, the design for the actual artifacts to be included in Monks and Mystics was quite vague. One bullet point for example was: “Add 10-20 Major Christian relics. To make it more interesting, these are unique and can never be destroyed”.
The content designers then had to come up with what historical artifacts to include, descriptions for each, ideas for what the art could be like, effects for each, and acquisition methods. A single paragraph of design turned into hundreds of paragraphs of event text, and thousands of lines of script.
What content designers create includes:
Artist
Person: Bjarne “Grimjotun” Hallberg
The artist is responsible for creating new art for the game. This mostly manifests in a large variety of interface icons, but they’re also responsible for the overall layout of each interface, as well as providing sketches and similar so that the interface itself can be implemented before the art is completed.
For example, here is a sketch of the society interface from the Monks and Mystics design document:
As you can tell, a number of things have since changed, but the overall idea is recognizable in what’s in the game today. Sketches like this are invaluable when it comes to ensuring that early versions of the system can be implemented and iterated upon.
The artist also helps outline what’s required from artists external to the team. For example, if 3D art is needed, the artist might make a 2D sketch of what it is they want so that the 3D artist has something to work with and the result ends up fitting well into the game.
All told, the artist has significant impact on the overall art direction of the game, while making sure that new interfaces don’t look out of place.
Programmers
People: Magne “Meneth” Skjæran, and until recently Gwenael “Moah” Tranvouez (who is now on Stellaris instead)
The programmers’ main responsibility is to create new systems based on the design document. For example, the society system introduced in Monks and Mystics was created by the programmers, while the societies themselves were created by the content designers, and the art for it by the artist.
For some systems, no content design is needed. One example of this is the ally orders in Monks and Mystics. However, for most systems the job of the programmers is essentially to produce a foundation that the content designers can build the actual house on. In these cases, when a system is to be implemented the programmers will usually meet with the content designers to discuss what they require from the system, and agree on the syntax the content designers will use to interact with the programmed system.
Once implemented, content designers will often discover functionality that they require that was not provided by the first implementation, and based on this the programmers will iterate on it further.
Beyond creating new systems, programmers maintain the old systems by fixing bugs and making improvements. Most of the quality of life changes made in the 2.7 patch for example were implemented by the programmers, though often with significant assistance from art.
Another aspect of maintenance is ensuring the game stays performant. This is done both by trying to implement new functionality in a way that doesn’t significantly impact performance, and by spending time optimizing existing systems to make them faster.
Overall, programmers and content designers work closely together; the programmers ensure the core systems work, while the content designers make sure that the systems are actually varied and fun to use.
Quality Assurance
People: Arthur “[Arthur-PDX]” Bialecki and Daniel “Tuscany” Moore
The design team figures out what to do. The project lead figures out who should do it, when, and how to stay on schedule. Implementation creates it.
Quality assurance makes sure it actually works and is fun to play.
Quality assurance has a number of tasks. The most well-known is simply to find bugs, but this is far from all they do. In short, quality assurance’s responsibilities include:
Contractors
Beyond the internal team, there’s also a number of contractors that do a variety of tasks on the game that are more limited in scope:
Summary
I hope you liked this introduction to what the people on the CK2 team does.
Next week, I’ll be talking about the lifetime of a bug; from initial discovery to release of a fix.
As an added bonus, here’s five changelog entries from the 2.8 patch chosen at random:
- The society member list now includes a member count. Hovering over it will give you a breakdown of how many members hold each rank
- The 'All' Gender Equality rule no longer prohibits Achievements, though you will not be able to gain the 'Empressive' achievement while the rule is enabled
- Fixed piety giving an opinion bonus with anyone who can hold temples, not just theocratic governments
- The AI now checks to see exactly how many liege levies it'll deny its liege by revolting, rather than going "eh, half my levies I guess?"
- Fixed the end date given for settlements in the settlement construction confirmation window not always matching the actual end date even if all build time modifiers remained the same throughout construction
Summer has started, and most of the office is gone until the end of July, including the majority of the CK2 team. However, the show must go on, so for these four weeks I’ll be writing all the CK2 dev diaries.
Since most of the team being on vacation means that little development is happening, that means that these four dev diaries will be pretty light on info about the upcoming expansion and patch, but I hope to provide you with some interesting insights, info, and tidbits regardless.
For today, I’ll be writing about the different roles people on the team have, and what each such role is responsible for.
At the time of writing, the core CK2 team consists of: one creative director, one project lead, one designer, two content designers, one programmer, one artist, and two embedded quality assurance testers.
Beyond the core team, we also have the support of our central quality assurance unit, a 3D artist, and a number of external contractors, as well as a number of publishing roles.
So let’s start from the top, with the creative director.
Game Director
Person: Henrik “Doomdark” Fåhraeus
Our creative director has since CK2’s inception been Henrik Fåhraeus, though at the time the role was combined with the Project Lead role and Programmer role, and simply called Project Lead.
The role of the Creative Director is to provide the overall direction for the game. The main way the director does this is by writing the overall vision for each expansion, and provides guidelines and a framework for the designer to work with, which is collected in a vision document. This document outlines each feature the expansion and patch is supposed to have, with descriptions of what each feature entails, its purpose, how important it is, whether it’ll be free or not, and what professions will be involved in implementing it.
The game director then monitors the state of the game to ensure that it is staying in line with their overall vision and concept; that features are implemented in a way compatible with the needs they wanted to address, and working in the manner they expected.
Designer
Person: Alexander “rageair” Oltner
Next, we also have a designer. While the game director focuses primarily on the overarching vision, the designer focuses more on fleshing out the details, though there’s significant overlap with the game director sometimes fleshing things out, and the designer sometimes being responsible for parts of the vision.
The designer turns the vision document into a design document; a document fleshed out enough that it can be implemented by the programmers, content designers, and artists without having to constantly make assumptions about how something is meant to work.
The designer also serves as the primary point of contact between the people implementing the design, and the design team (the creative director and designer). If the design is unclear, ambiguous, or the implementer sees a potential issue, the designer is the person to ask in order to resolve such issues.
Project Lead
Person: Anna “Anona” Norrevik
While the design team decides what the goal of an expansion/patch is to be, the project lead figures out the “how” in order to make the release as good as possible, and to ensure the schedule is kept. As part of this, the project lead keeps track of the progress made towards the release to ensure that it is kept on track, and ensure that new features don’t creep into the project plan without good reason. If the project is lagging behind schedule, the project lead is also responsible for getting it back on track. There are three main ways for the project lead to do this:
- Ask for more resources. For example, if the code is lagging behind, a programmer might be loaned from another project. “More resources” will in some cases simply be more time; plan the release for later so that more can be done
- Reduce the scope of tasks. Often, it is possible to scale a feature down to some extent if there’s simply not enough time. For example, if a new feature originally was intended to have six related event chains, reducing this to five might be a way to get the project back on schedule
- Cut features entirely. Every design initially starts off with a number of ideas or features that aren’t core to the overall design. If the project is lagging behind, features like those are the first to go. As an example, during Monks and Mystics we implemented a large number of quality of life features, but there were some that ended up cut for time before implementation. However, features cut from one patch or expansion often end up in a later one
Estimation meetings
At the start of each expansion, the project lead meets with each implementation profession (art, content design, and code). In these meetings each point of the design is gone through, and the profession identifies any tasks that relate to their job, and how long it is likely to take to implement.
Based on this, the project lead can see from the start if it is actually plausible to complete the project on time, and determine if anything needs to be cut already.
If new features are added to the design later, shorter estimation meetings or estimations by the profession lead will also be undertaken for these features so that they can be fit into the project plan.
Task sprint distribution
Based on the estimates and the time available, the tasks are distributed across a number of sprints. Each sprint is four weeks long, with the first three being dedicated to new functionality, and the fourth week being dedicated to fixing issues introduced during the first three weeks. The tasks are split so that each sprint has roughly the same amount of work, but with tasks with more significant risks scheduled early so that the team can eliminate the risks as soon as possible.
Task distribution and prioritization
When a profession has more than one member, the project lead is responsible for assigning individual tasks/bugs to each member, or delegating this responsibility to someone within the profession.
The project lead is also responsible for assigning priorities to tasks and bugs so that the rest of the team is aware of what order they should work on the tasks.
Scrum meetings
As the CK2 team uses the development methodology Scrum, there’s three Scrum meetings: standups (AKA “morning meetings”), sprint reviews, and sprint retrospectives.
- Morning meetings - Each morning, the team meets to briefly summarize what they’ve done in the previous day, and what they’ll be doing today. This helps keep everyone aware of what’s currently going on in the project
- Sprint reviews - At the end of each sprint, each member of the team shows off some of what they’ve done in the sprint. These meetings generally also involve a few people outside the core team, so that they too can see how the project is progressing. This is also an opportunity to give feedback on the work done
- Sprint retrospectives - At the end of each sprint, the team identifies what aspects of the work itself could use improvement, and what went well. For example, the team might identify that communication between two disciplines has improved, or that parts of the design aren’t quite clear enough. The most important issues are identified, and a plan made to address them so that the team will do better in the future
Content Designers
People: Milla “IsakMiller” Isaksson, Joel “Divine” Hansson, and until recently, Drikus “Bratyn” Kuiper (who is now on HoI4 instead).
Joining us for the summer, we also have Matthew “blackninja9939” Clohessy from the Game of Thrones mod team
Content designers are part of the implementation team. In the old days, this position was simply called “scripter”, but the name was eventually changed as while “scripter” does capture some of what a content designer does, it leaves out quite a lot of it.
Content designers are essentially responsible for creating the actual content of the game, as opposed to code functionality and art. What is to be added is determined by the design team, but the details are generally delegated to the content designers, which is why they’re no longer called “scripters”; content design entails not just implementing a specification, but creative writing, research, game balance, narrative design, and so on.
For example, the design for the actual artifacts to be included in Monks and Mystics was quite vague. One bullet point for example was: “Add 10-20 Major Christian relics. To make it more interesting, these are unique and can never be destroyed”.
The content designers then had to come up with what historical artifacts to include, descriptions for each, ideas for what the art could be like, effects for each, and acquisition methods. A single paragraph of design turned into hundreds of paragraphs of event text, and thousands of lines of script.
What content designers create includes:
- Individual events and event chains
- Decisions
- Societies and other systems
- Artifacts
- Flavor text
- Characters
- Titles
- Religions
- Cultures
- Much more
Artist
Person: Bjarne “Grimjotun” Hallberg
The artist is responsible for creating new art for the game. This mostly manifests in a large variety of interface icons, but they’re also responsible for the overall layout of each interface, as well as providing sketches and similar so that the interface itself can be implemented before the art is completed.
For example, here is a sketch of the society interface from the Monks and Mystics design document:
As you can tell, a number of things have since changed, but the overall idea is recognizable in what’s in the game today. Sketches like this are invaluable when it comes to ensuring that early versions of the system can be implemented and iterated upon.
The artist also helps outline what’s required from artists external to the team. For example, if 3D art is needed, the artist might make a 2D sketch of what it is they want so that the 3D artist has something to work with and the result ends up fitting well into the game.
All told, the artist has significant impact on the overall art direction of the game, while making sure that new interfaces don’t look out of place.
Programmers
People: Magne “Meneth” Skjæran, and until recently Gwenael “Moah” Tranvouez (who is now on Stellaris instead)
The programmers’ main responsibility is to create new systems based on the design document. For example, the society system introduced in Monks and Mystics was created by the programmers, while the societies themselves were created by the content designers, and the art for it by the artist.
For some systems, no content design is needed. One example of this is the ally orders in Monks and Mystics. However, for most systems the job of the programmers is essentially to produce a foundation that the content designers can build the actual house on. In these cases, when a system is to be implemented the programmers will usually meet with the content designers to discuss what they require from the system, and agree on the syntax the content designers will use to interact with the programmed system.
Once implemented, content designers will often discover functionality that they require that was not provided by the first implementation, and based on this the programmers will iterate on it further.
Beyond creating new systems, programmers maintain the old systems by fixing bugs and making improvements. Most of the quality of life changes made in the 2.7 patch for example were implemented by the programmers, though often with significant assistance from art.
Another aspect of maintenance is ensuring the game stays performant. This is done both by trying to implement new functionality in a way that doesn’t significantly impact performance, and by spending time optimizing existing systems to make them faster.
Overall, programmers and content designers work closely together; the programmers ensure the core systems work, while the content designers make sure that the systems are actually varied and fun to use.
Quality Assurance
People: Arthur “[Arthur-PDX]” Bialecki and Daniel “Tuscany” Moore
The design team figures out what to do. The project lead figures out who should do it, when, and how to stay on schedule. Implementation creates it.
Quality assurance makes sure it actually works and is fun to play.
Quality assurance has a number of tasks. The most well-known is simply to find bugs, but this is far from all they do. In short, quality assurance’s responsibilities include:
- Verifying that new features work
- Verifying that bugs marked as fixed have actually been fixed
- Identifying new issues introduced for old features
- Identifying issues for old features that have not previously been found
- Giving feedback on game balance
- Giving feedback on whether new features are actually fun to use
- Giving feedback on whether there are annoying aspects of the game that could be improved upon (E.G., quality of life improvements)
- Monitoring the stability of the game (crashes and out of syncs)
- Monitoring the performance of the game
- Bringing problems to the attention of team members who can fix them
- Monitoring the forums to collect bugs that have not been found by internal testing, and to inform reporters if an issue is already known
- Monitoring the forums to identify what concerns the playerbase has
- Identifying risks, such as an increasing number of open bugs, degraded performance, decreasing stability, and so on
- Determining whether patches can be released or not
Contractors
Beyond the internal team, there’s also a number of contractors that do a variety of tasks on the game that are more limited in scope:
- Localisation - We have several contractors who translate the game into German (shokii), Spanish (kgw), and French (zimxavier)
- Portraits - Our portraits have long been created by an external contractor, CrackdToothGrin. You might also know him from the CK2 modding forum
- Event pictures - We generally have an external company create a number of event pictures for us each expansion
- Music - While we also create music internally, we do at times outsource some of it
Summary
I hope you liked this introduction to what the people on the CK2 team does.
Next week, I’ll be talking about the lifetime of a bug; from initial discovery to release of a fix.
As an added bonus, here’s five changelog entries from the 2.8 patch chosen at random:
- The society member list now includes a member count. Hovering over it will give you a breakdown of how many members hold each rank
- The 'All' Gender Equality rule no longer prohibits Achievements, though you will not be able to gain the 'Empressive' achievement while the rule is enabled
- Fixed piety giving an opinion bonus with anyone who can hold temples, not just theocratic governments
- The AI now checks to see exactly how many liege levies it'll deny its liege by revolting, rather than going "eh, half my levies I guess?"
- Fixed the end date given for settlements in the settlement construction confirmation window not always matching the actual end date even if all build time modifiers remained the same throughout construction
Last edited:
