Author
|
Topic: Future goals of videogame translation (Read 1 times)
|
Azkadellia
Guest
|
 |
« Reply #15 on: August 16, 2010, 04:18:11 am » |
|
But most of those guides are woefully outdated. There's better utilities out there than what's listed in said guides.
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #16 on: August 16, 2010, 04:51:11 am » |
|
But most of those guides are woefully outdated. There's better utilities out there than what's listed in said guides.
Case in point: http://www.romhacking.net/forum/index.php/topic,11248.0.htmlPeople still try to use 16-bit DOS programs since those guides tell them too. |
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #17 on: August 16, 2010, 09:42:36 am » |
|
Maybe we need an a flagging option where we can flag guides or utilities as outdated and have suggested alternatives.
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #18 on: August 16, 2010, 12:06:04 pm » |
|
That's probably the type of useful information that should go in reviews of the document! That's certainly the kind of thing it was intended for.
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #19 on: August 16, 2010, 12:21:17 pm » |
|
That's probably the type of useful information that should go in reviews of the document! That's certainly the kind of thing it was intended for.
Though it would probably also not look too good if someone new clicks a link in the getting started section and is then greeted with "Don't bother with this guide"  First we need alternatives, then we can discredit the old stuff  |
|
|
|
|
Klarth
Guest
|
|
« Reply #20 on: August 16, 2010, 12:40:39 pm » |
|
Maybe we need an a flagging option where we can flag guides or utilities as outdated and have suggested alternatives.
I've had the same idea for awhile now. There's a lot of stuff that shows up in a RHDN utility browse that hasn't had a real use in 5 years, if ever, and is archived solely for historical / completion purposes. These utilities would make a good candidate for some sort of "archive" flag in the DB search and are excluded automatically. |
|
|
|
|
Spikeman
Guest
|
|
« Reply #21 on: August 19, 2010, 01:25:57 am » |
|
That's probably the type of useful information that should go in reviews of the document! That's certainly the kind of thing it was intended for.
But the kind of beginner who doesn't look for the newest utilities is probably the same one who doesn't read reviews.  Big red text saying "This utility/document has been marked as outdated, check out the reviews" might be nice. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #22 on: August 19, 2010, 08:25:34 am » |
|
So put the review title 'THIS UTILITY IS OUTDATED' and then we'll make it Red. I'll tell you why a flag doesn't work. There's no reasoning as to why. Let's say guy X decides to flag Atlas as outdated because he either thinks command line utilities are outdated or he's just a troll. Someone else develops a new dumping utility. Now they declare Cartographer is outdated and mark it as such. Unless someone on staff is familiar with these utility, they'd probably approve it. Maybe we are familiar with some, but not the other hundreds of utilities and documents. I think specific reasoning as to why you're declaring something outdated and that nobody should use anymore is very important. Something like this might be self evident if we had release dates on documents and utilities. I thought about this before, but it's probably not possible to determine the release date anymore of the majority of older docs and utilities we already have. |
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #23 on: August 19, 2010, 11:02:50 am » |
|
So put the review title 'THIS UTILITY IS OUTDATED' and then we'll make it Red. I'll tell you why a flag doesn't work. There's no reasoning as to why. Let's say guy X decides to flag Atlas as outdated because he either thinks command line utilities are outdated or he's just a troll. Someone else develops a new dumping utility. Now they declare Cartographer is outdated and mark it as such. Unless someone on staff is familiar with these utility, they'd probably approve it. Maybe we are familiar with some, but not the other hundreds of utilities and documents. I think specific reasoning as to why you're declaring something outdated and that nobody should use anymore is very important. Something like this might be self evident if we had release dates on documents and utilities. I thought about this before, but it's probably not possible to determine the release date anymore of the majority of older docs and utilities we already have. And what stops someone from doing this kinda thing with reviews now...? >_>; ~DS |
|
|
|
|
KaioShin
Guest
|
|
« Reply #24 on: August 19, 2010, 11:05:31 am » |
|
So put the review title 'THIS UTILITY IS OUTDATED' and then we'll make it Red. I'll tell you why a flag doesn't work. There's no reasoning as to why. Let's say guy X decides to flag Atlas as outdated because he either thinks command line utilities are outdated or he's just a troll. Someone else develops a new dumping utility. Now they declare Cartographer is outdated and mark it as such. Unless someone on staff is familiar with these utility, they'd probably approve it. Maybe we are familiar with some, but not the other hundreds of utilities and documents. I think specific reasoning as to why you're declaring something outdated and that nobody should use anymore is very important. Something like this might be self evident if we had release dates on documents and utilities. I thought about this before, but it's probably not possible to determine the release date anymore of the majority of older docs and utilities we already have. And what stops someone from doing this kinda thing with reviews now...? >_>; ~DS Reviews aren't just a check-box, they require explanation WHY something is supposed to be outdated. So people who are later interested in the tool can form their own opinion of they agree or not. A check-box, possibly in bright-red letters would just keep anyone from ever downloading the tool again, no reasons given. |
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #25 on: August 19, 2010, 11:42:48 am » |
|
Well I don't think that the community should be able to determine what is outdated. I think that the staff could decide. It would just be nice to be able to filter by current utilities only. Also you may want to differentiate between DOS and DOS 16-bit since those are no longer supported on current OSes.
|
|
|
|
|
Neil
Guest
|
|
« Reply #26 on: August 19, 2010, 04:40:19 pm » |
|
Perhaps the problem is that as the systems get more complicated, the hacker needs to become a jack of all trades. You need to know file systems, graphics formats, compression formats, video codecs, etc. While those basic functions exist in one sense or another in the 16 bit stuff (enough that the documentation vaguely applies) it is much harder to know and do it all. Maybe we should be stressing specialization and move back towards the team model of translation. Games aren't coded by one person. Why should they necessarily be recoded by one person? Personally I think the concept of a high level overarching book of hacking zen to be an overly complicated idea of probably limited utility. How do you make something that high level for systems that complex? This isn't nuclear science, but it ain't 'how to make toast in 3 easy steps.'
|
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #27 on: August 19, 2010, 04:50:25 pm » |
|
Perhaps the problem is that as the systems get more complicated, the hacker needs to become a jack of all trades. You need to know file systems, graphics formats, compression formats, video codecs, etc. While those basic functions exist in one sense or another in the 16 bit stuff (enough that the documentation vaguely applies) it is much harder to know and do it all. Maybe we should be stressing specialization and move back towards the team model of translation. Games aren't coded by one person. Why should they necessarily be recoded by one person? Personally I think the concept of a high level overarching book of hacking zen to be an overly complicated idea of probably limited utility. How do you make something that high level for systems that complex? This isn't nuclear science, but it ain't 'how to make toast in 3 easy steps.'
I really like this idea. Some people like doing certain things, or have talents in different areas. We could tackle some of the harder projects in less time if we got a bunch of talented individuals together to do something. But I've also seen some of the discussions on (and the thread about it, while it was still around years ago) your attempt to band together for a PSX game before. It would have to be people who can get along, have free time, all of these variables. I'm not one to be pessimistic, but given how the community is, it's probably bound to fail.  ~DS |
|
|
|
|
Klarth
Guest
|
|
« Reply #28 on: August 19, 2010, 10:43:00 pm » |
|
I do like the idea of specialization, but once you get several hobbyists together working on a single project...it becomes more of an experiment in psychology than in romhacking. People have different levels of motivation for projects that lead to different paces. This can be frustrating to the people that are the full steam ahead mode. A project like this needs a strong project manager with a good overall vision of the project's framework and communicate it. They should also attempt to pace the project or at least have rough timelines for certain deliverables. Then tasks would be spread out accordingly among the team.
As far as the review thing, maybe we should find some volunteers that are willing to take over reviewing a whole category of utilities or documents? Might be a good way to jump start it.
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #29 on: August 20, 2010, 08:14:28 am » |
|
I do like the idea of specialization, but once you get several hobbyists together working on a single project...it becomes more of an experiment in psychology than in romhacking. People have different levels of motivation for projects that lead to different paces. This can be frustrating to the people that are the full steam ahead mode. A project like this needs a strong project manager with a good overall vision of the project's framework and communicate it. They should also attempt to pace the project or at least have rough timelines for certain deliverables. Then tasks would be spread out accordingly among the team.
Speaking as someone who has first hand experience in the mega team era of old, working completely by myself at times, and back to more recent partnerships, I can say this is pretty much true. Someone often does seem to get short changed. Whether it's difference in motivation or priorities, lack of keeping promises on delivery, or lack of good management. I am aware of these problems and yet I still find myself contributing to some in my group efforts. It's probably always going to happen to some degree because at the end of the day, ROM hacking (or any hobby) is low priority. If you force it higher, it becomes work. More stringent project management could help the overall project, but it starts putting more aggressive stress on the hobbyist turning it more into work and less into a hobby. That's going to end up counter productive as well. A balance with some loose constraints and soft goals is probably the best you can hope for. I think larger groups on a single project are doomed to fail in most cases, as we saw in the community project experiment and eras of old. While there were some successes and releases in the old days, there's a reason our community's project output ratio went way up afterward when groups became smaller. Success seems to come in more intimate groups of just a few people who mesh well together with their skill-sets and personalities. Wow, we're really drifting around in this topic. |
|
|
|
|
|
RHDN Forum Archive
