Tuesday, November 30, 2010

Home stretch

We have 10 days left to get our game to a playable state. What we have to really focus on now for this last week is to add AI into the game. As of right now, there is no AI in the game at all. We've also gone ahead and cut down quite a bit of features. This includes adding branching storylines for multiple factions, hangar to store multiple ships and ultimately, keep the game more arcade like. The schedule is a bit tight considering we all have other final projects we have to finish but it looks like we will be able to get everything in by next Thursday. We decided to go on a week and a half week sprint and so James will be assigning us new tasks.

Thursday, November 25, 2010

Tuesday Class Canceled

The University canceled all classes after 2pm on tuesday so we did not have a stand up meeting. Last time, we decided to try one week sprints instead and my current progress is as follows. I was assigned the task of implementing a radar system and its gui and I have completed this task. Since the design of the radar was not made explicitly, I initially worked on a top down view style of the radar. During the weekend, I talked with some of the members who thought the radar would simply show the enemies located at the front half of the ship. This means that the bottom of the radar would be the bottom of the player ship, etc. I began working on this system but soon found it to be much more complicated. The problem is how to actually define when an object is below or to the right of me? Essentially all axis, x,y,and z, determines the position each at different situations. My initial reaction to this implementation was simply confusion. It seems really strange to me to have a radar keep track of simply just objects in front. I need to ultimately talk to the team again so we can finalize the design of the radar. However, as mentioned by James, we need to have some type of radar in by the end of this semester, and if we decide to go a different route, then we can change it and consider it as the polish portion of our development cycle. I think we might be meeting on Saturday and hopefully, we can finalize all the tasks we need to get what we want as our playable demo

Thursday, November 18, 2010

Beginning of our last sprint to playable demo!

For today, I continued to add onto the collision detection. Since new types of weapons and objects are added, I've been adding onto the collision detection so the new objects can have interaction between other objects. When I first implemented the collision detection, we simply had a list of entities and from that list, I specifically only had asteroids. As more objects were created and I went from a naive implementation to a more optimized collision detection separating our space into 8 distinct quadrants, I began building individual lists for types of objects. Space objects would be in its own list, ships would be in its own list, pods, and now lasers. These lists improve on performance since I don't have to iterate over everything since all objects derive from entities, but rather, loop over the list of ships and pods if I wanted to check if any pods collided with any ships. So for this sprint, I began creating code for the laser list and its behaviors against other types of objects. For the next time, I have been assigned new tasks for the new sprints, My tasks are implementing a backend system to transform object's 3D location into a 2D format, and with that 2D format, I can then translate that location relative to the playership and display it in a radar.

Tuesday, November 16, 2010

Close to the end of sprint #2

For today, I've optimized the collision detection code by splitting our 3D space into regions and create lists that would keep track of the current objects in those regions. By doing so, the number of iterations the collision detection would have to do decreases dramatically especially when there are large number of objects. Instead of performing useless checks with objects that are opposite of the 3D space, only objects within a certain region in space can check against each other. In addition, if objects are in the same region, I perform another optimization to make sure that objects are within a certain distance of one another before continuing on with the check. For space objects for example, I would allow 2 objects to have a maximum distance of 512. If the distance is outside of that 512, no collision checks will be performed. Eventually, after we have models with numerous meshes available to us, each model would have a large bounding sphere that would encircle the model with smaller bounding spheres for the actual collision detection. The large bounding sphere will allow us to do a simple check to make sure the bounding spheres are indeed intersecting before we do the meat of the collision which will require us to loop through all the smaller bounding spheres to make sure there is indeed a collision. I also edited the camera a bit so that the camera is not created within the player but by the level. Because we can now use locators to define create tags for our model, we can simply create locators for the camera position for a specific ship and then assign the camera to the locator we want. For the remainder of the sprint, I plan to help the others finish their task and I will also take a look into the pod having difficulties firing at their designated position.

Saturday, November 13, 2010

Another sprint update and the process of reviewing games

Today in class, we went over how to review games and some of the key ideas that were discussed includes 1) Determine our target audience 2) Write about function and avoid opinions and personal bias. As our target audience will be developers like ourselves, the main focus in our review would be bugs that we have discovered and gameplay concepts that still need improvement, polish that would help create a better overall gaming experience.

For the sprint, I continued to add on to the basic collision framework such that all our objects will interact with each other in some way. For example, pods will "explode" when they collide with other objects. Currently, without any particle effects, pods and the objects they collide with will simply disappear. But when space objects collide into each other, they will "deflect" off of each other and go their own separate ways. I still need to add more math algorithms to make collision more natural however, I've completed all my tasks in that a basic collision system is now in place. One major problem that I will continuously be working on is the optimization of this collision system. Even with around 300 objects, framerate drops due to the large amount of checking. As for next time, I will continue to polish existing code and help any others who has yet to complete their tasks.

Wednesday, November 10, 2010

Progress of Second Sprint

For Tuesday's class, I was able to implement a basic framework for the collision of objects. For our purposes, when we debug the program, I also render the bounding spheres so we can tell when we are colliding into objects. Conveniently, XNA actually automatically create bounding spheres for each mesh of our model. By using these meshes, no extra code will be required to build bounding spheres. However, since a bounding sphere encapsulates a mesh, a single model will require numerous meshes for bounding spheres to be accurate. Therefore, each model will be split into smaller meshes such as a mesh that contains a wing, a mesh containing the body of the spaceship, etc. Next time I intend to generalize the collision framework so that collision between any objects will be applied. Since the last time, James found out that artists can put locators onto certain bone areas and name them. These locators can be accessed through xna and will make our ideas of attaching pods much easier. We can give locator for where to attach cameras, where to place pods, where to emit engine particles, where to shoot weapons, etc. We are also applying these locators into our level design. We can use these locators to place mission specific objects and certain story triggers. As a result, we can use maya as a level editor. Each level will be represented as a model which contains a series of locators which the programmers will use to place mission objects. This is solve our previous concern of hardcoding every single level.

Thursday, November 4, 2010

End of 1st Sprint

We're at the end of our 1st sprint and I was able to complete and do more than what I was assigned. My task was to get the player's movement implemented correctly and I helped create the gamescreen and the tutorial level so the player ship would be displayed. I also added the camera with a spring like effect to it as well as randomly generated asteroids.

As for today's class, all three groups showed their current progress, talked about what didn't work in our first sprint, and our impression on how our first sprint went. For the standup meeting today, I was able to create randomly generated asteroids since last time, and since we begin our next sprint, I will wait for my task to be assigned.

After class a few of the programmers met up and discussed ideas on what we'd like to accomplish in this upcoming sprint and some of the suggestions were to get the collision working between objects, figure out a efficient way to display a skybox without any notable rough edges that may show the faces of the box.

Tuesday, November 2, 2010

Tuesday progress

In class today, we learned that we will have to share our current progress with the rest of the class next time. Except for that news, my group went down to the computer lab to work on our project and spent some productive time refining our game concept. We discussed in detail what our ideas were regarding customization and decided to have a formal vote next time to finalize the customizing details.

For today's sprint, since the last time we met, Pace and I got the Game Screen and the tutorial level working such that the game will load tutorial level successfully and be able display and update all the ingame objects. I was able to complete my sprint task of getting the player's movement completed and also finished the camera so that the camera will trail the player. In addition, the camera will use a "zooming out" effect to show that the ship is accelerating, and then zooms back in when the ship is no longer accelerating. For the next time, I intend to help the others who still need to finish their work and polish and clean up the existing code to ensure it stays readable. So far, I have no impediments