I recommend reading my previous entries for more context: Thoughts after playing Myst and Thoughts after playing Riven: The Sequel to Myst. I talk about those two games a lot throughout this post.

I’m also just gonna make a note right at the top here that while it’s true that I felt this game was a bit of a step back for the series, I did enjoy it overall, so don’t read too much into the mostly critical tone. It just turns out that, given how much I’ve already talked about the positive qualities of the previous games in the series, I found it more interesting to talk about how it differs from them.

Have you ever been a fan of a band that burst onto the scene with an excellent (if rough around the edges) first album, released a more complex and challenging second album that had less commercial appeal (though would later be regarded as the fan-favourite), then in an attempt to recapture some of their initial success produced a highly-anticipated third album (possibly after losing/changing a member or two) which shows a technical improvement and maturation but ultimately misses the mark? (No? Just me? How about if I compare it to Community season 4?) Well, this arc very closely describes my experience playing through the first three Myst games, and Myst III is that third album: an achievement in technical ability and attempt at “return to form” that, while still enjoyable and possessing its own unique strengths, lacked the underlying drive and spirit of innovation that set the previous titles apart.

If we look at the circumstances of the development of each game, it can shed a lot of light on how each of them ended up the way that they are. Myst was developed primarily by brothers Robyn and Rand Miller; they were breaking ground with a number of new technologies (CD-ROMs were brand-spanking-new, and Quicktime – which they used to put video into the game – wasn’t even available when they first started development). They had assistance from a small team of 4 others at Cyan Inc., but by all accounts the Millers did the vast majority of the work. Riven was a bit less bleeding-edge, but with a budget somewhere between 20-40 times that of Myst, they had the resources to hire a much larger team and really showcase what they were capable of when given room to run with the idea. Additionally, they brought on Richard Vander Wende as a third member of the conceptual team, who Robyn would later attribute for some of the more significant differences seen between Myst and Riven. By the time Myst III went into production Robyn had left Cyan and the company had its sights set on developing an MMO-style spinoff rather than continue the main series, and the task of creating Myst III was given to Presto Studios (developers of The Journeyman Project series).

I don’t want to say anything too negative about the overall effort that Presto Studios put into creating Myst III; they delivered a high-quality game that aesthetically feels right at home in the Myst franchise, and it’s quite apparent from the end result that they had a deep appreciation for the series. But, to me, this entry marks a shift in the motivations and goals behind its continuation. Whereas the first two games feel like the product of the Millers’ passion for creating games and innovating in digital storytelling, the third feels more like the result of a franchise owner (Mattel at the time) wanting to continue making money from the series – with or without the original team. And while I think that Presto made a commendable effort in not only replicating but also improving upon the original formula established in Myst (the 360-degree views were amazing, and the presentation of the story was top-notch), some important elements were lost in translation.

For me, the biggest missing piece was that the puzzles in Myst III didn’t make me feel smart. The moment of understanding how to get past an obstacle typically was happening as I was executing it: trying all the levers/buttons on a contraption to figure out some correct order; locating a partially hidden critical path; finally finding that “one specific spot” that I needed to click on. I was given very few opportunities to gather, synthesize, or transform clues, and the few times that this did happen were greatly undercut by the puzzles being equally solvable through trial and error. The difference between “Ah, that’s how I’m going to solve that” and “Oh, that’s how I solved that” is subtle but very important, because it can be the difference between feeling smart and feeling like I’m following a complex series of “next” buttons. To give an example: the game teaches you about how a few plants behave in an organic-themed age, and then reference that knowledge later as part of puzzle solutions. However, the knowledge is not strictly necessary to solve those puzzles; they are simple enough that a person who didn’t know about the plants could still reasonably expect to solve the puzzles just by trying stuff out – which in some cases was still how I solved them even knowing the clues. The primary payoff is that some interactions that happened one time happened a second time, which is entirely different than the payoff of being able to solve a puzzle based on understanding its component parts.

I also loved the concept for the final puzzle as it required using information that you get at the very beginning of the game and I enjoy that sort of “closing the loop” feeling. But its execution honestly felt very sloppy, since the required information is never really indicated as a clue at any point, and by the time you get to the puzzle you’re given so much seemingly-relevant information that it’s not at all clear that you’re missing anything. This means that it’s highly likely the player won’t be motivated to search for the missing info because the game guided them to do so, but rather because they’re frustrated with not being able to solve a puzzle with missing pieces. On top of this, the puzzle doesn’t really provide a clearly defined success state, nor does it provide any feedback until you’ve solved enough to already be sure of the solution. I ended up asking for a minor hint after about 20 minutes of feeling completely lost, but I could have easily spent hours if I had tried to tough it out. There are ways to make an hours-long puzzle fun; this was not one of them.

I would still recommend Myst III to fans of the series, and to diehard fans of the genre. It’s visually captivating, and the continuation of the story from the previous games is very well-done, keeping in the tradition of morally ambiguous characters and endings. Beyond that, as a stand-alone puzzle game it’s fine – I didn’t hate it, but I wouldn’t put it at the top of your to-play list.

