It’s been a while, so here’s a quick update on what little is being done (emphasis on little).

Right now there’s quite a bit of lobby <-> game communication that needs to be written, and I find this extremely boring. To put this in an easier fashion, I’m making the game servers record and submit game results to the account server – and progress with this is very slow. On a positive note though, clients that are connecting to a game sends their account identity which is then checked against the account server by the game host. Look at the screenshot to the right for further reference – you’re able to see the account #ID and account name of others in your game via the scoreboard. You can still choose any nickname you wish!

A few other things you’ll note from the screenshot is that the rank insignia and title (the TERRIBLE rank title) is displayed next to the player name, along with an XP bar to the right. Below, the player’s current arsenal is displayed – the weapon names displayed in the screenshot are placeholders for the time being, i.e. this isn’t fully implemented. Since the game round hasn’t started yet, there’s also an indication whether or not the player is ready to start. And yeah, the ping display hasn’t been implemented fully yet either. No biggie.

Buying weapons is easy as a pie too. You can either press a key to automatically buy the most expensive weapon you can afford – à la The Seal Hunter – or press another key to bring up the buy menu. This is fairly straight to the point – your current arsenal is displayed (this arsenal limit of five weapons is as you can see also not finished yet), click a weapon or press its number key to purchase and equip it. Weapons displayed in green are those you already own, and those in red are sadly not affordable. And before any of you ask, Überwaffe is a very powerful weapon (something like the BFG9000, only more ridiculous) that I use during testing. Please note also that I’m not very happy with the current look of the buy menu and I will most likely end up making it an itsy bit prettier soon enough.

In conclusion, I’m working on setting up a forum and setting up some integration with this blog, so hopefully a forum opening shouldn’t be all too far away. Thanks for all your positive comments so far and until next time!

One of the biggest new features that I haven’t mentioned in plain text earlier is the addition of online accounts. This is something I am very excited about myself, as it will allow for some rather advanced statistics tracking, which in the end can in some ways help game balancing issues later on.

The account system itself is fairly simple – all you need is a username, a password, and an e-mail address – and you’re ready to go. This account you create for yourself will then be required to use whenever you want to play the game, and it’ll also serve to identify you to other players, as well. Only players using a valid account are allowed to play – so sorry, playing offline will not work. And yes, you need to have access to the Internet in order to play over a LAN, too – there’s no plans of having an ‘offline mode’ for the time being.

On a positive note however, this will allow very extensive tracking of game statistics. Every single kill you make, every weapon you buy – it’ll all be logged for your own amusement later. The games you complete will automatically be submitted and listed online to receive the public envy of the Seal Hunter community – any other person will be able to see exactly when you bought this and that weapon, when that bastard seal slipped by your defences, and just how much experience you gained during the whole ordeal.

… Hold up. Experience? Yep, you will gain experience for pretty much everything you achieve (read: kill) in the game. Experience will allow your player to level up (the maximum level will be 60, and I hope to release the expansion pack The Burning Seal in late 2010), and as you progress, it will also grant you unlockable weapons to equip and use. The idea is to have each player decide on a limited supply of weapons – right now I call this the ‘armory’ – which is a set of weapons that the player is allowed to buy. This is partly in order to avoid cluttering up the buy menu, but mainly my thought with this is to specialize players and the various roles they assume further. (In an indie 2D shoot’em up, too! Tsk, as if.) And just for the hell of it, I’m currently pondering to leave a newbie player with the measly pistol as their single weapon until they level up – but this is a headache that there’s still loads of time to consider in the future. There is actually no experience system implemented into Seal Hunter yet; the backbone is there, but you can’t currently gain any.

This is where development is currently, and please do note that everything in the screenshots above is still in work in progress. Nevertheless, I hope you enjoy them. See you next time!

Or to be a bit more specific, menu coding. The most agonizing part about working on Seal Hunter so far has been to get a decent menu system going, to the extent that I’ve actually been forced to (re)write the code for them a total of three times.

The first time around, I decided to simply go for Allegro’s built-in GUI system. As a feature of the graphics library itself, these were rather easy to implement and “everything just worked”. They looked terrible, but what the hey, that’s of no importance! However, as development progressed, the major issue with this approach was that they were a bit too obtrusive on the engine itself. Anytime a menu is displayed, it’ll run in a separate loop. To put this in laymen’s terms, overlaying menus on top of the game itself was very, very hard.

After realizing that little kink, I decided to try and rewrite the menu engine to work asynchronously from the rest of the game – in other words, being able to browse a menu without having what might be going on in the background freeze up. To put things lightly, this was way harder than I initially thought and in the I had a very unintuitive and rather sluggish version of the original GUI. I probably would’ve settled for this system in the end, but then a friend of mine discovered that these new menus somehow crashed the game for him while running on his system. I spent a fair amount of time trying to find the cause of the problem – probably two weeks, procrastination included – before giving up.

