Wednesday 29 September 2010

Stored Procedures Are Bullshit

Obviously not totally bullshit. They have their uses. But I am working on an application that has so overused them, that I feel like stabbing out my eyes with a rusty spoon every time I look at another of the 1000 line obfuscated monstrosities.

Who the fuck thinks writing a multi-thousand line stored proc is a good idea? At no point does common sense intrude and say ‘Hold on. I might have taken a wrong turn here’? I suppose not, since this app has literally hundreds of enormous procs, containing the vast bulk of the applications critical logic.

Even though the insanity of this approach should be self-evident if you’re anything other than a total charlatan, for the sake of my own sanity, I’ll iterate here why this is so much bullshit:

  •   Multi-thousand line functions of any form are folly. Multi-thousand line functions in an IDE as feature-free as your typical DB client are on a higher plane of batshit insanity. For fuck sake.     
  •  Why, oh why, would you choose to write business critical logic in the exact place where your unit tests can’t get at it? Oh wait, it’s because you don’t have any.
  • By writing all your critical code as SPs, it’s not only now next-to-impossible to test properly, it’s also tethered to the scaling capabilities of your DB. Nice work.
  •   Most of the stated benefits of SPs no longer apply. It’s 2010. 
  •  If the amount of SP code is large or especially complex, you’d better like your DB vendor because you’re not fucking changing.
  •  Your application developers have to context switch every time they want to implement a full slice of functionality. From modern IDE / language / tools to the SQL stone age of whatever shithole DB client you’re using (they’re all shit, no exceptions), this is the path to productivity destruction.
  •   Debugging stored procedures is a fucking black art, known only to DBAs and weirdoes. Fact.
Very few coding topics actually arouse strong feelings in me – something I have learned over years of working with many different people at different companies is that, as software engineers go, I’m reasonably easygoing. I can accommodate a vast array of programming styles and technologies without much of the usual subjective, vitriolic, bullshit that often reigns in an industry full of Aspergers sufferers.

But on this I’m clear. Fuck stored procedures.

Tuesday 14 September 2010

Roguelike - Mining!


Players can now enter mining mode and designate blocks to be mined. Miners will path to the nearest block to be mined, and start digging.


Roguelike - Pathfinding


Pathfinding entities up and running. Not that they've got to try hard in this particular test dungeon.

Thursday 9 September 2010

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.



Friday 26 March 2010

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.

Monday 11 January 2010

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.