Bonus content: Note pages! (Warning: Fairly significant and unambiguous solution spoilers)

For additional context, first check out my Thoughts after playing Myst – I’ll be referencing Myst a lot.

The difference between Riven and Myst is remarkable. Not only in how much more Riven is in just about every way, but also in how the Cyan team were able to deliver a sequel so far advanced from the original and and still absolutely nail it. If I were to play the games without context, I would have assumed there was at least one or two entries worth of refinement between them. More than just “holding up” like I have said for Myst, Riven is one of the best puzzle games I’ve ever played.

So, what exactly does “more” mean? On a technical level, an easy way to express it is that where Myst came on a single CD-ROM; Riven was 5. It was once-again on the forefront of graphics in computer games. There were more images (with a higher fidelity), more video (now often full-screen rather than relegated to a small box), more dialogue, more locations, more lore, and so on. But beyond that, there was just so much more to the game itself – to learn, experience, and understand.

As a child I played Myst far more than I played Riven simply because – as I’ve mentioned – my puzzle solving ability was largely non-existent at that age. In Riven, particularly near the beginning, there were relatively few mechanical devices to click on and interact with, and the objects that could be interacted with didn’t make it obvious what they did or were useful for. Simply put, I couldn’t really figure out how to do anything. This made it very boring to play as my younger self, but it set the stage for an absolute treat of an experience as I returned to it later in life.

To borrow a phrase from another review I read, Riven is less a puzzle game and more of an archaeological expedition. Most of the gameplay revolves around just exploring and being observant in order to learn about the world and how it works. I would expect most people to say that Riven is much harder than Myst – not necessarily because the puzzles are more complex or more difficult to solve based on the clues, but rather because Riven is a much more self-guided journey. If the player doesn’t pay attention, they might be able to explore all of the islands of Riven, but won’t end up with the tools necessary to complete the game.

Something that Riven does exceedingly well is making the puzzles and clues feel “diegetic” – that is – as if they are genuine and meaningful parts of the world, rather than abstract obstacles. It feels like every single piece of information you’re given has an in-world justification. One illustrative example (minor spoilers ahead) – and one of my favourite design elements of the game – is where the player is able to learn the in-game numeral system by playing a simple mechanical game that can be found in what appears to be a classroom. Rather than present the info directly through a diagram, or maybe something to decode, the game allows the player to interpret a believable in-game artifact based solely on their interactions with it and the context it’s found in. To add on even more clever design work in this very simple event:

  • Once the player figures out the operation of the game, it essentially reveals one random numeral from 1-10 each time the player interacts with it. The symbols that make up the numerals make it possible to determine the full set of 10 numbers after only learning 6 or 7 of them, and the random nature makes it more likely that the player will attempt to work this out, rather than continuing to rely on chance. (For the record, I learned 9 of them before cluing in)
  • Not only is learning these numerals required to complete the game, it’s also necessary to know how to “count” up to 25. These additional numbers are not provided directly by the game, but the ways that the symbols and their combinations exist from 1-10 also provides the player with the clues to reach 25. (This method of providing incomplete information that needs to be synthesized through related clues is re-used several times throughout the game, always to great effect)

Another very smart choice made in this game is to not make it immediately obvious what clues are necessary to solve which puzzles, or even what pieces of information are truly necessary clues. Most things that look like a clue do end up being a clue – or at least meaningful information – so the player isn’t punished for being observant by wasting their time (unless you’re like me and spend an hour trying to decode the D’ni alphabet to find it’s only got 25 letters and is definitely not a straight cipher for English). But I found that when the game was less clear about its immediate intentions with clearly important details, it led to a more inquisitive and curious mindset. I didn’t just care about the discreet details of a clue, I also cared about the context that I found it in, and how it might relate to other pieces of information I’ve gathered and contribute to what I know about the world. I didn’t just feel smart when I pieced things together, it also felt like I was understanding something cohesive and logical.

I will say that the game is not without its flaws; it does fall victim once or twice to the typical “hunt for the single detail on the single screen you haven’t noticed” roadblock that seems to happen in most point-and-click games (in fact, I found an actually hidden button well before I found one particular intended path). Also the steps to obtain one of the endings were somewhat difficult to intuit, and somewhat contradicted by a different ending. But, in a game that otherwise has some of the smartest and most engaging puzzle design I’ve ever come across, I consider those relatively minor points.

I’d recommend Riven to folks who are fans of the series and/or genre (particularly those who enjoy studious note-taking); folks who like to study game design; and honestly anyone who read all of the above and didn’t immediately think “ugh.”

I’m continuing to play the series! Here are my Thoughts after playing Myst III: Exile

Bonus content: As I’ve said previously, I love games that encourage/require taking notes. Here are the notes taken during my playthrough:

Note: I was playing the original Myst; not realMyst or the 2021 remake.

