In a game I made, I want to restart the game when the players presses a button.
I have an instance of a Game class, which is where most of the game happens.
I though that I could simply initialize it again, and it will be reset.
Game game = new Game(); - When the program launches.
game = new Game(); - When restarting the game.
But the game uses a lot of additional classes, such as Tank and Missile. Do I have to initialize all of them too, or is initializing the Game class, which will create new Tank objects and Missile objects (with the same reference names as the previous Game instance), enough?
In general, what would be the best way to reset a game or a level in a game?
Thanks
To provide a function that resets everything that needs to be reseted? Creating a new instance of this possibly complex object seems redundant and a waste of resources.
Related
I'm new to Agile. I'm currently writing a software that basically does a simulation using real-life objects – for simplicity's sake here's an example:
I have a GUI where I can add two Human Object(s) onto a plane, a Ball Object, and one Human Object. Then I can press a PLAY button to simulate a situation where Human Object A can throw the Ball Object by specifying parameters I can use physics based on Force/Velocity/Direction, and then the Human Object B can catch the ball based on its own position and time while he is walking (where its movement is specified by reading in an input file).
It's a two step phase where I do parameter specification, then pressing play to simulate how those events unfold.
My difficulties reside only for the backend part where I know I need an a) Event Handler, b) Coordinate system infrastructure. But I'm having trouble determining where in my User Stories they should belong?
Right now they sit on its own User Story just written as tasks as "Event Handling." and "XYZ Coordinate System", which I feel is not very well placed.
What I'm trying to understand: If I have the User story:
As a user, I want to be able to be able to add a Human Object to my simulation so that I can have the object interact with the ball
Would my Task List (for specifically back-end stuff) include:
Implement xyz-coordinate system
Implement having an Event Handler and adding the Human Object to being an Event Handling object?
Or should I stick those tasks into a User Story like
As a user, I want to be able to see my objects interact with each other when I press a play button so that I can determine what the status of the objects are after it is done playing
to handle the task of implementing infrastructure of the coordinate system and event handling?
(And to note, in reality outside of the example, I have a lot more objects and back-end processing.)
The direct answer to your question is that the user story you put at the end is probably your best bet for a user story. Implementation tasks are just how your team is going to make that happen. Where it gets messy in complex work like what you are describing is if that user story takes a month to build and you have to break it down.
You want to deliver functionality, even if it isn't the whole package. This may be abusing your example, but where I'd probably start in the case you give is first limit the scope of the user story to simulating those exact objects and interactions: 2 humans and one ball. This takes out a lot of the variability. Now, from a programming standpoint, there is a huge trap here. When you implement it, make sure to do it in a way that those areas can be expanded later without throwing the implementation out and starting over if you can.
Next, if that is too big, I'd probably split the throw and the catch simulation. This is implementing the code in a way that is aligned with the purpose of Agile. If I make Human A throw a ball, I can show that to a user and potentially learn. Maybe we are simulating football and we throw a "prolate spheroid" (the term for the shape of an American football) in a perfect spiral. I show it to the user and he says "No no, we're from Spain, we are simulating an overhead 2-handed throw of a round ball." Now you've learned something critical about the work you've done and the work to be done (the receiver can't catch with their hands).
The specific tool of user stories may or may not be helpful. I could write this last one as "As a sports coach, I would like to simulate a throw-in so I can experiment with different techniques." That contains a lot of convenient information for me. In particular, user stories are most valuable in places where you are trying to understand your user's needs better. However, if you feel you understand them well enough, "Simulate throw" is a perfectly adequate backlog item.
I am making an adventure game and, in order to go inside buildings, I would have to change scenes. I wanted to ask, since I want to keep the UI when I am entering buildings, how can I swap out a scene that is not the current one?
I am now using the scenemanager that I got from the official Godot documentation to switch scenes, but it doesn't have any functions to swap existing scenes.
I was thinking about placing a main scene within the UI and then another scene which would hold yet another scene. That last scene would be the one switching.
How I can destroy a single particle using phaser.js?, currently I have a simple particle system in my game (using a image as particle). I have seen the phaser documentation and the destroy function destroys all particle system (I want to destroy only one).
Since Phaser.Emitter extends Phaser.Group, you can iterate over the children elements of an Emitter with the methods you have available for a group (and the ones specific to an Emitter - look here - you have getFirstAlive() for example).
So you can have it like this:
emitter.getFirstAlive().destroy();
but it's up to you to find the one specific particle you want to destroy.
I have an application that I am working on, and I'm basically self-teaching GUI programming. I asked a fairly involved question over on programmers.stackexchange. This question is about the mechanics of an idea I had not tried.
I have three widgets: a TreeView, a TextField, and a DrawingArea. Each of the three widgets interacts very intimately with events on one necessarily triggering actions on the other. Those three widgets largely do not interact with the rest of the application except (so far) by reading an MVar containing the global application state.
Currently I can think of no case in which the larger application should ever interact directly with any of those three widgets. Further, that identical pattern would be replicated to review other data that has the same form. So, it seems to me that it would make sense to actually bind these three widgets together into a larger composite widget that can interact with GTK's normal event queue. So, for instance
type MyDataViewWidget = (TreeView, TextField, DrawingArea)
data DataUpdatedSignal a = DataUpdatedSignal a
data RedrawEvent a = RedrawEvent a
So, the widget would use DataUpdatedEvent to indicate to the rest of the application that something inside MyDataViewWidget changed, and RedrawEvent would tell the widget that it needs to redraw or re-read the source data.
(technically, I have not thought through semantically what the various actions in the composite widget would do... whether the widgets would just have a read-only copy of the application data and need to receive new read-only copies with the RedrawEvent or perhaps the widgets would have the MVar itself and be allowed to change the data in the MVar, etc... I'm just interested at the moment in how to actually do this)
Are there any examples of doing something like this? Basically, what instances do I need to implement to create the new widget and the two signals? I'd prefer to stick to Haskell, but I could drop to C in order to build up the new widget.
Unfortunately, there is currently no pure-Haskell way to (correctly) implement the Widget type class. You'll need to implement your widget in C, then import it via the FFI. There are numerous examples of this -- basically all of gtk+/gtk2hs is a collection of hundreds of examples of doing this.
I am developing an XNA project, where there are two DrawableGameComponents A and B, with the following constraints:
Either A is visible, or B is visible. So only one of their "Draw" methods has to be called.
Both A and B need to be enabled - always. So the "Update" method of each has to be called under all circumstances.
Currently both A and B are executed in the same thread. However, the "Update" methods of them are very CPU-Intensive. Since both GameComponents do not need to talk to each other, and both GameComponents do not need to share any data, it is easily possible to parallelize them.
What I would like to know is how to do that in XNA. The "Update" and "Draw" methods are called by the XNA Framework, so I do not know where to put the Threads. Is there a standard way of doing this?
Usually this is done through game state managment, where the Game1 class (default class) is used to call the Update() and/or Draw() of other classes (game components)
Take a look at the xnadevelopment game state managment tutorial, their they describe how to call diffrent updates and draws of different classes, and hopefully u'll see that multi-threading can be implemented in the Game1 class (default auto-created XNA class)
p.s. if you dont mind doing a lot of reading take a look at this article on XNA multi threading, its accompanied by some diagrams that explain how it works very well.
You haven't specified if you need both Update's to run simultaneously so I'm going off the assumption that one component is the only that needs to be drawn.
Using DrawableGameComponents they are automatically synced with your Game object, but, if you store a reference to each component instead of instantiating them without a stored reference, such as:
componentOne = new FirstComponenet(this);
Components.Add(componentOne);
componentTwo = new SecondComponent(this);
Components.Add(componentTwo);
// Immediately disable componetTwo
componentTwo.Enabled = false; // Prevents Update from firing
componentTwo.Visible = false; // Prevents Draw from firing (for Drawable components only)
Then you can let XNA manage the Update/Draw loops as per normal. componentOne and componentTwo being class level variables, you can manage when each are active.
Again, this is based on the assumption that you don't need one to update at the same time the other does.