subwayclub

It was reasonably popular and got picked up by a publisher and perhaps you have played it, but I won't talk about that.

The problem with your original assertion is that you have ignored the virtual world player types as described by Richard Bartle and positioned the Achiever view as the sole one of import, subsequently question begging your way to a narrow conclusion about what quality is.

I will explain further but first I should point out that I am deliberately engaging you on your weaknesses. You have a lengthy track record of preaching your views as unqualified absolutes and then going out of your way to never show vulnerability under fire. You seem borderline incapable of saying "Oh, you got me on that one. I was wrong!" And you are far too visible to get away with that without being called out by someone who knows the topic better than you do and has the credentials to back it up. That is why whenever you show yourself online you are getting more and more hostility. Rather than engage in pedagogy and encourage further questioning you give speedy dismissals to all sorts of subjects. You are necessarily wrong on at least some of them, being human. You admit to none of it. When you become challenged on Twitter you just block them. It looks alternately arrogant and pitiful, and people are increasingly aware with time that this behavior is the "Jon Blow brand". It has already shut you out of opportunities to benefit from, at minimum, the interesting conversation you seem to crave. I know this because I am in the back room on some of it. You would be let in but for this personal stuff. There are other ways to conduct oneself that avoid this particular problem, but it is up to you to rise to the challenge.

Now, to Bartle. Fair play and a high skill ceiling is the secondary goal of the design in popular online games, even e-sports: the first goal is always a balance of accessibility for each of the player types so that nobody is left with nothing to do or turned towards toxicity. That includes features that make dramatic trade offs throughout the design, like auto-aim functionality versus encouraging fine motor skills, global player ranking systems versus buddy systems versus community servers, team damage to encourage tactics versus potential for griefing and yes, fine-grained netcode decisions. The idea of players "deserving" something for their great effort to develop skill, when made central to the premise as in one-on-one fighters with extreme depth and difficult input execution, limits the potential audience to a niche Achiever population. It leaves out players who just want to play with their friends and don't have the best machines or connections, players who are more interested in exploring side systems of the game than the central mechanic, and players who want to elicit strong, surprised reactions(whether through clever tactics or simple trolling) and will do it with an aimbot if you've deprived them of alternatives.

What compensation does is twofold: it lowers the skill ceiling by moving all the considerations around time from the adversary's shooting performance to the target's perception of when they took damage. It also improves accessibility and feedback for all aiming and shooting because it matches player perceptions more closely. Players experience a deeper sense of control with compensation for the same reason that improving frame rates improves the sense of control.

For nearly every game with "twitch" gameplay this is a no-brainer choice: Lag compensation wheels the design back from a Byzantine technical artifact that inflates the skill ceiling and towards a tighter feedback loop that most players, even the less dedicated ones, will intuitively understand and are more likely to appreciate(hence - popular, accessible). Compensated shooting can still be made a skillful process, as games like Counter-Strike have ably demonstrated, without being opaque or tied to ping. And the downside risk is low because a death that feels unearned is rare even in the cases where it comes with a substantial delay. Surely if you were playing well you shouldn't have been in a position to take damage, right? The player can rest easy feeling that their tactics were at fault for putting them in a risky position, not the game.

And there is in fact a specific reason why I brought up your game. It focused on slower-moving projectiles. Thus target leading is already built into the core feedback loop of aiming, and the resulting latency from uncompensated shooting is less relevant to the experience. This would give you the impression based on personal experience that it's not required for accessibility. All your original remark has to do is find the qualifying factors in your experiences and lay them out, and you'd get the quality reply you seek without a fight.

The most popular "how to synthesize" article series is Synth Secrets which ran in Sound on Sound Magazine over a period of years. You can find those online.

Regarding what tool to use, a modular like this(albeit in physical, analog form) is the "original" way to do it. Modular sound can do just about anything provided you have the modules and will to program it. Later on in the commercialization of synthesis manufacturers built smaller semi-modular or fixed-path synthesizers which don't let you patch anything anywhere but are considerably simpler to achieve a result with since their basic architectures expose all the essentials of sound character without being so much of a programming exercise: the Minimoog and Oberheim SEM, to name two, just sound good out of the box and generally sound good no matter how you turn the knobs, and their designs are widely cloned even today.

This era lasted roughly from the early 70s through the early 80s after which synth programming soon became complicated again, this time by digital technology allowing everything to be tweaked and patched and perfectly recalled from memory, provided you were willing to dive through menus. Synth programming turned into a speciality in this era; everyone who just wanted a sound used the built-in presets.

Sometimes a "tool" is as simple as agreeing to enter a certain kind of conversation.

