• Yukkafuzz

While most of my previous posts have been about a specific topic, today I thought I would go more true "blog" style and just detail the happenings in EXO: Perl over the past week. The main task this week was to allow planets to generate a global "sea level" and fill those seas with a liquid: two options to start, water (of course) and lava.

(Top to bottom: looking at an underwater object at night ; an artifact encased in ice [yes, I know ice is not a liquid, but it used the same system]; lava on the surface)

This is a quite limited version of the ideal (or what I often call "moonshot") system for liquids. Obviously, lakes and rivers exist not at sea level. Multiple different liquids can form features on the same planet. It would be awesome if my planets generated in such a way to allow this, but in short, liquids are hard. When the environment is designed ahead of time and cannot be edited, it's not so bad, as you can hand-draw the way the rivers move and no one can attempt to drain your ponds. But in a procedural game like EXO, an algorithm to determine the flow of liquids is needed. And not only do they flow but we also have the idea of conservation of mass (well, volume is the way we actually notice it), at least for small bodies of liquid. In Minecraft, conservation of mass is ignored, and arbitrary sources of liquid can be created, with some limitations I won't detail here. Instead, it focuses on having an easy flow algorithm. For those not familiar, a Minecraft world is a set of cubes ("blocks") in a giant grid. Each block, then, has 6 neighboring blocks. Water is a type of block, so the flow problem is reduced from arbitrary direction to choosing one of 6 options. The algorithm is more or less like this:

  1. If there is no block below you, create water in that block.

  2. Otherwise, create water in each of your empty horizontal neighbors.

  3. Repeat for each water block created.

  4. Stop if you have not moved down after 7 steps.

If such a simple algorithm can be part of the world's most purchased game, ever (at least for PC, maybe for anything?), then why can't I do something similar? Perhaps I can, but the lack of conservation of mass is a little bothersome for the feel of EXO, and two other problems exist. One, Minecraft is flat, an infinite plane with some blocks stacked on top, whereas EXO's planets are spherical. Thus, I can't just lift Minecraft's algorithm, because of difficulty defining "horizontal" and "below". However, those difficulties can be resolved by generating terrain chunks using spherical coordinates ¹ . I have considered for a while using spherical coordinates, and this was the last straw for me to swap from my previous (Cartesian) system (not that spherical doesn't come with its own set of challenges).

Believe it or not, this was the equivalent of a "flat" surface for some locations on a sphere in the Cartesian terrain system. It's one of the other reasons I ended up switching to a spherical coordinate system.

The other difference from Minecraft is my terrain is generated per vertex, not per cube (I discussed this in detail in a previous post). That might not matter, since each vertex still has six neighbors, but it's not totally clear whether the resulting liquid flow will be satisfactory. All of these difficulties can likely be worked through, but as I said, the point is that liquids are hard. So, the liquid system stays simple for now, because I have an upcoming deadline.

"What do you mean, deadline? You are an independent developer!" Yes, and that does not mean deadlines are not still necessary. Like most deadlines, they can be bent if necessary, but in order to eventually release something, I need motivation to take care of some of the less fun tasks. This upcoming deadline is the "moratorium on new features", which is critical to putting out my first version. In a way, it's just a switch in mindset: previously, when creating features, I often referenced or connected to systems that did not exist in game yet. For example, when making the system for trade at space stations the first time, I made the payout for trade depend on the relation the player had with the owner of station, but I didn't have ways for the player to improve or decrease their diplomatic relations. The trade feature worked, and the game ran, but the gameplay experience would be wonky if you were making less money from trade and couldn't do anything about it.

A lot of systems and features are part-finished because of the habit to reference them this way. With the moratorium, all of these unfinished systems need to be tied up and connected to existing features while avoiding creating new loose ends.

With that in mind, the liquids can't just be pretty to look at! Interacting with liquid should affect the player. Lava should damage them, water should slow them down, and the ice I added (which will perhaps be moved away from using the liquid system, for obvious reasons) should be slippery. Ideally, different points of interest should be generated under/in the liquids than elsewhere. All of these made their way into the game over the course of the week. And, of course, the player should be able to jump in them! (With proper equipment, of course.) So, I leave you with the "underwater" and "under lava" pictures.

¹ for those who deal in math, using spherical means "horizontal" is changing either φ or θ , and "below" is just decreasing ρ . In a Cartesian system, yes, I could get "horizontal" with a tangent and bitangent vector to the surface, and "vertical" with the normal vector, but my grid of points is all integers, so moving in one of those directions would not necessarily come very close to a nearby point.

  • Yukkafuzz

