Fight!

I put together a simple system for the enemy fighting/chasing AI. They constantly try to align their direction vectors with the players position, but they only have a certain turn speed. Once they are within a reasonable range of setting their sights on the player, they start shooting. It still has a couple of glitches, but it's a good start I think. For example, the enemy doesn't stop firing just because one of it's friends gets in the way!

I also fixed the shield problem we were having last weekend. It was actually a larger problem than I thought because it wasn't just affecting the shields. Things were being drawn in a weird order, regardless of what order they were set up to draw in. It turns out that there were problems with the Depth buffer because it was getting set to a value in one object that was throwing off everything that was being drawn after it.

Slow progress

Unfortunately, due to finals in other classes, I haven't been able to do too much work on the game. On Saturday, I worked on a weird glitch that popped up with the shields. For some reason, the enemy's shields are being drawn much more opaque than they should be, but the player's shields are drawn normally. I worked on that for a while, but then decided it was more important to start working on AI, so Felix and I talked about how to implement each AI state.

The end is near!

We're about to start on the next and final sprint for the semester. We have 10 days to get our game feature complete, and then next semester we'll clean it up and polish it. We had to cut a few features in order to meet the deadline, but I think it's for the best. We decided to make the game more Arcade like than mission oriented, and I think it's going to really benefit from lightening it up.

Since Tuesday, I've been working on getting the radar to work correctly with no success. I even talked with my linear algebra professor to see if he had any ideas. He told me that I was on the right track, but since he didn't know how the game engine worked, he couldn't tell me how to solve a game engine specific problem.

I can project a point from 3D to a 2D plane just fine, but when the ship turns, the world orientation changes too. For example, if an enemy ship starts off in the -X direction from the player ship, turning the player ship toward it puts it in the -Z direction for the player ship, but in the world coordinates, its still in the -X direction. When the 3D coordinates are transferred to 2D, it still shows up to the left of the player ship on the radar (-X). If I try to transform the coordinates of the enemy ship by the player ship's rotation, this works until the player ship rotates in 2 or 3 directions.

For now, I'm just going to have to leave it as it is and try to figure it out after we get some AI and other important elements of the game working. I saw a radar for another game that works a little differently, and that may be the way to go if we can't get this one working.

Shields and radar

I used a shader to create a transparent-ish sphere around the ship for a shield. Its transparency depends on its normals, so it's more transparent in the center than on the edges. I also played with making it "pulsate", but most people didn't seem to like it so I got rid of it. I can use the same idea to make the shield flash when it gets hit though.

I also worked on the radar. We have the images up, but it's not quite tracking correctly. The problem comes from translating the 3D coordinates to 2D. I might try to use a shader to do it since that's what they do anyway, but I'm getting really close using a quaternion, so I'll try that route a little longer.

Felix got some particle effects into the game, but since he got them from a sample on App hub, we really don't know how they're working. I had to tweak a few things about them to get the draw order right.

Post processing

I was out of town this weekend, so I didn't get a chance to do much, but I did start experimenting with post processing effects. There are so many cool effects we can achieve and I'm really excited about the possibilities. I found a tutorial about how to make a realistic soap bubble, and with a few tweaks, I can use the same principles to create a nice looking shield around the ship.

Lasers, crosshair, scrum stuff and tweaks

I wrote a cylindrical billboarding system for the custom shader and used it to draw lasers. It looks ok, but I'm thinking of adding glow to the textures with post processing. If that doesn't look right, we might use cylinder models instead of billboarded textures. I added a crosshair to the screen when you're in first person view. I had to move the camera's position to the cockpit locator on the ship for it to look right.

I tweaked the input manager for a couple of functions - namely the camera switch and the pause. If you held down the buttons for those functions, it would keep switching back and forth so I changed them to only handle the input the first time the button got pushed. I also linked the resolution to the window size so when it gets changed in the options screen, the window actually changes.

I set up the next sprint and added backlog items and tasks and assigned them out to the team. For the art crew, I assigned Charlie the task of setting up their individual tasks and assigning them out to the team, but I did add backlog items for them.

Level loading and Normal mapping

I finished writing the shader to use normal map textures to smooth the ship and add detail. I did a quick test with one of Charlie's ships and it looks like it's working. Now we just need the art guys to generate some normal maps for the ships and it should look great! I found out that we can use the shader to have a "glow" effect, which would be great for our engines. Brandon would like me to see if I can get transparency working, which he wants to use to render the atmosphere's of planets. It would also work for a shield around the ship.

I got a "rough draft" to our enemies implemented. Right now they just show up at the given coordinates and start flying forward. I also implemented the system for loading a level built in Maya into the game. We can access the locators in the model and use those as positions for our assets in the game. For a quick test, I made a model in Maya with 8 locators and loaded 8 "dumb" enemy ships to the scaled coordinates of the locators.

Using Maya as a level editor

Brandon had the brilliant idea on Tuesday of using Maya to generate the data for our levels in the game. We decided to use locators in Maya to specify the points in space where we want things to be/happen in our level. The biggest advantage of this is that we don't have to hard code points for the assets. We just name the locators in Maya and reference them in XNA. In addition to the normal/bump mapping shader work I've been doing, I've also been working on getting a system in place to generate the levels this way.

As for progress on the shader goes, I found out that there is an effect file template in XNA for use to write your own shaders, so I've decided to write a whole shader for our game. It doesn't seem to be too difficult, but I was hesitant before because I didn't know the process behind creating a shader. Brandon has a friend that lent me a couple of DVDs that go over the whole basic process, so I feel like I've got a pretty good handle on it now.

