here’s the intro blurb on Jeevons Paradox from Wikipedia:

In economics, the Jevons paradox, sometimes called the Jevons effect, is the proposition that technological progress that increases the efficiency with which a resource is used tends to increase (rather than decrease) the rate of consumption of that resource.

basically what happens is that when resource efficiency increases it sets off a bunch of effects that increase the load on that resource (instead of decreasing the load) even to the point where the original load on the resource was MORE efficient.

check out the wiki article its very interesting.

enjoying your blog!

According to Ohloh, Oolite is almost half a million lines of code. That doesn’t include SpiderMonkey, GNUstep, SDL, Mesa or the other lesser dependencies, but does include a number of several declarative data files and scripts, as well as a bunch of tests and support tools. Call it 250–300kLOC of actual game code.

I don’t have a Linux build of Oolite handy (BerliOS is down… again), but the Mac “test release” binary weighs in at 19.6 MB (with three architectures in one file). This doesn’t including game resources; the data files, excluding textures and sounds, are another 680 kB. That’s a whole DOS box full of text!

From time to time, I’ve wondered where all this comes from. After all, most of that code is at least used for something (not all of it, since it’s written in a dynamic-dispatch language that can’t be dead-code stripped). I have several thoughts:

* Firstly, 8-bit machine code is inherently smaller than 32-bit or 64-bit machine code.

* Diverse hardware (and software). Oolite is supported on three operating systems and three processor architectures, and has been built for others (for example, IRIX on MIPS). It supports OpenGL 1.1, but makes use of features from 1.3 and 2.0, including shader support. This of course complicates rendering code.

* Graphics support. Drawing all those newfangled textures and shaders doesn’t just require texture files, it also needs loading, resource management, scaling and support for various hardware capabilities (see above); for instance, it can convert cube map textures for planets to equirectangular projection on the fly for systems without cube map support, which is very rarely useful but allows us to keep the ridiculously low hardware target.

* Abstractions. (The points below are special cases of this.) A dynamic-dispatch OO language adds overhead for class objects, method tables and so forth. Many components are written to be reusable in various ways. Writing specialized procedural code for each particular case will generally produce smaller code, but makes it harder to maintain and add new features.

* Parsing. Instead of hard-coding data, we use text-based representations which are parsed at runtime. In addition to the actual parsing (much of which is handled by GNUstep or Cocoa), there’s string constants, sanity checking and caching. In order to integrate with these data files, the procedural generation code has to generate abstract representations and merge them with data files rather than just return an array of numbers.
On the other hand, this stuff is the foundation of Oolite’s expansion pack support. Without the hundreds of expansion packs and active mod community, the project would have died years ago.

* Scripting. For historical reasons, there are three scripting engines in Oolite – one for AI state machines, an old deprecated system used for various things, and a newish, quite powerful JavaScript interface. Just the JavaScript interface glue is twenty thousand lines of code, not counting the interactive console support. The original purpose of scripting support was to express some game behaviours as high-level abstractions, but of course it’s also important for modding.

* Debugging support. There are many testing facilities and a complex logging system, primarily to help expansion pack developers, although some of it is also useful in debugging the game itself.

I guesstimate that with care and dedication, Oolite could be rewritten to be a third of the size while supporting the same functionality, and also be more efficient. (Especially if you raised the GPU requirements!) The important thing, though, is this: that hypothetical game would never be written. It would take man-years of work, and I’m not talking about the sort of weekend hobby work that built Oolite in the first place.

When you write a game in pure, tight assembly, every design change requires large parts of the work to be thrown away. The ability to use high-level abstractions and organically grow a game is what makes it possible for a bunch of hobbyists to write Oolite in the first place. (Well, I say a bunch; Giles Williams wrote it more or less himself, then the rest of us refined it.)

One thing you didn’t mention about Elite is that it’s one of the biggest non-modular, optimized assembly programs ever written. Much – not all – of the perceived bloat of modern software comes from this: abstractions make it possible to write more complex systems faster, and that’s the biggest benefit of more powerful computers.

Well, I usually keep this feling for myself since everytime I speak my mind, I feel like an old fart ranting about “how everything was better before”…

The truth is small software is good software and Keep It Simple, Stupid !

By the way, I like your blog, thanks for taking the time to write all those nice posts.

http://www.securitytube.net/groups?operation=view&groupId=5

It’s kinda like what people say about Lisp; you improved your knowledge about computers once you got the hang of it.