Roguelike Development

I've decided to blog a little about the ongoing development of a Roguelike. I'll be developing in C#, using libtcod.net for console support and some helpful library functionality like FOV calculation pathfinding, and BSP generation, amongst other things.

I'm primarily inspired by Dwarf Fortress, a game I'd love to be able to get into but just can't seem to crack. It's a testatment to its complexity that it actually seems simpler to develop my own Roguelike than to brave its (frankly horrendous) UI.

We'll see how far I get with this. Here's the first screenshot below! From small beginnings...

Set up the main console window, dividing it into sections. Tab toggles various enlarged views of the main window. Got a viewport system up and working so the main map can be scrolled.

Coding Standards

Coding standards are such a double edged sword. Almost nothing else (except for possibly contentious code reviewing) has quite the same potential for sowing discord in a software engineering team than a debate about coding standards. The pitfalls are many:

• There's a tendency for people to conflate personal preference with empirically-proven benefit.
• There's a tendency for the 'tidy-desk-tidy-mind' fetishists to brandish coding standards as a way of achieving the requisite level of code conformity - "THERE MUST BE NO INCONSISTENCY IN THE CODEBASE!". I find this type of software engineer ever so slightly tedious, to be honest. People vary in coding style like they vary in writing style, and whilst every effort should be made to conform to a common style where it matters, it is simply not necessary to constrain every little detail.
• On the other hand, coding standards can bring a desirable level of uniformity that allows people to move over the code base without jarring inconsistencies.
• They can also be used to explicitly rule out certain undesirable traits or bad habits.
  

Where things get trickiest, I find, is when you've agreed all the obvious points, and are debating what you might think are the more marginal details. Everyone generally agrees what the horrendous no-no's are (for instance, in our team we ban the use of complex prefixes on variables, other than a m_ on member variables - there's simply no need for it in a type safe language), they're easy to spot, everyone acknowledges they shouldn't be done, and there's usually no argument about explicitly dealing with them in the standards doc.

When you get to something slightly less obvious, say, arguing the finer points of parameter naming convention, or whether or not you should ban the use of #regions, people start grabbing their pitchforks and preparing for war.

It's at this point that the worst aspects of programmers as personality types usually emerge - detail obsessed, a certain level of anal retentiveness, an inability to communicate differences without needlessly inflaming others. These characteristics are stereotypes for a reason - software engineering surely has a higher-than-normal proportion of borderline Aspergers sufferers.

Assassin's Creed 2 Thoughts

I recently purchased Assassin's Creed 2, and have found myself slightly frustrated at the rough edges I'd hoped would be refined in the sequel. Partly it's a question of misaligned expectations - I think the previews and trailers of the original game set me up for an experience that's ever so slightly different from what the game actually sets out to deliver.

The Assassin's Creed franchise is an action adventure game par excellence. It's slick, looks beautiful, handles brilliantly and is polished to a high sheen. What I was originally expecting, on the other hand (spurred on by some over-the-top previews and early footage) was something slightly different, something closer to a 'medieval assassin simulation'. Previews boasted of living medieval cities populated by people going about their business, of 'hiding in plain sight', blending in, observing your target. Stalking, predating, killing your mark with some flair and creativity. What, in the end I think we got, was a game which actually emphasized story, free running, acrobatics and combat over and above any deep and meaningful assassination mechanics. Each of the main kills in the original game I accomplished merely by running up to my target, stabbing them, and running off. Indeed, the game seems to go out of it's way to encourage you to kill by this method, given that it's the path of least resistance by an enormous margin.

Contrast this with the Hitman series. In these games, such a direct approach will get you killed fast. Each level must be treated as a puzzle. Observation and exploration is key, before you engage in any hostile act. Once you have fully explored the level a number of approaches will present themselves. You'll have opportunities for all kinds of creative kills - poisonings, sabotaging the environment, sniper kills, misdirection of guards, hiding yourself in a quiet spot along your targets path. Assassin's Creed and it's sequel offer none of this. That's not to say they don't offer a lot, they most certainly do. However, they fail to meet the burden of my expectations, which is as probably more my fault than the game's.

There are several other issues I have that exacerbate the problems:

1. The game offers a variety of semi-scripted sequences clearly designed to offer a cinematic, exciting set piece - a guard chase through a catacomb to prevent other guards being warned, for instance. The problem with these is the same as the problem of attempting stealthy kills on the main targets - it's too easy to fail, and to survive if you fail by spamming combat counters. You get the immersion-breaking double whammy of not managing to maintain your low profile (i.e. you're as stealthy as a humpback whale) and yet there's little incentive to try again because you can simply fight your way out of most corners via the combat system. In some ways, games in which stealth is your only recourse achieve better immersion, because you die repeatedly until you learn to play. Here, stealth is the poor cousin to agility and combat.
   
