Team building guide

[0]

This is Version 0.1.0 of this guide.

I feel that for beginning hackers, there are many things they seem to miss out on early on. So, I have some things that I would like to clear up.

What I am hoping to achieve with this tutorial is to answer two main questions:
"How can one best go about creating a ROM hack either solo, or as a team?"
"How can one make a modular hack? That is, a hack that can be scaled to greater proportions as time goes on and more people join."

My reasons/justifications:

Spoiler:

The reason I made this is because many people have great ideas that could be really awesome, and are unique, like Pokémon Mars, but they don't have any organization or foundation to back them up.

I've been working on the Pokémon Conjure team, and early on I realized that there would need to be some kind of system in place.
Somethings I thought of when beginning to organize it are this:
How can we best express our ideas? How can everyone work at the same time? Can we revert back to some point in time? How can everyone prevent collisions when working on the same game?

Also in particular, what I would have liked when scripting/mapping/whatever is to know this:
What memory region can I work with? What areas are reserved, if any? Do we have a system that tells me what flags have already been used so I don't break anything?

These are things that can make or break a team, and even a solo project. They are things that can cause team members to drop out or you to just quit working because there is no foundation or structure in place to build upon and it becomes a jumbled mess.
It's like trying to make a building with no foundation on prone earthquake area. There is no doubt that when that earthquake comes, the building will crumble.

In short, what people miss out on (this is also what I feel defeats community projects as well) is early organization. From the offset, one should have some system in place.
I've learned very quickly that some kind of organizational system is very much key, and this is especially true when working on a team.
Many people, I feel, seem to neglect this fact, and just jump right in because they have a great idea without laying out a framework.

One more thing this guide should help with. If you have no organization and have to stop the project or leave due to family issues, and you come back, you probably wont remember much at all because you didn't leave yourself anything to go on, it might be so jumbled that you might have to re-do everything when you come back, or even worse, just simply drop the project.

Those are my justifications for why I am creating this guide, and I hope it helps at least one person. Some of these points will reiterate some of the above, but you should still read through them anyway.

1. Organization

Spoiler:

This section is a section of it's own about the most important thing in a ROM hack, organization.
Ideally, you want some way for everyone to work together, and make changes to the project, without breaking the main release.
With that in mind, here are some VERY important things about the subject.

A. Make a Git!

Spoiler:

A Git is a Version Control System (VCS) which saves a snapshot of your project every time you update the Git.

They can look difficult at the beginning, but TRUST ME, they are so worth it. So so worth it.

In short, it allows you to back up and restore from ANY point in time all the files from that update, even the most minute changes.

B. Make a Github!

Spoiler:

Github is a website that allows you to store your Git online so that anyone on a team can work on it from anywhere

This is very useful as collaborations will skyrocket to new proportions, and since it's a git, even if someone on the team deletes the game, you can always restore it by reverting it back to a previous change.

I can't give you a guide in this small space, but there is one located here: https://nathanj.github.io/gitguide/tour.html

Even though it was made in '09, it is still valid, and helped me with everything to make my own project.

ONE MORE THING!

This is possibly my favorite part about Github. Your project gets a free website through what they call Github Pages.

That means that anyone who is interested in your project can check out all of its features.
When it's released to the public, I will put a link to a project page here.

C. Make a project Forum.

Spoiler:

A forum is what Pokecommunity is. There are some free forum websites out there, like Proboards.

Here is an example: https://pokemonconjure.proboards.com/

D. Keep a list of already used flags and variable values.

Spoiler:

This is very important, especially as one builds a team. If four scripters are working on a specific part of the map, what will happen if everyone uses the flag 0xFLAG? Glitches will happen. It'll be set at a wrong time, key items aren't given, etc.
This list tells anyone working on the project what has been reserved and for what. If you assign your first work flags 0x900 - 0x91F, he has 32 flags to work with, and can't possibly run into another team members flags if they are assigned block 0x920 - 0x93F. If he would need more he would request it and you could give him a new block, like 0x940 - 0x95F, which is unused by another team member.

E. Try to follow some kind of notation system for scripts.

Spoiler:

