So i'm making a little game in which a player can wander around a map and collect things, but may also come across randomly moving bots. I'm trying to make it so that if the player and standing next to the bot and click's 'fight' the bot loses health.
The only way I can think of doing this is by making an ActionListener in the bot class. So I'm trying to make an 'if' statement like, if the Player is on a nextdoor tile, and clicks 'fight', the bot will lose health. However I've never used an ActionListener and despite looking at lots of examples I still don't understand them.
The bot's coordinates on the map are 'ycord' and 'xcord' and the player is represented by 'P'.
Is there a way of saying this...
if(map[ycord+1][xcord].equals("P") && 'fightbutton' is pressed){
bot.health--;
Thanks a lot!
I think you should not use an ActionListener. ActionListeners need to be "registered" on the instance that creates actions, in your case players. So every bot would need to register an ActionListener on every player, which (in my opinion) is a bit messy.
Instead, I would simply create a hitBy(Player) method on Bot which is executed by some superior Game instance. A fighting player would do something like game.madeHit(this) and the game searches for close-by bots and then executes bot.hitBy(player). This can be done by simply iterating over a list containing all bots; this list should be available in Game.
Related
I am working on a cooking recipe app for google home and I need a way to string several GoogleResponses (SimpleResponse etc..) together without requiring user interaction between them.
I have searched for other answers pertaining to this, and while I have found a few similar questions to mine, the replies tend to be along the lines of "the system was designed for dialogues so what would be the point?".
I fully understand this point of view, however because of the nature and behaviour requirements of the app that I am developing I find myself in need of this particular possibility.
The recipes are divided into steps (revolutionary, I know..) and there is roughly a 1 to 1 correspondence between steps and GoogleResponses.
To give an example of how a typical recipe unfolds it is usually like this (this is a simplification of course):
main content -> question -> main content -> question -> etc..
With each instance of "main content" being a step of the recipe and each "question" requiring user input.
If if was just like this all the time then there would not be a problem, I could just bundle each "main content -> question" section into one GoogleResponse and be done.
However there are often times where the recipe flows more like:
main content -> main content -> main content -> question
With each "main content" being a step in the recipe, it does not make sense in this context to bundle them together into the same response (there is a system for the user to move back and forth between steps).
I was originally using MediaResponses for the "main content" sections as those do not require user input to move onto the next step, but due to various reasons I won't go into here as this is already getting quite long, the project manager has decided that MediaResponses should not be used in this project.
The short answer is the one you already encountered - trying to make conversational actions not-so-conversational doesn't work very well. However, there are a few things you can look into.
Recipe Structured Data
Since you're working on a recipe action, specifically, it may be worthwhile to use the standard recipe support that comes with the Assistant.
On the upside - people will be familiar with it, and you don't need to do much code, just provide markup on a webpage.
On the downside - if you have other requirements for how you want the interaction to go, it isn't that flexible. (For example, if you're asking questions at some of the recipe points, or if you want to offer measurement adjustments based on number of people to serve.)
Misuse the "No Input" event
You can configured dynamic reprompts so you get an event if the user doesn't say anything after a few seconds. If they want to speed a reply, they could ask for the next context specifically, or you can catch the actions_intent_NO_INPUT event in Dialogflow and advance yourself.
There are a few downsides here:
Not all devices support no-input. In particular, for example, mobile devices won't generate this.
This may only be valid for two no-input events in a row. On the third event, the Assistant may automatically close the conversation. (The documentation is unclear on this, and the exact behavior has changed over time.)
Media Response
You're not clear why using Media Response "shouldn't be used", but this is one of the only ways way to trigger an event when speaking is completed.
There are several downsides, however:
There are a number of bugs with Media Response around quitting
On devices with screens, there is a media player. Since the media itself is incidental to what you're doing, having the player doesn't make sense
It isn't supported on all surfaces
Interactive Canvas
A similar approach, however, would be to use the Interactive Canvas. This gives you an HTML page with JavaScript that you control, including being able to generate responses to the server as if the user spoke them (or as if they touched a suggestion chip). You can also listen to events for when the generated speech has finished.
There are, however, a number of downsides which probably prevent you from using this right now:
The biggest is that the Interactive Canvas can only be used for games right now. (But this seems to be a policy decision, rather than a technical one. So perhaps it will be lifted in the future.)
It does not work on smart speakers - only some devices with screens.
Combining the above approaches
One way to get around the device limitations of the Interactive Canvas and the poor visuals that accompany Media Response might be to mix the two. For devices that support IC, use that. If not, try using Media Response. (You may even wish to consider the no-input reprompt for some platforms.)
But this still won't work on all devices, and still has the limitation that Interactive Canvas is only for games right now.
Summary
There is no one, clear, way to handle this... and this isn't a feature they are likely to add given the conversational nature of the platform. However, there may be some workarounds which might work for your scenario.
UI Control such as LISTVIEW or Tree or ... comes with model that is observable.
When one make a change to that model, I suppose JavaFX knows how to refresh it automatically in the display.
However my question here is as follows:
Is it the intent way, that someone who wants to update and not replace this model, do so in a background thread with a platform.runlater.
In other words, one has some serious computation to do, and needs to to update an ObservableList as a result. Is it the intended way, to do the heavy work in a background thread and at the end of it, run the update in a platform run later?
I'm asking this because this is what I have been doing so far without problem. But from my reading here and there, in particular in
http://docs.oracle.com/javase/8/javafx/api/javafx/concurrent/Task.html
It seems that some other mechanism shall be used. One should rather return a full list instead of updating the observable list.
But this works only if things comes from the GUI. In case the update is triggered from the back end, there is no way to do so.
The solution that I have used so far, was always to hold a reference to the observable list and updating it by means of platform.Runlater.
Is there any other way ?
The link you give has an example (the PartialResultsTask) that does as you describe: it updates an existing ObservableList as it progresses via a call to Platform.runLater(). So this is clearly a supported way of doing things.
For updating from the back end (i.e. from a class unaware that the data are being used in a UI), you'd really have to post some code for anyone to be able to help. But you might have a look at the techniques used in this article. While he doesn't actually update lists from the backend in the examples there, the same strategy could be used to do so.
I'm implementing a bounded context using event sourcing but have come across a problem. Say I'm modelling a game of soccer, and I'm interested in both the individual goals scored (who scored them etc) and the overall score. So if I have a Match aggregate root I ideally want events raised called GoalScored and ScoreChanged. The reason I want the score explicitly stated from the domain like this is that I don't want lots of different listeners and possibly other bounded contexts all computing the same thing.
This seems simple, but: the Match object has a Goal() method that adds a new goal. In the spirit of event sourcing this doesn't directly mutate Match state, but raises a GoalScored event that is handled within the Match which then mutates the state (as well as the event being pushed out to denormalizers). So in terms of raising a ScoreChanged, the score hasn't actually changed until the GoalScored event has been handled, so do I raise another event in response to that event (ScoreChanged), effectively chaining the events? I don't think so, for a start when an aggregate root is reloaded from the event store lots of extra events are going to be created each time in response to each GoalScored.
I also thought about working out what the score would in the command handler that raises GoalScored, sort of a 'what if' situation. Then I could raise both events in the command handler. I'd really rather not do that though - it just doesn't seem 'right'. Working out the score is simple enough for soccer, but other games (cricket for example) requires more work.
I could put both the goal and the score in the GoalScored event, which is fair enough, but again it doesn't seem right - the score has got nothing to do with a GoalScored event per se.
All the examples used when discussing event sourcing seem to use the eCommerce Customer/Order domain, and I've never seen a similar case as this.
Does anyone have any experience dealing with situations like this?
Thanks
The choosing of clean domain events, just like other modeling, should result in concepts that are mirrored in the domain. You say "the score has got nothing to do with a GoalScored event per se". But it does. In soccer, the only way a score can change is if a goal is scored. Though, goals can be taken back, e.g. via offsides calls or other penalties. It's not clear whether you want to model this or not.
It is common for a domain method to emit multiple events at once. A good framework will make it easy to consider them as a bunch, e.g. as a single commit. Why not emit both a GoalScored and ScoreChanged event?
You may also want to consider whether this domain has any commands at all. The soccer match itself is the system of record. The events that come from the match are a record of history already. Are you perhaps just writing a system which processes streams of events into streams of more events?
One thing that often helps when thinking about event sourcing is to notice your tense - you say StartMatch, but in an event sense it's actually the event MatchStarted.
As for the ScoreChanged, are you consuming this event outside of the Match? If not, the Score should be the only part publically accessible, and the GoalScored event simply mutates this. This holds CQRS in a minor way (how I get the score doesn't depend on how I change it). Score can then internally hold a state, or can replay all the GoalScored events to arrive at a number each time it's called. The 'feel' of properly designed event-sourced solutions can always regenerate any state from the events.
Now, if the ScoreChanged needs to alert other parts of your system (a player ranking, for instance), you can either multi-cast the event to different roots, or you might need to refactor your design. In this case, do you want to update players in real time, or only after a match is complete?
I have this open source project for event sourcing in scala which contains examples of how a basket works using it. Just in case is useful for you https://github.com/politrons/Scalaydrated
I'm kind of a UI buff - every "screen" in my game should transition in/out when it appears or disappears. Because my game is simple in terms of resources, I thought I'd just make each "screen" a CCLayer and define a function for the transitions, leaving everything in memory. It's turning out to be more complicated than I expected.
I think I have two main problems right now:
1) Each "screen" is a CCLayer. This looks fine, but I can't seem to stop receiving touch events, even when they are inactive. Child sprites do not seem to respect the isTouchEnabled property, so I'm hitting invisible buttons all the time.
2) I wrote a custom button class that is basically a sprite with a few separate textures for states. It uses the CCTargetedTouchDelegate protocol. I'm thinking this is a big part of the above problem.
I'm not quite clear on the CCMenu stuff. Is there a tutorial or documentation out there that better explains its designed purpose and how to use it? The documentation for cocos2d doesn't talk at all about what each class does, which makes it much, much harder to properly use the library. Also, when should I use a scene instead of layers? Can I write custom transitions?
I found that if you have multiple layers in a single scene for menus, such as for a main menu (simpler to have a layer for load game, new game, etc. than an entire scene) that if you add all of you buttons as children of the layer; then to stop them from receiving touches, simply move the layer off screen when not in use. Heres an example.
[loadLayer setPosition:CGPointMake(-1000,-1000)];
[settingsLayer setPosition:CGPointMake(-1000,-1000)];
[menuLayer setPosition:CGPointMake(0,0)];
And each time you select a button that would take you to say the load game layer just reverse it for the right layer.
[loadLayer setPosition:CGPointMake(0,0)];
[settingsLayer setPosition:CGPointMake(-1000,-1000)];
[menuLayer setPosition:CGPointMake(-1000,-1000)];
It's more convenient to use CCScenes for menus. All of the children of an inactive CCScene will not receive touch events, so you don't have to manage that behavior. CCScenes also have built-in transitions like a crossfade, but if you're like me, you'll probably just want to run an action to make the scene transition out, then call CCDirector:replaceScene.
Imagine the following situation in a game: A series of random numbers is presented to the player. Each number is shown to the player for a short period of time before it goes to the next one. It is the player's aim to pick a high number. He or she just needs to 'click' in the right moment and then the number is chosen.
The question is about how to implement this scenario in a secure way in a client/server scenario.
That means there is a game client which displays the above mentioned scene and there is a server to which the chosen number (in whatever way) needs to be send. The catch is to get this thing secure so that cheating (e.g. by modifying the client) is not possible.
There's really no way to make this completely secure. Even without modifying your client, all someone needs to do is have another program running in the background reading the monitor and looking for a certain number to appear and then send a mouse click event to your client program. This can be done without modifying your client program at all. Even if you somehow managed to make it secure so that they couldn't run any other programs or services at the same time as your program, they could just point a webcam at the screen hooked to a different computer to do the optical digit recognition and send a mouse click event over USB to the computer running your program.
Fortunately, you may be able to get around the problem. Generally if something is to be a "dice roll" you want a random "luck based" outcome. By allowing them to click at a certain time you are making this a skill based game instead of luck based and therefore not really a dice roll. You could make it so there's a slight "delay" from when they click to when the dice stops rolling, so they see it rolling around, click, and it slows down and lands on a number. This way what number was displayed when they actually click does not determine the outcome, but the next (random) number after that one, which would eliminate the possibility of cheating and make this a luck based roll instead of skill based.