Frequency of Updates

It’s been pretty quiet around here for the last few weeks, but I’m still hoping to increase the frequency of my updates as of now. I’m becoming more or less adjusted to being back in classes, and have my weekly course-load pretty comfortably gauged.

Master Server

It brings me plenty of pleasure to say that the initial version of the Master Server is ready to roll. Finally both the Master Server app itself and the game client’s interface to the MS is in good enough shape to be warranted as “done” for the time being. There are still more features and additions (on a more minor scale) to come in the future, but all of the core functionality is solidly implemented. Account creation, logging-in, character management, game hosting, receiving game listings, and user configurations are all in working order.

The Next Step Toward Being “Playable”

The only real obstacle left is getting the Master Server up and running 24/7 on my in-house server. Since we’re using a pretty standard residential ISP, the option of a static IP isn’t feasible. What this means is that the IP address of the machine will change every so often (although it hasn’t in over 2 weeks so far), which would render any hard-coded IP in the client worthless. I’ll be putting it up anyways soon for the sake of having it up, though.

Once the Master Server is up, I’ll release the latest version of the client (the completed Milestone 4) and put up a Webstart link. Technically, users will only be able to create accounts, log-in, and perform character/settings management, but it’s at least something. You can at least reserve your favourite character name in advance before Beta testing.

Milestone 5

Milestone 4 encompassed the development of the first version of the Master Server, and the first iteration of the game client’s interface to the Master Server. Now that I’m comfortable with where it stands, Milestone 5 can begin. It will focus on arguably the most crucial component of all in Project Skirmish: the game networking. Development will focus on writing the server and client for the hosted games themselves, and more actual game logic to support real games.

This entrenches upon areas like movement prediction for players, managing concurrent physics-simulated Props in the game world, player health and deaths, adding more weapons/items/content, and finally: Alpha testing. I’ll be posting around some websites asking for some testers, if enough of the local folks I already know here aren’t interested.

I’m planning on talking a bit about the networking model I’ll be using for Skirmish, which is largely inspired by the Quake 3 networking model. Until next time.

Things have been particularly hectic lately, with my co-op term coming to a close, classes starting tomorrow, and the lengthy work-term report that I’ve spent the weekend frantically composing. Things should balance themselves out in the coming week or so, and Skirmish development will resume once I get a solid hold on my upcoming homework load.

Since my last update, I’ve finished the User Settings/Configuration set of menus and windows. This means that the only item left before actually game networking (ie. the game actually starts to become “playable” online :)) is the game host tracking on the Master Server’s end. Exciting waters lie ahead!

A little while back, I briefly spoke about my entry in my university’s gamedev club’s 24-hour competition. All three judges have finally posted their marks and opinions of the entries, which you can view here, as well as the entries themselves. A huge congratulations to everyone who took part — it was a whirlwind that I can wait to help organize again this summer.

For anyone looking for a quick link to my entry, Circuit Runner, you can download it at: Circuit Runner.

Enter: The Lobby

User interface design and programming offer lots of interesting challenges to the hardy UI developer.

First of all, let it be said that I’m not an expert in UI design or development. Certainly not a guru. Perhaps “proficient” could be applied without too much wincing on my behalf.

UI design and development is probably the main area that I’ve put the least effort into in my previous game projects. I’ve almost always opted for highly streamlined UIs that are low on flexibility and focus entirely on just providing the bare essential functionality to the user. I won’t claim that Skirmish is leaps and bounds ahead of that, but I’ve certainly put in a lot of thought and effort into making a much more comprehensive user interface for the players to use. This is partly because of guilt for lackluster UIs in previous projects, and partly because, simply put, Skirmish requires a lot of interaction with a UI from the player.

The “Lobby System” represents the one of the most UI-intensive portions of the game, with the others being the map editor (Battleforge) and the one-day-to-come Equipment Shop. The lobby is the nexus point for the entire game, where players can manage their characters, list and join games, host games, and configure their local settings/options. There’s a lot that can be done, so my goal has been to make it as painless as possible on the user, while trying to avoid the necessity of large overhauls on my GUI engine.

Note: All screenshots in this entry are UI only, without logic or content yet implemented. Any illusions of content are just hard-coded data for example purposes.