2. Little creativity is required for the main boss kills. In some missions, it's even possible to sneak up on the boss completely undetected, only for him to magically turn around and spot you instantly when you hit his detection radius, or worse, the game activates a cut scene to begin a set piece as you're moving in for the kill. This, frankly, is bullshit. If I'm able to sneak up behind a boss, let me stealth kill him please.
   

That said, Assassin's Creed 2 does improve on its predecessor in a number of ways:

1. We no longer have the 'monk conveyor belt' as the only way of blending with a group. It's now a lot more organic, you can blend with any group of people, moving or standing, and they don't have to be wearing the same costume as you.
   
2. The game breaks you out of the main world far, far less. This was intensely irritating about the original game, which most people purchased on the basis that you were a medieval assassin, and so generally wanted to spend their time doing that, rather than spend their time as lesser man Desmond in the present.
3. Far more variety in general. There are foot races, feather and loot collections, glyph and treasure hunts. You can observe other thieves commit crimes, chase them and steal their loot. There's a notoriety system that controls how infamous and recognizable you are to the guard population. You have numerous ways of distracting and killing guards. There's multiple armour and weapon sets to collect and own. You can change costume. You have a stronghold of your own, which can be upgraded and improved, generating an income for you.
   

All in all, I think the game is very impressive, and I have huge admiration for the skilled team that made it. But if you could just add more depth to the main assassinations, I think this game would be a lot closer to perfection.

Old Skool Coders and Their Misconceptions

I've been a software developer for a little over five years. Not very long. I've worked in the games industry for just about half of that. Now, I'm not sure if it's just the games industry or whether this attitude is prevalent elsewhere, but there's a certain mindset amongst long-time games coders that drives me nuts.

There's this common perception that new guys code wastefully. We don't optimise for every last ounce of performance, that we waste CPU cycles and memory with abandon. That we're 'spoiled' by new-fangled high level languages, that we don't know assembler, that we don't even have to manage our own memory with some of the newest languages. It's just so much bullshit. Never mind that the first thing a half-decent games engine implements is a memory management system, so as to avoid the majority of your coders having to work with raw pointers.

The real kicker for me is that these old schoolers bemoan our lack of optimisation obsession, without EVER stopping to think WHY this is such a prevalent trend amongst younger developers. They usually get as far as saying 'they just don't have to bother, with today's powerful CPUs and abundance of cheap memory'. This just misses the point. It's a sad, tired variant of every generations obsession with proving they 'had it tougher' than the next.

The real enemy in game development now is not hardware limitation, or poor performance. The REAL enemy in projects of significant size is COMPLEXITY. Their battle was with crappy hardware and limited resource. Ours is with 100-man teams and projects that span millions of lines of code. The fact that some people can't seem to recognise that there are different imperatives in software development now than there were coding single player games for the commodore 64 just gets me angry.

Sins of a Solar Empire...

...is great. A real gem.

It's not a massively original game, it's very like a number of older RTS games - Conquest: Frontier Wars most closely resembles it, although Sins is definitely the better game. It incorporates a number of features that mark it out from the crowd - nothing revolutionary, it's simply a case of developers Ironclad being suitably shameless in incorporating worthwhile features from other games. It also looks pretty spectacular, and runs well on system that's a couple of years off the pace.

Back to Work Tomorrow

I've been off now for nearly two weeks, it's been great. But the really amazing thing is that I'm looking forward to going back. I really am fortunate to be able to honestly claim that I love my job. Although, perhaps fortunate isn't the right word, as I didn't exactly fall into game development, it took me a while and a few wrong turns before I got there. But I'm grateful to have made it.

You know you're in the right job when you get some time off and end up doing the same sort of stuff you'd be doing anyway. Coding things at home provides a good counterpoint to what I do at work. When you work on a big commercial game it's a little bit like working on a Boeing 747 - the project is so vast and contains so many complex parts it is literally impossible for one guy to learn it all, so you end up very focused on the one part of the project you are responsible for, with really very little idea on how the rest of it hangs together.

Working on my own stuff provides a nice balance. Perhaps it's why so many professional programmers enjoy coding in their spare time - it allows you to exercise the bits of your programming brain you don't often get to stretch at work. There is also a certain satisfaction on working on something small enough to be fully understood.

It's certainly a habit I've seen in other devs. Some make old 8-bit games or write emulators for old platforms. Some enjoy hacking their DS or PSP just to see what they can get working. People often associate programming or computer literacy in general with logical, linear thinking, but for many of the programmers I've known, it's simply a different kind of creativity.

I often have difficulty explaining to family or friends who ask how games are made, or ask what I do for a living. It is nearly impossible to explain to someone in anything like remotely meaningful terms how a modern video game is made if they have no prior knowledge of software development or anything to ground my explanation on. I usually go one of two ways - either I attempt to give them a full grounding in the last 50 years of computer science, starting with the Turing machine and working from there, or I oversimplify to the point of insulting them. I find a better approach is to ignore the nitty gritty and explain what the company I work for does - a developer's place in the grand scheme of things, via a very sketchy music industry analogy - developer is to musical artist as publisher is to record label, but that gives them the wrong ideas as to my own personal contribution, not to mention a vastly exaggerated estimation of my net worth :)

Attention, Fantasy Authors of The World

There's something about the position of claiming something is 'art' that has never sat easily with me. Perhaps it's the fact that the creative medium I feel most attached to (games) gets a fair amount of flak for being either dangerously violent drivel (Manhunt) at best, or self-consciously seeking that constant edge of 'new media' cool (Edge Magazine, The Escapist etc).

More specifically, I feel that attempting to portray games as art is just inviting our critics to laugh at us. Games are a medium. It is possible to create something considered to be 'art' in any medium, but that doesn't mean games are art. Television isn't art. Cinema isn't (usually) art. Newspapers are not art.

Moreover, I do not quite understand the need to be accepted as art. Who cares? For me, craft is important. Design is important, engineering is important. I'll look at a well engineered game and admire it in the same way I admire some feat of civil engineering - because I have some insight into the processes and work and effort that are required, I understand and appreciate the level of human ingenuity and thought that goes into making something that seems culturally vacuous to someone like my mother.

And games can exhibit great design, something that I appreciate when I look at an Ipod or a Dyson hoover or a Ferrari. There are other elements too - some games are well written, have exceptional storylines or feature incredibly artistic visual styles or worlds. I'm not desperate for everyone to recognise them as art, though.

I've been prompted into this, somewhat tangentially, by reading the latest and concluding novel in Terry Goodkind's Sword of Truth series, Confessor. I'll lay my cards on the table - I'm with a vocal minority on this one, in that I loved the series at the start, but increasingly grew tired of the incessant amateur philosophising of previously action-driven characters. It just gets worse and worse as the series goes on. And I think these two strands of thought (games as art / fantasy writing) are linked - I read fantasy novels not because the genre contains the cream of the world's writers - it doesn't. I read fantasy because I generally enjoy the settings, narrative and the action. There are exceptions - I can recognise Tolkien as art even if I never particularly warmed to LOTR.

Goodkind, I think, falls prey to the trap that some game commentators or developers do, namely that they feel they have to go out and prove the worth of the medium. They don't. Forget about proving your worth and remember there is as much to admire in a finely crafted and well honed story that brings enjoyment and escapism to millions as there is in writing something that gains recognition outside of your current fanbase.

In the end, I think Goodkind just doesn't want to be a fantasy writer, as his later novels just get further and further away from my definition of fantasy.