mntmoss

In this era I was a pre-teen and my brother, a few years older, did make a stab at tracking but ultimately focused on other things. I was a bit baffled by the whole thing and we never learned how to rip samples off other sources even though we definitely had the capability for line in and some sample editing tools(Just record off the radio or our CDs! It seems obvious in retrospect).

But it was very exciting to hear other people's work, regardless. Computer music - and it sounded like the stuff I heard in malls and on TV, instead of the synthy chiptune stuff!

Gradually I did start experimenting with composition on trackers and that proved to be another mountain climbed only gradually. Even when I had "the sound," it takes a lot of work to understand how to a bring a song structure beyond a four bar loop, but I would have to say that I learned a fair amount from studying tracker music too. A good success story for source availability.

The strategy is meant to introduce more sunk costs in the hiring process. They spent forever buttering up the candidate, and now they hear a number that is more than they were hoping for.

The less they need you, the less this is likely to matter. But if they really need you then of course your price is high!

I've thought similarly and extrapolate this to a kind of spectrum of "numbness" vs "sensitivity" that occurs in everyone in varying forms and degrees. This helps move the discussion away from one of objective character towards one of appropriate opportunities and role fits.

For many people, the pain of a certain kind of work goes unnoticed. They aren't stressed, and so they can succeed wildly. It could be physical labor, technical problems, dealing with people.

For the pathologically successful, the thrills come through something that most are too sensitive to handle. Think of surgeons operating on themselves, athletes who play extreme sports, artists who eagerly turn their most private thoughts into commodities, businesspeople who stay up late dreaming of ideas for exploiting the land and the people.

On some level all of these folks are monstrous - but society, where it is wise, finds a way to validate their interests to some greater benefit.

And I do see some whiplash frequently occurring with people just leaving school and coming to terms with these limitations of sensitivity, and their gradual development of some ethical center. They can't just do a good job and go home, like they thought. They can train as hard as they want, but they can't not feel the thing, and that puts them in a state of preoccupation about the problem.

The silver lining to this cloud is that someone who is both sensitive to the issues and a survivor among predators can put themselves in a position to change the rules, especially in business, because they are most aware of where the market will reward ethical behavior. It's surviving that long that's the problem.

Knowing more simply means that there is more philosophy to be done. Every scientific breakthrough comes with a renewed discussion of its best purpose in society.

Is an expensive DFA something that could be mitigated with source code hints? An 80% solution might do the trick.

A pretty good example of where physics have gone in video games is in pinball, pool and golf sims. The earliest of these generally had very simple ball movement behaviors and the constraint solving, to the extent that it existed as a concept, was designed to execute fast and model physics sometimes. And this remained basically true through the 16-bit generations.

But by the mid-90's it was just starting to be possible to do it somewhat right. There were a lot of pinball, pool, and golf games released in this time frame, as well as some of the early physics puzzle games(namely The Incredible Machine).

So by now you'd imagine it's close to perfect, right? Well, not really. Most video pinball games still emphasize the "video" part of it. Bounces are muted, the ball rolls a bit too smoothly, and the flipper angle dictates the shot trajectory more than in reality. And the same is true with other genres: there are plenty of things not modelled.

The best sim games are much better, but they still have their lingering issues.

Most of the effort that goes into a large game project is not in the runtime code, but in content creation: you probably only need one renderer or one physics system, but lots of levels, lots of characters with unique behaviors. So what does every one of the top general-purpose game engines provide? An IDE geared around content creation.

It is no surprise that you can find a benchmark where a general-purpose engine is slow. If you do nothing you go fast, but if you are supporting general-purpose use cases you add a lot of feature overhead, so you become slow. Why do pros use it, then? Because - if the engine is sufficiently extensible - they can use the built-in stuff as a placeholder and replace that subsystem with a custom one later. Project ships, everyone's happy.

With microbenchmarks based around scaling simple elements like "thousands of bullets" like the one in the video this point on general-purpose elements is especially important. As soon as you want to add any additional behaviors to those bullets your performance is going to plummet. And from a game design perspective, scale becomes boring very quickly. A player cannot really appreciate seeing more than a few hundred things on-screen at any moment.

So the way scenes are actually benchmarked in industry is by building out more of the behavior, adding placeholder assets at the estimated level of detail, seeing what frametimes result, and developing a scene budget around that. It all feeds back into the content creation pipeline again, because an optimized scene will have more care given to each of its assets.

