Planet Roguelike & The Oblong

Planet Roguelike is a new feed aggregator for roguelikes featuring a number of roguelike blogs that Altefcat recently announced on rec.games.roguelike.development, that you may wish to have a look at. It has all the usual suspects, but a few new blogs that I wasn't aware of...

including the Oblong, which features an as yet unnamed roguelike under development by Snut. I've included a screen shot from the left of the impressive 3d engine he's building the game with. Please note that these levels are procedurally generated...

Poll results for 'What of the following games are procedural'; new poll.

Thanks to the 17 people who voted, following my article debating Minesweeper vs Solitaire and the interesting comments following it. The results are:

Minesweeper	11 (64%)
Solitaire	3 (17%)
Poker	2 (11%)
Poker, once the cards are dealt	4 (23%)
Black jack	1 (5%)
Black jack, once you've counted enough cards	4 (23%)
None of the above	6 (35%)

Next up: which game featuring procedural content are you the most looking forward to?

Share a little Love

Rock, Paper, Shotgun's Jim Rossignol has pointed out that Eskil Steenberg has a blog, Quel Solaar, that if you are into procedural generation is well worth following. For those of you who don't recognise the name, he is one of those hero-developers who is writing a procedurally generated massively multiplayer game by themselves. I've linked to Love previously, but I recommend you bookmark his site for further perusal, even if it is just to stare in amazement at the beautiful in-game screenshots.

In other news, there has been a huge amount of development on the procedural game front. It seems like every A list game property is including some procedural generation these days (And even old returning favourites like Diablo III).

Here's a brief excerpt from the update I've just put on the procedural generation wiki:

June 29, 2008
Screen shots of Love

June 28, 2008

Comments by Jay Wilson, lead designer of Diablo III

June 27, 2008

Keynote by Chaim Gingold, former lead designer of Spore on Magic Crayon approach to design.

June 26, 2008

Video of game-play from Far Cry 2.

Rescue: The Beagles wins the TIGSource Procedural Generation Competition.

June 24, 2008

Interview of Lucy Bradshaw, executive producer of Spore.

Video of game-play from Left4Dead.

Interview of Gabe Newell on AI director in Left4Dead.

Designing a Magic System - Part Five (Effects: Resets, Keys and others)

(You'll probably want to read parts one, two, three and four before starting this).

3. Resets

Problem: The player can end up in many inescapable situations in game without necessarily realizing it - the game over maybe minutes or even hours down the track, but because the player is still alive, they continue playing even though they do not have the necessary means to finish the game. This may be because the player is suffering too much attrition to their hit points because they are not playing well enough in each encounter against an enemy, or they have failed to master the necessary steps required to avoid a lock or trap.

Solution: Provide the player with a collection of resets, instead of having a single exhaustible resource that is slowly diminished. A reset sets some or all of the player state to its original values, or deletes or removes part of the environment, so that it is no longer an insurmountable obstacle.

In addition to providing resets, the designer should reduce the overall player resources, such as hit points to a much lower level than required to complete the game. This has the effect of letting the player know that they are in trouble and need to improve their game play, much earlier than a huge single health bar would do. Management of the resets becomes an important part of playing the game.

For example, in Angband, the player will suffer many tens of thousands of hit points worth of damage over the game. But starting the player with tens of thousands of hit points will mean that they can progress a long way through the game without necessarily learning the 'correct' skills required to play. By reducing the overall hit points and making management of healing potions and resting important game requirements, the player is forewarned that they have not mastered the game intricacies. (This forewarning takes the form of premature death.)

Resets contribute to avoiding a 'death by a thousand cuts'. But they also contribute to correcting insurmountable game design problems. For instance, one way of avoiding locks is to have a building reset meter, that allows the lock to be escaped through an unbeatable reset - essentially setting the game back to an earlier point of play. Similarly, Resident Evil 4 has a one shot rocket launcher that allows any single boss to be beaten. In the event a particular boss encounter cannot be overcome by the player, they can elect to use the rocket launcher to avoid the fight. Teleportation in Angband can fix issues in the random level design: where too many powerful monsters threaten the player in a single location, either they can escape or teleport the threats away from them. Liberal provision of resets can correct these kinds of hard-to-balance game design issues.

At the same time, resets should be a limited resource. If unlimited, there is no clear point at which a player should stop collecting them. Therefore, game progress can slow while the player tries to minimize the risk of failure by maximising the resources they currently have. Or equally the player can continue to attempt to save the resources for 'a rainier day' and never use them for the current encounter. This is a weakness particularly in RPGs with unlimited inventory. A design where it is obvious how to replenish lost resources will encourage the player to use what they currently have, and not dither around attempting to build up more.

4. Cloaking

Problem: It is hard to accurately represent stealth within a game, particularly a turn based game. Stealth and camouflage in nature relies on the presence of a visually noisier environment than can be currently modeled in game, and as a result, visual artefacts in character models and environmental models usually give away the presence of a hidden enemy much more readily than necessarily desired by the game designers.

Solution: Completely hide the enemy from the player, by removing the character model from the visual field when it qualifies as hidden. Then provide an alternate in game mechanic for detection, which may be as simple as removing the conditions which permit the cloak, having partially visible character models, such as a transparent version of the model, perhaps dripping with water, blood or other environmental effects if appropriate, or have one or more detector abilities which partially or completely reveal the character model when the ability is used.

5. Information

Problem: Information as a strategic resource has been greatly diminished in single player games, as well as many multiplayer player vs. environment games. Blame the rise of sites such as gamefaqs.com, as well as automated software capable of collecting details on the game space. However, the player may still require details about the environment around them if the map they are on is procedurally generated, or the enemies they encounter move in unpredictable fashion.

Solution: Information abilities are usually associated with providing details on the current location of enemies, or otherwise revealing information associated with the fog of war in games (either due to restrictions imposed by line of sight, or maximum perception distance). Information effects can be varied, provide partial or complete, or even inaccurate information to the player. Usually they are associated with the current state of play, but may attempt to make predictions about future events, or reveal past events.

As noted in the problem section, information abilities are less useful if they provide one-time information that remains static from game to game. This is the main difficulty in balancing information abilities: the diminishing returns through repeated play or by players resorting to external information sources (arguably cheating) may result in these abilities being underselected in the long run.

In addition, a trade off must always be made in the user interface to determine how much additional information to show the player, beyond what they are already aware of.

Information abilities may also be used to counter other abilities. This is typically true of the detection ability which counters an enemy's cloak ability. There must be a long term strategic disadvantage to using the information ability so that it remains interesting even once all parties have the information ability. In the cloak example, consider having some enemies have an ability that renders them invisible only when the detection ability is used. The cold suit in Dystopia is an example of this: Stealth is normally countered by switching to Infrared scanning, but infrared scanning renders players with the Cold suit invisible. Obviously, players cannot have both Stealth and Cold Suit simultaneously.

5. Door / key puzzles

Problem: Some abilities designs may not be as useful in normal game-play as intended, or their utility, function or the user interface required to activate them may not be intuitively obvious to the player. This can occur particularly if there are a large number of abilities available to the player. Typically, if the player has more than seven options total, they may have difficulty remembering all the available options at any time.

Solution: Block the player progress until they master a particular ability, by presenting a door puzzle that requires the player use the ability to open the door blocking their progress. The concept of a door is not necessarily literal: it could equally be a river, a lake, a boulder or other feature blocking the players progress, or equally a guardian or end of level boss of some kind, but it should clearly present an obstacle which is initially insurmontable but provides enough hints to suggest that the particular ability is required to overcome it.

This allows the game design to design game content moving forward from the door with the guarantee that the player has mastered this particular ability. For instance, newer content make take the place of skill or timing challenges using that ability or more complex puzzles with interrelated parts which have in-game appearance similar to the initial door challenge.

The risk with a door is that the player never understands or masters the ability, and gives up the game in frustration, or that the player button mashes their way around the problem without understanding the fundamental skills required.

6. Buffs and Build modifiers

Problem: A build and respec system may be used to balance magic abilities by arbitrarily reducing the powers of magic users, such as slower skill development, preventing them using edged weapons, heavy armour or forcing them to carry magic books, esoteric spell casting components or bind demons into their weapons. These disadvantages may be initially balanced, but later in the game cause player frustration as they overwhelm the pleasure of playing the game.

Solution: Provide temporary buffs which overcome some of the disadvantages designed into the initial build and spec system. Many spells can be seen in this light, such as the ubiquitous Shield spell that AD&D mages use. Equally, cure light wounds spells instead of potions, the ability to magically create food instead of carry it in a separate inventory slot, and magical means of generating light in Angband are effectively modifying the 'standard build' of an Angband character.

Buffs and Build modifiers make the build and respec system more complex and care needs to be taken that they do not end up too powerful. This can been seen in versions of Angband prior to 3.0 where mages could learn spells from one magic book that made them more effective fighters than the equivalent warrior - luckily this compensated for their weak attack spells (with the exception of Mana storm and Magic missile).

And it is balancing these attack spells so that they remain useful that is the focus of part six.

Spore: The New Cambrian

The release of the Spore Creature Creator has resulted in a Cambrian explosion of content creation where amateur creature designers have populated the Sporepedia with hundreds of thousand of different creature designs - at least 754,495 to date (at the time of writing) at a rate of more than 100,000 every 24 hours. This is a tidal wave of new virtual life, sweeping up the gamer community in creationist controversy as would-be-gods evolve from the puerile (or should I say penile) to mimicry (of game controllers, Star Wars space ships, gaming icons and pop art) to highly original creations. What challenges beyond the obvious problems of a procedural Hot Coffee mod every minute does this tsunami of content create?

The Spore designers cleverly used PNG chunk types to embed the total content of a single creature into the picture data for that creature - allowing quick and ready transfer of the Spore creatures by dragging and dropping images from the Sporepedia into the creator. They've also incorporated ready sharing of existing content as well as 3rd party media integration with You Tube, and user tagging of creature types. But the huge amount of content has clearly exceeded the ability of the Sporepedia website to deliver it effectively.

At the moment, the Sporepedia interface allows 24 creatures to be displayed per page, and an editorial component of the site has offered up a selection of 'featured' creatures - 40 to date. Rated creatures, that is creatures where second user has provided some rating information on the quality of the creature design, number some 154,000 or so. Searching by tag doesn't appear to be supported - and there is very little other criteria to slice up such a huge database of information, except by individual author.

In order to download Spore creatures, the interface restricts me at best to 24 per page, a microscopic drop in the bucket of the total content out there. Where are the tools to let me download the most popular 10,000 creatures - or to have an RSS feed of the top 100 creature creators so that I can see their new work - or to dedicate 10 GB of my hard disk to automatically fill up with new creature types? How do I define an 'ecology' of creatures, with predators and prey, or a phylum so that I can have a consistent series of creatures evolved from a single antecedent? How else can users organise, sort and select data from a database of this magnitude in an effective manner? Clearly editorial control is failing to address these issues, as can be seen by the ratio of editorial selection to user content. I suspect EA and Maxis have their hands full just removing inappropriate content in this regard.

These issues of information management are at least manageable. Consider another statistic - to date, the Spore Creature Creator tools has populated one virtual game with approximately twice as many different creatures as all beetle species discovered to date. From wikipedia: 'The Coleoptera (beetle) contains more described species than in any other order in the animal kingdom, constituting about 25% of all known life-forms'. In other words, Man (actually avid gamers) has virtually created life at approximately a quarter of the rate that the Bible describes God achieving.

Divine hubris aside, extrapolation from the current creation rate suggests that within a year Spore will have approximately 30 million creature types. Forget the problems of trying to organize this information within Sporepedia - it is unlikely that the human brain is equipped to distinguish this many different creatures. In one sweep, Will Wright and co have created a tool capable of matching or exceeding the Earth's ability to generate new species since it's inception.

It is likely Spore only supports so many types of different creature morphology, and the specific creature characteristics are well defined within the editor. This may mean that the brain is able to filter on less specific criteria than the individual creature, and give the player a chance to recognize the important features of any in-game encounter, without having to refer to Sporepedia every minute of the game. The game design seems to have planned to an extent for these kinds of numbers: the Spore galaxy supports at least 4 billion planets, which suggests after a year of playing, you will only encounter a unique species every hundred planets or so.

The total number of creatures may not be an issue, as much as the player's ability to consume new content. For arguments sake, let's assume that a new creature is encounter every game minute. Over a typical ten hour a week playing pattern, this means the player could potentially encounter 6,000 new creatures - in reality, far less than this. Every year, this is 300,000 creatures, and an adult human lifespan of 50 years of continuously playing Spore, a total of 15 million creatures could be encountered. Therefore, within six months, Spore will have enough creature content to exceed anyone's ability to encounter it all in game in their lifetime.

Spore has created an unexpected set of design problems: the reverse of virtually any other game. There is literally too much content for any gamer to experience; and the tools to manage and select wholesale from this content don't yet appear to be in place. This is an ideal position to be in, and a reason that more and more games are moving to procedural content generation as a part of expanding the overall gaming experience.

What are you doing reading this?

Download. Check out what I've done.

I'm tentatively declaring my career as a game designer over.

I'll expand more later: but lets just say I am amazed by the amount of personality conveyed by the procedurally generated movement system. And how similar the art style is to Wormy.

Taboo Words

Just read a nice article 'Taboo Your Words' by Eliezer Yudkowsky. As I've mentioned previously, I like to avoid degenerating arguments into definitions, and he suggests another way of avoiding this problem - by avoiding the use of the terms you find contentious to begin with.

If you're interested in reading something outside of roguelikes, it looks like Overcoming Bias is has a lot to say.

Designing a Magic System - Part Four (Effects: Locks and Traps)

(You'll probably want to read parts one, two and three before starting this).

The variety of game design patterns to restricting magic is only part of the equation: it is not useful without having an indication of what magical effects should be in the game in the first place. While 'magic' by definition could be an infinite palette of wondrous brush strokes, the vast majority of games again settle on a limited number of design patterns to define how magic works within the game.

1. Damage

Problem: By definition or convention games are be won or lost - and the simulation of warfare and conflict is a fundamental to the earliest of games, such as Chess and Go. In order to represent conflict on an individual scale, as opposed to the massed armies or tribes, it is useful to have a representation of success or failure more complex than the binary alive / dead relationship. There are a number of ways of simulating this: it could be viewed as a tug of war which requires a success of failures on one side, where one or more successes reset the simulation back to its original values; or it could be as complex as a set of values that as they are depleted, the player on that side loses the ability to perform certain actions and eventually becomes incapacitated.

The problem with the tug of war relationship is that it can result in a perpetual conflict: the gains of one side offset by subsequent loses. Ideally in an ongoing game there should be an escalation of risk, so that as the game proceeds to a conclusion, the actions of the players become more critical to determining their ultimate success or failure. But the difficulty of simulating increasing incapacitation, as in the second example, is that failure results in a negative feedback loop. The game can effectively be over prior to one of the players being adjudged 'dead'. In this instance, there is little chance of a sudden reversal through late game play: and either the game must conclude in the surrender of one player or there must be significant value in attaining a game draw or significant shame in losing the game. Chess is a good example of such a game: and a significant design challenge in unit-based strategy games is ensuring the possibility of reversals instead of inevitable decline as unit attrition occurs.

Solution: Over the last 30 years of modern game design (the era during which the individual has superseded the unit as the most important playing piece), the simple scalar relationship of hit points has proven itself to be a strong middle ground between a tug-of-war solution, and a complex set of incapacitation values. Hit points are an abstract representation of damage to a player, abstract because as hit points are depleted, there is no additional penalty accrued to player actions: neatly side-stepping the negative feedback issues of gradual incapacitation. Hit points are well understood and from a design perspective simple to implement and balance. And more complex solutions are usually implementations of multiple hit point pools combined with status effects, so a fundamental understanding of hit points is necessary to understand more complex designs.

The damage effect of magic is to reduce the amount of one (actually zero) or more enemy hit points, and when they reach zero hit points, kill them and eliminate from the game. Damage can be broken down into the subcategories of instantaneous damage, and damage over time, as well as different damage elements (used to define potential enemy resistance to damage) and shapes (areas of effect in which enemies sustain damage). Damage can have any number of complex subtleties - see part six for a fuller discussion. Keep in mind that many games just rely on damage, with no other magic effects, and still have a vast range of possible choices as to how to apply that damage.

2. Status effects

Problem: Hit points are too simple for many game design(er)s: they are just a single scalar without any incapacitation effects. However, having multiple gradual incapacitation is too complex to design, as well as resulting in negative feedback loops.

Solution: Status effects separate player and enemy incapacitation from enemy damage. A status effect prevents the player from making one or more actions over a limited period of time at full effectiveness. The simplest to design status effects are binary: while under the impact of the status effect, the player cannot perform a particular set of actions, but the simplest to balance status effects are decremental: instead of preventing the action, the player can only do it with reduced effectiveness.

The complexity of status effects is effectively conveying to the player affected by the status effect that they have impaired or restricted choice of actions, and the number of different ways that this can be done is the restriction on the maximum number of possible status effects. For instance, the screen border may change different colours depending on which status effects are being applied to the player: this would imply a maximum of three different status effects could be used (as most colour spaces are three dimensional). Or a separate set of icons could be applied either to the GUI or hovering over the player graphic: in which case the size of the the icons (balanced by legibility issues) and the available screen real estate would dictate the maximum possible number of status effects in the game.

The time to recognise the status effect taking place is also a factor in real time games: which is why turn based games tend to have more status effects permitted.

While the number of different status effects is restricted by user interface considerations, the duration and number of possible actions restricted by a particular status effect is important to consider from a game balance perspective. These are key because of the need to avoiding designing guaranteed locks as a part of the status effect.

A lock is where the player can keep the status effect applied to an enemy (or vice versa) so that no effective action is possible by the enemy. A lock may occur because the enemy only has a restricted set of actions from which to choose, and the status effect blocks them all, or because the player is able to apply enough different status effects during the duration of each effect that they are able to prevent all enemy actions. For example: there are three different status effects in a game, and these last at least four game turns. The player is able to get a lock by applying each different status effect over the course of 3 turns, so that on turn 4, the enemy has all status effects applied and therefore completely incapacitated.

There are two methods to avoiding locks: either have useful actions which can never be affected by status effects (or only degraded by them, but to the point where they stay useful), or to have status effects have diminishing returns, so that applying multiple status effects (or the same status effect repeatedly) can never build the lock in the first place.

Note that the simplest status effect is the interrupt, which is where one player's current action is stopped by another player's action. It is possible in a game to get locks with just interrupts, and no timed status effects, so testing is inevitably required to ensure that the game is lock-free.

2a. Traps

Problem: Locks are an interesting and intriguing emergent behaviour that exists as a consequence of implementing another game feature (status effects). Dictating that a game should be lock-free is counter intuitive on several levels: the player should be encouraged to experiment with the game mechanics, and not prevented from exploiting them.

Solution: A intended lock design is a trap: that is, it is possible to design games where getting a lock on an opponent is an intended part of the game play. Traps are a sequence of player actions that result in getting a lock on an enemy for a short period of time.

The function of traps differs between single player games and multiplayer games. In multiplayer games, traps are to encourage yomi. A multiplayer trap should always have a guaranteed counter in the sequence leading up to the trap, but the counter should be high-risk (that is results in a worse position than falling for the trap if the player initiating the trap instead predicts that a counter will be used). David Sirlin writes extensively on the use of traps in his book Playing to Win.

In a single player game, there is no theory of mind of the opponent, because the opponent is a computer. The game may attempt to simulate an opponent, but any simulation will be less sophisticated than a real person. Therefore traps have a different function. When used against the player, a trap is intended to discourage certain behaviour. Unfortunately, this kind of learned helplessness is not the best psychological mechanism for encouraging game play, and should usually be avoided.

Against the computer enemies, traps should be treated as puzzle solving problems. A opponent should be introduced that poses a significant problem for the player, but for which a trap exists that significantly reduces the opponent threat. Deducing the trap should require puzzle solving skills, and applying the trap should require whatever level of manual dexterity, timing and hand-eye coordination is appropriate for the game audience target. Once the trap puzzle has been solved, this opponent becomes a skill test, and should either be removed or reduced in frequency.

It is worth stressing that traps (and all locks) should always cause damage (or other game win progression): otherwise the gameplay can be reduced to an inescapable infinite loop. A good example of this is paralysis in Angband: early in the dungeon the player encounters floating eyes which can paralyze them. Once paralyzed, the player can do nothing while the eye continues to gaze at them, paralyzing them repeatedly until they starve to death. The underlying lesson in this instance is to buy sufficient armour to have high enough an armour class to avoid the attack, and not to blindly run around corners. This lesson should be learned quickly and at little overall cost, as floating eyes are frequently encountered on the first level of the dungeon where little time has been invested in developing the character. Roguelikes are full of these kinds of 'learn not to do this' traps, which is paradoxically part of their appeal.

(Roguelikes can get away with designs that would completely wreck other games because of their procedural generation and permadeath mecahnics. In another genre, such an encounter early in the game would wreck the experience completely - in a roguelike, the lesson run away and don't fight everything should be gleened early on in the game playing process).

In part five, I'll be discussing more magic effect game design patterns: resets, information, door / key puzzles and build modifiers.

[Un] Unangband 0.6.2-gold2 released

Unangband 0.6.2 Gold 2 "The Shinier" aka "Heeerrrreeesssss Bandy!" has been released.

My involvement during this release has been merely 'file release dogsbody'. Bandobras and Big Al Phillips should receive all the praise: myself all the blame.

Please see the official Unangband site for details.

Random story generator

Infinity: The Quest for Earth has released an XML-based story generator, and invited you to submit your own story plots. Feel free to read the article, download the executable and have a play.

Having said that, the story examples they give are a little dry. For inspiration, go to Orion's Arm.

Conclusion to the TIG Source PCG Competition

The Independent Gaming Source procedural content generation competition has concluded: with approximately 49 completed entries. There's been no official announcement on the forums, but I've had a brief look at some of the entries. Rescue: The Beagles (pictured) has already been reviewed elsewhere, and Dyson looks intriguing (Edit: Also reviewed). I'll write up more as I play them.

This is a brief help-wanted request as well. I'm slowly writing up the finished entries on the PCG Wiki. It'd be great if readers of this blog could help out by either:

1. Expanding on an existing entry I've already written, by downloading and playing the game and taking some screenshots.

2. Writing articles for entries I've not already written. If you create a new entry, precede the name by pcg-games: and you'll get the right template and it'll automatically appear in the appropriate game categories.

Thanks in advance.

The Cost of Interruption

You've probably noticed, if you've been reading this blog on a regular basis, that I have periods where I write a large number of entries - followed by quieter times, such as now.

Unfortunately, this isn't just restricted to the blog: my UnAngband co-developers have to put up with extended periods of absence, followed by short spells of coding frenzy.

Recently, I've found myself unable or unwilling to commit enough time to UnAngband - following what you might assume is a typical procrastination pattern: I've been gaming, blogging and working on the PCG Wiki instead of writing code.

This is mostly to do with personal commitments: for instance, my wife and I are moving into a house this weekend: we're finally on the property ladder, and prior to that I've been 'on the road' with work for 4 weeks, travelling around Australia and New Zealand doing training and seminars - which is mentally draining, if not exhausting.

But with all this happening in the background, it's not a lack of time which has caused coding to fall by the wayside. But the time I have available has been broken up into smaller chunks, and generally I've had less periods I've been able to focus exclusively on one thing. And this is the crux of the problem.

With coding, if I have a longer period of time, I'm more productive. Not as in twice as productive, but probably ten times or more. This follows the pattern found a study in the 1960s by Sackman, Erikson, and Grant which found huge variance in individual programmer productivity. The reason for this is the time required to rebuild the mental model of the program before I can generate new, productive code. This mental model doesn't have to be complete, but it does have to be correct, and I've inadvertently introduced logic bugs that have persisted for years, due to faulty assumptions about how a particular section of code works.

As UnAngband becomes more complex, and as the number of contributing programmers rise, the total cost of rebuilding this mental model gets higher and higher.

But what I've also found, is that there is a significant cost associated in tearing this model down as well. As the more complex the model gets, the more it displaces regular social functions, like being polite and pleasant to be around. So as a consequence, any time I'm in the middle of coding, and get interrupted, I end up being a moody sonofabitch, which is hardly fair on the people around me.

It gets so bad, I have felt like being physically wrenched out of the code space, when I've been interrupted some times. I don't know if this feeling is unique to me - certainly, my father likes to take all his holidays at once - in fact the whole of February off, which suggests to me he experiences a similar switching cost between working and relaxing.

So rather than plain procrastination, blogging and gaming has become activities where I feel productive in a short term without experiencing this mind numbing interruption cost - the interruption cost of a blog entry is just re-reading the entry I've written so far, which is a much lower barrier.

It has got so bad recently that I've started dreading coding, in so far as the idea of doing something half-way and getting interrupted is a feeling I don't particularly want to experience.

My question is, is this something that you've experienced? Am I just over emphasizing the problem, and underneath it all is just standard procrastination?