A notation system is key on your scripts. By explaining its purpose at the top and making notes on lines that might be hard to understand, or every line, not only will you be able to better read it, others will as well. This is especially key when working on a team.
Also to make the notation system, just use comments that are not complied. In X.S.E, you simply type (') (the apostrophe) at the end on a line of code and anything after that is a note.
In X.S.E, when you compile a script with these notes, it doesn't effect your system because any non-code isn't compiled.

If you lay down these notes, then if you leave the project and come back to it, you can quickly know what you have written.
In addition, if you're on a team, if you have someone new, they can follow clearly laid down notes and build new scripts using the old ones, like a template.

The danger of not adding notes is when you come back to the project, you might just quit out of the sheer amount of lines that blur into one because you have no idea what they do or mean.

Finally, this one is for teams. Take the example of someone who is a really experience scripter who can make anything happen. You decided he is so good that he should be in a leading scripting position, in charge of 5 other scripters. When this leading scripter has to review code that inexperience scripters make with no notes, because they won't follow any kind of system, the leading scripter won't even know where to begin in the script, or what it even does. If they have no notes to go on, they won't be part of your team for too long because they would have to remake the bad code that newbies make, and it's not fun, trust me.

F. Trying to get info from a compiled source is difficult, make a text file system.

Spoiler:

As your hack gets bigger and bigger, you'll start having a game with so much going on that if you don't keep the plaintext noted scripts themselves backed up, you have a LOT of work to do to fix the issue should the ROM fail and be unrecoverable.

Keeping a good folder organization is key. Something like "Towns > Town name > Scripts > Level scripts" Is very useful.

For the scripts themselves inside the folders, for there names I do a naming convention of "Example Town - Area in town - Room in house if needed - Script type (level, person, etc) - Tile area or person name/description.txt"

My example: "Friendly City - Outside - Person - Old Lady by Lamp.txt"

While the file name looks long, it is much easier to find when I'm looking for a specific script, and I can just search for it.

2. Try out an IRC for group projects.

Spoiler:

An IRC is a really quick method of communication that can allow people to easily work on a project together in real time. It's very simple to make a channel on any free server. It is also much easier to handle then a hundered different PM's on Pokecommunity and it can be your own private space.

3. Make template scripts.

Spoiler:

I've personally decoded quite a bit of Fire Reds scripts, from the Magikarp guy to the elite four. I have noticed that you can create a specific pattern for reoccurring events.

For instance, If you want a total of 30 NPC's in your hack to give the player a Pokémon, you don't need to recreate a give Pokémon script 30x times. Instead, it would be best if you wrote a single, well notated script. You could change a few strings and a variable and make an entirely different person give a new Pokémon with the same template.

Again, the key here is a well notated template script.

4. Learn everything.

Spoiler:

If you want to become competent in ROM hacking you should learn how to do things on your own, even when on a team. If you're great at scripting, but are really bad at making maps, learn how to do it. You should have some knowledge of every aspect of ROM hacking.

If you're solo, this will make you're ROM great, exactly how you like it. On a team, this makes you less reliant on a team members temperaments, and also makes you able to review each team members work before actually putting it into the game.

5. Patience.

Spoiler:

You will need a lot of this. Think of it as being in the long haul from the start, depending on the depth and length of the hack that you will be making.

6. Be careful when mapping.

Spoiler:

Many people seem to make mistakes in their ROMs. Either they don't proof read it, or don't care, and personally, it looks bad if a path is blocked or someone can step through a tree.

7. Choose a ROM base(s) in the beginning.

Spoiler:

Seriously, don't add one later only to find out that, oops, it erased half your scripts or half your maps. Make sure you figure it out first, or it can cause enough headache to make you quit the project.

These little things are what can make or break a hack and a team.

Final note:

Spoiler:

I don't want to see another team oriented project go down because they had no system and no way to add new members because the entire project became a cluster of information and nothing tangible.

That's the end of the guide for now. I'm open to constructive criticism, so please let me know what you think and how I could improve upon this guide.

Let me know if it should exist, not exist, if you like it or hate it, whatever it is in the comments. It's appreciated regardless.

Thanks for reading and happy hacking!

 

[Vagrant Pixels]

Thank you very much for this.

It clears up many things, and I read it just before something big happened.

 

[0]

Well thank you very much Vagrant Pixels, I am glad it helped.

 

[illumine]

The title might be misleading, as the bulk of the post doesn't deal with team building primarily.

 

[0]

Illumine, what would be a better title, should I be able to change it?

EDIT: Maybe "A beginners guide"?
I can't really think of a better name, as that really what it's about. Basically the thread is some points I've noted and expanded on here from working on a team myself.
When people can't think of a plan right from the offset, they can really mess up a team, as no one knows what is going on.
However, when one organizes it from the beginning, and everyone knows what's up, things can work a lot better.

 

[0]

The guide has now been updated. It is now better organized and also has better points then the previous version. To those whom read my first version, I'd suggest reading this one. Thank you!