In the course of designing a pen and paper RPG (ongoing for a few years now), I have sketched out the following damage scale:
1 A blow capable of temporarily incapacitating; a solid punch to the jaw or floating ribs, a gunshot wound (any location), a solid blow to any limb or the body from a melee weapon; first degree burns; tear gas
2 A blow rendering unconsciousness or blood loss causing unconsciousness; either a gunshot wound to the head (nonfatal) or a solid blow to the head from a melee weapon; strangulation (2 minutes); second degree burns; nonfatal exposure to chemical weapons
3 A fatal blow or blood loss resulting in death; or strangulation (10+ minutes); third degree burns; nerve gas
4 A fatal blow which severs the head or cuts the torso in half; fire or acid which chars the flesh of a corpse leaving no skin or hair
5 Repeated blows or explosives which reduces the body to lumps of flesh; this level of damage could be caused by an enraged mob to a helpless individual over the course of 10 or 15 minutes; fire or acid capable of consuming flesh but not destroying the bone
6 Mincer or grinder which reduces the body to a flesh paste; or in the path of detonation of a shaped charge; fire hot enough to reduces the body to ash or acid to dissolve it to soupy remnants
7 Thermonuclear explosion; chemical processing of body using for example concentrated acid; or specialized equipment capable of evaporating flesh
8 Disassembly by nanoscale machinery; exposure to surface of the sun
9 Disassembly to atomic components; exposure to core of a neutron star
10 Exposure to singularity; exotic methods of reducing to component quarks or strings
Care to guess what the game is about?
Wednesday, 28 April 2010
Damage scale
Posted by Andrew Doull at 21:37 14 comments
Labels: game design, rpg
Wednesday, 21 April 2010
Valve reduces their carbon emissions profile
Also designs games better than Zynga, CCP (makers of Eve Offline).
Posted by Andrew Doull at 12:08 0 comments
Monday, 12 April 2010
Sunday, 11 April 2010
Data design for Civilisation games
I seem to have Civilisation on the brain at the moment; and with the recent 0.6.4 release of Unangband out the door have been spending some time looking at the Freeciv project. If you're looking for roguelike game design, you might want to stick around though, because I'm going to be discussing data file design in some detail.
Freeciv is a Civilisation clone, written originally as an exercise in client server programming (There's a nice history summary at the bottom of this AI discussion). Its implementation of the various Civilisation games falls somewhere between Civilisation 1 & 2 as Alex Mayfield points out the last time I mentioned my Civilisation Revolution house rules. Luckily for me, much of the unit design is very similar to Civilisation Revolution so it seems quite possible that I may be able to get away with limited amounts of source code changes.
The mod system that Freeciv uses is quite similar to the Angband edit file system - with the exception of the format which is seems influenced by the Windows .ini file format. A mod in Freeciv consists of a number of rulesets which are used to initialize data structures with values and flags which impact the game play for that unit. A typical Freeciv unit may have the following format in the units.ruleset file:
[unit_warriors]Contrast this with an Unangband monster entry, and you'll see there is not a lot of difference, other than the format which defines how the values are read in:
name = _("Warriors")
class = "Land"
tech_req = "None"
obsolete_by = "Pikemen"
graphic = "u.warriors"
graphic_alt = "-"
sound_move = "m_warriors"
sound_move_alt = "m_generic"
sound_fight = "f_warriors"
sound_fight_alt = "f_generic"
build_cost = 10
pop_cost = 0
attack = 1
defense = 1
hitpoints = 10
firepower = 1
move_rate = 1
vision_radius_sq = 2
transport_cap = 0
fuel = 0
uk_happy = 1
uk_shield = 1
uk_food = 0
uk_gold = 0
flags = ""
roles = "DefendOk", "FirstBuild"
helptext = _("\
This unit may be built from the start of the game. It is the\
weakest unit.\
")
N:24:Small goblinOne initial observation is the Unangband file format encodes a lot more information in much less space. We could reduce the total length of the Freeciv warriors entry to about half the current length by adopting a similar context-dependent format, as opposed to the more context-free format that Freeciv uses. We know every Freeciv unit has to have an attack/defense/move/vision/firepower and upkeep values, so there is no need to have each of these defined on a separate line: and the user interface itself can be used as a guide for how we can lay out the values more compactly in the ruleset file format.
G:k:y
I:110:8:20:16:10
W:2:1:0:4
M:0:0:1:0
B:HIT:HURT:1d5
F:DROP_60 |
F:OPEN_DOOR |
F:ORC | EVIL | IM_POIS |
F:HAS_SKULL | HAS_SKELETON | HAS_TEETH | HAS_CORPSE | HAS_HEAD | HAS_HAND |
F:HAS_ARM | HAS_LEG | HAS_BLOOD | DROP_MISSILE | DROP_TOOL | DROP_WEAPON |
F:DROP_CLOTHES | DROP_ARMOR | DROP_FOOD | DROP_JUNK |
F:SCENT | DWARF |
D:It is a squat and ugly humanoid figure.
This may not sound especially important, but from the perspective of quickly editting multiple entries - for someone trying to mod the game - screen real estate is a valuable commodity.
The second observation is that the Roles in the warriors unit in Freeciv are not intuitive, in the same way the Unangband flags are. You can guess straight away from looking at the goblin entry the ways that HAS_HAND and DROP_WEAPON might be used in the game. DefendOK may make sense, but FirstBuild? In some ways, this may be an issue with the fact we're dealing with an agglomeration of multiple individuals rather than a single entity, but it is worth bearing in mind that defined roles (and flags) may not 'natural' and may be worth redesigning.
There is a significant difference between the way roguelikes and Civilisation games play that is not reflected correctly in the similarity between the two file formats. Roguelikes rely on your ability to learn and understand special abilities and unique effects and which one to use at any point in time. The fact that small goblins are immune to poison makes a significant difference only if you are facing a small goblin, and have a choice between a poisonous and non-poisonous attack. So a binary flag is an appropriate way to reflect the criticality of this decision.
Civilisation games on the other hand, rely on the aggregation of small differences over a large number of units, and so scalar values are much more important than binary flags. The fact that a warrior can defend a city is much less important than the attack and defense values of that warrior: a difference of only 1 in attack strength is the difference between success and failure of a particular combat, but that combat may be played out multiple times in a single game, which converges towards an average result in a way that a roguelike does not. If you want to think about it another way, most roguelikes allow you to reset to your starting position of full health at any point during the game with a single item - Civilisation games don't allow you to reset to your full complement of warrior untis.
So while the Freeciv file format is undoubtedly a natural evolution from moving hard-coded game data to an external file the same way that Angband does, I believe there is significantly more value to be gained by extending the file format of Civilisation in interesting ways.
If you look at my Civilisation house rules, you'll see a lot of rules of the format 'with technology/civic/building', unit X gets Y, where Y is often a modification to an existing scalar value of some kind. Or more importantly, the set of units of type Z get this change, where Z could be all units, mounted units, pre-gunpowder units and so on. It would be extremely useful and flexible if we could encode this into the Freeciv ruleset without having to have flags refer to hard coded bonuses in the game code.
There's a couple of ways of considering how to do this. We could go with a full blown scripting model, where each unit runs a script to determine which modifiers apply to it's basic values, and the avaible technologies, civics, buildings and so on are exposed to the script system to check. However, I'm uncomfortable with a full scripting system, and I think we can do this in a simpler fashion.
Imagine a unit as a collection of scalar values and properties. Some properties are intrinsic to the unit ('on-foot'), some properties are dependent on the civilisation ('the-wheel-technology', 'democracy-government'), some are global ('nuclear-winter','global-warming') and some are positional ('attacking-city', 'defending-forest') or modal ('fortified'). A unit type then defines a set of rules where the unit having the matching property modifies either a scalar value through setting the value, addition, multiplication or scaled by percentage, or through the addition or removal of a property for that unit. We can use properties to also indicate that the unit is a member of another unit type, which also has a set of rules which further define the unit and so on.
We can then determine the unit scalar values by starting with the base unit type, and matching rules from that unit type and the rules from its properties, applying the effects of each rule exactly once.
For instance, one unit type might be as follows:
military-unit = {
can-attack;
can-defend;
fundamentalism-government:+1 attack;
...
}
We can also evaluate scalar values instead of properties.
military-unit = {
...
experience>=3:veteran;
veteran:+50% attack;
veteran: +50% defence;
...
}
One important extension to this is that the units have to be able to affect other unit types. For instance, aircraft cannot be attacked by ground units.
aircraft = {
*ground-unit:-can-attack;
...
}
And we have to be able to override this:
anti-aircraft =
{
*aircraft:ignore;
...
}
where ignore is a reserved value that prevents the associated property from being processed.
I'm still in the early days of sketching this out, but I hope this will be an improvement on the existing Freeciv rulesets. The implementation of this design will, of course, be another complication.
My question for you is whether I'm reinventing the wheel here? I believe this is a design pattern that multiple games must have confronted before, and there should be something that already does this work for me, short of going to a full scripting system like Lua.
Posted by Andrew Doull at 11:22 0 comments
Labels: civilisation, game-design
Saturday, 10 April 2010
Request for donations for Angband site hosting
Takkaria is asking for contributions towards hosting the official Angband site:
Server hosting for rephial.org currently costs $38/month, which is a quite a bit of money. We started off on a lower-price plan but we received enough in donations to switch to a higher one for a while, which has made using the bugtracker much more bearable. Now we've run out of funds from the previous drive, so we're looking for more donations to keep things running as they are.I'd like a non-Paypal donation method if possible, as I'm unable to access Paypal and have been unable to for years.
There's no pressure to, but if you would like to contribute to Angband development monetarily then please do at http://rephial.org/donate. If you want to remain anonymous, that's fine by me, but I like to publish people's names to recognise their contribution.
Posted by Andrew Doull at 12:22 0 comments
Monday, 5 April 2010
Unangband 0.6.4 released
This is the "Once your variant gets a nowhere town, it will never leave" release aka "Wasn't this supposed to be out months ago?"
You can download the source code from http://prdownload.berlios.de/unangband/unangband-064-src.zip. You can download a precompiled Windows build from http://prdownload.berlios.de/unangband/unangband-064-win.zip, a pre-compiled Mac OS/X build from http://prdownload.berlios.de/unangband/Unangband-0.6.4-osx.dmg. A Linux version should be following shortly. [Edit: Now available at http://prdownload.berlios.de/unangband/unangband-064.tar.gz - thanks to Mike].
For more details, please see the official website.
I've not spent nearly enough time quashing bugs, but real life has left me pretty drained at the end of the working day. I'm sure my motivation levels will pick up soon enough - just need a little holiday from staring at the source code.
Posted by Andrew Doull at 13:54 1 comments
Sunday, 4 April 2010
One Man, One Vote
For anyone who's up for Civilisation Revolution challenge games, may I suggest the following: No Democracy challenge, playing on Diety. The only restriction is you may not use the Democracy civic - Greeks have to change away from that Civic on their first turn.
The game suddenly becomes a whole lot more balanced and interesting, as I suspected.
Posted by Andrew Doull at 08:49 0 comments
Labels: civilisation, game design
Saturday, 3 April 2010
Re: Engineering
I've came up with suggestions some time ago about what alternate weapons the Team Fortress 2 Engineer should have. But since then, Valve have released several subsequent updates which have considerably changed how the Sniper, Soldier and especially the Demoman play and a beautiful crafted fan page has suggested some alternate turret weapons. And, in case you've missed it, the last major update to Team Fortress 2 added a chocolate bar for the Heavy and several melee weapons (One for the Pyro and one shared between the Demoman and Soldier).
So the scope is there for the Engineer to have more than a few additional items added: either as a part of the update, or in further releases.
Looking back at the suggestions I made: the Quik-R-Ratchet, or a variant thereof has already been tested in beta as the PDQ; the Scout order book suggestion existed at one point as a backpack but was not adopted; the I-Spy-Shooter is fine, but not amazing - and having played my first 35 point Spy game yesterday, I now feel qualified to state its hard enough already to sneak up on an engineer that I think there are better alternatives; and the BRB still feels distinct enough to be useful - perhaps also allowing the engineer to teleport even if his exit is sapped.
I'm still not convinced that the engineer needs alternate buildings - the only one from the fan page that feels 'right' is the multi-mode flying turret - and Valve themselves have pretty much ruled out replacing the teleporter or dispenser. Buildings that provide various buffs (kritz, minicrits, invulnerability) make the buffs that other classes provide less special, and similarly turrets that provide alternate attacks lessen the uniqueness of class weapons. And anything that affects the small window of opportunity between backstabbing an engineer and having the turret turn and shoot you while you try to sap it, is going to affect the balance of Spy vs Engineer encounters - which of the ways of taking out turret emplacements is the most interesting and least frustrating for the Engineer.
Here are some more Engineer item suggestions:
Gone Again Guitar: While playing the Gone Again, the engineer and all nearby friendly buildings become invisible and do not have any effect or attack enemy players. The Gone Again plays as a taunt animation for a fixed duration with a cooldown. Why: There needs to be a guitar based weapon for the Engineer, and something which allows the Engineer to build in an open location and then draw in the opposition should be fun. Especially since you'll be able to hear him play, but not know where he necessarily is. Replaces the Shotgun.
Ranch Home Rivetgun: The Rivetgun is a ranged weapon similar to the medic's primary weapon, but with a slower rate of fire, much smaller magazine capacity and more damage per shot (about 25% more DPS than the medic). However, the Rivetgun also repairs friendly buildings it hits - at approximately the same rate as hitting it with a wrench. Why: this allows the engineer to repair their buildings while not necessarily next to them - letting them roam with confidence. Since the repair depends on ammunition, it should be a shorter term improvement, and this is balanced against wrenching because the Rivetgun doesn't resupply buildings or remove saps. Replaces the Shotgun.
The Cowpoke: The Cowpoke is a crossbow with a barbwire drawstring and a red hot poker for a bolt. The Cowpoke has better range than the Sniper's bow, but does less damage, and has a much slower reload. Friendly turrets turn twice as quickly when tracking targets branded by the Cowpoke. The Cowpoke replaces the Shotgun. I had planned on making this a melee weapon but realized that a) hitting a building with a branding iron doesn't make a huge amount of sense and b) making this a ranged weapon encourages the engineer to run forward and tag upcoming targets. Note that this doesn't prevent a Spy from disguising or turning invisible - just when the Spy becomes a valid target they get tracked that much quicker.
Stand Tall Spurs: The stand tall spurs allow the Engineer to pick up and move his buildings. If the engineer is hit while moving a building, the building takes damage as well as the engineer. The Stand Tall Spurs replaces the Shotgun - left click to pick up, and then place the building using the original building placement commands. There is a short set up time when the building is placed again (2 seconds) before it comes fully active.
Well-done Arc Welder: The Well-done allows you to buff all nearby buildings temporarily which reduces damage to them by 50% for explosives and 25% for all other damage types, but means you take twice as long to upgrade your buildings. The buff lasts for 15 seconds with a 45 second cool down and appears to be a shower of sparks coming off the affected buildings. Why: an invulnerability buff is tempting, but would completely stop an ubercharge against a building in it's tracks. Whereas a buff may tempt both the attacker and defender to hang around. By biasing the damage reduction against explosives, it reduces the effectiveness of classes the most which don't have to expose them to direct line of fire of the turret to destroy it. Replaces the Wrench.
Good 'ol Grappling Hook: I've waxed lyrical about the next for a grappling hook in Team Fortress 2 long enough - hit a building or map section and you are pulled towards it, hit an enemy player and they are pulled towards you. This would completely unbalance the Engineer, allowing them to aggressively move forward and put turrets in unexpected locations, as well as drag an opponent into their turret's line of fire. I think the craziness would be worth it though - especially after the fun I had with the Demoman replacement weapons. To balance it: the grappling hook prevents you upgrading any building or speeding up construction because it replaces the Wrench. I'd hate to have to contend with a level 3 turret somewhere I hadn't planned on looking.
Posted by Andrew Doull at 11:56 0 comments
Labels: articles, game-design, links, tf2
Thursday, 1 April 2010
4/1 = Fooled?
I'm writing this in advance, so I'm unsure of the reaction to my leading you down the garden path to a mythical land of CGI dwarves. I hope you've enjoyed the process - I certainly had fun putting the story together, weaving together fortunate coincidences with real world personalities and outrageous lies. If you've read this blog long enough, you should recognise my penchant for mixing reality and mythology: my personal highlights have been reviewing an alternate reality World of Goo and projecting Eve: Online into the near future - but any review I've written has launched from a sudden thought into faraway fantasy. As the Toady One put it when I ran the idea past him, it's been 'intense'.
One regret I've had with this blog has been I never remember April 1st early enough: should I do so in the future, there are some well planned sucker punches taking advantage of the fact Australia is 16 hours ahead of anywhere interesting. But I'll leave the details until another day.
I've always found the art of hoax an enjoyable and fascinating experience. The best hoax I've been swept along for the ride with is Peter Jackson's Forgotten Silver - an underrated docudrama which for a magical moment on a Sunday evening captured the hearts and minds of most New Zealanders. My mum pointed out the flaws first: there are few lost cities on the west coast of my homeland, an island which has been inhabited for all of 600 years, but even once you've figured out the plot, a good shaggy dog story should throw you enough in-jokes to keep propelling you forward. I didn't have a Colin McKenzie dying on camera to finish up with, but a mashup of Team Fortress 2 and Dwarf Fortress provided enough ideas to keep me moving to a semblance of a conclusion.
The typical reaction to falling for a hoax is outrage. I want you to put aside that emotion as much as you are capable of and celebrate another - imagination. If you fell for my story, it is because the seeds I planted fell on the cherished soil of fertile and optimistic dreamworld. This should be something you should be proud of. You have the capability to rise above the mundane and cynical, escape the clay around your boots and float away on boundless escapism. You are a gamer.
Posted by Andrew Doull at 13:53 7 comments
Dwarf Fortress 2 open beta coming soon (design notes - part eleven)
PS: Frender, I really miss you. BFF?
Posted by Andrew Doull at 11:36 4 comments
Labels: blogging, development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part ten)
I've got plenty more design notes, but I think you should just get over to the official announcement where you can register your interest.
Posted by Andrew Doull at 09:31 0 comments
Labels: 7drl, development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part nine)
Everyone starts with the camera beard hat unlocked. You may have guessed that we're going with a steam punk theme, and there is nothing more steampunk than a camera beard hat. I'll say it slowly for you. Camera. Beard. Hat.
If you've linked to this announcement from Boing Boing, you may need to get some tissues now.
Posted by Andrew Doull at 08:06 0 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part eight)
Rather than being skill based, we went with a class based system which is much more representative of the original Disney movie. The classes are Heavy, Scouty, Snipy, Engy, Demi, Soldy, Pyree, Spyee and Doc. To create minority interest, we've left hints that Demi is possibly female, transgendered, sexually ambiguous, straight, gay, black, Amerindian, Hispanic, Scottish, one-eyed, dating Ashton Kutcher and Republican. Luckily, with the full facial and forehead beard, you'll never be able to tell.
Posted by Andrew Doull at 06:05 2 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part seven)
DF2 is entirely first person view with the fuzziness at the bottom of the screen being a Hollywood cinematic effect used to represent the size of your dwarf's beard. Hideo liked this idea immensely when we showed him the alpha in a private alpha at GDC, but I suspect there were translation issues as he went on to implement a side beard in Metal Gear Solid 3.
You should attempt to increase beard length for additional unlocks, like a sandwich and a jar of urine. And in the game.
Posted by Andrew Doull at 05:35 2 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part six)
There are some other radical changes that you should be aware of before you download the beta client. One of the first suggestions Tarn came up with when I asked him what he wanted in Dwarf Fortress 2 was 'More dwarves', so you now start the game with 9 dwarves instead of seven. That's been the basis of the viral marketing ARG that we've been running, so if you see 7+2 =9 anywhere, you should strip search anyone nearby who is unusually short of stature or has a beard so you can find the next clue. My next few posts will also have sequences of letters randomly underlined, which should be used to send morse signals across an old Atlantic telephone cable we found to unlock a stenographic photograph of Scamps. And Microsoft have kindly reprogrammed Windows to randomly include a blue screen of death featuring an ASCII rendition of Gabe Newell which will haunt your dreams.
Posted by Andrew Doull at 04:24 1 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part five)
We were confident enough at this point to open up DF2 to a select group of beta testers and put feelers out to those we knew would take an interest in a multiplayer procedurally generated kick ass fantasy world. It was one of these, Randy Pitchford who was ultimately responsible for the radical change in direction of the visuals for DF2. Randy was concerned that the look of DF2 was 'too shit brown': mostly because he kept locking the doors to the washroom in the fortresses he built, so his dwarves would work overtime. We brainstormed this over Skype - and during the chat, it was almost like a light bulb went off above both our heads at the same time. There was a power cut in my house, and Randy was turning off the lights to save on power bill costs since the light from the monitors was enough to keep his developers awake while they worked overtime. When we reconnected, we were both babbling 'how about red and blue'. I made Randy promise that we'd get to use the look we discussed for our game, not his, and started revising the engine.
What you see in the open beta of DF2 is the original engine ultra-realistic graphics, which are then rotoscoped and painted using another algorithm Chris came up with. Overall, the look was well received by our beta testers, except Eskil Steenberg, who suffers from a rare visual condition that means everything he sees looks like an impressionist painting and who found the new appearance 'derivative'. I'm telling you this story now, ahead of you playing the game, so you don't blame Chris for cartoon like appearance.
Posted by Andrew Doull at 03:57 1 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part four)
With Chris on board, the pace of development improved considerably, and we were able to include version 2 of the procedural animation system that Spore used, translating the Dwarf Fortress raws that Tarn was building into life like models complete with advanced moves like floppy legs and crab walking that hadn't been possible with the original engine.
Prior to Chris joining, we had done some experimentation with mo cap through a contact of mine at Weta Works. While this didn't pan out, we did use the Battle of Dagorlad from the first Lord of the Rings movie as a reference for DF2 fortress invasions:
Apparently the reason there are no dwarves in this battle is that Peter Jackson wasn't happy with the CGI animation at the time: he felt it couldn't capture their natural grace and athleticism.
Posted by Andrew Doull at 03:20 1 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part three)
Chris had spent half of 2008 personally replying to every abusive email he had been sent by disappointed purchasers of Spore - including the ones I was procedurally generating using the DF2 Markov chain code. I've not included my original email because removing the more extreme expletives renders it unintelligible, but here's the remaining correspondence, for your edification:
It's clear that you have a passionate love of games. It's just you don't understand the pressure we were under, and you have to admit the final result is still impressive.I would like to apologise now unconditionally for anything mean I've said about Chris, or anyone else who worked on Spore. He is an incredibly hard working and talented individual, and I've learned over the intervening years that in any large software project, compromises have to be made. It turns out that Will was right, and was ultimately responsible for the decisions that led to Spore being a less than completely hard core reinvention of every game genre that ever existed. It's just a shame he wasn't involved in DF2, like Chris was.
-- Chris
[text removed]you, you piece of [text removed]. I could do better. In fact I have: [link removed]
Regards,
Andrew Doull
Wow. I don't know what to say except: how can I get involved?
-- Chris
Posted by Andrew Doull at 02:50 5 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part two)
Sam had an agreement with Intel to allow him to license the Offset engine as open source, much as John Carmack had made available earlier iterations of the Doom and Quake engines, and he was willing to make the engine available as an alternative front end for Dwarf Fortress, provided Tarn opened up the DF code.
While Sam's suggestion was appealing, Tarn and I had both moved on considerably from the original Dwarf Fortress concept, and we decided instead to branch the DF code base, and split the work three ways. Tarn would continue to maintain the DF1 code, while I would work on the DF2 code with Sam consulting after hours as time was made available.
Why did I end up being lead developer? Real Life had thrown me a curve ball, in the form of the global financial crisis, and I had lost my job and had to move into my parents basement with my wife. The situation was highly embarrassing - why is why I've not mentioned anything about my personal life on my blog - but it meat I was able to spend a considerable amount of time integrating the code, and building a front end using the Offset engine. The visuals were so impressive that it made the only other 3d Dwarf Fortress viewer available at the time, 3Dwarf look like Populous.
I want to show you this segment from Sam McGrath's demo of Project Offset on Attack of the Show - mostly because I spent about 18 months with the dwarf render Sam shows off to start with. We ended up calling the model Frender because we used him so often as a place holder. He used to get pretty messed up by some of the AI bugs we encountered - if you've read the Dwarf Fortress development logs you'll have an idea of the kind of situations he found himself in.
With the procedural character generation algorithms we use in the beta, you'll have a 1 in 63,000,000,000 chance of running into an exact copy of Frender in the final game:
You don't see it on camera, but a friend of Sam's who was at the filming of the show says that he did an incredible double-take when the host mentions another game with the word Fortress in the title. He recovers by the time they cut back to him, but I wonder if this is where the seed of the idea was first planted.
We knew even from early game play testing, that we had something special, and Tarn started devoting his special project days at the end of the month checking in his 'downstream' Dwarf Fortress changes into upstream DF2 improvements.
It was about this time that Chris Hecker became involved.
Posted by Andrew Doull at 01:56 2 comments
Labels: development updates, df2, releases
Dwarf Fortress 2 open beta coming soon (design notes - part one)
After Dwarf Fortress won the Ascii Dreams Roguelike of the Year 2007, Tarn Adams and I started corresponding by email, discussing our shared love of the roguelike genre and where we thought the genre was going in the next few years. I believed then, and still firmly believe, that I saw procedural content generation replacing the need for level designers, which meant that we could throw aside the shackles of tunnel like level design and replace it with roaming open worlds, generated on the fly as you explore the landscape. Tarn aka the Toady One was drawn to the idea of having a 3d graphics engine based fantasy world and that he'd made significant architectural mistakes in going with a tile based design and would need to start again from scratch to met this goal. For a while, that is all that Dwarf Fortress 2 consisted of: a long email chain brainstorming ideas and filled with blue sky thinking.
The release of Spore was like a body blow. That so much impressive developer talent that ultimately been wasted creating a universe filled with curate's egg worlds left us both feeling devastated and at a loose end. I particularly had high hopes for the game, and felt Will Wright had betrayed both himself and his team by deciding to go with cute, instead of (r)evolutionary.
It was about this time that Tarn was contacted by Sam McGrath, of Project Offset fame. Offset Software, as it is now known, had been acquired by Intel, and Sam was concerned that much of the original concepts for the project would be delayed or diluted by the corporate culture that Intel was imposing. Project Offset, for you not familiar with the concept, was an engine designed to allow rapid prototyping and development of 3d art assets using procedural techniques - which Sam had turned into an impressive set of technology demos with the intention of building an open fantasy world. I've included one demo below, just so you can see where we were starting from with DF2:
Posted by Andrew Doull at 00:46 8 comments
Labels: development updates, df2, releases