I believe that exact framing of Uncharted is the origin of the term “ludonarrative dissonance”, where the character’s motivations and morals are in contrast to the extreme violence they are committing because of the nature of it being a video game.
Definitely one of those things I didn’t question when I was younger, but as I get older it’s hard not to see it.
EDIT: I was wrong, the term originated from an analysis of Bioshock, but Uncharted was later held up as a strong example of this. And it’s more generally about the contrast between narrative and gameplay mechanics.
I know that it was originally coined for BS1, but I think its application to BS:I is an interesting case. That was a game about American violence, and featured gratuitous amounts of violence... though it only works from that birds-eye view, right? In terms of the ground-level story, it feels distinctly weird - maybe even grody - to be mowing down hundreds of people, literally tearing their faces open with a mechanical device, in the process of trying to save the Disney Princess deuteragonist (who actually calls you out on your actions early in the game).
Except... the game is ALSO about how time, and the shifting (lost) priorities and understandings of an ideology, are often at the source of violence disconnected from reason. The game is full of people doing things divorced from the original rationale, a veil of manufactured righteousness thrown over it all (patriotism, revolution, a debt that must be repaid), and taking their behavior to an extreme because they don't really understand the true core of why they're doing what they're doing. Kind of like... playing a game that attempts to say something meaningful and sophisticated about society, but that's built on the bones of a gameplay loop that originated with full-throttle demon-slaying action. (Well, actually, Nazi-slaying. Hmm...)
...I don't know how clear I'm being, but the gist of it is that I think Infinite knew what it was doing a lot more than people give it credit for. It's kind of a jumble on purpose.
I thought about this playing Just Cause 2. So I go to this island, blow up all of their oil, gas, and power infrastructure, killing hordes of security guards who are just locals working the few jobs available to them.
Yeah I was in a bar one night and was peckish, so tried to buy a packet of crisps. They said minimum spend on card was £5, so I said just charge me the £5 it's fine.
Card got blocked as they thought it was fraud. Annoying! And not something inebriated me wanted to deal with at 2am.
Ok. Maybe they protected me from myself, but still!
This is why at my current place we are not supposed to do any dev without an SME on the call. We do the development and share the screen and get immediate feedback as we are working in real time! It's great.
Man, pre big-internet was so hard to find information on games. I remember for the original tomb raider a friend needed a guide, so I wrote and printed out them a guide for the full game, since I played it pretty obsessively.
I love the clojure, but I think a big downside is not being able to use it at work and now work feels like I'm being forced to work with stone age tools in comparison. That gets quite depressing sometimes.
Sometimes I think I was happier before I learned Clojure.
I love the clojure, but I think a big downside is not being able to use it at work and now work feels like I'm being forced to work with stone age tools in comparison.
Sometimes I think I was happier before I learned Clojure.
I never understood this sentiment. Even if nobody on my team uses Emacs or Vim, or Clojure, Rust, Zig or Nix, or some browser extensions, or any other tool, nobody could ever directly deny me access or restrict the use of any of that on my machine, some vm-box or EC2. And once I prove their usability to me personally, I show that to my colleagues and typically people when impressed they start using them. Once you have more than three people, you can start discussing rolling it out for general use. Just this past year alone, I have convinced my teammates to use a bunch of tools they'd never heard of before.
It's more depressing if you work in a big organization where decisions come down from on-high instead of letting teams decide what's best. (Especially if one of those decisions is so-called Agile practices which were about empowering teams against on-high global decisions from management, but that's a digression.)
But yes, treat it as a job, and make time for "fun time" after work at home using your favorite tools and languages and OSes, and you can still be happy, especially because the bills are being paid. And even in restrictive corporations there still may be opportunities to introduce a little of your favorite thing... Clojure itself "snuck in" at a lot of places because it was just another jar, and it's not too hard to shim in a bit of Java code that then turns things over to the Clojure system. You can also try getting away with internal-only tooling.
If I had stayed at my last job a little longer I would have tried putting more effort into sneaking Common Lisp in. I had a few slackbot tools I wrote in Lisp running on my machine that I turned over (with pre-built binaries) to someone else when I left (but I doubt they're running still). The main application was Java, and there was already mandates from security people and others not to use other JVM languages.. at least in application code. I was thinking (and got a prototype working) of sneaking in Lisp via ABCL, but only for selenium web driver tests. It was a neat trick to show some coworkers a difference in workflow: write or edit a web driver test, one of your asserts fails or an action click on some ID that's not there fails, in Java you get an exception and it's over, you'll have to restart the whole thing, which for us was expensive because these test suites typically spun up huge sets of state before starting. But with Lisp, exceptions don't automatically go back up the stack, but pause at the spot they occurred: from there you can do anything in the debugging REPL that you can do normally, redefine functions, classes, whatever, and then resume the computation from where it left off (or at some higher part of the call tree stack if you prefer), thus no expensive restart.
There's also ways to introduce things you like that aren't just different languages. My team started doing "lunch and learns" at most once a week (sometimes less often); if anyone wanted to talk about whatever for 30-60+ mins during a lunch period we'd get together and do it. Sometimes that would be about specific work things being built, sometimes it would be about external stuff, ideas (e.g. the Mikado Method) or tools. Once I did a brief presentation about property testing and later on got the quicktheories library for Java into the codebase and handling some tests, and ended up not being the only one to occasionally make use of it.
An example of me solving an Advent of Code with clojure and repl. You can see i never interact with the repl directly, I just send code to it via my editor and get results inline.
reply