Screenspace was always x-right, y-down (aka Cartesian quadrant IV) because that was the convention NTSC used to paint the screen.

3D has not had the benefit of an obvious hardware model to emulate. Y-up, Z-up, Y-down are probably the three most common variants though.

I believe the original article is bad, but not simply for the reasons you state.

It's rather part of a tired genre of "kids these days" articles where modern technology has somehow poisoned them beyond comprehension. In fact, kids tend to do things in a pragmatic and rational way, and it is on the author to appreciate what they are and are not savvy about.

The typical pattern around new technology in my own life(30's Millenial) is that even within the generation you get people who develop a specialty, and their counterparts who learn to be good at asking for assistance. And intergenerationally the pattern magnifies as you get more and more dependencies on the group of true experts, and there's often a gap in the training of the next group - "no careers in this".

People perhaps 30 years older than me - the Boomers - would have come of age in the mid 70's, right as semiconductor ICs really started making waves. The probable focus of their attention with respect to technology would not necessarily be "computing" but "electronics," since so many consumer electronics suddenly became possible. But as consumers they would want service and support, and so the nature of the sales around this stuff was to promise that they could use the device in a very basic way and have someone take care of them if it broke.

The Gen X and cusp Millenial crowd, on the other hand, grew up with the devices ambiently around them and little marketing dialogue(what dialogue they had would be diverted towards toys and games consoles). Their incentive was to figure out enough to fix some yard sale or dumpster find; and modern notions of computer hacking derive from that romanticization. But the reality for many folks in these generations is that they can only be self-reliant in so many ways. It takes unusual persistence to reverse engineer your computer starting from nothing or only the most basic kind of information, and yet that is often the kind of story heard from people who "got into computers" around this tine.

As you get to the more Internet-connected era, it gets a lot easier to get directed to some kind of help or guidance, and that made for a substantial generational shift, although a lot of my memories of programmers on the early Internet is of the most arrogant, ego-centic types anxiously blasting anyone who dared challenge them. The word "toxic" had no parlance yet.

I believe the main challenge that is faced by the younger crowd now is what happens once the brightly paved road to knowledge drops off - there are lots of "friendly" 10-minute video tutorials for everything, but often the conceptual depth is missing, and so you have a cycle of learning and relearning with more rigor, while it would be more common in the past to jump from self-experiment straight to academia, simply because all the knowledge really was centralized there.

Hey lostgame, here are some thoughts:

1. This time of year is notoriously tough on mental health, and that's probably part of it. I got a subclinical case of SAD during the holidays. No triggering reason, life is generally OK, but I really was not very active outside of some minimum activity. I am finally coming out of it now that the days are noticably longer.

2. There's also been a seasonal cold going around that I just started getting over today. Its symptoms were mild but included some amount of disorganization and inability to focus. Really dramatic between yesterday and now in terms of how much I accomplished and how difficult it was.

3. All that notwithstanding, I have had a few traumatic experiences that resurface on occasion. The most effective thing I've done is to find a hobby that is really intensively engaging - not just idle escapism like most entertainment but the top-end, "I have to stay 100% in it" kind of stuff. For a while judo did this. It's a large committment, though, and I can't always find time for it. More recently pinball has filled that gap, and pinball is something I can get a quick fix of on my phone. Both of those games assault the senses and require my total attention to succeed, which really does a lot to reduce the ruminating aspects of traumatic stress.

4. When I want to ruminate and escaping won't do the trick I will turn to a diary. In here I try to settle my thoughts with storytelling. The goal - and there is a goal here - is to not just report the facts and rationales like a detective but to make a fairy tale out of it, adding in the kind of symbolic resolution you feel is just or in character with your beliefs, even if it means adding fantastic elements. When you do this, you change the story into one that allows you to heal and guides your identity back towards something stable. The "healing story" is an old folk technique, and a good, low-risk one to try.

5. It probably isn't the job, and like others are saying, you want to keep that. A good rule to work from is "fix ordinary things", and if the job doesn't need fixing then it probably isn't the focus.

Everything can be a struggle. Let yourself rest, but also don't let things go when you have the energy and focus, even if it means silly stuff. I realized that my habits are such that I am really focused to do a little more coding right when I go to the gym...and so now I go and immediately use their bathroom to get in an extra 20 minutes. I go in the off hours so there isn't a traffic jam, but it's like, "well, my mindset is good here, why not use that?" Sometimes it is little stuff that adds up like that, that gets me through the day.

Though I'm tempted to agree, there is an old macroeconomic observation that might throw a wrench in the analysis, which is that the waves of new technology seem to be coming faster and faster, and likewise, the turnover of companies in major stock indexes has also gone faster and faster.

In an imagined hyper-accelerated future market where the trend continues, companies will be born, grow large, be disrupted and die in a figurative eyeblink. And Google's lifespan would be cut considerably shorter in such a circumstance, if for example something like Brave's business model were to hockey-stick and disrupt their golden goose.

However, the counterfactual to that is that there surely is some kind of end to accelerating turnover in the markets. And it's a statistical rule; individual companies can be hardy survivors given the right circumstances and management, and companies with longstanding platform monopolies, like IBM, MS, Oracle, and now Google tend to have a lot more freedom to redefine themselves; it's the customers that get screwed, not the company. All the company has to do is find a way to move its customers to the next-gen platform, and even when they start failing at that, like IBM, they have a lengthy fall.

The best-case end result of this instability, of course, is the "double interface" - an interface abstraction on top that talks in terms of the domain problem, and then a second layer to convert the lower level interfaces into that abstraction.

Unfortunately GUI is particularly fiddly and difficult to write the double interface for, since you get a "thousand words is one picture" problem: it doesn't reduce well to text.

The main limitation to the AI governor model, which has been tried in many games to varying success, is that the solver necessary to make them play like an optimal player tends to start encompassing more and more parts of the game mechanics as you add in tricks like "use a worker to rush production" or "plan improvements to coincide with tech advances". The player, likely to be of a controlling or anxious mindset, will reject the idea that these details can be left up to an unaware AI, and given the option to do so they will micro-manage the fun out of the game.

When the game has relatively few options that can be played to a high depth, like Chess, of course, it's easy to write such a competent AI with a brute-force approach. But that's usually not how 4X games are structured: there are a ton of decisions involving overlapping timers and resource bonuses and force committments, and so the top-end strategy revolves around leveraging everything in a just-so way to accelerate growth and minimize losses.

The move towards lower micro and symmetric balancing in newer games has the upside of downplaying much of this; your advantage, where you get one, is much less likely to come from careful micro employed to replicate a 50% advantage in a single scenario hundreds of times, and AI benefits as well. But it also loses some of the charm of weirdly unbalanced 90's strategy.

Lately I've been testing a "third way" of thinking about refactor/rewrite decisions, which is to first document the existing requirements.

The trick is in making those docs so small and lean that they fit neatly in comments inlined with key functions, and this I have accomplished by reduction to a list of "must" and "cannot" (abbreviated to + and -) bullet point items. It must function like this, it cannot function like that. Some requirements can be turned into automated tests or static checks, others need an eye to verify. But the cycle I'm seeing often works out to be: write speculative requirements, write speculative code, then reverse-engineer true requirements and maintain code against that.

Doing this creates a base quality bar that the code has to hit in both the rewrite and refactor cases. The trap that rewrites tend to fall into is that the requirements are lost during the rewrite, so the new code becomes just as speculative as the original greenfield code. If you have the requirements as your reference, on the other hand, the area of bad code you can write is limited to the boundaries of those requirements and any missing requirements. This makes new code much less of a gamble.

As a service, the gig economy deliveries are very low quality and low accountability. I just walked into a Mission taqueria and had to wait on not one but two Doordashers. The first one left with the second's order, came back, and said, "never mind, I'm cancelling."

Recently Safeway has also made a move to use Doordash. My parents have used Safeway's delivery for years and the change is terrible there for a different reason: an order from a grocery store is likely to be 10-20x bigger and more expensive than an equivalent restaurant order. The scale turns it into a fundamentally different job - how much you're lifting, the best type of vehicle, the value of the cargo, the emphasis of the throughput/latency equation. Each time since, when they get an order, it's by someone in a hatchback who is unused to the work. Safeway drivers previously did not accept tips, and so one of the big draws of Doordash is missing. Since the stores have handed off the customers to Doordash, updates on delivery status have become more difficult to get.

Identity is a pretty critical element to this, it turns out. If the restaurant knew their regular deliveryperson and could coordinate that info, they wouldn't send out wrong orders. If Safeway could specify drivers from a pool of truck drivers with freezer units and connect the customer to them directly, as they had before the change, there would be less of an unknown in ordering from them.

On the other hand, it's a case of "it can probably only go up from here" since competing on quality is likely to become the case if the economy stays fully employed and regulation starts creeping in.

Advertising readily exploits low price consumers like you, too.

First of all, they find ways to drop quality. At first they have the good deal for a limited time. This results in social proofing - good reviews and customer approvals - that theirs is the exceptional choice - quality at low price. Then they downgrade it. But because you were already buying it, you won't look the next time.

Second, they find ways to engineer deals that lead you down a path of more expensive dependencies. You go to the supermarket, and you get your veggies, and you see a sign saying "best enjoyed with" - and there's a product. Maybe one you know and are familiar with, maybe one you don't. Regardless, you see the sign and the message and you start wondering, "am I enjoying my veggies less because I'm doing it wrong?"

The dairy industry has succeeded at this for decades, crafting all sorts of narratives about the necessity for milk, the pleasure of milk, how milk lets you have moments shared with friends. It doesn't have to have a brand name attached to reach you and reprogram you.

I would vouch for the last few decades seeing quality improvements: it's become very easy to purchase obscure goods online, to get frozen gluten-free dinners, find product reviews, learn about foreign countries, and other things where the process isn't always saving hours, but it is in some way putting more guarantees on the experience and hence adding a certain dimension of freedom.

At the same time it's become apparent that fewer hours of labor and more benefits with a pay cut is desirable for many, and we're in a "superstar" economy that discourages such. The oft-heard complaint is that we can't enjoy these technological wonders since we have no time.

"Citizen Kane of gaming" is a memetic joke in game criticism. Go check out Critical Distance if you want to see an aggregation of lengthy deep thoughts about games.

All art is borne of appreciation - and thus literacy.

Games are still in a place where literacy is relatively low and the popular vernacular changes with every incoming freshman class and generation of consoles. That doesn't mean that the art does not exist, it means that most people can only temporarily agree upon the most recent instances of it; the others are "not real games".

But on the design and development end of things, the vocabulary is gradually establishing itself. Colleges are churning out fresh blood for the industry at a torrid rate now. There are bonafide career veterans with decades of experience guiding them and offering words of wisdom. The industry often gets in the way of the learning by putting so much focus on product(and the subsequent disposability of that product in turn creates a vast catalogue of attempts that go unstudied), but the learning is taking place regardless.

I don't think the predictions the article makes are exactly what will happen, regardless. The increasing emphasis on customization is atomizing the production process into ready-made software and assets; in so doing, that inches everyone slightly closer to being developers. It's a gradual philosophical shift that's in motion, here.

One thing that struck me when I started studying pinballs in more depth is that they really had the same basic technologies in use between the 40's and the 70's, decades spent entirely on finding creative uses of EM relay logic and coils and rubbers. To the extent that those games have memory, it's just enough to count credits, trigger a score reel and serve bonuses.

And that scale of logic translated into a microprocessor makes for some pretty trivial software; the games got to skip over all the intermediate technologies of vacuum tubes and drums and core memory. So part of that initial video game boom - and the corresponding switch to solid state pinball - really was a kind of seeking out of applications for hundreds to thousands of bytes of memory, often supplemented with existing analog tech. It's a fascinating crossover in many ways with a punctuated ending: the '84 games crash and the '85 computers crash precipiated cheaper RAM and in following years, suddenly all the games started having more expansive worlds, full soundtracks, keyframed sprite animation etc. The development shifted from a hardware and manufacturing focus to a software one; and the computing devices became much more convergent and portable. And that is the trend we've been on since in the consumer space - inexhaustible cravings for more memory and higher fidelity, held at bay only by the whims of hardware teams.

But I'm looking at coverage of CES this year and see this long trend as something that's played out, with a lot of companies across the board aiming to pitch new concepts. We're in a space where people have Enough Memory. So things are getting exciting again.

Everything can benefit from having a dose of storytelling to it. At the same time, the stories being presented to broad audiences are almost certainly flawed in ways reflecting the power structure, as you've detailed. Marketing teams tend to live and breathe story and so will often draw upon myths that please the key stakeholders - management and executives. Those myths then circulate into the atmosphere and at times reinforce themselves, but it is absolutely necessary to combat them and demonstrate strength.

The best way to do so is to have counterexample myths available: not just your personal story or "buttoned-down" aspirations of serious productivity, but a bit of a fairy tale, with symbolic and metaphorical aspects, and perhaps something comedic as well.

When you move the conversation away from the concrete and into the fictional you gain a lot of room to manuever and define your role: not a hapless geek or myopic code monkey, but a brave knight or a spellcasting wizard, suddenly embodying the powers of those archetypes. Indeed, there is an extant tradition of programmers using those metaphors and others as well: the ninja, the Zen master, the blacksmith, and so on. From this cast of stock characters you can adapt the specific theme you need to address into a small plot spanning perhaps a few sentences - something you can scribble down during a meeting. The result will carry far more rhetorical power than a plain argument.

As a follow-up, I recommend Nancy Mellon's "Storytelling and the Art of Imagination" as an inspirational resource and reference for getting out of literal thinking and into the myth-making frame of mind. This was the text for class on storytelling I took recently and it was a good kick in the pants - I've recommended it to friends, too.

The code is not large enough to need maintenance at a fine-grained level.

There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it. The feature is done, and we are into code golf and speculation, neither of which are productive uses of time. In my experience the success rate of speculative refactors like the one author made has perhaps a 50/50 chance, so no better than the initial strategy. It's the requirements themselves and the application of techniques to avoid various classes of errors that give code direction and structure - not the aesthetics at a moment in time(which is what author took issue with).

If you spot multiple approaches on the first try, you can add a comment with a date outlining alternatives so that the conversation may be resumed later when the new requirements come in. But at all times you're always at the mercy of "discipline", and there's no preemptive measure that avoids that.

Where this style applies the most is with hardcoded assets: initializations and runtime behaviors that require an unknown degree of flexibility.

When someone is trained in OOP, the requirement "flexible behavior" triggers a search for answers through polymorphism, but polymorphism is much more structured than a copy-paste-modify code path. It creates limits to scope and requires more explicit names for things. That is the point, of course. You have write more code and do more complex things to get the same level of flexibility, and it'll be harder to debug since the call stack will have to jump around throughout the layers of abstraction. In a "time from idea to production code" latency analysis, OOP structures lose to copy-paste.

And that's why, across the bulk of game codebases I've seen, there tends to be a big jump from hardcoded assets straight into data-driven ECS-style approaches. Small games start with the former, and if they get big enough switch to the latter. The ECS approach still exacts a debugging penalty because more bugs will exist in data, where they're harder to analyze with IDE tooling, but more behaviors are encoded as explicit patterns with limited scope, which is good in a team environment, and it's possible to go data-driven in an incremental rewrite: simply find all the truly redundant stuff, replace it with a parameterized pattern, expose the pattern as data. For the stuff that isn't easily parameterized, consider encoding a small state machine interpreter so that an imperative program definition may occur in data. In the entity system, add some notion of dynamic compositions of state and behavior at initialization. Between those three you can cover just about everything, and you never have to do it 100% to ship: it's there to assist the things that benefit from additional structure, which probably isn't all of the game. (rather, in the AAA environment the data-driven approach can tend to get out of hand - it's a move that allows the designers to avoid needing explicit code support for longer and longer periods of time, with the predictable result of enterprise anti-patterns that abuse scripting in a fashion that is much harder to debug than the hardcoded equivalent.)