For example, when martial artists practice, they mix the study of technique with its application in a competitive setting. This distributes the learning into a feedback loop amongst the population of students, with good techniques surviving and evolving in their application over time. Gradually the dojo settles into a style based on the direction of its teaching and the kinds of students it recruits, which can then be further tested against the wider world in a tournament.

In comparison, if you just watch a video and try to do the techniques with your buddy at home, you don't enter into that conversation. Nothing is being tested thoroughly so your feedback is limited at best and the training probably won't hold up when brought anywhere else.

For another example, having a creative conversation requires taking a starting point or thread of thought and allowing it to be pursued farther and farther without shooting it down or completely terminating the thread. In this scenario the conversation partner or partners need a mindset that can spot opportunities for coherent elements that weren't necessarily obvious: rather than focusing only on execution, they can adapt concepts and techniques from one scenario to another effectively to generate new ideas. Over time this process eventually suggests some form of execution as a way of proving the idea, but not necessarily a "final" execution. The creation of a large work is an accumulation of this process of having the conversation and gradually adapting elements into the work as they are found relevant.

In that light the tangible "tools" of things like gear, software, etc. play a somewhat instrumental role. Sometimes they are the source of feedback because the workflow can convey success or failure(error messages, misplaced pixels, etc.) At other times they are more like a component of execution and require a whole extra design phase in order to convey feedback: development tools play this role with respect to application software since having the program compile and not crash, or even fulfill some written spec, is insufficient in telling you if it's really doing the right thing. And when highly abstract techniques like mathematics are brought into play the effect is almost magical since the coding tools offer next to zero feedback on whether the resulting algorithm produces correct results: you can create some tests but the basis is all steeped in a theory of operation that renders the physical program structure irrelevant.

I don't think there is a "technical profit" to be had, though.

The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use.

For tech to be useful it has to succeed at creating enough leverage that you would use it over what was there previously, and plenty of technical projects get stuck on that point: they show an immense engineering effort but are solving the wrong problem because they don't optimize the desired workflow, or they expect everything to change around the product's workflow.

In that light, in a universe where most of these designs are bad and misguided and deserve to be put out to pasture, the cost-center mentality makes total sense because it asks the design to prove itself as early as possible. And the outcome of that in turn is the familiar rushed, unmaintainable prototype-in-production scenario.

New technology efforts always have this element of being a judo match: if you can find just the right time and place to strike and take the problem off-balance you can get an instant win, but the same strategy at a different moment doesn't work at all, no matter how hard you flex your coding muscles, and would leave you better off not attempting any new tech.

The balance-sheet model doesn't explain when and where to strike, though. It just says whether or not you're trying to do so this quarter, and any benefit will most likely show up on a different business unit's balance sheet.

Intel has more of the existing partnerships with OEMs, and that isn't going to reverse immediately with a strong showing from AMD. The new Ryzen Mobile notebooks are low-to-midrange entries and groundbreaking in their category, but Intel still covers that higher end segment.

It's easier to see this from Intel's perspective: Intel's biggest threat is from the onrush of GPU-driven computing, and Nvidia is the market leader there. The classic play is to starve them of oxygen by leveraging existing channels to get them out of the gaming notebook market. Thus comes this weird saga with AMD and Raja which is a win win deal in fact: Intel gets ammo to fight Nvidia now and a key hire for their own development later, and AMD gets another source of cashflow and marketshare plus a graceful exit for what has been reported as shaky, conflicted executive management at RTG. Although they've delivered decent hardware and software recently, there have been numerous PR flubs from the group and the business unit performance is questionable overall. There is an open question of what happens to RTG later on, but perhaps the answer is simply to survive in Intel's shadow again.

There's so much history in between that it's easy to cherry pick your favorites:

