Dropping Loot - <AUTHOR> http://journal.stuffwithstuff.com/2014/07/05/dropping-loot/ <comment><USER3> A better approach (IMHO) to loot in RPG games is to give NPCs/monsters actual equipment they can use and then drop naturally. You can combine this with a trinket generator to give each one a little more flavor. Of course some mobs carry stuff they can't use themselves (for example because it is assumed they looted it off someone), that's also fine - just put it into the "character generator" function or the monster template.

I'm a huge fan of giving mobs some history and uniqueness, and that's an easy way to do it. A nice side effect is that you don't have to think about loot separately when designing the content, because it comes naturally from the design of the mob. This also means that, by definition, a mob can never drop an inappropriate item.

Recently, I re-discovered the ancient Baldur's Gate games (enhanced edition), and they do something similar. Mobs drop the actual equipment they have.

Some loot traditionally comes from the body of the monster itself, like a rat's tail or a wolf's fur which you can bring to the next merchant or quest- giver for reward. A more natural method of doing it would be solely through the skill/crafting system, instead of dropping pre-defined animal parts just because they happen to be important to some quest.

<comment><USER4> I think that's a cool idea, but in practice it doesn't seem to lead to very fun gameplay. It means a large swath of monsters: jellies, giant insects, wolves, bears, spiders, serpents, etc. wouldn't drop anything. You'd end up basically just trying to kill "monsters" that are humans. To me, that's not very fun.

> You can combine this with a trinket generator to give each one a little more > flavor.

I do have that. They are "powers" and work similar to items in Diablo where they can be a prefix or suffix on the name of the item and modify its stats. So you can get a "Glimmering Stick of Wounding".

> This also means that, by definition, a mob can never drop an inappropriate > item.

I did try this, but my experience was that it made killing mobs predictable and boring. "Oh, look, the wizard dropped yet another robe." I deliberately sacrificed realism (which is of limited value in my book anyway) to get a more exciting, surprising game.

> Some loot traditionally comes from the body of the monster itself, like a > rat's tail or a wolf's fur which you can bring to the next merchant or > quest-giver for reward. A more natural method of doing it would be solely > through the skill/crafting system, instead of dropping pre-defined animal > parts just because they happen to be important to some quest.

I do have that too. There is a "crucible" in the "town" where you can combine items to make new ones (again similar to Diablo). It's a fun mechanic, but I don't want to lean to heavily on it. I find games where you go into the dungeon, amass a pile of rat's tails, sell them, repeat, to be super boring.

<comment><USER3> _> It means a large swath of monsters: jellies, giant insects, wolves, bears, spiders, serpents, etc. wouldn't drop anything._

I guess at a fundamental level it depends on what kind of game you want to make/play. To me the allure of RPG-style games is that they can be story vehicles. Run-of-the-mill animals dropping weapons and gems has the opposite effect on me: I think it disrupts the world's integrity and as a player I always think it's a design weakness.

In any case, they do drop something - their bodies.

 _> You'd end up basically just trying to kill "monsters" that are humans._

Nope, at least not if we're talking standard fantasy RPGs. You _could_ argue that all the tool-using monsters are human-like, but to me that's not very accurate. If there's a moral in-game argument in there, well, you generally don't kill Goblins because they're not human, you kill them because they're evil or they attack you first. There are generally tons of tool-using monsters in fantasy settings that aren't even humanoid. But yeah, I think it's OK to have human bad guys as well. To me, basing the distinction whether to kill some creature on whether they're human or not feels weird and questionable.

 _> I think that's a cool idea, but in practice it doesn't seem to lead to very fun gameplay._

Obviously, I disagree. Not every mob needs to drop riches, especially if the loot doesn't make sense within the story. Providing predictable and nonsensical short-term rewards is not a player retention strategy I'm overly fond of, I might as well just install ProgressQuest and watch that for half an hour. On the other hand, there are many games that do just that, so your view is clearly commercially viable.

 _> "Oh, look, the wizard dropped yet another robe."_

That's only a problem if the expectation is that every lootable item is indeed loot-worthy.

 _> I deliberately sacrificed realism (which is of limited value in my book anyway) to get a more exciting, surprising game._

I see you're not kidding about not caring for realism. That's of course totally fine, do your thing. I'm not trying to convince you of anything. My point is that I personally think the choice between fun and realism implies a false dichotomy. Yes, dropping "realistic" loot is a bit predictable - <USER2> it's a good kind of predictability that makes the in-game world more convincing. And with just _a little bit_ of good will and creativity you can still make them drop unique and surprising things without breaking their character.

Maybe I'm mistaken but you sound a bit defensive, which was not my intention. Once again, this is _not_ a critique of your game. It's a very personal opinion about loot and the style of games I like to play. At the end of the day, you're the guy building something amazing and I'm just a random dude on the internet who except for the occasional abysmal LD entry never even made a real game. So: rock on :)

<comment><USER5> You do realize this is a loot system for a roguelike, right? Not a story driven CRPG.

<comment><USER6> Sure, but this is exactly how Titan Quest (not a roguelike, but an action-RPG) works. Animals will never drop spears, but if you see an enemy with a bow, you will most likely find a bow on its corpse (or nothing).

</comment></comment></comment></comment></comment><comment><USER7> Interesting, my $0.02:

Initially some of the drops are specified using percentages. My advice is to never use percentages when selecting chances to pick an item from an arbitrary list of items. Instead, use numbers which loosely correlate to ratios. Here is an example list of items:

1, 1, 2, 2

the chance of picking the first item is 1/(1+1+2+2) or 1:6. The chance of picking the last item is 2:6. Using this method, you can add arbitrary odds to the list and it will automatically total up the odds for you. For example:

1, 1, 2, 2, 3

The first is a 1:9 chance, the last is a 3:9 chance. The numbers still maintain relative chance next to one another - i.e. you are 3 times more likely to get the last item than the first.