Myst was one of the first two games my family purchased for our brand-new Windows 95 PC back in the early 90s (the other being Sim City 2000), and so my recent playthrough had a very thick layer of nostalgia settled over the entire thing. As a 7-year-old I wasn’t able to solve many of the puzzles, but I was still able to make varying amounts of progress through trial-and-error, random fiddling, and a decent amount of luck. Even still, playing it decades later, I could vividly remember many of the locales, mechanics, and even the broad details of the story.

Nostalgia aside, I felt that the game held up relatively well for its age, though parts of it certainly feel dated. It occupies an interesting space where the designers clearly took a lot of care and attention in their craft, but the medium and technology were still new enough that a lot of modern design conventions didn’t yet exist. For example: as part of one mechanism, something changes from white to red to indicate it being “active” in a context where, as a modern player, my first thought was that it was telling me something was wrong. Since the colour wasn’t the only piece of feedback being provided it wasn’t difficult to ultimately figure out the correct meaning, but it did lead to a bit of wheel-spinning that likely wouldn’t have even been an issue to folks playing the game closer to its release. There are also a few puzzles that rely more on tedium than cleverness to solve, but still I found these interesting from an anthropological perspective more than they were frustrating.

One thing I’ve always appreciated (and continue to appreciate) about the Myst series is that they try to make the puzzles feel like they arise from the logic of the world, rather than appearing solely as an obstacle for the player. The level of success here is variable, but if I accept that the story’s characters have a compulsion to build needlessly complex mechanisms for relatively simple tasks, I can find myself believing in the worlds as real spaces that served a real purpose. And, in return for hand-waving away a bit of contrivance, we’re rewarded with a very integrated-feeling experience, and a very impressive and fantastical visual style.

I’d recommend this game to folks who played but weren’t able to finish the game as a child (I was able to knock it out in a single 4-5 hour sitting); folks with general nostalgia for early-90’s FMV/point-and-click puzzles games; folks with an interest in historical game design; and folks who want to play through the whole series should absolutely start here. I don’t have any particular cautions, as I feel like the game is pretty upfront about what it is.

I’m continuing to play the series! Here are my thoughts after playing Riven: The Sequel to Myst and Myst III: Exile

Bonus content: I love puzzle games that require taking notes. Something about puzzle solutions that can’t be held in my brain all at once plus the act of writing on a physical medium I find very satisfying. Here are the notes I took while playing Myst (excluding the page with the final puzzle’s solution):

Manifold Garden was, in every sense of the word, a treat. In a puzzle game, some of the key things I want to encounter are: outside the box thinking; novel mechanical concepts; interesting atmosphere; clean and intuitive presentation; puzzle solutions that make me feel smart. Manifest Garden delivered on all of these, and more importantly, it did very little to get in its own way. While it’s common to find games that include one or more of those positive qualities, it’s far more rare to find a game that lets you fully enjoy those things – with minimal exception – for its entire runtime.

To give an example: the puzzles in Manifest Garden are – relative to similar games – fairly short and simple. Given the baseline complexity of the game’s world, I consider this to have been an entirely necessary decision. The game’s two fundamental mechanics are that 1) the player can rotate the world’s orientation to change what direction is “down”, and 2) the world’s space is infinite and loops on itself (if you travel far enough in one direction you’ll end up where you started). This is in an incredibly novel and versatile concept, but as a game with physics-based puzzles and a first-person perspective it also has the potential to be incredibly disorienting. Adding too-complex puzzles runs the danger of having the player be frustrated by their non-Euclidean freedom, rather than being able to enjoy it. As someone who enjoys a good tough puzzle I might feel somewhat underwhelmed by its puzzles in isolation, but in the context of the game they felt perfectly suited, and I absolutely felt like a big brain genius after solving them.

To add some more, unstructured praise: The visuals were show-stopping throughout (I’ve always been captivated by fractals), I don’t remember much of the music (but in that good way where it supported the atmosphere seamlessly), and I was constantly delighted by how the game surprised me with new mechanical interactions that arose from very simple objects and concepts.

The few negative things that I encountered in this game are all broadly related to the design challenge of figuring out how to allow the player to understand “where” they are at any given time in a world where ideas like “position” and “orientation” are very flexible. One way this was mitigated was that, in open areas where this is the biggest concern, landmarks and points of interest were easily discernable – even from a distance. So even if the player doesn’t have a great idea about their current position, they can at least figure out their destination. The trade-off is, however, that navigating solely based on landmarks rather than an understanding of the layout of a space can make progress and travel feel somewhat disconnected and abstract. Yes I completed the game without feeling significantly lost at any point (which is, in itself, a huge accomplishment in design), but I often had the nagging feeling that I was leaving an area prematurely after homing in on a visible landmark and finding progress to a new area. The game does teach you early on that if you need to return to an area it will take you back, so you ultimately just have to put aside any internal instincts to “map out” the space and plan routes and instead trust in the game to guide you along.

