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

Sex discrimination and who works on games

Posted on March 26, 2009

My eye was drawn to this story, because it refers to where I used to work. Short summary is that a game developer is claiming compensation for discrimination at work for being gay. I won’t go into the actual case, because I don’t know the guy and haven’t worked there for ages, so it’s not fair to comment. However,I would like to extend the issue it covers to a wider call for action:

The games industry needs to grow up and stop acting like kids.

We act all high and mighty and start huffing and puffing the minute anyone suggests that ‘video games are for kids’, whilst at the same time doing very very little to change that perception. With a few very notable examples (the nintendo wii, games like Civ and some of the more complex sims) games ARE aimed at children, either deliberately, or aimed at the ‘inner child’.

It may be true that most people playing GTA and Call of Duty and World Of Warcraft are NOT 13 year old boys, but if so, that’s a triumph against the odds. Everything about mainstream gaming seems to aim at that demographic. Think about how to make a product attractive to a 13 year old boy, and how many games incorporate this stuff:

  • Guns (enough said…)
  • Big Tits (“phwoarr! etc”)
  • Scoring points (“I’m better than you!”
  • Achievements (“like gold stars on a school report”)
  • Bragging rights and taunts (“You suck!)

Outside of video gaming, most of us grow out of obsessions with these. (well most of them..ahem). Of course, you can make adult-aimed (non-sexual) games that contain guns too, but a hell of a lot of games just use guns as pure gun porn. Show me a game that contains a female elf that looks like anything but a supermodel. Show me a soldier in a game that doesn’t have biceps like zeppelins. They are few and far between. Alyx in HL2 is a wonderful exception to all this, but she is the exception, not the rule.

Anyway, my reasoning here is that these sort of games are what we make, because that’s the kind of people we are. Game developers are overwhelming male, overwhelming white (scarily so), overwhelmingly middle class, and overwhelmingly under 40. I have no idea what proportion are straight, but given the amount of artists that spend all day modelling buxom elves, I assume 99%. (Given the amount of time artists spend modelling men’s biceps and chests, I assume 99% of the 99% are just in denial :D)

I’m 40 this year. I’ll still be making games, but I’ll be unusually old for a developer then.  Normally by this age you ahve left and got a real job, or you run a big studio and employ the same young white rich kids to do the work.

What the games industry needs, in order to grow up, and to grow in size, is more women, more black and asian people, more gay and lesbian developers, and people from different backgrounds. And that absolutely means that it needs to crush with huge force, ANY discrimination in the workplace.

Maxis apparently have more women that usual for a game dev, no surprise they are doing well.

Now before you slag me in the comments for doing a game called ‘gratuitous space battles‘, take note that I entirely include myself in this. I am white, under 40, came from a borderline working/middle class home, straight and male. (plus surely I get points for doing intellectual games?) I like buxom elves and spaceships exploding too. This is why people who are not like me should get into the industry. Save us from ourselves.

Escorts and formations

Posted on March 25, 2009

I got the code in today for ships to escort others, and for formations. There is a very clunky ugly GUI for setting it up, which needs fixing at some point.

Basically, in the deployment stage before a battle, you can add orders to each ship which will instruct them to escort or fly in formation to a specified other ship. If that ship is destroyed, the orders get ignored. Escorting is the same as saying “Do what you want (according to other orders) but dont get more than x meters from this ship.” Formation is the same as saying  “Always remain at this exact offset in X and Y terms from the specified ship”. The formations are in world space, not relative to the parent ship, and this seems to work best.

It seems to work (although I havent’ tried fighter formations yet), and I can see already it will lead to much more strategy in the game. You can set up ships to be flanked by other ships with anti-fighter lasers, thus providing a screening layer for a cruiser which might have invested in big guns and not have room for anti-fighter modules.

Plus a group of cruisers or frigates flying in formation looks pretty cool, especially after I fixed a silly bug which meant 75% of the laser bolts were not getting drawn. It’s real mayhem now :D

Multiple beams and turrets!

Posted on March 24, 2009

At last I’ve got around to adding laser turrets to the ships, so the beams don’t seem to blast out of just anywhere any more. I’ve also added support for multiple beam origins per weapon, and for them to be different to where the module is placed on the ship design blueprint. This leaves the blueprint looking functional, whilst allowing me to spam a few laser turrets on the bigger ships. It also means you can have a battery of lasers that all zap at once. Maybe eventually I’ll introduce minor delays or other cleverness to make them seem more independent.

There isn’t really a connection between the weapon type and the number of turrets you get with it, but it has no gameplay effect, and is purely visual. So some ships have a slot that links to multiple turrets, and placing a beam laser there will ‘spawn’ multiple turrets, whereas the same weapon on a different ship gets just one.

I don’t think it matters, there is zero connection between the two phenomena in Eve online, and it doesn’t seem to bug people. The main thing is, it looks cool, and I hope, somewhat gratuitous:

Bad Customer Service. Why is it still here?

Posted on March 22, 2009

I’ve recently ahd the displeasure of dealing with both sony and dell for customer service. Dell are supposed to e sending me a laptop, but it’s not here. Naturally, like all megacorps, they cant be bothered to actually *care* if you get the product, so they outsource this vital part of their business to some third party who ignore emails and have a broken website with an order tracking form that returns blank pages in all 4 browsers I tried. I outsource part of my business (credit card payments) to BMTMicro, and I KNOW they are damned good, because I tried RegNow, RegSoft, FastSpring, Plimus and BMT.

The bit that bugs me is that emailing dell themselves means that you get a reply in their business hours, which is mon-fri 9-5pm.

lets look at that again:

Mon-Fri 9am-5pm

What is this? 1970?

Dell are a HUGE and GLOBAL corporation. They can afford to employ a skeleton staff over weekends, or even (maybe I’m out on a limb here) to work from 8-5 or 10-6 in overlapping shifts?

If you emailed me this morning for tech support, or customer service, you got a reply today. Today is a Sunday, and Mothers day. I will answer your email the moment I read it. I am a one-man company. I sincerely hope that in this recession, discerning customers learn to punish the companies that treat them badly, and reward those who treat them well. I know I will :D

A day optimising the debris

Posted on March 20, 2009

I love the debris effects when ships get hit or explode, but they are expensive because it creates so many objects, so today I’ll be optimising so I can expand the extent of them. Some of the debris is transitory (fades out) and roughly 1/4 of it stays on-screen all the time. It all spins, but it stops moving over time.

Currently the call to draw the debris makes up 3.49% of the time spent drawing the battle screen. That might not seem like a lot, but if I want to triple the amount I can draw, and support bigger maps, it could get out of control.

It’s 9.15Am and I’m starting to code a faster system. Currently, every single speck of debris is stuck in a big global list and I go through and draw each one, although I reject them very fast if they are offscreen. This is very slow though. At least 20% of the draw time is spent just iterating through the list. My proposed solution is to stick each cloud of debris into groups, and do the iteration of groups (rejecting obviously offscreen groups) and only go through individual specks if the group is visible. I think that should speed stuff up a lot.

9.30 Am. First test shows it’s dropped to 3.74%. Hardly a mind blowing improvement.

9.33 Am: Ooops, that’s the wrong exe being profiled. I need to set up a new project configuration (release symbol). Damn. That means total rebuild. Time for tea.

9.55 Am Somehow I can’t get this poxy release build + debug symbol build to run. grrrr.

11.00 Am Still getting my builds fixed. I have a debug build which runs with optimisations on, and that seems to at least work. Also I now cache the debris texture pointer so I’m not doing a string search every frame to find it.

11.30 Am. New system seems tons SLOWER. I need to flip back and forth so I can verify this is really true. It seems to be because of my use of STL lists, when each cloud of debris has very few members. I need to ensure my code isn’t using debug STL before going any further. It’s the same even with release, so I’m ditching the new system and will optimise the old one.

11.45 Am Creating and destroying debris objects is very slow. I’m going to have a fixed array rather than a global list, and use a series of flags instead. This does seem to be a bit faster, and makes much simpler code. However, the fixed array size and the method for finding an inactive debris item is inefficient and doesn’t scale at all.

12.15 PM Simple but major speedup. I was always searching the whole array, whereas clearly the solution si to always start the array search from the item one above the last one which was available, and wrap around. That sped up debris initialising by a factor of five. Time for Lunch!

1.30 PM I’m now precalculating some of the data thats used identically by each bit of debris and passing it to the update function. It’s maybe 20% faster. I just spotted I’m checking for alpha < 0 even for debris whose alpha does not fade. Fixed!. Ideally I need to update almost nothing for debris that’s offscreen, and yet have it still behave sensibly when it then appears onscreen later.

1.51 PM New system where I mark out debris that has practically stopped moving, and omit any further position updates for them has reduced the update time by another 20%

3.10 PM New graphical debug display shows me which debris array entries are persistent, in use and unused. Took 2 minutes, but its very helpful. May attempt a system to ‘defrag’ the array now.

4.10 PM Defragging system works great. Time to double the amount of debris everywhere and see how it all holds up.

5.45 PM Everything looking ok. Probably need to add some nice smoke effects at some stage. Time to work on gameplay code.