Half a Victory Is Better Than None

I failed to solve the synchronization issue, I didn't finish implementing the periodic refresh algorithm I came up with, and I haven't even started the prediction/estimation part.  But the sad fact is that I am out of time.  I've pulled an all-nighter and now I must prepare for a long road trip.  I hope I'm safe on the road after this!

On the bright side, my video clearly shows what's working and what isn't, and my documentation is honest and straightforward.  So even though I'm deeply disappointed that I didn't finish the project to my satisfaction, I can take comfort in the fact that I did my best in the time I had, and accomplished some decent things in spite of the numerous factors against me.

Most importantly, I learned a lot of very useful things for my own future projects.  And that's my whole reason for being here at DePaul.  Thank you, Professor Keenan, for another practical and challenging class.

What to do: Panic or Surrender?

The project was going so well yesterday!  I got all the player commands working and was able to go to bed and sleep well knowing that only the collision synchronization remained for today.  Assuming today was going to be as productive as yesterday, I felt confident in my ability to work out those remaining issues one by one and have the project completely finished by bedtime.

As has been the case on every single part of this project, the reality didn't support my optimism.  The network went down over and over again today.  Also, most of today's builds just crashed on the other test machine, with no noticeable pattern.

I'm going to try to finish my efforts to get the two machines in sync, but if I am not successful in the next few hours, I have no choice but to throw in the towel.  I'm heading out of town in the morning and there will be no more time to work on the project.

Here goes  a "Hail Mary"...

Thrust! Woohoo!

The ships thrust!  Finally!  My code was just in the wrong place.  It wasn't executing for the other player, only for the local one.

Another problem solved.  Now to figure out a way to synchronize the two machines.  My personal laptop is so many times faster than my work machine, the actions of the players don't sync up at all!

On to the next challenge...

Turn! Fire! Asteroids?

I'm a-turnin' and a-shootin'!  Yeehaw!

Trouble is, I didn't change anything.  Why did it work this time when it didn't work before?

More trouble -- my asteroids weren't there this time, but the last test had them all there correctly.

Hmm...  There seem to be some reliability issues here.  Time for more troubleshooting.

PacketReader Problem Solved

The problem with my packets was that I had accidentally removed the call to NetworkSession.Update.  I fixed that, and suddenly I have asteroids on both machines!  Yay!  Unfortunately, my ships still don't move, turn, or shoot.  One step at a time.

So there's one problem solved.  On to the next...

Where, oh where have my packets all gone?

OK, here's the situation at the end of my work day today:  The lobby works, the players connect, the game begins, packets are written...but no data is ever received.  The players can move around on their respective machines, but their representations on the remote machines remain motionless.

The problem:  IsDataAvailable always returns false no matter how much data is actually sent.  Countless examples and online references show the same sequence of steps that my code is performing, but for some reason, there is never any data to be read by the PacketReader.

Where, oh where have my packets all gone?  Oh where, oh where could they be?

I guess I have my work cut out for me tomorrow.

Visible Signs of Progress

Look!  My lobby is 100% working.  My code was slightly flawed, but not bad.  As I suspected, all I needed was a working network.  I'm suddenly very grateful for my employer and my freedom to use its equipment.  :)

Upon launch, the user presses the Home key to log in with a local profile. 

The user then presses A to host a game or B to join one.

When the other player joins, his/her gamer tag is listed on the main screen.

"Ding!" Light Bulb!

On my way home, as I grumbled and cursed this irritating, stressful, and completely wasted day, I got an idea.

It occurred to me that the problem at home is the network while the computers work fine (well, mostly), and the problem at work is the computers while the network works fine.  So this seemed like an obvious next step:  Why not take my two working laptops to work and connect them to the network there?  Duh!

Thus is the plan for tomorrow.  I'm going to get up, have a good breakfast, pack up my laptops and their power supplies, and get my butt back to work where I can borrow the network and hopefully, at long last, see if all that code I wrote last week actually works.  I'm not placing any bets on that, but even if it runs and crashes, at least I'll have something to troubleshoot.  And that's far better than what I've got right now.

