Sprint Update The last sprint was about AI. We used states to define which update function is used for AI ship. Then according the state the function is chosen and it overwrites the movement variables like the velocity and position of the ship. My part was to create explore (roam) state. I just used timer and after certain time the direction vector and thrust scalar are reset to random values. Question is if changing the thrust is necessary, probably exploring in random directions with constant speed may look better. The code was not tested yet.
AI Ideas Here are some ideas that may make behavior of enemy ships look more realistic or interesting in gameplay:
Each enemy has its own scoring system and remembers in which states it got the highest score. This may help implement learning AI.
Changing AI state system that allows to apply several states at the same time. This would enable to have enemy for example hiding and chasing the player, or hiding and exploring, all at the same time.
Flocking and splitting the enemy and again flocking near the player.
Befriending some enemy ships so they work for you.
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.
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:
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.
File Management 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.
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.
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/
Update on capstone: I think I finished Level class methods save, load, delete. It was tested and works ok. Need something to save from Level, have no idea how to build the game level yet. I would like to start creating a load screen now.
Combined model working! Back to previous block I think I finished it. My 3D model didn't have any ModelBones so it was done by combining several 3D models together. It uses AddChild() methods that add child GameObjects to its parent GameObject. Unfortunately it is a tree-like structure and I am not looping through it very efficiently. The question is if there are a lot of children what the game frame-rate would be. I believe it can be used for up to 2 levels of tree (child<-parent<-grandpa). I got a help with math from Yen, a phd student at SCI Institude. I have to admit this was hard to see how it works. I think it is still not finished and needs some testing. Here is the video shot from the XNA test, submoon<-moon<-planet<-sun, there are 4 planets, sun si moving in +x direction and the whole system is following it.
In regards to previous blog I finally found a tutorial for animations in XNA 3.1. It uses ModelBone class and seems to be quite usefull. I am planning to wrap it in AddChild(), RemoveChild(), Transfer(), Rotate() methods. Combined model can move as one and its parts can move independently relatively to the model's center. Here is the video shot from the tutorial to get the idea:
