Yeah. There's a gate finding oracle (src/control_oracle.py) that runs on every room.
The positional work is actually being extended right now, because KQ5 makes complicated use of it.
69 karma · joined November 5, 2014
The positional work is actually being extended right now, because KQ5 makes complicated use of it.
The door is a sprite, declared in the VIEW, that is in the way of the strip of elevator shaft (declared in the PIC) that you have to step on in order to exit from the volcano (room 82) to room 83, which is the beginning of the endgame.
If you just look at the script, the fact that you can't just walk into the shaft is not visible. Once you've caused the explosion, all that happens is that a variable is set called causedEruption, and the door animation happens. Nothing else other than a look message uses the value of causedEruption in the script. So before we added in the VIEW and PIC files, the engine thought that the endgame was free once you stepped onto the volcano crater.
The PIC file is what tells you that that strip of the screen matters (it's the exit), and the VIEW file is what tells you that the door (a sprite) initially blocks access to it, and once it becomes open allows access to it.
So the engine had to look at the VIEW and PIC to deduce that causedEruption was the flag that mattered, which meant that the items you have to use to cause said explosion were needed for the endgame.
Also in LSL2, nothing in the script tells you that you can't dodge the KGB agents on the beach by walking around them.
In KQ6, the patched game prevents you from returning to the Labyrinth entrance unless you hold everything you need for inside. Stepping on the mountain will just not work. So you can save inside... you should be "safe" at that point (as safe as you can ever be in a Sierra game, lol).
I feel isolated and lonely when there is a group that has a common narrative and set of assumptions that I don't fit. These come out in general statements, assumptions, and/or jokes. Then I have to decide whether to hide my own preferences (lying by omission), get into an argument, or change my preferences. All three options are exhausting and take energy away from actually doing work.
Examples:
* Generalizations about "real haxx0rs": "programmers have side projects", "programmers use [operating system of choice]", "programmers heavily customize their editor", "programmers can't get a girlfriend/are introverted/socially maladapted", "programmers don't care about their clothes", "programmers don't wear a tie", etc.
* Disproportionately caring about one set of users/customers which resembles the team. Example: spending a lot of time talking about/fixing the experience of male users when the vast majority of users are female (and the product is not mature yet); making fun of users and their silly ways when the majority of users are female and/or non-technical and/or young and/or old and/or not from cosmopolitan areas, etc.
* Having to have a conversational style that's significantly more aggressive than what is natural for me in order not to get left out of conversations. I have to be comfortable cutting people off in meetings and jumping on the ends of sentences. I've learned to do it but it's pretty exhausting, and takes energy away from actually doing work. Also, having to jump verbal cues gives me a feeling of insecurity about people not caring what I have to say unless I shove it down their throat, even when that is obviously not the case (because my input is well-received).
As a manager/CEO, here are a few things you can do to help:
* Allow hires to be vetoed on the basis of not having an inclusive worldview, regardless of their professional ability. You can ask "tell me of a time when" type questions to suss that out. Eg, "tell me of a time when you had to convey a complicated technical point across to a non-technical customer (or team)", and watch for denigrating statements. I've given product manager candidates hypothetical products to design for a very particular audience, and anyone who made excessive fun of the intended audience was a no hire.
* Enforce civil conversational standards around the workplace, ie no off-color jokes, talking down to customers, empty generalizations, etc. I don't mean sending around HR videos on what not to say, I mean simple statements like "That's not funny, and offensive" (said flatly), "This customer pays us $X" or "That's not how we're going to improve our conversion rate", etc.
* Encourage open and written discussion of issues, eg via bugs, written code buddies/reviews, etc. Have anyone be able to veto a commit (with good reason), or reopen a bug. Having the bulk of these discussions in writing can help shy/non-confrontational people have their say. Having a focus on getting things done, and getting them done right, vs how exactly they get done can also help people feel more at ease.
* Pay close attention in group discussions to see if anyone is chronically unable to finish their thought without being shut down or talked over by someone else. If their thoughts have merit, be their advocate and calmly say something like "I'd like to hear X finish their thought". Say it as often as necessary. Then encourage other people to say it for you, when necessary.
Aside from all of this, as an early startup employee I've been mistaken for the admin, and as a consultant I've been in situations where people assumed at first sight that I was dumb, not technical at all, had not programmed for long, and more generally was less competent than others. If these prejudices survived one conversation they were generally a sign that the company was pretty fucked up and that much more was wrong with it.