Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
nielsm
Jun 1, 2009




In this example it seems "obvious" to me that you could compare the ejection vector to the difference between the motion vectors of the two objects, the ejection should generally be opposite that? Is that a rule being used, or even useful at all?

E: terrible snipe

Adbot
ADBOT LOVES YOU

Flannelette
Jan 17, 2010


While they don't seem to reveal the exact methods it seems a main trick for high speed physics is to try and predict and solve the impacts mathematically before the frame when they would happen so objects can't get inside each other as their locations are solved ahead of time.

And older style collision
https://www.youtube.com/watch?v=UnU7DJXiMAQ

Flannelette fucked around with this message at 11:46 on Apr 19, 2019

Stick100
Mar 18, 2003

ninjewtsu posted:

i was thinking about that as a possible solution, but obviously it's fairly expensive.

is "perform a raycast only if an object is moving at speeds faster than our normal physics accounts for" ever a solution? like if you know that things get wonky in your game if an object moves more than 1 foot in a single frame, perform a raycast to check collision if its moving more than 1 foot in a single step?

Yeah that's what that "don't go through things" script does, it uses normal collision unless the object is moving too fast compared to it's collider size then it starts testing.

Hyper Crab Tank
Feb 10, 2014

The 16-bit retro-future of crustacean-based transportation
The answer to all these questions really is "yes, sometimes". The fundamental thing to understand about computer games is that we cheat as much as we can get away with. Because even though computers are much faster now than they were say 20 years ago, we've also been pushing the envelope a lot and it's just not possible to simulate physics accurately in real time on consumer hardware while also doing all the other stuff that's part of a modern video game.

So we use whatever tricks we can get away with. Most of them revolve around trying to do as little work as possible by figuring out what absolutely needs to be done now with any semblance of accuracy and what we can cheat with. That process is part automatic and part manual. You might be surprised how often the answer to a complaint (from, say, a level designer) like "the physics wig out if I put this object near this other one" is "then don't put those objects near each other".

But there are automatic things too. Spatial data structures for early rejection, heuristics, doing rough physics for things first and fine grained stuff if it seems like some particular object needs more attention - especially if it's close to the player. If the player isn't looking at an object, it makes no sense to simulate it with high precision, right? The player doesn't care exactly how the box fell of the shelf if they weren't there to see it, they just want it to be on the ground somewhere roughly nearby.

Then again, these fast, dirty cheats are what gets us into trouble, too. Because we're trying to somehow solve all these problems all at once, and it's not always boxes moving straight at other boxes. A lot of the time it's a rotating irregularly shaped object moving in a curved path towards a pyramid or some other nonsense and now the clean mathematical solutions don't work, or are too hard to implement, or too hard to get to be performant. So things slip through the cracks, and we (programmers) talk to the level designers and tell them to set things up so the player isn't likely to encounter a situation where it all breaks down. And it works... most of the time... until some very persistent player manages to ram a car into a swing set to hilarious results that show up all over youtube and we all get to have a good laugh about it while sweating profusely inwardly.

