List of possible rooms instead of possible directions - inform7

I try to list possible directions to which the user might go. But for the tone of the story it would be nicer not to say "you can go north and south" but "you can go to the bathroom and the kitchen".
I found hat code but it only shows the directions.
Definition: a direction (called thataway) is viable if the room
thataway from the location is a room.
After looking:
say "you can go [list of viable directions]."
Any idea?

Absolutely not the nicest way of doing it, but I had a similar problem and I ended up iterating over the list of directions you created and added each of the rooms to a list of rooms, one could then say:
nLooking is a number that varies. nLooking is 0.
After looking:
now nLooking is 1;
let accessibleRooms be a list of rooms;
let pDirections be list of viable directions;
repeat with dirToLookAt running through pDirections:
try silently going dirToLookAt;
if rule succeeded:
add the location of the player to accessibleRooms;
try silently going the opposite of dirToLookAt;
now nLooking is 0;
say "You can go to [accessibleRooms].".
Before going through a locked door when nLooking is 1:
stop the action.
I used nLooking to block the output
(first opening door)
It seems to be locked.
when looking for the rooms one could access.
if rule succeeded checks if the palyer was able to go to the room. If that is the case the room the player walked in is added to the list and the player is moved back to where he came from.
This works only if one does not make a chaotic map where moving in the opposite direction of where one came from does not mean one lands in the same room. One could possibly just place the player back in the room he came from...
Late answer I know but maybe it helps people with the same problem :)

Related

Inform7 camera with two different film rolls

Hey guys i try to implement a camera:
A photograph is a kind of thing. 36 photographs are in the film roll.
Appearance relates one thing to various photographs. The verb to be shown by means the appearance relation.
The description of a photograph is usually "It shows [a random thing which is shown by the item described]."
Understand "of [something related by reversed appearance]" as a photograph.
This allows the player to refer to any photograph by its subject: useful if we have a large number of them.
Now we create an action to let the player use the camera and generate these photograph objects:
The player carries a cheap instant camera.
Understand "photograph [something] with [camera]" as photographing. Understand "photograph [something] with [something preferably held]" as photographing. Photographing is an action applying to one visible thing and one carried thing, requiring light.
The photographing action has an object called the selected film.
Setting action variables for photographing:
let N be a random photograph in the film roll;
now the selected film is N.
Check photographing:
if the second noun is not the camera, say "You need a camera for that purpose." instead.
Check photographing:
if the noun is the camera, say "Sadly impossible." instead.
Check photographing:
if the selected film is nothing, say "You're out of film." instead.
Carry out photographing:
now the noun is shown by the selected film;
move the selected film to the player.
Report photographing:
say "Your camera instantly spits out [a selected film]."
Like in Example 322:
http://inform7.com/book/RB_9_12.html
In the example there is only one camera with one film roll.
but i want two different cameras and both cameras should have a individual film roll.
So i can take pictures with camera#1 saved to filmroll#1 and i can take pictures with camera#2 which are saved to "filmroll#2".
Can somebody help me?
I think you could do this with aliases. It's been a while since I coded in Inform 7, but I believe the syntax is something like:
The player carries a first camera.
The printed name of first camera is "cheap instant camera".
There is a second camera in the lab.
The printed name of second camera is "cheap instant camera".
You would have two cameras that display as the same thing, but are distinct. And you could do the same thing with the rolls of film. You might still have issues knowing which camera is which, but hopefully this gets you on the right track.

Reassign user story during sprint?