This distinction is also basically why you don't see Jon Blow, for example, really get excited about discussing the runtime architecture of his game projects: If the bulk of the game is assets all the way down, there's nothing to talk about, and the only part that concievably could be exciting is some of the core algorithms that drive the interactivity.

It's also why so many gamedevs are apologetic about their code: half of them try to escape this reality by finding a magic mix of abstractions(which eventually blows up and causes rewrites once sufficient complex behavior hits the codebase), the other half run with it and stay in the local optimum of inlined, hardcoded, primitive-heavy functions.

Hello - the IDE focus looks very attractive from an indie-engine developer's perspective(small scale development always gains the most from having unified, consistent tooling). Will this be a customizable environment to e.g. assist working with asset dependencies?

At a glance I don't have any other major remarks. It looks very much like it's on the same general trajectory as Zig, which is probably a good sign that that design space is in the right ballpark for low-level real-time systems. There is some attraction in having automatic memory available for application-level tasks with more indefinite boundaries(editing tools tend to develop compiler-like qualities which in turn creates a need for more introspective style), though it's probably outside the scope of this language and might be suitable for a scripting-layer approach instead.

I basically disagree with this formulation on the grounds that it does not sufficiently respect political opinions as being reflective of self-interest; these opinions are often a result of not just consistent messaging but tangible incentive.