I watched a video yesterday titled "What Games Are Like For Someone Who Doesn't Play Games". As a lifetime 'gamer', it can be hard to get in the head of a person playing for the first time, or even just a less experienced player. The video illustrates that what many gamers find intuitive or obvious actually relies on an extensive base of knowledge built up by players from a young age. Even the introductions or tutorials of modern titles prove frustrating for a new gamer. Viewing this critically as a game developer, it shows that a balance must be struck between compelling gameplay and ease of use, or you're choosing to cater only to an audience of already established gamers. Now, that audience is quite large, and it is not wrong to choose to more or less ignore the problem of onboarding a new gamer; however, careful design can help to bridge this gap in experience.

The main tools for the designers are instructions and feedback. Unsurprisingly, it's not enough to write an instruction manual, nor to display the instructions when someone begins the game. But somewhat less obviously, even what can seem to be well-designed instructions, which appear only when a feature has been unlocked or steadily over the course of a tutorial, also frequently fail to serve their purpose properly. The video mentions a couple: accidentally clicking through them, or doing so on purpose because who wants to read a wall (or even short paragraph) of text when you could be, for example, exploring a vast, procedurally generated universe? ^_^ I can think of a few more: not noticing the instructions (yes, popups are unobtrusive, but is that what you want?), not remembering all the details when you need them, or unclear wording, usually from a lack of assumed knowledge.

Just because the instructions can fail does not mean you should not include them, but you also need to adapt to the player. Here the other tool, feedback, comes to the rescue. The most basic form of feedback, of course, is the functionality of the game. When I click on a star, the camera zooms to focus on it. When I hit the 'w' key, the camera moves forward. When I try to hit a grayed-out button, nothing happens. Using only this form of feedback, however, can be frustrating, especially for the "nothing happens" case.

When I click the "Travel" button, nothing happens. I could have guessed, since it's grayed out. But why?

Even when something happens, it's not often I consider the "oops, what key did I just press?" situation. I've had plenty of experiences playing a game where I have to open up the controls configuration or even just press each key on my keyboard to try to undo something I did accidentally. Can I, as a designer, help the player in that situation? Perhaps. For some functions that might not be that common, or would be a significant problem if pressed accidentally, it's probably a good idea to add a little hint. Imagine:

Just minding my own business exploring this solar system.

"Ack! What in the WORLD just happened?" (I entered screenshot mode. But would I know that?)

It would be fairly disastrous to lose the entire UI and have no idea why or how to get it back. The first idea would be have a nice-sized message permanently on the screen that reads, "Screenshot mode. Press F1 to toggle," but you can imagine how much someone actually intending to take a screenshot would appreciate that. Instead, I try to strike a balance with a hint you can permanently disable.

It would be pretty hard to miss this little hint, and it's relatively unobtrusive.

Still, you should be able to disable it for the full screenshot effect. You can hover over it and exit, optionally disabling it forevermore.

While accidental button presses do happen, this screenshot mode case is far less important than a few other types of feedback: the answers to "Why can't I do this (that I normally can do)?" and "Did that do anything?" These questions have probably occurred to you, if you play any games, at some point in distress during gameplay. I showed an example at the top of this post in EXO: "Why can't I travel to this star system, when I've been able to travel to star systems like this in the past?" If the player can't figure out the answer to that question, it's going to lead to frustration. Yes, with the way games often go these days, you would be able to Google the answer (if EXO: Perl was released....), but as a developer I believe the game should not rely on the existence of a wiki.

The thing that most players don't consider is that it can be a headache to actually provide them with this kind of feedback. There are several reasons why you would not be able to travel to a star system: not enough fuel, engine is not powerful enough, you've removed your engine entirely, you're carrying too much cargo. When creating this initially, I just had a few checks with a "CanFly" function, which the rest of the code could use as a yes or no (boolean). It was self-contained. But to give the reason why the ship can't fly, I need to create a new function that breaks it down, reason by reason, meaning I can't be just getting a yes or no answer. Basically, where before I had the small "CanFly" box, now I have two boxes whose contents should be really quite similar but not the same. Not to mention adding some user interface elements to display the message. You can see why that can be a headache, even if it's not particularly difficult.

Hovering over the button provides the player the reason it's grayed out.

To be honest, I am not sure this little hover-over tooltip is enough to make it obvious what's wrong. Will the player hover over the button? If they do, will they notice the tooltip? We like to think "of course", but I've seen it go the other way.