A Correct But Useless Answer

A little research has revealed the answer to where to get a .NET Framework Client Profile.  Apparently, they get installed automatically with any Visual Studio installation, including Visual C# 2010.  So this answers at least one of my questions, but does absolutely nothing to solve my problem because, as I mentioned in my previous post, I cannot install VC# in this room without rebooting, and I can't reboot without losing everything that I've already downloaded, synchronized, and installed.

I shall continue to brainstorm.  Stay tuned.

Is There No Way To Test This Thing?

Realizing that I had absolutely no way to test it on my network at home, I decided to do the next best thing and test it at work (where I am right now).  So I packed up my laptop and headed to the office.  I chose a nice, quiet room with its own local LAN and some of the most up-to-date technology we have in the entire building.  I thought that I'd be able to complete the project while having an entire afternoon with a pretty fast, reliable network all to myself.  Once again, I was sadly mistaken.


I installed Dropbox on two of the computers so I could synchronize them with my workspace.  I had forgotten that my Perforce directory still contained all of the projects from my last class with Professor Keenan, so that took a lot longer than expected.  No problem -- I still had a few more hours before I had to get back home.

The first unfortunate discovery was that the game didn't run.  At all.  So I checked to see what version of XNA was installed here.  It's 3.1, not the 4.0 that the project requires.

So I tried to install the version of XNA that Professor Keenan put in Perforce.  It said that I couldn't install it without having Visual Studio 2010 or Visual C# 2010 installed first.  This room only has 2005 and 2008, so I started installing Visual C# 2010.  After a painfully long wait, it finally completed, and then told me that I had to restart the computer to finish the installation.  Well...that's not an option.  When these computers reboot, they get re-imaged, so everything that I'd just done would get wiped out.  Right down the drain go a few hours of downloading, synchronizing, and installing.  So this approach was obviously not going to work.

Then I decided to see if I could set it up the way an end user might.  I went online and downloaded the XNA 4.0 Redistributable.  Surely this would be a simple solution, right?  Nope.  Upon launch, the installer said that it "requires at least Microsoft .NET Framework 4 Client Profile".  What the hey?  Do all Games for Windows make their customers jump through so many hoops?  Seems like that would be bad for business.  More importantly, where do I get a Client Profile, and what the heck is it anyway?

Ugh.  Exasperated.  I'm gonna take a short walk and think about this.  At least it's beautiful outside.

Code Complete...Maybe

As of right now, as far as I know, all of the major functionality has been implemented.  Sending, receiving, and processing messages, creating and joining sessions...all of it.  Unfortunately, I have no idea if any of it works because I haven't figured out how to test it yet.  I can't establish a connection, and half the time, Spacewar crashes the other two computers in the house anyway, so I really only have one computer that will run the game reliably.

Oh, well.  It's time to quit for now and head to bed.  I'm sure these feelings of exasperation and helplessness will lull me into a deep, restful sleep.

A Little Good News, a Little Bad News

Good News:  Based on some simulated data and logic, I believe that my lobby code will probably work correctly in its current form.  Also, I got Spacewar to run on my work laptop.  Also, the network sending and receiving code is nearly all in place and ready to be tested, which brings me to...

Bad News:  I cannot get the system link to connect over my home wireless network no matter what I do!  So I have a new strategy: I'm going to see if I can find one of my old hubs and connect both computers directly to it so I can try connecting straight through the wire.

Stay tuned for updates...

A Lobby At Last...Or Is It?

With considerable reservations, I finally claim to have a working lobby.  It's taken 14 hours of nearly continuous effort, it's not user friendly, it's not intuitive, it's not informative, and it doesn't work at all the way I want it to, but it allows logins and can enumerate the connected players.

The next two challenges are these:

1. First, how in the world can I test this?  The game runs fine on my own laptop, but on both my work laptop and my wife's, it crashes immediately upon launch.
2. Second, I have to determine the logic for when the game should actually begin.  Right now, my code looks for two connected players who have both signaled ready.  This logic may work, but until I solve Problem #1 above, I won't know for sure.