60654

> A secondary factor caused by real estate hyperinflation is that all the stuff that once made the SF Bay Area so interesting has been priced out. I remember the Bay Area in the 1990s. It was a hub not just of tech but of art, music, and culture. It was a magical in a way that's hard to explain today, and I say this as someone who only visited. My main experience of it was from the culture and "vibe" it exported. All that is gone now.

That recapitulates my experience as well from living in SF. There was a feel of the city that has since disappeared. For me the breaking point was in the early 2010s, when I noticed all my nontech friends disappearing - they were getting priced out and moving, mostly out of state. And the conversations in tech changed too, from doing interesting and weird and exploratory things, to conversations about money, getting vc funding, and working on things that will make even more money.

The vibe was turning into a 90s wall street, and not the old city where everybody was a misfit and did their own weird thing. That's probably the part I miss the most.

Do you have any links on the Detroit AI you mention? All I see on the GDC vault are talks about lighting and engine tech, can't seem to find any game AI info.

Nice intro! Some of the more advanced techniques (MCTS, GOAP/planning and so on) get the short shrift, but it's totally expectable for an intro article.

And the early section on constraints is especially great. Game AI has to worry about enjoyable performance and variety of challenges given almost no CPU time, which makes all the difference...

For something that has state that is not always fully known (for example, some cards have been played so we know what they were, but we don't know what's left in the deck or in other players' hands), what we're describing is a _partially observable_ Markov decision process, or POMDP.

In short, a regular MDP models moving from one state to future states with some probability. In a POMDP, we don't know which state we're in, but we have some guesses, i.e. we have a probability distribution over all states. So we model a sequence of taking actions and performing observations, and using those observations to update the probability distribution, so that we can reduce the uncertainty as much as possible.

The typical example is robot navigation, where POMDPs are used extensively. For example, a blind robot starts out somewhere, it doesn't know where, so the probability distribution over all possible locations is uniform. Then it moves north, and discovers that it was successful; this observation modifies the PD to states that are reachable by moving north from previously likely states (conceptually: this will exclude all sorts of corners and dead ends from consideration). Then let's say it tries to drive north once again, but it discovers it bumped into a wall and was unsuccessful. Now the PD gets updated again, based on previous PD and the results of this action (conceptually: we bump the probability of any state that we can drive north to, and hit a dead end or a t-intersection), and so on. As this sequence of actions and observations continues, we hope the probability distribution will collapse to the specific location that we're in, or a small set of guesses.

(This is a narrative description of course; for the nitty gritty details there are many more precise materials on POMDPs! :) )

By the way, this is still a _Markov_ process: the trajectory of _how_ we got to some probability distribution doesn't matter, if those sequences of actions produced the same result they are treated as equivalent per Markov assumption.

Big book being written right now with beta chapters available:

http://ithare.com/contents-of-development-and-deployment-of-...

Also this site has a nice collection of very widely known blog posts on networking for gamedevs:

https://gafferongames.com/

Hmm, Moby is quite avant-garde, or at least was back in the day... But why would anyone want to build IoT products on top of an aging DJ?

(... I'll show myself out.)

Because of soil issues, the Transbay Terminal (Salesforce) builders had to anchor the foundations in the bedrock, which is unfortunately deep under layers of landfill and soft sand. But this fill and sand is exactly what will get liquified during a big one, so they didn't have much choice.

But what's weird, IMO, is that some of the shorter highrises like the Millennium Tower were approved to be built not anchored, but on pylons floating in the soil layer:

https://sf.curbed.com/2016/9/16/12945600/why-millennium-towe...

https://sf.curbed.com/2016/9/15/12930402/millennium-towner-s...

I mean, sure, as long as things are stable, the weight of the building will keep it in place. But I don't think anyone knows how the soft layer underneath most of SOMA will behave, when a big earthquake comes. People know it will undergo liquification, but by how much, and what will it do to buildings on "floating" foundations, that's not certain...

Iterative prototyping is great. The Cerny method is mostly useful for games that have tons of content, rather than systems. For example: an RPG that has tons of areas and weapons and characters. It's totally a good idea to first build a vertical slice with only one area, and a few characters and weapons...

But for systems-heavy games this falls apart. For a game like SimCity or Minecraft, making a proper vertical slice would mean building 70% of the game! That doesn't really help de-risk anything. :). For systems games it's much better to do iterative prototypes, accumulating systems with increasingly longer feedback loops...

(Source: my experience making systems-heavy games :) )

Yeah, all those ads about how they're going to fix fake ads, and clickbait ads, and so on, all over the L stops...

They're buying ads that try to influence public opinion, about how they mishandled orgs buying ads that try to influence public opinion. :)

