Thursday, 20 October 2011

Has been up for a short while now at Roguelike Radio. I've been too busying playing bRogue to be posting this in a timely fashion - as you may guess from listening to the podcast. However, it appears that I was not busy enough not to have anything to say. I was also involved in episode 7, on 100 Rogues, which I neglected to post earlier.

Wednesday, 12 October 2011

I seldom mention other roguelikes being released, but I think this one is a little special. We recently discussed Brogue on Roguelike Radio and the first line of the Brogue 1.5 change log caught my eye.

I asked Pender the obvious question 'How random are these? Will you get the same lock and key puzzle in the same room every time?'. His response has got me genuinely excited:

Pretty random, and definitely not. The level geography is generated
randomly, and then the quest room function takes over, picks a quest
room type (of which there are currently 17, defined by the data in a
master blueprints table) and scans the level to find discrete areas
that meet certain requirements of that quest room -- e.g. a dead-end
area of certain size range that is dominated by a single chokepoint
cell. Then it adapts that area to serve as that kind of quest room.

He goes on to describe a nifty flood trap (that you may want to avoid reading to not spoil yourself) which is completely dynamically generated and triggered when you get a key from the centre of the room. And the puzzles can have dependencies on each other:

So the key that you take from the room, assuming you escape, will be
used to unlock a door elsewhere on the level. These locked rooms can
be nested within each other, as can the rooms that guard the keys, and
it is always possible to unlock them all in a single game

Monday, 10 October 2011

I hate to see a developer getting burned by speaking to the public frankly about the issues they experienced during development; but the sheer idiotic rage of PC fanbois when John Carmack stands up and speaks his mind has to be seen to be believed.

As far as I can tell, there are two (actually 3) problems with Rage:

1. Six years ago when they began developing the engine, Mr Carmack made an (incorrect) call that the PC was not going to be significantly more powerful than consoles when RAGE was released - which he has spoken about at length.

2. id was anticipating AMD would have a graphics card driver released prior to RAGE being released which had the correct OpenGL extensions and/or performance necessary to handle the code RAGE is using (and AMD did not - in fact they made things significantly worse by releasing some Battlefield 3 beta drivers which bundle an 'ancient' version of the OpenGL drivers).

Sure, John isn't helping things with making public statements prone to misinterpretation, but he's staying consistently on message about this.

The third problem is the technology itself. The megatexture technology uses virtual texturing, in a similar way that the processes on your computer uses virtual memory, so that the actual texture can be much larger than what the graphics card can fit in its memory - with megatexturing it is in the 10s of GBs on disk. Reading some of the patch and graphics tweaks notes, it is also compressed, with both the GPU and CPU tasked with decompressing the texture on the fly with preference given to maintaining 60 FPS. What this means in practice is that you cannot compare your computer's performance running RAGE, to any other game that you've played (even ignoring the additional complication that id is pretty much the only company to use OpenGL instead of DirectX drivers).

The reason boils down to what parts of the computer are getting stressed enough to become a bottleneck. In a traditional game, levels are hand designed so that textures can be loaded (relatively) far in advance, so that the disk performance is almost never an issue - it is occasionally, because you get pop-in - typically at a scene start, but that may as much of an issue with the I/O bandwidth between main memory and the graphics card as between disk and main memory. With RAGE, every part of the computer becomes a potential performance problem - disk, disk cache latency, I/O between disk and main memory, CPU, GPU, I/O between main memory and CPU cache, CPU cache misses, I/O between GPU and main memory and/or CPU cache, GPU memory, other processes running on the system etc. It is highly likely that you have something slowly down one of the areas I've listed that you're not aware of, and a system which stresses all of these will only run as well as the slowest part. To take one example: if you've got a relatively full non-SSD drive before you installed RAGE, not only will you have disk fragmentation, but the files will be written to part of the disk which rotates slower under the drive head, which means that the data will be read from the drive slower.

(The consoles have a significant advantage here, because everything except the game can get out of the way - for instance, you are not running anti-virus software on your Xbox 360 or PS3; and the developers can write to 'bare metal' bypassing the abstraction layer required to support multiple graphics cards.)

So what possible reason could id have with going with such a high-risk design? Well, I'm guessing for much the same reason that every operating system now uses virtual memory - it incredibly simplifies the process of development. Under older memory management systems, such as OS X 9's segmented memory model, and (heaven forbid) DOS's flat memory model, you had to worry about a whole lot more variables: such as the maximum amount of memory you could be allocated at one time, whether that memory was 'near' or 'far', whether another program was attempting to access the same memory, and so on. With virtual memory, memory is always yours, flat and you can effectively have as much as you want (within the limits of the address space) provided you don't try to access all of it at once - the operating system handles the underlying details (relatively) transparently.

With megatexturing (and other virtual texturing methods) you don't have to worry about a texture budget for each discrete level: you just go ahead and design whatever you want, and the underlying engine will handle all the loading and unloading of the parts of the texture that are within (or close to) the actual field of view.

If you've been following John Carmack's public statements in the lead up to RAGE's launch, and have enough understanding of how computers work, none of the above should be a surprise to you.

Equally which, if you have enough of an understanding how people work, none of the subsequent overreaction should be much of a surprise to you either. But the subsequent un-PR-filtered statements by Mr Carmack are doing nothing but add to this overreaction. Which is unfortunate in the extreme, because from all appearances, the technology is the right approach to solving the issue*. Almost as unfortunate as Zenimax' decision not to license it, and likely prohibition on releasing it as open source at some point in the distant future.

Tuesday, 4 October 2011

Is up at Roguelike Radio. It's another episode where I say I really enjoyed the game and then spend most of the episode bringing up flaws and making over the top statements that I already regret making. I'm going to follow up with a blog post to clarify some of the stuff I'm talking about.

About Me

I'm a IT manager from New Zealand who has spent 5 and a
half years in the United Kingdom, and 4 years in Australia. I live in
Sydney, Australia with my wife and twin daughters, and spend my free time at the moment developing Unangband and blogging. I also wrote as the Amateur for GameSetWatch.