Building living systems with hypermedia actors
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51703 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Message passingHypermediaLink (knot theory)Traverse (surveying)ImplementationLink (knot theory)Statement (computer science)Software developerTracing (software)Virtual machineMathematical modelMessage passingSlide ruleReading (process)Broadcasting (networking)Hypermedia19 (number)Quantum stateFinite-state machineNeuroinformatikCASE <Informatik>Observational studyComputer programmingGame theoryQuicksortEnterprise architectureMultiplication signWeb 2.0Physical systemDifferent (Kate Ryan album)HypertextMathematicsTerm (mathematics)Water vaporProcess (computing)Condition numberArithmetic meanExecution unitCartesian coordinate systemBuildingMultimediaImplementationSurfaceRootGroup actionTheoryReal numberBerners-Lee, TimMealy machinePointer (computer programming)Phase transitionFront and back endsMaizeLatent heatFinite set
06:26
Flash memoryMobile appClient (computing)Moment of inertiaServer (computing)AbstractionFunction (mathematics)outputCartesian coordinate systemDifferent (Kate Ryan album)Client (computing)Variety (linguistics)Slide ruleWeb browserData conversionQuantum stateGoodness of fitMultiplication signGame theoryMobile WebQuicksortGame controllerPoint (geometry)Process (computing)Boundary value problemTopological vector spaceAbstractionDesign by contractCategory of beingShape (magazine)Observational studyTheory of relativityMathematicsCASE <Informatik>2 (number)NumberServer (computing)Machine visionTouchscreenComputer configurationFundamental theorem of algebraWeb 2.0Parallel portComputer fileRight angleContext awarenessArchaeological field surveyComputer clusterCodeBookmark (World Wide Web)Spring (hydrology)outputEscape characterProfil (magazine)Active contour modelWhiteboardGraphics tabletPhysical systemComputer animation
13:14
Gamma functionZoom lensElement (mathematics)Plane (geometry)Message passingClient (computing)Finite-state machineEndliche ModelltheorieHypermediaMedical imagingGame theoryQuicksortComputer fileBitView (database)Software frameworkFerry CorstenHypermediaMessage passingDependent and independent variablesPoint (geometry)Quantum stateFile formatFinite-state machineOrder (biology)Server (computing)Multiplication signClient (computing)ExplosionLink (knot theory)Web 2.0Line (geometry)Instance (computer science)Dimensional analysis.NET FrameworkUniverse (mathematics)2 (number)MereologyMathematicsOffice suitePlanningHypercubeMultimediaElement (mathematics)Right angleArmVideo gameWeb crawlerFigurate numberCAN busGradientComputing platformSystem callVirtual machineBooby trapEndliche ModelltheorieService (economics)
21:23
Client (computing)Design by contractServer (computing)Link (knot theory)HypermediaGUI widgetGroup actionElectronic meeting systemGamma functionImplementationFunctional (mathematics)Category of beingGroup actionComputer fileCASE <Informatik>Uniform resource locatorRepresentation (politics)Message passingType theoryData structureMilitary baseFinite-state machineQuicksortGame theoryBitMereologyGame controllerHypermediaClient (computing)Form (programming)Right angleLatent heatOrder (biology)ImplementationServer (computing)Design by contractQuery languageMultiplication signFile formatWeb 2.0Quantum stateComputer configurationCartesian coordinate systemDependent and independent variablesLink (knot theory)EmailDomain nameTraffic reportingProfil (magazine)InformationArmGeneric programmingVirtual machineData mining
29:32
ImplementationMetreServer (computing)Hybrid computerMultiplication signJSONComputer animation
30:24
Category of beingMessage passingServer (computing)Group actionComputer configurationLink (knot theory)Game theoryComputer animation
31:16
Keyboard shortcutLabour Party (Malta)Landau theoryConvex hullMaxima and minimaControl flowBitHypermediaGame theoryTouchscreenMultiplication signProcess (computing)Dependent and independent variablesGroup actionCategory of beingQuicksortGoodness of fitFinite-state machineGame controllerComputer fileServer (computing)Graph coloringOffice suiteTwitterGreen's functionAbstractionClient (computing)EmailWeb 2.0Link (knot theory)HypercubeSource codePoint (geometry)InformationLevel (video gaming)CountingFile formatQuantum stateUniform resource locatorVotingUniform boundedness principleParameter (computer programming)Validity (statistics)Coma BerenicesCASE <Informatik>MultimediaForm (programming)Service (economics)MathematicsPosition operatorComputer animation
Transcript: English(auto-generated)
00:04
Okay, so now I can see my slides. You can see them also. I have a nice enterprise-y title which is called Building Living Systems with Hypermedia Actors. And I also have like the real title which is Agent vs Agent.
00:20
My name is Einar. I'm a backend developer at NRK which is the public broadcaster in Norway. So everybody in Norway knows what NRK is. If you're not from Norway, it's like the BBC of Norway, I guess. So, disclaimer first. This is what I like to call an idea talk. So it's not technology specific. It's technology agnostic.
00:45
There was some F-sharp and Suave I.O. involved in the preparation for this talk. So you might see some traces of that. But it's not a talk that's going to teach you F-sharp or Suave. And it's also not a talk that's going to require you to understand much of F-sharp or Suave.
01:04
So it's an idea talk. I'm going to talk about three ideas. Three old ideas. I think often the old ideas are the best ones. And when I say old, I mean that it's an idea that has roots that are older than myself.
01:20
So first one I'm going to talk about is Actors. Actors was sort of, the theory of Actors was formulated by Carl Hewitt in 1973 in a paper. And it's a mathematical theory that treats Actors as sort of the basic units of computation. And what does that mean?
01:41
It means that when you do some computation in your program, an Actor will do it. And these are the things that an Actor may do. So an Actor, when it receives a message, it can send messages to other Actors. It can create new Actors. And it might change his mind what it's going to do next time it gets a message.
02:02
So there might be a state change inside the Actor. So that's the first idea I want to talk about. Second idea I want to talk about is even older. It's finite state machines. And this is like seriously old. It was formulated in the 50s and by Moore and then by Mealy a year after.
02:25
So there's some subtle differences of what a Moore machine is and a Mealy machine is. We're not going to talk about that. So roughly a finite state machine is a mathematical, another mathematical model for computation which is based on states and transitions.
02:41
So a finite state machine has a finite set of possible states that the machine can be in. It has a current state and then there are some conditions for transitioning between the different states. And in this talk I'm going to try to sort of combine the idea of Actors and the idea of finite state machines. Because then everything will be nice.
03:03
And the final, the third idea is the idea of hypermedia. And that's an interesting one because it's simultaneously sort of the newest one and the oldest one. When we think of hypermedia today we mostly think of sort of Tim Berners-Lee style hypermedia,
03:20
World Wide Web style hypermedia. But the idea is older than that. So the term hypertext was coined by Ted Nelson in the 60s. And you can trace it even farther back to a paper by Vannevar Bush from 1945 called As We May Think. Which is a very interesting read. I recommend that you read that one.
03:44
So a hypermedia document, in this case a Tim Berners-Lee kind of hypermedia document, is simply a media document that contains meaningful links to other documents. And what does a meaningful link mean?
04:04
So what it means is that the link, it's not just a pointer to another document. It also describes the relationship between the document that you're sort of currently at and the other document that you're linking to. So it describes the relationship and what it means to traverse that link.
04:24
So those are the ideas. And to sort of make it more concrete, these are abstract ideas. I thought I'd use a sort of a case study to make it more concrete. So this is my case study. This is Spy vs. Spy, which is a cartoon that's been going for a long time.
04:46
Which I think is kind of amusing. You have the black agent and the white agent and they're trying to blow each other up basically. So that's the gist of it. So we're going to apply those ideas that I talked about.
05:01
To this case study of the agents. And what we're going to do with the agents? We're going to try to create or show you a conceptual design and play a hypermedia-based game using these agents. So agenda, I already talked about the ideas. I'd like to provide you with some background for why I think these ideas are interesting.
05:25
So it's not just a whimsical game. It has some sort of real value also. Some challenges that I meet in my day job. Then we're going to talk about the agent vs. agent game. The conceptual design of it. The application of the ideas that I mentioned to the game itself.
05:46
If we have time, we're going to take a brief look at the implementation. That's when you might see some F-sharp. And of course we have to play the game. Okay, so background first. So I told you I work for this thing called NRK.
06:03
Which is the Public Broadcaster. What I do on the team is I work on the program player team. And we provide an API for basically all the surfaces that if you're a customer, you might consume some TV or radio material that we have.
06:25
So basically, these days what we do is serve up this. This is the most popular TV show, at least online in Norway these days. We have an API. And we have a bunch of clients and different applications that talk to our API.
06:43
So all kinds of different devices in different sizes and with different capabilities. So we have the smart TVs of a lot of varieties of those. We have obviously the desktop with all kinds of OSs and strange browsers that I didn't even know existed. So there are people that will use particular Vietnamese browsers to talk to our API.
07:07
And they need a good experience, right? And of course there are the handheld devices. Kids in particular use iPad mostly when looking at our stuff. And a lot of use is also on mobile.
07:23
So the challenges that this brings. So we have these lots of clients and we're trying to build an API. And that API is not a static thing. It needs to evolve over time. We have new features that we'd like to implement. Things change and we need to grow with it.
07:42
So first challenge is a very real one. How do we avoid breaking the clients that work today when we're trying to do something? So we have sort of... I like to call it a semantic inertia between the client and the server or the API that we provide.
08:07
Which basically relates to the problem, what is the contract? What have we agreed upon? And is that contract implicit or explicit? So is it explicitly formulated what we have agreed upon between the client and the server?
08:21
And that means, it's an interesting question. What can the client trust to be there when we make a change in whatever way? How is that going to affect the client? Are things going to go away? Will the data still look the same? And sort of the converse of that is what can the server freely change, right?
08:42
So what can we change without fearing that we might break a client? And this is what I basically spend most of my time worrying about. Has the client made any assumptions about the data? And of course, they have. And I might not have sort of the perfect vision of what those assumptions might be.
09:05
A lot of web APIs serve up JSON. And JSON is sort of a weak contract in that it only gives you sort of a syntactic guarantee. It will be a well-formed JSON, but what properties or the shape of the data in that JSON document?
09:20
Well, you might have that documented somewhere else, hopefully. But JSON by itself gives very weak guarantees. So that's the first challenge. Second challenge is how do we build robust abstractions? So if we can sort of make believe that we have a sound design process that has given us some abstractions
09:41
that we would like to represent in our code, how can we make them robust? And by robust, I mean that they should be independent. They should have clear boundaries. They should be providing encapsulation, isolation from other sort of things. And they should be able to execute concurrently and in parallel.
10:04
That's the second one. Sort of related is, number three, how do we reason about the code? And in particular, at any given point in time in a running system, what is the state of the application? That's sort of a hard question to answer, yet it should be, yet it's kind of fundamental.
10:22
And it's a sad thing if we can't really answer that question. Related question to that is what is going to happen next in our application? So if I'm in some state, hopefully I know what that state is. I get some input. There's going to be a transition. I'm going to end up in a new state, and there might be some output.
10:41
And I'd like to sort of have a feeling of control of that process. I don't think it's much to ask, but it's, well, you know. So those are the challenges. Now let's see how they apply to this case study of the game.
11:04
So in designing this game, I took inspiration from an existing game. It came in 1984, and it was one of my favorites on the C64. Which is, yeah, looks like this. This, I believe, is the splash screen. Gameplay looks like this.
11:21
So there's a white agent and a black agent. And you can see that they have some options for, well, at least there's a bomb there. So they can put traps for each other. And sort of the goal of the game is to find the secret file, which is like a concrete folder.
11:40
Because this was like olden times. That's what spies did back then. They grabbed physical folders and ran away with them. And if you can sort of grab that file, then you can escape from this game world before your time runs out. But, okay, so that's all nice and good.
12:02
But I think, let's see if we can get this going. You're not seeing this, I think. So this would be much better. See? So here we are.
12:21
I'm going to try one player. And I think I'm the white guy. And basically the black guy is trying to kill me. But I still remember some of my skills. It's unclear who's going to win this one.
12:43
He's a coward. He's running away. Yeah, I won. So at this point I could start looking for the secret file and stuff. But I suppose we should be sort of proceeding.
13:03
Let's see where I was. If I can find my slides again. I'd like to continue. I think we're back. So I took some inspiration from this game. It's not going to be fully featured and it's not going to have graphics.
13:23
But still, I have a conceptual design. Please stop buzzing like that. So I made a game world consisting of some rooms. My imagination is not that great. These are basically the first names of rooms that I came up with and I just ran with them.
13:45
So the idea is that you're going to have multiple rooms and then you're going to have doors between the rooms. That would, for instance, let you go from the office to the laboratory. And most of the links or the doors are both ways.
14:01
But there's a one way from the teleport to the exit because there's a teleport in the teleport room. And then there's a dotted line from the exit to the plane because you do need to have the secret file in order to be able to take the plane out. So this is what the gameplay might look like. This is now the black agent. He's going to be dropped into the game world at some random place.
14:25
And then you need sort of the goal for the game which is to find the secret file which is also going to be dropped somewhere random. And then the black agent might navigate around like this. And when he comes to the exit he sort of finds out, oh I can take the plane out because I don't have the secret file.
14:44
So he starts looking for the secret file, goes back to the control room. And lo and behold there's the secret file. He grabs the file, goes to the teleport room, teleports to the exit and he's out. Of course that's too easy. Not much fun of a game.
15:03
So we need to add adversaries, other agents. At least one, the white agent. But you could generalize that. So you could have the pink agent and the green agent and the blue agent. So that's one dimension where my game is better than the old one because you can have as many agents as you like.
15:21
And you need strategic elements. So I'm not going to add all the traps but I'm going to have bombs. Because bombs are fundamental to the spy universe. So this is more of a realistic sort of still image of the game state at some point. So you can see there are two agents, the black one and the white one. The secret file is there. And there are two sort of trapped links.
15:43
So you can put a bomb on a link which means that if you go from one room to the other room you're going to trigger the bomb. And the agent has to disarm the bomb or explode. So that's the conceptual view.
16:01
Now let's try to apply the three ideas that I told you about. The actors and the finite state machines and the hypermedia bits. So first idea, actors. So to sort of implement this I'm going to use F-sharp agents for the actors. So technology agnostic. I could have used any other technology.
16:24
Of course other actor technology on the .NET platform or I could have used Elixir or whatever. I happen to use F-sharp agents. Because it's simple and I knew a little bit about it. So yeah.
16:40
And then the idea is to sort of all these concepts that I talked about I'm going to make everything an agent. So the rooms themselves are going to be agents. So you're going to send messages to the rooms. For instance, oh well I'm going to get back to that. But I could just say it. If you're planting a bomb that's going to be a message that you send to the room.
17:02
The secret file itself is going to be an agent. So you can send a pickup message for instance to the secret file. The getaway plane is going to be an agent. And the bombs are going to be agents. And of course finally the agents themselves are going to be agents.
17:25
And so just to remind you the thing with the actors is that when an actor receives a message it might send messages to other actors. It might create new actors. And it might figure out what it's going to do next time it gets a message. So some examples. When a client sends a pickup message to the secret file
17:42
the secret file is going to change its state to taken. And it's going to send a message back to the agent that they now have the file. Another example, when the client sends a plant bomb message to some room resource we're going to create a new bomb which is going to now be a new actor.
18:04
And the room is going to change state so that it's now booby trapped. And finally when a bomb explodes it's going to send an exploding bomb message to the agent which is very bad news for the agent. And the dropped message to the secret file.
18:23
And there's going to be other examples. These are just some of... Second idea, finite state machines. So I'm going to model now each agent. And this is now sort of actor agent not the spy agent. It's going to be modeled as the finite state machine.
18:40
So here's an agent. It can be in three possible states. It's going to start out alive. If it picks up the secret file it's going to be alive and have the secret file. And then in either one of those states if it gets an exploding bomb notification it's going to enter the dead state. And what's going to happen in the dead state
19:00
is that you're immediately going to be resurrected back to the alive state. But as you can see there's no way back to sort of dead and then alive with file. Which means that if you have the file you're going to lose it. Here's a bomb. So the bomb is going to start out in an armed state.
19:22
If some poor agent enters the room it's going to trigger the bomb. And then two things might happen. The agent might try to cut a wire because that's what you do with bombs. It has wires and you can cut them. And this is sort of a boring part of the game. It's not very tactical.
19:42
You should always cut the red wire because then it's going to be disarmed. If you cut the blue wire it's going to explode so that would be stupid. I will accept pull requests that allow the agent to specify which wire you should disarm. We'll get to that.
20:01
And finally the secret file is in one of two possible states. It's either going to be available in some room. Or it's going to be taken by some agent. Okay, so third idea is hypermedia. Hypermedia and HTTP basically.
20:20
So this is the basic situation. We have a server. The server is written in Suave. So F sharp then. And I had to use some F sharp web framework because I was going to use the F sharp agents. And then there's going to be a client. And the client is written in Node. And there are historical reasons for that.
20:43
I'll get back to it. But basically you're going to send off an HTTP request. And you're going to get some HTTP response back. And that response is going to be in a format called siren. So the idea is to expose each entity in the game as a resource.
21:01
And I know I said that everything in the game was going to be an agent. Really everything in the game is going to be a resource. Which is basically just an URL and an agent. So it gives you a way to identify each agent. And I'm going to use siren as the hypermedia format. So siren is a format that Kevin Schweiber made.
21:24
You can read the specification up here at GitHub. And this is the MIME type. So you can see it's JSON based. So it's syntactically valid JSON. But it has some more structure and some more definitions to it. Which means it's going to provide the client with more guarantees.
21:43
About things that are going to be there. And how it's going to look. So it's going to be a somewhat richer client server contract. It's still going to be fairly generic, right? Because it's not a domain specific MIME format. But still. So the client can trust some properties to be there. And those properties are going to be enough to drive the application or the game rather.
22:04
So those things that I can trust to be there. Is that the document is going to contain links. Which is where I'm going to find my hypermedia links. And I'm going to use those links to navigate the game. I can also trust something called actions to be there.
22:22
And that's for making hypermedia controls. And that's what you use to make the state transitions in the game. And hypermedia control is basically like an HTML form. It provides you an opportunity to provide some extra data with the HTTP request.
22:40
So basically you make a post or a put or a delete on the resource. You specify that with actions. So examples of actions are going to be plant a bomb. Disarm a bomb. Or pick up the secret file. Here's what the plant bomb action looks like. So it's going to have a name.
23:01
And again I can trust these things to be there because it's in the siren specification. It's going to have a name, a title, an HTTP method. In this case it's going to be post. And what this really says is at this room, called some room in this case, I'm going to send the bomb referrer which is going to specify the room I'm coming from.
23:22
So this is sort of the room you have to come from in order to trigger the bomb. Because each room might have multiple entrances. So it's just from the one entrance that's going to trigger the bomb. And in a sort of HTTP world, here's a recap of the bomb's finite state machine.
23:45
So it can either be armed. And if it's armed, when you go to look at it, you're going to get a 200 OK with the representation of the bomb. But if some agent goes to the room where the referrer header happens to match the referrer header for the bomb,
24:02
then you're going to be redirected from the room you wanted to go to and to look at the bomb instead. And you're also going to trigger the bomb which means that when you're redirected over here, you're going to get a siren representation of the bomb and no links to go anywhere. So you're basically stuck with the bomb, right?
24:21
You have no further options except one which is the action to try to disarm the bomb. And then you can issue this post request specifying a wire color. So you should choose the red one. If you choose the blue one, you're basically going to have another redirect which takes you to a random room and indicates that you died.
24:48
And then I actually simplified the finite state machine a little bit because it doesn't really matter when the bomb has gone off or it's been disarmed. It's gone. And if you try to sort of read a bomb that's gone, you're going to get a 410 bomb.
25:04
And the final part that you can trust to be there in a siren document is going to be a property. You can put whatever you like in there. That's basically just a JSON blob, right? And I use properties for telling a story. So just read this and see if you can make anything out of it.
25:21
I'm not going to parse it or trust anything particular to be there. So here's an example of some properties. This is what happens when you try to look at the black agent resource. And this is actually the black agent looking at the black agent. Here is the black agent looking at the white agent.
25:43
So it's less flattering in that case. Yeah. And then I was going to, I think, have a little look at the implementation.
26:01
I think we're fairly good on time, so you can have a slight look at the implementation at least. Let's see, where should I put this? Over here. So as you can see, this is now, you can see it. I cannot see it very well, but that's fine. I can see it over here.
26:21
So which resource is this? This is a secret file resource. I just wanted to sort of try to explain at least what it means when I say that this is agent-based or actor-based. So it means each thing is going to be a resource like this.
26:43
It's going to accept a message. So the kinds of messages you can send to the secret file is either a location query to sort of ask where the secret file is. You can send it a notification that it's been dropped at some location.
27:01
That's going to update the location for the secret file. And then you can send it sort of a web message. And the web message means basically just that it originated with the client and not sort of with the game internals. These other are game internal messages. And I said I think that, well, here's a representation of the secret file, not very interesting.
27:25
This is where you define the actor or the agent. You just start it with some method here. And this is now implemented using a mutually recursive function in the F-sharp.
27:40
So you have the available over here, which is now going to listen for a message. And if it gets a message, then it's going to do one thing if it gets a location query. And another thing if it's dropped. And a final thing if it's a web message. I suppose the more interesting thing is one of the things that you might do is that you pick up the secret file.
28:08
And that's going to be, let's see, yeah, over here. So if you make a post request to the secret file, that means you're picking it up. And then you're going to change state from available to taken.
28:23
And taken is the second part of the sort of the mutually recursive function here. So basically if this happens, I'm going to start execute the taken function now, which is going to call itself recursively all the way until it gets a dropped message,
28:43
in which case it will be available again. And this means that if I'm in the taken state, I have a lot simpler things to sort of worry about than if I am in the available state. In particular, there is no meaningful thing you can do with it with a web message,
29:05
because it's taken, so you're not going to find it, right? Whereas if it's available, I do have to sort of make a more interesting response to the various requests that I might make. And I think that's enough implementation because I do want to have time to play the game also.
29:25
Right. Let's have a look at that. So, begone Visual Studio, actually begone this one also. And let's see if I can somehow manage to get a hold of this.
29:48
So, I have here, I'm going to start up, this is wrong. Let's see, I'm in the wrong place.
30:04
So, I'm going to start up the hyper-agent server, which is now the Suave server. I could go, I think I have enough time for that, just to show you. I could start Postman or something like that, or obviously I could just curl or something.
30:25
And I could make, let's see, I could make a GET request. This is probably too small to see, but this is, I'm going to hit the server now. And when I do that, when I send the GET message, I'm going to get a siren document back.
30:41
Hopefully you can see this. This is what I said was going to be guaranteed. It's going to be an action there. It's going to be some links and some properties. But it's cumbersome to play a game like this in Postman. So, I have a better option, I'm happy to say.
31:01
So, what I did, let's see. Can you see this now? It doesn't look very nice, but that's better, I suppose.
31:21
Like this. And maybe I should just go and fetch the server also, because you're seeing that now. Good.
31:40
Right, so it said there was sort of historical reasons for having a client written in Node. The historical reason is that last year I did another talk at NDC which featured another hypermedia game called Hyper Wizard. And I wrote a client for that. The good thing is that since I used the same hypermedia format, which is siren, I can just reuse that client.
32:07
Because the client doesn't make any other assumption than that it's actually a valid siren document. So, any old game that will use siren can actually be used with this client.
32:22
So, let's see. Can I do something like this? Node run. Not like this. Like this. And I can just sort of like point to where the game is.
32:42
Which is over here. And I'm going to dump a little bit of data about the request and response. And I can sort of read my siren document in here. But I'm not going to do that because, as I said, I can trust this information to be there.
33:01
So, I can make like more higher level abstractions to work with this thing. So, the game look is going to dump out the properties which I said was used to tell a story. So, it says now welcome to the hyper agent game. This is agent versus agent. And I can even do something like game do which is going to look up an
33:25
action in the siren document and sort of perform that action to make an HTTP request. So, I can do now start agent which is going to be the name of the action. And I'm going to need a comma there.
33:41
And this is going to be the black agent. And when I start that, I'm going to get a 302 found which will redirect me to some random place in the game world. And because it's HTTP, when I get a location header, I can choose to follow it using the follow command. Which is going to look up the location header and just go wherever.
34:03
So, now I'm in some other room. And now it seems I'm in the teleportation room which is fine. Let's do the same thing for this guy. So, game to local host.
34:28
And I can do start agent. Let's see. And this is going to be now the white agent.
34:41
And I'm going to go wherever I'm redirected to. Okay, so I'm in the office and there are screens on the walls and there are charts and burn downs. It seems Jira is in there. Okay, that's fine.
35:02
But I'm going to cheat a little bit because over here on the server side, it says that the secret file can be found in the control room. Which is useful information when you're trying to demo the game. So, let's try to make one of the agents go over there.
35:31
Okay, here I am. I'm going to try to navigate over there. It's just the control room, right? So, to follow the links, I need to use a zero-based index.
35:44
And it seems to me that this is the third one counting from zero. And if you can read this, it says that you're in a room full of blah, blah, blah. But you found the secret file and you can grab it. So, this is because the secret file happens to be in that room. I'm now going to have a link to it.
36:06
And you can see, hopefully, down there that there's going to be a secret file link and I can look at the link. But I'm not quite sure which link it is. So, it's zero, one, two, three, four, five. It's the fifth link.
36:21
The sixth, rather. So, let's have a look at it. And I can take the file. In this case, I'm going to affect the state change, but I'm not going to send any data because I don't need it. And when I do that, I'm going to be redirected back to the room.
36:44
I think we're, unfortunately, running out of time. So, let's see if I can... I'd like to try to plant a bomb anyways. I'm going to do plant bomb zero.
37:08
And that's going to put a bomb in the teleport room so that if you're approaching from the laboratory, you're going to sort of trigger the bomb. Now, I've got a 201 created and I can have a look at my bomb.
37:26
And it says, this is your deviously set up bomb, which is great. I don't know if I have the time, but I'll see.
37:40
Where did I set it up? Yeah, so there is a bomb. Yeah, laboratory to the teleport room. Let's see if I can just get this guy to the laboratory.
38:02
And I can fairly easily. This is the laboratory. I should now have a link to the teleport place, which is going to be the second one.
38:21
And as you can see, I was now redirected to the bomb, which is bad news. Now I have this diehard style bomb on my hands and I need to cut the wire.
38:41
And let's see if I screw up. I was redirected. And it's going to say over here that agent white blew up and it dropped the secret file and so on and so forth. We're not going to have time to complete the game because we're out of time.
39:01
But I'm happy to answer any questions you might have. Also, if you're interested, you can see the source code over here. You can play the game if you want to see it to the finish. Yeah, let's play.
39:21
I also promised to mention PubConf tomorrow evening. There's going to be lots of awesome speakers and I'm also going to be there, unfortunately. And you should remember to vote. And just sort of the final thing for me is reminded that this is the color green.
39:41
Questions? How I would use this in my job. So this is sort of a long stretch from my job in some sense. But sort of the ideas are equally valid. So in particular, it's easier to get started with the agents and the finite state machines than with the hypermedia stuff in some sense.
40:07
Because we have already committed to a format that our clients are using. But we have some hypermedia capabilities in there. So we're not in a hopeless position like that.
40:23
So I would say even though this is a whimsical thing, right? This is not very serious. I think you can apply these ideas to implement something, anything that talks to the web basically. If we're using this in the backend, no, we're not.
40:51
But we might at some point. Because I really believe in the idea of using actors like that.
41:00
Yeah, the source is on GitHub. I'll put a tweet out there with a link. Any more questions? Then I think we're done. Thank you.