Normal/bump mapping

I've been working on getting normal and bump mapping to work in our game so that we can use lower poly models but still have a nice polished looking game. The problem is that XNA's BasicEffect class doesn't support normal maps, so we're going to have to write our own shader.

I've been trying to figure out if there's any way we can use the BassicEffect for everything but the normal map. I don't want to have to write a shader that handles everything about the rendering process, but I'm starting to think it would be less work to just go ahead and do so.

Also, I've been trying to generate some decent normal maps for the current ship we're using to test the code, but I'm having trouble understanding Maya's process for creating normal maps. I think I finally figured it out last night, so we'll see.

Space Skybox

I implemented the space skybox this morning. I had to create a model in Maya and throw a quick placeholder texture on it because the skybox Brandon created was a little too small. The method for drawing the skybox disregards the size of the box, but it was too small to fit around the ship, so weird clipping things were happening.

The drawing method is pretty cool. I got the idea from Reimer's tutorials. You attach the box to the camera and disable the depth buffer before you draw it. That way, the skybox doesn't cover up anything outside of it. You have to enable the buffer again afterward though.

Mostly Management

We had two meetings this past week where we all got together to work on the code. I put a few more functions into the Input Manager to control the ship and fixed some little bugs I found in the Options Screen. I also added a roll capability to the ship after Felix changed the rotations to quaternions.

I posted several times to the group various suggestions and questions I had about the different pieces everyone's been working on, and answered other questions about how the model is supposed to work.

Most of the team has been pretty good about updating their pieces in the sprint, but there are a couple that I had to remind. Hopefully, they'll remember next time.

Managerial stuff

Since Tuesday, I created some more tasks for the committed backlog items in the sprint. I assigned these tasks out to the developers and artists. On Tuesday, I showed the art crew how to use the repository to version their assets. I don't know if they'll really need it like we do for the code, but I thought it wouldn't hurt.

Project setup

I've been pretty busy setting up the project and trying to come up with tasks for the backlog items. I've created a menu screen and an input/screen management system. The menu handles input from the user and (through the screen manager) changes the screen based on their selection.

Repository and Scrum Works

I set up a repository for both the programmers and the artists. I started working on the base code for the game - just the bare bones to get something up and running. I also did some management to Scrum Works. I added a few backlog items and started to set up our next sprint.

Posting discussion to Google group

I posted the things we talked about last time to a page on our Google group. I separated the things into "Brainstorming" and "Features" categories. There are certain things that we know we're going to need, and these will be the features we develop first. Once we lock down which other features we want, we'll start working on those as well.

Scrum stuff

Our game was chosen and Bob and Roger made me the Scrum master for the team. I used ScrumWorks to create our team and added everyone to it. I also created a sprint for us to plan our next sprint - mostly just to practice creating a sprint.

Matrix/Quaternion research

Since there's a possibility that our game doesn't make it through the judging, I didn't think that I should do any work specifically on the Space Fighter game. Instead, I did some research on using Matrices to represent 3D geometric transformations such as translation and rotation. In developing our prototype, this is the one area that caused me the most trouble (because Reimer's tutorials use Quaternions for rotations), so I wanted to understand the concepts and principles behind it a little better.

Explosions and tweaks

I attached explosions to the capital ship so that during the demo when we blew up the ship there was some visual indication of it. I also tweaked the controls and the movement speed a little to make it easier to blow up the ship for the demo. The bounding sphere was too large around the capital ship so I shrunk it down so you could get close enough to hit the ship without running into it.

Pod and updated models

I imported the pod model and got it to rotate around the ship no matter what direction the ship goes. I also got it to launch the pod when you press 'X'. I imported the latest ship model with it's texture map and turned the ship to face the right direction.

The enemy ships were moving based on a predefined flight path, but it was tricky to get them to face the right direction so I changed them to simply fly around randomly. I added a control scheme to better handle joystick input. I added the ability to switch between that control scheme and the control scheme for an XBox controller by pressing the 'Y' button.

Importing custom models and textures

I added particle effects capability to the prototype, but they need still need more work. I also added acceleration and braking. I set it up to use .fbx models instead of .x models since any models we make will have the .fbx extension, and imported a test ship that Charlie made. I created a test cube texture with the direct x texture tool and imported that into the game for the skybox.

Particle effects

My assignment is to get some particle effects into the game by next Tuesday. Yesterday, I started reading up on how to do both 3D and 2D particle effects. I'll be experimenting over the weekend to see which one will be best. I'll put in effects for explosions and engine thrust and possible "space dust" - we'll see.

Building the prototype

Over the weekend, I worked on the prototype. I added collision detection, randomly generated targets, and the ability to shoot those targets. I also attached the skybox to the ship and disabled the depth buffer for the skybox so that it looked to be infinitely far away.

After Felix added XBox controller handling, I tweaked the controls to add a few more maneuvers by using the right joystick as well.

Getting Started

We talked in class about the kinds of things we would like to implement for the space fighter game. Weapons, physics mechanics, ship customization, ship/enemy varieties, campaign etc.

We decided that for the prototype we want to get a fairly decent model of a ship into a basic 3d flight physics engine. For a video, we'll have it chase after another ship as they dodge other objects (asteroids, space debris, etc.) For game play, we'll probably just have the player control the ship and maybe try to fly it around obstacles and shoot. We won't have time to develop the AI, so we won't bother putting an enemy ship in for the game play.

The programmers are going to read through some XNA 3D engine tutorials online and start to implement it for the game. We may need to set up a repository, although that may not be necessary this early on and could probably wait until we get assigned into full groups.