I have a non-player character in an Inform 7 Interactive Fiction story that I would like to get a simple reply from. The character is a robot doctor. When you get on the exam table the robot doctor holds out a tongue depressor and asks you to say, "Ah." I would like the character to say something when the player types, "say ah" but so far it's not working.
Here is my code thus far:
The exam table is a supporter in the Med Bay. It is fixed in place and enterable.
In the Med Bay is a person called Auto-Doc.
After entering the exam table, say "A number of bright lights embedded in an overhead panel bathe you in a cold, white light. A panel in the wall opens and an auto-doc trundles forth on a three-wheeled base. Clutching a tongue depressor in its mechanical grip, a small speaker hidden within crackles with the words 'Say, ah.'"
After speaking in the presence of the Auto-Doc, say "Mmm. Mm-hmm. Very interesting."
The last line is causing the compiler to throw an error, but I am unable to figure out what to use. I've tried Instead of speaking, After telling the Auto-Doc something, After saying ah in the presence of the Auto-Doc, and so far nothing is working.
Any hints as to how I can get the Auto-Doc to say something after the player types "say ah"? I'd even be happy with the Auto-Doc replying the same way no matter what the player says.
Here's a handy tip: command ACTIONS while playing the game in the IDE to see the action name when you type commands.
>actions
Actions listing on.
>say ah
(to Auto-Doc)
[answering Auto-Doc that "ah"]
There is no reply.
[answering Auto-Doc that "ah" - succeeded]
>
So the rule you're looking for is:
Instead of answering Auto-Doc that "ah":
say "Mmm. Mm-hmm. Very interesting."
After some more research, I have discovered that the responses understood by Inform are yes, no, and sorry. So understand "ah" and "say ah" as saying yes. followed by Instead of saying yes in the presence of the Auto-Doc, say "Mmm. Mm-hmm. Very interesting." is one way to do it.
Here's what the code looks like now:
The exam table is a supporter in the Med Bay. It is fixed in place and enterable.
After entering the exam table, say "A number of LEDs embedded in the ceiling switch on, bathing you in a cold, white light. A panel in the wall opens and an auto-doc trundles forth on a three-wheeled base. Clutching a tongue depressor in its mechanical grip, a small speaker hidden within crackles with the words 'Say, ah.'"
In the Med Bay is a person called Auto-Doc.
Instead of saying yes in the presence of the Auto-Doc, say "Mmm. Mm-hmm. Very interesting."
Understand "ah" and "say ah" as saying yes when location is Med Bay.
Instead of saying no in the presence of the Auto-Doc, say "Hmm..."
This sets up two different non-committal responses for saying yes and no. Saying 'ah' is understood as saying yes, so the player gets a response.
I'm pretty new to Inform and it seems like this shouldn't be too hard to do but I haven't yet found a way. I want to change a room's description based on where the player came from. Something along the lines of:
The Town Square is a room. "As you enter the small town square, [if yourself came from West]
the rising sun makes silhouettes of the roofs and spires to the East.[otherwise]your long
shadow strides before you as the Sun rises behind.[end if]"
What's the best way to go about this?
I found a reasonable solution:
The last location is a room that varies.
Orientation is a direction that varies.
Before going to anywhere, now the last location is the location of the player.
After going to anywhere:
now orientation is the best route from the last location to the location, using even locked doors;
continue the action.
The Town Square is a room. "As you enter the small town square, [if orientation is east]
the rising Sun makes silhouettes of the roofs and spires to the East.[otherwise if orientation is west]
your long shadow strides before you as the Sun rises behind.[end if]"
The "using even locked doors" modifier ensures this will work even if a door closes and locks behind the player. The solution does assume that the player has come via a reversible route, which may not always be the case e.g. if the player has teleported.
I´m creating a 2D isometric city building simulation and today I have kind of a "best practice" question without asking for specific code.
As in all city building games you are able to place building, roads and so on. The player is able to place building everywhere, no matter if it´s connected to a road or not. In addition to that there is one building (call it center building) all the buildings need to be connected with (by road).
I need to handle that without doing too many calculations which, breaks the FPS.
Right now I have a timer job for each building which checks if one of the surrounded tiles of a building is a road. That works fine, also for a lot of buildings since the check is simple.
But now I would like to check the connection to the center building. To check that it is necessary (in my opinion) to use something like a pathfinder, which checks if one of the surrounded tiles has a road connection to one of the surrounded tiles of the center building.
I can not check that frequently because this completely smashes the FPS down to 30 or lower. My idea was to fire an event if a road has been built or destroyed to "recalulate" the road connection. But there comes another problem...the player might destoy a road in the middle of the map and the buildings are really far away from each other so I need to find the involved buildings which also might take too much time.
My last idea is creating something like a timer queue and work through these items gradually, but before I keep using the trial and error method I would like to ask you for ideas.
Really looking forward to your ideas!
Yheeky
You could have each building store a list of tiles (a path) that connects it to the center building. Then when a tile is randomly destroyed by the player, you can have each building tested to see if it pathed through that road tile or not.
Alternatively you could have each road tile store which buildings require it, so when the tile is destroyed you have the buildings immediately throw flags. This could get quite messy though, but lends itself decently to background speed cleanup calls.
Both methods are quite messy. Perhaps you can make it a rule that the player can't place roads except next to other roads or next to the center building. Then when the player deletes a road tile, do a paint-style fill that destroys all of the disconnected roads. You can also periodically do a random check on tiles to see if they are illegally placed or not, but that should be unnecessary if you're careful.
I have a number of things I want to restrict from fitting through specific doors. So the chair is too big/heavy to carry but can be pushed through room to room in most cases. Except if the door is narrow. I can probably write specific code successfully to handle a specific case, but I want to handle this generically so I can have a number of bulky things and narrow doors.
The follow code functionally works, however the second noun ends up "nothing". I would like to use the name of the door in the direction of travel to respond to "push chair s" with the message "The chair is way too bulky to fit through the crack". Any ideas what I am doing wrong or another way of doing this?
A thing can be bulky. A thing is usually not bulky.
A bulky thing is usually pushable between rooms.
A door can be narrow. A door is usually not narrow.
A bulky, enterable supporter called the chair is in room1.
There is a narrow door called the crack. It is south of room1.
Before going with a bulky thing through a narrow door:
say "[The noun] is way too bulky to fit through [the second noun]." instead;
You can name the things in the rule preamble and use those names to print them in the rule.
Before going with a bulky thing (called the cargo) through a narrow door (called the obstacle):
say "[The cargo] is way too bulky to fit through [the obstacle]." instead.
When computing checkmate for a king in chess, do you determine the other players possible moves against your king? Or do you consider merely their unit's reach? If you say it's the former, then there is a contradiction like "this statement is false" Consider this image with two kings a square apart and their knights protecting from above rooks. If we assume that the definition of possible moves must prevent check based on enemy possible moves, then the logic recursively alternates.
First, we say that our king is in check from the enemy knight so we are limited from moving our own knight because we must escape.
Then we realize that the knight does not have an available move into our king's square because he will be placing his king in check with our rook. He does not have our king in check after all.
Then we realize, free from check, that we are now able to move our own knight to the enemy king forcing him to move from check and preventing further his choices.
However, we notice that we cannot do this because it will place us in check with the enemy rook.
We realize that since we cannot actually move our knight, the enemy king is not actually in check, therefore he is freely able to use his knight to attack our king.
Go to step 2 (no matter how many times you have already).
Okay, so maybe we assume that reach always counts regardless of the enemy's check status. If our king is in reach of the enemy knight's usual attack range, we consider it a check and must resolve it. Is this how the actual game is ruled though? It seems an easy solution to the problem faced when programming the game logic, but I'm not sure if it is correct or not.
I did some thinking and came up with this analysis:
I think you have proven that the scenario of both kings being in check (not necessarily the scenario of the board I showed) cannot exist by contradiction.
Only one player can make a move at a time.
Therefore, one player makes the initial move which transitions from the state of no kings being in check to some king(s) being in check.
According to the rules, this move is not allowed if that player's king results is in a check. (I will point out the significance of 'results' soon)
This means that no matter how check is defined, he cannot make any move if his king meets that condition.
Therefore, the only transition to checks from no checks is to the enemy being in check.
The enemy must escape check, still following the rule of not entering check in one move.
The remaining state would be game over or that king escaping check.
So I understand that both kings being in check is not possible.
Now the board I showed is either reachable or not reachable.
Let's assume the board is reachable and see if there is a contradiction.
Let's ambiguously assume it's white's turn since the scenario is symmetric.
This means black just moved.
Therefore, black's king is not in check.
The black king is only reachable by the white knight.
Therefore, the white knight must be restricted by some rule to not attack the black king.
The only two possible rules that can enforce that conclusion are:
The white knight is currently protecting his king from check.
The white king is in check already and that move will not solve the check.
First, assume 2 is true regardless of 1.
The white king is in check and the only piece in attack range is black knight.
The black knight cannot attack the square containing king, however, because it would place his own king in check.
Therefore 1 must be true and the white king is not in check.
So both kings are not in check.
We reverse the game board to see if this is reachable.
Assume the scenario with the following alterations:
White has a bishop 2 up and 1 right from the black rook.
The black king is one square to the left.
The white king is one square to the right.
No kings are in range of any other pieces, so it may be reasonable to assume this initial state is reachable.
The black knight is protecting his king from the bishop, so it cannot move to under the white knight.
The white king moves left.
Now the white knight is protecting the white king and cannot move to under the black knight.
The black king moves right one square.
Thus, the scenario is reachable.
The only questioned assumption standing is that when any moves are considered, it is safe to assume that the check rules are computed. Thus, a king may come in range of a unit which may not attack it due to prevention of his own king being in check. If this assumption is not made, then the pieces simply could follow the rules of not allowing kings to enter the unrestricted attack range of an enemy unit.
Now, it is interesting to see if this scenario is computable without infinite loops.
For dependencies, I will use arrows.
For the initial white king moving left,
white king -> black knight stopped -> white bishop attack black king
Those are single step computations, no loops in dependencies so far.
For the black king to move right,
black king -> white knight stopped -> black rook attack white king
Still no dependencies.
What about when we now try to check white knight's available moves including attacking the black king?
white knight stopped -> black rook attack white king
What about if the white rook attacks the black rook?
white rook stopped -> black knight attack white king
White's remaining options are to move the king to the right or down.
Our conclusion,
Moving to this board state is possible without breaking the 'don't move into check' rule.
This board state obviously assumes that computing check depends on possible enemy moves, not their simple native attack ranges.
When this state is reached, both kings are not in check.
It is at least possible that this is not a stalemate. (Unknown if always)
So I finally found rules on wikipedia about placing another king in check even if it compromises one's own king. So, we cannot make our assumption in part 2, thus the board state is not reachable.
"A piece unable to move because it would place its own king in check (it is pinned against its own king) may still deliver check to the opposing player."
Thus our final conclusion for the apparent actual rules of chess, the board state is not reachable as it follows the check rules.
I am going to choose icedtrees answer because of the valuable logic which follows the game rules:
if for every move for player X (ignoring rules about king threats),
player Y can capture player X's king next turn,
then player X is in checkmate.
However, I would fix them to be the following:
{X is checkmate}
if and only if {
For all legal moves:(move according to rule definition) X {
There exists a generic move:(legal move A ignoring rules of protecting king A) Y such that {
X king is captured
}
}
}
I may be misunderstanding, but I think your problem is easily fixed by noting that it is only possible to be in check if it is your own turn. Check in chess is associated strongly with a compulsion to defend the check, and you cannot do that if it is not your turn.
For any chess position, it is VERY IMPORTANT to define whose turn it is, because that lies behind so many mechanics in the game. In your board position, if it is black's turn, then black is in check, and if it is white's turn, then white is in check.
Even if the position is impossible, you can still define some good rules about positions that are good for chess computations.
Some notes on checkmate in chess:
Checkmate is actually not very intuitive, and when you play the game you start to notice funny checkmate situations that do not make much sense.
Here is a good way of thinking about checkmate, in my opinion:
In a legal chess game, when checkmate occurs, the checkmated player is unable to prevent his king being captured the successive turn by the opposing player. That is, checkmate in chess is nothing but "ending the game one turn early", so to speak. If you ignore all rules in chess about threats to the king, but preserve the movement patterns of the pieces, a computer could calculate checkmate by looking forward.
The logic would be as follows:
if for every move for player X (ignoring rules about king threats), player Y can capture player X's king next turn, then player X is in checkmate.
Here is a more complete version of "check and escaping check":
Given it is player X's turn:
if player X's king is in movement range of player Y's piece, it is in check. If the piece cannot escape check, it is checkmate.
There are three ways of escaping check:
Moving your king to a non-attacked square
Blocking the piece(s) delivering check
Capturing the checking piece.
Maybe you're over-thinking this :-)
Here's the algorithm from a working chess program that's relatively strong in human terms:
Generate the list of pseudo-legal moves for the side to move. By pseudo-legal, I mean don't bother to verify whether the generated move leaves that side's King in check. Omitting this verification can save time validating moves that are never searched.
For each move that is searched, validate that it doesn't leave the side to move in check.
If every move leaves the King in check, then the side to move has either been mated or it's stalemate.
If the side to move is currently in check, then it's mate. Otherwise it's stalemate.
My naïve approach would probably go like this.
player.startTurn();
if (player.isInCheck()
if(player.king.hasNoLegalMoves() && player.cannotProtectKing())
game.checkMate(player);
function isInCheck() {
boolean isInCheck = false;
for (Piece p : player.Opponent)
if (p.canAttack(player.king) {
isInCheck = true;
return;
}
I may be missing something here, but I don't understand why it wouldn't be this simple.
For one thing, this board position isn’t even REMOTELY possible.
1) How did you get the rooks and kings off the first and eighth ranks without moving any pawns?
2) Check is defined as the state where your king is under attack by an opposing piece. CheckMATE is the situation where you are in check and cannot legally get out of check.
3) If it’s your turn and one of your pieces is capable of capturing the opponent’s king, it doesn’t matter if you would put yourself in check to do so: it’s whose king would die first?
4) Notwithstanding that, if it’s your turn and your opponent is in check, it either means neither player noticed that your opponent was in check (in which case you go back and make sure they can—and do—get out of check before you do anything else) or that nobody noticed that it was checkmate.
So, when it’s your turn you can’t finish in check, but when determining a threat to the king, the opposing king’s safety is irrelevant.