I’ve opted for a Pane-based system for the lobby, with the Character List being fixed on the left, and the larger pane being able to flip through three other panes that allow the player to access the major components of the lobby system.

Both of the shown windows are fairly streamlined to fulfill their purposes with relative ease: The Character Window allows for creation, deletion, and info-display of the characters associated with one’s account. It’s not implemented yet, but a mouse-over on a character in the list will present a pop-up info sheet of that character’s stats and information. The Join Game pane presents a list of active games in-progress, and the options to join, refresh the list, and retrieve more detailed information. The reason that I chose not to have a mouse-over feature for this as well is because the client will need to literally query the server for more detailed game information over the internet, which is far less than instantaneous. Still, this might change yet.

The Host Game pane is the one I’m the least happy with. Overall I felt very constrained for space in the tiny pane I gave myself, but I remained steadfast in my decision to keep the Character List present on the left side. I really didn’t want a separate “Characters” pane that would require the player to select a character from that pane to decide what character to join/host a game as, first. My own GUI engine has limited me insofar that EditBoxes don’t support horizontal scrolling text or word-wrap across lines, so the grossly long “Info Text” component was necessary.

Again, not implemented yet, will be a pop-up similar to the one described for the Character List that will appear when the player places the mouse over a map listed in the “Map List” ListBox, which will display map information, and a thumbnail image of the map itself.

Last is the User Configuration pane, which allows the player to customize local settings. This includes visual/mouse/interface options and key bindings for either the keyboard or mouse. Plans exist for gamepad support one day down the road.

This set of panes seemed like the simplest to design. I modeled the Key Bindings pane after just about any AAA FPS published in the last 10 years, and used a simple table to handle the keys. The Options pane still feels pretty empty because of the early stage in development the game is still at; it will fill up as progress continues.

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.

Cyberspawn

I have been getting some solid work done on Cyberspawn, which I mentioned a few times back February. Development on it has struck up again, with my Skirmish interest waning a bit at the moment. It’s been a lot of fun so far, and it’s particularly exciting to work on because I’ve never really explored 3D game development, and it will (eventually) be my first game with a true focus on atmosphere and storyline.

The most recent item has been the conversion from software raycasting over to OpenGL.

Aside from the bilinear texture filtering and large FPS boost, the changes are very subtle. The conversion has just been a verbatim change-over of functionality from software to OpenGL. Since the project has made the transition from “toy project” to “making this one happen” status, I’m opting for a more practical approach to writing a 3D game than old 2.5D raycasting techniques.

Linux Adventures

I’ve been continuing my fun quest of becoming better acquainted with Linux, and have been using it 90% of the time over Windows for the last few weeks without issue. Aside from playing the “newer” games, and Visual Studio, I don’t feel any major force pulling me back towards Windows.

Also, recently I made the move from Gnome to KDE for my desktop environment, and I can candidly say that I won’t be looking back any time soon. It feels overall much more established, polished, professional, and above all, functional.

Upon deciding to move my development over to Linux, the next big task became finding a good IDE or text editor, and learning how to use makefiles. I had previously been using a lame script that I wrote, which would simply recompile ALL source and relink after every single change. Hoy was that slow!

As the astute reader might be able to discern, the above screenshot was taken from within KDE, and I now have a solid development environment for Cyberspawn established on Linux. I’m using jEdit as the text editor, which has a vast plug-in system, enabling project management, buffer tabs, a built-in console and error/warning log, and other excellent Visual Studio-like functionality. I’m surprised at how happy with it I am, and that it’s easily rivalling my productivity — perhaps beating — from back in Windows with Visual Studio.

(Development environment)

In short, I really strongly recommend looking into sliding over to Linux for your desktop and/or development needs. Not from an esoteric Linux elitist sort of viewpoint, but just because it’s such a hugely viable platform for any user willing to learn a thing or two. I can only see my experiences here as being huge pros on my future co-op terms and beyond.

Question to the Reader: What OS do you primarily run? Have you ever tried a Linux distribution? Do you plan to? Have you ever killed a man with your bare hands? Do you plan to?

Master Server

Progress has been moving along slowly but surely with the master server. As a recap, the master server will be a single instance app that will maintain a database of all player accounts, characters inside those accounts, and servers being run by players. Players will be able to log-in to the master server with their account credentials and view, join, and host games.

