Game Design, Programming and running a one-man games business…

Running to keep up

Posted on October 1, 2011

About 8 years ago I was chatting to the receptionist at a games company I worked for, and she was telling me about a conversation she had recently with the lead coder (and general all round engine god) of the company. He had been working late (as usual) and looked up at her, a bit vacant and said “I can’t handle this any more”. By which he meant the long long hours of coding, coding, staring at a screen (he had 3) and pouring over complex algorithms to get the code to be faster, faster… He wasn’t an 18 year old student any more, and it hit him really suddenly.

That’s kind of the whole lifestyle trying to keep up in the world of game production.

It’s not just games. I remember a quote by Glenn Tipton, guitarist for Judas Priest, where he said he loved the new wave of neo-classical heavy metal guitarists, because even in his forties, it meant he couldn’t put his feet up and know he was good. They were always pushing him every year to be faster, flashier, better.

There's always someone who can play faster than you...

I’m sure it’s true in every field, weight lifting, (any kind of sport really), comedy, writing… the pressure goes up and up each year. In order to suceed, you need to be better than the people who came before, and every year, the cumulative pile of stuff that came before gets bigger and better.

I am VERY aware of the fact that you can go to steam right now and buy a lot of once-big-budget games for the same price as buying one of mine. I’m not trying to play AAA games at their own game, but I’m trying to keep my games as fresh and modern and polished as I can. The harsh fact is, I can’t expect to make a game that’s just *as good* as Gratuitous Space Battles, and expect it to sell as well, three years later. That’s planning to fail. I need to address every single thing I know was wrong with GSB, and if I achieve that, I expect to maybe match that games sales, nothing more.

So in comes better online integration, achievements, better unlocks, hopefully better user customisation. Better artwork, better all-over-polish, better play testing and bug testing. And that means hiring more artists,  spending more time, being more obsessive with detail. This is not an easy gig. This is anything but an easy gig. And yet I love it. When I tried the battlefield 3 beta, I was noting everything that impressed me about it, knowing I need to get that sort of detail into GTB. When GTB comes out, BF3 will be old news. It will be yet another rung on the ladder of what gamers expect.

Note: I’m not just talking about graphics. I couldn’t begin to compete with the shaders and the pixel-pushing power of the frostbite engine. I’m talking about polish, all those little things that make games more playable, approachable, long-lasting and easy to use. Stuff like animated menus, text that nicely fades in and out, and is pin-sharp. intuitive GUI’s that are in just the right place, taking up just the right amount of space. Really well thought-out color palettes, sounds that all seem to fit together, flawless execution of UI stuff, great tutorials etc.

Back to work…

Anatomy of a gratuitous bug

Posted on September 28, 2011

I think I’ve fixed a bug in the gratuitous space battles campaign game. I’ll know ‘officially’ soon, but it fixed it on my machine :D Here’s what was involved.

A player complained of a random crash bug at the end of some campaign battles. I could not ever reproduce it, and back-and-forth emails began. Eventually, this awesome customer provided me with exact steps to reproduce, and all their save game data to let me replicate it. First run through and….. nothing. It was fine. Roughly every third run-through, in release mode it crashed…

Step 1! Hurrah! it actually crashes for me. This is 50% of the battle because then I *KNOW* that it is the games fault, and not the gamers system, or software. This is good, although frustrating news.

Step 2! It crashes in debug mode. This is another 25% of the battle because I can actually see what data is corrupt. As it turned out, the ‘firstfleet’ pointer in the code that assigns captured ships to the players winning fleet is clearly trashed. How did this happen?

Step 3… debugging. It transpires that the firstfleet pointer is accessed multiple times before this point, and after being initialised, confirming that it *must* have been valid, and becomes invalid between initialisation and access when adding captured ships to the fleet. This means we  can step through and watch what happens, if I break on initialisation..

Step 4 discovery! Stepping through the code confirms my suspicions. Once the battle ends, the code updates all the players fleets and removes ships that died in battle. Then, other code innocently picks the first of the players fleets in the battle, and initialises a dialog box listing the enemy captured ships that will be assigned to the fleet. Later…. *drum roll* it deletes any fleets that are now empty. Can you see the bug yet?

Step 5: fix! Changing the code that naievely picked the ‘first fleet’ to pick the first player fleet that still has some intact ships ensures that the later deletion of an empty fleet, and invalidation of the pointer is harmless, because the captured ships are now getting added to a surviving fleet. Bug probably fixed, pending the player confirming that a new exe fixes it.

Why did I not spot this bug six months ago? Well here is what has to happen.

  1. The player has to fight a battle with multiple fleets at once (common).
  2. He has to win (fairly common)
  3. The ai has to lose by the right margin to leave some captured ships (fairly rare).
  4. The winning player has to have enough ships removed from the *first* fleet in the list to have that fleet entirely deleted, despite winning overall. (pretty darned rare).

Simply put, This didn’t happen to me once in testing. It hasn’t happened to many players either, as I understand it. And if it has happened to you… I may have good news :D

Regimental colors

Posted on September 25, 2011

Today I got a decent chunk of work done for the regimental colors editor for GTB. GSB only had your user name, which didn’t really add a feeling of connection to the other player, so GTB will have your regimental logo (like a cap-badge insignia) associated with your maps and armies, so hopefully players will feel more like they are really fighting against proper opponents.

I plan to support user-designed, uploaded logos too, but because 95% of players won’t be arsed to do that, there is a simple editor that arranges a logo out of 3 layers and renders it to disk as your profile logo. The rendering isn’t done yet, but the rest is:

You can choose between a bunch of graphics and the three layers get combined, with a choice of some colors, plus you can move elements up and down and scale them. It’s the bare minimum that will give me an assurance that you will generally see fairly unique logos for all your opponents when playing other players armies. Plus it was fun to do :D

The problem with code like this is you can get *too* into it. I could happily spend a week doing a fully featured military insignia designer with a ton of features, but you can’t have that attitude with a game as huge as GTB if it’s ever going to ship :D I really hope the game does well enough for people to get into designing really cool logos. GSB has a great modding community and I’d love to see them go to town with stuff like this.

 

Patch and games sizes, onlive, bandwidth…

Posted on September 24, 2011

So OnLive is out in the UK. I noticed quite a few people on the interwebs pointing out that they won’t sign up because, like me, they are on limited bandwidth internet plans.

I live out in the country, where there isn’t as much choice of ISP as the cities, and because my business needs the net, I need a rock solid connection with reliability and really good telephone support, so I end up paying over the odds. As a result, I have very reliable broadband, pretty fast, but bandwidth capped to 45 gig /month. I generally never hit the limit, but then when I see a game demo thats 2 gigs, I normally just skip it.

Something that made me think about this was Heroes of Stalingrad, Red Orchestra. This game is a tech-support trainwreck, with numerous bugs, random crashes, occasional dissapearing sound effects, rubber-banding, blah blah. Underneath it all is a great game.

The good news is they keep patching the game (although often introduce more bugs than they fix). The bad news is the patches are normally 400MB+. Apparently the developers claim this is the unreal engines fault in some way, although I find that hard to believe. Almost all bugs in a game are in the .exe and the exe is rarely >20MB.  Regular 400MB patches are crazy.

I definitely think that big games studios totally forget about the ‘bandwidth-challenged’. It’s one thing to release big patches. It’s another thing to release such patches several times a month, and require the patch for online play. If everyone MUST have the latest version, don’t insist on chewing up over a gig or two a month of peoples bandwidth limit just to play a game.

 

 

Starting on the challenge stuff…

Posted on September 21, 2011

GTB is such a huge game that I seem to veer into certain areas of it for weeks at a time, then veer back into other bits of it and think “did I write all this code?”

One of the features from Gratuitous Space Battles that I was very happy with, was the online challenge system. It was very popular. About 226 trillion billion zillion challenge games have been played (roughly). Obviously I want a similar system incorporated into GTB, and naturally I want to fix the things that were not perfect, which I identify as:

  • The challenge browser was not as good as it could be. You couldn’t filter out played/downloaded challenges.
  • Any challenge that had content, be it DLC or a mod that you did not have, could crash the game, and not be pre-filtered
  • The emotional connection between you and the challenger was limited. (Rarely used messaging, and rating, but not leaving comments etc).

I plan to fix all of this, but the middle one is the current one of interest.

GSB had a binary .gsb format for a challenge, which basically packed in binary data for the fleets designs, deployments and orders, and a little bit of data about the challenge (custom settings etc) and that was it.

GTB will use a new .pak format I’ve written that will behave a lot like a zip file. (no compression yet, sadly). It will be a folder full of stuff for each battle, all the enemies unit designs, the deployment timings for their attacking units (or initial deployments of defending units), and all of the data from the scenario file, down to the location of every tree, crate, barrel, barbed wire etc…

That makes a GTB challenge file slightly larger than before, but I can live with that. They are under 100k. How many custom maps in games are under 100k now? It also means you could move a few trees or change the texture of a single tile, and upload an existing scenario trivially without any inconvenience.

Anyway…. The upshot of this new file format is that theoretically, if I write the code for it, the format could include custom sounds, graphics etc. That means you could do a mod for GTB which included different textures for the terrain, and custom units, issue it as a challenge, and EVERYONE could play it, because the required content gets downloaded with it.

Sadly, there is no way to prevent dupes there, so if you have a custom tank texture, and upload 10 challenges, someone downloading all 10 gets the texture 10 times, but I think that’s not so bad. Only a minority of players are likely to issue or play modded challenges anyway.

The main thing is, my pak file format pakker and unpakker all works fine, so it’s another step along the path to having online play working. Now I need to replicate a lot of the GSB functionality (and improve on it).

Edit: I swapped out my code to use some zip code instead , after finding a zip wrapper that was extremely lightweight.