Initially we had many setbacks with VGA.  Getting anything at all to show up on the screen was difficult in itself.  We were very happy when we were finally able to display a pixel anywhere on the screen, but this was short lived when we realized that a 640x480 framebuffer wouldn’t fit on the FPGA.  So we settled with a 320x240 framebuffer, which was more than enough for our usage.  The next problem we encountered was corruption of pixels on the screen.  Sometimes faint vertical lines would appear on the screen.  We realized this was because the VGA clock we were using was 25 MHz (Divided the 50 MHz FPGA clock by 2), but the VGA specification calls for a 25.175 MHz clock.  We found a way around this by changing the pixel clock on the LCD monitor we were using to match ours.
The Ethernet would randomly jam after sending between 500-600 packets.  It is still unknown why this happens, but we worked around this by having it reset the driver if it jams.  We wanted to implement the UDP protocol so that we could play over the internet, but did not have the time to do this.
Other than these mentioned problems, everything else went smoothly.

Our original goals were met, with two exceptions.  We would have liked to display at 640x480, but were limited by the FPGA.  We also would have liked to implement UDP and play over the internet, but ran out of time (It is possible with the current hardware, however).  Given what we know now, there are a few things we would do differently.  We would organize our C code better, allowing for easier additions and changes.  Also, we ran into problems with the linker not being able to compile the code because it there was too much text.  This was because we initially wrote almost all of our sprites as repetitive C++ calls that would place a series of pixels on the screen.  This ended up making the text section very, very big.  We ended making a new function that displays a sprite from the data section, which saved a lot of space and was much more efficient.  It would have been nice if we wrote this function from the beginning.
Due to the lossy nature of Ethernet, both players’ stations in the project were able to reliably talk to each other (because of our sequence numbering scheme), but there was still a noticeable, varying delay in the Ethernet transactions between the stations. We would have liked to have further optimized our Ethernet drivers to get rid of these delays, but we didn’t have the time to do so.

 Overall, our project went very well, and we are very satisfied with the final result.