It's much more straightforward to view the public politics and culture as a primarily top-down construction: "let's make these groups more upset at each other; let's make these other groups reconcile". This decision, made for cold reasons of accumulating power for oneself and immediate cronies by herding public opinion, subsequently filters down through the system via funding grants, access to information, and the occasional revolving-door or literal kickback. It gets amplified because job holders and job seekers spot the opportunities and threats awaiting them through a simple agreement or disagreement: they therefore start conducting themselves accordingly in "the way of the times", taking up the causes of the powerful with a bare minimum of overt messaging, hoping that they have backed a winning horse. This scramble happens across a broad range of industries, at many levels of the career ladder, and in seeking friends and relationships. There is a lot at stake in having "right opinions," in fact. The way in which the country seems to "come apart" or "come together" on issues is therefore most reflective of disagreements at the top, and produces a four-year cycle in a political-cultural feedback loop tied to electoral results: the politics become the culture, disseminate through media, and in turn inform the politics of the next cycle.

The wedge that breaks the cycle, on an individual, issue-by-issue level, is good storytelling. Stories have the power to change self-narrative towards a direction independent of the structural narrative, and their fulfillment generally comes with some way of overcoming structural forces.

But as for why there's the specific conflict we're experiencing today, it's pretty simple: it's a local vs global conflict; when you globalize, there are some "powerful losers" at the local level. And so the narrative has been a competition of these interests, proxied through various parties and institutions.