(By the way, I should say my primary work is not physics programming, although I am a programmer. I haven't had to wrestle with the really tough problems personally.)

Hyper Crab Tank fucked around with this message at 16:04 on Apr 19, 2019

djkillingspree
Apr 2, 2001
make a hole with a gun perpendicular

ninjewtsu posted:

i was thinking about that as a possible solution, but obviously it's fairly expensive.

is "perform a raycast only if an object is moving at speeds faster than our normal physics accounts for" ever a solution? like if you know that things get wonky in your game if an object moves more than 1 foot in a single frame, perform a raycast to check collision if its moving more than 1 foot in a single step?

This isn't exactly the solution most games use - there's the idea of "sweeping" a collision volume, which essentially extrudes out the volume's path over time as a shape and then checks for where that shape intersects with collision objects to determine the point of collision.

For example, if you imagine a cube moving in a straight line, all of the cube's positions along that path are contained within a box with four of its vertices set at the face opposite the direction of movement, and the other four set on the the face in the direction of movement where it ends. Essentially, instead of "moving" the cube you stretch it in the direction of movement. Then, if you have two stretched cubes like this, you can identity where those two cubes intersect and that will determine where the collision happens. Usually, testing the intersection of two solids is cheaper than breaking down your simulation into tiny steps and doing raycasts for each step.

Though, as you might imagine, if something is taking a curved path, those volumes can get quite complex, so you often have to sample points on the path and build your swept volumes out of those.

To clarify, this problem isn't really specific to what people think of as "physics systems", either - really, all physics systems are is a more complex/simulation driven way of dealing with object collision, which is a problem that games have always had to solve. Even non-physics driven bullets need to do checks to make sure they don't tunnel through players.

Flannelette
Jan 17, 2010


djkillingspree posted:

This isn't exactly the solution most games use - there's the idea of "sweeping" a collision volume, which essentially extrudes out the volume's path over time as a shape and then checks for where that shape intersects with collision objects to determine the point of collision.


If anyone's ever wondered why when a video game physics object quickly slides over a flat surface made of multiple objects and but catches and bounces up on the "flat" seams this is usually the culprit where it's predicting a collision with the edge of the next piece since the prediction is using a simple quick algorithm to be useful in realtime.

Goreld
May 8, 2002

"Identity Crisis" MurdererWild Guess Bizarro #1Bizarro"Me am first one I suspect!"
For collision detection, Bullet can for example use Minkowski sums, which is the convex hull of all space the object could have overlapped during the time step.

Detecting the collision is easier than resolving, as others have mentioned - for anything sufficiently complex you have to backwards step with sub-timesteps; using a restitution force is a good way to get exploding sims.

One other big issue is that (usually for performance reasons), game physics engines often favor Euler and Verlet integration rather than higher order methods like Runge-Kutta-4. Someone feel free to correct me if this is just a configurable option in most engines, but code I’ve looked at seems to generally be linear Euler.

When you go above the sampling limit on Euler, it is inherently unstable, unlike RK4 which is conservative and won’t explode. This holds especially true for spring forces.

Flannelette
Jan 17, 2010


Goreld posted:

For collision detection, Bullet can for example use Minkowski sums, which is the convex hull of all space the object could have overlapped during the time step.

Detecting the collision is easier than resolving, as others have mentioned - for anything sufficiently complex you have to backwards step with sub-timesteps; using a restitution force is a good way to get exploding sims.

One other big issue is that (usually for performance reasons), game physics engines often favor Euler and Verlet integration rather than higher order methods like Runge-Kutta-4. Someone feel free to correct me if this is just a configurable option in most engines, but code I’ve looked at seems to generally be linear Euler.

When you go above the sampling limit on Euler, it is inherently unstable, unlike RK4 which is conservative and won’t explode. This holds especially true for spring forces.

Semi-Euler and Verlet should be enough for fast paced game physics where you don't mind if it's wrong aslong as it looks good and RK4 is more expensive and has its own problems (isn't sympletic) it just doesn't seem worth using unless you have a really stiff spring or something which probably why it doesn't show up.


I've asked about collision for 3d/modern 2d games but anyone know how different it was is back in ye olde days with sprites (where everything was explicitly just a grid of pixels)?

Flannelette fucked around with this message at 06:50 on Apr 21, 2019

Hyper Crab Tank
Feb 10, 2014

The 16-bit retro-future of crustacean-based transportation

Flannelette posted:

I've asked about collision for 3d/modern 2d games but anyone know how different it was is back in ye olde days with sprites (where everything was explicitly just a grid of pixels)?

Old 80s/early 90s games tended to have integer movement on a tile map or something that was also on integer coordinates (with subpixel movement usually handled specially). It makes collision detection and response significantly easier if you know movement is always going to be exactly aligned with the boundaries of tiles and other sprites. All you have to do is move a pixel at a time and reject the movement if the moving object would intersect something else after moving (and since we're talking about axis-aligned bounding boxes, detecting overlap is fast and trivial) and you can be sure objects will be flushly aligned without having to figure out how to separate them and whatnot. You can still tunnel through things by moving fast enough, of course.

Some games still did a lot of the same operations we're talking about here, though, such as pushing objects out of solid walls. But the constraints were much tighter and assumptions made so that the checks could be vastly simplified. The biggest advantage is arguably not having to worry about rotating or irregularly shaped objects.

Hyper Crab Tank fucked around with this message at 07:52 on Apr 21, 2019

g0lbez
Dec 25, 2004

and then you'll beg
This thread is a great read but I burned through it pretty quickly and my only remaining curiosity would be an elaboration on already answered questions so if anyone can share some links to some more insider developer stories (preferably trainwrecks as they're more entertaining) to help my workday go by easier that'd be great!

Discendo Vox
Mar 21, 2013

We don't need to have that dialogue because it's obvious, trivial, and has already been had a thousand times.

g0lbez posted:

This thread is a great read but I burned through it pretty quickly and my only remaining curiosity would be an elaboration on already answered questions so if anyone can share some links to some more insider developer stories (preferably trainwrecks as they're more entertaining) to help my workday go by easier that'd be great!

Gamasutra is loaded with postmortems and development blogs and other such articles, with varying amounts of self-promotion.

mutata
Mar 1, 2003

Also: feel free to ask for elaborations other follow ups to previous questions!

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!
About the frame rate stuff, there are a lot of ways that it can happen beyond just collision detection.

Framerate dependency mostly happens because the intuitive way of writing a game loop is to advance the game by whatever timestep, then figure out all of the various things that can affect the game state that happened since the last frame, and apply those to the game state according to the game rules, and repeat.

The problem with doing things that way is that, by default, it's not dealing with the fact that things happen between frames and in a particular order at all and there are a lot of ways that can lead to discrepancies.

Of those things that affect the game state, the order that they're processed is almost never determined by what sub-frame time the event theoretically would have happened, it's determined by something else like what order the objects were created, which means that the order that things happen can change depending on whether they happen in the same frame or different frames. It doesn't matter if the physics system is good enough to handle subframe interactions if it all goes into per-object contact lists that then get processed in a completely different order and aren't interleaved.

Failing to integrate acceleration and gravity when making physical-behaving stuff that doesn't use the actual physics system is a another common mistake.

Subframe time carryover is rarely handled correctly. By that I mean, if a game is stepping once every 100ms (just hypothetically), and some event is supposed to happen in 150ms, then it will really happen at the 200ms frame, but most game logic is written in a way that any responses to that event are treated as if they happened at the current frame time, so they start at the 200ms mark too and now that's all running 50ms behind. I think most shooters by now are handling this correctly with rapid-fire weapons, and sometimes it's done correctly by accident, but it's still a problem for state transitions (like animation states) and especially timers.

Using a fixed time step doesn't make these problems go away, but it does make them behave consistently, and it also allows a lot of subframe carryover problems to be eliminated by doing things like making all of the animations last for multiples of the frame time.


Also just a fun personal anecdote related to the carryover problems, I was making a TAS mod of Quake and found out that if the framerate gets high enough, it hits an internal 72Hz limiter, which conflicts with nearly all of the animation in the game being driven by chained 100ms timers, and causes everything to animate 10% slower than it should.

OneEightHundred fucked around with this message at 08:10 on Apr 29, 2019

Flannelette
Jan 17, 2010


When the term Tickrate is used in regards to a game engine is it the same as Tickrate for hardware? The smallest interval when any state in the game engine can change or are there things that can happen sub-tick in the same way things can happen between frames?

I'm trying to find a paper on the game technique that I like but I don't know what it's called to search for one, it's the thing that metal gear rising and a few other games, plus any modeling software has where you can split a mesh with a plane and it will generate 2 new closed meshes procedurally.

BiggerBoat
Sep 26, 2007

Don't you tell me my business again.
You guys have been going on about unions and working conditions a lot. Stumbled across this story about a possible walkout at Riot.

https://kotaku.com/riot-employees-plan-walkout-to-protest-company-blocking-1834387083

Mooey Cow
Jan 27, 2018

by Jeffrey of YOSPOS
Pillbug

No sane human being would design a collision system like this, btw, with 50 different "hitboxes" for every wall for different player states. Instead you would have one polygon (or polyhedron) for each wall and change the player's collision volume depending on their state. To achieve the effect that Mario could get closer to a low wall and step up on it, you'd do a check first from the middle of Mario to see if that part hits anything; if it doesn't do a shorter test from the knees or something; if that also doesn't hit anything, allow Mario to move up on the thing. Basically imagine the stacked boxes on those walls upside down and placed on Mario instead (but you probably wouldn't want them to be actual boxes rather than just very simple line or volume/sphere tests).

The thing described in that video is just so backwards for no real advantage that I really doubt that's actually how Mario 64 works.

Chev
Jul 19, 2010
Switchblade Switcharoo
No, that's really how it works and it's a logical evolution if you take it in the context of 8 and 16 bit pixel platformers, where characters were also using points (as in Mario or that McDonald thing) or raycasts (as in Sonic) with plenty of special cases to get specific behaviors, and some modern games that seek to emulate the feeling will also use them (Indivisible for example). Everything was still to be invented back then, and favoring approaches that didn't require complex geometric calculations.

The whole standardized volume-based collision approach in 3d worlds that we use today is a result of a different evolutionary branch that mostly sprouts from Quake (itself finding its roots on Doom/Wolf3d), which came out three days after Mario 64 so it's not like they could borrow from each other.

Mooey Cow
Jan 27, 2018

by Jeffrey of YOSPOS
Pillbug
I mean, has anyone actually dug into the code to verify that's how it works? Because I literally can't find anything to suggest that. The best I found is the level structure, where the collision is pretty clearly stored as three vertices and a plane vector, with no hint of any boxes. So if they exist, they must be constructed at runtime, but storing that would be slow and take up memory (and there would surely be debug tools showing them). So instead they would be calculated when needed on a per check basis. But this is pretty different from saying the walls "have" boxes, as they would only exist during that particular check, and other colliding things would/could put their own boxes on the triangles.

Also note that the slope "boxes" in the video are actually parallelepipeds, requiring at least one full plane check you can't get around by transforming everything to be axis aligned with the box. So the system still requires complex calculations (which should be obvious anyway, as the system handles objects rotating in all sorts of ways, and the boxes would actually represent triangles).

Like, the system described just sounds totally awkward, not like an evolution of 2D collision. If someone can verify it, that's fine, but no one should get the idea that this is a good way to build a collision system. It won't give you a "retro" feel, it'll just give you headaches. Points against tiles on other hand can have real uses.

Hughlander
May 11, 2005

Mooey Cow posted:

No sane human being would design a collision system like this, btw, with 50 different "hitboxes" for every wall for different player states.

Have you seen how ships in Star Citizen work? :)

Flannelette
Jan 17, 2010


Mooey Cow posted:

I mean, has anyone actually dug into the code to verify that's how it works?
I think it has for mario 64 or it seems like it must have for the speed run techniques used on it now, the only things I can remember is it has to use simple math since it doesn't have floating point and it is done at run time.
I think the boxes are just a visual aid for the video and the real effect isn't a real box like in bounding box collision, just an imaginary hitbox like volume around the tri made from the opposing vectors of it and the player.

Chev
Jul 19, 2010
Switchblade Switcharoo
I mean, it's a matter of dual representations, just like how a collision between two aligned boxes is strictly equivalent to a collision between a point and a box that has the sum of the dimensions of the two original boxes, or how an ellipsoid-to-triangle collision is a sphere-to-triangle collision in the frame of reference formed by the ellipsoid's semi-axes. Like, the algorithm is strictly the same, and from the code you can't guess the intent of the programmer. You can argue that one is easier to picture, but that'll be, in fact, arguable depending on how you need to visualize the problem (like, for the ellipsoid, if you're trying to visualize it in a larger frame of reference the first way is simpler, if you're trying to visualize how to solve it the second way is). Because they're equivalent representations mathematically or algorithmically, you're free to switch to the more convenient one according to your needs.

In the case of that Mario madness the stuff in that video is all strictly exact algorithmically or mathematically and yeah, that's been verified and tested. The representation's kinda crazy but the problem lies in that the equivalent representations you can cook up for it aren't particularly simpler to visualize. You can't just take the measured behavior and reduce it to a collision volume around Mario interacting with environment triangles. Instead you're gonna have a bunch of volumes that depend on where he is, what's he's colliding with and what direction and height he's approaching it from and how the collisions aren't watertight, etc. Mario vs a wall isn't Mario as a box or cylinder but a test against the axis-aligned vector that's closest to the wall's normal and that's not the same, in fact neither Mario not the wall behave as volumes but on the other hand if you wanna visualize a volume somewhere the parallelipiped's a good one to visualize the displacement field that Mario's effectively interacting with.

If you wanna find the intent behind it you can sorta see how it could be reducible to a box around Mario that was only tested with axis-aligned surfaces in a level with only acute angles, by people who only had a sketchy idea of how box-to-plane collision tests should be done and limited computing power, then special-cased like crazy to account for gaps and ceilings and diagonals and so on, but that's only helping you trace its lineage, not how it actually behaves due to all that special-casing. So many tricks, too. I was amazed the first time I discovered, when playing Mario Sunshine, that Mario would automatically jump off/hang on ledges when close enough just to avoid the special cases from only partially standing over them.

And so yeah, it's not a good collision system, but on the other hand it's a great example of solving the collision problem with limited resources while still getting some very specific desired behaviors out of it.

Chev fucked around with this message at 00:43 on May 1, 2019

ETPC
Jul 10, 2008

Wheel with it.
https://www.youtube.com/watch?v=2TSB5YQqDiY

DreadCthulhu
Sep 17, 2008

What the fuck is up, Denny's?!
Are there any well established resources for music producers / composers who want to specifically write for games? Not for getting into the industry, more about how making music for a game differs from other contexts. Anything that game composers say "you gotta read/watch/learn from x" to get a deeper understanding of it? Or does everybody wing it?

Isaac
Aug 3, 2006

Fun Shoe
I've been working on a game for a while and just got to the point I have an alpha I would appreciate feedback on. Is this a thread I can do that, or does such a thing exist in games?

Studio
Jan 15, 2008



https://forums.somethingawful.com/showthread.php?threadid=3506853
:tipshat:

I wouldn't say not to post it here, but it's not really the point of this thread?

Isaac
Aug 3, 2006

Fun Shoe

Studio posted:

https://forums.somethingawful.com/showthread.php?threadid=3506853
:tipshat:

I wouldn't say not to post it here, but it's not really the point of this thread?

Thanks!

I'll split the difference and let you know itt that I posted itt (in that thread)

Roman
Aug 8, 2002

I'm curious how devs/studios, especially who make bigger AAA titles and live service games, feel when they see streamers and other people who do nothing but play games for 8+ hours a day for years complain that "there's nothing left to do, game dead."

How much can you really cater to those type of people? Is it worth it? How much influence do they really have? How big are their numbers compared to the majority?

leper khan
Dec 28, 2010
Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Roman posted:

I'm curious how devs/studios, especially who make bigger AAA titles and live service games, feel when they see streamers and other people who do nothing but play games for 8+ hours a day for years complain that "there's nothing left to do, game dead."

How much can you really cater to those type of people? Is it worth it? How much influence do they really have? How big are their numbers compared to the majority?

Live games are a content mill. If the game has been running for any length of time, that group will just need to wait ~2-4 weeks for the next content drop.

If it’s shortly after launch, maybe the game got pushed without the endgame fleshed out thinking it would be in place before most people got to it. It’s not a good look, but there’s not much to do about it other than to churn out the content at the fastest sustainable rate.

cubicle gangster
Jun 26, 2005

magda, make the tea
I feel like I saw that most obviously with the division.
Quite a lot of people got annoyed and angry that the game ran out of content 100 hours in. Seems like it would be better in some cases to have the credits roll at hour 50 and boot them back to menu.

TheDiceMustRoll
Jul 23, 2018
yo, game devs

I've had a suspicion for awhile due to knowing people in various other entertainment industries such as film and tv.

When people who work at big AAA studios do poo poo like go "I'm the guy who did (big game)", is this always an instant indication they're a lying sack of poo poo? Everyone I know who works on film and tv just treats it like work, even when they're free to discuss things they don't care to, and generally don't toot their own horn.

Then you get people who are like, "yOu KnOw I mAdE wOw, RiGhT?" and I have to wonder why people would care to claim that kind of poo poo. How do normal developers feel about this behavior?

Fangz
Jul 5, 2007

Oh I see! This must be the Bad Opinion Zone!
In what context do you mean here?

Chernabog
Apr 16, 2007



There're all kinds of people in the industry, like in anything else really.

Fangz
Jul 5, 2007

Oh I see! This must be the Bad Opinion Zone!
Are you comparing a bunch of guys in the pub who were extras or helped move equipment in the Avengers to some ex-Bioware writers/designers/artists trying to kickstart an indie project. Because if so then obviously you aren't comparing like to like.

TheDiceMustRoll
Jul 23, 2018

Fangz posted:

Are you comparing a bunch of guys in the pub who were extras or helped move equipment in the Avengers to some ex-Bioware writers/designers/artists trying to kickstart an indie project. Because if so then obviously you aren't comparing like to like.

Mark Grummz has literally said he created WoW.

Gearman
Dec 6, 2011

TheDiceMustRoll posted:

Mark Grummz has literally said he created WoW.

You mean Mark Kern? He was a lead, so he's not exactly lying.

To expand on this: context really matters, and it's tough to know what he was saying without the full quote. That said, I think it's well understood that no AAA game is "created" by a single person as is evident by the miles-long credits that no one reads.

Gearman fucked around with this message at 00:27 on May 20, 2019

RossCo
Dec 30, 2012

I have no idea what I am doing in almost any given situation.

Gearman posted:

You mean Mark Kern? He was a lead, so he's not exactly lying.

To expand on this: context really matters, and it's tough to know what he was saying without the full quote. That said, I think it's well understood that no AAA game is "created" by a single person as is evident by the miles-long credits that no one reads.

Exactly this. I've never had someone doubt the games I've worked on:

a) Because I always disclaim it with "I'm a small part of a large team"

b) Because they can see the trauma in my eyes

c) No rational human being has this many tshirts from one company or franchise

The whole credits thing is interesting. Some of the political fighting that goes into credit sequences is truly impressive.

RossCo fucked around with this message at 20:16 on May 20, 2019

Kennel
May 1, 2008

BAWWW-UNH!

RossCo posted:

The whole credits thing is interesting. Some of the political fighting that goes into credit sequences is truly impressive.

And that's why Valve just list every employee alphabetically.

RossCo
Dec 30, 2012

I have no idea what I am doing in almost any given situation.

Kennel posted:

And that's why Valve just list every employee alphabetically.

Completely true: I proposed randomising the order in which sections display in a credit sequence once.

My lead looked at me and asked if I didn't have enough bugs in the game, and thus felt the need to introduce some into the credits.

The burn was real.

nielsm
Jun 1, 2009



Kennel posted:

And that's why Valve just list every employee alphabetically.

Have any changed names to appear elsewhere in the credits?

Adbot
ADBOT LOVES YOU

cKnoor
Nov 2, 2000

I built this thumb out of two nails, a broken bottle and some razorwire.
Slippery Tilde

Roman posted:

I'm curious how devs/studios, especially who make bigger AAA titles and live service games, feel when they see streamers and other people who do nothing but play games for 8+ hours a day for years complain that "there's nothing left to do, game dead."

How much can you really cater to those type of people? Is it worth it? How much influence do they really have? How big are their numbers compared to the majority?

I can answer this, generally you want streamers to play your game for a full session, and if they manage to do that 8+ hour a day for years and still have an audience of a 100 viewers or so then good on them. Those people rarely complain about there not being anything to do though, as their stream viewers are very much tied to the game they are playing. Essentially if they were to swap to another game they might lose a large chunk of their audience and subscribers. So it's pretty much a non-issue for that specific time of streamers.

A larger worry are streamers that play your game for 8 hours and then decide that there is nothing left to do, since that either indicates that they do not like the game or that there are in fact nothing more to do. Both of those are bad. While at the same time you wouldn't cater to those streamers. You'd probably pay some large streamers to stream you game during launch week to get eyeballs on the game, and while you hope that they want to keep streaming you're not relying on them to do so.

For just monetary value, the most valuable type of streamer are those that are happy to stream your game at no cost, and has an audience of a few hundred. They tend to have the most engaged audience and are more likely to by your game if the streamer recommends it. That is of course under the assumption that you do not have to spend time babysitting them to get the game running, or that they say horrible poo poo so you have to black list them from getting future games. You rarely cater to specific streamers outside of a marketing activation, but you might cater to streamers generally by making the game more streamable. Daily challenges are a good example of this, as it gives streamers and players something to come back to every day.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply