Over the course of the collaboration we expanded Xevious to include 2D and 3D render, a local co-op mode and a local versus mode (fleet commander), and added support for importing Tiled maps to design background terrain. We also partially added 2 player networked play. The game now has very rudimentary knowledge of different levels.

At the end of the first Xevious collaboration, we had only designed for future support of a 3D renderer and Tiled background maps. That meant the code base needed a lot of refactoring to support the major new features. I spent a couple of hours before the collaboration preparing the GameState class to support local multiplayer play, but didn't spend time on the other features. So a lot of time was needed refactoring during the collaboration instead of writing new code.

I was pleased we managed to get all the features except for network multiplayer working. This was really a major overhaul of how the game code worked.

I missed out on the first half of the competition and was a little scarce the second half, due to taking care of my wife who was pretty sick. She was feeling a lot better by mid-day so that was good.

MonoGame
From my perspective, using MonoGame for the first time on one of our collaborations went smoothly. I was surprised how compatible MonoGame is with XNA. Switching Xevious to MonoGame only took about 30 minutes to an hour. Most of the work was manually adding all the content to the new content pipeline.

Working with a Repository
Doing the collaborations is a great way to gain experience using repositories since so many more issues arise when more than one person is working on the code. I am feeling more comfortable using Hg. Especially indicating file renames and pulling older versions of a file from the repo. It was also good to see other collaborators using branches to develop their features even though I didn't.

Dealing with merge conflicts is still a big challenge for me. KDiff is confusing. I want to spend some more time learning how to deal with merge conflicts as RB basically had to bail me out on one of them.

Overall
I was really happy to work with everyone and will be looking forward to the next one we do.

Of all the ideas we implemented, I think the Fleet Commander was the most novel. This could be a really fun twist to ship scrolling games if played out. One could even look into making it one player where the computer controls the ship and the player controls the fleet spawning to try and defeat the computer ship in an arcade reversal of the classic game.

I'm going to go ahead and say that even though the repo would not compile at the *official* deadline it was by no means a failure. As the universe usually works, I think we ran out of time. Or, at least, I did.

I did get a lot of the things I wanted to do completed…. the server works, for one. Secondly, you can configure the Settting.txt file with the appropriate settings, and log in as a unique player (requires recompile after editing since the Settings.txt file is contained within the project) . I didn't quite get the iInternetPlayerController working, but that was more of a de-serialization issue that was incomplete than the design and implementation not working.

I guess what I'm saying is that it was a pretty great collab. I'm pretty sure we got some better organization going in the structure even if we didn't realize its full potential. It happens, everybody butts heads at times, but hopefully it also opened our minds eye to new horizons.

What went wrong

This was a bad project to expand (even though it had both the most promise and the most votes).
There's nothing wrong with the way it was. It worked, and it was an outstanding effort for its time.
With that out there, there was a lot of room for improvement:

• There was redundant and conflicting code.
• There was design theory that we had a hard time even communicating about.
• There was time wasted figuring out what the heck was going on and what needed to be done to move forward.
• We should have spent some time 'prepping' the project before attempting to update it.

How we're going to improve
I'm not sure. I think a good thing would be to complete the design and object layout before beginning. This collab we updated a previous work.. but I don't quite recall if we had any kind of flowchart for the first one. If we had of, we could have compared what worked last time with what didn't work, and revise the overall layout. On any ongoing project, that will be priceless. Starting with a great layout and some visual diagrams can never hurt. The only other thing is communication. I don't think we did a bad job with that this round, however there were still points when we had to go back and reference each other to know what was going on. There's nothing wrong with that either in most circumstances but there's still an overall lack of foundation that reared its ugly head this collab.
So my recommendations:

• Create a graphical object layout before beginning.
• Discuss, review, and update the layout before beginning.
• Communicate discrepancies quickly, and resolve issues before they become design issues.
• If updating a previous project, spend 3 hours streamlining code.

That's pretty much my input. Like I said, I think we did well on a lot of those points, and great on others. Time was a factor for me so I'll have to see how things ended up.

Sadly I won't be able to finish the de-serialization today. I really really wanted to spend that extra time today and get it done, but it's 8am Sunday, and the last time I wasted time laying around asleep was Friday mid day. So, it's catching up to me.

I want to give a BIG OLD THANK YOU!!! to everyone who showed up and participated today (sorry, this weekend).

You know, these things aren't always fun. They are work, and that work is not easy. Add to that having to put up with me, and you've earned yourself that (-fill_in_the_blank-). Take care guys, and I'll be around Monday evening, or possibly late night tonight (Sunday).