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.

Taking a step back

Actually, two steps back.  The first step back was going back to the drawing board on the lobby.  I'd struggled for days to adapt the sample code to the Spacewar game without success.  Without any success.  So I decided that, with the huge mess I'd made, it would be easier to go back to the drawing board on my design of the lobby interface.

In the process of reworking my lobby, I discovered another serious problem.  Just as Professor Keenan forewarned, the data-driven code did indeed require more work once the networking stuff started coming into play.

So my second step back was to re-evaluate the data-driven stuff and make sure that the distinctions between Player 1 and Player 2 were being made properly.  Now that these things are all looking perfect, I'm returning once again to the lobby functionality.  Third time's a charm, right?

A Discovery and Cautious Optimism

Just for the heck of it, I decided to log in to both games using the same login ID -- the one that works -- and I made an interesting discovery.

1. First, I logged in to one machine and created a session using System Link.
2. Then I logged in to the other machine with the same ID and joined that session.
3. On the first machine, I got an message that said I had been disconnected from the LIVE service.
4. However, both machines went into the lobby, and both IDs were listed.

So now the question is whether I can get by using the same ID on both machines as long as I use the System Link option.  Time will tell.  I'm moving forward with this approach for the time being.

Venting frustration...

I've spent all day trying to run the network game state management demo, and I have just now discovered the reason for my lack of success. To make matters worse, it turns out that Professor Keenan had warned us about this issue weeks ago and the fact somehow slipped past me.  Here's my stupid, boneheaded story:

I set up the accounts for my first login (using my DePaul email address) back when the assignment was first given. There were no problems.

To have a second computer to test with, I brought home my work laptop from the office.  The versions of XNA and Visual Studio were older than the versions needed for this project, so I had to upgrade both.  Why did I have to upgrade Visual Studio?  Because my second Windows LIVE login was causing the program to crash and I wanted to try to debug it.

The reason for the crash, according to the debugger, was that the account didn't have an XNA Creators Club membership associated with it.  That's when I remembered that I never finished the setup process for that email address.

Then I started setting up the App Hub/Dreamspark stuff for that account. I got to the point where I needed to enter the code provided by Prof. Keenan, and the system wouldn't take it.  It kept saying "Please enter a valid code".  No matter how careful I was, or what combination of "O" and "0" I substituted for that ambiguous character, the code was never valid.

So, to get another functional login to use for this project, I've asked several of my game developer friends if anyone has a spare XNA Creators Club account login that I could borrow for a couple of weeks.  While I wait for responses, I'm going to finish what I started with the lobby screen.  Hopefully, by the time I finish it tomorrow, I'll have a second login that will enable a "Player 2" to join.

My hopes are resting on the fact that I have no plans whatsoever for the coming weekend, and plan to use the entire time to work on the project and get caught up.

Wish me luck.

Back in the Swing

After being forced to abandon the project for a week, I am now back into the deep concentration required for it.  My mother came to visit for a week, and she kept me insanely busy the entire time.  It was really awesome to have all that time to spend with her, but it did set me back just a little bit and caused me to miss the deadline for the lobby.

No worries, though.  I've written multiplayer game lobbies before, and I did spend some time last Monday analyzing the sample code and speculating on how it might be adapted to the Spacewar project, so it's not like I'm coming in cold.  "Nothin' to it but to do it."  Right?  (Fingers crossed....)

Data-Driven Me Crazy

Well, as it turns out, three of the problems I mentioned in my previous post all shared the same root cause:  I was not handling the message correctly!  I designed my system so that all data packets have a type field that tells the queue processor how to handle them.  For the asteroids, I had forgotten to specify the message type as ASTEROID_INIT.  Without this identifier, the message was being handled like a TURN message that was owned by the host.  And THAT, my friends, is why Ship 1 was facing down the Z axis:  it was getting the asteroid's rotation values.

So now the only problem I have to solve before moving on to the lobby is to figure out why the game is throwing an exception when transitioning to the next screen.