The most important thing I've done for myself recently is to start breaking away from the social streams by doing my own aggregation with Fraidycat. Besides letting me assemble a lot of sources, it dampens the noise because it doesn't let a single feed drown out the rest: that Twitter account that can't stop shitposting every two seconds in between the real insights is thus tamed.

And so there's a distinct "lack of addictive qualities" when I open it, followed by some very rewarding content. It does take a little time to put together but it helps that we have social streams now to sample from, since so many of them ultimately link to a slower-moving source of real content like a personal blog.

I would like to chime in by noting that Rust's mature form is borne of a very specific scenario, which is the web browser, software so complex that the "zero-cost" element is more like "actually possible to optimize" in practice. And a great deal of that complexity is accidential in some form, a result of accreted layers.

And in that respect, it's not really the kind of software anyone needs to aspire to; aspiring to write programs simple enough that Zig will do the job is much more palatable.

Reinterpreted in my own words:

Usercode spinlocking is not legible to the kernel. Therefore anytime you attempt it you are in the situation of fighting the scheduler, and given that even the kernel devs are constantly challenged by the problem of making appropriate scheduling tradeoffs, you will lose.

A really good book has a sense of permanence and speciality to it that outlasts typical online content.

Philosophy and mathematics books, for example, tend to exist outside time because they are dealing with fundamental unanswerables and constructions of assumption, not "extent of our knowledge" empirical observations as with science. If their thinking is robust, they never go out of date.

