For the 3rd sprint I was working on a part of the HUD that was showing the number of available pods and their types attached to the ship. The second part was to make it animated so for example the shield pod would have some graphical (for example moving bar) indicator of the remaining energy.
First part was easy, I just pulled out data from the ships class and passed it to PodsView class that represents the part of the HUD. Instance of PodsView class is inside the ship class since it is there were the number of pods changes (adding, removing pods). It also makes logical to update and draw PodsView there, in reality where is the HUD? It is inside the pilot's cabin and updates the state of the plane.
In regards to the second part making the HUD animated I am still not sure what those pods are supposed to do, I may need to talk to somebody about this.
Here is the video shot. It shows types and how many pods on the bottom left corner of the screen. There is no fancy graphic it is just showing functionality, there are currently 6 weapon pods.
Monday, November 29, 2010
Wednesday, November 17, 2010
2nd Sprint and GUI
GUI
This task was challenging for me since I was redoing it over, and over, and over ;-). It was about GUI interface, pop-up windows, scroll-boxes, buttons and their over, off, selected states and how all this stuff communicates among themselves. First I started with an idea that all those GUI elements can be just another screens but this unfortunately didn't work. I couldn't figure out how to make our game state management have more then 1 screen at a time. I think it is because it lists screens as states and only 1 state at a time is allowed. I found quite an interesting tutorial how to build a state machine that allows drawing multiple screens at a time and some really cool transfer-between-screens and "loading..." effects, the link is here . Unfortunately when I started implementing it I found It was over my head and even if I were able to pull it it would be like rebuilding the screen management from scratch. My final decision was to break everything in GUI classes and have GUIElement (it can be anything from button to scrollbox) that can be added on the screen and put into the screen class list as its member variable. All drawing and updates is then done by looping through their appropriate Draw and Update methods. Those GUI classes just take care of graphical updates on the screen, when anything is selected they just pass the appropriate index of selected item to its parent screen. Then it is up to the parent screen class to add any functionality and decide what to do with the selected item.
TODO:
I already had basic code for saving, loading, deleting files from the 1st Sprint so I just created a new Player class and move all these methods there. Since I am assuming that this Player class will contain all pertinent information about the player and his/her mission (name, level, score, which ship upgrades, weapons...) it should also carry methods for saving, loading, deleting itself. I found easier to do all operations on files only and then just update screen appropriately. Also to avoid any save or delete synchronization errors when overwriting data the file is actually first deleted and then again saved but with a different file name. The file name is always different and contains a time stamp.
Conclusion
I realized (unfortunately when I was almost finished ;-)) that I am trying to reinvent the wheel. Even that I haven't found some tutorial for GUI on XNA there must be tons of information how to do it in other programming languages. I suddenly remembered that we talked in CS3505 about Design Patterns. Good programmer has some ready programming receipts in his/her bag and I probably missed this opportunity to add a new one to mine.
This task was challenging for me since I was redoing it over, and over, and over ;-). It was about GUI interface, pop-up windows, scroll-boxes, buttons and their over, off, selected states and how all this stuff communicates among themselves. First I started with an idea that all those GUI elements can be just another screens but this unfortunately didn't work. I couldn't figure out how to make our game state management have more then 1 screen at a time. I think it is because it lists screens as states and only 1 state at a time is allowed. I found quite an interesting tutorial how to build a state machine that allows drawing multiple screens at a time and some really cool transfer-between-screens and "loading..." effects, the link is here . Unfortunately when I started implementing it I found It was over my head and even if I were able to pull it it would be like rebuilding the screen management from scratch. My final decision was to break everything in GUI classes and have GUIElement (it can be anything from button to scrollbox) that can be added on the screen and put into the screen class list as its member variable. All drawing and updates is then done by looping through their appropriate Draw and Update methods. Those GUI classes just take care of graphical updates on the screen, when anything is selected they just pass the appropriate index of selected item to its parent screen. Then it is up to the parent screen class to add any functionality and decide what to do with the selected item.
TODO:
- Right now I am having problem with transferring between screens that its buttons doesn't remember previous state (already pressed).
- It is missing Refresh screen method, when changing the screen resolution it doesn't update sizes appropriately
- Functionality, it needs to be decided on the whole New Game, Load Game flow and what information save in SavePlayerData structure.
I already had basic code for saving, loading, deleting files from the 1st Sprint so I just created a new Player class and move all these methods there. Since I am assuming that this Player class will contain all pertinent information about the player and his/her mission (name, level, score, which ship upgrades, weapons...) it should also carry methods for saving, loading, deleting itself. I found easier to do all operations on files only and then just update screen appropriately. Also to avoid any save or delete synchronization errors when overwriting data the file is actually first deleted and then again saved but with a different file name. The file name is always different and contains a time stamp.
Conclusion
I realized (unfortunately when I was almost finished ;-)) that I am trying to reinvent the wheel. Even that I haven't found some tutorial for GUI on XNA there must be tons of information how to do it in other programming languages. I suddenly remembered that we talked in CS3505 about Design Patterns. Good programmer has some ready programming receipts in his/her bag and I probably missed this opportunity to add a new one to mine.
Monday, November 8, 2010
GUI for XNA
It is surprising that XNA doesn't have any GUI classes to build something like drop-down menu, scroll boxes, buttons and so on. I went through some forums and it looks like all game developers just create those GUIs from scratch. I will probably try to do that also. It should have InputManager object as parameter, position on the screen, and more; the result should be some classes like PopOutWindow, ScrollBox, DropDownMenu, .... Then in order to use it I will need to create a Screen object and initiate and place those objects there.
Wednesday, November 3, 2010
1st Sprint and Simple AI with Acceleration (forces again)
Update on Capstone:
My part was to create load, save screen and device some means for it. In regards to screen I just reused the code from other screens made by Jason and James and tweaked it to my needs. The save, load, delete system had to be built from scratch. I made a choice to keep all files in the same directory and located it next to the executable file. This directory should not change anytime only the files inside it. After several tests and frustrations with file naming and their renaming on the fly it showed as best just to save them each time with different name made of a time-stamp. After each file operation the reloading files must follow together with refreshing the screen. I think this is the best way to avoid problems with any lag for file operations (saving, deleting,... is not instant) and related XML file corruption.
Simple AI with Acceleration (forces again)
Simple AI can be built quite easily with a notion of acceleration (forces). If we are passing the player's coordinates to all enemy ships then each of them can compute a force on itself with magnitude proportional to its distance to the player. Also at the same time we can introduce some small pushes in random directions. If the player's ship is moving the enemies will follow in its general direction, if the player stops they can just move randomly around one spot next to the player or if they acquired higher speeds they would be circling the player.
This effect can be applied to simulate the enemy flocking, instead of the player they would follow a leader.
Cool info on Flock simulation in Games
I found a cool info on more advanced flocking simulation http://www.red3d.com/cwr/boids/
My part was to create load, save screen and device some means for it. In regards to screen I just reused the code from other screens made by Jason and James and tweaked it to my needs. The save, load, delete system had to be built from scratch. I made a choice to keep all files in the same directory and located it next to the executable file. This directory should not change anytime only the files inside it. After several tests and frustrations with file naming and their renaming on the fly it showed as best just to save them each time with different name made of a time-stamp. After each file operation the reloading files must follow together with refreshing the screen. I think this is the best way to avoid problems with any lag for file operations (saving, deleting,... is not instant) and related XML file corruption.
Simple AI with Acceleration (forces again)
Simple AI can be built quite easily with a notion of acceleration (forces). If we are passing the player's coordinates to all enemy ships then each of them can compute a force on itself with magnitude proportional to its distance to the player. Also at the same time we can introduce some small pushes in random directions. If the player's ship is moving the enemies will follow in its general direction, if the player stops they can just move randomly around one spot next to the player or if they acquired higher speeds they would be circling the player.
This effect can be applied to simulate the enemy flocking, instead of the player they would follow a leader.
Cool info on Flock simulation in Games
I found a cool info on more advanced flocking simulation http://www.red3d.com/cwr/boids/
Subscribe to:
Posts (Atom)