pixelbro

> but how can electromagnetic resonances not be considered in the discussion to warrant continual downvotes

Because everyone's been telling you the same thing in a multitude of different ways, but you refuse to get the point. Yes, the operation of the software we write can be affected by the physical realities of the hardware we use to execute them, but any time this causes the software to behave differently than it would in a purely hypothetical computer, this is considered an error and the results invalid. We even have hardware that automatically corrects for when rare events such as freakin' cosmic rays cause the value of a bit to flip (ECC memory).

The domain of software engineering is abstracted from physical reality. There's nothing useful to be gained from such discussions, because the whole job of hardware engineers is to enable us to operate at a higher level where we don't have to concern ourselves with the quantum electrodynamics necessary to make the transistors do their jobs.

What he's implying, and what you're missing here, is that the discussion is about the FFT and MP3 algorithms, and how that signal processing affects the signal.

The physical substrate which executes the algorithm is irrelevant to the discussion. Indeed, even the fact that the signal represents sound waves is irrelevant. We could build a computer that executes the same instructions on the same inputs mechanically, using gears and valves and whatnot, or perform the instructions manually on paper, and the algorithm would result in exactly the same output.

> I would say if you are fortunate enough to be working with something like .NET, you can abuse the shit out of LINQ and not really feel the added complexity.

In my own database mapping code for my game (I use RethinkDB) I made a type called DatabaseLink<T> where T : DatabaseEntry, with a Value property that will retrieve the link target from the database cache. It's almost as fast/convenient as a simple field, and it serializes to a GUID.

I wouldn't say you're overthinking it at all! You make an excellent point, and as a game developer it's something I have to consider. Our mission is to craft joy for our players, but I certainly cannot afford to rule out any potential in terms of designing our games to be more engaging.

On the other hand, I've witnessed many instances of gamers who have fallen victim to habit-forming mechanics that continue sinking hours and dollars into a game daily but also say that they no longer truly enjoy the time they spend in that game. There's many aspects that play into that sort of behavior which games can be designed to exploit, not least of which being the sunk cost fallacy and fear of missing out: a player who has reached the endgame might have run out of interesting content to play through but feel obliged to continuously "defend their title". They're encouraged to keep coming back long after it stops being fun by being constantly presented with what appears to be an existential threat to the supremacy they have labored towards.

At that point I think we can safely say that such a game is no longer a positive impact on that person's life.

My way of attempting to ameliorate these sorts of conflicting interests is to structure our organization as a multi-stakeholder cooperative, in a way that gives players meaningful influence over business, design and development decisions.

Of course! I'm not ascribing any moral weight to it, just pointing out the similarity in tactics. Engagement can be a good thing if you're using it to improve someone's life rather than simply trying to extract as much time and money from them as possible.

Uh, it's interesting that you see the design of your product as a counterexample, because to me it looks exactly like what mobile games have been doing as a mechanism for maximizing engagement.

You want to stop them from playing through too much of the game's content and burning themselves out on it. So you lock them out with a timer, forcing them to come back later. Then you reward them for coming back every day. This encourages them to turn the game into a habit and integrate it into their routine.

Looks to me like you've accidentally stumbled onto one of the very tactics games use to turn people into addicts.

While we're all patting ourselves on the back for understanding probability, the correct calculation is actually log.98(.5) = 34.3 = number of attempts required for a 50% chance of getting a 2% item.