|
Part 8: Acceptable Casualties Last time, we went in a big loop, and we basically ended up going nowhere. Cobalt Quadrant  The Federation world here is still threatened. I back off a bit, hoping for them to attack the Federation world and then be easy pickings. So of course they decide to stay put, because the game is in maximum trollery mode. I'll just have to bite the bullet and take the fight to them. Fortunately, it's not a literal biting of any bullets. I make it out of the fight undamaged.  I'm not so lucky in the Corridor, though. Corridors at this point start becoming nerve-wracking endurance fests, with four or five force fields per run. Periwinkle Quadrant  No. Periwinkle Quadrant is dead to us. We're turning this ship right around, going back to Cobalt, and taking out that Cobra Fleet. Cobalt Quadrant Again  Last time we ended up going in a giant loop. But remember Brown Sector back in the first half of the game? Going west took us to Home Quadrant, but going east right afterwards took us to Red Quadrant. We're going to take the loop backwards and see if the path diverges. Omega Quadrant  North from Cobalt takes us to Omega Quadrant, which is expected...  ...and the foes in this part of the quadrant yield to our might...  ... but man, that's less fuel than I'd like. Westward ho! ... to Cyan quadrant, according to our map, which has tons of enemies and is a Red Zone. We won't find any fuel in Cyan. But this is where the paths diverge. Green Quadrant  Unlike Cyan to Omega, the Green-Omega hyperspace route is two-way; east from here takes us back to Omega Quadrant. That means we can route the rest of the glitchrun: from Cobalt, go east to Periwinkle, east again to green, tunnel through the wormhole, then east to Omega, then tunnel through that wormhole and thence to Solaris. (We can't just go north from Cobalt and then straight to Solaris; the Corridor and the Star Pirates both block our passage in a way that won't let us do the tunneling glitch from that direction. We have to enter on the western side.) But that's a glitchrun and thus not relevant to us. We're here about to run out of fuel and that attack fleet is going to try to cut us off on the way to the Federation world. The Flagship group is eyeing that Federation world hungrily too. We need fuel, and we've got Zylons trying to intercept us and trying to destroy our fuel dump. Seconds count. Let's go raid the Zylon world.  Our fuel alarm goes off partway through the raid, but we finish it before the Attack group can cut us off...  ... and actually manage to pull into the hangar with a reasonable-ish margin of safety. We now have a new problem. Look at that map again. The wormhole and the Federation world are, together, blocking our path north. We're kind of stuck again. We could let the Flagship group attack and use the Savior's Passkey, but that's a glitch. We could let the Flagship group attack and then sit around with our thumbs up our butts. After awhile they'd blow the planet up and then we'd be able to fly through. But we're impatient. We'll have to take matters into our own hands.   There's one final mechanic I haven't fully explained. Blowing up your refueling hangar doesn't merely remove your ability to get refueled or repaired. It also blows up the entire planet. You might think that this is an unforgivable crime on our part, but we have an important mission, and they were in our way. You've got to understand. There are a handful of Atarian pioneers stranded on a failed colony on the Lost Planet of Solaris. Rescuing them clearly justifies dooming the millions of personnel on a fully-established Federation military world. The needs of the many are outweighed by the needs of the few. It's just logic. ... actually, you know what, if anyone asks, the Zylons did this. And before you ask, yes, it is impossible to win glitchless without the Green sector Federation world being destroyed. We have exhausted literally every other path reachable from this side of it without glitching. Speaking of glitching, blowing up a Federation world does not count as a successful sortie for the purposes of blockading, and thus for the purposes of the Tunneling or Quadrant Control tricks. This is kind of hilarious, because it means that it keeps blockading you after its destruction (at least until you back out and re-enter the now-empty sector), but it's mostly sad, because it means that you can't use the Quadrant Control trick to rocket around the Galaxy completely unopposed, blowing up friendly worlds like some kind of demented Orion drive. Anyway. Let us not dwell on the past. What is done is done. Onward, to a glorious future! Aqua Quadrant  Hot on the heels of a major dick move, Solaris now pulls another major dick move. See that wormhole there on our side of the asteroids? It wobbles back and forth. That's not really a dick move on its own, and it isn't unprecedented. We saw that in Brown Quadrant. What is unprecedented is that the endpoint of the wormhole here also wobbles. The location in this screenshot? That's where you want it. That warps you up to the northern part of the map and lets you continue to uncharted territory. If it's a sector to the west, it warps you into the middle region, and thus into the loop that leads us nowhere good. But we luck out, though that jump timer is awful low. We have to act fast to make it in time. But we do, and that Zylon planet guarding the exit will let us max our lives count on the way north. Handy! Ochre Quadrant  Our fuel is looking not great. Worse, we've got a lot of fights left, and based on which exits are unaccounted for, it looks like we won't be encountering any further Federation worlds. We can't refuel except by dying, but that's a temporary solution too: there aren't any Zylon raids from here on out either, so our current life stock is our entire fuel supply now. We're going to have to fly carefully. This stretch, from the Aqua Quadrant warp on, is the reason Solaris is a real challenge to beat even with savestates. Fighting my way to the east exit, I mess up a force field in the Corridor and lose a ship. But fuel is under 2 units at that point so I figure it's no real loss. Cyan Quadrant  The only place left for that south exit to go is the north entrance to Omega Quadrant. It better go there or the glitchless run really is impossible. The less said about Cyan Quadrant the better. I grind through four battles with reversed controls (since, as you may recall from last time, Cyan starts out as a Red Zone), and die twice along the way. Both times, it is because my fuel tank has dropped to zero. Enough of Cyan Quadrant. On to, hopefully, Omega. Omega Quadrant  Omega indeed! Victory is in sight. It's winnable glitchless after all.  All we have to do is clear three fights against the most vicious enemies in the game one two lives with no refuel or repair.  For added entertainment, the first Cobra Fleet fight kicks us back to the hated Cyan sector. But that's just a distraction. We've got savestates here. It is now...  ... simply a matter...  ... of persistence. We key in one last hyperwarp.    We've done it. We've beaten Solaris. We've shown that it's possible to beat it glitchless. We've also shown that you probably shouldn't. VIDEO The rest of the playthrough is now on YouTube, should you have more time than you know what to do with and hope to fill it with 8-bit pew-pew-boom sounds. FINAL MAP This table gives the map interconnections. Each exit leads to the opposite entrance (so going east always puts you by the west exit of the destination quadrant), but not all exits are reachable from all entrances. Which exits are reachable from which entrances may vary based on glitches. One-way warps are marked with an asterisk. pre:Quadrant North South East West -------------- -------------- -------------- -------------- -------------- Home Crimson Teal Red Red Teal Home Grey Grey Crimson Red Lime Lime Home Home Crimson Brown Home Teal Grey Brown Purple Crimson Lime Home* Grey Teal Purple Crimson Teal Lime Red Red Purple Brown Purple Grey Crimson Cobalt* Lime Cobalt Omega Ochre Periwinkle [no exit] Periwinkle Green Magenta Green Cobalt Green Aqua Periwinkle Omega Periwinkle Magenta Periwinkle Cyan Aqua Omega Aqua Ochre Green Ochre Magenta Cyan Magenta Omega Omega* Ochre Ochre Cobalt Aqua Cyan Aqua Omega Cyan Cobalt Magenta Green I played a lot of adventure games as a kid, and one of the things that always jumped out at me was that the adventure wouldn't always know the solutions to its puzzles. For things like PUT HAT ON STATUE, it clearly did, but then you would also have the occasional complicated machine where the game knew what knobs did and what state it wanted the machine in but had no idea how to get from point A to point B. Solaris ultimately splits the difference. It actually gets a fairly complicated maze out of a set of sixteen rooms, and it does it with only three one-way transitions. It "knows" about the puzzle behind moving from Aqua Quadrant South to the north exit, in the sense that that wormhole clearly had special programming. But the fact that the Green Quadrant Federation world needs to be destroyed to traverse the maze without glitching is a property of the map, not of any explicitly coded scenario. The design and the mechanics are fairly clever about misleading the player, as well. Everything about the base game tells you to not spend too much time on the map screen, but if you just rocket from battle to battle you won't notice that the Brown Quadrant wormhole will move out of your way. Much more cunning—and trollish—is the way the second half of the game puts enemies in places where they are guaranteed to block you, but also where engaging them will send you barreling through the Galaxy in the wrong direction, through a series of obvious exploration possibilities that often cut off your ability to backtrack. That said, I really can't say that Solaris is a game worth beating. We exhausted the moment-to-moment mechanics of the game just within Home Quadrant and its neighbors, and the final third of the game is a terrifying slog where the primary question is whether bullets or fuel loss will be what kills you. You're honestly better off, both from a having fun standpoint and from a high-score standpoint, just ignoring Solaris entirely and tooling around murdering Zylons. But then, those were our real orders, weren't they? The whole Lost Planet of Solaris thing was just a pretext. I can't say I wasn't warned, going in. But pretext or no, it's possible, and it's possible without cheating. It is done. ManxomeBromide fucked around with this message at 07:44 on Aug 27, 2016 |
#
?
Aug 24, 2016 08:22
|
|
|
|
| # ? Apr 27, 2024 21:43 |
|
|
Nice work, this was really well done. 
|
|
#
?
Aug 24, 2016 13:31
|
|
|
ManxomeBromide posted:That said, I really can't say that Solaris is a game worth beating. We exhausted the moment-to-moment mechanics of the game just within Home Quadrant and its neighbors, and the final third of the game is a terrifying slog where the primary question is whether bullets or fuel loss will be what kills you. You're honestly better off, both from a having fun standpoint and from a high-score standpoint, just ignoring Solaris entirely and tooling around murdering Zylons. Now that's ludonarrative harmony. Easily the most informative LP I've read, even though I didn't understand a lot of it (and I have a CS degree (although as you say programming was half electrical engineering back then so)).
|
|
#
?
Aug 24, 2016 13:45
|
|
|
I have to admit, I've got a soft spot for when games require you to progress through straightforward application of game mechanics producing an absurd result.
|
|
#
?
Aug 24, 2016 16:05
|
|
|
So, did you make up the colors/names of the sectors yourself?
|
|
#
?
Aug 24, 2016 16:12
|
|
|
Thuryl posted:I have to admit, I've got a soft spot for when games require you to progress through straightforward application of game mechanics producing an absurd result. See also Wizardry and Might & Magic 2.
|
|
#
?
Aug 24, 2016 16:23
|
|
|
Carbon dioxide posted:So, did you make up the colors/names of the sectors yourself? I did, because I needed to be able to mark where I was going on my maps. Having five blue sectors and two red sectors really didn't help. And for the record, Periwinkle is #CCCCFF and is totally a color.
|
|
#
?
Aug 24, 2016 17:10
|
|
|
Well, dang. Congratulations. And actually nice work on the programmers' part for making a game that was possible and not just like that one CYOA with the perfect ending you can never reach by following the pages.
|
|
#
?
Aug 25, 2016 00:27
|
|
|
Tech Post 7: Doug, Mel, and the Modern World I've just spent the past month digging into a binary that hewed to strange and arcane requirements, trying to tease out its secrets. There's precedent for that, in literature and folklore. A lot of us have, at this point, heard of The Story of Mel. If you haven't read it, you should go read it, and if you have read it, that link is to an annotated version that explains the tricks in detail. Mel Kaye is an interesting comparison point, because Mel was working in the 50s or early 60s and was about as far from Doug Neubauer writing Solaris as we are from him. So it's interesting to see what's changed and what hasn't. Before we go on, though, I do have to note that I don't like The Story of Mel. It's a story of the guy who writes the fastest code, and who thinks that entitles him to get to pick and choose his projects at will, and also excuses him writing impenetrable code and does not require him to mentor his own co-workers. Programming is a craft, not a feat of athletics—and to the extent that there was method to his techniques, they should have been spread throughout the entire company. To the extent that tools existed, and that Mel could beat them, the techniques he used to beat them should have been folded into the tools. And from a basic level of professional standards, leaving your successors the ability and knowledge to extend and modify your work once you're gone is a fundamental responsibility, one that Mel expects to be praised for shirking, and that the storyteller is willing to grant. Despite literally wasting two weeks of the storyteller's time to reverse engineer a loop that wasn't even accomplishing anything important, because Mel just kept his tricks to himself. Sure, stories grow in the telling, but the basic idea here is still incredibly unhealthy. We know for a fact that Atari's internal developers shared tricks with each other—the six-digit score trick was apparently the "Dave Staugus score kernel" there, after the programmer who worked it out—and once it was devised, everyone used it. It was a hardware upgrade for everyone. The optimization techniques Mel employed only upgraded the RPC-4000 if Mel was the one writing for it. To this day I am baffled by the idea that he's supposed to be some kind of folk hero of the open source community. But all of that is culture. Let's talk technology. Constraints In Mel's time, the integrated circuit had only just been invented, and it would be approximately ten years before the technology was mature enough that you could create a CPU on a single chip. The defining feature of the computer in the Story of Mel is that it is a drum-memory computer. This means that its RAM is basically a disc drive that is always spinning and reads data when it comes into the right place. This computer would not have had a lot of RAM, but it would have had a whole lot more than the Atari 2600 did. After all, it had to store the program it was running in RAM. (Mel complains about programs that can't modify their own code. Self-modifying code was a limited thing on the 6502—we'll get to that in a bit—but a fundamental constraint of cartridge-based programming is that the program code is immutable. That's what "ROM" means. Modern machines forbid self-modifying code of the sort Mel deployed on the grounds that if it's allowed it opens you up to the broadest class of system-takeover malware attacks.) But the sticky bit about drum memory is that it means that memory accesses can take a variable—and large—amount of time. Everything about Mel's tricks revolves around the fact that he wants to always have his memory's "seek time" be zero. The program's instructions, considered in execution order, are scattered throughout the memory so that the time spent running the previous instruction is exactly the amount of time it takes to seek to the next instruction. (Mel's employers weren't complete newbies here; they had in fact mechanized the process of instruction placement. Mel could defeat it with hand-tuned code, but he could also defeat it by significant margins because he assigned the locations of the most time-critical code first, while the instruction-placement program would just go through from start to end. That this story ends with "so Mel is Just Better" instead of "so best practices for that machine changed to putting the most time-critical code at the top of your program" is the part where I start gnashing my teeth and ranting about the savagery and barbarism of earlier days.) So in this sense, the Atari 2600 is a system with the unimaginable luxury of constant, and fast, memory access. This also means that your program gets to just be written in linear order. One of the other odd things about the Atari 2600 is that past a certain point optimizing for size or speed buys you literally nothing. ROM chips always have a size that's a power of two, so if you've gotten your program down to 2KB, you gain nothing whatsoever by getting it down to 1.5KB. And since you're shackled to the television's electron gun, past a certain level of efficiency making your code faster just means that you're spending more time waiting for the CRT to catch up. In modern terms: once you're I/O bound, that means your logic is fast enough. It's as true today as it was in 1977. Mel's Tricks High-level program organization aside, several of Mel's programming tricks are detailed in the story and are relevant to the 6502 as well. Opcodes as constants. There's nothing stopping you from treating code as constant data and reading it as a raw value. But on the 6502, doing this is purely a dick move that makes your code more brittle. Constant data on the 6502 can be encoded directly into the instruction, and it's always faster to do so. Self-modifying code to replace indexes. The 6502 turns out to be really bad at pointers, so this trick was very common if you weren't running off a ROM. If you're reading an address out of RAM on the 6502, that RAM has to be in the first 256 bytes of memory, and you have to index it. For loops with well-defined bounds, it is often simpler to just modify the address in the middle of an instruction to point at the new place to load from. However, while simpler, it's very rare that it's faster, because messing with memory that isn't in the first 256 bytes of RAM is 50% slower. And the Atari 2600 laughs at you, because with only 128 bytes of RAM, all of it can be used as pointers and be accessed really quickly anyway! Sometimes constraint is a luxury all its own. Self-modifying code to alter opcodes. This is the one that stumped the storyteller for two weeks. Unlike many other chips, the opcode on the 6502 is its own byte, and the data is in other bytes. You can mess with the operands, or you can mess with the opcodes, but you can't do both at once. Because of this, the trick doesn't translate, and I'm unaware of any tricks on the 6502 that involve modifying opcodes and that actually buy you anything. Doug's Tricks See Tech Posts 2 through 5. But here's the thing. I've done my share of 6502 assembly programming, but I'm too young to have done so professionally. It's always been as a hobby and as a curiosity. I knew about the 6-digit score trick going in, but that was the only technique used that I knew in advance. Not a single one of those posts required more than an hour of experimentation to research. In the Doug vs. Mel showdown, Doug wins hands down. The View From 2016 Moore's Law hasn't broken yet. We command unimaginably sophisticated systems at every scale of deployment from handheld through datacenter, and we've had to grow our techniques to match. There's a very strong tendency to consider this a sign of weakness—a generation of John Henrys giving way to an age of power tools. I think that's only half right. The idea of shifting from a world of hand tools to a world of industrial machinery is a useful one, but the old code that's really worth reading is less like admiring the mettle of iron men in wooden ships and more like admiring the comfortable simplicity of a piece of well-crafted old furniture. It's a genuine relief to step away from a world where one is trying to get fifteen different computers to all kind of talk to each other and point in roughly the same direction while speaking slightly different variations on five different relevant standards into a world where there is one computer doing one thing because that bit right there is a 1. When I started digging into Solaris's code, I really expected it to feel like cracking a cipher or solving a puzzle. Instead, it felt like I was taking a tour and being directed to points of interest. The Atari 2600 is just small enough that even when it's juggling as much as Solaris did, at any given moment all the pieces are doing something relatively obvious. It was a genuine delight to see the parts of the system fit together to become the whole of the display, and I hope I've been able to get that across to you through these articles. And if by some odd chance Doug Neubauer himself ends up reading this: Thanks. By my standards as a youth and as an adult this was a very fine work, and I'm glad I got to spend time with it. ManxomeBromide fucked around with this message at 07:52 on Aug 27, 2016 |
|
#
?
Aug 25, 2016 10:40
|
|
|
I'm merely echoing what others have said, but I'll say it anyway: this has been an absolutely fascinating LP, and thank you for making it. By the way, that last post reminded me to recommend Code: The Hidden Language of Computer Hardware and Software to anybody in the thread who wants to learn more about the beginnings and inner workings of computer hardware and how machine code interacts with it. I'm not a programmer by any means (I can look at C# source and kinda get what's happening before my brain starts to hurt), but that's exactly who the book is written for. Code starts with the very basics of what, well, "code" actually is and accomplishes (using examples like Morse and Braille), segues into cleverly teaching the most common counting systems in order (binary, octal, decimal, hex), then takes a detour to explain how telegrams and the first cross-continental phone systems worked using electrical/mechanical switches and repeaters. It's only until halfway through the book that the author feels the audience is ready to cover transistors/memory/ICs using plenty of color schematics, and at least 2/3 of the way through before the topic of assembly is even brought up! It's extremely well-paced and designed, and written in a way that never left me bored. Check it out if you get a chance.
|
|
#
?
Aug 25, 2016 19:50
|
|
|
That's a really great essay. I appreciate that you're willing to share what you have learned.
|
|
#
?
Aug 26, 2016 00:49
|
|
|
Yeah, I didn't comment while it was going on but this was really interesting and I'm sad it's over. You should pull this treatment on more games, as it was entertaining and educational. I mean, it's your call, don't listen to me. I don't have to put in the work to create the entertainment.
|
|
#
?
Aug 26, 2016 17:31
|
|
|
|
| # ? Apr 27, 2024 21:43 |
|
|
I've sent off the thread for archiving. I'm glad you folks enjoyed it. In the meantime, in checking over what I'd written I had made one fairly serious error: I'd attributed the Atari ST's graphical OS to Digital Equipment Corporation. It was actually a product of Digital Research, of CP/M and DR-DOS fame. edit: http://lparchive.org/Solaris/ is live. Thanks again everyone, and see you next time. ManxomeBromide fucked around with this message at 09:17 on Aug 29, 2016 |
|
#
?
Aug 27, 2016 08:11
|
|