If a story is in progress and then swim lanes are code review and QA-ready, how should the assignment of stories work? Should a story remain assigned to the developer? And should the code review and QA tasks be created as sub-tasks in it? Or should the story be re-assigned when it is moved to code review by the developer, and when code review is done, it is moved to QA lane by the reviewer and re-assigned to QA by the reviewer. It seems anti-pattern to re-assign tickets from in-progress to future states. It looks okay to re-assign tickets before it was brought in the sprint but not after.
Scrum does not have anything to say about how the work is done nor how a board is managed. However, many team's look at Kanban's "pull" approaches to answer this. In that case, work is never assigned or given, it is only claimed/taken on. Therefor, work would be moved to "Code Review" by the reviewer when they began the work. Similarly, the work would be moved to QA by the tester when they started. "Ready" columns are a bit of a misnomer as they are not states. Rather, they are statuses of the previous state. If your order is Code Review - QA Ready - QA, then in fact, QA ready is a possible designation on work in Code Review. This may seem minor, but it is very important to prevent pile-ups in your process where work stalls without owners.
There is no single answer, but one way of doing it is to think of of a User Story as a container of tasks where each task is a small technical deliverable of any kind. With this mindset you can effectivly stop thinking of who the assignee is as each developer will have its small contribution towards the goal.
One of the problems with task re-assignment is that at one point you can loose traceability of who has done what and productivity on per developer basis. So in this sense having each teammember doing its own tasks and delivering towards the completion of a user story can solve this.
Then you can assign the User Story to the product owner, or you can assign it to a developer that kind of holds ownership towards its delivery to test when the tester will take over. But the user story when assigned to a developer does not mean that he owns the User Story, it just means that it is his responsibility to ensure hand over to test nothing more nothing less.
When a tester encounters a bug then you create a bug attached to the User story.
Not recommended. It's feasible tho. You have to assess your current work situation. If the user story is something that can make a whole difference, then it would be better to just stop the sprint, reassess your situation and make the necessary changes - then continue. Either way, when you are adding a new user story to the backlog, deadlines can be hardly met.
We are using a little bit different approach. Like we have following columns on Jira Board.
To-do
In_progress
Ready for Review
Ready for QA
In-Testing
Rework/Rejected
Done
A developer pick a task from to-do and assign it to him self and keep it in-progress. Once he is done he moved it to Ready for Review and keep it un assign. Someone will pick it and assign it to himself and review it. After reviewing that person will move the case to ready for QA without assigning it to anyone. Whoever is free or plaining to work on case will assign that case to himself and when he starts working on the case, he will move it to in-testing. As a result of testing the case can go in rework/rejected or in Done. If it moved to Rework/Rejected he will assign it to original person who initially worked on it. And that person when rework on it, will move the case to in-progress again.

Efficiently matchmaking players in firestore

I'm working on a game that requires player matchmaking i.e. putting 2 players into 1 battle room.
While there are few players online in the game this is not an issue, however if we assume scenario of 1,000,000 players online at a time, who are all trying to matchmake, then picture becomes more complex.
Assuming following flow
My first instinct was to
When player clicks "play" call cloud function that checks if "open" battle room exists.
If there is one open, place player in it and start the battle or set battle to be active.
In case there wasn't an open room, we create new one and wait for another player to join.
However I see a lot of issues here given that we have 1,000,000 players who would be performing this action. For example, while performing step 2 and setting room to be "active" we might be pushing more players into it during the time those requests resolve?
If you want to deal with concurrency, I think you should use transactions to perform this action (adding a player to a room). That way, you ensure to check if the room is still open before adding a player in it. If 2 players start a matchmaking at the same time and find the same room, then only one single player will be added to that room
https://firebase.google.com/docs/firestore/manage-data/transactions
As far as I understand I can suggest One way to make it easier is have state of a user itself instead of calling cloud function to create room
Make user state like active, online, offline. When a user press play set its state active.
Call a query to fetch user where state == active , limit to 5(example).
start a transaction to match it with first user if succeed change status to playing for both else if failed ( you got matched to someone else or player you were trying with got matched to someone) check next player.
If during this you should be always observing your own state if it changes to playing because someone else matched to you then straight head to game.

Biped arduino robot that can navigate in the house

I will create a biped robot soon, i will add speech recognition and stuff to it.
I want it to find in my house. Is it possible to create like a map or something where i mark the
places in the house with numbers or something and then make the arduino robot
read it, so ex. when i say: "Go to your room" (the arduinos room = my room) it will go
to it's room (my room) automaticly.
UPDATE:
Is there a gps module or something that i can modify like i want so my robot
can find in my house? So i can mark where it can go and where the rooms are
and so i can program it to go to ex. my room when i say so, and it will find to my room.
There are many different ways of attacking this scenario. If you are talking a map it might be worth generating a measurement system whereby you can use an array of units to allow your robot to navigate the house. I think you will run into issues over time with unexpected variance so the large part if navigation code would have to tackle calibrating against a known map.
The advantage of using this method is that you could have it "learn" a new space by mapping a new array against your units

Right way to accommodate an HTTP GET that could "skip" to a POST?

Let's say you have a HTTP GET request which could be skipped in some circumstances. For example, imagine you have:
GET /orders/new, which lets you pick what flavor of ice cream you want
POST /orders, which makes a new ice cream order
Normally, GET /orders/new shows you the list of flavors and a Submit button. But if there's only one flavor available today, you'd like to just POST the order to avoid having the user make a useless decision. (We'll imagine this is a universe in which everyone likes all flavors equally and so will always be happy with your dictatorial ice cream choice.)
It doesn't seem correct to do something like "redirect to POST" from a GET request, since that wouldn't be idempotent. So then what's the right way to do this:
if there's more than one flavor: let the user pick the flavor(s) they want for their order
if there's only one flavor: pick the only flavor for their order and immediately make the order
either way, wind up with a newly POSTed order
It's a GET, it should never result in a POST. Period. If you want to avoid the choice, avoid doing the GET entirely somewhere in the flow before the GET /orders/new. Maybe I only want to see the flavors, but not actually proceed with an order.

Resources