Gauntlets of Recursion (+3)

Times, trials, and turbulence.

Bridging the gap between client and server.

The “Fun Stuff” Begins!

It seems like the quantity of updates to the dev-journal are fairly proportional to how exciting the development I’m currently doing is. And, I suppose, it should be. But it does make for large lapses of quiet when I’m working on less “visually notable” aspects of Skirmish. πŸ˜‰

Nearly all of my work lately has been focused on getting the communications between the game and Master Server operational. This meant lots of low-level socket and TCP/IP code using the (moderately convoluted) Java NIO API, and getting the connections working the way I like both client-side and server-side. In short: a lot of nitty-gritty code that needs to be written for correctness and speed efficiency, and doesn’t lend itself well to screenshots. πŸ™‚

After spending a good chunk of the day finishing this work up, it felt very nice to realize that I had some more interesting features and goals to work on, now that the under-the-hood labour is (hopefully) out of the way. Small but more enjoyable things, like cleaning up the mini-map and making some improvements to the game timing logic.

With the underlying network code written, it was time to finally bridge the gap between the client and master server. I’ve had the MySQL back-end code and account handling logic sitting around on the master server for a while now, so it was nice to get the chance to see if it all actually worked properly.

The first order of business was to create a window for players to log-in with. Just a small minimalistic dialog to facilitate account creation and logging in, to lead into the main “lobby nexus” window soon-to-come, where the player will be able to manage their account, join and host games, and modify local configurations.


(Logging into Project Skirmish!)

Β Β Β  While creating the dialog, I gained some more appreciation for the work I had to put into the GUI system while I was developing Battleforge. It was a challenge to put it together at the time, but it’s certainly paid itself off in spades at this point. It was a snap to toss together this dialog, with automatic component centring/arrangement and the like. I had to rearrange some logic with the actual dialog system to function properly with stacked dialogs (which Battleforge never needed), but all is well now. Secondary dialogs pop up when the user logs in (or fails to) or creates an account, properly phasing out control from the underlying log-in dialog.

Β Β Β  Like I said, the Master Server is totally functional in terms of allowing clients to connect and create accounts, but a lack of a full-time server to host it with dissuaded me from bothering to put anything online for public to play with just yet. Not that reserving your account name in advance is really a big deal for anyone but the most hardcore of readers. πŸ˜‰

Β Β Β  As always, thanks for reading. I’m looking very forward to writing about the account system in more detail, and showing the development of the main lobby windows.

6 responses to “Bridging the gap between client and server.

  1. The Visible Man April 13, 2008 at 10:10 pm

    Sounds like some great progress! I’m glad things are moving along and you’re done with most of the back-end systems. Hopefully the remaining work will be more visual so we can get some more screenshots out of you πŸ™‚

    Can’t wait till Milestone 5, keep it up!

  2. Dean April 14, 2008 at 3:20 am

    Looking forward to it as always!

  3. ravuya April 14, 2008 at 10:35 am

    Care to post a bit about how your GUI system works? I don’t remember seeing anything about it previously. I’ve come to the conclusion that having the UI build itself makes a hell of a lot more sense than handling resizable dialogues myself.

  4. zyklon April 14, 2008 at 5:46 pm

    hey, looks good. I need my username!!!

    I am actually working on setting up my server/linux box atm, you can have me set it up as the master server if you like, its going to have 768mb ecc ram, in it.

  5. Stephen April 15, 2008 at 10:21 am

    @Ravuya: Sure. At the base is the GuiManager, which maintains all of the GUI-related graphical resources (window pieces, fonts, etc), and all of the Windows and Dialogs present. There is a base Component object from which all GUI objects derive from, which offers all of the basic functionality common to all GUI objects (centering/alignment stuff, detecting mouse-over, adding/updating/rendering children, etc). My GUI forces all non-Window/Dialog components to be within a Window/Dialog, just because it’s easier to just tell components to follow the style/rules of their parent in general (ie. the Window/Dialog). My windows cannot be resized or moved on the fly (although the latter wouldn’t be hard) for simplicity-sake. The contents of windows are somewhat hard-coded, since they can’t be resized/moved, but auto-centering and padding functions make it pretty painless to position UI elements fairly elegantly. I also don’t have a traditional ‘message pump’, instead just a generic EventHandler interface that lets the parent respond to events by a child (much like Java’s AWT). I’d be happy to answer any further questions, if anything is unclear. I’m also quite open to suggestions; I don’t feel that I put as much planning into the GUI as I could have — it sort of ‘grew out’ of Battleforge. πŸ™‚

    (Gah, monster paragraph!)

  6. brian.ripoff April 15, 2008 at 5:30 pm

    That could’ve been a whole entry Steve!

    It still could be… πŸ˜‰ I love that kind of explanation blog. Its always interesting seeing how other people do these sort of things.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: