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

From Frictional Wiki
Jump to navigation Jump to search
m (→‎Collaboration: Misc style touch-ups)
(→‎Working on the Mod: Expanding on version control)
Line 28: Line 28:
 
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.  
 
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.  
  
==Working on the Mod==
+
==Managing development==
When working on the actual mod, it is important to be able 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 links to useful tools and guides which will help you to achieve that.
+
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===  
 
===Setting up a Scrum Board===  
In short, a scrum board is a board used for keeping track the team's development progress. It is very useful for assigning tasks, tracking what was done and what needs to be done, tracking bugs and backlog features.
+
In short, a scrum board is a board used for keeping track the team's development progress.  
One of the free tools which provide that is [https://trello.com/home Trello] and is recommended when working on mods.
+
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.'''
 +
 
 +
One of the free tools which provides that is [https://trello.com/home Trello].
 +
A guide to organise a board can be found [http://www.Put-A-Useful-Link.here here].
 +
 
 +
===Version control===
 +
There is nothing worse than having something crash or overwriting a file and losing your progress.
 +
At the very least - back up your work often.
 +
 
 +
However, the recommended solution is ''version control''.
 +
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.
 +
 
 +
'''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.
  
===Setting up an Online Repository===
+
*Check out guides to Git [[Git guide|here]].
You can read about Setting up an Online Repository [[Setting up an Online Repository|here]].
+
*You can read about Setting up an Online Repository [[Setting up an Online Repository|here]].
  
 
==Finishing==
 
==Finishing==

Revision as of 18:53, 25 July 2020

This article is designed to help anyone who considers making mods for any of the games made by Frictional Games.

Collaboration

Working on a mod alone is entirely possible, but it is recommended to assemble a team. Whether you need help with level design, programming or something else, it is a good thing to have someone to rely on. However, that requires managing the team and making sure work is actually getting done. And if you can't get people to work on your mod, keep in mind that even having people who only give you feedback about your ideas is still very helpful.

VERY IMPORTANT: If you are going to work in a team, make sure to create the mod idea together. An unfortunately popular phenomenon is people joining mod development, getting a sneak-peek at the mod and losing interest in working on it. Creating the mod premise together will keep the members invested.

Your first instinct might be to invite anyone who wants to help - however, a good practice is to keep the team small. Adding more people to the team does not mean more work will get done. The more people you have, the more time gets spent managing them.

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 the FG Discord server. Share your work and ask questions!

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.

Realistic Goals

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.

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

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.

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. 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

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 board used for keeping track 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

In other words, it's a "to-do" list with more features.

One of the free tools which provides that is Trello. A guide to organise a board can be found here.

Version control

There is nothing worse than having something crash or overwriting a file and losing your progress. At the very least - back up your work often.

However, the recommended solution is version control. Systems such as 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 Gitlab or GitHub will let you store your repository online, saving it from accidental deletion or hardware failure.

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.

  • Check out guides to Git here.
  • You can read about Setting up an Online Repository here.

Finishing

Before the mod can be released, it should pass a series of procedures which will make sure the mod is clean of bugs and stable enough so it can be played by the public.

Playtesting

From now on, you should be running Playtests on the mod whenever possible. Playtests should be performed on the versions of the game in which you want to release. 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.

Bugs and Changes

A complete list of all bugs and changes should be maintained, and their current status. Preferably this should be done in services like Trello. Notifying bugs on platforms like Discord is totally insufficient for tracking bugs; it's just too easy for the messages to stack up and get lost. After each playtest, the bugs and necessary changes from the log file 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 mod creator, 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 most necessary part of shipping is the act of being realistic and cutting features. Your mod simply cannot have every cool feature and still ship in a reasonable time frame. The creator of the mod should make decisions about what to finish and what to cut, based on how far along in the release process they are.

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.

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.

Good luck!

See also