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).