In my years of phpBB MODding, I have always looked at creating MODs as a process. This is correct, you may say. But how do you interpret "process"? In my first few years of MODding I interpreted it different from how I do now. Back then, I created MODs something like this:
- I get an idea.
- I start editting code to get to this idea.
- Gather changes into a file.
- Test it once.
- Release to public.
This might make sense for small modifications, but it is said that it works a lot worse then the following structure:
- I get an idea.
- I write down the idea and the exact features that I want: what does this MOD do?
- I look at points of improvement or conflict and write the points down in a logical order.
- Start scripting according to that order.
- Gather changes into a file and check if something doesn't add up.
- Test the entire thing yourself.
- Does it do what you wrote down in step 2? If not, go back.
Send to a select group of people for more testing.
If thumbs up from small testing group, release to public for more testing.
Why is the second structure better then the first? Downside is that it has more steps and takes more time. But what this technique has over the other is some sort of quality insurance. It makes sure that you will release a product that matches your idea. Also, it adds an extra step of testing to eliminate bugs. This is said to work well for small modifications (Simple Points System) as well as large modifications (Advanced Dungeons & Rabbits). For larger modifications it is more of a requirement. ADR is one of my best examples for this. Up untill now I have tried to do it using the first method, and as some people might know, failed miseraly.
In the next post, I will show you how I wrote my project plan.