This is better than using percentages because you can add items without having to recalculate the percentages so that everything adds up to one hundred percent (yes you could normalize the percentage but this still makes it tougher to understand the chance of each item relative to one another. If you want to make a high chance of dropping nothing, simply add a null item to the list with a really high chance, i.e.:

(null) 99, (diamond) 1

This results in a 99/100 chance of dropping nothing, and a 1/100 chance of dropping a diamond.

<comment><USER4> Oh, great comment! I've gone back and forth on exactly this a number of times. I'm not a big fan of percents for exactly the reason you specify. The reason I'm still doing it instead of automatically totalling the odds is because it makes it easier to specify the chances of not dropping anything at all.

> If you want to make a high chance of dropping nothing, simply add a null > item to the list with a really high chance, i.e.:

Brilliant. I'm going to change my code and do that. Thank you!

<comment><USER8> Check out [http://diablo2.diablowiki.net/Item_Generation_Tutorial](http://diablo2.diablowiki.net/Item_Generation_Tutorial) for a slightly more complex system that IMO is a lot more flexible and can give some truly astronomical drop rates on exceptionally rare items (i.e. Zod runes, Tyrael's Might sacred armor).

The trick D2 uses is using a table similar to this:

        TreasureClass    Item1    Prob1    Item2    Prob2    Item3    Prob3    ...
        runes23          zod      1        runes22  5000
        runes22          cham     1        runes21  5000
        runes21          jah      1        ber      1        runes20  5000
        ...

As you can see, some of the items are actually TreasureClasses, which have their own entries. Whenever the item picker lands on a TreasureClass, it drops to the corresponding table row and "rolls the dice" again, so to speak. This is repeated until the item picker lands on an actual item.

If you look at TreasureClassEx.txt from Diablo II, you'll see that they further use this system to calculate nodrop rates, item generation per act/per difficulty, etc. Pretty cool once you wrap your head around it!

<comment><USER7> That's a good idea and probably what I'd do if I were to take it one step further - in particular if you went with null item drops, it would be great to "subclass" that so that its ratio does not interfere with the rest of your calculations. I.e. - 1:20 chance of dropping an item, 1:6 chance that it is item type XYZ.

+1 for Diablo 2, the game that destroyed my grades in school. :)

</comment></comment></comment></comment><comment><USER9> > It made it impossible for the player to seek certain items. Let's say you've > got a good kit of armor except you really could use some high quality boots. > How do you fill in that gap?

In many games, believe it or not, is a actually intended. Once certain mobs start dropping certain items, people start camping only those mobs and ignoring everything else causing a large bottle neck for the population (in the case of multiplayer only obviously).

Additionally, say you give a mob 0.01% chance to drop The Sword of a Thousand Truths. And of course everyone wants the The Sword of a Thousand Truths. So every day you go out and farm these kobolds until your fingers are numb rather than exploring the world.

Finally, by providing a clear path to getting what you want, you will likely max out sooner and stop playing until the next content patch, which in turn means less revenue for your game

<comment><USER10> What does this have to do with a single-player roguelike? I can sort of see

> of course everyone wants the The Sword of a Thousand Truths. So every day > you go out and farm these kobolds until your fingers are numb rather than > exploring the world

but playing for such a duration is already a massive design failure.

<comment><USER11> In most of the roguelikes I've played mobs don't continuously respawn like that anyway. If you stay in a dungeon too long, either they'll be no more mobs and you'll starve, or higher level mobs will randomly start popping in.

</comment></comment></comment><comment><USER12> Did you look at Nethack? Certain monsters have set loot. Dwarves have a high chance of carrying a pickaxe, noble variants have a high chance of having dwarven mithril, shield, iron shoes. Same with Elves. Soldiers carry K- and C-rations. Paper golems leave piles of blank scrolls!

Monsters will pick up items. If you are in the dwarves mines and there's a mining dwarf about, gnomes and other creatures will pick up the piles of rocks they leave behind.

Additionally monsters with the right flag set will often use items. This can reveal their blessed/uncursed/cursed status ("The dagger welds itself to the goblin's hand!") or identify the item - which is sometimes a real pain, when a consumable you needed is used. ("The gnome zaps a wand of lightning! You die...")

<comment><USER13> ^ This.

Nethack is still unparalleled in how dangerous a monster can be with "your" loot (think you kill a monster with a magic missile, it drops loot, but before you can get to it another one dives into the pile, and quaffs the potion of invisibility/healing you desperately needed).

</comment></comment><comment><USER14> Neat idea! I am constantly impressed by the number of different and interesting things that Bob works on. All of his game programming work, and his several (if prototypical) programming languages, each exploring some unique idea. [https://github.com/munificent?tab=repositories](https://github.com/munificent?tab=repositories)

I've always wanted to write a roguelike. I wrote a woefully incomplete MUD a long time ago. It had the interesting (to me) property of representing items and features as .NET assemblies. Servers could link so that a doorway could move players, with their items and effects, seamlessly onto another. If I recall correctly .NET even had the security model to (nominally) support it safely, where all items may invoke only approved engine APIs, and where trusted assemblies might be loaded while untrusted items and their consumers pass through to be loaded again later on another server. The idea was to enable a sort of open web of interconnected MUD worlds. Only ever made it to the tech demo stage; I recall spending a long time on that system, event handling, and other engine features (classic game dev mistake) and never got around to game content! I don't regret the time: it was primarily a project of exploration and the act if building just the engine was its own reward. (Tomorrow I might try to dig up my old source for the MUD but I suspect it will be like [http://www.xkcd.com/1360/](http://www.xkcd.com/1360/) )

Anyway, could anyone recommend a good OSS roguelike that's accessible and easy to hack on? Looks like Angband is OSS, and of course there's NetHack, which if I remember correctly is written in C. Stone Soup's site appears to be down.

<comment><USER4> > Anyway, could anyone recommend a good OSS roguelike that's accessible and > easy to hack on?

As soon as I get around to open-sourcing mine, I'd recommend it. :)

It's a pretty clean, small codebase. I've spent a _ton_ of time designing it to have a clean extensible architecture. It's written in Dart and runs on the web, which is nice.

I just need to check with work, but that should be fine and I'll put it online soon.

If you like C#, the previous incarnation of my game is already online: [https://bitbucket.org/munificent/amaranth](https://bitbucket.org/munificent/amaranth)

I've pretty much abandoned it, but you're welcome to do with it as you like.

</comment></comment><comment><USER10> > I learned the hard way that a huge part of the fun of roguelikes is the > "lottery effect". Every time you kill a monster there should be a small > chance of getting something really amazing.

That's one way to handle item drops, but it's not the only way, even considering only Angband variants. The other popular loot system has you making your own stuff -- instead of "dragons always drop dragon scale mail" (boring?), you'd have something like "dragons always drop scales, and you can use them to forge dragon scale mail".

<comment><USER15> He addresses all of these points in the blog post.

<comment><USER10> ...um, no he doesn't? I've made one "all of these points", and it's not addressed. Where does he talk about making items?

<comment><USER15> ugh, apologies, I must've read someone's comment above and attributed it to the post. Sorry about that, I'll upvote you.

</comment></comment></comment></comment><comment><USER16> In the paper and pencil RPG world, if you want to generate a reasonable level 5 sorcerer player character or whatever, there are (usually) extensive systems to go direct to lvl 5 and skip the earlier levels. So just generate your NPCs / Monsters the same way. Obviously all paper and pencil RPGs have a "system" for generating level 1 PCs, and randomly simulating in a computer the lifespan of a character as it levels up doesn't sound all that hard or time consuming.

I fooled around with this idea in the 80s and it wasn't feasible computationally at the time, but it would work now. One funny problem I ran into is a stereotypical adventure eating monster tends to accumulate a lot of lower level adventurer cruft, not as much good stuff as you might hope for. Lets be realistic, a dragon is going to have to spend a large part of its lifespan eating unlucky dwarves if you hope to catch it with a cache of exotic gems harvested from those dwarves. A gang of thieves would on the surface have "harvested" lots of loot from peasants and occasional nobles over the years, but over the years most of that has drained out due to simple weight and need to eat. So thieves were another disappointment. As I recall corpse robber monsters tended to accumulate the best loot over time. Also nest type monsters, due to inability to move / spend anything they get, killer trees got the best loot. This can't be an original idea? I think this is how dwarf fortress generates people but I'm not sure?

For pathfinder, although I can't recall the name, there is an entire book (article? chapter?) just on custom NPC/Monster design techniques. Actually using a OGL licensed scheme might have issues. But the existence of one solution does imply the problem is solvable in at least one situation (LOL).

</comment><comment><USER17> Great read!

"In Angband, any monster that drops stuff can drop pretty much anything. Monsters have a level, and if they drop loot, it just randomly picks any item near the monsters level."

-> (RPG related) I felt like this was an issue with Diablo 3 compared to Diablo 2. You basically just had to mash around in D3 grinding the top-level monsters and hoping... whereas in Diablo 2 you could make conscious choices over where to farm if your goal was to find a certain item (albeit the drop chances were extremely low, so most people just did Meph runs or Baal runs and traded their way up). Here though the author is doing drops way more realistic than either of those games heh, so that's quite an awesome feat.

Itemization seems really tricky; analyzing Diablo 2 vs Diablo 3 can actually provide some interesting insight into how item systems affect gameplay etc... maybe those devs even tried doing it realistically at some point but found it didn't pan out gameplay-wise?

<comment><USER18> Having played both games extensively, I feel the most interesting thing to analyze about in which parts of the game are randomized, and how that randomization impacts gameplay. Let me pick 2 examples.

In Diablo 2, areas were randomized internally but externally consistent: the individual makeup of areas would be different every game, but the connections between different areas would remain the same.[1] This means that repeatedly exploring the same area remains entertaining for a relatively long time in Diablo 2. This is important, because as you say, items have a higher chance of dropping from certain monsters than from others. If you "have to" keep farming the same area over and over, it helps prevent boredom if that map is different every time.

In Diablo 3, the internal layout for each outdoor area is always the same, and even indoor areas are relatively static, compared to Diablo 2's. After a while, you know the best way to maximize efficiency, which encourages people to repeatedly farm one area, but this is a double edged sword: once you know what the most profitable way of playing the game is, playing any other is much less attractive. This actually reduces the range of (rational) possible actions in the game, inducing boredom more quickly. In addition, some of the best areas to farm in Diablo 3 are the dungeons. These are (smaller and optional) sub-levels within areas. Each area had fixed dungeons in Diablo 2. In Diablo 3 areas can often spawn 5 or 6 different special events, while it has only 2 or 3 (fixed, just like the areas themselves) spots for such events. This adds another layer of randomization: you need to be lucky twice: once to find the dungeon and once again to find the item in the dungeon.[2]

Something else that changed between Diablo 2 and 3 is the way item affixes are randomized. In both games, magical items can spawn with certain properties, and those properties have stat ranges. You might find a Short Sword with the Red prefix, giving +1 or +2 damage. In Diablo 2, the best items (Uniques, Sets and Runewords) had fixed affixes with random stat ranges: you might find a Tyrael's Might with anything between +20 Str and +30 Str (in addition to have a dozen other affixes), but that it would get a significant +Str roll was guaranteed. Even the worst Tyrael's Might was a great find. Relatively casual players would be happy with any stat rolls, while true Diablo 2 addicts would make do with nothing less than a +30 roll. Such a perfect roll could (and still can) increase the value of an item by a factor of 10 to 1000+,[3] even if the objective difference between a random roll and a perfect roll is fairly small in the grand scheme of things.

In Diablo 3, this was thrown out the window. Legendary and Set items get _some_ fixed affixes, but even if you got the best item in the game and perfect rolls on the fixed affixes, you still need 1-3 other affixes to get a genuinely good item. In addition, the stat ranges were much wider. Immortal King's Tribal Binding could get +30 or +200 Str, and with the right random affix, all the way to +300 Str.[4] This makes the relation between gear cost and power fairly linear. You might have to find half a dozen Tribal Bindings before you got one worth using. In addition to finding the dungeon, and then the item, you also need to get good affixes on the item, then get good rolls on your affixes. Finally, in some slots, the best items in the game were not Legendaries, with their half-random setup, but Rares, with fully random affixes, which instead of 1-3 good affixes, need 5 or 6. It is no wonder then that players were unable to find their own items, and were forced to turn to an auction house, where they were primarily supplied by bots and gold farmers (unknowingly, but still).

Blizzard tried to address some of these issues in the Reaper of Souls expansion. Here's a few examples relating to the above points:

* Enchanting was added: allows you to replace one of each item's affixes with a different one (only one affix per item, but you can repeatedly change the same affix until you get one you like), reducing the impact of random affixes.

* Rifts were introduced: random dungeons with random monsters and a random boss at the end, which are generally slightly more efficient than just farming normal areas.

* The auction house was removed, reducing the impact of bots and farmers, allowing an increase in the drop rate. Trading in general was removed as well, making it impossible to turn to third-party trading sites (as was common in Diablo 2).

* The stat ranges on affixes were reduced, lessening the dependence on highly random items. Many Legendary items got unique Legendary-only affixes that (when combined in clever ways) make them far better than fully random Rare items.

Overall, this has significantly improved the game, but having played Diablo 2, Diablo 3 and Diablo 3 after the Reaper of Souls expansion, I can't help but feel like these are in the end just patches on a fundamentally flawed design, and that some of those patches actively prevent it from becoming better. Diablo 2, on release, was a bad implementation of a great design. This allowed it to be improved over the course of almost a decade (sporadically by modern standards, but impressive at the time). Diablo 3, on release, was a mediocre implementation of a bad design. Blizzard improved the implementation (at significant cost, to the point of forcing them to postpone the expansion), and details of the design, but it is still only a good implementation of a mediocre design, and improving it much further strikes me as uneconomical, to put it mildly.

_____

[1] For example: [http://classic.battle.net/diablo2exp/maps/act1.shtml](http://classic.battle.net/diablo2exp/maps/act1.shtml)

[2] It's worth pointing out the two different types of randomization in games. One is the type the player can influence, like which area to farm and whether to play solo or in groups. The other is forced upon players, like what affixes your drops have or whether a dungeon spawns in a given area. Players tolerate the latter to much higher degree than the former.

[3] Filled with jargon, but: [http://forums.d2jsp.org/topic.php?t=59979863&f=52](http://forums.d2jsp.org/topic.php?t=59979863&f=52). Look at Hellfire Torches for a typical desireable item, and Black Hades for an extreme example.

[4] These are the post-expansion stats, but it illustrates the principle, which is much reduced, but still very much alive: [https://us.battle.net/d3/en/item/immortal-kings-tribal- bindi...](https://us.battle.net/d3/en/item/immortal-kings-tribal-binding).

<comment><USER19> Play Path of Exile. It's a much better game than Diablo 3.

Whether or not Rares or Uniques are best in slot items is a matter of designers taste when it comes to Action RPGs. You can tune the item drop tables however you want. I would argue its nicer to have rares be BiS items, as its more fun when you see item diversity in the top builds. Seeing everyone walk around with the same Uniques is boring.

Diablo 3 fails because it does not provide enough ways to customize a character's build. There are a handful of stats that are important, and they mostly scale linearly. The skills are all unlocked, and you can change them at will.

If you do not have enough ways to customize your character, the item drop tables are moot. You can't drop items that are interesting if there are no interesting stats.

Path of Exile is the true successor to Diablo 2. The options for customization are endless, so every item that drops has the potential to be interesting. You should check that out if you are interested in ARPGs, especially something like Diablo 2. And if you are really interested in game analysis, their systems are really unmatched in today's game marketplace.

Diablo 3 is not a game in the Diablo genre. D3 is closer to something like Baldur's Gate: Dark Alliance, or the X-Men Legends games.

Edit: I focused on the itemization part of your post, but I totally missed the map part of your post.

I'm not sure map randomness was relevant at all in Diablo 2. That game was pretty much all Meph runs, and then Baal runs. The maps didn't really matter, you just teleported to the boss and hoped for good drops.

<comment><USER18> I've played Path of Exile a little, but while I'm don't usually care much about graphics in game, the style in PoE was an incredible turnoff for me. It's a real shame, because the game design indeed has some very interesting ideas, and I would've loved to explore them in more depth.

I agree with your point on maps. Diablo 2's focus on bosses over general farming was one of its weak points. The map structure would've been more important if Blizzard had made boss runs and general farming rewarding in distinct ways.

There are other things that I feel Diablo 3 did wrong, but my comment was getting dangerously long as it was: lack of build permanence (you touched on this), non-existent social features (slightly improved in the expansion), uninspired items (less so since the expansion) and badly tuned reward structure (I appear to be alone in feeling the expansion has not improved this aspect).

</comment></comment></comment></comment><comment><USER20> Back when I played adventure/RPG games...the one thing that broke me out of the suspension of disbelief in most games was how, after defeating an enemy who was clearly using some amazing equipment, your party wouldn't bother picking it up and instead, pick up a few GP and maybe a "Short Sword"

Of course, I realize now that that was a reasonable constraint of game design and balance. So it's not coincidental that my favorite RPG of all time, Ultima 7, had a famously in-depth inventory system, and yet also was so unbalanced that combat was mostly pointless.

<comment><USER21> Some of that could be "worked around" by having said enemy's amazing equipment breaking during the fight.

<comment><USER22> Halo 1 actually does that. The Covenant Elites have neregy swords that dissipate once you kill them, and the grunts had plasma cannons that would just explode when the grunt was killed. That's why it was so epic when they made those weapons pick-able in Halo 2

(And Tartarus's Gravity Hammer in Halo 3!!)

Still waiting to be able to pick up Hunter's built-in arm weapons though....

</comment></comment></comment><comment><USER14> Folks who enjoyed this article might also like the book Game Programming Patterns: [http://gameprogrammingpatterns.com/](http://gameprogrammingpatterns.com/) \- also written by the author Bob Nystrom.

</comment><comment><USER23> The article is basically describing leveled lists, which is what Fallout and the Elder Scrolls games use: [http://www.uesp.net/wiki/Skyrim:Leveled_Lists](http://www.uesp.net/wiki/Skyrim:Leveled_Lists)

</comment><comment><USER24> [meta]

The title mangling introduced a case of RAS syndrome. RPG games is redundant since the G stands for game.

The original title of this article is just "Dropping Loot". If you're going to mangle the title, at least mangle it in a way that doesn't introduce a new error!

<comment><USER25> Redundancy is an important part of communication and error- robustness I both human and computer languages.

RAS Syndrome is a sweet spot trading off economy of characters/syllables vs clarity of message. As with most things humans gravitate to, it is a rational act, not a stupid one.

"A foolish consistency is the hobgoblin of small minds."

<comment><USER24> Nope, completely disagree. It is not a rational act, it indicates thoughtlessness in language. And much as I like the Emerson quote, it does not apply here. The question isn't consistency, it's accuracy and clarity. The redundancy does not add anything -- your assertion that it adds error robustness makes no sense because the communication medium is not lossy.

Even if in the general case redundancy can be useful -- I don't correct others' spoken conversation so long as I can understand what's being communicated any more than you do -- in this case it detracts and distracts.

</comment></comment></comment><comment><USER26> OK, so this increases realism, but at the cost of making balancing much harder. If you decide you want the player to get healing potions at a certain rate, you now don't have a single place where you could specify that.

<comment><USER27> Just for once I'd love to play a game that emphasizes realism at the cost of game balance. Because constant focus on the latter in pretty much every game makes for a lot of ridiculous and suspension-of-disbelief-killing situations like a group of soldiers with chainguns shooting down from the sky an armoured FTL-capable Battlecruiser, or small bats dropping swords and a metric ton of gold from their "inventory".

Realism is unbalanced, but guess what, the real world is also unbalanced. I want to play a game reflecting that.

<comment><USER26> I'm pretty sure you wouldn't want to play that game for long. If you want the real world, you know where to find it. People play games to have fun. To some degree (but much smaller than most people think), realism increases fun, but when it makes the game frustrating, boring and unwinnable, it's bad.

<comment><USER6> But you can make great games with more emphasis on simulation. For instance, Operation Flashpoint/ARMA(?) or the original Rainbow 6, where firefights are absolutely deadly.

</comment></comment></comment></comment><comment><USER28> I recommend having a listen through some of the [http://www.roguelikeradio.com/](http://www.roguelikeradio.com/) podcasts. They focus heavily on roguelike design and development topics. I don't believe they have featured a podcast specifically on loot but it has featured as a topic in several of them.

</comment><comment><USER29> I used to NetHack... any item was obtainable with the Wand of Wishing :)

<comment><USER30> And it was always blessed greased +2 grey dragon scale mail.

<comment><USER12> L - a swirly potion

If you spelled it "grey", you didn't get your wish!

<comment><USER31> That's now fixed.

</comment></comment></comment></comment><comment><USER32> It would be quite neat to extend this with an evolutionary algorithm for picking starting positions in the hierarchy and probabilities based upon some proxies of enjoy-ability or play-ability.

</comment><comment><USER33> I only play with "drop all"* checked

* [http://ja2v113.pbworks.com/](http://ja2v113.pbworks.com/)

</comment><comment><USER34> In which tougher monsters drop better quality loot.

<comment><USER32> Well, yes. But I think this undersells it.

This is probably the best TL;DR: The author created a nice way of specifying loot dropping behavior such that (begin quote): _" Any monster has a chance of dropping almost any item, so you have that pleasant anticipation. At the time time, the probabilities are weighted so that each monster still has a unique "feel" to their drops, and you can seek out monsters that are more likely to drop what you want."_

And the author achieved this with a concise but clear DSL in which you specify the probability of starting at a particular point in the equipment hierarchy, and then an object is chosen by traversing (probabilistically) the equipment hierarchy.</comment></comment>


You might be able to get a tax credit for your prototyping - <AUTHOR> http://www.ksrevenue.org/taxcredits-research.htm if you are incorporated. <comment><USER2> Well, aside from this being Kansas-only...

" The credit is 6.5% of the difference between the actual qualified research and development expenses for the year and the average of the actual expenditures made during the year and the two previous tax years."

Wonderful. I can take a credit for 6.5% of...umm, $0 - $0. That comes to...$0.

Sometimes it sucks not paying yourself...

<comment><AUTHOR> 1) This was an IRS benefit and guideline. As I understand it, every state likely offers it.

The form is at <http://www.ksrevenue.org/pdf/forms/k-53.pdf>

2) If you were using your savings to live on so that you could do prototyping, can that be treated as an expense? (payroll or other). This assumes you were incorporated.</comment></comment>


Ask HN: Any Black Friday deals offered by YC-backed startups? - <AUTHOR> Since it's Black Friday, let's do a roundup of what YC-backed startups are offering today. Any good deals around? <comment><USER2> Given the relatively few amount of YC startups who sell physical consumer goods, it might be a better idea to make this thread come Cyber Monday.

</comment><comment><USER3> Automatic is a Y Combinator company and their Internet-connected car gadget is on sale this weekend. [https://www.automatic.com/](https://www.automatic.com/)

<comment><AUTHOR> Very nice! I'm going to get one.</comment></comment>


Job Matching Platform – Beta Testers - <AUTHOR> Hello HN. A friend and I are working on a platform that helps consultants like myself find more qualified leads. Very often, I would engage with a potential client/employer for several phone calls and in-person meetings only to find they were severely below my budget range. My best clients were the ones that came to me via referral or my company website.
So we started this project in order to make that organic discovery process systematic. We are looking for beta testers in anticipation for a late January 2017 release. If you are interested, you can read more about it here:
http://www.thevarsity.co
Thanks. <comment><AUTHOR> Also, if you're curious, we're building it on Node, React/Redux, and Mongo DB. We also connected to Firebase for real-time chat and used the react-google- maps component for Google Map integration. Sendgrid for email, and Stripe for payments.</comment>


Raiders of the Lost Web (2015) - <AUTHOR> https://www.theatlantic.com/technology/archive/2015/10/raiders-of-the-lost-web/409210/ <comment><USER2> HN discussion from first submission:

[https://news.ycombinator.com/item?id=10387071](https://news.ycombinator.com/item?id=10387071)</comment>


How I Found a Job That Makes Me Feel Good as a Developer and a Person - <AUTHOR> https://medium.com/code-like-a-girl/how-i-found-a-job-that-makes-me-feel-good-as-a-developer-and-a-person-5ada7218d26a#.3wwozpdyp <comment><USER2> I applaud the writer. Their achievement is not easy.

One nit that struck me as a bit odd: they felt that a MacBook Air was necessary for their development. I'm not a front end engineer, so maybe I'm biased, but is that so? Personally I love my MBA, but I wouldn't buy it if I had trouble affording it and I think there are plenty of more affordable computers out there that would help someone learn to code.

<comment><USER3> I shed a tear every time I see something like this:

> I got a Macbook Air even though I couldn't afford it, (believe it or not, my > intern salary was pretty low)

Why? Because somewhere someone is not reaching to his/her full potential because it has beaten in to his/her mind that a $200 windows laptop is not enough to start learning.

I know of a successful startup that started on a 10" netbook...

<comment><USER4> A $200 windows laptop is enough to start learning, but it's definitely going to slow you down compared to a better tool. You can make up for it with hard work, but I think investing the extra $800 in an MBA is well worth the money if it's even remotely feasible.

<comment><USER3> > but it's definitely going to slow you down

I see two flaws in your argument:

First, you assume that the $200 laptop is slower than the macbook Air. You would be amazed how much horsepower $200 can get you these days.

Second, lets say my cheap laptop is 30% slower than your MBA. How many serious projects were abandoned because the hardware was 30% slower than the MBA? How large is that number compared to projects that got abandoned due to, say, lack of motivation?

If you want to buy an MBA, fine do it. But don't try to convince others they wont be successful unless they too have an MBA (or a ThinkPad Yoga or a Microsoft Surface or whatever people consider a sign of success in your neighborhood).

<comment><USER4> > First, you assume that the $200 laptop is slower than the macbook Air

No, I didn't assume that at all--hardware speed has _literally nothing_ to do with my reasoning.

Hardware speed slows you down slightly, but it's a negligible factor next to crappy tooling. The programming infrastructure available for free for Windows is far, far behind that available on Unix systems. And if you use Linux, the tooling is there, but you're going to be fighting with software/firmware that doesn't support Linux for a good portion of your time.

> If you want to buy an MBA, fine do it. But don't try to convince others they > wont be successful unless they too have an MBA (or a ThinkPad Yoga or a > Microsoft Surface or whatever people consider a sign of success in your > neighborhood).

I specifically said "A $200 windows laptop is enough to start learning". You can definitely be successful with a $200 windows laptop. But, as compared to working with more effective tools, it's going to slow you down.

Your comment is a child post to mine, but you haven't responded to anything that I actually said.

<comment><USER3> > Your comment is a child post to mine, but you haven't responded to anything > that I actually said.

Okay, you seem to take this very seriously. But why? All I have said is that you don't need an MBA to be successful. Do you firmly disagree?

Anyway, back to your arguments: you claim a lot of issues with windows and linux but you don't give a single real-life example. So basically, citation needed :)

<comment><USER4> > All I have said is that you don't need an MBA to be successful.

If that were all you said, we wouldn't be disagreeing. But that's not all you said.

It's ridiculous to claim that all you said was that you don't need an MBA to be successful--anyone can read your previous post and see that you claimed a lot more than that.

> Anyway, back to your arguments: you claim a lot of issues with windows and > linux but you don't give a single real-life example. So basically, citation > needed :)

Windows: The default shell is abysmal, PowerShell is geared toward MS-centric programming (which requires other, expensive tools) and still isn't up to par with bash, and bash ports to windows are a bit limited and buggy. Meanwhile, bash isn't even the best shell on Unix systems.

Linux: I spent about 4 hours this past weekend getting wireless working on a Dell laptop. It's an 8 year old laptop--newer laptops are _less_ likely to have mature drivers since there's been less time to for drivers to have been produced or released.

If you had spent significant time working on these systems, you wouldn't need citations, because you'd have plenty from your personal experience.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I like this personal story. It has a point, is long enough to develop the story, yet well written enough not to be any longer than necessary.</comment>


Manager's Playbook: Heuristics for effective management - <AUTHOR> https://github.com/ksindi/managers-playbook <comment><USER2> Everybody bashing 1-on-1s, but they're really important. A 1on1 doesn't need to last half an hour and be full of red tape. The best managers I've had do a 5 minute check, but ONLY WITH YOU: hey, how are you doing? everything alright? Any issues (personal or professional)? And off you go to keep on working. But you know what? You feel _they care and they listen_. In these quick 1on1s we've learned multiple important things. For example, the "what do you think is a big time waster" question is usually brought up here, and it's very useful to have the point of view of the dev team.

We're all devs and we love to live isolated: we thrive sitting in a corner with our headphones and coding. But remember we can't escape our human nature. Having someone that listens to you exclusively for 5 minutes, once per week is very valauble.

<comment><USER3> As a manager, I don't do 1-1s for my sake. They're exhausting affairs, the end of my 1-1 days end in me basically losing all the energy required to work.

I do 1-1s because they're one of the most effective tools in my toolbox to check in on my team, get early warning on problems, and maintain quality relationships with everyone.

<comment><USER4> >> the end of my 1-1 days end in me basically losing all the energy required to work.

aren't 1:1s a big part of your required work?

<comment><USER3> Yes, and they're the last thing I do that day, because I'm drained afterwards.

I wouldn't call them a big part of my job, depending on how we're measuring "big". They're important, but they're not the largest amount of time on my calendar by a long shot.

</comment></comment></comment></comment><comment><USER5> I would add this:

The three Ps: pay, promotion, perks. People perceive you, their manager, as all-knowing and all-powerful about them. You aren't. But you'll never convince your team that you aren't. So:

1\. People never forget what you say about the three Ps. Never, ever, even once, make jokes or offhand remarks about them.

2\. Don't say anything that might sound like a promise unless you are CERTAIN you can keep that promise. NO: "I'll give you a raise IF I can get the budget for it" YES: "It's budget planning time."

And this:

Layoffs suck. If you have to lay people off, do it promptly once you've decided who. Don't wait. Don't dither. Get it done. Pending layoffs generate rumors and anxiety that can make your company a horrible place to work. It's always hard to get a team back on track after a layoff. Don't make it harder by your indecision and delay.

</comment><comment><USER6> > PRs should always be prioritized. Aim for review SLA of 1 hour.

I don't agree with this. For the sake of the argument let's agree that a review takes _less than 1 hour_ (which is definitely not always the case). That would mean that an Engineer needs to check his emails / notification more than once an hour to meet this SLA.

This is totally unproductive IMO.

I like most of the other points though, nice list.

<comment><USER7> If you have a PR review that takes over 1 hour, it's very unlikely that the reviewer will be applying the kind of focus that it takes to really review. For the typical Silicon Valley style development role.

1 hour _SLA_ would be astonishingly, irresponsibly fast. In the real world, in small teams that put in a concerted effort, the outlier best average review times are like 6 hours based on real data. Ideally you would want to be within a work day, but if you are under 24 hours you are doing better than 90% of teams working at random BigCos the world over, I bet.

<comment> devo-x-lie This all really depends on the maturity of the organisation and the team.

"1 hour SLA would be astonishingly, irresponsibly fast". Yes this can be true for a lot of cases, but at the same time it's nothing 'astonishing' or 'irresponsible'. Again it just depends in what state and maturity level the team and organisation are at.

Also, I think you are talking more from dev side of things? Would that be a good assumption to make? If that's the case then your points are very valid, but don't forget a lot of ops-like-teams work on code bases significantly smaller than coding projects and as such that SLA is totally fine.

Let's also remember that an 'SLA' for a review should be a guideline, not a factor to be always meet. There are always factors that will influence this.

<comment><USER7> Yes, I was referring to the context "For the typical Silicon Valley style development role" I mentioned.

Part of this may be that we are using different definitions of SLA. Normally when people around me say SLA, they mean something that is an upper bound pretty much always expected to be met (or else there are consequences of some sort). If you are referring to a softer agreement than that, it could make sense. If you were holding 1 hour as an SLA by my definition, that would mean you pretty much need to always have someone on deck to immediately review all PRs, to be safe.

I mostly posted because I don't want people who are less experienced to get the impression that 1 hour average review turnaround is normal or necessary in a typical development environment. In specialist roles, sure. For example, if you told me your work was responding to support tickets created by customers, and it sometimes resulted in PRs to modify your infrastructure-as-code, I could see the team working out a system to always get reviews within an hour.

</comment></comment></comment></comment><comment><USER8> > 1:1 Most teammates value it

lmaof not at any company where I've worked. Everyone has hated it just hated it

Here is why:

\- Its awkward because you often have little or nothing to discuss.

\- The person you are speaking to is pretty much powerless should you need something to change

\- Its yet another meeting you have to attend

<comment><USER9> > The person you are speaking to is pretty much powerless should you need > something to change

Only if your company is terrible. Anyone in the company should be able to recommend a change. If it makes sense it should happen. Full stop.

If there's something in your company that prevents change from the bottom up it's very poorly run.

I say this having been a regular employee, manager, and founder.

<comment><USER10> >> The person you are speaking to is pretty much powerless should you need something to change

> Only if your company is terrible. Anyone in the company should be able to > recommend a change. If it makes sense it should happen. Full stop.

On the whole this makes sense but in my experience at large companies this isn't how it always works. Often politics get in the way, or priorities limit the actions available. Also depends on the suggestion itself. I've had difficulties getting my suggestions heard.

<comment><USER4> even small-mid companies (< 500) have this problem. Of the 3 complaints the GP stated, it's the only one the manager can't fix easily

</comment></comment></comment></comment><comment><USER11> I don't think I've ever left a 1:1 feeling like I didn't waste my time, both as a manager and team member. The structure of a 1-1 (as described by the playbook) forces you to see problems where there are none. They are forced and contrived.

A natural check-in every once in a while is much preferred in my book, I trust my team members to bring up actual problems as soon as they see them. A leading question forcing some reflection is fine but forced meetings for the sake of the meeting is wrong.

<comment><USER12> I'm a big believer and user of 1:1s and don't think they're a waste of time, because if there are no problems it gives me a chance to get a coffee, go for a walk, get to know my direct reports - how is that a waste?

The challenge with natural check-ins is everything else in our world is scheduled and it will eat all time not allocated. I block off the time and the schedule tells my team mate "This time is for you".

I trust my teamm members too, but it's not their job to proactively bring up every problem in a timely manner:

Some people/cultures will not do this but they will respond to empathetic, well thought out lines of questioning.

some problems are very sensitive and scary and don't need the added burden of "going to the boss to ask for some time to talk"

Some problems are not apparent and the 1-1 gives you a forum to discover them

Some very serious problems are not viewed as problems by your team members. A huge part of a manager's job is to identify them early.

I do a lot of the casual and emerging management stuff as well; 1-1s are not mutually exclusive. There are bad 1-1s too: right now with everyone remote I think the quality has gone down because we can't capitalize on the personal aspects. You learn that the 1-1 process is the easy part; actually giving a shit and working at building relationships is the hard part.

</comment></comment><comment><USER13> This is written by a coder, for people like him. It's therefore no wonder that people are eating it up: it's telling them what they already "know", or believe to know, or hope to be true.

Does anyone still believe in that 10x coder cliché? I thought we had decided to only use that idea sarcastically years ago? And, even worse, do they all still believe (against basic principles of statistics and logic) that they are uniquely able to identify and hire these übermenschen?

The one distinctly managerial thing it does imitate extremely well is to be both superficial and contradictory: "Set aggressive but achievable goals". Yeah, no shit! "Be customer-focused." Who would'a thunk? Additionally: do weekly one-on-ones, write documentation, sit in on sales and marketing, do whatever "upskilling" may be[0], recognise that hiring is your most important job, and know as much about your software as anyone not doing any of those things.

But, in all fairness, some typical managerial cruft has been cut. Or, maybe, one of the introductory lessons of management at least in the US has so far eluded the author: to at least pay lip service to issues like diversity in hiring or enabling work-life-balance.

If you've seen some of the more successful companies from the inside, you know they have gone through the motions so long they ended up actually believing it, and are now reaping the rewards that come with teams that include people from different walks of life, in both productivity and enjoyment.

Considering we've seen some startups almost disintegrate due to blind spots with regards to privacy, security, or ethical considerations of selling surveillance equipment to dictators or AI to drone fetishists, these larger- than-the-next-release issues certainly seem to deserve mention, as well.

[0]: not killing your higher-ups, hopefully, but also not teaching, because it would be silly to forgo such a common word, wouldn't it?

</comment><comment><USER14> I am currently reading Michael Lopp's book "Managing Humans" and wholeheartedly recommend it to anyone who wants more breadth on this topic. It's a really easy read with some rather poignant examples.

</comment><comment><USER15> Knowing the architecture and tech stack should be a stretch goal.

Depending on the people and the size of the team, people management and communication can take more than 40 hours a week.

</comment><comment><USER16> The most interesting aspect of this playbook IMO is the cartoon. Using 1-1 to bring up promotions.

When employees ask for promotions:

good managers know how to harness this ask with clear, manageable, attainable goal setting and delivering on the promise. Most employees are also not beyond solid transparent reasoning. Average managers get into a defensive mode

If anything good managers are like high-performance coaches, they understand your motivations and channel your energy. The reality is most companies promote people into management roles by picking people like them.

As a counter test, watch out to see if a newly promoted manager starts talking and acting (in subtle nonconscious ways) like their manager or the real power in the organization. Examples include - Working hours, decision making, predictable agreeability and even hobbies etc.

<comment><USER3> As a manager, it's your job to grow your directs until they're ready for a promotion. It's also your job to make sure that they _want_ whatever that promotion entails. Typically speaking the crossover from IC to management is a pretty common trouble point for engineers, and you should make sure that nobody gets put into management who doesn't want to go there. You'd also be surprised about the number of engineers that are actually interested in leadership too, fwiw.

As a manager myself, I actually keep a private sheet of the internal career ladder and progress for each of my directs, with notes and an unambiguous "meets expectations, exceeds expectations, or needs improvement" across each category that company has set for their role. This helps me keep my feedback to them consistent, clear, and focused.

</comment></comment><comment><USER17> This is a great resource! More of a reference / bulleted list rather than a playbook. I wrote something similar for my new front-line managers who were playing with the idea of transitioning from IC to management[1].

The big things really are all about 1-1s, feedback, coaching, and delegation. From everyone I've talked to the hardest part is the delegation piece. It's so easy to fall back on our original skills as developers. And yet, it's more important than ever to delegate those responsibilities whenever possible

[1] [https://adamconrad.dev/blog/technical-lead- management/](https://adamconrad.dev/blog/technical-lead-management/)

</comment><comment><USER18> I was really excited to see coaching listed and it was on target of good advice. But it was generic also. I didn't see any related to permission based questions. And I'll admit I didn't study the material heavily yet but I plan to and hopefully be involved to expand on it. That being said I think this is a great project! I look forward to seeing managers adopt whatever they can

I worked in that industry for a good chunk of time and there is a lot more to it.

I'm no expert. But I strongly believe 1 on 1 are a complete waste of time. I've never seen them be productive.

And don't get me started on 360s. They basically mean you hate your employees

</comment><comment><USER19> 4 hours later and no comments. I think this deserves more comments. So I am putting one here to take this initiative. This has good content.

Edit: and one day ..., when I'm hired as a manager for the first time I can adjust to some things I like here.

<comment><USER20> Agree this is good even for ICs. I am going to take some of these themes into my manager 1:1's now.

I especially like "purpose" since I need to find meaning in my work otherwise I can detach or become disengaged. I work for a big company and its easy for the meaning of tasks to get lost.

<comment><USER19> Perhaps there is a way to find more meaning in the work? A new way to do something, or automate, etc?

<comment><USER20> Hmmm not meaningful enough. I can automate anything, at any company. I mean deeeeeep meaning. Why does this company exist? How do I serve this meaning. It needs to connect with the outside world. Impact people.

<comment><USER19> I am in the same boat. To find myself how I can impact the world or people in a positive way. Deep meaning. Purpose. Right now I fail to get hired at a company I would be so very passionate about at this level. And I must earn my living so that one day I can sustain running a company.

</comment></comment></comment></comment></comment><comment><USER21> If you like this, check out [https://www.manager- tools.com/](https://www.manager-tools.com/) .

They've put together a pretty comprehensive list of topics from basics like how to give feedback, or how to be effective with various types of communicators, to more nuanced stuff like how to deal with a merger, layoffs, or even how to handle personal scent issues.

I highly recommend checking out the site, their COVID19 series, and their map of the universe.

</comment><comment><USER22> This looks like a well curated collection. Kudos to the author.

</comment><comment><USER23> This is a great collection. Lots of useful approaches, some of which I haven't seen before. Sure, some stuff wouldn't work for us, but that doesn't mean it's not useful to know about. Further reading section is also A++.

</comment><comment><USER24> I think I disagree on the "managers don't author features" part. This is leadership 101. Don't ask anyone on your team to do anything you wouldn't (or couldn't) do yourself. Maybe you have 10 years of experience authoring features other places and now you're above that. But what if the place you are now in charge of is so broken features couldn't get released even if you knew how to build them? You're basically going to blame your subordinate individual contributors' skill set or motivation or something. Without trying it yourself, you won't see how broken it actually is.

<comment><USER3> This is complicated, and depends both on the strength of the team and the history of the manager.

On one hand, in many teams the manager is still in a semi-engineering role, and might be the most experienced member of the team. On top of that knowledge of the roadmap is quite the advantage when coding, since you have a lot more context around requirements.

On the other hand, there's a lot of systemic risk in managers deciding which stories they themselves are going to execute on. There is a nasty temptation for the most interesting and/or difficult tasks to get self-assigned to the manager, which creates a silo and stifles team growth.

Personally I do much more hands on early during my time with the team, and during swarms. But in general I tend to stay a bit more hands out and focus on the things that only I can do for the team.</comment></comment>


A C Heisenbug in the wild - <AUTHOR> http://jacquesmattheij.com/a+C+Heisenbug+in+the+wild

<comment><USER2> I don't mean to be that guy, but this is the sort of bug that makes me wonder about the state of professional programming. Even if you're not fluent in C, as a programmer it should be intuitively obvious what's going on here.

Of course we all have brain farts now and then, but there's no way this code should survive a second, let alone a third reading.

Or am I just being conceited?

<comment><USER3> It's non-obvious that asserts would just be #define'd out of existence when NDEBUG is defined if you haven't been told that specifically.

<comment><USER4> As you might be told specifically by, for example... the documentation?!

The biggest surprise for me is that this error survived more than one attempt to remove it...

<comment><AUTHOR> Doesn't surprise me if it's in a 20k loc program. Very easy to overlook the obvious.

That said, like the previous comments, if someone had seriously looked for this issue, you'd have hoped they'd have found this pretty quickly.

<comment><USER4> No, that's a fair comment. I have spent a surprising proportion of the past 10 years moving initialization calls from <random problem-causing place> into `main', so whenever I see a call to something like `someinitialization' I just assume it's in `main' along with all of the rest of them.

But it could easily be somewhere creepy and random, and the side-effects a bit hard to spot, making it harder to find.

(Which, of course, is why you should always put all of this stuff in `main' ;)

</comment></comment></comment></comment></comment><comment><USER5> A C compiler _could_ warn on large classes of side-effecting code inside assert(), as he suggests, but it'd be tricky to decide exactly which kinds of side effects to warn on to avoid too much noise. At the very least, I/O stuff would probably have to be excluded, or else you'd spuriously warn on the common pattern of dumping some debugging info to stderr within a call like assert(everything_ok()).

</comment><comment><AUTHOR> I think "Side effect free" in assert() is the biggest takeaway from this.

</comment><comment><USER6> This is why we should read man pages:

man assert: "This may create Heisenbugs which go away when debugging is turned on."

</comment><comment><USER7> This is why the Delphi compiler codebase (written in C) uses two functions, "invariant()" and "invariant_if_debug()", instead of library-supplied asserts. The second gets compiled out in release; the first triggers internal compiler error diagnostic even in production.

<comment><USER8> I was under the impression that Delphi was written in Delphi.

<comment><USER7> The Delphi IDE is written in Delphi, but the Delphi compiler is written in C.

<comment><USER8> Ah, interesting. I'll have to tell that to my dad, who always told me that Delphi was one of the earliest self hosting languages.

<comment><USER9> Delphi is an object-oriented variant of Pascal. Pascal has been self-hosted since the late seventies.

</comment></comment></comment></comment></comment><comment><USER10> Avoiding this kind of bug is one of the reasons why Go doesn't have assert().

</comment><comment><USER11> The Python analog would be something like this:

assert (object() < object()) == False

(try running this in the interpreter a few times)

<comment><USER12> Woah... so this is coercing it to a string and the address in hex is being compared. Am I off on this?

<comment><USER13> Yes. Python is not that mysterious.

For generic objects, the __lt__ and __gt__ methods are simply defined the only way that's sensible, which is effectively as a pointer location comparison.

</comment></comment></comment><comment><USER14> That's not a Heisenbug. That's just a classic newbie mistake. If it's made by a non-newbie, then I highly question their competence.

</comment><comment><USER15> This is the reason why I think it would be preferable for assert() to use eager evaluation. Any optimizing compiler will optimize away the useless check if debug mode is off, even if function calls obscure it (as long as the compiler can reason about purity).

</comment><comment><USER16> Trivial stuff, really. Useful to know - sure. Worth several pages of the blog post - hardly.

Now let's see the HN fanboism in action. It is Jacques' after all.

<comment><USER17> You're not necessarily wrong, but try being less nasty about it.</comment></comment>


Emailify - Internal Stylesheets to Inline Styles  - <AUTHOR> http://burrowscode.wordpress.com/2011/02/19/emailify-internal-stylesheets-to-inline-styles/

<comment><USER2> This is really cool! I will definitely be using this in my current Rails app!

I must admit it took me a minute to remember that when I created my email templates that I had to do inline styling. When I looked at one of them just now I remembered the hatred. I'm going to forkify emailify so hard.

<comment><AUTHOR> Sweet man, I'm working on ironing some bugs out right now. Getting the scoping mechanism to be conformant is my next focus.

<comment><USER2> Awesome, that will be quite useful.</comment></comment></comment>


Cloudflare: 18.104.22.168 for organizations - <AUTHOR> https://blog.cloudflare.com/1-1-1-1-for-your-organization/ <comment><USER2> The macOS installation instructions are missing a few details. They should include information about (1) what to do with the previous server addresses, and (2) whether the Search Domain should remain the same.</comment>


Chips in brains will control computers by 2020: Intel - <AUTHOR> http://www.computerworld.com/s/article/9141180/Intel_Chips_in_brains_will_control_computers_by_2020 <comment><USER2> Very interesting article. Just like most things, this could be very good or very bad depending on how it is used. Seems like the human body is the most advanced breakthrough of all time. Can a computer chip augment that?</comment>


Ask HN: How do VMs hot swap native code? - <AUTHOR> * The JVM compiles bytecode to native code on the fly<p>* Lisp implementations like SBCL take an expression entered at the REPL, compile them to assembly, and insert it into the running process<p>How does this work? I think I should be looking at the internals of some scheme implementation, but am not sure where to start. <comment><USER2> Check out the VM for Factor. It is really well-written: [https://github.com/factor/factor/tree/master/vm](https://github.com/factor/factor/tree/master/vm) It's based on HotSpot so you could check out its code too.

In short, the answer is to think of everything as an object. A pointer is an object, a block of compiled code is an object, a return address is an object, an execution context is an object and so on. All these objects are related to each other in one huge object graph that the VM keeps track of. For example, if one code object (such as a function) calls another, then the VM views each address in each assembler CALL instruction as one pointer, pointing from one function to the other. So if foo calls bar and bar is recompiled, a new code block which we'll call bar' would be inserted at the end of the code heap and then each CALL instruction in foo would be updated to point to bar' instead.

This can get quite complicated if another execution context is running baz which was called from bar. How can we ensure that it returns to bar' instead of bar? We would have to go through the stack of the execution context and update all return addresses stored in it so that they point to bar' instead of bar.

Of course all this has to be done as efficiently as possible so VM implementors use huge amounts of bit fiddling tricks which obscures what the code is doing...

</comment><comment><USER3> I can think of three VMs that do JIT re-compilation along the lines that you mentioned.

Google V8 is fairly well documented, but I think it is very complicated.

JVM is a beast. Perhaps the openJDK project has some useful information.

Personally, I would look at Racket Scheme: [https://racket- lang.org/](https://racket-lang.org/) The main reason being is that there are several papers that describe how it is done internally.

A simple example that could get you started may be found at: [https://eli.thegreenplace.net/2013/11/05/how-to-jit-an- intro...](https://eli.thegreenplace.net/2013/11/05/how-to-jit-an-introduction)

<comment><AUTHOR> Thanks a lot! TIL there are libraries for that.</comment></comment>


RNN or Recurrent Neural Network for Noobs (RNN Explanation and Code) - <AUTHOR> https://medium.com/@debarko/rnn-or-recurrent-neural-network-for-noobs-a9afbb00e860 <comment><USER2> Keras for explaining a basic RNN model? Really? Do it in Numpy and it will be a lot clearer what's going on.</comment>