* New economic and political philosophies(merchantilism, Machiavelli's works, Magna Carta)

* Theological developments(Islam, Protestantism) and the various resulting conflicts as motivators for modernity

* Access to New World flora and fauna(new crops and livestock) increasing the ability of the nascent industrial state to support large populations at a lower cost

* Refinements to math and science that built on or revised ideas from antiquity(e.g. Newtonian physics, cell theory)

* Advanced craftsmanship in certain crucial precursor technologies like lenses, gears, etc. A lot has been made of how the industrial world started operating on a fast-paced timetable, but the Romans had no pocketwatches.

I recall seeing a comparison of DX7 vs dexed patches on Youtube that mostly found audible differences in envelope lengths, not timbre. That seems like something more straightforward to fix, though there's always the potential for a caveat like it being tied to the original hardware sample rate.

Scope variance is actually really common in mobile games as well as RPGs and simulation. All of them share the same kind of design goal of bending time to fit a certain play session or inner/outer game loop length. More "immersive" games ignore the logistical problems of extreme detail and offer tools like time compression, but designing for accessibility bends things the other way, towards providing a spliced-up timeline where events don't have to happen in any particular order apart from one that builds up a sensible narrative.

Hence you have the existence of things like equipment screens that can be popped up mid-battle, pausing everything to let you think about how to divide up loot. And the energy model in mobile F2P, which doesn't make a lick of sense but enforces limited session length and progression. You can take this even further when you think about power up items in pretty much any game.

I don't exactly agree. While the internal hardware does tend to receive less emphasis now, the physical build quality has increasingly been given a scientific treatment, and for good reason: it's the part that matters the most! A phone with an inferior camera, screen, and battery life is a worse phone for most people. So there are lots of reviews that subject these elements to tests with measurable results. That really wasn't the case years and years ago: the fact that the features of a device actually worked was often novelty enough.

Gravity Falls was a big hit with older viewers(grand supernatural mysteries plotline underpinning various family drama). There's also a new Ducktales - I've only caught the premiere of that but it looks like a fitting reboot. Steven Universe has been very good, and before that there was Adventure Time.

Good all-ages shows are definitely there in the mix, although the pressure to cut everything down to formulaic audience pandering has remained a constant.

As a baseline recommendation try this: turn some of the apparently unfactorable pasta code into a large inline function and then start factoring from that point. Usually an opportunity will appear to realign the code in a new way that gets you something you didn't have before. Repeat a few times and you will end up with some original code abstractions that you never would have seen without a careful evolutionary process.

It's the race for core counts that we've been expecting since the mid 2000s - just a lot later than anyone expected since we detoured into GPU and mobile computing.

Our software still isn't really ready for it, but I guess that's to be expected.

FWIW I believe it helps to run ordinary fans in the room in tandem with a filtration unit to combat the airflow issues.

"Forward+" is the typical term for the newer style of forward rendering which includes a special pass for optimizing large numbers of lights(the most appealing part of deferred).

It comes and goes in phases according to the available technology. The first Quake was all muddy brown and gray. Quake 2 and Unreal both introduced color lighting and looked like a disco on Saturday night. Mid-2000s games added a lot of new lighting and post-processing effects but they had limitations causing harsh shadows and highlights, hence another round of gray/brown photorealism came through.

But in this decade things are finally feeling more evened out. Lighting models are sophisticated enough to allow for designs similar to a film set or photo shoot, and post-processing is getting past basic glows and filters and into a spectrum of quality/performance tradeoffs.

Of course, the games that don't aim for photorealism always age better. That's been the case since people started digitizing photographs for games.

The Silicon Valley Suicides - Why are so many kids with bright prospects killing themselves in Palo Alto? (2015)

https://www.theatlantic.com/magazine/archive/2015/12/the-sil...

Contemporary schooling in the US can vary from school-to-prison in poorer neighborhoods, to academic pressure cookers that appeal to demanding parents by promising that their boy or girl will "be successful".

Feedback. Speed and clarity of feedback trumps effort in honing a skill. Note that parent didn't say "no work" but "no homework". Most forms of homework give unclear feedback to the student with few ways to check work before turning it in. I cannot count the number of times in middle and high school that I got a homework assignment with poor directions that was assigned the day before it was due, leaving no opportunity to correct course - just a lot of nervous "I guess this is what they want?" Hours and hours of time wasted on a concept that I might have actually understood how to apply but not how to present in the way they wanted.

Every local newspaper comments thread is basically like this. It's 4chan for old people.

Join three instances and check out their local and federated timelines. They're all different in size and character and your hit/miss rate goes way up by putting in a bit of "pavement pounding".

Twitter has to do everything itself - sales, marketing, customer support. This means that its vision is limited by what the executives can see, and they're going to look at traditional business factors for ideas. The political structure tends toward corporate fiefdoms over time.

Mastodon is leveraging forces from many different directions: first by building towards the existing GNUSocial protocol and its userbase, and then as different communities come in, getting donations of their time and skills to operate instances tailored to their needs. Businesses have angles on this too: for example Japanese art site pixiv made their own instance and client app. The federated model allows some divergence but also the "loose ties" of a common protocol. There is the prospect of embrace-extend-extinguish occurring, but this historically only happens some of the time, and it requires the full pressure of a giant tech firm and all their marketing strength to make it work.

Just the other day I replied to a Reddit thread, and told a gamer who experienced periodic frame drops in CS:GO to check the other system processes. He protested that he had nothing else running, but elsewhere in the thread a Task Manager screenshot revealed that Windows 10 Smartscreen Filter was chewing through files and bottlenecking the HDD(a problem I've also experienced).

Basically, desktop Windows has crossed the threshold of "needs SSD" to perform adequately. And in theory that shouldn't impact the performance of an older game, but it does, because what happens next is that the scheduler misallocates process time and throws off everything.

The essence of it is in good application of macros. Macroassemblers were essential tools for software that wanted all three of complex, high-performance, and fast to build on hardware of that era. Although it's a bit intimidating to write a large program without a higher-level syntax backing it, it's possible to invent coding conventions and reuse strategies that get you to the desired level of flexibility and maintainability, but perhaps without as many built-in checks and a simpler strategy with respect to resource usage(a general-purpose "malloc" is not a thing you would want to do casually in an assembly program since it makes everything considerably harder to track - but simpler fixed-buffer or mark-and-release strategies were fair game).

And if you were a little more ambitious you could also write a custom code generator that added whatever additional features you needed - expansions, type checks, expression evaluators, simple optimizations. Code generation is actually far easier today since the scripting languages now are so much more powerful and feature-rich than what a typical early 90's setup would have(assembly, buggy proprietary C or Pascal compiler, Basic variants).

Of course there's nothing stopping you from taking a similar approach now and custom-generating some source instead of using templates or compile-time evaluation or other fancy features - it's just harder to communicate.

The problem tends to stem from misplaced feedback, not intentional badness. In this case the scenario is set by copy-pasting the dev cycle of previous games onto a new one. The game gets designed from the surface(marketing, and specifically marketing artifacts like the Gex character and a pitch that dictates the design) inwards and so ends up with huge gaps in what it wants to do versus what it actually does, and tons of stuff that gets thrown out as unusable. And then new technology gets in the way.

I am actually finishing up a project that went very similarly, just at a smaller scope.

You've got the strategy I've started using. After years of frustration from cheap laptops that get hot and have poor battery life and can't really be upgraded I recently switched to a computing strategy that seems to have started well for me: Get a nice Chromebook, then use that to access a beefy PC remotely(Chrome Remote is free and pretty simple to set up with just a bit of port forwarding needed, and works fine on coffeeshop wifi).

But the "beefy PC" is actually a business SFF(ThinkCentre 715s) using the AMD A12-9800 APU, the final version of Bulldozer and a starter for the AM4 platform. The only thing superlative about it is the amount of external storage I added - a whole array of cheap USB flash, multiple HDDs, etc.

I actually splurged on that APU and could have gotten the A8-9600 for better value, but I liked the idea of "maxing out" the old architecture.

Now my upgrade cycle will probably be: wait a year and then get whatever is discounted then. By getting the APU now I already see a nice 2-4x improvement over my last laptop, and I defer a decision on getting a discrete GPU. And when I'm out the Chromebook gets me an all-day battery, local access to Android and Ubuntu apps, and 80% of the Windows experience(some network latency, and no remote audio) for productivity.

That doesn't cover the interpolation part of it, though.

    var z = "This is just a literal value";

    var q = 'This automatically runs Std.format, letting me include "$z"';

Clippy

The root of the problem is that we tend to need special case automations to build UI for the same reasons that carpenters and blacksmiths need jigs and molds, but we keep reaching for generic tools to solve them, because software lets you extend things indefinitely and so an "ultimate" generic tool is always just out of reach.

For example, instead of a one-step translation of "invision mockup" to "final site" it would make sense to translate the mockup into an automation conveying that specific design language.

HTML and CSS deceive us by apparently being those generic tools to solve everything. But because they're generic and composable in a high level sense they actually get in the way of the intention - layout, content, and interactions are all shoved into non-overlapping functionality boxes. And then we add JS on top of that, making it possible to break out of the model badly.

It's also the engineer's job to make rent and pay their health insurance despite unreasonable demands. But apparently the only part of this labor issue we want to discuss is the nobility of sacrifice.

DOS PCs were the lead release for Willy. There are two versions as well, the floppy original which supports the soundtrack on MT-32, and a CD "multimedia PC" release which is basically the Sega CD version in 256 colors(no MT-32 sound, just SB/Adlib).

The game has some clockspeed bugs on DOS, though. The animations play at the correct rate, but timers that use the in-game clock will fire too fast above about a 66mHz 486 speed. This left me stuck on a puzzle for a few years, since I first got to play the game in the late 90's and it wasn't obvious that I had a bug.

It reads like "The Jungle".