Difference between revisions of "Making a Mod - Best Practices"

From Frictional Wiki
Jump to navigation Jump to search
m (WIP note)
 
(29 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Wip}}
+
{{note|This article is long, but taking the time to read it might help you save a lot of time when making a mod.}}This article is designed to give modders things to keep in mind while creating their project. Remember that these are just guidelines intended to help you – you don't have to follow them, but they may teach you something useful.
 +
==Starting Out==
 +
 
 +
===Scoping Out Your Project===
 +
In order to make sure your mod gets released, it is '''extremely''' important to make it under a manageable scope. This means that you must avoid being overly ambitious. Creating a project that is too massive will likely end up getting cancelled. Many modders may come up with interesting and big ideas that sound doable on paper, but later realize that it is a lot more work than first anticipated.
 +
 
 +
The best way to combat this is to create a limited scope from the start. It is much better to be conservative and create a project that is smaller than what you think you can do. A small project is better than a cancelled project.
 +
 
 +
If you would like to create a big project, it is best to first create a small one, which will give you an idea of how big you can go in the next project. Two small projects will teach you more than a single big one.
 +
 
 +
{{tip|Don't plan your project with play time or the number of levels in mind. This will end up in having a lot of content left to make and no ideas for it. Instead, gather your gameplay ideas and design around that. It is easier to add onto a complete project than fill an unfinished one.}}
 +
 
 +
And remember: quality over quantity. Players will enjoy a unique and well crafted mod even if it is short more than one that is artificially expanded just to be long. You will also have much more fun and satisfaction if you can finish a project before it bores you.
  
This article is designed to give potential modders some pointers and things to keep in mind while creating their project. Remember that these are just guidelines intended to help you – you do have to abide by them, but they may teach you something useful.
+
===Collaboration===
  
==Starting Out==
+
You will need to decide if you are going to work in a team or not. This will influence the scope of the project, so it is be done when starting a mod. A team can of course be brought on after working alone for some time, but that comes with additional challenges.
  
=== Scoping out your project ===
+
Working on a mod alone is entirely possible, but working in a team will make it much more bearable. That said, do not assume working in a team is always easier than working alone; there are upsides and downsides. Having a team requires managing it and making sure work is actually getting done, which is a considerable challenge.
If you wish to actually complete your project, it is extremely important that you create a manageable scope. This means that you must avoid being overly ambitious. Creating a project that is too massive will likely end up cancelled. In the start it might be difficult to imagine how much work will go into your project. Many people will imagine a big project and consider it "doable" in the start, but later realize that it is a lot more work than first anticipated. The best way to combat this is to create a limited scope off the bat. It is much better to be on the conservative side and create a project that is smaller than what you think you can do. A small project is better than a cancelled project. If you would like to create a big project, it is best to first create a small one, as to get more accustomed to the process.
 
  
=== Assembling a team ===
 
 
{{Idea|If you are going to work in a team, '''make sure to create the mod idea together.''' An unfortunately popular phenomenon is people joining a team, getting a sneak-peek at the mod and losing interest. '''Creating the mod premise together can help keep the members invested.'''}}
 
{{Idea|If you are going to work in a team, '''make sure to create the mod idea together.''' An unfortunately popular phenomenon is people joining a team, getting a sneak-peek at the mod and losing interest. '''Creating the mod premise together can help keep the members invested.'''}}
  
Working on a mod alone is entirely possible, especially if the mod is very small, but sometimes you may want to collaborate with others and assemble a team. That said, do not assume working in a team is always easier than working alone; there are advantages and disadvantages. The biggest advantages of working in a team is that you can concentrate one's skills in a particular area, such as level design, programming, writing. The resulting output might have higher quality because of this.
+
'''Remember, even having someone to only give you feedback is very helpful.''' Furthermore, participating in public discussions about modding can help you and others learn. This can be done in the modding channels on [https://discord.com/invite/frictionalgames the Frictional Games Discord server]. Share your work and ask questions!
On the flip side, the many challenges of working in a team can negate the advantages if you do not manage the team well. It is crucial that the team has a team leader who can organize the group of people, tell them what they should focus on, and follow up how things are going over time. This article does not explain what it takes to be a good team leader, because this topic is very expansive, but without structure in your team it will likely stall the project; some people may not work, others may not know what to work on. The team leader is likely to be one of the developers in a smaller team, but the important aspect is that everyone agrees on who will hold the responsibility for the progress of the project.
 
When you are looking for potential team members, do not fall into the trap thinking more people will make the project easier. The more people you have, the more time will be spent managing them. Having for instance two persons working on the same kind of content (like map design) requires them to be able to co-operate as well, which adds another burden to the team leader that they must consider as they organize the team. For smaller teams it is best to stick with as few people as you can get away with. A guiding rule here is to keep the team small. Adding more people to the team does not mean more work will get done.
 
  
Even if you don't have a team, participating in public discussions about modding can help you and others learn. This can be done in the modding channels on [https://discord.com/invite/frictionalgames the FG Discord server]. Share your work and ask questions!
+
''Main article: [[Efficient_Teamwork | Efficient Teamwork]]''
  
 
==Mod Design==
 
==Mod Design==
One of the most useful questions you can ask yourself is "Why should someone play my mod?" It's a hard question to answer truthfully, but if you can answer it well, you're on the right track. Think about what other mods are out there, and what they offer. Does your mod offer something new to the players? Is what you offer enough to entice players who are busy playing other mods? Even if you cannot answer this question, just thinking about it will probably help your mod.
+
Ask yourself "Why should someone play my mod?". It's a hard question, but if you can answer it well, your mod design has good potential. Think about what other mods are out there, and what they offer. Does your mod offer something new to the players? Is what you offer enough to interest players? Even if you cannot answer these questions, just thinking about it will probably help you come up with ideas.
  
===Realistic Goals===
+
===Understand the Engine===
Create realistic goals for yourself. Think about how long it takes a commercial developer to make a horror game with 20 maps. If your mod is going to have 30 maps, the development process is going to be very hard. The thing to keep in mind here is "Quality over Quantity." Players would far prefer to have a short, unique and well balanced mod than big, repeating mod.
+
You should really read the documentation of the game you want to mod.
 
 
Do not be afraid to cut content and features. If the mod looks like it's never going to be finished, or there's some content that you don't think meets the quality of the rest of the mod, then start cutting.
 
  
===Learn to Take Criticism===
+
By doing that,  you will learn two important things:<br>
One crucial thing to learn is to know how to receive criticism about your work. When sharing your work online and with your team, criticism will be inevitable. If someone did not like what you made or suggested a better way to achieve something, there is no reason for you to attack them. Attacking someone just because they did not like your work, or because they suggested something else, is a destructive and toxic behavior, especially if you can't take suggestions from your own team members. Take constructive criticism to heart, and ignore the destructive ones. Taking suggestions from other people doesn't make you less of a person, quite the opposite.  
+
What things you can do with the engine and how to do them so they work well. There will be multiple ways to achieve what you want, but sometimes only one will work without code problems, affecting the performance too much, and other risky stuff. Reading the documentation will also ensure you are not recreating something that is already in the engine and is much easier to use.
  
 +
<!--Switched the section order to flow more naturally-->
 
===Compete With Gameplay and Story===
 
===Compete With Gameplay and Story===
Do not just focus on classic horror, be creative and make mods with interesting story and gameplay. It doesn't even have to be horror to begin with.
+
Remember that most mods cannot compete on a complexity and scale level with commercial products. They were made by teams of artists and developers with years of experience. It can take years to make a mod that has 30% the amount of content that the base games have. Instead of making big mods with dozens of maps, try to come up with engaging gameplay and a story that will be shorter but effective.
The issue with horror games is that it's very hard to make something unique and interesting for players to engage. Horror cannot be repeated, which is why it is recommended to break boundaries. You don't have to worry about the commercial viability of new gameplay styles or bizarre stories, you can try out truly new ideas. Most mods cannot compete on a content level (maps, models, sounds, etc) with commercial products. They've got teams of artists with years of experience. Beat them with your gameplay and creativity. Players will play a mod that has very little in the way of new content, but has interesting story and some new gameplay thrown into the mix.
 
 
 
===Understand the Engine===
 
You really should read the documentation of the game you want to mod. The thing you'll learn most by doing so isn't whether you can do X with the engine, but rather how X should be done so it works well. There will be multiple ways to achieve what you want to create, but only one way would be the best and correct way to do it, without affecting too much on performance, code problems, and other risky stuff. If you learn how to code properly, then you can avoid bugs later in the development of your mod. If you learn how to create materials properly, you will have an easier time altering and adding new materials in the future.  
 
  
 
==Managing development==
 
==Managing development==
Line 41: Line 44:
  
 
===Setting up a Scrum Board===  
 
===Setting up a Scrum Board===  
In short, a scrum board is a board used for keeping track the team's development progress.  
+
In short, a scrum board is a group of lists used for keeping track of the team's development progress. It is used for:
It is used for:
 
*creating tasks
 
*assigning tasks
 
*tracking what is already done
 
*tracking what needs to be done
 
*tracking what is being worked on
 
*tracking bugs
 
  
'''In other words, it's a "to-do" list with more features.'''
+
*Creating tasks
 +
*Assigning tasks
 +
*Tracking what is already done
 +
*Tracking what needs to be done
 +
*Tracking what is being worked on
 +
*Tracking bugs
  
One of the free tools which provides that is [https://trello.com/home Trello].
+
One of the free tools which provide that is [https://trello.com/guide Trello].
A guide to organise a board can be found [http://www.Put-A-Useful-Link.here here].
 
  
 
===Version control===
 
===Version control===
There is nothing worse than having something crash or overwriting a file and losing your progress.
+
There is nothing worse than not being able to track your work or recover older versions of your project.
At the very least - back up your work often.  
+
 
 +
Systems such as [https://git-scm.com/ '''Git'''] help to keep track of changes and back them up. Whenever you ''commit'' your work, a snapshot of the work is saved. In case something goes wrong, you will be able to go back to any older commit. Commits are stored inside a ''repository''.
 +
 
 +
'''One of the most important feature of Git is collaboration.''' Working on all sorts of files with multiple people will get messy very fast if you just send them back and forth. Git allows multiple people to work on the same project simultaneously, and (after setting up) requires only a few clicks to upload your work and update the work of others. It also helps you resolve any conflicts when multiple people edit the same file.
  
However, the recommended solution is ''version control''.
+
'''Read more about [[Setting up an Online Repository]].'''
Systems such as [https://git-scm.com/ '''Git'''] help keep track of changes and back them up. Whenever you ''commit'' your work, a snapshot of the work is saved.
 
In case something goes wrong, you will be able to go back to any older commit. Commits are stored in a special folder called ''a repository''.
 
  
Furthermore, using services such as [https://about.gitlab.com/ Gitlab] or [https://github.com/ GitHub] will let you store your repository online, saving it from accidental deletion or hardware failure.
+
==Online Presence==
 +
You will most likely start sharing your creations before the mod is published. It is recommended to make sure you have something to show off before you create mod pages. Therefore, you should prepare a set of media to preview the mod, as well as coming up with an intriguing description to catch the eye. All of these should make you stay relevant for some amount of time at the very least.
  
'''However, possibly the most important feature of Git is collaboration.''' Working on all sorts of files with multiple people will get messy very fast if you just send them back and forth. Git allows multiple people to work on the same project simultaneously, and (after setting up) requires only a few clicks to upload ("push") your work and download ("pull") the work of others. It also helps you resolve any conflicts when multiple people edit the same file.
+
You will receive feedback and criticism from other users or from your own team about your work. It's important to accept and learn from them, instead of denying, attacking or ignoring such feedback. You grow all the time during development, and your mod's success will be affected by how you react to feedback and criticism.  
  
*Check out guides to Git [[Git guide|here]].
+
''Main article: [[Online_Presence|Online Presence]]''
*You can read about Setting up an Online Repository [[Setting up an Online Repository|here]].
 
  
 
==Finishing==
 
==Finishing==
Line 76: Line 77:
 
'''Make sure your mod was tested by other people just before release.''' It might be surprising, but sometimes things will break even if you can play the entire mod without bugs on your set-up. You can also install a clean version of the game and check if your mod behaves properly there before getting playtesters.
 
'''Make sure your mod was tested by other people just before release.''' It might be surprising, but sometimes things will break even if you can play the entire mod without bugs on your set-up. You can also install a clean version of the game and check if your mod behaves properly there before getting playtesters.
  
Playtests should be performed on the final versions of the mod. ''Don't let team members play from their personal versions of the mod!'' Many hours can be wasted on finding bugs caused by incompatible versions, or realising the reported bug is already fixed and the playtester had an outdated version.
+
Playtests should be performed on the final versions of the mod. ''Don't let team members play from their personal versions of the mod!'' Many hours can be wasted on finding bugs caused by incompatible versions, or realizing the reported bug is already fixed and the playtester had an outdated version.
  
{{tip|Ask playtesters to take notes. This will get you more feedback than without them.}}
+
{{tip|Ask Playtesters to take notes. This will get you more bits of feedback. }}
  
 
===Bugs and Changes===
 
===Bugs and Changes===
Line 91: Line 92:
  
 
==Post-Release==
 
==Post-Release==
So you have released your mod, and soon enough rating and reviews started popping up. Your mod may or may not have been successful, but what comes next is up to you. The best approach is to learn from the feedback you get, see what worked and what didn't, and improve it for the next time. Talk with players, get involved in how they experienced your mod.  
+
So you have released your mod, and soon enough rating and reviews started popping up. Your mod may or may not have been successful, but what comes next is up to you. The best approach is to learn from the feedback you get, see what worked and what didn't, and improve it for the next time. Talk with players, get involved in how they experienced your mod. Don't be afraid if it takes more time than usual to make your next big mod. Good ideas take time to brew, especially for horror games.
 
 
Making horror games is hard, and poses challenges not seen in other genres. It can take time to brew a good idea for a mod, so make sure you let it cook for enough time!
 
  
Knowing what to fix, what to change, and how to listen to your community is a continual learning process.  
+
Knowing what to fix, what to change, and how to listen to your community is a continuous learning process.  
  
 
Good luck!
 
Good luck!
 
==See also==
 
 
*[[:Category:Modding|Category:Modding]]
 
  
 
[[Category:Modding]]
 
[[Category:Modding]]
 +
[[Category:English]]

Latest revision as of 13:50, 8 December 2021

Note icon.png This article is long, but taking the time to read it might help you save a lot of time when making a mod.

This article is designed to give modders things to keep in mind while creating their project. Remember that these are just guidelines intended to help you – you don't have to follow them, but they may teach you something useful.

Starting Out

Scoping Out Your Project

In order to make sure your mod gets released, it is extremely important to make it under a manageable scope. This means that you must avoid being overly ambitious. Creating a project that is too massive will likely end up getting cancelled. Many modders may come up with interesting and big ideas that sound doable on paper, but later realize that it is a lot more work than first anticipated.

The best way to combat this is to create a limited scope from the start. It is much better to be conservative and create a project that is smaller than what you think you can do. A small project is better than a cancelled project.

If you would like to create a big project, it is best to first create a small one, which will give you an idea of how big you can go in the next project. Two small projects will teach you more than a single big one.

Icon tip.png Tip: Don't plan your project with play time or the number of levels in mind. This will end up in having a lot of content left to make and no ideas for it. Instead, gather your gameplay ideas and design around that. It is easier to add onto a complete project than fill an unfinished one.

And remember: quality over quantity. Players will enjoy a unique and well crafted mod even if it is short more than one that is artificially expanded just to be long. You will also have much more fun and satisfaction if you can finish a project before it bores you.

Collaboration

You will need to decide if you are going to work in a team or not. This will influence the scope of the project, so it is be done when starting a mod. A team can of course be brought on after working alone for some time, but that comes with additional challenges.

Working on a mod alone is entirely possible, but working in a team will make it much more bearable. That said, do not assume working in a team is always easier than working alone; there are upsides and downsides. Having a team requires managing it and making sure work is actually getting done, which is a considerable challenge.

Icon idea.png Idea: If you are going to work in a team, make sure to create the mod idea together. An unfortunately popular phenomenon is people joining a team, getting a sneak-peek at the mod and losing interest. Creating the mod premise together can help keep the members invested.

Remember, even having someone to only give you feedback is very helpful. Furthermore, participating in public discussions about modding can help you and others learn. This can be done in the modding channels on the Frictional Games Discord server. Share your work and ask questions!

Main article: Efficient Teamwork

Mod Design

Ask yourself "Why should someone play my mod?". It's a hard question, but if you can answer it well, your mod design has good potential. Think about what other mods are out there, and what they offer. Does your mod offer something new to the players? Is what you offer enough to interest players? Even if you cannot answer these questions, just thinking about it will probably help you come up with ideas.

Understand the Engine

You should really read the documentation of the game you want to mod.

By doing that, you will learn two important things:
What things you can do with the engine and how to do them so they work well. There will be multiple ways to achieve what you want, but sometimes only one will work without code problems, affecting the performance too much, and other risky stuff. Reading the documentation will also ensure you are not recreating something that is already in the engine and is much easier to use.

Compete With Gameplay and Story

Remember that most mods cannot compete on a complexity and scale level with commercial products. They were made by teams of artists and developers with years of experience. It can take years to make a mod that has 30% the amount of content that the base games have. Instead of making big mods with dozens of maps, try to come up with engaging gameplay and a story that will be shorter but effective.

Managing development

When working on a mod, it is important to keep track of your and other's work, while making sure everyone knows what left to be done, what is already done and more. The following section provides tips, links to useful tools and guides which will help you to manage the project.

Keep in mind these are very important even for one-person projects! Keeping track of work always gets one far - it helps you plan and remember things.

Setting up a Scrum Board

In short, a scrum board is a group of lists used for keeping track of the team's development progress. It is used for:

  • Creating tasks
  • Assigning tasks
  • Tracking what is already done
  • Tracking what needs to be done
  • Tracking what is being worked on
  • Tracking bugs

One of the free tools which provide that is Trello.

Version control

There is nothing worse than not being able to track your work or recover older versions of your project.

Systems such as Git help to keep track of changes and back them up. Whenever you commit your work, a snapshot of the work is saved. In case something goes wrong, you will be able to go back to any older commit. Commits are stored inside a repository.

One of the most important feature of Git is collaboration. Working on all sorts of files with multiple people will get messy very fast if you just send them back and forth. Git allows multiple people to work on the same project simultaneously, and (after setting up) requires only a few clicks to upload your work and update the work of others. It also helps you resolve any conflicts when multiple people edit the same file.

Read more about Setting up an Online Repository.

Online Presence

You will most likely start sharing your creations before the mod is published. It is recommended to make sure you have something to show off before you create mod pages. Therefore, you should prepare a set of media to preview the mod, as well as coming up with an intriguing description to catch the eye. All of these should make you stay relevant for some amount of time at the very least.

You will receive feedback and criticism from other users or from your own team about your work. It's important to accept and learn from them, instead of denying, attacking or ignoring such feedback. You grow all the time during development, and your mod's success will be affected by how you react to feedback and criticism.

Main article: Online Presence

Finishing

Before the mod gets released, it should undergo a series of procedures which will make sure the players have the best experience possible. Remember, first impressions matter - having something broken on release can impact the way your mod is received.

Playtesting

Make sure your mod was tested by other people just before release. It might be surprising, but sometimes things will break even if you can play the entire mod without bugs on your set-up. You can also install a clean version of the game and check if your mod behaves properly there before getting playtesters.

Playtests should be performed on the final versions of the mod. Don't let team members play from their personal versions of the mod! Many hours can be wasted on finding bugs caused by incompatible versions, or realizing the reported bug is already fixed and the playtester had an outdated version.

Icon tip.png Tip: Ask Playtesters to take notes. This will get you more bits of feedback.

Bugs and Changes

A complete list of all bugs and changes should be maintained along with their current status. Preferably this should be done in services like Trello. After each playtest, new bugs and necessary changes should be added, and assigned to team members. When a team member has fixed a bug or change, they should submit the new content to the team leader, who should verify that it is fixed and then update the status on the bug list.

Cut or Defer Broken Features

The hardest and unfortunately necessary part of publishing a mod is cutting features. Don't be scared to remove unfinished features - often it can be easier to do that and make sure it doesn't break anything than actually make the feature work.

Beware of feature creep. Make sure feature ideas actually add to the design of the mod and aren't there just because they are cool. It can be surprisingly easy to keep adding features to already existing work instead of actually pushing the development forward.

Cutting features will save you unnecessary time wastes and stress.

Post-Release

So you have released your mod, and soon enough rating and reviews started popping up. Your mod may or may not have been successful, but what comes next is up to you. The best approach is to learn from the feedback you get, see what worked and what didn't, and improve it for the next time. Talk with players, get involved in how they experienced your mod. Don't be afraid if it takes more time than usual to make your next big mod. Good ideas take time to brew, especially for horror games.

Knowing what to fix, what to change, and how to listen to your community is a continuous learning process.

Good luck!