On to the next challenge!

Complications With the Data-Driven Approach

I've been working on this phase of the project every day this week, but I had completely forgotten to keep up with the blog, so here's an update of what's happened:

I started out by focusing on the Retro mode since it's considerably simpler.  I got Fire and Hyperspace working almost right away.  Over the following couple of days, I got Thrust and Turn working.

Now that all of the player commands in Retro were successfully data-driven, I turned my attention to the Evolved mode.  This one isn't turning out to be nearly as simple.

On the plus side, the data-driven controls from the Retro version transferred over with no issues.  Fire, Hyperspace, Thrust, and Turn still work by processing the messages from the queue.  However, there are some issues.  Here is a list of the current challenges and things to fix:

• The asteroids aren't showing up.
• When the level ends, it throws an exception.
• Ship 1's model is facing down the Z axis for some reason.
• This causes his bullets to miss the opponent because they're passing by behind him.
• Ship 2 doesn't have these issues.  He's facing the right direction and his bullets hit Ship 1.

As a result, I'm probably going to miss this first deadline.  But I plan to have a lot of time to myself next week, so that should provide enough opportunity to catch up.  Here's hoping!

Fire and Hyperspace done!

After several analysis sessions, I finally think I have a good idea on how to data-drive this thing and make it conducive to networking.  So far, it works great for the Fire and Hyperspace commands.

I'll provide more details later after I get the thrust and turning commands working, because then I'll have a better idea about whether this approach is really going to work.  I have faith!

I also skipped ahead and looked at the lobby code from the Invites example.  I may be mistaken, but it looks like a lot of that code can just be borrowed as-is, with little rework.  I hope I'm right!  We shall see soon enough.

Preppin' for the project

I've set up one set of logins for the project now.  What an utterly annoying process!

For mhenson@mail.depaul.edu:

• Windows Live...check.
• Dreamspark...check
• App Hub...check.
• Xbox Live...check.

PA4, done and gone

The interleaving part was a lot easier than I was anticipating, but I had to lighten up on my attempt to preserve the test program in its original form.  The only change I really made was that I put all data into the same queue instead of having separate queues for the Calc and FSM data.

This was made possible through inheritance.  I created a QueueData class with an abstract getDataType() method.  Calc_Data and FSM_Data were refactored to inherit from this class.  The InputQueue was declared to store QueueData objects, so it could accommodate both types of data.  The process() method iterates through the queue, and if getDataType() says it's Calc data, then it calls pCalc.doWork().  Otherwise, it calls pFSM.doWork().

Mission accomplished!

PA4 is coming along fast!

I just started working on PA4 and it's nearly halfway done already. I had to make some changes to the test program, but otherwise I've been able to conform to it very closely up to this point.

I'm ready to start the interleaving part now.  I know of a couple of different ways to implement this part, but I'm trying hard to use the test program as it's given, and I'm having a lot of trouble figuring out exactly how Professor Keenan's implementation worked.  If I don't figure it out soon, I'll just go with my own implementation and see how much of the original test program I can keep.  That'll be a task for Wednesday, which I believe will be my next chance to sit down with it.

More to come...

PA3 is almost done...

I finally got a chance to sit down with PA3 again today.  Thankfully, the code I wrote at the airport last weekend compiled and ran.  However, it didn't work.  The server wasn't receiving the same data that was being sent...or so it appeared.

The problem had two parts -- first, memcpy doesn't work exactly the same way as sprintf.  Getting the data into the sending buffer was a whole lot easier when I switched to sprintf to write the integers into the character array.  Second, the server appeared to be receiving garbage.  The problem was the buffer length used in the recv call.  I was receiving the entire length of the buffer rather than just the number of bytes expected.  Once I made that change, the data came through nice and clean.

Then, miraculously, everything else fell into place pretty neatly.  The only other problem is that I was looping through the sorted list backwards and printing the numbers in the wrong order.