The master server itself is proving to be a fairly easy job, but the main work is on the client’s side, where the visual interface and logic for interacting with the master server will be done. The master server currently allows users to connect, create accounts, and log-in. My current task is doing the dialogs and networking work on the client’s end to allow players to perform these first-most tasks.

I’ve been restructuring a lot of the main game logic to better support the new ‘lobby’ interface, whereas I settled on having ‘Sessions’ of different types to accommodate this. A session is a fancy word that means that the player is either playing inside of a game, or inside the lobby system (finding a game or viewing characters), or even in the map editor. The game will be able to switch between sessions seamlessly, making for simpler transitions and, inside the code itself, a much nicer unification of data structures. In short, this will make it easy to implement transitions like going from the lobby into a game after clicking ‘Join’, or testing a map you’re working on in the map editor by switching from the ‘editor’ session to the ‘game’ session and loading that map.

Screenshots soon.

Game Competition

I’m still working on getting the judges together to do the actual judging and scoring for the game compo entries, but hope to get things worked out very soon. I’m also trying to orchestrate getting the pizza quantities handled and delivered for the ‘Game Showcase & Final Meeting’ for the gamedev club at my uni. We like to get everyone together at the end of each term to show what we’ve been working on, and enjoy some pizza. I showed by voxel renderer last term, in November, but will be showing some stuff from Skirmish hopefully, like blowing up crates with the rocket launcher. Always a barrel of fun!

EDIT: I intentionally haven’t posted a download link to my compo entry yet — I’d like to wait until the judging is done and instead proffer a link to the entries/judging results so you can enjoy everyone’s game.

I’m just about to hit the bed, hard, but wanted to drop a quick entry in here. The 24-hour gamedev competition is over, and the judging will happen in the coming week. Below is a little screenshot from my entry before I collapse for the night.

And now is a time for rest. 39 hours without sleep has a way of creeping up on a fellow.

I’m just getting my stuff ready for the competition (mentioned in my last post) now. We’ll be taking over a computer lab in the Math Building (MC 2060 if anyone in UofW is reading ;)) for the next 24 hours or so. I’m planning on writing periodic mini-entries to myself as I go, and hopefully turn my experience into a mini-article afterwards.

Wish me luck!

Project Skirmish: The Master Server

Minus some minor grievances about the editor, Battleforge looks like it was rather well-received. I’ll be gradually working on tweaking things, fixing bugs, and general sprucing-up over the next while, but my main focus is now on the next big auxiliary component of the game: the master server.

Skirmish will function like many of the popular action games out there, whereas one main server will manage a large list of player-hosted servers, allowing players to search through these hosted games through one central access point. This presents the least bandwidth strain on myself, and doesn’t physically limit how many players could potentially be online at once.

The Master Server will act as a hub, of sorts. When Skirmish loads up, it will present the player with a login screen, which will establish a connection with the master server. After that, the player can create/delete/manage their Characters, refresh the listing of currently active games, customize their controls/settings, or even host games themselves. A chat feature might also be added, depending on the bandwidth load it presents.

The Master Server will be also written in Java, and will use a MySQL back-end to manage accounts, characters, servers, scores, and just about everything else. I’m finally putting the book I received at Christmas, Learning PHP & MySQL, even though I’m using the Java J/Connector MySQL driver rather than PHP. This is my first time delving into relational databases, but it’s been nothing short of an excellent learning experience. I’m very glad I narrowly chose this route instead of resorting to flat-files.

24-Hour GameDev Competition @ Waterloo

After a couple of weeks of planning, myself and one of the other UW GameDev Club executives have organized and launched a 24-hour gamedev competition at our university. It will be taking place this Friday at 8PM and run until Saturday at, you guessed it, 8PM. A theme will be announced before we begin, and judging will take place in the days thereafter.

I am supremely excited for what events unfold this Friday, and eager to see what games see completion by the end of the competition. I haven’t added a new finished game to my portfolio in nearly a year (gah, has it been that long?), so this is a golden opportunity.

We’ll be taking pictures of the entrants’ games as they are developed, as well as pictures of the entrants themselves as they grow more and more sleep deprived. I’m bringing a pillow just in case. We’ll be ordering pizza sometime part-way through, and generally be having a great ‘ol fun time like any crowd of gamedev-loving developers should.

Don’t forget your pillow!