I would recommend this game pretty broadly to folks who like puzzle games, particularly stuff that is mind-bending and messes with perception. Similar to (but still very different from) Antichamber and the Portal series. I would caution anyone who has trouble with spatial puzzles, dislikes feeling disoriented, and possibly folks who get motion sickness or vertigo (depending on how it manifests in video games).

This has the shape of a song and most of its parts. I still have some stuff I’d like to do: re-record some of the guitar; change up the second verse; figure out some lighter background instrumentation; maybe add a few drum fills, etc. But if I don’t share stuff in progress, it often will never get to the point where I think it’s complete, so here we are!

I started making this as a way to get used to my new MIDI controller:

It’s a neat little unit that fits on my desk and is built to integrate with Ableton. I’d only ever briefly touched Ableton previously but I have never fully married to any particular DAW, so I figured I’d give it a proper go. Working with a MIDI controller at all (opposed to manually transcribing notes) has been a dream, and I can tell that when I start getting into more of the advanced integrations it’ll just keep getting better.

There hasn’t been anything huge since my last post, but quite a few small things. Most of it has focused around improving the herbivore behaviour through things like pathfinding improvements, some tweaks to how actions happen, and various bugfixes. I’ve also added a UI overlay to start showing some simple game stats – soon to be expanded upon – and implemented a few workflow improvements to help keep track of my ideas and progress.

Herbivore Behaviour

Last post I talked about how the herbivores were performing too efficiently, leading both to a lot of “swarming” behaviour as well as degrading performance. I’ve addressed this in two main ways: introduce more complexity to the decision making progress so that it’s less efficient and predictable, and by making pathfinding a bit less expensive.

Some of the adjustments I’ve made:

  • Actions now have a configurable “duration”; e.g. after eating, walking, etc., an entity will wait a number of cycles before doing another action.
  • Entities have an ideal number of children; after they reach that number they become far less likely to create any more.
  • If an entity’s pathfinding “fails” it will now idle for a short period; wandering in random directions, instead of immediately attempting to pathfind again.
    • If pathfinding fails, the entity is also supposed to “blacklist” the object it was walking to so it will pick a new target, but this might not be working.
  • Entities no longer route their path before every single movement; they’ll instead remember a previously routed path and follow it for a number of cycles before re-calculating.

On top of these specific adjustments, I’ve also made a bunch of tweaks to individual parameters for both the grass and herbivores to try to get to a state of equilibrium. I’m aiming for a scenario where both types of entities can survive for a long time while also not killing the frame rate. It’s getting close – the herbivores are much less explosive and the grass a lot more resilient, and the game tends to stay above 60FPS, but over a long enough period it’s inevitable that the herbivores will eat all grass and then die for lack of food.

UI Overlay

This is a pretty minor thing overall, but an important first step. So far I’ve just added some text that tells me some basic info about the game state – this can help me gauge how various factors impact the game’s performance. As well, now that I know how to create and update text on the screen, it gives me an avenue to start displaying properties of individual entities.

Workflow Improvements

