|
Thankfully no on has shot giants at us out of a cannon yet.
|
#
?
Apr 19, 2020 02:46
|
|
|
|
| # ? Apr 25, 2024 21:12 |
|
|
Fun fact: the Pirate and Kaizoku enemies had their names flipped around in translation. Later translations would change the Kyzoku (JP: Pirates) to Buccaneers or Privateers, keeping the same idea of a weirder name for a pirate since Pirate was already used.
|
|
#
?
Apr 19, 2020 03:39
|
|
|
 OK. So. This guy. If you've played a lot of video games from this era, you're probably familiar with the way Japanese companies often encouraged, or forced, their dev teams to use pseudonyms in the game credits. You might think this is yet another example of this, but nope! NASIR is Nasir Gebelli, an Iranian-American that is low-key one of the most brilliant coders of the time and one of the most important people in Square's early life. Also he's technically royalty. Nasir got his programming start alongside the rise of microcomputers in America in 1979-80 or so. Inspired by arcade games, he was one of, if not the first, programmer to get fast action games to work on the Apple II and arguably launched the Apple II game industry. He co-founded the company Sirius Software, and churned out like a dozen games a year. The reason he was so productive is that he's a literal savant. Nasir's preferred programming style is to sit down and think about the project, work out all of the code in his head, and then type out an entire assembly language program in one go because he just can't be bothered to write down any loving notes. He was personally successful enough to split off and form his own publishing company, Gebelli Software, just in time for the video game crash of 1983. When Gebelli Software went bankrupt, Nasir decided to just gently caress off and tour the world for a while. A few years later, he decides he wants to get back into programming, and his industry friends tell him about the amazing new Nintendo Entertainment System, and also they know a little company called Square that's looking for programmers. Nasir didn't know anything about the NES, nor did he speak any Japanese, so obviously this sounded like a perfect idea and he went for it. Square didn't have a translator on staff, but they could recognize a mad genius when they saw one and hired him. At Square, Nasir programmed some games that were mostly tech demos. 3-D World Runner and Rad Racer were basically tech demos, showing off 3D effects that the NES wasn't ever meant to do. When Hironobu Sakaguchi decided he wanted to make an RPG, he had trouble getting staff at Square to join his team. He eventually managed to sign on a 7-man "A-team" to start the project, and every single one of the team is worth an effortpost in their own right. Sakaguchi as director, Koichi Ishii and Akitoshi Kawazu as designers, Kenji Terada as scenario writer, Yoshitaka Amano as character designer, Nobuo Uematsu as composer, and our boy Nasir as the programmer. There were a few minor obstacles that Nasir had to overcome. For one, he still didn't speak any Japanese and Square still didn't have a translator. Also, Nasir had never heard of RPGs before. At all. Not even Dungeons and Dragons. At first he tried to understand all the aspects of gameplay, but apparently he just couldn't get it, so eventually Sakaguchi just told him to implement the design notes as written. And there we have it. The core explanation for why Final Fantasy's game mechanics are so janky even though the game is a technical marvel: the game was coded by a supergenius who had no idea what he was doing. Nasir went on to help program FF2 and 3, and then he took a nap for a while, and then roused from his slumber to code Secret of loving Mana. Probably in one sitting, and probably without writing down a single note. Since then, Nasir's been basically living off of royalties and staying out of the public eye. I think he hangs out with John Carmack sometimes. Oh, final note: That slider-puzzle mini game? No one asked Nasir to do that. He just got bored or something and stuck it into the game.
