For some light reading, you may want to refer to the recent controversy of Dungeon Crawl Stone Soup removing mountain dwarves from the game.
Sunday, 30 October 2011
Off to the Fortress
Posted by Andrew Doull at 13:43 5 comments
Labels: dungeon crawl, game design, links, roguelikes
Thursday, 27 October 2011
Tuesday, 25 October 2011
The first rule of Band club
Posted by Andrew Doull at 10:04 0 comments
Labels: roguelike radio, roguelikes
Monday, 24 October 2011
Sunday, 23 October 2011
Anquestria
Anquestria is a My Little Pony Angband variant.
Is this some kind of meme I missed out on?
Posted by Andrew Doull at 14:52 3 comments
Labels: anquestria, links
Friday, 21 October 2011
One fish, two fish
In a brief follow up to my earlier note, for you maths grognards out there, Ridiculous Fish has improved his fast maths integer division algorithm - proof included.
Posted by Andrew Doull at 21:25 0 comments
Labels: links
Thursday, 20 October 2011
Roguelike Radio - Episode 8 (Progression Systems)
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.
We're on iTunes so please rate and comment on the podcast there to help spread the word.
Posted by Andrew Doull at 16:07 1 comments
Labels: links, podcasts, roguelike radio
Friday, 14 October 2011
Something fishy going on
It's not often you see something like this in the Steam patch notes:
- Dramatic increase in performance for low-level math libraries
Posted by Andrew Doull at 21:45 4 comments
Thursday, 13 October 2011
C-
Where I respect what Steve Jobs achieved, I wouldn't be writing this blog without Dennis Ritchie.
Posted by Andrew Doull at 17:36 2 comments
Labels: links
Wednesday, 12 October 2011
Brogue 1.5 released
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.
Dungeons now include interactive “quest rooms,” which include lock-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:
and-key puzzles, collapsing/flooding terrain, hidden items, elaborate
traps, challenges, boss monsters and more.
Pretty random, and definitely not. The level geography is generatedHe 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:
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.
So the key that you take from the room, assuming you escape, will beFor the full explanation, change log and download links, see the Google groups thread.
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
Posted by Andrew Doull at 15:30 0 comments
Labels: brogue, procedural generation, roguelike radio, roguelikes
Monday, 10 October 2011
Rage on RAGE
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.
*Except that apparently ray tracing is.
Posted by Andrew Doull at 08:10 6 comments
Labels: game design, game industry
Thursday, 6 October 2011
Roguelike Radio - Bonus Episode (Interview with Ido Yehieli)
Is now up at Roguelike Radio.
I've been trying to persuade my fellow podcasters that we should be calling these bonus episodes @sides, to little effect.
Posted by Andrew Doull at 10:11 0 comments
Labels: links, podcasts, roguelike radio
Tuesday, 4 October 2011
Roguelike Radio - Episode 6 (Dungeons of Dredmor)
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.
We're on iTunes so please rate and comment on the podcast there to help spread the word.
Posted by Andrew Doull at 14:36 3 comments
Labels: links, podcasts, roguelike radio