17.1 Project and team management
Various terms get thrown about here and the idea is popular throughout society. Although it has in many cases quite rightly been chastised and made fun of there are a few things that can be learned from it. Most people when putting a team together will tend to have people of different skills come together to make hopefully achieve something greater than they might be able to by themselves. There is no unifying idea behind this section but some thoughts and observations.
Translation There are three common roles in translation efforts with the actual translation being one, the editing of the translation for the purposes of the game being another (there might be limits on lengths and screen space) and proof reading (which ideally is not conducted by either of the first two) which can also be amalgamated into general editing. Several translations have attempted to omit the latter (both professionally and in ROM hacking projects) which often leads to a cleanup having to be made later in life. Once again loekalization.com has a lot of interesting things on the matter and Densetsu’s Translation Toolbox is another valuable resource.
ROM hacking Quite often there are two types of hacker on the team and that usually means one to do a lot of the longer winded basics (it is a faux pas to ask for a table for a game unless the game does something odd in the encoding for a reason) and another to help with higher level concepts and maybe assembly with the second maybe not being a permanent team member. Tool development tends to be split between the two groups quite evenly as well.
Artwork and music Nowadays it probably warrants being split into 2d and 3d and maybe fonts as well although most of the time in hacking existing fonts are adapted for use or minor tweaks to the ones that come with a game rather than actual font development happening. Still as things get more detailed (not that 2d has not been that way for decades now) having people on a team solely to deal with artwork and music from the creative side of things is highly suggested.
Level designers Granted with most of ROM hacking typically being focused on translation efforts or solo projects (or would be solo projects with a couple of team members of similar ability) and equally most people that find themselves contemplating hacking a game will usually understand a lot of it at an intuitive level this is not as common a role as it is in general game development or even the likes of modding PC games. However with level editors being made and level editing happening not to mention the idea of total conversions the idea of having a level designer as a team member is perhaps not as alien as it was some time before. Also the idea of game theory and the related psychology has been mentioned a couple of times in the document and related to that is the idea of mechanism design as from a programming standpoint multiplying by 4 is no different to multiplying by 7 (ignoring ideas like overflow and limitations of size) yet an experience generation rate of nearly twice that of another (see some of the third party servers for games like world of warcraft and the criticisms of those when they increase experience multipliers), a score progression twice that of another and especially in games like those that might be described as real time strategy a battle speed of twice that of another makes for a radically different game.
“project manager” In real life this can be a role but as far as ROM hacking goes it is usually a role adopted by a single person within a team (usually one with a fairly limited role or role that is not always going to be needed throughout a project). There have been a few project managers in ROM hacking but in practice it has seemed to be those that might just be lending a few skills to a project (say a hacker capable of text editing and such but less skilled in assembly) or someone that has previously managed a project (very much leading to a catch 22 situation where experience is necessary but getting experience is not going to happen unless you already have it).
Pipeline management The most basic case of this is injection software for text. Your other team members might have amazing skills in other areas and fair levels of technical ability but it might still fall to you. If you have to hand edit 3000 separate files it gets very tedious very fast so automating a bit of that is important and likewise it cuts the other way and if your translator will have to view and edit in a hex editor or deal with a mountain of programming extras it will probably not go well. This is usually where version control and things that might one day end up as Gantt charts appear.