So now, the only reason that I say it's almost done is because of the error checking.  There is a lot of validation that I'm just skipping at the moment.  The code is riddled with "TODO" comments marking where additional validation needs to be performed.  I may or may not have a chance to get back in and do those things, so it's possible that the version that I just checked in is the final form of this assignment.

PA3 is underway

I was stuck at the airport with a three-hour delay.  What a great opportunity to start working on PA3!

I had no internet access to get to the Winsock documentation, but I did have my 3G smart phone.  I typed in the long, ugly, complicated URL from the assignment write-up on the unwieldy little keyboard and was able to read the tutorials.  Since I couldn't copy and paste from my phone into the IDE, I had to type the code by hand.  Inconvenient, but probably a better learning experience.

I believe that I was able to get most of the code in, but there was no time to test it.  I hope that I can try to run and troubleshoot the code soon.  I'll post again when I do.

I think PA2 stands for Pain in the A__ 2

PA2 is finished at last!  Here's how it went:

The first time I sat down with it, I took care of the Dog and Cat.  Pretty simple, as explained in my last blog post.

The second session was focused on the Bird.  It went through a few different iterations before it ran without throwing a debug assertion failure.  Getting the output to look right was simple.  Even the memory addresses were showing different objects as appropriate.  But it threw a debug assertion and corrupted the heap every time.

Having reached the end of my rope on the Bird problem, I decided to go ahead and write the code for the Fish. Due to the Bird's assertion failure, I was unable to test the Fish, so I just left the code as it was until I had a chance to fix the Bird.

I took a break from the whole thing and spent an afternoon at Yosemite National Park.  I think the fresh air helped, because when I returned to my hotel room (bed 'n breakfast actually), I was hit with an inspiration.  The problem with the debug assertion failure was a simple and stupid one -- as it turned out, I was just doing a couple of things out of order.  I was clearing out the string before deserializing the object rather than after.  Therefore, the original pointer address was being replaced rather than a brand new string being created.

To top it all off, the code I wrote for the Fish worked on the first try!  Yay!

Finally, a chance to work on PA2

I finally got a chance to start working on PA2 today.  I wanted to wait and start it after I had a chance to watch the entire lecture, but I'm realizing that it would be impossible to do so, since it has taken me three separate sittings so far to get through the first hour and a half.  I really hate my workload at the moment, and my unreliable internet connection at home certainly doesn't help matters.

OK, enough whining.  There's work to be done.

I loaded up PA2 and ran it, and as expected, one test passed and four failed.  I added serialization code to the Dog class, and it passed the test.  I added serialization to the Cat class, and it passed its test too.  Then I optimized the Cat serialization by reordering the data members to make a smaller packet.  It worked.

Then I started working on the Bird class, and noticed that the serialization will not be quite so straightforward since it contains a string.  This will require some time and thought, neither of which I can spare any more this evening.  So I will have to wait until Tuesday to try out my strategy for this one.

I only hope there's enough time on Tuesday, since it will be my one and only chance to work on it before it's due. This is where things get tense and exciting, eh?

PA1 -- The Spacewar part

Spacewar compiled and ran without any issues whatsoever.  I was annoyed by the controls, and I think there must be a better keyboard configuration.  I'll have to put some thought into it.

PA1 -- The C++ Part

I'm not entirely sure if my implementation is exactly what the assignment wanted, but the results look good.

Getting Started in SE558

This blog will be devoted to my work in SE558: Architecture and Design for Multiplayer Games. I've only made a couple of networked, multiplayer games, but they weren't real-time action games. So, I hope to get some great and valuable experience in this class by doing a new type of networked game that broadens my skills in this area.

These first few weeks could be a little rough, because I'm currently overbooked at work and it's taking up all of my days, nights, and weekends.  But in three weeks from now, I enter my annual non-teaching session, so there will be nothing on my calendar other than this class.  I can't wait to get there, because the pressures I'm under at the moment are anything but pleasant.

Still, I'm eager to get started on this class. I loved the last class I had with Professor Keenan and I'm really looking forward to this one.