History books likewise indulge in rich storytelling about what happened and why. The story is assembled with fact, but filtered through the historiographical lens of the author. There are many niches of history that can only be studied in books. History is easily revised, but each telling can uncover a more "complete" truth.

And fiction, of course, captures the world as a non-factual experience and therefore says the things that can't be said(no words for them, little concept or attention given to them). As a storytelling medium, writing is not everyone's preference, but it is the singular most productive form we have, and so a lot of fiction books express forgotten corners and small whispers of thought.

Given that you have a serious temperament I would recommend starting with very old books from ancient times, since those are the ones least likely to be "obsolete" - power laws being what they are.

Raku (formerly Perl 6) basically sits alone as the successor to the slower-and-more-expressive throne. It's a great language to study for the gee-whiz-they-thought-of-everything factor.

But, nobody is paying attention to it. Some of that is because of the Perl 6 baggage, but just as much is probably because this past decade was so heavily entrenched in proliferation of the web-cloud-mobile paradigm that new scripting systems weren't part of the hype cycle. If it didn't get the backing of the FAANGs, it didn't register.

I can imagine a day coming where scripting shines again, though. It might actually be closer than we think. There is always a need for glue code, and glue code benefits from being a kitchen sink of built-in functionality.

IMHO there is a basic error they're making, which is to do all of this in one product. When they have two internal architectures sharing one interface, the overall scope bloats up, which leads to some miserable UX.

With most game projects, the point is to ship them once and then start anew with the next one - long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather exceptional and sit at the top end of the business - they can afford to keep around the staff dedicated engine work for the long run. The majority of users in contrast are equally as likely to welcome clean breaks as they are to despise them; as long as the previous engine has the proverbial lights kept on, there isn't an issue.