#sandgame
Explore tagged Tumblr posts
sandgame · 1 year ago
Text
Faking a spherical Age for the sake of KI coordinates
Heyo Tumblr, been a while!
Although I haven't used this blog lately, I have still been screwing around with this thing in the background of my life, because at this point I've basically accepted that semi-theorizing about how to make Better Uru is just my pastime.
Anyway. As a result of something else I was contemplating for this bizarre project of mine, I realized that because of how KI coordinates work, game worlds which allowed players to wander sufficiently far from the Age's Maintainer's Mark would need to implement some form of fakery in order to properly simulate the effect of walking around on a sphere while using a cylindrical coordinate system.
The "obvious" solution of just making the game world a sphere is… not really smart, though, so what's a game dev who is overcommitted to the concept of realism in this game to do?
Well, first let's finish defining the problem.
As you walk away from the Zero point of an Age, your elevation coordinate will decrease (generally; local surface geometry like mountains notwithstanding) until you reach the Zero’s exact antipode, because walking across the surface of the sphere will always send you "down" relative to the placement of the Maintainer's Mark. It should then increase back to 0 as you proceed back toward the Zero point across the other half of the planet.
But because game worlds are flat, this effect would have to be simulated for sufficiently large maps.
To do this, we have to know the following values:
The average radius of the planet
The distance traveled from the Zero point
The Zero point’s elevation relative to the planet’s average radius
The player’s local elevation relative to the planet’s radius
Using the equation for the length of a circular arc, we can reverse engineer the angular distance traveled:
L = θ * r
Or
θ = L / r
Where L is the length of the arc travelled (how far from the zero point the player is in a straight line), and r is the planet’s radius. 
NOTE: The math in the next part assumes you never travel more than 90 degrees around the planet, which I think is generally acceptable for the purposes of this hypothetical, but just be aware that what's presented here is not a completely comprehensive solution.
Solving for θ lets us construct a right triangle whose hypotenuse is the planet’s radius plus the player’s current elevation above that radius, and whose long leg is the planet’s radius minus the vertical distance the player has travelled away from the Zero point. We find the length of the leg with this function:
a = c × sin(θ)
Once we have a, we subtract it from the planet’s radius to get the elevation KI coordinate.
It may be necessary to make adjustments to certain values going into the equation solving for a in cases where the player has moved more than 90 degrees around the planet from the Zero point. 
The distance coordinate is calculated using the following formula to get the horizontal “opposite” leg of the right triangle formed by the radius of the planet and the angle the player is away from the Zero axis—which extends straight through the center of the planet, or:
b = c × cos(θ)
The value of b is our horizontal distance from the axis of the Zero point. (I should point out that we can't just use the XZ vector distance between the player and the Zero point for this measurement, as the player's travel is being treated as an arc for the purposes of simulating a sphere, and the arc's length would be greater than the actual absolute linear distance traveled if the map were actually spherical.)
The angle coordinate is the simplest to calculate, as it’s simply the player position’s angle from the vector of the Zero point (the “line” of the Zero), converted to torantee. 
In addition to faking the KI coordinates, a shader may also be used to post-process the geometry of the scene such that it falls over a false “horizon”, much like Animal Crossing New Horizons’ island terrain does (though the effect would be far less dramatic in this case). 
3 notes · View notes
necromanticowboy · 2 months ago
Text
Tumblr media
Imma need all the gamers to check out SAND on steam
1 note · View note
artsology · 3 years ago
Photo
Tumblr media
Our “Sand Painting Art Maker” game has 140 colors to choose from, and we just received this digital art work from a student in Texas who had the patience to go through and use all 140 colors! Love it! Go to our site and give it a try (see Art Games, page 1). #sandart #interactive #sandgame #artsed #artteacher #k12artchat #digitalart #artgames #freeonlinegames https://www.instagram.com/p/CbpzAgbLHwY/?utm_medium=tumblr
0 notes
kobiilucas16 · 9 years ago
Photo
Tumblr media
From sand game #sandgame #gamer
1 note · View note
clarinette15 · 9 years ago
Photo
Tumblr media
#fun #sun #brittany #bretagne #morbihan #atlantique #mer #plage #ocean #beach #castle#sandgame#sand
0 notes
alahmnat · 11 years ago
Text
*polishes his own sword in preparation for the battle with Zib over today's scheduled SAND post*
;)
1 note · View note
marso209 · 11 years ago
Photo
Tumblr media Tumblr media Tumblr media Tumblr media
JUST GONNA DUMP A BUNCH OF MY RECENT WORKS HERE AND THE TOP ONE IS JUST ME BEING EVIL
0 notes
vicislifeinbinary · 11 years ago
Photo
Tumblr media
seriously tho wtf am I doing #sandgame #sandapp #magicsand (her: Sundby)
1 note · View note
sandgame · 5 years ago
Text
Some NPC thoughts
Part of the magic of Uru was being able to actually talk to the characters in the game (if you were lucky enough to be around at the right time, of course). Unfortunately, using that as the primary mechanism of keeping players involved in the story just can’t scale to the size of a player base that would also make the game financially viable. That said, it’s a key component that made Uru very different and very special, and I want to find ways of keeping it around, while also recognizing its limitations.
Additionally, I want to give players more of a relationship with the various characters in the game, so that they have a better understanding of them and their roles in the cavern. Because the DRC and company were only ever “live” NPCs, the only way to get to know them at all was by being lucky enough to meet them in person. Otherwise, you were relying on word of mouth (or worse) to even know who they were. I know having deeply personal relationships with them is unrealistic and impractical, but there should at least be guaranteed opportunities for every player to meet them all and interact on some level.
To that end, the various main characters in the game (the DRC, Watson, etc.) should be able to exist as both traditional NPCs and Uru’s “live” NPCs – Actor-Controlled Characters, or ACCs, if you will. As ACCs, they would operate much the same way they did in Uru, occasionally wandering through various areas of the game, conversing with bystanders, and carrying out day-to-day business (the “palace intrigue”, if you will) with other ACCs to nudge along the finer points of the game’s current narrative. (As a side note, there will need to be some way to cover and report on this stuff in game for those who are interested but can’t be online 24/7.)
As ordinary NPCs, these characters would also exist to give and/or receive quests – for lack of a better word. Players may be tasked with bringing Kodama equipment to help shore up a chamber in the Aquarium, for instance, or be dispatched by Dr. Watson to talk with another NPC “explorer” who has information about the bahro. These tasks may be assigned directly by other NPCs, or come in the form of a KI message. Some quests may even only be possible if the player has a certain reputation with the character(s) in question. Anger Kodama, for instance, and you won’t get asked to help him anymore (or maybe you’ll get asked to help him by somebody who also dislikes Kodama and wants to annoy him). Or, if you blow off too many of Watson’s messages asking you to help vet information, he stops asking. Be diligent in completing marker mission tasks, however, and Laxman may take a shine to you and recruit you for more regular Lattice maintenance operations.
The challenge to this approach is marrying the ACC and the NPC so that they feel like a cohesive experience. First, ACCs should have access to the underlying metrics about their relationship with each person they interact with. This helps inform their tone and attitude. Players who have angered a character should expect to have their questions ignored at town halls, for instance. Similarly, ACCs should be able to feed the outcomes of live interactions back into the NPC’s metrics, so that if they substantially alter their standing as the result of an in-person interaction, the computer-driven NPC can take that into account going forward.
Second, characters should only ever exist in one location in the game at any given time. An ACC should never appear in Negilahn at the same time as their NPC counterpart is waiting patiently for you to arrive at a drop-off point in the City. When an actor logs on to control a character, the NPC counterparts should always link away (unless that would cause them to link out while actively speaking with a player, in which case we can let the mask slip a little, so to speak).
On a related note, as NPCs the main characters should generally not be visible in-game unless they are part of a player’s quest. In that case, they will be visible only to that player (and anyone else in their party currently engaged in the quest). Lesser characters that will not have an ACC counterpart can generally exist within the game 24/7, it will simply be the responsibility of the story department to know which characters are currently engaged in an activity so that they’re not used in another one somewhere else at the same time. Generally, NPCs that get used as elements in a personal quest shouldn’t also be used for ambient narrative to avoid conflicts. In the event that a special live event is in progress (like Wheely’s rescue), it should be possible to completely suspend the assignment of new quests relating to the NPCs involved, and active quests should also be suspended for the duration of the event, in order to prevent potentially incongruous interactions (we don’t want Laxman to be giddy with excitement over a new KI function while the cavern is in mourning, for instance).
To help keep players from getting frustrated or confused by receiving instructions to meet an NPC somewhere, only for them to be missing because their ACC is yucking it up in a pub downtown, players should be given temporary insight into a character’s location via the KI when they need to interact with them, along with receiving a ping when the ACC logs out (causing the NPC can return to their post) so that they know the character is available to speak with in the appropriate context. ACCs should stagger their availability so that players are not consistently locked out of progressing a quest because they can only play when the character is in ACC mode (having ACCs operate on 30-hour D’ni days would help with this). Additionally, players should only be able to receive a single assignment to locate a particular character, to prevent them from running into the same person in multiple places. If a quest line would conflict with this, an alternate branch should exist that puts the player off until they finish whatever quest currently has the NPC active. Then, after a delay, another quest can re-activate the NPC in another location.
Lastly, to prevent ACCs from getting flash-mobbed every time they show up, they should be available very regularly (taking into account the aforementioned staggered presence). Ideally every main cast member would appear in the game at least once a week, if not more so. It should also not be possible to add them as buddies, so that players can’t monitor their online status unless they’re actively involved in a quest. Calendars should be produced for the live events department that lay out each character’s availability, and assignments should be made in advance for when ACCs will log in, for how long, and who will be playing them during a given session.
10 notes · View notes
sandgame · 6 years ago
Photo
Tumblr media Tumblr media
The view I always wanted.
I’ve been working on actually building up a 3D model of the Cavern based on the map I made for Unwritten, and I decided to see what things would look like from Bevin. Of course, my Cavern is twice the size if you go off of KI coordinates alone, so what you see here is actually Bevin at roughly 2,000 spans away, rather than 1,000. The vertical offset and angle from the Zero Line are identical, though. Also, don’t read too closely into Ae’gura’s appearance, it’s just a rough-in at the moment.
(The Bevin scene was imported from Uru via Dark Magicks.)
46 notes · View notes
sandgame · 7 years ago
Text
Units of measure
Some of the new (well, new-to-us) Uru concept art in the Obduction-Kickstarter-backer-exclusive Art of Cyan PDF got me thinking about how the D’ni might have measured and proportioned their buildings. It wouldn’t make any sense for D’ni buildings to be laid out in surface-friendly units like feet or meters. For instance, ceiling heights in the US are between 8 and 10 feet, but there’s no reason besides sheer coincidence for a D’ni ceiling to be exactly 8, 9, or 10 feet tall, because they had no idea what a foot even was. That isn’t to say that things like ceiling heights would be wildly different - the D’ni were humanoid, after all, and there’s a certain range of values within which humanoids can live comfortably - just that I’d like to have a native unit to base these measurements on.
Right now, we only have one known unit of D’ni measurement for distances: the span. It’s mentioned in the Book of Ti’ana, and the Great Zero uses it for the distance and elevation measurements in KI-PS coordinates. A span is about 13.3 feet long, which has always struck me as oddly long (and oddly precise) for a fictional basic unit of measurement. Obviously, the D’ni would have needed to have smaller units of measure to work with in day-to-day life, but what are they, and how big are they?
It so happens that if you divide a span into 25 equal pieces, you get a unit of measure that is about 6.4 inches long. I call it the icosipentispan, for lack of a real term. It’s about an inch shorter than the length of the average human male hand (which is 7.4 inches). I can’t see why a hand-length would be any less obvious a unit of measure than a foot (and really, whose foot was ever 12 inches long?). It also turns out that by dividing a span into 25ths, it becomes possible to write distances in decimal (icosipentimal?) notation, making it the D’ni equivalent of an SI unit. (I kind of have an inclination to drive up to Cyan sometime and measure RAWA’s hand now.)
Just like with D’ni time, there’s also a halfway measure that you can arrive at by dividing the span into fifths (the “pentispan”). This yields a unit that’s about 6 inches short of a yard (it’s 2.67 feet / 0.8-ish meters). You can also divide the icosipentispan into fifths to get another halfway unit that’s about 1.28 inches long; otherwise going out to the “hundredths” place in icosipentimal notation takes you down to the 1/4 inch (or 0.65 centimeter) range.
With these smaller units in-hand, it becomes possible to start building humanoid-scale buildings out of native units. Ceilings could perhaps be 3 (7.9 feet) or 4 (10.67 feet) pentispans high, or we could get more granular and work in icosipentispans to hit the sweet spot in-between if desired. Stairs could be 5 icosipentispans (1 pentispan / 6.4 inches) high, and 8 icosipentispans (10.24 inches) deep. (This is a slightly shallower incline than the current 7.5″ x 11.25″ rise/run stairs I’m currently using, but despite using nice round numbers it’s not too far off.)
34 notes · View notes
sandgame · 7 years ago
Photo
Tumblr media Tumblr media Tumblr media Tumblr media Tumblr media Tumblr media
Taking a quick break from building Ae’gura to work on some stuff in Substance Designer. It’s an awesome tool that I really need to use more often, so that I don’t have to re-learn it every time I want to make something.
The first image is my attempt to rebuild this texture from the Great Shaft as a high-resolution, physically based material:
Tumblr media
The second image is actually the exact same material graph, but with different outputs. I exposed the stone and metal color parameters through HSL adjustment nodes so that they can be modified directly inside of Unity. This lets me modify the look of the material on a per-object basis without having to make all-new textures from scratch every time I want to tweak the colors. I can make the red and gold areas of that first image literally any color I want with just a few clicks! The stone textures themselves are created from procedural generators that have color gradients mapped onto their grayscale output; there are no photographs or hand-painted images of stone anywhere in this material graph. In fact, the only input bitmaps I used are the ones in the second row, which (from left to right) are handmade height, ambient occlusion, and material mask maps that I made in Sketch.
The Linking Book on the bottom row is also entirely made from procedural generators, laid out on the UV map using shape masks. The leather and paper both use basic cloud, noise, cell, and scratch generators as a base. Again, color gradients are then mapped onto the grayscale outputs of those generators. The wear on the edges of the leather binding (which is hard to see in this picture) and the yellowing on the pages of the book are accomplished through edge detection-based dirt and blur generators (which are based on a baked curvature map of the object), as well as some shape masks to provide better emphasis for the page yellowing. The page stacks on the sides of the book were created by tiling a gradient and applying a color overlay. I still have some work to do to add definition to the spine of the book cover, but it’s pretty close to finished at this point.
I originally built the Linking Book mesh in 3DS MAX a few years ago, but it’s been further modified and UV mapped in modo 701. I also used modo to bake the ambient occlusion map that’s being used, because Substance Designer’s AO baker was acting kind of weird. It weighs in at a little over 100 polygons, which is slightly more than Cyan’s Linking Book model in Uru. (The linking panel is an empty hole in this screenshot from Substance Designer’s preview window because it uses a separate material that isn’t loaded.)
11 notes · View notes
sandgame · 7 years ago
Photo
Tumblr media
Surprise! I decided to make a rough massing model of the D’ni city (by which I mean the City Proper, not Ae’gura - you can see the latter off in the distance in this shot). There’s a lot of explorable area here (probably a fair bit more than in Uru’s Ae’gura), but it doesn’t feel like it’s too enormous to traverse on foot (and Nexus terminals will eventually help cut travel times even more). It honestly feels pretty incredible to walk around in it, even if it’s just a bunch of gray boxes right now. No joke, I actually got lost at one point, and I’ve spent the last week solid doing pretty much nothing but work on this. Some sign-posts and landmarks are definitely going to be in order. 
Here’s a better view of the whole scene, prior to the addition of the rest of the terrain:
Tumblr media
This is the product of about 2.5 weeks of work in Unity. I used ProBuilder to create all of the buildings, walkways, and staircases, and I used rock assets from the Big Environment Pack to kitbash together a rough approximation of the terrain. I still have a few more holes to fill, and I also have to get occlusion culling set up (because boy howdy is kitbashing inefficient), but it was finished enough last night that I decided to go for a stroll, and wanted to share what it looks like from eye level. The view up top is taken from the western upper harbor area, about 240 feet above the water line, and maybe 200 feet west of the line of the Great Zero (which runs straight through the center of the circular boardwalk area below).
The layout of the city is built on this overhead plan originally created by Mark Engberg (yeah, I know). Surprisingly, with the exception of a couple of staircases being way shorter than they needed to be, the plan translates into 3D with basically no modifications needed. The dimensions/layout of the cavern and the position/size of Ae’gura are inferred from information in the novels, Aitrus’s map of the Descent, this map of Ae’gura (which the Unwritten map of Ae’gura is largely based on), the map of the cavern on the floor of the Great Zero in Uru, other old Cyan concept art of the cavern that’s posted on Chiso, and a heaping helping of "that looks about right”. Depending on how Ae’gura itself comes together, it may change size in the future. Also, I know that Ae’gura itself looks a little... weird, but that’s because I just banged out something extremely rough to get a sense of its distance and scale.
There’s a lot more area on the cavern wall that still needs to be mapped out and designed from scratch. I’m not an architect or a city planner, and the terrain in the cavern is wacky enough that even if I were, this would be a pretty unique challenge. I think what I’m ultimately going to have to do is figure out what the lay of the land is like, and then work from there to design the habitable spaces. Figuring out where to put landmarks that have only been established in writing is also complicated by Cyan’s infuriating insistence on using “the city” to mean both “the city on the cavern wall” and “the island of Ae’gura” (this is not just a Wingrovism; Uru does it too).
As far as fleshing out this particular area more completely, I’m at a bit of a loss. There aren’t really a whole lot of examples of D’ni architecture to work from, especially not the really old stuff that would have been built around this original harbor point. I keep finding myself falling down rabbit holes trying to figure out what sort of evolutionary paths D’ni’s architectural design took, how residential structures might have looked (since we’ve never really seen any), which areas of the city reflect certain eras of construction, and how much those areas were renovated or rebuilt at later dates. There are whole fields of discussion to be had about how D’ni culture, religion, and philosophy influenced their architecture at different periods, in everything from proportions to ornament to layout, location, and orientation (@mcmansionhell​‘s recent History of Architectural Theory series has been particularly “helpful” in driving me to look at the bigger picture, depending on how you want to define “helpful” ;)). How does an intense devotion to Yahvo, or a desire to please the divine, translate into architectural design? What did the D’ni find aesthetically pleasing, and did that change over time as they transitioned from being a bunch of surface-dwelling Ronay refugees to a civilization that knew of no other home but the cavern? What sort of buildings got an exception to the “only religious buildings go on the Great Zero line” rule, and when? These are all things that I think ought to be explored and defined in order to bring a greater sense of place to the city, but I’m also not sure I have the sort of expertise (or the strongheadedness) to start building my own fanon bible of this stuff on my own. So for now, massing models it is, I guess.
(Fun side story about the layout plan: I forget exactly how I came across it originally, but a couple years ago I found the website for the architecture design firm that Mark Engberg works for now, and they have several pieces of concept art that were done for Uru listed on this page. The thing is, because the site is built on WordPress, their image uploads are all stored in predictable locations that by default don’t have index lockouts. I’ve found REALLY MASSIVE versions of about 20 pieces of Uru concept art in the upload directories - including several that aren’t even shown on the website - because apparently they just uploaded the source files and relied on WordPress’s image resizing features to generate web-friendly versions. One of these pieces is a version of the city plan I linked to above that’s almost 7,000 pixels wide, so the elevations are all perfectly legible. I’ll leave it to intrepid web crawlers to find these assets themselves, because I’m not entirely sure whether Cyan or Colab are actually okay with them being public.)
46 notes · View notes
sandgame · 8 years ago
Text
Making Players Vulnerable
One of my big narrative problems with Uru was that it made the players invulnerable, which kills a lot of opportunities for tension. Whether it’s being just a little bit worried about whether that 60-foot drop to the Journey Door in Gahreesen is a good idea or not actively chasing around the bahro linking into the city literally four months after they killed a teenage girl, being vulnerable has the opportunity to keep players on their toes a bit. Besides, it’s not like this invulnerability is a feature of the Myst games – you could still die, you just had to do something that was pretty fundamentally stupid, and those opportunities only largely presented themselves right at the end of the game.
Since Uru and SAND are persistent-world MMOs, it’s not really possible to impose that sort of permanent failure state on the player, but I think there's a way to build a system that requires players to pay more attention to the environment, and which provides the opportunity for heightened narrative tension, even if the negative outcomes are only temporary. Uru's panic-link system will still be in place to prevent players from doing anything that would obviously kill them (like jumping into lava), but what about things that fall short of that criterion? What about smaller (but still serious) falls? What about linking into an arctic blizzard in nothing but your underwear?
To that end, I've designed a system that lets the game impose consequences on players for foolish or reckless behavior. It's sort of an amalgam of the Consequences mechanic from Unwritten (and other FATE RPGs) and pieces of the debuff/condition system in other MMOs like Guild Wars 2. Players have two "impact" bars (for lack of a better term), Conditions and Consequences, which work to indicate how much harm a player has incurred, and provide good visual feedback for their current condition. The system itself is fairly straightforward, but it requires a fair amount of explanation, so follow me after the break for the nitty gritty.
Consequences
I'll start with the Consequences bar, since that basically serves as the player's underlying "health bar". It can be affected by Conditions, but those are not the only way to impact it.
The Consequences bar is divided into three segments. When a player’s character is in perfect condition, the bar is completely empty. If the player does something that will hurt them, that injury is applied to the bar. The greater the harm, the more the bar will fill up. The Consequences bar will also gradually drain, reflecting a character’s recovery from their injuries. So, if a player jumps down a 10-foot drop, they may take some small amount of Consequence impact, but that will gradually bleed off as they continue playing (so long as they don't do anything else that will hurt them). This "draining" process takes longer for each segment, so minor injuries will "heal" fairly quickly, while major impacts will cause even the smaller things to linger much longer.
If the player incurs enough harm to completely fill one of the Consequences bar's segments, it will never drain on its own. For instance, if a player falls off of a 50-foot cliff, they will completely fill the first segment of the Consequences bar, as well as a good portion of the second. Even if they stand stock still forever, they will never "recover" enough to drain the first segment back down to 0. When a segment is full, it will reduce the player's movement speed, and they will be immobilized once all three segments are filled. Any new impacts are also applied on top of any existing Consequence impact, so falling from another 50-foot cliff with the first segment already filled has a greater chance of maxing out the player's Consequences bar entirely.
To empty filled segments of the bar, players need to take corrective action. First-aid kits (which are purchased from merchants in the cavern) can be used to clear the first segment of the bar, as long as the second or third segments are still unfilled. If the second segment is completely filled, a first-aid kit will have no effect. Instead, players must visit a medical tent to get themselves patched up. As long as the third segment remains unfilled, players can choose to defer this action, though their reduced movement speed may quickly make this situation untenable. If the third segment of the bar is filled, players will be automatically incapacitated, and must return to a medical tent immediately for treatment. Linking to a medical tent is a free action built into the new personal linking system (more on that later), but the actual use of the medical tent does cost the player in-game money. Using a medical tent does incur a cost, serving as what I suspect will be a fairly reliable gold sink. If the player does not have any funds in their character's wallet, the medical tent will only clear the second and third Consequences segments.
Conditions
Conditions are situational, environmental effects that, if left unaddressed, will cause harm to your character. If you start to take condition "damage", the Conditions bar will gradually fill up. The rate at which it fills up is determined by the specific type of condition and how long you remain in the inflicting area. Some conditions get increasingly worse over time (stacking intensity), while others just take longer to wear off (stacking duration). If the Conditions bar fills up completely, you will start to take Consequence impact until the Conditions bar has started to drain.
Just like the Consequences bar, the Conditions bar has a built-in drain rate that will cause it to empty at a specific speed. This drain rate applies even while conditions are being applied. As a result, some conditions may be minor enough that you can power through them without taking Consequence impact for a long time. In other cases, conditions will quickly overwhelm the bar's drain rate, causing it to fill up and begin applying Consequence impact.
Stacking
Conditions are applied over time (they're "DoT"s, in MMO parlance), rather than in a single application (like falling damage). Different conditions can apply in different ways, and this has an effect on how quickly the condition starts applying to the Consequences bar, as well as how long it takes for the condition to stop applying.
Conditions that stack in duration will continually add the newly-applied duration of the condition to the total length of the applied condition so far. For example, an Age may apply a 3-second block of Cold with each "tick" (roughly every second). After three seconds, the total remaining duration of the applied Cold condition is 6 seconds (3 seconds applied at tick 1, 3 seconds applied at tick 2, 3 seconds applied at tick 3, but 3 seconds have also elapsed).
In the table below, the horizontal axis indicates a condition's elapsed time, while the vertical axis indicates the time at which it was applied. You can see that at tick 2, a second stack of Cold is applied, but it "stacks" onto the end of the first application from tick 1. This means that damage is applied consistently throughout the duration of the condition, but it can take exponentially greater amounts of time for it to wear off.
Tumblr media
Conditions that stack in intensity will apply condition damage from all applied stacks simultaneously. For example, standing in a fire may apply a 5-second Fire condition that fills the Conditions bar at a rate of 1% per second with each tick.  After 3 seconds, there are now 3 stacks of Fire which are cumulatively filling the Conditions bar at a rate of 3% per second. Assuming the player exits the fire at 3 seconds, they will incur 2 additional seconds of 3% condition damage, then 1 additional second of 2% condition damage, and finally 1 more second of 1% condition damage.
The table below is laid out just like the one for the Cold condition, but here you can see that instead of being added onto the end of the most recent stack, each new stack is applied on top of the existing ones. This has a multiplicative effect on the amount of damage taken with each new stack, but it quickly wears off once the stacks expire.
Tumblr media
While rare, more than one condition can be applied at a time. In these cases, the damage applied to the Condition bar is the sum of the damage generated by all currently-applied conditions.
Mitigating Conditions
By wearing the right gear for the environment you're in, you can easily mitigate most conditions entirely. For example, wearing a parka in an arctic environment will reduce or even eliminate the duration of applied Cold conditions. Wearing a gas mask will allow you to walk across the magma chamber in the Descent without incurring any Noxious Gas conditions (though you may still incur Fire conditions due to the heat, unless you also wear a fire suit).
Condition mitigation is relayed to players through real-world analogues. Rather than requiring players to understand complex abstract statistics tables, clothing is rated for specific situations using real-world measurements. For example, that parka may be rated to eliminate Cold in temperatures as low as -10º. As long as the temperature (which is visible on the KI) remains above -10º, Cold conditions are mitigated entirely. Behind the scenes, there are calculations done to determine the percentage of mitigation that occurs once the temperature does drop below -10º, but players only really need to understand that the colder it gets, the less effective the parka is.
In cases where different items of clothing have different "safety" ratings (like a gas mask with no Fire mitigation worn with a heat suit with Fire mitigation up to 500 degrees), the most effective piece of clothing is always used to perform condition calculations. This prevents players from having to manage a complex inventory of equipment and calculate what the final effectiveness of wearing a parka and shorts is, versus wearing a parka and snow pants.
Consequences Impact
As noted above, conditions will begin to affect the Consequences bar once the Conditions bar is completely filled. This serves as a sort of buffer, enabling players to notice that they're experiencing an issue and work to address it before they start taking direct harm. Different conditions will fill the Condition bar at different rates, depending on their intensity (Fire fills the bar much faster than Cold, for instance). It also has a persistent effect, though, continuing to apply Consequence impact even after the player has left the dangerous area. It is therefore in the player's best interests to get out of dangerous situations before the conditions are severe enough to start impacting the Consequences bar.
Once the Conditions bar is full, a specific formula for each condition determines how strongly they impact the Consequences bar. To return to our previous example, Fire will apply Consequence impact much faster than Cold, and that impact will increase with each active stack. All stacks of a condition will always apply at the same rate, so the severity of a condition is determined solely by the number of applied stacks and the type of stacking it performs. There is no "worse" version of Fire that gets applied by stepping in lava, it just applies more stacks at once. Similarly, there is no “worse” version of Cold, it just applies more frequently and for longer durations the colder it gets.
Consequence impact will stop as soon as the Conditions bar drops below 100%. This can occur because all conditions have expired, or because the Conditions bar is draining faster than any remaining conditions can keep it filled.
17 notes · View notes
sandgame · 8 years ago
Text
What Kind of Game Is This, Then?
Last time, I talked about the absurdly broad nature of the term "adventure game", and how it makes deciding what's "acceptable" in a Myst MMO rather difficult. Today, I'm sort of wiping the slate clean and trying to approach this process from a new angle.
Rand has talked in the past about how Cyan doesn't build stories around game mechanics, they develop a story and then build the necessary game mechanics to support it. In Uru's case, I think they were simply trying to make the wrong game for the story they wanted to tell – or at least, for the story they originally seemed like they were planning to tell. In the end, Uru hewed too closely to the kinds of games that Cyan had always done in the past, despite the fact that the story of rebuilding D'ni and growing a community in the cavern called for a different set of mechanics to support it. The final product's limited mechanics (along with a boatload of eleventh-hour meddling by UbiSoft) hampered Cyan's ability to tell the story the way they'd been hinting at it since the days when Uru was still just called MUDPIE. I don't want to call it a failure of imagination on Cyan's part – after all, when development first kicked into high gear in 1999, the very idea of a mass-market MMO was still fairly groundbreaking stuff. Ultima Online was still king of that space, and the granddaddy of the genre's modern format, World of Warcraft, wouldn't be released for another 5 years. That said, Cyan definitely has a wheelhouse that they're most comfortable working in, and Obduction has proven that they're still incredibly talented at innovating inside of the "single-player puzzle-adventure exploration" sub-genre. But that sub-genre is not suitable for every game set in the Myst universe. To tell the story of the Pento War through a puzzle-adventure game would be to fundamentally misunderstand the way that game mechanics can be used to further engagement in a tale of clashing empires. An RTS or turn-based strategy game would be vastly more suited to telling that sort of story.
So, if SAND's goal is to tell the story of D'ni's restoration the way it was originally intended (or at least, how I and others in the MUDPIE era interpreted that intent), I think it behooves me to put together a set of mechanics that specifically support that goal, rather than trying to cling as closely to the puzzle-adventure exploration sub-genre like Uru did. In essence, I'm not trying to build a Myst game that you can play online with friends. I'm trying to build an online game that tells a story set in the Myst universe, and those two things are allowed to be very different. In fact, like I said last time, the MMO format almost makes that a necessity.
What kind of game is SAND, then?
Well, despite everything I've just said, I don't think it should completely cast aside its puzzle-solving roots. There should still be some aspects of the original series included, because we are, after all, traveling to the very OHSA-hating heart of the most puzzle-obsessed race in the multiverse. In addition, though, some parts of the game are drawn from more traditional RPG-style MMOs, while others are pulled from building and social simulators like Minecraft and Second Life. I recently described it to someone as "an Unwritten campaign that a million people can play at the same time", and for now that's the best way I can think to summarize it. Ultimately, I don't think you could pin this down into a specific video game genre, but somehow I'm sure it could still be classified as an "adventure game".
Buckle up, things are going to get crazy from here out.
7 notes · View notes
sandgame · 8 years ago
Text
What IS an “adventure game”?
I know the devblog here has been quiet for a long time, but that’s not to say I’ve been ignoring the project - just that I’ve been wrestling with what the game actually is and how to document the process of figuring it out without launching into hundred-thousand-word epics.
A lot of my thinking of late has centered around what makes something an adventure game, as opposed to a survival game or a shooter or an RPG. I mean, boil any game down far enough and they’re basically all adventures, with the possible exception of simulators, Civilization, and Tetris. Even at a high level, though, the term “adventure game” applies to such a wide variety of games that the label is essentially meaningless. Any category of games that includes Myst, Tomb Raider, Portal, Monkey Island, Minecraft, and Zork is a category that is bloated beyond any conceivable utility. Further, the delineation between what is and what isn’t an adventure game is often incredibly arbitrary. Tomb Raider and Uncharted are adventure games (“action adventures”, specifically), while Half-Life 2 and Halo are shooters. Both sets of games have a strong focus on storytelling, a fairly on-rails narrative structure, plenty of combat, and some basic puzzles and platforming. Why are the former two adventure games while the latter aren’t?
I’m trying to get to the core of what an adventure game is, because the longer I work on this project, the more I’ve come to realize that the simple set of gameplay mechanics and narrative structures that exemplify Myst-like adventure games (“puzzle adventures”) simply aren’t enough to build an MMO out of. 
MMOs only survive if enough players keep coming back on a regular basis over a long period of time. There is simply no way to produce enough story-driven content to sustain that level of engagement on its own. Players will always finish it faster than it can be created. This necessitates more replayable types of content, which themselves require the development of more mechanics and systems to support them. A good mini-game implementation requires leaderboards and more advanced controls. A good player housing implementation requires an object placement interface for decorating, and a process for obtaining those decorations. Obtaining decorations and clothing implies some sort of crafting system, as well as an economy for trading materials or finished items between players. It also requires the development of an inventory system for storing all of those things. Adding an inventory opens up the potential for more kinds of stories that trigger off of objects that can be picked up and carried around. Good social features require more robust group creation and curation tools. Providing deeper interactivity with the game’s environments requires making decisions on how to handle things like player vulnerability when falling from high places or encountering other types of environmental hazards (heat, bitter cold, toxic air, etc.). Incentivizing players to replay content – especially in group settings – requires creating some kind of reward structure. Interactive NPCs that can scale beyond talking to a handful of people in real time requires a robust computer-driven conversation system.
I think there are compelling cases to be made for implementing all of these things, but how much is too much? Is any of this even interesting to people who like Myst and/or Uru? Does any of it automatically disqualify this as an adventure game? Am I really just inventing a glorified Myst RPG? If people like it anyway, does that even matter?
4 notes · View notes