Last night was Game Dev night at the London Geek meet in the ThoughtWorks offices. It was really enjoyable, I really enjoyed the talks, and meeting and chatting to everyone there.

Interestingly, there were a bunch of comments throughout the evening that confirmed some long-standing suspicions I've had about professional game development. I'm not pointedly directing this at any individuals - it really was a pleasure and an education talking to every person present. However, I couldn't help but notice that there seems to be a pervasive macho streak in the game industry, sustained by the belief that game development is considerably harder and more creative than any other form of software. Or, as I have overheard game developers saying, first hand, than any other human endeavor.

Not rocket science

Now, there's no doubt that different niches of the software industry vary in complexity, just as the commitment and experience of individuals, teams and organisations varies over an enormous range. I have no doubt that game development lies on the upper part of that spectrum rather than in the middle. But I also have no doubt that there are lots of other software industries which are just as complex, demanding and creative as game development.

Game dev is not special or unique in having many hard problems to solve. When game devs claim that it is, it simply looks like a defensive reaction to the pervasive belief outside the industry that games are trivial time-wasting distractions, and that creating them must therefore be one of the easiest and most lightweight aspects of IT.

This would be merely silly self-delusion if that was as far as it went, but this state of affairs actually has huge damaging knock-on effects. The belief that they are tackling projects which are harder than other software projects leads to an attitude verging on arrogance - an assumption of superiority, and that they have nothing to learn from the rest of the software industry. As a result, game dev shops don't even attempt to talk to other software engineers about their common craft, and as a result the engineering prowess of the game industry actually lags behind the rest of the software industry by five or ten years. Practices and techniques which are de rigour in the rest of the industry these days, such as test-driven development and continuous integration, are virtually unknown in the game industry. Examples during last night's discussion, which were held up as indicators of how difficult and complex game dev is, appeared to many people in the room to simply be symptoms of clearly bad design.

The legendary long hours and project burnout in the game industry is actually a symptom of this - far from being the most capable engineers amongst us, the reason they are working such ungodly hours is to compensate for poor software engineering. The rest of the software industry used to suffer from a similar overwork problem, but you know what? We figured it out, decades ago now. It's notable to me that other industries which suffer from overwork and burnout (eg. the finance industry) are also buzzing with arrogance and secrecy.

Humility and communication are pre-requisites for any learning. Jeez, get over yourselves and go learn how to run a software project.

Written by none other than the OpenGL architecture review board themselves, this is the de facto starting point for anyone learning how to write programs to draw computer graphics using the OpenGL graphics API. As such, the entire breadth of OpenGL is described in these 800 weighty pages.

This comes with one or two questionable implications. Firstly, the authors, being the authoritative source, are obliged to cover the entirety of the OpenGL interface, even though portions of it are now obsolete, having been supplanted in practice by newer techniques. The older methods are still present, and are described here on an equal footing with the later additions.

Similarly, to avoid getting embroiled in the idiosyncrasies of any particular vendor's implementation of OpenGL, there is never more than an occasional vague allusion to the potential performance implications of using one approach over another. The concept of using vertex arrays is covered in a general-principles sort of way, as are vertex buffer objects, with the admonition to "prefer them over explicit calls to glVertex() for performance" buried in an appendix-like chapter near the end. The idea that rendering primitives of GL_TRIANGLES is heavily optimised on modern graphics cards receives no mention, from which I mistakenly inferred that other primitive types such as GL_TRIANGLE_STRIPs, with their lower apparent vertex counts, are a preferable alternative.

This egalitarian presentation means that the book can rightly claim to be an unbiased description of OpenGL the interface, and is lent a long-term relevance by giving no bias towards any particular vendor, nor being subject to the fashions of rendering techniques that sweep through the industry every few years. On the other hand, it also means that the book is considerably larger than most people learning OpenGL will need, and fails to cover many of the vastly performance-enhancing techniques that have become standard throughout the industry.

Rating: 6/10.

I bought the 'Orange' Shader Language book next. Can anyone recommend one of the other OpenGL books that are out there? Since they are all 800 pages I'd rather not wade through them all to find the best one.

Launches a new blog, at a shiny new permenant URL.

Director: Brian de Palma (1983)

Oh, I don't know, my expectations were too high or something. I expected an intense study of greed, corruption and criminal will. Maybe I'm desensitized. All I found was that it frequently descends into simply camp 1970s gunfight scenes. Amusing to note the influences it has had on other media, particularly the mansion in Grand Theft Auto: Vice City. I couldn't find much else to commend it.

Unnofficial meme from the Unofficial Planet Python, programming languages you know or have known:

• BASIC (ZX Spectrum, BBC and GFA) Thanks Mum and Dad for buying the old Speccy for me and my brother, and thanks also to WHSmiths for replacing about twenty of them free of charge, bricked by wobbling peripherals. Was slow, slow, slow. Be thankful those pixels were so big. The foray into BBC BASIC came for a single, albeit paying, project at the school where my Dad was headmaster. I also wrote a bunch of GFA BASIC on the Atari ST, which was relatively cool, as these things go. Did away with line numbers, had parameters passable by value or reference, and compiled to produce reasonably fast stand-alone executables. Lacking a compelling way to aggregate values into structures though.
• Z80 assembler, self taught on the ZX Spectrum. Wrestling with that darn screen's convoluted memory layout.
• 68000 assembler, self taught on the Atari ST. Finally fast enough to do wonderful things to the screen, which had a reasonably sane memory representation. Wished I was doing it on an Amiga instead though.
• C, learned on-the-job at a student apprenticeship at Marconi R&D during my university holidays. Special mention deserved for Kernighan and Ritchie The C Programming Language, as beautifully definitive and concise description of the language - just about every computer book employs a detracting surplus of verbiage in comparison.
• Modula-2, as part of the aforementioned apprenticeship. My first OO, I guess. Full of great ideas that I didn't fully appreciate at the time, having never worked on large enough projects to require them (or indeed, any project that wasn't a personal bedroom project.)
• Pascal, for a one-term 3D graphics project at university.
• C++, on the PC, self-taught using a mixture of pirated and cut-price academic Visual Studio licenses. Anyhow, this then lead to years and years of professional C++ development, mostly on various UNIX boxes, mostly in the GIS industry. So exhilarating when it worked, with the intricate, interlocking mechanisms whirling their fiendishly efficient blades through tasks like a light sabre through butter. But writing it, with hindsight, was *so* *much* *work*. And such an utter ball ache to find those intermittent bugs that would shake the whole thing explosively to pieces like a brick through a jet engine when you least expected it. I must have been a masochist.
• BASH shell scripts, still in daily use to this day, mostly tiny bits of script-fu to automate common desktop tasks, or pipe the output from one thing into some other thing, or heck, even to just do some sorting or filtering on part of the file you're editing in Vi. Absolutely indispensable to me, despite the fact that half the time I'm wrestling with the impedance mismatch of running it in Cygwin on Windows. I literally don't understand how developers can get along without using it *everywhere*.
• SQL and a bunch of stored procedures in PL-SQL (procedural SQL.)
• C#. Lots to like here, we spent a couple of very happy years together.
• Visual Basic 6, and then later some Visual Basic .NET. They made me do it.
• Python, including IronPython (Python as a dot Net language.) Nirvana at last. Apart from BASH, it's the only entry on the list that I still use daily today, and unlike BASH, the usage is gleeful.
• GLSL, for hobbyist graphics and games.
• Scheme to the extent that I worked through SICP, twice.
• Go, for a new service in IBM Cloud.
• PHP, to maintain an old service in IBM Cloud. Two PR's thus far.

I find my lack of LISP and its derivatives disturbing. And last year I recall entertaining fantasies of learning D, to see if I could use it as a more civilised alternative to C-extensions for Python. And just yesterday I was playing with a minimal OpenGL fragment and vertex shaders, longing to be conversant with Cg. Yeah yeah, I'll figure them all out later this week...

Update: First time through I forgot all about SQL, PL-SQL and BASH.

I've always been intrigued by OpenID, while simultaneously being repulsed by the identifiers that I thought users were forced to adopt. Seeing one too many strings like:

https://me.yahoo.com/a/.DuSz_IEq5Vw5NZLAHUFHWEKLSfQnRFuebro-

tossed around made me think I'd have to adopt a username like that, which obviously is never going to wash, for aesthetic and typability reasons alone.