|
|
#
?
Apr 19, 2020 04:10
|
|
|
Tendales posted:Oh, final note: That slider-puzzle mini game? No one asked Nasir to do that. He just got bored or something and stuck it into the game. I wonder if thats why the payout is so lousy. "Hey, it took me 3 minutes to write this, it should take you 3 minutes to solve it, so you don't deserve that much of a prize"
|
|
#
?
Apr 19, 2020 04:31
|
|
|
According to Wikipedia, that slider game is the first instance of a mini game in an RPG despite not being referenced in the main game and not even accessible except through the secret developer button code.
|
|
#
?
Apr 19, 2020 04:34
|
|
|
But yeah, Nasir was a big big deal. To the point where he (allegedly) told Sakaguchi no in regards to something in FF2, and not only brought him back for FF3, but moved everyone on the team to America so he could finish it.
|
|
#
?
Apr 19, 2020 04:42
|
|
|
Was the thing he said "no" about the Ultima bug? To this day that's one of my favorite RPG development anecdotes and to know that this guy was behind it... explains a lot, really.  (Story: That Ultima only did about ~500 damage and didn't scale with any spell level, not even its own, was known about in development. Sakaguchi wanted the bug to be removed, but the programmer (apparently Nasir?) justified it by saying that "legendary stuff that dates back to an age before 'proper techniques' would look inferior from present's point-of-view", and the programmer thought that was realistic. Sakaguchi didn't agree, but he couldn't do anything about it because the code was ciphered.)
|
|
#
?
Apr 19, 2020 05:38
|
|
|
Even Richard Garriott has sung Nasir's praises, so he's definitely not just a legend in NES circles.
|
|
#
?
Apr 19, 2020 05:54
|
|
|
The ultima thing was the other major programmer on 2, Hiromasa Iwasaki.
|
|
#
?
Apr 19, 2020 06:26
|
|
|
Tendales posted:
|
|
#
?
Apr 19, 2020 09:19
|
|
|
PMush Perfect posted:Can I link this in the OP? Sure!
|
|
#
?
Apr 19, 2020 13:13
|
|
|
As great as he is, this: Tendales posted:Nasir's preferred programming style is to sit down and think about the project, work out all of the code in his head, and then type out an entire assembly language program in one go because he just can't be bothered to write down any loving notes. Is probably why the game is a buggy mess on par with the original Pokémon games, with it being a miracle it even runs. That, of course, just reinforces how much of a badass he is.
|
|
#
?
Apr 19, 2020 14:22
|
|
|
That story reminds me of The Story of Mel. Ironically, if you show most experienced programmers that story, they'll come away from it thinking "Christ, what an rear end in a top hat Mel was" more than "drat, Mel was good". Because no matter how good your skills are, you need to be able to work in a team, and code that only you can understand or modify is antithetical to that. I'm not saying that Nasir was an rear end in a top hat or that their code was in as sorry a state as Mel's was, to be clear.
|
|
#
?
Apr 19, 2020 14:55
|
|
|
LiefKatano posted:(Story: That Ultima only did about ~500 damage and didn't scale with any spell level, not even its own, was known about in development. Sakaguchi wanted the bug to be removed, but the programmer (apparently Nasir?) justified it by saying that "legendary stuff that dates back to an age before 'proper techniques' would look inferior from present's point-of-view", and the programmer thought that was realistic. Sakaguchi didn't agree, but he couldn't do anything about it because the code was ciphered.) I wish I could say something like this at work and have my bug-ridden code accepted. Instead any time I've tried I've gotten my boss angry at me. Maybe I'm just bad at lying.
|
|
#
?
Apr 19, 2020 15:07
|
|
|
I suspect that the excuse was given mostly because trying to debug assembly even with modern tools is a tedious slog and there is a very real chance that it was both noticed beforehand and attempted fixes had caused massive problems elsewhere, because that is a pretty elaborate excuse for spur of the moment. Forcing a fix may have also caused potential issues in terms of releasing on time, so it may have been dropped just because it wasn't game-breaking or there were bigger problems to fix in the limited time they had. Assuming that the story actually happened as told, which I'm less sure of. Not that those involved deliberately lied, mind, but rather that time papered over details.
|
|
#
?
Apr 19, 2020 15:35
|
|
|
I remember reading The Story of Mel ages ago, but had forgotten the details needed to find it, so thanks for that. There are so many kinds of genius in the world of programming, and I think they're all useless unless paired with equal genius in communication. I've worked with people in similar skill levels - lots of skill in repeating the problem statement in many different ways and describing how much work they're doing to investigate the problem, but unable to provide any detail. The really good ones do eventually turn in a solution, but it's a mess of changes and mismanaged states that make the development process obvious - they make a change, run the program, find a problem, and fix the problem, never bothering to go back at the end to see whether any of the conflicting changes suggest an easier approach. I got one where I couldn't even follow the logic, so I called a team meeting for the developer to explain the change to us, with diagrams and pictures. Once I understood what his solution was, I rewrote the whole thing in a couple of lines and ended up with the same result. He'd gotten so wrapped up in handling edge cases that he missed a simple fact that made the whole thing neat and tidy. The actual solution method was brilliant - the execution just took the long route to get there. This is why I like to lean on processes that include peer reviews, thorough testing, and the ability of anyone on the team to (responsibly) set a roadblock that must be cleared by unanimous consent before we can proceed. At the very least, we'd be testing every spell to make sure it works properly, especially if we change anything that might affect it, and at least two other people would have to inspect any bug fix to reduce the chances of any of the changes creating other problems elsewhere. However, that kind of budget, schedule, and team probably didn't exist in the NES days. It also would have made for significantly fewer amusing speedruns and exploits.
|
|
#
?
Apr 19, 2020 20:43
|
|
|
It's also significantly harder to do stuff like that when you're programming in assembly.
|
|
#
?
Apr 19, 2020 20:46
|
|
|
Nidoking posted:He'd gotten so wrapped up in handling edge cases that he missed a simple fact that made the whole thing neat and tidy.
|
|
#
?
Apr 19, 2020 21:22
|
|
|
on top of all the usual tangles involved in early game dev, in assembly, on an 8-bit computer designed to be affordable in the mid-80s, there's the language barrier imagine having to sort all this out with your programmer using a second language you don't regularly use and barely remember from high school how much pantomime do you think was involved
|
|
#
?
Apr 19, 2020 21:51
|
|
|
ultrafilter posted:It's also significantly harder to do stuff like that when you're programming in assembly. It really doesnt matter what language youre working in if its an organisational or institutional issue. It much more a result of this being a last ditch seat of the pants dev process. And the things needed to create a structure that supported good coding practice and reviews would have taken precious time, money and expertise, which as an almost failing dev studio they have most def lacked. And Especially when your star coder is notoriously uncooperative. Game dev now is large enough that you cant really have one savant doing everything, and enforcement of good practice is absolutely necessary. (Until crunch time [memo:crunch time is now permanent] that is.) These kinds of concerns are entirely why Sony and playstation exploded the way it did, they provided ample support to third party devs and kept updated documentation about the PS1 available online, which then let all kinds of studios make games leading to a staggeringly huge library relative to its counterparts (1300 ps1 vs 296 N64) Rigged Death Trap fucked around with this message at 22:07 on Apr 19, 2020 |
|
#
?
Apr 19, 2020 21:57
|
|
|
Rigged Death Trap posted:Game dev now is large enough that you cant really have one savant doing everything
|
|
#
?
Apr 19, 2020 22:01
|
|
|
Well AAA, though yeah the FF1 dev team were working in practically indie conditions. Indies generally arent constrained by release times until they strike a deal with a publisher. For example: FF7 apparently had anywhere from 100 to 150 people working on it, FF7R I wouldnt be surpised if that figure is 2 to 3 times that. You could totally have had 10 people work on FF7R if you were fine with it taking 20 years
|
|
#
?
Apr 19, 2020 22:15
|
|
|
ultrafilter posted:It's also significantly harder to do stuff like that when you're programming in assembly. Rigged Death Trap posted:It really doesnt matter what language youre working in if its an organisational or institutional issue. I'd also add that just because modern disciplines have trouble dealing with raw assembly code doesn't mean that best practices in the 80s (and early 90s!) couldn't. Even though they had less memory to work with on the 8-bits, the programs I've taken apart for them make much more consistent use of memory than a modern program would, even when this ends up using double or triple the amount of space they'd technically need. Memory locations often aren't re-used by different tasks, and there's surprisingly little use of temporary working values. Jordan Mechener was flying solo when he wrote the original Prince of Persia, but even so in his published source code there's one file that pretty much sets up the entire memory layout for the entire game. It's more telegraphic than you'd want for a team, but it's not uncommon for there to be a file that goes into great detail over just how RAM is going to be laid out in the program. Once you move on to chips that have better support for hardware stacks, then temporary variables that are recycled more or less instantly become a more common thing, so while I haven't taken apart any classic DOS games, I'd expect to see more recycled storage there, at least. The idea that assembly language code is inherently brittle doesn't hold up, though. The GDC Diablo Retrospective talks about... well, a lot of stuff, but the two real highlights were that until the netcode was patched in the game was pretty much pure assembly language—they had to import C expertise—and also that there was a big fight about turn-based vs. real-time and the prototype real-time conversion ended up happening in a manner of hours. Being able to get that to happen, though? That is what takes a lot of work, experience, and discipline.
|
|
#
?
Apr 20, 2020 01:20
|
|
|
It's only vaguely related, but a small team of modern programmers have done magic with 6502. https://www.youtube.com/watch?v=ZWQ0591PAxM&t=331s
|
|
#
?
Apr 20, 2020 01:38
|
|
|
That's very nice! I saw some (different, but also very, very good) NES homebrew work at MAGWest last year, too; there's some real talent doing NES homebrew these days. It warms the heart.
|
|
#
?
Apr 20, 2020 01:52
|
|
|
PMush Perfect posted:It's only vaguely related, but a small team of modern programmers have done magic with 6502. Between this and Game Hut's videos, I've determined that early game development involved heavy use of dark sorcery and witchcraft.
|
|
#
?
Apr 20, 2020 02:51
|
|
|
Randalor posted:Between this and Game Hut's videos, I've determined that early game development involved heavy use of dark sorcery and witchcraft. The real wizardry, IMO, comes from programmers that learned to operate in the weirdnesses of a digital machine driving an analog television. If you can get your code efficient enough to work in the HBLANK interval you can do sorcery.
|
|
#
?
Apr 20, 2020 03:00
|
|
|
Tendales posted:The real wizardry, IMO, comes from programmers that learned to operate in the weirdnesses of a digital machine driving an analog television. If you can get your code efficient enough to work in the HBLANK interval you can do sorcery. While I've certainly written at alarming length about that before, I suspect that FF1 doesn't do a lot of this. The general technique of building the display by dividing the whole frame up into a series of stacked regions—"raster effects"—was a lot harder to do on the NES. The Atari 800 home computer and the Commodore 64 both had special hardware for divvying up the screen almost arbitrarily, and the Atari 2600 (older than the 800; I don't know either) was so primitive that the programmer was obliged to treat each raster line individually anyway. The NES, in contrast, only really had built-in support for dividing the screen into two parts, basically by trapping when one specially designated sprite collides with the background. (Early NES games where the status window is at the top and has some lightly animated element at the bottom? That was there to trap when to split the display.) It could only fire once per frame, though, and then it would latch into place. (The C64 had a similar "trap when you hit a certain way down the screen" value, but it didn't latch so you could retrap as many times per frame as you could dare to cram in, and thus have as many ranges as you could ever want.) C64-like tracking was, AIUI, bonus circuitry added into some cartridges, like a particularly underwhelming SuperFX chip. What makes things worse is that the video memory for the NES was kept separate from everything else, and there was only one byte accessible to the CPU at any given time. You'd write to special memory locations to alter which bit you were looking at, and then write to another special memory location to put stuff into that video memory. That's not super-bad on its own, but it turns out that while the frame is being drawn, those values change as the graphics chip works through drawing the display, so if you mess with it you can corrupt the display, or even corrupt graphics memory itself. This is usually simply disastrous but if you have a proper understanding of what changes when and why you can either defang it (Zelda 1 ends up doing this as a side effect of moving up or down on the map) or take full control of it (The Japanese version of Rockman 6 has an effect on its title screen that I only recently learned was even theoretically possible on the NES). Nasir might well have known some of these tricks by 1990, but I can't think of any part of FF1 I've seen where it looks like it's pushing the hardware that hard. I think they mostly were just setting up the display once and for all in the much longer VBLANK interval between frames and then letting the graphics chip do its work.
|
|
#
?
Apr 20, 2020 03:31
|
|
|
ManxomeBromide posted:The idea that assembly language code is inherently brittle doesn't hold up, though. The GDC Diablo Retrospective talks about... well, a lot of stuff, but the two real highlights were that until the netcode was patched in the game was pretty much pure assembly language—they had to import C expertise—and also that there was a big fight about turn-based vs. real-time and the prototype real-time conversion ended up happening in a manner of hours. my favourite takeaway from that lecture was that battle.net for Diablo 1 was handled by 1 computer I can't imagine any kind of stable online game being able to do that these days
|
|
#
?
Apr 20, 2020 04:19
|
|
|
GreyjoyBastard posted:That DW1 run is preposterous. So there are two things to this. One is that DW1 only polls for input every 4 frames, so you have a (relatively) large amount of leeway in pressing buttons. The other is that NESCardinality is insane (in like, a good way).
|
|
#
?
Apr 20, 2020 04:44
|
|
|
ManxomeBromide posted:I'd also add that just because modern disciplines have trouble dealing with raw assembly code doesn't mean that best practices in the 80s (and early 90s!) couldn't. Even though they had less memory to work with on the 8-bits, the programs I've taken apart for them make much more consistent use of memory than a modern program would, even when this ends up using double or triple the amount of space they'd technically need. Memory locations often aren't re-used by different tasks, and there's surprisingly little use of temporary working values. If you're interested in these kinds of tricks, or just the things developers do to make video games work in general, the War Stories series by Ars Technica is full of them. For example, find out how Crash Bandicoot hacked the Playstation. Unfortunately, I don't think any of them deal with NES-era games.
|
|
#
?
Apr 20, 2020 04:52
|
|
|
Aces High posted:my favourite takeaway from that lecture was that battle.net for Diablo 1 was handled by 1 computer You ever play Marvel Heroes? 'Cause I'm pretty sure that was run by 1 computer. And it was (mostly) stable. Not counting when goons went out of our way to crash the server...
|
|
#
?
Apr 20, 2020 04:59
|
|
|
Kheldarn posted:You ever play Marvel Heroes? 'Cause I'm pretty sure that was run by 1 computer. And it was (mostly) stable. Not counting when goons went out of our way to crash the server... Using those loot things all at once was such hilarious stupidity, I loved it.
|
|
#
?
Apr 20, 2020 13:48
|
|
|
It's kind of weird that someone working in the Apple II game industry wouldn't know what an RPG was considering how big Wizardry and Ultima were.
|
|
#
?
Apr 20, 2020 15:57
|
|
|
Nice, I love a good technical LP. One nice not so obvious bonus for black belts is that, since they don't need weapons or armor, they have a lot of empty item slots that you can use to store unequipped gear. And item slots are extremely precious in this game.
|
|
#
?
Apr 21, 2020 05:36
|
|
|
PMush Perfect posted:Bikke, the best character in 8-Bit Theater, don't @ me, Rabbi Raccoon posted:Oh wow, 8-Bit Theater. I loved it back in the day. He's gotta be done...right? achtungnight posted:I liked 8-bit Theater too. Favorite line- “Astos, huh? Well, now that you’re messing with us, your rear end is toast.” PMush Perfect posted:Sarda being impressed by Bikke beaning him with the Orb of Water is my favorite character moment AND the source of my favorite line. FoolyCharged posted:Thankfully no on has shot giants at us out of a cannon yet. Once upon a time, I read this comic while it was being created, but I didn't get very far into it (I think I got to the part shortly after they dealt with Garland) before I stopped, and I don't remember why anymore... Thanks to these comments, I just finished binge reading it last night, and man, what a ride it was! Overall, 10/10 would recommend! It made me laugh a lot, and did not end how I expected!
|
|
#
?
Apr 21, 2020 15:13
|
|
|
Kheldarn posted:Once upon a time, I read this comic while it was being created, but I didn't get very far into it (I think I got to the part shortly after they dealt with Garland) before I stopped, and I don't remember why anymore... How long did that take?
|
|
#
?
Apr 21, 2020 16:46
|
|
|
Some Goon posted:How long did that take? 3 days. There's a lot of skippable filler poo poo in there, like one-shot comics, holiday comics, guest holiday comics, etc. I also skipped the Fighter's Journal Entry comics because too much talking not enough stabbing.
|
|
#
?
Apr 21, 2020 17:49
|
|
|
My favorite bit was the dual-class half-elven ranger, who's other half, was half-orc.
|
|
#
?
Apr 21, 2020 18:06
|
|
|
|
| # ? Apr 25, 2024 21:12 |
|
|
I'm just glad I'm not the only one re-reading that beast as a result of this thread. I'm also glad it's humor holds up surprisingly well for being a product of the early aughts.
|
|
#
?
Apr 21, 2020 18:21
|
|
