Oops, this could cause runaway heap growth and eat up all available resources leading to a crash. The spawn function should check if Swiftlet already exists, or at least if it is in the area and have a limit on the number of Swiftlets that can exist.
I bet they’ll fix it by having it derez when its distance from the cloud reaches the distance at which it would spawn. That’s a simple fix that makes it harder to trigger a crash (or a buffer overflow to exploit).
IMO it should not spawn at all, but be a unique item. That would be a more involved fix, because then you’d have to protect it against abductions and other denial-of-service shenanigans. And that is why I am certain they won’t do it. They are in beta and want all the boxes checked for release, not double the development costs by starting over to get it right.
That sounds like an awfully complicated way to go about things, considering that Nick has just nailed a net to some clouds.
There’s an easy fix. Make the bird skinable, hunters will camp the area and the chance for heap exhaustion will never happen.
I’m still trying to figure out why the developers thought that an NPC that pops up when you pass specific a point in the world was a good idea in AN ENDLESS FEATURELESS 3D SKY WITH THREE POTENTIAL AXES OF MOVEMENT!
Almost NOBODY who spawns where Nick did without a guide is going to go anywhere NEAR that specific freaking cloud.
Looking back a couple of days, there’s an audio cue to attract users to that cloud.
You’d think they would test for this the first time around.
Developers creating a system are thinking in terms of “how can we make this work?”
A good tester is thinking in terms of “how can we make this break (preferably in an amusing way)?” – as that’s how a good-sized subset of your users will be thinking! Bored, inquisitive people on computers like to pull things apart to see how they work, or break them because they love that “CRASHtinkletinkle” noise they make as they fall apart.
A really *good* developer, or systems architect or whatever, should be thinking defensively from the start – considering at design time not just “how can we make this work” but also “how can we stop those $%^$ers breaking it?”
However, on any project, most of the coders will be of the first kind, or at least in that mindset because their options are constrained by the system design they’ve had handed down to them, and the chain of command restricting how much they can alter or deviate from it. So if the lead designer drops the ball or misses a trick, we get this situation.
I don’t think this comes from being a good developer or not. Creators are more free to concentrate on their work if they know their inevitable mistakes will eventually be found by testers. Of course coders will try to work at their best (not my experience, actually: I had my colleagues letting *me* find and correct the stupidest mistakes, out of simple laziness and “you’re so good at that”).
The point is: you may be a good coder and not want to stop every two lines to think hard about how a kid could break your program. If you’ve done a good analysis and your code is solid, slip-ups can be fixed when they’re found by a much better tester than yourself.
If you made a fundamental, structural mistake, ok: you’re not a good designer, and your mistake will have to be dealt with in some clumsy, inelegant way.
OK, let’s just make the bird *explode* instead of leaving XD
“Bored, inquisitive people on computers like to pull things apart to see how they work, or break them because they love that “CRASHtinkletinkle” noise they make as they fall apart.”
Or, as Classic Paranoia once put it:
Fragile things, dropped from a great height, make a nice sound.
They don’t have to be THAT fragile. Almost anything will break, if you drop it from high enough. At some point, what really matters is the debris radius.
Two colleges, Caltech and U.C. San Diego, have actually measured this with watermelons, from 9 and 7 stories, respectively. But that’s another story.
No. If this were in the released build, you could “You’d think the beta-testers would have caught it.”
But you can’t apply that logic here because Nick literally IS the beta-tester. Every game is this broken before beta-testing, that’s why we have beta-testing!
Maybe the two of them could trade rhymes until they work through their existential crisis…
This leads to porn… how?
Everything leads to porn. What’s it called…Rule Thirty Four, or somesuch?
Rule #34: If it exists, there is porn of it.
Not quite… Rule 34 says that if you can think of it, there is porn of it (including drawings or CG porn). The Quantum Corollary to Rule 34 says that if necessary, such porn will be retroactively created somewhere on the Internet, as soon as you begin searching for it.
I’ve been on a couple of forums where they tried testing the rule, by coming up with implausible combinations and situations. The results were… disturbing, and of course hella NSFW.
Of course, Avenue Q did the seminal educational piece on the topic:
Heh. “Seminal”. (My inner 12-year-old is really immature for his age.)
I probably have already said this somewhere else, but: this forum needs a +1 button.
The fact that they implemented a system capable of spawning NPC-quality AIs dynamically, rather than just having an NPC that gets made invisible and mindwiped when nobody’s around, is interesting.
I’m waiting to see how the razor wire comes into play…
I’m imagining Nick at the head of an army of thousands of rhyming birds, and conquering the rest of the Whimsy VR world. Becoming a virtual tyrant would break the system utterly, fulfilling the contract while gaining POWER, ABSOLUTE POWER!!! BWA-HA-HA!!
Okay, I’ve got to lay off the caffeine at night.
On a good day, you’re like that on decaf.*
*And I live the plan.
I like how they nailed up the net on conveniently placed clouds
©2007-2017 Skin Horse | Powered by WordPress with ComicPress
| Subscribe: RSS
| Back to Top ↑