Yeah, there are multiple reasons. Perf is important: inverse trig functions are generally much slower both on the CPU and on the GPU [1]

But also - most of the time gamedev happens in 3D space not in 2D space (even if it gets rendered down to 2D). So it's more natural to do a dot product of two 3d vectors, than try to mess around with trig functions that work on scalar angles. Same with rotations: it's easier and better to use quaternions in 3D space than try to rotate along each axis separately.

[1] GPU intrinsic estimated costs: http://www.fractalforums.com/programming/shader-function-or-...

I can't tell if you're trolling or are just not up to date on game AI, so assuming the latter: you have to think beyond chess. There's much more info on interactive storytelling in the AIIDE proceedings I linked to, it's a very active area of research. Academically it goes back at least to the mid 90s, Oz project at CMU for example, or MIT Media Lab projects. And in commercial production, interactive stories are as old as the industry, probably the best early example is Infocom but back then there wasn't much AI driving it; it's not until the 2000s that people started actually building "drama managers" for shipping games to introduce dramatic conflict dynamically.

It's a nice historical overview of using search and ML for formal games like chess.

But - this is not the game developer usage of "game AI". Where are wargames, where are artificial characters, where is interactive storytelling, where are realtime control systems, and so on, and so forth? The doc is missing a lot of the actual history of game AI, which is much wider and more varied than presented here (and ML approaches are still in minority).

Anyone interested in game AI history should definitely check out the past proceedings of the AIIDE conference: http://www.aiide.org

Re "midwestern highways": haha, I don't see a "self-driving" car navigating the I-90 in Chicago anytime sooner than SF. ;) At least SFBA has super mild weather that makes the obstacle detection problem much easier. Here there are only two seasons: winter and road construction.

(But yeah, we are very far from cars navigating urban areas, or indeed anyplace where weather is inclement and so are people.)

"Three weeks in the lab saves you three days in the library," as the old grad school quip goes. :)

(And yeah, this is a classic failure mode of TCP...)

Not the parent, but I have two specific suggestions about the on boarding process.

One, please add a directory (feed?) of public conversations that can be viewed without logging in. I want to see how the platform is used by other people and whether that fits me - but if you ask me to create an account first, I'm going to bounce.

Two, here on HN you say the team is mostly cog sci and engg people, which sounds awesome and piques my curiosity about why you made this. But the web site itself doesn't mention that, or anything about the people behind it. Please add an 'about the team' page so that I can understand more about the people who are inviting me to use their platform.

Hope this helps!

AI is the overall field and the superset of all of the various approaches.

ML is one family of approaches for knowledge acquisition in AI, but far from the only one (eg. logic based inference is another big one).

DL is a family of approaches in supervised ML. As the author points out, it's a subset of a subset.

But saying that this sub-subset "drives" AI is like saying endocrinology "drives" medicine: not the right mental model at all.

That's because Generation X is tired of all this millennial talk, as Gizmodo explains so well:

https://gizmodo.com/5851062/generation-x-is-sick-of-your-bul...

;)

Ahh the pedway. A lovely idea, but every piece of it is in different shape. Some bits are nice (Illinois Center), but others are super dumpy (from Macy's to Millennium Station), and anything in between.

I hope this attention from the Architecture Biennial will result in some new interest and cash to freshen it up a bit. Because right now it's just raw and utilitarian, in that unsentimental way that Chicago infrastructure tends to be... :)

I'm guessing Millennium Station, since the pedway doesn't cross the river...

I was waiting for the part about how this game "changed video game localization" but it was not there. Just a clickbait title.

Overall nice post, though. Translation is hard, and especially getting the feel of a particular place in time.

It was neat to see their examples of turning plain Japanese into a quasi-Elizabethan English in order to match the vaguely medieval setting of the game. That's something that's really hard to do (because it's more than translation, now you're reinterpreting the original text)...

Yeah, having done robotics in the past, I'm super skeptical of promises of level 5 autonomy in the real world, even in the medium term.

I mean, we were able to do level 5 trucks in the desert two decades ago! But the human world is much less benign, and the perception problem is hard. And the history of AI is littered with limited solutions that failed to scale.

So I'm more curious about the purported GM testing of level 4 in Manhattan, it's a much more realistic and far less forgiving driving environment.

Maybe in towns, but not in big cities, NY, Chicago, LA, or even smaller ones like SF. Most of the time, if you try to strike up a conversation with a stranger, like trying to chat to someone you don't know on the train for example, they will be polite but not engage - and they will probably assume you're trying to sell them something etc.

There's a number of tech solutions to scaling mob AI. Most of these are also applicable to non-online games as well:

- Running AI at a different frequency than the game. The network event loop might run at 30Hz (33ms tick delta) but AI doesn't need to make decisions that often, maybe every 100ms or 500ms etc.

- Separate decision making from performance. A cheap execution system can run at a high frequency, while an expensive decision making system runs at a lower one.

- AI LOD. Mobs that are far away run much simpler AI that doesn't try to perform detailed animations etc. Mobs that are in unpopulated areas get frozen, and thawed once somebody enters.

- In instanced dungeons, mobs don't even exist until the players enter, and once players leave, the mobs just get unceremoniously killed.

- Offloading. Mobs are just game agents so in online games it's possible to offload them to other servers that get load balancer as players move about, areas get frozen etc.

Basically the big question is: if nobody is interacting with a mob, does it need to exist? In most online games they do not. And even in sim heavy games, maybe they don't need to run the same high fidelity AI when nobody is watching.

Then the last tip is:

- Make the AI as cheap as possible for the task at hand, but no cheaper. A mob in MMO that is all aggro and easy to kite doesn't need to have complex strategic cognition, and it would probably be a detriment. Everything need a to match it's context.

Source: I make games. :)

