Game 457: Sinistar

Of the four original releases by LucasFilm, Koronis Rift is the only one whose lead designer, Noah Falstein, has a Wikipedia page and a pre-LucasFilm career described there. Notably, his juvenilia includes the unfinished simulation Koronis Strike: A Simulation of Mining and Combat in the Asteroid Belt, from which Koronis Rift borrows the left side of the title, and his first game as a lead designer at Williams Electronics borrows the rest of it.

Sinistar's prototype logo looked more... sinister

Two pieces of advice for anyone who wants to play Sinistar. One, use an analog stick - it's unconventional for the genre of multidirectional shooters, but Sinistar had a joystick with three levels of pressure sensitivity, and being a Williams game, expected an accordingly precise level of finesse from you. Second, play the easier AMOA-82 prototype version - it's a little buggier, has some missing animations, and Sinistar will call you a coward for doing it, but you might actually last five minutes. And don't worry - it's just as deadly as any other Williams classic, only much stingier with bonus lives.

Not good!

With its radar view reminiscent of Defender, Sinistar continues the house design of moderately complex, high-intensity shooting action, though there's less going on here overall, with only three types of objects to encounter, plus yourself and Sinistar.

• Workers are harmless robots attempting to construct Sinistar; a spooky biomechanical construct. Destroying them delays this somewhat, but you can't possibly destroy them all.
• Warriors are bots with pivoting turrets. They initially harass you, but the longer you tarry on in a sector, the more numerous, aggressive, and accurate they become, to the point where they can be more threatening than Sinistar himself.
• Planetoids are resource-rich astronomical objects which the workers mine for the materials needed to build Sinistar, or that you need in order to destroy him.

 

Shooting planetoids releases crystals which you can collect to obtain sinibombs; a homing weapon which destroys Sinistar (sinibombs also destroy my wife, so she tells me). But the workers can steal them to accelerate the construction, and it's tempting to chase them down but this is probably a waste of time. Ultimately, it's a race against the workers to obtain enough sinibombs before they finish building him - it takes 13, but you'll want more than that in case some don't land.

Herein lies the most significant difference between the prototype and commercial versions. In the prototype, the planetoids are far more generous with their crystal output. Time after time in my initial attempts with the final revision, I just couldn't shake off enough crystals to take on Sinistar by the time he announced himself (Beware, I live!). And this is effectively a game over; you can't survive long once he starts hounding you, much less mine crystals under that pressure, and even if you have more lives, Sinistar does not reset his state when you respawn, nor do you replenish sinibombs, and he'll just eat you again within seconds.

I did have a bit more luck by camping close to Sinistar's construction site - workers tend to accumulate en masse there where they present as targets of opportunity, but I still couldn't beat the first zone reliably until I switched to the prototype version. And then in that version, I could never beat the third sector dubbed "Warrior Zone," which features increased spawn rates of, you guessed it, Warriors.

Reportedly, Williams' executives demanded a higher difficulty to increase quarter collections. Somewhere out there, there must be an idealized ROM set that has the feature completeness of the final version but the original difficulty curve intact.

 

Here's a video of my best attempt on the prototype version, where I score almost 124,000 points.

  

GAB rating: Average

Sadly, this one ends Williams' perfect run of ivory deck entries. Points for a novel gameplay concept and a very cool-looking and sounding villain, but Sinistar is hard for the wrong reasons. Defender, like its successors, was ruthless but kind of fair about it, and I enjoyed the process of mastering its controls and mechanics until I could get a respectable score. Sinistar is too fast, too fiddly, too zoomed-in to get a sense of what's going on, and too unforgiving. The radar is little use; the way it is positioned, if you're looking at it, you're not looking at the main screen, and something on it will kill you while your attention is diverted. And if you are looking at the main screen, something will zip onto it from offscreen and blast you quicker than anyone can react.

It occurred to me while complaining about Sinistar's tight-fisted approach to bonus lives that it is lacking a certain quality that some of the best arcade games of the golden era had, and earlier Williams games did quite well. There's not very much in the way of secondary, bonus point-scoring objectives! Defender, Stargate, and Robotron had humans to rescue, which was always secondary to destroying your enemies and totally optional in Robotron, but awarded the bulk of your points and was well worth pursuing for the bonus lives it would accrue. Joust had its eggs and bonus rounds with special objectives. But in Sinistar, by far the largest point-award is for destroying Sinistar which is what you're trying to do anyway. And sure, you can farm some extra points by sabotaging the construction zone with some early sinibombs, but it's not worth that much, and probably not worth it past the first zone. I had thought about the possibility of improving Sinistar with easier bonus lives, but with fairly one-dimensional goals (destroy Sinistar for points and progress), what would really be the point? Your main source of points is playing the game to beat the levels, and either you play well enough to gain them faster than you lose them, or more likely, you don't.

Next post we'll be back on the LucasFilm chronology with Falstein's first product for the newly founded team, and their last on the Atari platform.

Game 456: The Eidolon

Read the manual here:

https://www.mocagh.org/loadpage.php?getgame=eidolon 

 

