I like how even though you don't know much, you still put that little knowledge in use to make me (and others here) explain why things go the way they do. So just felt like saying, you have really got some spirit there! If you want to, you may become a good rom hacker one day.
Err, he doesn't really need to insert anything by himself. He simply needs to keep a copy of the ROM before it's sent out.
I.E:
1) New map needs making, leader gives a copy of the game to whoever is doing it.
2) Leader gets the ROM back and checks to see everything is in working order.
3) Leader copies the updated version and gives it to whoever needs it next
That way nothing is messed up, and nothing gets corrupted. I'm pretty sure that IPS patcher is a sufficient program and errors are caused on the user side.
The way you describe it here, sharing the one and same rom file for others time after another might work in some kind of a situation but it's a very impractical way of doing it here. This would mean the hack wouldn't progress much at the time and team members might either turn lazy or annoyed by not being able to do anything at all.
On the other hand, the team members couldn't provide the project leader with ips patches containg all the data they changed (in certain period of time). Why exactly?
Most of the data in rom must be defined to be there. This is done with pointers. In other words, data couldn't be stored anywhere in rom unless a pointer would be changed to look for the data in that offset. So it it's safe to say (and actually confirm it too!) that IPS patches have some sort of a data structure that contain the offset of where data will be written. To be precise, IPS patches work like this;
Code:
[Offset to write to (3-byte value)][How many bytes to write to (2-byte value)][Data to write to...] // and the same thing loops over and over again....
Then, we have people editing the rom files with programs using dynamic pointers or ones using tools such as FSF (Free Space Finder) for help. There are used to look for free space in rom (if not defined in any way, the "earliest" part of it) where new data could be written. So people just tend to use the offsets/rom addresses those programs give them and input new data in those offsets.
Now, if team members could work on the same rom file (and share it back to the leader when they finish a certain task is), it's very likely they happen to write data in the same rom addresses. Now if the leader uses two ips patches that share even a small part of the same rom area where data is stored, all those new things implemented in the two patch files become "corrupted" in the game.
Basically, IPS (or any kinds of patching formats) is/are not gonna work in this kind of a project. Therefore, the only possible option I see is the project leader forming the hack himself, with the resources brought from the other team members.
Of course the hack could also rely on a disassembly (which would probably be the most efficient way of doing the hack) but none of the team members could understand any of it so this idea would obviously have to be scrapped.
Though I agree with you the leader needs to have some sufficient knowledge, I also disagree. It's a community hack, if someone gets stuck the entire community is their resource not just the leader. I'm sure someone around is willing to lend a hand or has an idea of what's wrong.
In this case, the hack wouldn't become much of an "achievement" but you're probably right, it wouldn't be an obstacle with being able to progress with the hack.
The director could always shoot down ideas and stories that aren't possible, then finally out of the ones that are possible we could make a community decision.
If the storyline writer doesn't have any kind of an understanding behind the hacking process, he or she isn't really needed. Besides...
koolboyman said:
Miksy91 said:
Looking forward to checking out Prism though! It's also good to hear you've put real thought into storyline and planning there. As personal opinion, I think planning and coding should go hand in hand. If you don't have imagination, what is the use of knowing how to program?
Exactly!
Pushing the "all-knowing" project leader to work on the story instead of just using his brain on creating complicated events can develop the guy in a completely different way. Personally, I have no trouble creating even complicated codes from scratch. But a whole different issue is to plan long, storyline-related events, and what happens in them exactly.
Besides, there are a few great hackers out there who already have all the "needs" to become the project leader. Personally, I wouldn't apply for the job as I'm already the project leader of my own hack (which sounds a bit silly but the result isn't really much different); I create things with any kinds of resources available and help out others with their projects. Only thing this job is not containing is the "distribution & building" process which is no way "not-doable".
I don't agree that the leader would have such an unbearable load, but I do agree that he/she/they need to know atleast what they are doing.
It wouldn't be unbearable. The most things the leader did was to build and plan the hack on his/her methods. Of course it would be a good idea to a couple of "side leaders" who would assist other team members who don't know as much as they do. But the project leader would be the one to watch over them though.