Fortunately Ned Batchelder's rant, leading me to Simon 'Zeppelin' Willison's demystifying blog post, taught me all about how to use your own URL as your OpenID equivalent of a username, by inserting some HTML onto your web page. So now I've managed to jump through the sign-up hoops required to get me one of those globally-unique OpenID username identifiers for myself:

tartley.com

There. That isn't too painful, is it? Since I got set up, it has proven lovely to use. Get on board!

by Clay Shirky (2008)

Shirky has thrown a few beautiful and insightful essays over the wall the last few months. He is the guy who penned the 'Gin, Television and Social Surplus' piece a while back. It's a joy to find that this book is up to the same standard.

In it, he explains how the social changes enabled by recent technology are profoundly and permanently altering the ways in which human beings interact, form groups, and get things done.

This is making activities and projects possible which could never have been dreamed of even ten years ago, and is similarly displacing many established institutions. The greatest effects of this change will be seen when the technology has progressed to the point of invisibility, and the current upheavals in the music and newspaper industries are just the leading edge of the wave.

It's a change no less significant than the invention of the printing press, in terms of its ability to transform societal institutions. We do indeed live in interesting times.

Rating 10/10 - everyone should read it.

I'm excited to be giving a talk at PyCon UK next weekend about creating OpenGL programs in Python, using the graphics and games library pyglet. I'm still working feverishly on the presentation. This post is to be a permanent URL for the content, downloadable demos and YOUR comments, once PyCon is over.

See y'all there.

Update v1.0: The presentation slides are online, as is the demo source code.

Update v1.1: Fixed a bug using batches of vertex lists. (they don't work with triangle fans, and they need a duplicated first and last vertex in each list to delineate primitives.) Rendering speed is still awful using graphics.draw, vertex_lists and batches though. I'm chasing that up next.

Update v1.2: Fixed some of the performance problems, demo 6's batches of vertex lists are now the fastest way to render, which is the expected result. Still curious why calls to pyglet.graphics.draw() are slower than pyglet.gl.glvertex() though.

Update v1.3: Added demo 9 which creates a maze with ghosts wandering within it. The entire maze is rendered in a single batch.draw() call. Innumerable other improvements throughout.

by Ivan Idso, 2007.

A disclaimer, to begin - the author is my new-to-me brother in law, so I got a copy at cost, inscribed 'soft aardvarks' (I think), and a few weeks later got a once-in-a-lifetime experience of being taken on a balloon ride by the man himself. So the write-up is going to be a glowing one.

Fortunately, I don't have to stretch the truth at all in order to do so. It's a short and lightweight read, which does explain the mechanics and practicalities of hot-air ballooning. However, the focus of the book is on the social aspects, and the effect it has had on the life and disposition of Ivan, his family and friends. As a result, it's a thoroughly personal and heart-warming read, engrossing and explanatory and fulfilling throughout, that left me feeling closer to the author, and with more of an understanding of him and his lifestyle.

by Jerome D. Salinger (1951)

Of course, people make such a fuss over it, they really do. You ask anyone. It's that Salinger's fault. He never listens to anyone. Sometimes I think he only writes it because he knows it gets on peoples goat. Writing about some crazy kid. I mean, I say he's crazy because that's what everyone says, but he's no crazier than the rest of us if you want to know the truth. Smoking and swearing getting laid, if he got half a chance. But it's only what anyone would have done, well, anyone with any sense, that is.

There's one thing about it though, it made me remember a time when I was very young, no joke, and I started reading this very book, I don't know where I got it, I think my Father gave it to me. But I don't think I got very far. It must have been beyond me, to tell you the truth. Well, you've got to give the old Pater his due, for trying to stretch you and all that. That's just like him, it really is.

Anyway, the story doesn't really go anywhere, at least not anywhere I could fathom. Well, things happen, but it's just everyday things over the few days after being expelled from school. The usual stuff. You could write a whole essay, I suppose, about whether or not Caulfield changes or learns anything by the novel's end, or simply remains an adolescent. But I don't think that would amount to very much. So it's a stylistic experience, at any rate. Very 'A Portrait of the Artist as a Young Man' I'm sure, and you've got to give him his due.

Rating: 7/10 - Bloody Salinger, he never listens to anyone, him.