City proper - outside of the lakefront - is not prohibitively expensive either.

But I'm just weirded out by how the article discounts Chicago based on assumptions about, what, tax policy? Where is this coming from? The Rahm is lobbying hard, and he's very pro-bigcorp, as McDonald's new 500,000 sqft world headquarters in West Loop can attest to.

Regardless of where Amazon lands (and I don't really have a horse in that race), Bloomberg's weird hang-up about Chicago are no more than a distraction. It's bad enough that Michael Bloomberg is personally spending $millions on TV ads to support the Cook Cty soda tax in a state where he doesn't even reside. Ugh.

Thank you! It's so good to see hype free discussion of this stuff.

I would also add that using simulations to test (or train) robots is also not new, and has significant limitations. Robotics has been using simulation since before the Grand Challenge, but what we find is that simulations make simplifying assumptions that don't bear out in real life: simulated sensors are more idealized than in real life, object recognition is idealized, actuators are idealized. But that makes it hard to apply any learnings to the real world, where sensors hallucinate and actuators lie all the time.

And yeah, we _could_ be fuzzing the simulation and adding failure modes, but not many people do. It's hard to simulate these kinds of defects in a usefully realistic way.

Hah, yes. Glad to see others were weirded out by that too. It's so strange to see people seriously discussing how to redesign the trimmings, when nobody even has an existence proof that fully autonomous navigation _is even possible!_

And it's not like robotics research hasn't been working on this problem for half a century now. It's a hell of a hard problem that one can't just product-design their way out of.

> Most people aren’t in tech or law or teaching in universities; they fall solidly in what is called working-class. They work as electricians, carpenters, plumbers, in hospitals, restaurants, as clerks, office managers, farmers, etc.

I'm surprised that he's surprised by this. Even in SV you can have a reality check, if you just deign to strike up a conversation with the cooks and the bus drivers and the janitors who work all around you. No need to take a road trip to the summer house to have this epiphany, just open your eyes.

Yeah, same story with Chicago. Big tech scene (esp finance), some big universities (Northwestern, UChicago, UofI, IIT, etc)...

But in the end, it's the country's third largest city, the metro area is huge, and tech is just one industry of many. The number of jobs may be large, but the percentage will never be as high as with small, specialized towns.

> That's what you need as an indie developer. A lot of publicity and great art. It doesn't matter that you essentially reproduce the exact same recipe as any other Nintendo platformer, as long as you have great art and music, people will love your content.

Oh how I wish that were true, it would make for such an easy formula to follow to commercial success! :)

The visual style is definitely unique, and will get them a lot of media attention. Good for them! But translating that into sales - that's not easy at all...

Glad to see they're framing as a capital/labor question, because there are additional important considerations about robots replacing labor, in addition to increased productivity:

1. Robots are capital, and therefore investment, while labor is a pure expense. Capital will generate income that can be reinvested back into more capital etc, generating more wealth for the owner, and they can sell those robots later to turn that investment liquid.

But labor is purely an expense, and the money that a manufacturer pays to employees is wealth that they've transferred elsewhere, it doesn't compound, and it can't be owned and controlled like capital can.

2. In terms of taxation, governments in Europe and US tend to: 1. Tax labor relatively heavily (income taxes), 2. Tax capital gains relatively lightly, and 3. Do not tax capital ownership as such. So it's rational for capital owners to try to replace labor with capital if it can perform the same tasks - with tragic effects for labor.

Following Piketty, it seems to make sense to introduce a small but nonzero tax on the ownership of capital (not just on capital gains at the time of a sale) to offset these changes.