LucasArts might be best known for their classic adventure games, or perhaps for their numerous Star Wars games, but the first wave of releases under the LucasFilm Games label was a series of four pseudo-3D action games for the Atari and other computers. I already played two of them, as they had been created in 1984, though they went unreleased for over a year until LucasFilm secured a publishing deal with Epyx.

The Eidolon, one of the two developed for Epyx in 1985, reuses the Fractalus engine for a very strange first person dungeon crawl. The manual takes the form of a Vernean inventor's journal, chronicling his subterranean travels under the surface of the earth's crust in the titular Eidolon, a powered tunneling vehicle armed with a fireball cannon.

Exploring a strange world, to seek out new life forms, and destroy them!

 

The journal explains some of the game concepts in-universe, but purposefully leaves a lot of key details out. For instance, there are monsters lurking about these caves which can be destroyed with your cannon, but what the manual doesn't tell you is that the monsters are invulnerable until you get quite close, and you can waste a lot of energy and time shooting at them from outside the kill range before you realize this. And it explains that there are four types of colored fireballs you can fire (destructive red, energizing yellow, freezing blue, and transmogrifying green), but gives me no reason why I'd ever want to bother using anything but red. And indeed, I never discovered any reason to, except for at the end of levels, where you are forced to. More on that later.

Despite using a more advanced iteration of the Fractalus engine, I found Eidolon to be ugly and unpleasant to look at. There's no equivalent of the former game's show-stopping re-entry sequence, and there's not much to look at except monochromatic walls - essentially an inversion of Fractalus' craggy landscape. Fractalus can get away with a bit of abstractness, given you're flying over the landscape and rarely need to be all that spatially aware, but in Eidolon you're navigating a maze, and the spatial demands are much higher than what can be visually communicated.

It took some tries before I quite figured out what The Eidolon is all about, but eventually I got good enough to consistently reach the eighth and final level, but I can't beat it.

Some basics about how the game works - very little of this is explained in the manual:

• Each level is a maze, with three regular monsters hiding somewhere in it, plus a dragon.
• Find and destroy the dragon to win the level. The C-H gauge helps you find it.
• Each regular monster has a colored key card that you can collect after destroying it. A barrage of red fireballs is all you need (once you move in close enough) but easy does it - fireballs drain your batteries quickly and you have little power to spare for overkill.
• There are also a number of fireballs just bouncing around the corridors.
• Yellow and green fireballs can be scooped up with the space bar for more energy.
• Blue fireballs can be collected to freeze time for a few seconds, but you can't hurt enemies during this time.
• Red fireballs hurt you, but can be neutralized by shooting them with your own reds. Easier said than done - imprecise graphics and abysmal framerate make it hard to tell if you were successful, and if you fire a second red by accident, well, now you just have a new red fireball to deal with.
• The dragon is shielded by an invisible force-field which will be opened by a specifically-colored key card. Later levels require two or three of them.

 

The dragon fights are chaotic and visually incoherent, but there's a logic to them. Each level's dragon is vulnerable to a specifically colored fireball, and only trial and error can help you find it. The trick is that when you inflict damage, you see sparks fly, but when you don't, it's damn near impossible to tell if it's because you flung the wrong color, or you missed, or it was neutralized by the dragon's own ordinance. But it's not randomized, so you're good once you learn. And if you get low on energy, you can recharge by hanging back and mashing the space bar to absorb the dragon's attacks - only red ones can't be absorbed, and most of the time you'll heal faster than you get hurt.

 

Here's a video of my best attempt:

 

There's another aspect to The Eidolon which isn't obvious, and isn't necessary to begin playing, but absolutely crucial to understand if you want any chance of finishing the game. You don't need every key-card to beat most levels. However, unused key-cards carry over level to level, and if you kill every monster on the first four levels, you will have exactly enough key-cards to finish the rest of the game. So do it! Then you may ignore the rest of the non-dragon monsters completely. You're on a tough time limit, and the deeper you delve, the more complicated the mazes, and the nastier the monsters. The less time spent fighting them later on, the better.

 

The eighth level is dark and confusing to navigate. Floating fireballs do help get your bearing.

 

And then there's a seven headed dragon at the end. I have no idea how you're supposed to deal with this. I can't manage to destroy a single one of the heads, not even with save states.

What's even going on?

 

There is footage on Youtube of someone beating the game, and the last fight is roughly three minutes of visual chaos, concluding with a sprite of Nicola Tesla holding a dragon egg.

 

GAB rating: Bad 

Rescue on Fractalus was visually striking but a bit too simplistic. Low difficulty helped make its slow performance bearable, and the look and feel made the experience enjoyable. But The Eidolon is ugly, punishingly sluggish, awkward to control, and needlessly obtuse. Or as "D" put it, "this is lame."

 

Updates could continue to be slow between now and November, unfortunately. My place of employment tends to go through cycles of idleness, buildup, and crunch, and we're hitting crunch hard thanks to upper management making some wildly optimistic assumptions about the efficiency of vibe coding. You can churn out 75,000 lines of code in a few months without any SME's this way, but the product will be a buggy piece of crap that does maybe 10% of what it's supposed to do, and it turns out the client doesn't want that.