The other piece of feedback I mentioned was "Did that do anything?" People expect an instantaneous response to pretty much anything they do. That's how physics works: you touch something, and you feel something. If you push something, it moves. So when the player does something, whether that's pressing a key, clicking, or using a button on the interface, something needs to happen. Now, this sounds obvious, and in one way it is, but consider EXO's planet extraction. Once landed on a planet, you cannot simply walk into your spaceship - your crew stays in orbit (think Star Trek). The player needs to call for extraction in advance, and they can with the touch of a key. But imagine glancing at your air gauge and realizing there's just a sliver left. You panic and press the extraction key. Nothing happens. You press it again. Nothing happens. You look at your air gauge. It's empty. You look at your health. It's decreasing rapidly. You start to think "What the heck?" You press the extraction key for the third time. Still nothing. A thought crosses your mind, "This game sucks." You look at your health. It's at a quarter. Then suddenly, ZAP! and in a moment you are back to the spaceship view. Of course, in this situation, pressing the extraction key worked perfectly the first time. It started the timer for extraction and you panicked while the timer counted down. But the reason you thought "this game sucks" was because it did not tell you (or show you) that the countdown had begun.

A simple but prominent message can be a very effective feedback mechanism.

Visual feedback is easy to show in a blog post, but auditory feedback is also essential. Satisfying thrumming for, say, a laser activating or another high-tech tool, or a short error noise when you try to activate it with no power is processed by the player almost unconsciously. Without these cues, the player (myself included) is quick to assume the game is not functioning, when in reality almost every piece of feedback you get is an extra feature that the developers intentionally added in to assure you the game is still running smoothly.

I don't resent this, however. The player should not be left wondering whether the game is working as intended. Feedback in its many forms is essential to the experience of a game, even though it's not a glamorous feature to create or to talk about.

  • Yukkafuzz

I have heard of a host of "90-10" rules for many different applications - one you might know is "90% of your worry comes from 10% of your problems" - and if you're not convinced there's a host of them, a couple of quick Google searches should enlighten you. Something must fascinate us with these two numbers, usually percentages, that makes rules that use them feel meaningful. And, as I'm sure many fields do, programming, and perhaps specifically game development, has its own:

"90% completion is only 10% of the work." Basically, it's really easy to create a mostly working program, but to actually turn that into a completely working program takes way more time. This rule can also be applied recursively: so to go from 90% completion to 99% completion is only 10% of the work of going from 90% - 100%. (Doing a bit of math, that means the last 1% of completion is actually 81% of the work, and the last 0.1% is 72.9% of it.)

This rule may explain why games notoriously either get delayed or release on time and suck (for lack of a more respectful way to put it). Estimating the time it will take to create a feature becomes very difficult with this principle, since it goes against our natural understanding of things, which is quite linear. If you're driving and you're 90% of the way there, it's going to take approximately one ninth of the time you've already spent to finish. But in programming something with the 90-10 rule, when you're what feels like 90% of the way there, it will take about nine times the time you've already spent to finish. Comparing the two, that's a factor of 81 difference! So even knowing the rule, to actually accurately put an end time to a project is a challenge.

However, you might notice, or protest, that the time estimates by the 90-10 rule are too extreme. That yes, games get delayed, but they don't get delayed by nine times the amount of time already spent. Well, the key here is games never release 100% complete. And if you've ever played games, you know. Bugs abound, especially in the very first versions, and features, including things as large as new playable heroes, etc. get added afterward. This is not because the programmers and designers did not notice that some bugs still existed or that they wanted more features; it's just that to fix or add these things would take too much time. But even the best games with very few bugs and an engaging set of features still don't seem to adhere to the rule at such an extreme - so how do I explain that?

Well, taking from what I have already mentioned, even the best games cannot be considered 100% complete. So, say one of the best games is actually 99.99% complete. Since the rule applies recursively, the last 0.01% of completion would take ~66% of the total time of the project, and so far 34% of the total time has been invested. Now, take away the percentages for a second. So it takes 34 time units to create an amazing game (that 99.99% completion). It takes 10 time units to create a pretty bad, unfinished game (90% completion), but only 19 to create a pretty good game (99% completion), and about 27 to create a great game (99.9% completion). It's about three and a half times as long to develop an amazing game compared to a bad one. And the next time the new game you've been anticipating gets delayed, you can think they're moving from the great to the amazing mark - about 25% more time required.

For an independent game like EXO, the idea behind why early access release works comes from this rule. I can, (hopefully), release my first early access version somewhere around the "pretty good game" mark, where people would be happy to buy it and play - and then, with that sustenance, I can continue developing to try and reach the "great" or "amazing" marks. It often proves impractical or impossible for indie game studios to go for the "amazing" mark as the first release; the reality is they need the money to be able to sustain development for the amount of time it takes to get there. But hopefully you see that even though games knowingly are released into the world incomplete, they remain honest and worth your investment.

In this way, the 90-10 rule transforms from a terrifying warning about the absurd time sink of development into a reassuring caution sign: your progress may feel like it slows down immensely, but keep working, and your end result will be worth it.

One Knight Studio © 2019