Nintendo have breathed life into an old dog but can it cope with all the gimmicks and new developments in the handheld field? Can our humble GBA compete with the dual screen, touchpad pretender? Can it be sexier than a PSP and do all the tricks it states?
This weekend I went and traded in my old GBA and in its stead I got myself a silver GBA Micro. Probably a crazy thing to do but the Micro for me just seemed perfect and simply irresistible. In looks alone it makes the PSP look like it's been hit with the ugly stick.
I got home and I endured a wait for it to fully charge, pouring over the literature in the box and the various additional things the shop gave me. The wait was well worthwhile, I was in for something sublime.
By the time it was ready it was dark out and I hadn't turned on any lights. I turned the Micro on anyway and I was blown away. The screen was clear and bright, it seemed as though Nintendo had finally produced a portable system. I had been playing Mario and Luigi: Superstar Saga on my old GBA and was slightly worried about the text being squashed or small. If anything it's easier to read now without having to catch the light correctly. I went through quite a few games and I noted that all seemed to work perfectly, if anything they were enhanced by the screen, despite it being smaller it was clearer.
The controls are great now too. The d-pad and buttons are slightly soft, but it's not a problem as it's more of a feel issue and personally I've gotten used to it and don't even pay mind to it now. The way the shoulder buttons are set are also a great consideration. The buttons are set to be activated by pushing nearer the middle of the console, as opposed to being easier to push from the outside. This makes it a lot more comfortable when playing as more of your hand is supporting the console and your fingers are not set at odd angles.
The main thing about a handheld should be portability. How easy is it to take around and play on the go. It's all fine a company releasing a handheld but not many have seen me take it out and about. I've not taken my old Gameboys out much in the past just due to the size of them (and issues with lighting). Unless I was carrying a bag it wasn't always so easy to store in a pocket and well I rarely carry a bag. The DS and PSP fall into this category, although I'm not sure I'd really take a PSP with me at all.
With the Micro though, it's a true handheld. I can take it anywhere and not worry about the lighting or if I've got a bag or not. This fits easily into any pocket already reserved for something else. If that wasn't enough the neckstrap works a wonder also, or the keyring pouch. It is amazing, it's the first console that is portable and that you can take with you anywhere, even if it is only for a 5-10 minute blast, you are able. With the UMDs on the PSP I've found by the time you've fired it up and got a game loaded, it's time to shut down as you've reached your stop. The GBA SP was probably the closest thing to a portable console but it didn't find favour with me as it was such an odd shape and didn't give the comfort needed, plus the lack of in-built headphone socket soured me.
Basically what I am trying to say is that the GBA Micro, over any other handheld in the past, is truly a portable device. It'll fit anywhere and play anywhere, with the bonus that you can stick in any headphones you like without needing attachments. It's extraordinary and definitely something that'll win you over in an instant of seeing one. If anything my love has grown for it owning one over just playing with one in a shop or at a friend's place. Not only that, it has gotten me lots of attention whenever I've played on it in public. Seems my statement at the start regarding the PSP being ugly is shared by quite a lot of others.
Now onto step two. Bolster my GBA collection and look into some gimmicks. Namely, I intend to see if the Micro can out PSP a PSP with the Play Yan attachment.
Saturday, January 14, 2006
Sunday, January 01, 2006
OP4 Yuugure no Aka
So I had my say on the whole process of our first fansub. It was an interesting process and good fun but it wasn't without mistakes. There were a few things I learnt that I hope we don't repeat again in future.
The thing that I noted when I started on this was how sort of possessive I got. As I said before the translation was done by Yume but in our QC (quality check) process we ended up doing some rewrites. This helped make me feel more instrumental in the project, when I could suggest something and have it acted upon. It was good that I could question any line and Yume would go ahead and check it out without any fuss, even if it was the tenth time I had queried that line in the last five minutes. He probably got sick of my constant questioning. Just a note, the idea of QC used here may differ wildly from your ideas so bear in mind my previous entry.
Anyhow with that said, you feel it becomes part of your work and as such I didn't want to put my name on it unless I was comfortable with the standard. It is probably laughable but I felt as though my name was a stamp of approval and I had to make sure everything was good enough for my perfectionist standard.
In keeping with this my first real annoyance and our first real problem was with the way we handled the iteration of scripts. At first we had scripts flying about all over and just as you make notes on what to discuss and change with Yume, he'd got further on in and also gone back and changed lines. So I was basically making new notes from new scripts each day. I think we finally got an understanding when I became frustrated and commented on how disrupting it was. Still when I was sent the final script, we were still working from slightly different versions, something I didn't find out until later on. There were a few problems that came about to this specifically which I'll raise later.
This is the first lesson then. Don't start work on QC until you have a script locked down in place.
So once you have a script locked down and distributed the exact same copy to both, the next step is to check for errors. We went about it raising questions as we went along. If something didn't fit we made a note. In the process of this we raised questions about spelling, grammar, sentence structures and all sorts. Something may just sound wrong out of context, so it helped me greatly to ask Yume for more explanation to help me. This leads to him to evaluate how close he is and whether or not he fully understood it. It also lead to me thinking about it in a different way and opening up other meanings he may not have got off the bat.
No matter what it was or how small, you have to raise a flag and go about working out why something is what it is. On the basis of not understanding why a sentence was structured like it was, trying to understand what was being said or just wanting to know other possible translations for a word, we came across errors in translation or alternative translations which may fit better. If not it helped to rework the current line to be clearer or more apt.
The second lesson then is never be afraid to question anything, no matter how silly, small or insignificant it may seem.
When I was watching through the release we made, there was still quite a few errors that I saw. Not a great many but enough to irritate me as I wanted to be perfect. I think that's due to one main factor. We were striving for a release before Christmas Day so we didn't really watch the final encode to allow us that final pass. It shows as some of the things we would have picked up on are missed. You have a structure set in place and having deviated it highlights problems that arise. It's a one-off and I doubt we'll see something similar happening again but it's probably best we went through such a thing now rather than on a later release when we should have learnt.
I guess it's an obvious thing but that is the third lesson. Don't go skipping steps to rush a release out.
The way we worked our way through, it was very collaborative. We both made notes and consulted each other where we thought changes should be made. Where we had errors creep in, was when we made changes away from this collaborative process. This meant when we went back later there were things we made changes to but didn't note to the other. It is a lot faster to work solo when doing this and make changes as you go, without the need to justify things to the other. Some things can be cut and dried but even the most simplest things can turn out to be a problem.
I'm not so sure where I stand on this. As I say it's quite a bit faster solo but easier for errors to creep in. However, should everything be undertaken together and slow the process right down? Drawing things out can be just as bad as rushing things. Not sure what lesson to take from this but I'm sure this is something to work on as you go through more subbing.
So only a few things and it's probably common sense, but without a guideline in place it can all become muddled. I'm pretty sure for whatever we tackle next we'll be much more in tune with what is needed. Not only that, we'll probably be doing something which is shorter in length even if it is episodal. There is less stagnation and it's easier to manage and feel like progress is being made when you are getting continual releases. We'll see how it goes when Yume does decide on a new project and whether or not we get more people on board to help out.
The thing that I noted when I started on this was how sort of possessive I got. As I said before the translation was done by Yume but in our QC (quality check) process we ended up doing some rewrites. This helped make me feel more instrumental in the project, when I could suggest something and have it acted upon. It was good that I could question any line and Yume would go ahead and check it out without any fuss, even if it was the tenth time I had queried that line in the last five minutes. He probably got sick of my constant questioning. Just a note, the idea of QC used here may differ wildly from your ideas so bear in mind my previous entry.
Anyhow with that said, you feel it becomes part of your work and as such I didn't want to put my name on it unless I was comfortable with the standard. It is probably laughable but I felt as though my name was a stamp of approval and I had to make sure everything was good enough for my perfectionist standard.
In keeping with this my first real annoyance and our first real problem was with the way we handled the iteration of scripts. At first we had scripts flying about all over and just as you make notes on what to discuss and change with Yume, he'd got further on in and also gone back and changed lines. So I was basically making new notes from new scripts each day. I think we finally got an understanding when I became frustrated and commented on how disrupting it was. Still when I was sent the final script, we were still working from slightly different versions, something I didn't find out until later on. There were a few problems that came about to this specifically which I'll raise later.
This is the first lesson then. Don't start work on QC until you have a script locked down in place.
So once you have a script locked down and distributed the exact same copy to both, the next step is to check for errors. We went about it raising questions as we went along. If something didn't fit we made a note. In the process of this we raised questions about spelling, grammar, sentence structures and all sorts. Something may just sound wrong out of context, so it helped me greatly to ask Yume for more explanation to help me. This leads to him to evaluate how close he is and whether or not he fully understood it. It also lead to me thinking about it in a different way and opening up other meanings he may not have got off the bat.
No matter what it was or how small, you have to raise a flag and go about working out why something is what it is. On the basis of not understanding why a sentence was structured like it was, trying to understand what was being said or just wanting to know other possible translations for a word, we came across errors in translation or alternative translations which may fit better. If not it helped to rework the current line to be clearer or more apt.
The second lesson then is never be afraid to question anything, no matter how silly, small or insignificant it may seem.
When I was watching through the release we made, there was still quite a few errors that I saw. Not a great many but enough to irritate me as I wanted to be perfect. I think that's due to one main factor. We were striving for a release before Christmas Day so we didn't really watch the final encode to allow us that final pass. It shows as some of the things we would have picked up on are missed. You have a structure set in place and having deviated it highlights problems that arise. It's a one-off and I doubt we'll see something similar happening again but it's probably best we went through such a thing now rather than on a later release when we should have learnt.
I guess it's an obvious thing but that is the third lesson. Don't go skipping steps to rush a release out.
The way we worked our way through, it was very collaborative. We both made notes and consulted each other where we thought changes should be made. Where we had errors creep in, was when we made changes away from this collaborative process. This meant when we went back later there were things we made changes to but didn't note to the other. It is a lot faster to work solo when doing this and make changes as you go, without the need to justify things to the other. Some things can be cut and dried but even the most simplest things can turn out to be a problem.
I'm not so sure where I stand on this. As I say it's quite a bit faster solo but easier for errors to creep in. However, should everything be undertaken together and slow the process right down? Drawing things out can be just as bad as rushing things. Not sure what lesson to take from this but I'm sure this is something to work on as you go through more subbing.
So only a few things and it's probably common sense, but without a guideline in place it can all become muddled. I'm pretty sure for whatever we tackle next we'll be much more in tune with what is needed. Not only that, we'll probably be doing something which is shorter in length even if it is episodal. There is less stagnation and it's easier to manage and feel like progress is being made when you are getting continual releases. We'll see how it goes when Yume does decide on a new project and whether or not we get more people on board to help out.
Subscribe to:
Comments (Atom)
