forked from ohayo-jacob/takunomi-blog
22 lines
3.9 KiB
HTML
22 lines
3.9 KiB
HTML
<img src="/images/2017-02-27/a.jpg"></br></img>
|
|
<time datetime="2017-02-27">2017-02-27</time>
|
|
<p><em>Link's Awakening</em> only has few good puzzles. The third boss (Splitting the eyeball), the 7th dungeon's premise (Navigating the tower with a ball) and the moving floor things in the 8th dungeon.</p>
|
|
<p>They aren't hard though. They are opaque. I was stuck for several months as a child due to the first in that list. Not being a native English speaker didn't help me either back then.</p>
|
|
<p>Yet this made me wonder, what was the better solution? Nintendo's answer has since then been to outright tell us when a puzzle is a puzzle, and since they're never really complex, telling us about a puzzle is equivalent to telling us the solution.</p>
|
|
<p>The sentiment mentioned by developers like Phil Fish and Jonathan blow in _Indie Game Life After_speaks about how some western developers today, would probably rather see the puzzles slowly transition into much more fiendish puzzles (without outright explaining everything along the way). Kind of like how the puzzles in The Witness probably transition<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup> from easy to devious.</p>
|
|
<p>What I'm suggesting is probably gonna sound like fanboy Stockholm Syndrome, but what if the best solution, for these games at least, was the way Nintendo has done so far?</p>
|
|
<p>Zelda games are part action games, part puzzle games. They're light on plot and lore, but big on world building through quirkily animated characters, great music and interesting locations. Things move at a brisk pace. Enemies have little health, Link can often roll (or backflip) to move faster and eventually, the player acquires some means of fast-travel (Bird, tornado).</p>
|
|
<p>The puzzles <strong>don't</strong> slow things down. In fact, since they hardly even act as cerebral stopping points, they can hardly be called puzzles, that's just convention <sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup>.</p>
|
|
<p>Instead, the puzzles are slight mechanical interruptions, alterations or additions. Shooting the obvious eye above a door with a slingshot is no more difficult than wailing on a Lizard dude but it changes up the flow and sometimes feels good.</p>
|
|
<p>A good lesson to learn from this, is that the tools of Zelda are manifestations of different mechanics, and they <em>puzzleize</em> straight-up <em>hack-'n-slash</em> gameplay. As noted earlier, this is of course a way of thought that has frustrated many players and developers for all sorts of reasons, but damnit, I like it, and I believe there can be a huge difference in my game design if I make use of this way of thought deliberately, instead of simply making my game accessible.</p>
|
|
<p><em>Sodagirl</em> already contains elements of this way of thinking, but having specifically detailed how it works, gives me a better tool for iterating and changing. <em>Puzzleizing</em> barebones combat changes up the basic gameplay, but doesn't break the flow and speed, and sometimes even allow the player to branch out, performing the occasionally repetitive tasks of video games, in personal ways.</p>
|
|
<hr class="footnotes-sep">
|
|
<section class="footnotes">
|
|
<ol class="footnotes-list">
|
|
<li id="fn1" class="footnote-item"><p>I'm gonna be honest: I Haven't played it yet, but it seems like a good guess though. <a href="#fnref1" class="footnote-backref">↩</a></p>
|
|
</li>
|
|
<li id="fn2" class="footnote-item"><p>The opposite direction, making the combat all about puzzles, definitely make for slower, but not worse gameplay, see the unpolished but brilliant indie game <em>Auro</em> (<a href="https://itunes.apple.com/us/app/auro-a-monster-bumping-adventure/id912559144?mt=8">iOS</a>/<a href="https://play.google.com/store/apps/details?id=air.DinofarmAuro&hl=da">Android</a> and <a href="http://store.steampowered.com/app/459680/?l=danish">Steam</a>) <a href="#fnref2" class="footnote-backref">↩</a></p>
|
|
</li>
|
|
</ol>
|
|
</section>
|