Moonside

2

Moonside wrote

The recent slew of articles I've posted is btw just the result of closing the million tabs I have open on my phone.

2

Moonside wrote

I appreciate the work put into making these recordings available, but the pedant in me is unsatisfied how the release years aren't in titles.

5

Moonside wrote

I think these are related: valuing super unapproachable games has had a quite a bit of connection with worries about minorities getting into the pastime. Ergo, it's not a surprise to hear a tantrum like this after the failure of the title afterwards if the main problem was learn-to-swim-or-drown difficulty curve.

2

Moonside wrote

Honestly it took me a while to figure out as well. But despite all, it's the best I've used.

2

Moonside wrote

I listened to the beginning of this while lunching yesterday and it truly is an episode. It is wild stuff and you get to hear game industry stuff that's usually insider baseball.

3

Moonside wrote

The curious thing is that I've never really seen functional language pseudo being written. But then again I'm not a serious programmer or a software engineer.

3

Moonside wrote

Tbh in that specific case I'd just use mathematics:

f(n+1) = f(n) * g(f(n))

which is almost an implementation in some functional languages. (Nb. it's very nice to be able to use n+1 or 2n style notation in parameters, it can clean up expressions a lot.) Obviously the base case ought to be treated somehow, but that's besides the point.

I would say that ad hoc usage of pseudocode seems innocuous to me - sometimes you have improvise and there's not an common agreed upon system to draw on. Perfect is the enemy of the good. But I think its virtues as a tool for planning and documentation aren't great. If you go forth and plan or prototype your project in pseudo before implementation, why?

I'm speculating here as I don't have access to any empirical research treating this topic.