Last updated:
March 25, 2019 01:00 PM All times are UTC.
Powered by:
PlanetPlanet
Welcome to the ScummVM planet - This aggregates the personal blogs of developers, teams members and active participants from all around the ScummVM community. If you wish to subscribe to updates to the planet or individual blogs please use the links on the right hand side. To add your blog to the planet contact DJWillis.
A couple of days ago, Google announced the organizations that have been accepted for Google Summer of Code 2019. We are very pleased to announce that ScummVM is one of them, together with our sister project ResidualVM. The Summer of Code is a yearly event organized by Google to encourage students to contribute to open source projects. Open source organizations provide mentors and projects to work on, while Google give some money to participating students. You can find more information on the official web site. We also have some information on our wiki, and in particular project rules that applicants will need to follow.
Are you ready for a great adventure? Do you want to contribute to one of the largest game preservation projects known to mankind? Then ScummVM and ResidualVM are waiting for you! Have a look at our ideas page. Of course, you are also very welcome to bring your own idea! Students have until April 9 to write and submit proposals for the project they want to work on. The accepted proposals will be announced on May 6, and there will be a few weeks for community bonding before the start of the coding period on May 27.
In any case, don't hesitate to chat with us on IRC! #scummvm and #residualvm in the Freenode network are the place to go!
Work on the ScummGlk engine is ongoing. Since Christmas holidays I've been primarily focusing on adding support for the version 6 graphical Infocom games to the Frotz sub-engine, with particular focus on Zork Zero to begin with. Whilst I don't count the version 6 games among the best of the original Infocom line-up, ScummVM has always been about providing as good a coverage of old games as possible. So from my point of view it's worth spending the extra time adding support for the remaining Infocom games now rather than later, and only moving onto the next sub-engine once that's done.
Below is a screenshot of Zork Zero as of when I came back on the 7th January:
As you can see from the screenshot, the background is starting to be properly rendered, and the 'A' and location glyphs are properly rendered and interleaved with the text. The status bar still needs some work, though.. although it is being rendered, it's then being completely wiped out by the status bar window, which isn't even displaying any text yet.
Right now, I'm focusing on adding the 8x8 fixed size font used in the original games. If you look closely at the screenshot above, the current resizable TrueType font doesn't really look crisp at that low a resolution, and is somewhat blurry. I'm currently making a tool to use the same font data that Frotz has, and produce bitmaps to add to the fonts Zip file for the different 8x8 font styles (normal, bold, emphasized, and bold & emphasized). It has had it's share of issues:
Somehow, I don't think I've got it quite right yet.. :)
Anyway, progress is gradually being made, and I hope to have Zork Zero fully supported soon. The other v6 games currently error out immediately during startup, but I'm hoping further adding support for them will be a simpler matter.
Seasons greetings to all, and I hope everyone has a happy time as we finish 2018 and look forward to the beginning of 2019. As I sit in the Los Angeles airport writing this, I'm reminded yet again of how much fun I have doing reverse engineering, since even the smallest thread of work can lead you in unexpected directions as you trace the flow of what methods call a given method, and what methods it calls.
For something to do, I opened up my Companions of Xanth in progress disassembly to do a bit of pottering around with it. Just by chance, scrolling through the disassembly, I noticed a call to a method I was pretty sure took in a string, but in this case was passing in a value. I then quickly realised it was an offset n the data segment that hadn't been properly resolved, so I did that. The message in question turned out to be a generic "insufficient memory". So from it's usage, I was able to identify the entire method it was in.. it's called during startup, and ensures that there's enough free memory to play the game. Ironically, it looks like the code to actually display the message if there isn't enough was broken, as evidenced when I ran the game in DosBox debugger.
From there, identified a method just before the message call that took in a number and passed out a string.. it wasn't too hard to identify it as a number formatting routine. I confirmed it in the DosBox debugger by putting a breakpoint in the machine code, and seeing the result from the method. I then noticed that there was one other method calling it, so I was intrigued to find out what it was. It turned out it too was a block of code in a method that printed out the free memory, in a method that looked like a big switch based on a single value. It looked like a keypress. Playing the game, I was able to confirm that pressing 'M' on the keyboard did call the code, which printed out the amount of free memory in the status area.
This was a good woo-hoo method. I had identified the method for handling keypresses. Likely, some of the other keypresses do fairly identifiable things, like saving and loading, so knowing where each key's code is, I'll be able to trace into what they do, and what methods they call. In fact, the free memory printing for the 'M' key already prove dividends. From it, I was able to identify the method that cleared the status area, and a version of 'sprintf' for printing text in the status area. In the future I'll be able to look further into other places that call the method to add lines to the status area, and start identifying other parts of the game code. For example, looking at an item produces a description in the status area, so by setting a breakpoint in the status text writing code, I'll be able to identify what method calls it, and start identifying the structure of items that likely have a "description" as one of it's fields.
All this progress today came from a minor diversion to pass the time sitting in the airport. The notice of an incorrect parameter to a method call has unraveled more of the game's secrets, and giving me multiple further areas I can investigate. A nice way to start the holidays.
One of the things I like about my work on ScummVM is that it's a hobby rather than a profession, which gives me the freedom to switch what I'm working on when I desire. I've previously had encouragement to resurrect my Gargoyle engine work from about a decade ago. It was an early attempt to add support for Frotz into ScummVM, and at the time it was rejected due to multiple reasons. It was specific only for Infocom/zcode games, lacked clipboard, truetype fonts, and Unicode support. Most of these things have since been solved by the ScummVM framework itself, which now supports all of them. So I thought, why the heck not, and decided to work on it again.
However, my original Gargoyle engine being limited to just Zcode was a problem. Not only wasn't it extensible to other IF systems, but it would also take work to properly reimplement it to support Unicode. In the end, it was just simpler to scrap it all, and start from scratch. Luckily, there's the very convenient Glk specification, that was specifically created for easing porting the various Interactive Fiction interpreters to other systems. I knew that by supporting it, it would make it easier to create a framework that could support multiple different interpreters as sub-engines.
So I created a new Gargoyle engine, which I've since renamed it to ScummGlk to avoid ambiguity with the stand-alone Gargoyle project which also implements the Glk specification. After over a month of work, I've created an engine that implements the bulk of the API, and implements two sub-engines under it so far.. Scott for Scott Adams games, and Frotz for playing Z-Code/Infocom games. Scott was useful as a test case, due to it's simplicity. With it as the first sub-engine, I was able to focus on getting the ScummGlk core working. Then Frotz was a fairly obvious second choice, given it's popularity and large number of available fan games.
As of last weekend, the review period was completed for the engine, and it was merged into master. Daily builds now include support for both sub-engines. I've spend the last week fleshing out detection entries for all the ZCode games on the if-archive, so all the games will be automatically detected by the launcher. I'm going to wait on announcing an official testing period until I finish support in Frotz for V6 games. But if you can't wait, you're certainly welcome to jump the gun and try playing some games. Maybe one of the early Zork from GOG, or the immortal classic Freefall :)
Having the engine included into master will be a real nostalgia trip for me. Even prior to my original Gargoyle module, and before I even started working on implementing adventures in ScummVM, I spent several years as part of the Interactive Fiction community. Indeed, the Hitchhiker's Guide to the Galaxy was one of the first computer games I ever had. I spent way too many hours getting frustrated with the game's puzzles.
Over the last couple of days, we moved our downloads to a new mirroring infrastructure. Previously, each and every download was delivered by our main server located in Austria.
Now, our downloads are delivered through MirrorBrain, a download redirection system that allows us to build our own content distribution network. MirrorBrain is already used by many open source projects.
MirrorBrain tries to always select the best mirror based on your location, so you will get the best download speeds possible.
While we already have a few mirrors located in Europe, we are currently looking for people willing to donate some bandwidth and storage located in the US and in other parts of the world. If you want to mirror the ScummVM repository, please contact us via E-Mail at serra@scummvm.org.
If you run into any issues with our new download system, feel free to leave a comment in our forums.
A few weeks ago, we started improving our website, including (but not limited to) dusting off our forums and our wiki. There's also some stuff going on 'behind the scenes' like improving the way we handle translations for this website.
Over the next couple of days, we are going to roll out a new mirroring system for the downloads we provide in order to allow us to distribute the necessary bandwidth across several servers.
We are almost done with setting up the new system and basically just have to 'flip the switch'. However, it is possible that you might run into issues like broken download links or messages complaining about missing files during the transition period.
We are working hard to keep service interruptions as minimal as possible. Many thanks for your understanding!
Over the last few days the ScummVM team has been working hard on upgrading our infrastructure. During the process all of the supporting sites have been updated, cleaned up and secured with SSL support.
Due to how DNS propagation works it may take up to 48 hours until you can access the forums and wiki.
If you run into any problems with the Forums, Wiki, Translations, Bug Tracker, or any other website related issues please let us know. For minor issues feel free to post on this thread. For major problems use the bug tracker using the Web component to let us know.
It's been a while I haven't posted something about what I'm doing... So here it is.
There's nothing new concerning Kingdom: The Far Reaches. I'm still waiting for a hand with the MVE player, and TMM (who implemented the MVE missing opcodes in ffmpeg) is still super super busy. So, well, let's consider it's rotting. :(
I made some very small progress on Adventures of Robin Hood (lilliput engine) on the sound, but it's still very imperfect. To implement it, I think I should add a mixer, we'll see...
More recently, let's say a week ago or so, I started documenting Escape From Hell. I currently have half of the functions renamed and most of the structures. I'm not really sure it'll be an engine for ScummVM as it doesn't use a mouse, but it's fun to make good progress on something I vaguely looked at more than 10 years ago. At the time, I guessed the compression format, picture format, and enough of the maps and monsters to display maps. I even brute forced the encryption...
All that is now far more clear with an eye in the binary :)
Ho, I forgot to mention: Escape From Hell is using a modified Wasteland engine, in case it rings a bell :)
This is the summary of all the works I have done in Google Summer of Code 2018.
Overall Description:
Improvement for the Stark engine used in ResidualVM for the support of the game The Longest Journey with two main focuses: menus and characters' shadows.
Pull Requests:
Below are the main PR created and merged, ordered by the sequence of development. One may click the number of the PR to view it in detail on GitHub, which contains discussions between me and my mentor along the development.
The two main focuses: menus and characters' shadows are finished as scheduled. All codes have been merged and one may test and use them freely in the game.
Other than that, there are some issues, which is out of expectation, emerged during the development. The feature of pressing F8 to save a screenshot is not implemented for the time being. The confirmation dialogs are still pretty rough. Also, there are some proposed GitHub issues related to the engine, most are about the debug console. I have planned to tackle them after GSoC and I will keep engaging in the future development of ResidualVM to help further improve the Stark engine.
Google Summer of Code officially ended last Monday, August 6th. My project was to
reimplement Star Trek: 25th Anniversary in ScummVM.
The project involved reimplementation of all of the hardcoded game logic, since it doesn’t
have a scripting language. In my original proposal, I conservatively estimated that
I would finish only the first 4 away missions, of 7 in total. In fact, I managed to finish
all 7 (though it took a few days past the official end time).
That doesn’t mean it’s done though; the away missions are only half of the game, albeit
the larger and more interesting half. There also remains the pseudo-3D space combat
element, which I dabbled with, but am still nowhere near done with. I’m hoping to be able
to finish that by the time summer’s over, though I can’t make any guarantees on that.
So: the end result is that, right now, you can play all 7 away missions in Star Trek: 25th
Anniversary in ScummVM. However, without the bridge sections or space combat, players will
be missing the context of why you’re on the away mission in the first place.
Here is a more comprehensive list of what remains to be done in the long-term:
Space combat, segments taking place on the bridge (finish implementing 25th anniversary)
Support for non-DOS versions (mac, amiga) and other languages (french, german)
Support for Judgment Rites (probably not happening too soon unfortunately)
To compile ScummVM with the star trek engine, run:
./configure --enable-engine=startrek
make
Then, you will need to provide ScummVM with the original DOS game data files, and copy the
“voc” folder from the CD into the same folder. (If you don’t do this there will be no
voice acting and missing audio.)
The final mission
Continue reading for the regular postmortem on the mission I just finished working on.
Spoiler alert.
In this mission, the USS Republic, which you fought in a mock battle at the very beginning
of the game, gets demolished by a mysterious assailant.
There are reports of softlocks in this mission. One is that after you lower the shields,
the Elasi immediately beam over before you can shoot them, rendering the mission
unbeatable. I haven’t verified this, but I can see why it would happen based on reading
the code; the timer that’s supposed to make them beam over before you raise the shields,
also applies after you lower the shields! So, if you lower the shields much more quickly
than the developers expected, that counter may reach 0 and cause the elasi to beam over.
There’s another reported softlock, though, that doesn’t seem to be a real softlock. For
some background, in the auxiliary control room, you’re supposed to either “use” or “look
at” a specific part of a console in order to see that the torpedo loading mechanism is
jammed. This triggers an event flag necessary to complete the mission. A GameFAQs guide
claims that under certain circumstances, it becomes impossible to do this, which is only
half-true.
Once you power up the shields, it becomes impossible to power up the weapons until later
on. The result is that you cannot “use” the weapon system to trigger this event flag;
however, you can still “look” at it to do so.
It’s all rather confusing - and it doesn’t help that you need to click on a very specific
part of the console for any of this to work - but I haven’t found a softlock here. Though
if I’m mistaken I’ll gladly fix any further softlocks.
Interestingly though, in the hallway that links the two turbolifts together, using Spock
on the debris at the end of the hall, when the support beam is in place, would crash the
game, because code execution actually derails into executing data. Those kind of mistakes
can happen when writing raw assembly…
Anyway, that’s the most interesting stuff I’ve found in the final mission. I may make more
infrequent blog posts as I work on the rest of the game, though don’t expect the
almost-weekly updates I’ve been providing up until now.
During the last three months I worked on porting The Immortal. Unfortunately, I have fallen ill last month and are still recuperating so I haven’t got much work done since. Although GSoC is ending, it doens’t mean work on The Immortal will cease as well. I will keep working on it over the next month to make up for my sick days.
Those are the big ones left until the game is in a playable state. I'm sorry for everyone that was looking forward to play the game at the end of this GSoC period and hope to make up for it by the end of September with a PR. I want to thank my mentors Arnaud Boutonné, Thierry Crozat, the whole ScummVM team and Google for creating the Summer of Code in the first place.
During GSoC 2018, I was working on adding support of Pink Panther games to ScummVM: The Pink Panther: Passport To Peril and The Pink Panther: Hokus Pokus Pink.
With the help of my mentor, I followed the logic in the original game and finally, now The Longest Journey in ResidualVM shall have shadows that are calculated based on actual lights in the scene!
Below are some screenshots as demonstrations. For a better illustration, I temporarily rendered the shadow with solid green. As you can see, in location 39 00, the shadow of April will become longer and change its direction based on the lights.
As I have said in the previous blog, the game computes the shadow in a way that is not the same as the reality. Well, with the help of my mentor on reading the disassembly, the truth behind the screen was revealed. Honestly speaking, after knowing this, I really don't think I can figure it out just by observing the game itself.
So, in general, the game first calculated an overall direction from lights. The way to compute the directional vector from lights varies based on the type of the light, but basically, it is related to the distance between the model and the light and the brightness of the light. Notice that I am saying "model" here, not vertices. It turns out that one light direction is applied to all vertices of a model.
The Calculation of the Point Light
After that, the directions from all the lights are summed together as an overall direction. Remember the maxShadowLengthI mentioned in the previous blog? It is used to clip the horizontal length of the overall light direction. It turns out that the maxShadowLength needs to be divided by 1000 before being used, that's why its value seems to be so large.
After that, things become trivial. By passing the overall light direction to the shader, with some linear algebra, it is easy to calculate the casted position of a vertex. It is even easier if you first transform the light direction to the model space since then the plane of the shadow is just the XZ plane. You can save some of the math.
The Vertex Shader
By the time when I wrote this blog, the PR was not merged yet, but I believe it is very close to that. So now, all the tasks scheduled for this year's GSoC are finished. I have learnt tremendously from this project. I get more familiar with C++, I know more about game programming, and I even get some hands-on experience on CG with OpenGL! Also, I need to express my greatest gratitude to my mentor bgK. He is truly a good mentor. Without his detailed reviews and clear guidance, I would never accomplish so much. This is a truly wonderful journey and a valuable experience.
Thank you all, for you guys are truly wonderful :D
I’m sorry for the lack of progress and apologize to everyone that is eagerly looking forward to playing the game. Fortunately, after a short stay at the hospital I’m feeling better now and can resume work on the project.
added finding similar colors in the palette to represent ActionText’s RGB colors, which aren’t located in the palette.
bugfixes
Now the colors are implemented, only text is left. Text which is used in text files was written using Windows codepages(1250, 1251, 1252, 1255), depending on the language. To use text in ScummVM I need to convert it to UTF-32 and add unicode support for MacText.
Probably I will hardcode conversion tables, as I don’t see another way how to do it.
Well, probably the shortest blog ever this time...
Long story short, I haven't figure out how the original game computes the shadows. There can be at most ten lights in a scene but there is only one shadow, and the way that shadow reacts with lights in the game is just, so strange...
Take this scene as an example. The green circle is the range denoted by the field maxShadowLength. It's too large, way larger than the true shadow length in the original game. There is only one light entry here, the lamp. You may imagine what will happen if you hold a lamp so close like this. The shadow should be extremely long and cast on the wall, right? That's not what happens in the original game. In fact, the lamp just moves the shadow a tiny bit against its direction.
So I can only draw the conclusion that the original game does not compute the shadow as the reality. I have tried many possible and "reasonable" implementations that came into my mind but none of them seemed to be fit. (Yeah based on the above description you may be thinking about biasing the length or something like that but believe me, I have tried, really.)
Have to say that this is really frustrating. Anyway, I'll keep on digging next week.
No real progress as I have been feeling really sick the last couple of days. A sip from that fountain water would be really nice right now… The camera tracking of the player is still a bit wonky but once that is ironed out, object iteraction and triggers are next as was planned in last week’s post.
This past week has been spent on space; trying to make heads or tails of the game’s
“pseudo-3d” engine. And, while it hasn’t been entirely unsuccessful, progress on this
front has been relatively slow.
I started by getting the background starfield working. It involved some trigonometric
functions and matrix multiplication. Nothing too insane, once I figured out what I was
looking at. To complicate matters, the game has at least 3 fixed-point decimal formats,
including a format specifically for numbers between -1 and 1, in addition to using the
processor’s floating-point hardware on occasion.
Encouraged by this early progress, the next step was to make more elements of the game’s
intro visible, starting with the red planet the Enterprise flies past. However, when
I finally reached the function which draws space objects to the screen, the function graph
showed me this would be no picnic.
Each box is a block of code, some too small to see.
Despite my best efforts, I was unable to quite get this working properly. I discovered
today that I didn’t even have an accurate view of the function, because part of the code
is overwritten from elsewhere before it gets called! Perhaps because of this
incompleteness, I was only able to get a sliver of the image to appear in a glitchy way.
I’ll figure this out, eventually. But I alotted myself a week to work on this before
moving on to other things, so I’ll come back to this later. It’s time to start focusing on
code cleanup so this can be merged into scummvm, as well as finishing up the away
missions. Then, I’ll come back to finish space combat and everything between missions.
Last week I worked on mission 6, “That Old Devil Moon”. It features some interesting lore
of two ancient civilizations that annihilated each other through the use of nuclear
weaponry. What a totally, uh, alien and unthinkable prospect, haha…
This mission features the most obscure puzzle in the game, which involves converting
“sacred numbers” from base 10 to base 3 to crack passcodes! While I personally can handle
a bit of base conversion, the even bigger sin is that the hint required to open the door
is missable! If you fail to look up every remotely relevant entry in the ship’s computer
before beaming down, you’ll have no way of even knowing what numbers you’re even supposed
to convert! I definitely had to look up a walkthrough here.
Incidentally, while implementing the text input boxes, I found a way to crash the game.
Simply fill up the box, then repeatedly press the “end” key, enter a character, press
“end” again, etc. Soon the text buffer overflows into something that’s probably important
and the game crashes. This works because the “end” button is the only one that doesn’t
check if the length of the string exceeds the maximum text size. Naturally this is fixed
in scummvm.
In addition, this mission, too, has some ways to get an infinite score, by repeatedly
scanning or using the computers in the final room. Using McCoy’s tricorder on the air in
this room also works. That’s all in the way of bugs that I’ve found, though.
GSoC officially ends next week. I’ve opened up my pull request to the main branch, though
the engine is still incomplete, so I can continue working on it in-tree; in addition to
working on the final mission this week, I have some feedback to take care of before the
pull request gets accepted.
And I said: "Let there be shadows!" And there are shadows. Just, not good enough...
So, from this week till the end of GSoC I guess I'll be dealing with OpenGL. As a newbie to computer graphics, I would be lying if I say that I am not worried at all. I once believed that OpenGL hated me, it hated me so much that it didn't even want me to render a tessellated triangle on the screen. But that hard time is passed now and I am happy that I start to get along well with OpenGL, and it is kind enough to let me produce something physical this week.
Ah, the shadow.
Okay, shadows. Actually what I have done so far is based on my previous wrong assumption about shadows in The Longest Journey. In most of the scenes I have played, which is not many actually, characters have shadows that look like they are cast from above. The Longest Journey is a 2.5D game with 3D characters and 2D backgrounds, so, in my personal perspective as a CG newbie, it won't be that intuitive to perform a full shadow casting technique like the Shadow Mapping here. But if shadows are just cast from above, then things are a lot simpler.
So, with this "wrong" assumption, and the fact that the original game doesn't seem to have complex and realistic shadows, I decided to use the simplest shadow casting technique: Planar Shadow. Basically, it just squishes the modal onto a surface and paints it grey. Since I just want to cast the shadow from above, the squishing is even easier. Below is a screenshot when I was testing how I could squish the model.
April: I don't feel so good...
That's not the whole story. A good shadow should be semi-transparent. But simply enable blending is not enough since transparent faces will cover on each other, and there will be the Z-fighting problem. The solution is intuitive though: stencil test. With the enabling of the stencil test and proper manipulation on the stencil buffer (no two shadow fragments can be drawn on the same location), a nice semi-transparent shadow is produced.
Blending and Stencil Tet
Well, like I said before, this is a wrong assumption. The Longest Journey does compute shadows from existing lights. And there are three types of light in the game: point light, directional light and spotlight. Luckily lights only contribute to the length of the shadow, so right now I think the Planar Shadow technique can still be used.
From the look of it right now, I guess it is time for some linear algebra. More updates will come next week.
Even the simplest thing can turn out to be a big time drain. I encountered mismatches in the mapping for sprites and their actual position in the files before and assumed that some change from version to version. Apparently, they changed the file layout and compression mid-development and added a lookup table to remap sprite packs and files to how they (presumably) were originally. I’m glad it cost me only a day of manually jumping around in tables and I didn’t end up with more work than necessary. Seeing the wizard casually paddle out of bounds on his barrel is more than worth it though.
The inventory is almost done (except for using items of course). Either text rendering needs to be refactored so it can be used outside of dialogs or rewrite the inventory so it fits the structure of a dialog. I will update the GIF tomorrow once it's fixed.
Next
Update viewport camera to follow wizard
Render static objects (chests, torches, …)
Collision detection
Interaction with objects (pick up items from bodies, chests, …)
Last week was mostly focused on finishing up the second part of the “Feathered Serpent”
mission, in which Quetzalcoatl is put on trial by the klingons for spreading messages of
peace. Kirk agrees to go through a set of trials to prove his honor or something so that
Quetzalcoatl can go free.
Kirk offering a fine defense.
Mission oddities
Last week, I mentioned various ways to get an infinite score in this mission. Well, there
are even more, easier ways to do so in the second half, including:
Repeatedly scanning a door lock with Spock.
Repeatedly scanning an energy life-form with Spock.
Repeatedly carving out part of a room with a phaser.
All of the above are in a single room. This room also interestingly allows you to cancel
a death if you react fast enough.
In addition, this mission has two endings (three if you just give up defending
Quetzalcoatl entirely). The “main” win method is to discover a weird alien room, which is
probably what most people did.
The secondary method is very obscure, and I suspect most people don’t know about it. If
you don’t discover the alien room, you instead must pass a Klingon automaton blocking you.
Since the solution is so obscure, I’ll just tell you. Using the stun phaser doesn’t work;
after two shots, it kills the crew. Using the kill phaser doesn’t work, either; it kills
the crew after only one shot.
So, what’s do be done? Use the stun phaser, THEN the kill phaser. That will give it just
enough energy to overload before it can take out the crew. …Naturally…
On my casual playthrough, I completely gave up on passing the automaton, since I already
knew about the other method of completing the mission. This is an “inferior” way to
beat the mission, anyway, but it’s interesting that it’s locked behind such an obscure
solution.
What’s next
For now, I’m taking a break from the repetitive mission logic to take a look at the
pseudo-3D and ship combat stuff. I really have no idea how long this will take, but I felt
I needed to look at something fresh and different. Regardless, my primary mission is to
get the away missions working and I only have 3 weeks left (officially), so I’ll return to
that if time doesn’t allow me to finish the starship stuff. Due to the belatedness of this
post, there’ll be another later this week.
This week, in addition to finishing up the Harry Mudd mission, I’ve done the first half of
mission 5, “Feathered Serpent”. This is the only mission to be divided into two “away
mission” segments, with another ship segment between the two.
In classic Star Trek style, we encounter the Aztec god Quetzalcoatl (Quetzecoatl?)
attempting to bring enlightenment to the Klingons. Lt. Buchert must have jinxed us when he
mentioned the absence of any angry gods last mission.
The first half of the mission consists of eight rooms, which is technically a record so
far, but some rooms are little more than scenic pathways. It’s also very linear compared
to other missions. There’s only one case where you might have a reason to backtrack at
all, and often you’re prevented from going back to previous rooms entirely.
This mission has some rather pretty screens.
Mission oddities
There is a case where you can scan Lt. Stragey (the redshirt) while he’s dead, and
someone who is… clearly not McCoy, say “He’s dead, Jim”. Was DeForest Kelley sick that
day? Well, he says the same line in other places, so I substituted one of those in.
There are at least two ways to get an infinitely high score in this mission. The first way
is to repeatedly try to grab a snake in the second room. Whether you succeed or not, you
get a point each time. (Normally the snake retreats into a hole before you can grab it.)
The second way is to repeatedly solve one of the puzzles. I don’t really want to give away
any solutions, but there’s a particular action you can do repeatedly on the lake screen.
The first time, it wards off a monster, but after that it serves no purpose, despite
continuing to give you points.
Unfortunately, based on my limited testing, it looks like your score does cap at 100% in
the final report.
Unused stuff & version differences
The devs seemed to have a good sense of humor; in particular, the original floppy version
was snarkier in places. If you use a knife on yourself, it says “You won’t break your
contract to the network that easily!”
That line was changed later; this particular piece of text changed between the original
floppy release, the mac release, and the voiced release. Supporting all 3 will surely be
a nightmare.
Also, it turns out that the redshirts are named after the devs, which somehow makes the
redshirt deaths seem even funnier.
A personal favourite of mine.
I’ve also encountered the string “***Game Over, Man!***” in the game files multiple
times, at least back in the first mission; perhaps it was used before they implemented the
“game over” menu properly. Today, I even found a voiced version which seems to be unused,
done with all the professionalism of any other line. I wasn’t a fan at first, but this
narrator voice is growing on me.
Anyway, there are just two and a half missions to go now. I think I could manage to finish
this within GSoC, starship sections and all. I doubt I’ll have enough time to finish
Judgment Rites, but perhaps I can get a decent chunk done if space combat doesn’t turn out
to be too insane to implement.
March 06, 2019
Each box is a block of code, some too small to see.
Kirk offering a fine defense.
This mission has some rather pretty screens.
A personal favourite of mine.