This was the single-handedly most important lesson I’ve ever learned from as a coder, and I feel stupid today for not paying more attention to the this earlier in the course of development. Do not reinvent the wheel. I had a look around for a menu library and ended up with Guichan. Thank <insert name of deity> for it; Guichan was excellently designed and very easy to customize (read: I changed a few window colors) and it was much easier to extend than Allegro’s GUI. The few issues I had were quickly resolved thanks to the library developers and a few searches of their forum. Still, there was a lot to adapt from the remains of the old menu, and this was one of the more painful and excruciating processes I’ve been through with this project.

In today’s news, with most of the menus actually finished up, I can finally focus on the game itself again. Right now I’m working on some of the lobby<->server communication, which I actually enjoy in its perverse ways.

And stay tuned for a look at a new and quite major feature of Seal Hunter.

Whilst Seal Hunter thankfully is a 2D game, there’s still a Z property of certain game objects in order to give the illusion of depth in the scene, and since it’s pretty darn useful to have when it comes to particle effects. This was in itself entirely trivial to implement in 2D back in the day (just offset the y coordinate by the distance the object is above the ground etc etc) – but the difficulty of adding it to the game isn’t what this is about, it’s moreso a proof of how extremely messed up I am.

Like how this was the first method of testing bullets that came to my mind. Yay! It’s a… Oh dear. I’ll happily leave any interpretations of the above to the reader – for better or worse. (And yeah, I know the reflections are closer to shadows in this screenshot. That particular issue was fixed not a long time afterward, soon as I actually realized how the real world works.) Having a peek at the screenshot below, you’ll see the results of increasing the blood amount an itsy bitsy bit and increasing the initial Z velocity of gibs; a frickin’ volcano of blood and meat after killing a single seal. Yeah, I was bored, but it sure looked spectacular.

Besides allowing for the implementation of bouncing weapons such as the grenade launcher and the thrown hand grenades, the possibility to do the jump-onto-crawling-seal-and-crush-the-hell-out-of-it move was added in as well, but this time with a rather major change. In my version of the game, jumping is entirely player controlled, which basically means the jump action is bound to a key just like moving around on the field is. This was mostly due to being too lazy to sync up the automatic jump animation across a network, but it also added a bit of a challenge to finishing off a crawling creature (I might be a terrible player, but I think it’s bloody hard to actually land a jump perfectly). For the curious, you aren’t able to fire your weapon while mid-air either; the reason for this being that weapons with bouncing bullets (again, the hand grenades and the grenade launcher) got way too powerful.

Speaking of bouncing bullets, and to finish this God forsaken post off, there was a rather amusing bug early on related to those that lead to us playing around with it for about half an hour. And yes, that screenshot is very old. Basically, whenever a bullet bounced off of the ice, its Z velocity direction will be negated (so that it will bounce back up after going downwards) with a loss of speed as well. This was accidentally also applied to the X velocity (the horizontal speed and direction of the bullet), which lead to bullets that got ‘stuck’ after a few bounces, becoming stationary on the ice and not disappearing until an unlucky enemy walked straight into them. Oh gee, mines! Hilarity ensued, and that’s all there is to it, pretty much. Was fun while it lasted. ;)

At first, implementing a multiplayer system beyond the network code itself seemed a rather trivial task – I had been given a game concept already proved to work quite well. But the further this project progressed, the more complex did the actual implementation of multiplayer turn out to be, and I’d like to mention a few of the difficulties that I faced (and still am facing) related to this.

Excessive co-operation

Imagining a bunch of players standing at the far end of the ice, each covering a portion of the screen in minigun fire, made me rather aware of this relatively big problem at an early point, and sadly I haven’t been able to test this very extensively as of yet. The current plan is to allow a maximum of four active players at once, so as to not crowd the icy field too much.

Difficulty scaling

In the original game, the difficulty in co-op mode was ramped up by increasing the rate at which seals appeared. This is currently the same method I am using as well, but finding the exact formulae for this is not an easy task, and would also require thorough testing. The problem with having many enemies is that splash weapons such as the M79 or the grenades may easily become overpowered and possibly greatly impede the money income of a merry grenadier’s companions. Since the actual field of play in Seal Hunter is bigger than that in the original, modifying the height of the field dynamically based on the number of players is also an idea that I’ve been meaning to look into – for example, keep the field the original size with 1-2 players but increasing it to its maximum as the player count increases further.

Round structure

Before a round can start, all players ingame must signal that they are ready, and only then will the actual game start. But what happens if a player joins while a round is still in progress? What happens if a player leaves? The current solutions to those issues are to force a joining player to spectate until the round is over, and if a player leaves mid-game the enemy spawn timers will dynamically adjust to suit the number of players still there. And any money the leaver earned, or any weapons that he bought, will be lost forever. I’m not entirely happy with this second solution, but it’s simple. Again, further testing will prove just how good this concept might be.

If any readers would have any alternative ideas to the problems listed above, feel free to give me your input below. Thanks!