Working!

It's by no means perfect, but it's mostly working, with a few glitches!

Glitches:
Thrust doesn't display fully FIXED
Win-lock (game won't return for another round) FIXED
Double-Killing? two lives decrement at a time FIXED
Client-side fences animate strangely FIXED

Other than that, the game is fully networked!  Awesome!  A few easy (well, should be, knock-on-wood) bugs to get through and the game is set!  I'm really excited, and I can't wait to apply what I've learned here to actual games (or games that I create, rather)

I learned a few things:

Client/Server can be a bitch.  You have to be careful with what you send to whom and how they apply the changes.  I guess my first approach was very p2p, but I ended up switching halfway through to the more "common" client/server approach, which means all processing (essentially) is done on the server minus input which is applied on the client side.  Relevant or important events are triggered on the server and sent to the client.

However I had my queues set up to run exactly the same, which resulted in some strange errors and doubled or  echoed creation going on.  If I could go back and do it again (unlikely with my workload) I would separate the server queue implementation from the client queue implementation.  That would have saved me a great deal of trouble.

P2P management can be very hap-hazard, ownership has to belong to specific machines and that needs to be explicit, else all you really have is a bunch of very similar simulations running simultaneously, which is fine until your images and game states start looking different.  You'd need either every piece to be owned by a specific machine and have a quick-n-dirty abstraction method to make quick work of such a structure, or some way to keep ID numbers synced between multiple machines doing their own creation/deletion locally that needs to be broadcasted to multiple machines.  This is why I switched from an organic P2P to a Client/Server model.

And now back to those bug fixes.

EDIT:

W00t! All bugs fixed! Now, if I have time, to fix prediction!  The way I did my code was to send data only when absolutely necessary (only when input has been read or collisions have triggered, etc) which is awesome, but also not so much.  It means the games run "apart" until an event is triggered and something is sent, which results in slight rubber-banding I would like to be taken care of with prediction (a loose model, basically targeting or lerping to desired values)

Kickass.

Rage

Not the game, the real and burning feeling inside the pit of my stomach at the moment.

I have a somewhat sloppy yet functioning lobby, and the game is set to be networked and tested, just in time for me to figure out that I have no access to a second computer.  I cannot run my final project, I can't test it, all I can do is sit and stare at all of my hard work sitting in a lobby, waiting for someone else to connect who never, ever, will.

Every computer I've tried at the CDM requires an update to windows live, and I can't update them because I don't have administrative access. All of the school computers are "locked" from downloading programs and receiving updates.  Which is the only way windows live will let me onto windows live.  So I am stuck in the muck and mire of red tape and bullshit.

What a way to end the week.

Currently looking into every option I can, but I don't know where any of it will go.  Most of my friends use Macs, those who run PC's are either gone at the moment or require heavy use of their own PC's and I can't monopolize on their machines to do my testing.

Just wonderful.

Mo' Work No Time

I've now moved beyond the queue-driven part of the assignment.  I just recently was able to achieve a second account on the XNA creators club with which to actually test my game, so for the majority of the past few weeks, all of my networking has been purely theoretical.  Which is quite worrisome for me, but with any luck I can plug it into a separate computer tomorrow and the universe will not implode and my laptop will not set on fire.  If I'm really, really lucky, maybe then the game would even run.  But that's stretching things a bit.

Theoretically speaking, I even have prediction in my current "networked" game.  If a remote player receives a ship update, it's local copy will have a "desired state" that gets updated, and then the physical state interpolates (A very, very simple version of Dead Reckoning, I recon. [See what I did there?])
It's not quite so simple, though. Extra prediction is added in, when packets come across and set new states or create new objects (at least I think I have this for new objects? Making  a mental note to go back and check that) it takes the estimated trip time (which XNA so nicely provides) and moves the given state forward based on the trip time so that the received state is as close to the state back on the original sending machine as possible.  Then both the desired state (with the last given input) and the actual physical state are updated side-by-side while the psychical state continues to interpolate to the desired state (in terms of position, velocity, acceleration, rotation, rotational velocity, the whole shebang)

So, at the very least if I turn in a pile of steaming waste at the end of the quarter, at least I had my prediction model running, and I guess that's worth something?

I also almost forgot (since I'm not actually networked yet, you see...) about object creation/destruction, which I have now somewhat-sloppily yet successfully packaged into the game.  I'm very uneasy about how it works only because it seems a bit to hard-coded for my liking, I would appreciate a more flexible and abstracted system, but given my time constraints and my still-growing familiarity of OmegaRaceX I just first need something to work before I can then go back and make everything all nice and fancy looking.

I just have to also split time between this project and creating a particle Shader for Real Time Graphics.  I found some source code that should be able to help me with the setup of that project, at least, but this next week is going to be killer... hopefully not literally.

Anything else I've added? Well, not that I can think of at the moment.  I'll finish up the lobby tomorrow and plug this sucker in and see if it works.

Fingers crossed, right?

-Kevin

Switchin' and swizzlin'

I still haven't sent anything across a network, yet.  At least not for OmegaRaceX.  And I probably won't get a chance to do so for some time yet.  That's the problem everyone having Macs.  Even my roommates have them, and I can't find anyone to test with/against.  I did, however, re-vamp the Data-Driven queue to be "state-based"

It ignores commands of a lesser sequence number (meaning I can "spam" messages in case any are lost without major concern) and it sends state information (position, velocity, rotation, etc) instead of event based information (such as input info) which hopefully will help and enable very quick networking.  There are still a great deal of issues to solve, but there's no real one way to go about doing so.  There's hardly a "way" at all, it seems like "whatever works" is the way to go for networking.  Or rather, whatever works best, I should say.

I'm leaving for home this weekend, hopefully I can drum up somebody running windows back there to begin the testing.  I'll have more updates by this weekend, somehow, regardless.

I'm thinking about adding in extra information for prediction.  At this point, though, everything is funneled through one data type, at least, which is convenient!

Updatez

So collisions wasn't too much a hassle to resolve.  My solution is by no means elegant or hyper-efficient and it will have it's bumps in the future to come, but I ran across some weird sections of code.

For collisions, the previous programmer copied the entire list of objects into a separate array of SceneObjects and then used a foreach() to loop through the scene objects and checked against each object.

The copy couldn't have incurred too much overhead, since each SceneObject in the list was a reference to the SceneObject in memory, but the double-checking is a strange way to go about doing your collision checking.  The game is small, so that could be a justification for a redundant collision check, but when I started queuing my collisions it would double-trigger collisions and cause really terrible behavior in the game.  It was a simple fix,
(a double-for loop
for(int i = 0; i < sceneObjects.Count -1 ; i++)
{
for(int j = i+1; j < sceneObjects.Count; j++)
{
//stuff goes here }
} )

so I guess it must have been a simple oversight, unless there's some tidbit of information I'm missing.

But I'm going to go ahead and say that was just bad collision code practice and leave it at that.  Now the game is "data-driven" with the exception of win/lose screens, I believe.  All input, creations and collisions are funneled first through the InputQueue, and are processed at the end of every loop.

My unhappy moment of the day was in the collision code I changed the scene objects to be somewhat based off of unique game IDs. Which is fine for the most part, until you have to loop through your entire list to find an object of a specific ID.  (Actually, make that twice, to find the first colliding object, and then the second)

This was done because once I start having to send information between hosts/end machines I won't be able to send references, the two games will have to have some common denominators (ID numbers)
But even keeping those ID numbers synced is going to be a fun challenge in of itself.

This Saturday sucks.

The Beginning of the end (Data Driven Omega Race X)

So far today has been a smashing success.

And I mean that with the utmost sarcasm.  The task before me (Make this game multiplayer) is significantly more daunting than I first imagined.  This morning despite sickness and an overall unwillingness to do anything, anywhere, ever (it's been one of those days) I managed to at least convert the game to it's "data-driven" state.  I'm not QUITE all the way there, however, seeing as how I've only gotten player input to be "data-driven."

Up next is managing lasers, bombs and walls to all become data driven as well.  It's not so much difficult as it is tricky.  Knowing what to put where is half the battle.  Coding everything to interact cleanly is the other half.  And that's when you have to start sending things across the interewebs.  It's going to be a very long quarter, especially if I don't get any better and kick this sickness and funk.

I didn't do a whole lot in terms of making the game data-driven.  Created some specialized structs and classes and an generic input queue handler, and then hijack the player's "GetPlayer1/2Input()" functions to direct all of their input to the queue instead of the players themselves.

Now I will do the same for "fireLaser()" and "layMine" and finally in there somewhere I'll hijack the collision systems after I learn how those work so that everything in the game (minus main menu stuff, I'll worry about the lobby later) is funneled first through the queue.  There's a lot of work ahead of me yet.

I must say, I've been complaining about plug-n-play coding at DePaul for some time now, but now that I finally get a taste of some real coding challenge, I'm almost feel too lost to start.  Not much in the way of guidelines or instructions, just "go 'fer it"

Hey, at least this time around I'll be actually learning something.

-Kevin

No Dumping

Just got out of class, about 45 minutes late, actually.  Keenan has the best stories, I can't believe I haven't had him as a professor until now. I'm feeling a bit jipped about it, I'm about to graduate and I just got to take a class with arguably one of the most knowledgeable professors at DePaul who worked in the industry for many years and has more awesome and hilarious stories than you can shake a stick at.

This class is great.

On the other hand, we discussed the purpose and meaning of dump, and apparently I forgot to include sequencing numbers in my inter-leavened queue.  I actually did it in a way that was "not good" namely I had two very separate queues and I just popped things on/off the stack in each different one depending upon a third queues enumeration of the type.  It worked, but it was definitively not the best or most ideal system.  I re-hashed that tonight based on the examples that we covered in the beginning of the class to include a queue of special structs that held queue info and "do work" data.

Speaking of which, I have to go re-save my output.txt
Oops,

Later,

Kevin

Bein' Brain Dead

Well I spent about the past hour on the latest project.

It should not have taken me that long.  The actual programming part of the assignment  took me about 20 minutes, maximum.  The worst part was I was stubborn and refused to adhere to professor Keenan's naming standards in our Test.cs, which means that I spend the majority of my time mindlessly changing specific names repeatedly just so the test code ran with the classes I already had.

I don't have any idea why I had my own names instead of sticking with what Professor Keenan's names. My brain is fried and for some reason it seemed like the logical choice...?

The assignment itself was really easy.  I don't quite get the whole process, the concept of data driven development is really pretty sweet, but the assignment itself felt very underwhelming.  The good news this is the last isolated programming assignment, next week we will get into more game-based programming assignments soon enough!

I look forward to that.

In the meantime, hooray for getting homework done ahead of time!

-Kevin

Success by the seat of my pants

Currently I am a very happy programmer.

And a happy man.

I finished the server code in an afternoon, which isn't anything to be proud of or ecstatic about, there are most likely hundreds upon thousands of programmers who could do more in less time.  However, I wasn't exactly inspired during the writing of the program, so I found it difficult to concentrate at many points during the coding.

But the main reason I'm so happy is because I was able to do this in one shot.  Often times when I being a program, I will complete a section of code that should work, only to find out that it not only doesn't work, it usually works in a way contrary to the specified purpose.  Iterative programming is the name of the game, however I tend to come up with a game plan and try to execute it in one sitting without having to test every little tiny bit.

I understand that this is how games and programs should be done.  Make one piece work, save, submit, and then make the next tiny change.  However there comes times in my coding where I get on "a roll" and I feel that if I stop I will lose momentum and steam.  I'm stubborn when it comes to things like this.  I could be a lot better at iterative development if I would give it all of my attention instead of splitting my coding time between "this should work onto the next topic without testing" and "get one thing working at a time"

But today, at least, it paid off.  I knew what the code was supposed to do, I was careful in my implementation, and when I went to run my program, it worked.  Not the first try, but on the third when I fixed a casting error.

I would say this is an unusual case because the program was so linear and inter-dependent it didn't really open itself up to iterative testing and development.

I know Professor Keenan would call bullshit, and I'm 99.99% sure he would be right.  Everything can be, and should be, tested piece by piece.

But every once and a while it's nice to have a bit of validation that I understand what I'm doing and when I don't make tiny errors that the core of my programs still work and work well.

The best part about all of this is, though, that I'm ahead on my homework.  I'll actually be able to relax this weekend.

Knock on wood.

-Kevin

Easy Peasy Lemon Squeezy?

Well, um, I'm not really sure what to say.  From what I had been hearing the last part of this assignment was supposed to be more difficult?  I guess having taken Comp Sci II I'm in better standing for serialization, or at least the application of it.  This entire assignment quite literally took me no more than about 30 minutes if you add the times together, mostly because I forgot to bring my notes on how the files were arranged, and I mistakenly started changing the order of both the constructors initialization lines AND the actual order of the constructor's passed parameters.  That was FUBAR.

That's the thing about programming, no matter how good you get, now matter how hard you focus and try, you are going to most definitely hit snags in your work.  After contacting my good friend David about my difficulties (at one point I couldn't even get my breakpoints to trigger?) I realized my mistakes, rectified them and quickly re-adjusted, and finished off strongly.

Now I kind of wished that Professor Keenan had given us something a little more challenging such as serializing dynamically allocated data structures?

Of course that's probably wisely saved for another stage in the class. As long as you understand the simple, small things,  you can understand the working of a more complex beast.  As long as you aren't thrown to the beast, first, you will always stand a very good chance.

So... how 'bout that weather?

-Kevin

Serialization

Still working on the last serialization problem for the second homework assignment, the first three were pretty easy, pretty simple, I've done much the same in the previous computer systems II class that I've taken.  Unfortunately most of my time has been taken up with Calc II homework.  It's long, tedious, and the teacher for that class is not what I would have hoped for, it's hard to understand her and she makes a good number of mistakes, which isn't conducive to me learning anything.

For the serialization, it was all pretty simple, re-arranging classes to be well-aligned (no, this isn't some psychological or therapy session for classes)  and then passing these classes into character array buffers. The only tricky part is when the class contains pointers to other objects, which is when you have to start adding in whole other objects to your serialization/deserialization.  The worst is when you start dealing with other data structures such as arrays (simplest case) and then vectors, linked lists, and etc.  Don't even get me started about maps and dictionaries.  Luckily Professor Keenan hasn't given us anything as headache-inducing as trying to serialized a dictionary of information.  That wouldn't be fun to put together on the other side of the socket!

I will post more later, but for now I have to get back to this calculus work.  I wish I hadn't been forced into taking this class... a year after taking the first one.

Yikes.

-Kevin

F1rst

Hey! Another blog! This one for networking of games.  This is going to be an exciting class, I can't wait!  Finally have Ed Keenan as a professor and I get to learn all about networking!  And add this to David and I's Xna engine!

The first lecture  I was scrambling to get all of the notes I could possibly manage to scribble down while he was talking.  It's old hat stuff to most people, but new to me, and the class finally wasn't being handled with kid gloves.  I've had too many classes whose skills and experiences were so mixed that the classes had no choice but to repeatedly go over the basics for some and leave others who wanted more information high and dry.  It's a necessity, I understand, I've had these conversations with a number of professors, but it doesn't make it any less fulfilling for me.  Now this is a class where I'm going to get in deep to things I don't know, I don't understand, and are quite frightening!  I can't wait.

Funny story, actually, I never wanted to be a programmer.  Never, I was adamant about being a Game Designer (Which I still am, that's my career goal!) One of the professors that arranged to meet with me during my tour of DePaul when I was still looking at schools was none other than Ed Keenan.  I highly doubt he remembers me from our meeting, it was only for an hour or so almost a year and a half ago.  But I remember him. He really impressed me with his description of the degree here at DePaul, and put a lot of confidence behind the program which instilled a lot of confidence in me.  If I remember correctly he laughed when I said I was applying for the Game Design track, he said I should take the programming concentration instead.

Well Professor Keenan, here I am.  Throw your worst at me, I want to be the best I can be, I'm willing to learn if you are willing to teach.

That story being told, this is really supposed to focus on my difficulties with the first assignment.  The only difficulty I'm having right now is getting Professor Keenan to accept me on the Google Group for our class..  I've emailed him once or twice, to no avail.  This blog will never get read if I can't get into the group and link it to my name, so that is a big issue right now.

As for the programming assignments, if you can call them that, I breezed through them with no problem.  In small projects I really enjoy working with pointers, even c-strings, they are fun to toy around with.  I'm crazy because I like pointers, I like having the control of C++, not relying on things such as garbage collectors and such.  C++ has it's downsides, of course, lack of intelisense in VS 2010 is one thing, not language-dependent but IDE-dependent.  And then there's the case in big projects managing your memory gets to be a daunting and confusing task.  Then there's the fact that new and delete/free seems to cost a pretty penny in terms of memory, more than you'd think at first, anyway.  It's no different in a managed language, it's just not a lighting-fast allocation and de-allocation as I would like to believe.  I hope somebody can teach me about memory pools in the near future.

Anyway, the C-string assignment was a walk through a very  short park, a very light slice of cake, or what will you.  Compiling and running spacewar was like shooting a particularly large catfish in a pitifully tiny barrel with an M-60 and several hundred rounds.  I've been working in XNA and VS2010 since I first got to DePaul.

It was just a "see if everybody's stuff works" homework assignment, so I'm not disappointed.  I look forward to the rest of this class!

-Kevin