▲ 160 points
back
108 comments
> Your users will do what you make easy
This is why game designers must remove all repetitive, boring, yet effective strategies in order to make good games.
If there's something the player can do to gain advantage, no matter how boring or tedious it is, they will do it and they will ruin their fun and they will assign all blame for it on you, the designer.
I remember playing Pokemon GB games on an emulator and would actively battle with lower level pokemons in the wild or other NPC trainers to level up my own pokemons. Though, I enjoyed it, for some reason.
I understand what you are getting at and I think that applies to the majority of games. That being said, how do you approach games like RuneScape where the grind is part of the appeal?
It's not about removing anything repetitive - it's about trying to find a balance that works best for the player and for you as the developer/producer.
MMOs and games in general have you experience content in roughly 5 different ways: authored (expensive), procedural (complex and generic), emergent (problems explode with size), repeated (the grind), or user generated. Each game, and each system and region inside a game, is a balance between those.
In RuneScape social is the appeal, and you got things to click and numbers go up while you chat with people.
The grind is absolutely not the appeal, but the other cool stuff outweighs it.
I really don't see the connection you're trying to make. There are huge swaths of the gaming industry which are based entirely on repetitive and boring tasks, including some of the most popular games in history, such as Bejeweled and all of its Candy Crush offspring. Or idle, incremental and clicker games. Or slot machines, for that matter. All of those gamers are perfectly happy to spend money on boring repetition -- sometimes for years on end.
All these games are singleplayer games. In multiplayer games the point of the GP post is much more pronounced. If a single strategy beats all others, approximately nobody will play the other strategies and a significant part of your game content may as well not have been written. You need multiple viable strategies (preferably in some sort of rock/paper/scissors loop) to keep the game interesting.
I guess it depends on the definition of "boring". The games you mention cater to different audiences than strategy games, and they make the repetitition a core part of their experience. Special thought went into making their loops feel engaging and rewarding.
So I guess the lesson is more like: Game designers need to remove all effective strategies which short-circuit the core gameplay that your audience expects.
Yes, but that is how the game is designed to be played. The point is if there is a most effective path that is different from the most fun path then the game designer has got room to improve.
And therefore some would say that those games are deficient in something important. Of course they're "successful", but usually through exploitative and disrespectful designs.
Those make it clear what the game is upfront. The upset happens when you believe a game is one thing and it turns into a grind for incidental reasons.
I went through this when playing Spiderman on PS4. It became repetitive but couldn't stop myself from doing the side quests.
Depends on the kind though, Nintendo is said to willingly spread repetition to ease pedagogy so you can play while ignorant. They rotate around patterns gradually removing repetition.
Yes and repetition induces expectation, which, when broken, creates surprise and presumably enjoyment. Kind of like in music.
This post is somewhat ahistorical as far as the objective-c content is concerned.. perhaps Brad Cox had the author’s conception of how one should write ObjC, but what he describes was definitely not how Apple thought about or encouraged folks to program far far before the iPhone gold rush. Objective-C’s clean interop with C is a major selling point, but dropping down to C has long been a technique to be employed only in the targeted areas where it’s important.
(Source: joined the Cocoa team in 2005.)
Yeah there's plenty of criticisms for ObjC, but this post kinda makes no sense to me. No one wrote ObjC like that and to make a coherent argument as to why would require a historical non fiction book. I'm not sure who the target demographic for this post is, and it's Java section makes sense, but the ObjC section doesn't seem focused. It kinda turned into a "OO developers are stupid" post. I'm a game dev (primarily iPhone/ObjC!) - we started that shit and I can't get on board here.
I don't think the Java section makes sense either. I'm no historian, but I don't think it was ease of serialisation that led to huge amounts of config in Java. I suspect that was more to do with its status as an "enterprise" language.
Having encountered a similar proliferation of config in "enterprise" C++ (where it's usually not implemented in terms of serialisation) it was mostly driven by a need to modify the behaviour of systems in production without having to go through software release processes that were often cumbersome and beaurocratic.
My graduation project was to port an Objective-C framework developed on NeXTSTEP into Windows.
Additionally by going through NeXT manuals, or the Brad Cox book, I don't get where the author came to the idea everyone should be doing C.
Heck even the device drivers had a framework.
I find Ruby gives me multiple patterns to solve problems in, each of which feel easy.
Even when it becomes evident doing it another way would have been better, usually it is still readable and consise, and quick to develop.
My biggest disappointment in this profession is that ruby isn't used much more outside of rails. My team use it for everything except low level driver stuff, and it feels like we have this huge unfair advantage over our competitors.
> and it feels like we have this huge unfair advantage over our competitors.
As one man company I feel you on this. May is subjective, but starting from watching people that spend literally weeks to combine some buggy wordpress plugins to build out a functionality that is essentially just CRUD to folks who build multi server, multi service apps for just a few hundred monthly users. Where we just run a few generators, add a few major gems and can start focus on the fun stuff.
Although rails alone is enough to carry ruby. I think there is likely just not enough reason to use ruby over python in most non web use cases.
Is there particular reason to use it over Python even in web use cases? I'd say it's pretty arbitrary, choose what you know, or on the basis of the main library or two you'll need to use.
I would consider this kind of the disadvantage of Ruby. If everything is obvious nothing is.
What languages do you think your competitors are using that are slowing them down?
What kind of advantages?
I always get frustrated when I see Python code written by Java programmers. It's full of unnecessary classes and complicated abstractions, and doesn't make use of Pythonic features that might keep the overall design much more simple. Good programmers know the philosophy of how each language is supposed to be used.
On the other hand, one is often called upon to work with many technologies to accomplish small tasks, making it impractical to become an expert in each one.
I've recently moved to Python from a Java and Kotlin background. Is there any resource in particular you'd recommend for quickly getting over "Javaisms" for people in this situation? I'm keen to write Python as idiomatically as possible but it's often hard to escape your background.
Which in basically every language means “imitate the standard library” or “imitate the framework you’re running.”
Your code is gonna be full of standard library and framework code, your code might as well blend in and be roughly intuitive to people who already know them.
Wait until you see JavaScript written by Java programmers.
It had "Java" in the name.... right??? right!!??
I wonder - is programming language agnostic? Suppose if I learn a particular language - L1, my programming style & thinking is biased by the convenience of the language L1. Now, if I start programming in language L2, obviously for next few months (or years) - I continue to think in L1 & program in L2. It takes time to unlearn L1 & learn L2. Because we are humans. Do we have a bug in our expectations?
As a .NET dev I feel 100% the same in regards to JS and TS. I'm proficient with all three but I have seen so so so many C# devs writing javascript/typescript with classes "bEcaUsE iT haS cLasSes tOO".
I know exactly what you mean, but I hate this on programs in Java and C++ too.
I feel your pain, brother. with the encroachment of frameworks and TS into the frontend, things that could be done with 50 lines of straightforward code become 10 files with a build step.
In a similar vain I feel like frontend got completely taken over by backend programmers. Modern react apps feel so much like enterprise C# or java it's uncanny - complicated tooling, long build times, overengineered libraries. They've made themselves completely at home and managed to all but obscure the actual underlying tech.
> ObjC was intended to be used in a different way though. ObjC OO is C with an OO layer for interop. You're supposed to write 95+% pure C.
Hmm, it seems then that the programmers at NeXTStep and Apple didn't understand ObjC either, because the highlevel macOS/iOS APIs almost never use C structs for grouping simple data items but instead expensive ObjC objects where even the most simple setter/getter operation involves an objc_msgSend call under the hood.
Developers will do things they like more often than things they do not like.
Hubris and laziness is the hallmark of developers, so the easy path is the most often used path, which becomes familiar, which then leads to a choice between familiarity vs FUD. You get a few mavericks, but unless they can prove a productivity change by some metric or miracle, they never make much headway.
> The user will look at the programming language and think that what is the easiest thing to do is the best thing to do
Hard disagree that this is what we should cater to. Programmers should also know the ecosystem they are working in. Just because you learned python with really long chains of method calls, doesn’t mean you should use the same style in Java… though it’s “easy” because that’s what you are used to doing.
If you know a way to attract only good programmers to your ecosystem, great. Most of us have to design systems to handle the way the average programmer will use them. It's easier to build a language that nudges mediocre programmers in the right direction than to make those people spend more time and effort learning the "right thing".
> Just because you learned python with really long chains of method calls,
Long chains of method calls are no more idiomatic in Python than Java to start with (Ruby tends toward fluent style, but Python doesn't.)
I have seen a weird emphasis lately in the dotnet world of trying to mimic the semantics of node or python by sweeping complexity under the rug with syntactic sugar, in the name of making the platform more minimal and welcoming to developers coming from those ecosystems.
I'm not much of a fan, because you still have to deal with how asp.net works once you build anything serious, and now that isn't something the quickstart tutorials expose you to.
excellent take on why programmers prefer one way of doing things over the other. i am adding it to my ever growing list of possible explanations.
another common one is: that's what we have been taught in school.
python has mostly replaced java in schools now but java used to be the introductory language of choice. one can even say that it was like a feedback loop, i.e., the industry dictating what students should learn...
Isn't that a universal law ?
We live in valleys, we go where taxes are low, we cut corners in parks.
Balancing structure and ease is an interesting art.
On a related topic, I found the Badass users book to be very insightful and practical: https://www.amazon.com/Badass-Making-Awesome-Kathy-Sierra/dp...
Seems to be coming at the same idea as https://www.haskellforall.com/2016/04/worst-practices-should... .
I think Apple makes it too easy/fun to force-close apps on iOS by flicking them upwards from the app switching screen.
There is a different way of closing applications on iOS?