I want to create a FSM diagram and wanted to use plantuml for that. I stuck with backward arrows
There is a way to create backward arrows but it looks overcomplicated and too limited for such a simple task
#startuml
:start;
repeat :Ask to enter login;
repeat while(Is name valid?) is (No) not (Yes)
:play game;
#enduml
which gives this
but when you want to implement a little bit more complex logic like:
Ask to enter name
Ask to enter password
On the third failed attempt go back to the (1)
it looks like it's just not possible with plantuml
I don't know if it called State diagram but I took a look on all types of diagrams plantuml supports and it seems to be the fittest one
I would say that an activity diagram works best.
What you described is easy to explain, but complex to display in correct UML, I don't think that's specific to plantuml. Here's how I would express what you said:
#startuml
start
while (App) is (running)
:enter username;
repeat
:enter password;
if (Password correct?) then (yes)
:Play game;
stop
endif
repeat while (Third attempt?) is (no) not (yes)
endwhile (exit)
stop
#enduml
As Jeffrey pointed out, you are more likely thinking in terms of activity diagram, your nodes being the actions that happen and not the states.
If you want a state diagram, you need to shift your mind to the background of your currently identified actions. So in the simplest means, there are two main states in your system:
Let's zoom into the first state, which appears to be more complex and deserve some substates. You have identified an Enter a name action while in the game configuration state. Until this action is completed, the name is not known. Once it is completed, the name will be known, but a validity check needs to be performed. You could express this with the following states:
You'll see that when entering the substate No valid name known, the first things that happens is to ask the name. And once everything is fine, you've finished the sub-state machine and can continue to the new states.
The plantuml code is:
#startuml
state Configuring {
state NameNotKnown as "No valid name known":entry / Ask name
state NameKnown as "Name knwon"
[*] --> NameNotKnown
NameNotKnown --> NameKnown : Name entered
NameKnown --> [*] : Name is valid
NameKnown --> NameNotKnown: Name is invalid
}
[*] --> Configuring
Configuring --> Playing : Launch game
Playing --> [*] : Game over
#enduml
It's worth to mention that you could fine tune this diagram, using entry, exit and do behaviors in each simple state. Moreover, you could simplify my example using guarded transitions, and even behaviours that are expressed at transition level.
Related
I am developing a web distributed application to let any user to play the Klondike (solitaire) game. I want to develop a API REST but I am not sure how the resources URL should look like.
At the server, I have the 'game', 'stock', 'waste', 'tableau', 'foundation' classes among others. The game class has the method moveFromStockToWaste, moveFromTableauToTableu... which implements the movements of the game.
What I have read about REST API is that the resources URL should look like a hierarchy of nouns while the operations (verbs) over this nouns are the HTTP methods (GET, PUT, POST, PATCH).
I am not sure if the way to move a card from stock to waste via API REST should look like this though moveFromTableauToTableau resource is a verb and not a noun:
UPDATE /player/{playerId}/game/{gameId}/moveFromTableauToTableau
Other way I have though is having this tableau piles cards resources:
URL: /player/{playerId}/game/{gameId}/TableauPile/1/
than in turn have resources like the number of not upturned cards and the upturned cards (all the information needed about the tableaus).
Then update this tableau pile resource by deleting the last card:
DELETE /player/{playerId}/game/{gameId}/TableauPile/1/upTurnedCard/3
And then put the card deleted in the target passing the new card suit and value:
POST /player/{playerId}/game/{gameId}/TableauPile/3/upTurnedCard
But this way the REST API would let to move a card from the tableau to the waste and this is not a valid movement.
I always think designing a REST API as a pretty uneasy task.
The second approach seems cleaner in naming convention terms, but I think you should never compromise the integrity of your targeted system to be compliant with such things. As you allow making one atomic operation in two http calls, it is in fact no longer atomic and you expose your system to unpredictable state in case of network failure or if any call fail for some reason. Avoid this kind of problem must be the top priority.
One idea could be thinking moves in terms of moves collection. So for a game you have a moves ressources. And then you can refine the move nature with some additional request parameters such like
POST/players/{playerId}/games/{gameId}/moves?type=TABLEAU_TO_TABLEAU
Body:
{
"src": "stock",
"dest": "waste"
}
This way you should have enough flexibilty to handle the different types of move.
Besides, may I suggest you to use plural form for resource naming :
player -> players
game -> games
so
GET /players naturally means give me all values of the player resource
GET /players/1 means give me the player of the players resource with the restriction playerId=1
I am developing a web distributed application to let any user to play the Klondike (solitaire) game. I want to develop a API REST but I am not sure how the resources URL should look like.
Oracle: how would you implement this as a website?
At the server, I have the 'game', 'stock', 'waste', 'tableau', 'foundation' classes among others. The game class has the method moveFromStockToWaste, moveFromTableauToTableu... which implements the movements of the game.
One important thing to realize is that the classes in your implementation don't matter; REST is about manipulating documents, the changes that happen to the game are side effects of manipulating the "documents".
In other words, the REST API is a mask that your game wears so that it looks like a web site.
See Jim Webber's talk DDD In the Large.
Klondike is effectively a state machine; any given tableau has some limited number of legal moves to make, each of which takes you to a new position.
So one way you might model the API is a representation of the tableau plus affordances (links) for each move, and the game progresses from one state to the next as you follow the links that describe a possible legal move.
There are "only" 8*10^67 or so deals to worry about, and for each of them you effectively have a graph of all of the reachable positions, and order them by traversal order, and then just link them all together.
/76543210987654321098765432109876543210987654321098765432109876543210/0
/76543210987654321098765432109876543210987654321098765432109876543210/1
/76543210987654321098765432109876543210987654321098765432109876543210/2
/76543210987654321098765432109876543210987654321098765432109876543210/3
And so on.
It's not an impossible arrangement, although it may be impractical, and since the URL describes the entire state of the game, the player has access to hidden state.
I'd suggest first trying this approach on something less complicated, like tic-tac-toe.
Hiding the state is relatively straight forward, because the mapping of the current game to a specific seed can be done on the server. That is, you send a POST to the start game end point, and that generates some random identifier, and maps the random identifier to a seed position, and off you go.
But a potential problem in this design is that HTTP is a stateless protocol; there's no way for the server to "know", when the player requests GET /games/000/152, that the client was previously in a position that could legally move to position 152. You can make the URI hard to guess, but that's about it.
What you likely want is the ability to ensure that the moves made by the player are legal, which means that the server needs to be tracking the current state of the game, and the player gets a view of the open information only.
The simplest HTML model of this would have the representation of the game show the information that the player is allowed, and a form with a list of the legal moves. The player selects one move and submits the form, which is a POST back to the game resource (directly back to the same resource, because we want the cache invalidation properties). Your implementation could then check that the received move is legal, refresh its own local state, and send an appropriate response.
That's the basic pattern we should be considering; GET the game, then send an unsafe request to modify the server's copy of the game.
The basic plan isn't all that different if you want to use a remote authoring approach. GET fetches a representation of the revealed information, the client makes legal edits to that representation, and PUTs the new representation to the same URL. The server verifies that the new position is reachable from the old position, and accepts the move, using its own copy of the hidden information to update the representation of the player's view.
(Pay careful attention to the meta data used in the response to PUT; the server is supposed to be communicating carefully whether the new representation is adopted as is, or if the server has transformed the proposed representation to make it consistent with the server's constraints).
You could, of course, also use PATCH to communicate the changes made to the representation by the client.
If messages were lost, or duplicated, the client's view and the server's view might not be aligned. So you may want to have your representation of the game include a clock/timer/turn number, so that the server can be certain that the players move is intended for the current state of the game.
EDIT As Roman notes, HTTP already has built into it the concept of validators, which allow you to lift data from your domain specific clock into the headers, so that generic components can understand and act appropriately to conditional requests
Another way of thinking about the game is to consider event sourcing; the client and the server are taking turns appending entries to a log, and the view of the game itself is computed by applying the events in the log. The client's moves would be limited to the set that manipulate the open information, the server's moves would reveal previously hidden information.
So you could use Atom Pub, or something very similar to it, to write new entries into the log. This in effect gives you two different representations of the game - the view, that shows you what you see when you look at the tableau, and the feed, which shows you the moves made to reach that point.
(If you squint, you'll see that this is really just a variation on "let the client pick a legal move".)
You could, I suppose, treat each of the elements in your domain model as a resource, and try to design an API to allow the client to manipulate those directly, but it isn't at all clear to me what benefit you get from that.
I would like to understand how to create a way to redirect the conversation to the anything_else node when confidence is lower then a established limit.
I am creating a node triggered by intents[0].confidence < 0.5 that jumps to the anything_else answer.
So if I enter a value "huaiuhsuskunwku" it recognizes as the intent #greetings and do redirect its node.
Any idea why it is recognizing it as a greeting in the first place?
And how can I configure it properly?
Two things here:
1a. Before the newest API was released, which is still beta, we used what is called a relational classifier. Meaning it checks all the classes available, and will do its best to fit it into the most similar one. So I would assume you have relatively few intents, and each intent has only a handful of samples. There are too many features in the algorithm to point to one specifically, but its finding some features that make it think it is part of that class.
1b. You should create a class for off-topic that just includes a bunch of things you dont want to respond to. This essentially helps balance out the existing classes so it knows it is NOT your main classes. You wont need any dialog nodes for this, the off-topic class simply helps it fall to anything else as you want
2. Just this week we have released an update to the API. This changes it to an absolute classifier so scoring is handled differently now. Each class is evaluated on its own. We have also included a built in off-topic handler to help weed out gibberish like this. See the docs here:
https://www.ibm.com/watson/developercloud/doc/conversation/release-notes.html
Watson follows Top to Bottom Flow. So there may be 2 cases.
Your Greeting node is above to the one which you created for routing to Anything else and that your query's (huaiuhsuskunwku) confidence was >=0.20 for #greeting intent. In this case just move your greetings dialog below to the node you created.
If your greeting dialog is below to the node you created for routing to Anything else dialog. The given condition(confidence < 0.5) failed and thus skipped that dialog. In this case, check the confidence of that query in 'Try it' window and adjust confidence value in dialog accordingly.
I have seen some references to the Auto-learn function of Watson Dialog but I can't find coverage in any of the documentation. Can you point me to a source of information on how best to use Auto-Learn?
Thank you for your feedback, we are always working to improve our documentation.
For your immediate benefit, auto-learn is a bit of a misleading name for a feature t, but the name has stuck.
Autolearn has become the "did you mean..." with four bullet points that shows when a user sends an input that has no direct matches.
A little history...at one time, we thought that if a user typed something, saw the did you mean... and clicked a link, their intial input must have meant the same thing as the one they clicked, the system should automatically remember that.
Imagine this:
"What are your credit card fees?"
Did you mean... 1. apply for a credit card 2. cancel a credit card 3. pay your bill
click apply for a credit card
The user was simply interested in that, but obviously the two DO NOT have the same meaning. So we realized thats a bad idea, the system will learn incorrectly. However, we still call it auto learn.
So I'm working on something that's going to be a rather large undertaking. I've figured out how to do a "bare-bones" kind of dice hud that just rolls a basic 2-20. However now I need to go to the next step.
I want to make a roleplaying system dice hud for my sim. For this I want it so that when you click the HUD you get a menu, that lists all the skills in my system. When you click the skill it refrences a notecard in the Hud to do some minor math before displaying the result: IE.
There's a normal 2d6, 2d8, 2d10, 2d12, 2d16, 2d20 ((Whatever basic configuration that always rolls a standard die))
Though I want it to look into a note card to add in a character's "STATS" and "SKILL LEVEL"
So say they want to hit someone with a sword?
I want the Hud to generate a random value between 2 and 12, then add in the character's Strength, speed, perception stats as well as their sword skill level.
If I could see the basics of HOW to start this I can then move forward from there.
You cannot write into a note card using a LSL (or other) script.
If you want to roll a dice, simply use llRound( llFrand ); or integer x = (integer)llFrand(19)+1;
You could use a webserver to save information like that. Just google free web space, you're gonna find a lot. SL's HTTP communication is, let's say, ok.
This is kind of a big project. If you don't know where/how to start you should hire a professional. Just look for groups in-world. You're going to find a lot of people willing to help you :)
In LSL you cannot write in a notecard, however if you try OpenSim you can use that function:
osMakeNotecard(string notecardName, list contents);
But that is only available in OpenSim, see osMakeNotecard.
I'm creating a cricket manager stats game. I need to create a ball-by-ball simulation of the game. The game/ball outcome will be influenced by player stats and other external factors like weather or chosen tactics.
I've been reading around that most of the games can be implemented as a state machine, which sounds appealing to me, but because I'm a newbie at cricket I'm failing to envision this game as a state machine.
Should the Ball be a state machine or the match or the player or all 3. I'm also not sure how will i orchestrate this state machines (through events).
I'm also having hard time identifying the States and transitions. Any help would be greatly appreciated.
So here's what I understand from your question - Your cricket manager game will simulate a match ball by ball depending on player stats (bowler's skill/experience, batsman's skill/exp, fielding/wicketkeeping stats, so on...) and other related variables. From my understanding this will be more of an algorithmic engine rather than a visual representation of a cricket game.
Now answering your question, first of all, I don't believe you're looking at FSMs the right way. An FSM is a piece of code designed such that at any point in it's lifetime, it is in one of many possible states of execution. Each state can and usually has (that's the point of it) a different update routine. Also, each state can transition to another state upon predefined triggers/events. What you need to understand is that states implement different behaviour for the same entity.
Now, "most of the games can be implemented as a state machine" - Not "a" state machine but rather a whole nest of state machines. Several manager classes in a game, the renderer, gameplay objects, menu systems, more or less everything works off a state machine of its own. Imagine a game character, say a boxer, for the purpose of this example. Some states you'll find in the 'CBoxer'(?) class will be 'Blocking', 'TakingHit', 'Dodge', RightUpper', 'LeftHook' and so on.
Keep in mind though, that FSMs are more of a design construct - a way to envision the solution to the problem at hand. You don't HAVE to necessarily use them. You could make a complete game without a state machine(I think :) ). But FSMs make your code design really intuitive and straightforward, and it's frankly difficult to not find one in any decent sized project.
I suggest you take a look at some code samples of FSMs at work. Once you get the idea behind it, you'll find yourself using them everywhere :)
As a first step you should go through the rules of cricket and your model for the ball outcome to summarise how previous balls affect a given ball.
Then identify what you need to keep track of, and whether it is convenient to use a state machine to represent it. For example, statistics are usually not very convenient to keep track of as FSMs.
With that information in mind, you should be able to build a model. Information you need to keep track of might be either state machines or an internal value of a particular state. The interactions between balls will dictate the transitions and the events circulating from one machine to another.