To replace the Google doc I was previously tossing ideas into, I’ve started using Jira to track ideas/tasks/bugs/etc., though that’s pretty boring. I’ve also started uploading my work to github (https://github.com/dlouwe/tinyfeelingrobots) to A) keep myself a bit more structured/mindful in how I work on things, and B) maintain a working backup of my changes, and C) allow any errant soul the chance to check the thing out for themselves. I am 95% sure that this has all of the project files necessary to load the thing up in Unity with minimal/no configuration, but I also don’t entirely know what I’m doing!

A side effect of using these tools is I’ve had to somewhat formalize a name for this project: Tiny Feeling Robots. Because I’m not creative and I like iteration. 🙂

What’s next?

We’re inching ever so close to the actual purpose of the dang thing, which is to start allowing the properties of entities to change over time and observing what kind of shenanigans that causes. The only thing that I’m really waiting on for that is being able to view entity properties while the game is running. Technically I can do that using the Unity editor, but that’s not very practical. So, depending on how easy that is to set up, we could potentially see some shenanigans in the next blog post!

Well now, a lot has gone on since my last update. A lot of it has been behind-the-scenes stuff like refactoring and optimizations and more refactoring (which I’ll talk about a bit further below), but I have introduced something new to the artificial ecosystem. For the time being they’re called “herbivores”, and they eat grass!

New friends!

You might also notice the grass looking a bit different; I’ve been doing a bunch of tweaks to existing behaviour as I go, though nothing huge. I’ve mostly just been trying to make something that looks aesthetically pleasing at this point. The biggest change is letting the grass populate up to about 10 squares away; this makes it more possible for grass to return to areas rendered barren by voracious herbivores, as well as makes the overall shapes less homogenous.

Now, a significant issue with the herbivores at the moment – at least in terms of establishing some sort of equilibrium in the ecosystem – is that they are far too efficient. I essentially built them on top of grass with modified parameters – plus the ability to move and consume grass – so they are essentially always trying to either eat and reproduce if possible.

That’s a lot of friends

Reproduction currently is only limited by a percentage chance, which means that if a single herbivore is likely to reproduce at least once in its lifetime, then it’s at least possible that it could reproduce twice, and each additional herbivore increases the likelihood of more being born, leading to overpopulation inevitably consuming all available grass.

The horror

You can see near the end a small pocket of grass was able to re-establish due to the newly increased propagation range, however, it ends up being moot. I have some plans for how to improve this behaviour that mostly revolve around making the herbivores less efficient; such as making them get hungry less often, give them a diminishing likelihood to reproduce multiple times, etc. I would like the reproductive cycle to be more “generational” than “relentless swarm.”

You may also notice in the 3rd image that it’s starting to encounter some slowdown; these herbivores have been a really excellent exercise in pointing out poorly optimized portions of my code. This is also another big issue with how efficient the herbivores are; it was fine for grass to be very efficient because their operations are relatively low-cost. Herbivores, however, need to regularly search for meals as well as pathfind to reach those meals, which can become very expensive to do constantly – particularly when they start getting further away from meals and/or can’t find a valid path. The measures I talked about above should help with this as well, plus I also want to give them the ability to remember their paths for a period of time; currently each herbivore re-checks that the entire path to its next target is valid every time it wants to take a step. That’s good for accuracy, but very bad for performance.

My next main goals are, in order:

  1. Add behaviours and tweak the herbivores until the ecosystem can find some sense of equilibrium without grinding the FPS to a halt. I want to be able to let this run for some time.
  2. Allow the critters’ parameters to drift over time. When a creature reproduces, I want its descendant to have slightly different inclinations.
  3. Build some sort of UI that lets me inspect the individual entities and see what sort of parameters they optimize towards as the “fitter” settings should produce more offspring.

And now I’m going to delve a bit into the more technical stuff that I’ve been up to. I’m putting this at the end in case up until this point has somehow been within your threshold for nerd shit, but no further.

Aside from lots and lots of incremental changes in order to get specific things to work, I’ve made two major changes in how the code is structured and operates.

Firstly, I consolidated all of my non-water entities into their own singular class. This was due to the fact that in Unity if I want a script attached to one game object to interact with the script of a different game object, I need to write the name of Script B into Script A. This isn’t an issue if I just want to allow the Herbivore object to trigger some interaction in the Grass script, but my end goal isn’t to hard-code specific interactions – rather to build the rules behind the interactions and let those operate in a more arbitrary way. So, in the interest of not coding myself into a corner, I moved all entity behaviour into a single script and allowed those to be controlled through parameters. E.g. a creature with 0 “speed” isn’t ambulatory, even though its script has the code required to move in it.

I had actually started on an early version of the Herbivore and sorted out a pathfinding script before deciding to make this change, so it required a lot of backtracking. But I’m feeling much better about my ability to scale this to additional entities; any work I put into building any given entity is also extended to any future or existing entities, which is the sort of efficiency I can get behind.

The other significant change was getting the controlling “brains” to split off when they reached an entity limit. This was something that I hit a roadblock on before condensing all entities into a single class. Each brain needs to know what kind of entities it controls, and the master list of brains also needs to know what kind of entities the brains it lists control, and the thought of creating a new list of brains for each entity was unacceptable. I made a few attempts to make this dynamic and work with multiple entity types, but it just ended up getting tied in knots that I didn’t know how to untangle, and I shelved it for a while. Moving everything into a single entity cleared that up, and let me finish the implementation. This was also necessary, because the behaviour of multiple herbivores under a single brain was quite poor (each herbivore under a brain would have a random chance to move towards its next meal each cycle), so this let me keep using the brain approach, but only allow each brain to control a single herbivore before spawning a new one.

Some technical goals that I have coming up at some point aside from the more functional ones above:

  • Allow for entity configuration to be stored to and read from physical files.
  • Figure out a good way to store entity parameters in a sort of balance; e.g. as one raises, one or more could lower. I’ll delve more into the functional reasons behind this when I get closer to doing it.

Hopefully it won’t be a full damn year before my next update, but, it might!

I had originally planned this out to be a collection of my thoughts on the FFVII Remake in general, but by the time I got done talking about the music, it felt better to split it out into parts. The other parts will likely be more substantive in terms of talking about the game itself, but as this is the topic I’m most critical about, I wanted to place it first. Also, I’m leaving the introduction as-is from before I decided to split it up, so, here we go.

I am hesitant to call this a “review” – partially because it’s difficult for me to view this game with much objectivity, but also because a “review” isn’t exactly what I want to do here. To say I had high expectations for this game would be an understatement; I did my best to go into it with an open mind and to be accepting of change, but in the 20+ years since the original’s release I’ve had more than enough time to build up a strong image of what game I’d want the remake to be. I’ll be upfront and say that it wasn’t that game – at least not entirely – but it was a stunning product nonetheless. And I think that, rather than try to review the game from the perspective of an impartial observer, I would like to talk about my experience and what it meant to me through the lens of an ex-10-year-old kid who used to be so enamored with the original game that he would hunt down magazines with FF7 articles to read and re-read them over and over during the periods of time between when he could visit his one friend with a PS1 and actually play the dang thing.

Now, as I mentioned above, this was not the exact game that I wanted, but I knew that it never would be. The game that I wanted was just the original updated in a way that would perfectly satisfy my personal nostalgia feels. But to actually expect that is, in my mind, a selfish and empty desire, and in the end I’m glad that that’s not what they produced. The game that I did get to play was ambitious, surprising, fun, and – most importantly – absolutely brimming with attention to detail and care.

I am going to be critical of a number of things below because I care so deeply about the series, but regardless of any missteps I may note, I don’t doubt for a second that the folks who made it put their whole heart into crafting something that was not only faithful to the original, but also something new and exciting for returning players. And for that alone, it will always be a very special game to me.

Warning! Spoilers.


Alright, I’ve gotta get this one out of the way first.

Background: The original FFVII OST was one of its most memorable facets – and the one that I think shines the brightest beyond just nostalgia. On top of the typically stellar (and, in my mind, peak) composition quality of Nobuo Uematsu, the decision to generate the music in real-time on the console (opposed to pre-recorded audio) gave the game a highly unique and stylized sound. The synthesized instruments and effects were of a higher quality than its predecessors on the SNES, but with less realism and fidelity than those that would come later, setting its audio completely apart. All this to say: the music was an integral part of the original experience of playing FF7 on the PS1, and was a driving force that accompanied every emotion I felt while playing it, which is why I find it very disappointing that the music was one of the more underwhelming facets of the remake.

The FF7 Remake’s OST is largely re-arrangements of tracks from the original which is, in itself, an idea that I love. (Note: Nobuo Uematso is listed as a composer for the game, but I believe this is only for his role in the original composition as well as the new ending theme – Hollow. It looks like the soundtrack work was done primarily by Masashi Hamauzu and Mitsuto Suzuki). I grew up listening to fan-arrangements of video game music and they were a wonderful way to pay homage to the source material while also exploring and transforming it in new ways, which is an approach that fits right in with the spirit of a remake. And while there were a lot of places that the new soundtrack did hit that mark, I felt like it was trying to do too much, and lost sight of what made the original soundtrack so iconic.

I think the easiest way to illustrate this is with the Remake OST’s track list: https://www.jp.square-enix.com/music/sem/page/FF7R/ost/en/SQEX_10768_75/. Namely, the sprawling one-hundred-and-eighty tracks that it lists (150 if you don’t count the 30 collectible jukebox songs). For comparison, the original OST was 85 tracks for the entire game, and other more recent series entries also have similar lengths (85 for FFXIII and 96 for FFXV). And, remember, the remake only covers a portion of the original game which only puts about two dozen songs “in play” within that portion of the story (before counting songs like the Chocobo and JENOVA themes which make an early entrance).

Obviously a few dozen tracks wouldn’t satisfy a full-length game, and the approach they took to pad things out – a blend of updated/re-arranged/remixed version from the original supplemented by some brand new compositions – again, absolutely makes sense. I can also see how their attempt to closely tailor the soundtrack to each moment of the game could lead to such a gargantuan track list; they clearly wanted to do something extraordinary, and I’d even say they succeeded at that. It’s an incredible feat that I’m sure they didn’t simply decide to undertake on a whim, but while doing so, they didn’t give the original – and I can’t overstate uniquely iconic – source material enough room to breathe.

One thing that was surprisingly rare in the remake OST is vanilla reproductions of the original’s tracks. And by “vanilla” I mean where they primarily updated the instrumentals but left the fundamental structure of the song in place. As an example, the most straightforward version of the main battle theme is the third one that you hear in the game (out of about 5 or 6 in total). Failing to properly establish the source material makes any alterations of it lose meaning for new players who don’t have the proper background. A person dropping into this remake in media res simply doesn’t have the context to feel the impact of any unexpected tonal shifts or key changes. However, if we assume that returning players were the focus, it doesn’t necessarily make things better.

They had the ability to trigger instant emotional recognition for every single returning player simply by hitting some specific motifs and musical beats (as evidenced by me nearly weeping when the intro cutscene/music transitioned into a beautiful homage of the original intro), yet instead they seemed far too eager to add, embellish, and alter fundamental points of the original songs and missed out on a lot of potential. When what felt like a majority of the re-imagined tracks included unexpected tonal shifts or key changes, different time signatures and tempos, or were straight-up EDM remixes, I am left with the impression that at some point they started making changes for the sake of change rather than for specific intent. I don’t actually think that was the case, but it was certainly how it came across a lot of the time as I was playing the game.

To round this out with a more positive note, I want to talk about some things I liked. While I disagree with the direction it was taken – the music is undeniably of very high quality, and does lend the game its own unique feel. I thought that the idea of having extended cinematic mixes of the boss themes to match the cinematic multi-stage boss fights was very very cool. As I’ve already said: I do believe they wanted to give us something extraordinary and put a lot of effort towards that end, and I think that on its own can be appreciated. I also have nothing bad to say about the new compositions that were introduced – other than the crowded nature of the overall score made it difficult to really get to know them. The effort and quality that went into the music absolutely aligns with the high level of detail shown throughout the rest of the game, it simply failed to make the sort of emotional connection that I know it could.

Addendum: I also have to take a moment to gush about Hollow – the new ending theme that was composed by Nobuo Uematsu; it simply blew me away. Based on his comments, it sounds like a main ending theme with a famous vocalist was part of his desires for the first FFVII, so it’s really cool to see him able to now realize that vision. On top of this he absolutely nailed it, and frankly sounds more like an entry from the original OST than most of the re-imagined tracks on the new one.

Up next, I’ll be discussing gameplay, visuals/experience, and story. Likely to be split over at least two more parts. Hopefully soon!

After a small hiatus to deal with life, I’m back at it! There’s a bunch of ground to cover in this post; I’ve made some significant performance optimizations, some behaviour changes to the grass, and have also added water generation!

Alas, I wasn’t thinking to take screenshots while anything was in progress, so be forewarned that this will be more of a text-heavy update, with just a couple images of the latest progress.

More speed!

First let’s talk about the performance improvements. This is probably the most boring bit as it’s almost entirely behind-the-scenes work, so I’ll try to keep it brief… ish.

The existing issue was that, in order to be aware of its surroundings, every piece of grass was checking for other game objects in a small square around it every single time it was updated by the program – roughly every frame. This caused the amount of computation to quickly ramp up as more and more grass was spawned, creating significant slowdown after running for even a minute or two. I tried experimenting with adding a delay to the grass calculations (pause for X frames before updating again), which did help to some degree, but ultimately didn’t solve the issue at scale.

I had a number of thoughts on how to deal with this (and suggestions from some friends I was bouncing ideas off of), but settled on creating a new script (I’ve called it a “brain”) that is in charge of controlling a collection of grass squares. When the program starts I spawn a number of brains with one grass square each, and every update cycle each brain script randomly chooses one of its grass squares to run its own updates, and the others remain idle. Each time a new square of grass is added, it’s placed under the control of an existing brain. This means that as the program runs, the number of grass updates stays consistent, rather than increasing with new grass growth.

This new approach creates some new issues that need solving – primarily that it artificially slows the growth of grass as time goes on – but the performance gains are very much worth it. As I write this post, I’ve had a simulation running for over 20 minutes with virtually no slowdown.

A blue addition to the family

As much fun as it has been tooling around with the grass (though as you’ll read later, I’m definitely still doing that), things won’t really get interesting until there’s more factors within the simulation. My next step here was to add bodies of water to give the grass a more meaningful way to gain energy.

My method for generating the water was to first place a small number of initial “seed” squares of water and then continue to add more water next to existing water semi-randomly. I limited the placement to the main cardinal directions (no diagonals) to keep the bodies of water contiguous. I’ll need to come up with something a bit more sophisticated eventually for things like rivers or streams that have more intentional shapes, but for now this does the job well enough.

When adding the water I ran into technical issue due to some code I had taken from the first game tutorial I built. Essentially, it placed random game objects by first creating a numbered list of all squares on the “board”, then picking from that list at random, placing the object there, and removing that position from the list. This is what I was using for initial grass placement.

It’s is a very clean and efficient method if we are only placing objects randomly from the list, but the water is now being placed in semi-specific positions. Since there was no efficient way to find a position in that list based on its coordinate, any alternate placement method (e.g. water next to water) would cause the list to no longer reflect the “board” state, making collisions possible.

The solution was relatively simple: I needed a placement method that could check whether or not a coordinate was “empty” before placing an object there. Luckily I had already created exactly that for the grass’s growth script, so I only had to make a more abstract version for the world generation to use. This let me scrap the “list” method entirely and streamline object placement overall. As with most things this isn’t without its drawbacks (e.g. since we don’t keep track of free squares, placing an object randomly on a very full screen becomes exceedingly difficult), but we’ll also toss this on the “good enough for now” pile.

Lastly, I visualized water “depth” by changing its colour based on how many water tiles surround it. This is purely cosmetic; if I ever want to do anything functional with water depth I’ll want something a bit more meaningful, but for the time being it’s much nicer looking than just flat blue.

Ta-da! Initial world generation, now with water!

Yes still more about grass

With some performance issues solved and water existing in the world, I was able to start making some significant updates to grass behaviour. The primary change being to how grass gathers energy.

Previously, grass would lose a fixed amount of energy each “update” and then gain back a semi-random amount based on how many grass and non-grass squares were surrounding it. Then if the energy reached a threshold it would try to grow, if it hit zero the grass would die. I manually tweaked these values so that the grass would live in some cases and die in others, but on the whole would generally live. While this successfully created something interesting to look at, it ultimately wasn’t very meaningful. There was enough variability to make it look vaguely organic, but grass that was in a “living” position would essentially never die, which was far from ideal.

Instead, grass now gains energy based on its proximity to water. This has some limits (that I’ll go into below), but is a big step towards the environment determining how the things in it behave. And going back to an old idea about crowding, the amount of energy grass loses is now increased when it is surrounded by more grass.

Another small change I made was to allow grass to grow up to 2 spaces away. This wasn’t in response to any particular challenge or goal, other than to give entities more behavioural options.

The result of the above changes was very satisfying. We see grass clustering around water sources, but not too aggressively. Growth now slows down when grass starts to fill up space, and we no longer see a trend towards large, uniformly dark green clumps. We also see grass start to die around the fringes when it tries to grow into spaces that are too far from water or that create too much competition.

Improved grass growth behavior

Unfortunately, as mentioned above, there’s some limits to the new behaviour. The biggest issue is the strict limit to how far grass can exist from water due to how distance is currently being calculated.

The “standard” way to calculate distance is to scan the game area (or a sufficiently large portion thereof) for every single object that exists on the correct layer, then iterate through each one and do some math to figure out which is closest. This works in a lot of cases when dealing with a limited number of objects, but it my case it scales poorly.

Since grass and water exist on the same layer, the distance calculation becomes less efficient as more grass squares are grown. The current band-aid for this is to limit how far grass will look for water, which limits the potential number of grass squares it will have to check. The downside is that this makes an artificial threshold for where grass can live.

This is an issue that, going forward, will effect anything that needs to make decisions based on what it knows about the world, so I’m going to have to find a better long-term solution. My ideas right now involve giving objects a “memory” for certain things that will update when the target in question changes, rather than every time the object needs to make a decision that involves the target.

What’s next?

Some upcoming priorities are:

  • Create an ambulatory animal entity that uses the grass for food.
  • Update the “brain” script to allow splitting off after it gets to a certain number of controlled objects.
  • Implement aging for living entities.
  • Upload the project to Github. This was a request from a friend to check out the source, and figure it wouldn’t hurt to share it here as well.
  • Create a proper to-do list. I may also make this public.

This time: less of a dissertation, more pictures! I’ve been working on getting the grass to, well, do things. As previously mentioned, I had thought to try to somewhat mimic Conway’s Game of Life, but departed from that relatively quickly. Instead, I came up with some initial assumptions about how grass should behave:

  • It doesn’t move, but it can grow to adjacent spaces.
  • It will grow when it has enough energy, and will die if it runs out of energy.
  • Growth reduces energy.
  • It doesn’t live well in isolation, but it also doesn’t thrive when crowded.
  • All behaviors should include some variance.

Gotta Start Somewhere

Before implementing any behaviors, I had to do some figuring-out how to get the grass to interpret the game state and make copies of itself, which is mostly boring. Instead, here are a few early failed tests:

This one also caused Unity to crash!


The above made me realize that the square boundary I had drawn didn’t have any application yet in how the game understood itself, so I ended up just making the whole background brown and have delegated “game boundaries” to be a future problem to solve.

Also at some point between the above two tests I did manage to create a state of equilibrium; the grass was not yet growing, but it was dying in a relatively random – but ordered – way.

Like, Mold or Something?

The equilibrium test was nice because it was demonstrating some of the assumptions I had made. Since it dislikes crowding, the grass would die if there were too many other adjacent grass tiles. However, this was a bit much. Plants don’t tend to just fully die because there’s other plants around, plus in future tests it just looked very inorganic, so that behavior was greatly reduced.

Next I reached a stage where the grass actually appeared to grow:

This was good! I then thought it would be neat to visualize the “health” of the grass:

This is the first point where I thought “Oh, neat!” My main issues here are that A) grass in isolation was dying far too quickly, and B) the growth was very uniform and uninteresting. Groups of grass close enough together would simply amalgamate into a big blog and grow outward with little variation.

Something Not Entirely Unlike Grass

At this point, the internal workings of the grass had quite a lot of settings to fiddle with. And fiddle I did. For a couple days. Until it reached its current state, which I’m quite happy with:

The biggest differences between this version and the previous are that it is much more likely that grass in isolation would stagnate rather that die, and that a piece of grass would not always choose to grow to an adjacent square when it had enough energy to do so. This led to a great deal more variation in the patterns that grew. It still does trend in the direction of a solid blob, but that’s more of a function of there being nothing to curb its growth; there’s infinite energy for it to grow with, and nothing to eat it.

For fun, I also made a GIF with the same settings but double the size:

One thing you might notice near the end of that one is that the frame rate starts to noticeably drop. If I let it run much longer it absolutely crawls. So, I will definitely need to put in some work optimizing the current processes. Every individual grass square probably doesn’t need to be acting every frame, eh?

What’s next?

I still have a few things I’d like to do with the grass, such require growth to take time, and, as mentioned, I need to try to optimize the speed a bit. After that, though, the next two additions I want to make are some sort of herbivore creature and water. These will introduce something for the grass to consider food, and something to consume the grass.