Making Games Megathread: Congratulations on releasing the horniest game of 2022

The Something Awful Forums > Discussion > Video Games > Making Games Megathread: Congratulations on releasing the horniest game of 2022

«‹›1358 »

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

TooMuchAbstraction posted:

Especially if you're doing all the art yourself, you really want to spend some time on figuring out what an achievable aesthetic is for your game. Most games have far more artists than programmers, so you're going to have to cut corners somewhere or you'll never finish. Common corners to cut:

- Don't have really detailed models. You already mentioned going for low-poly, so that's good. But by the same token, really low-poly, where every vertex counts, can be extremely hard to do well. Really what you want is structural simplicity, ideally something where most models are built up out of simple shapes, and detail is implied more than spelled out.
- Don't have detailed textures. Photorealism is right out. Give some serious thought to whether you need textures at all, or if just blocking out colors. One trick I've used is to assign materials on a per-vertex basis, with each material being basically a distinct color. Remember that you can use lighting and postprocessing to dramatically change how a scene looks.
- Don't have lots of distinct models. The fewer individual things you have to model, the more time you can spend on them.

For what it's worth, I use Blender for all of my modeling. In the rare event that I need a UV-mapped model, I usually handle it by making a "high-quality" model with Blender materials assigned per-vertex, and then baking that high-quality model's albedo and normals into textures that Blender automatically maps to the low-quality model. Here's the notes I wrote on that topic.

But usually I just assign simple materials directly to the low-poly model's vertices.

Along with this, targeting a consistent low fidelity aesthetic makes everything easier. If you have extremely photorealistic models with high def normal maps and material shaders on everything, then every time your animations do something dorky its going to stand out like a sore thumb.

On the other hand if you make your game out of Lego people, having someone wave their arms in a very unnatural manner can actually look reasonably fine and nobody will complain about it.

This is why I think Doom is such a prolific game engine; because the art assets and technical level inherently give you a low bar to meet, and make it easy to produce content. Meanwhile modern FPS games don't see 1/1,000th as much mod work as Doom does, because just building a single level takes a thousand hours of work.

al-azad posted:

Speaking as a guy who does all of his art, a consistent aesthetic is far more important than quality or details. Everything being consistently crap is more accepted than having some low poly garbage mixed in with a carefully detailed portfolio piece. There�s nothing wrong with marketplace assets either but adapting them is an art form in itself.

Bingo

# ? Feb 25, 2021 01:11

Adbot: ADBOT LOVES YOU

# ? Apr 19, 2024 10:05

Somfin: Oct 25, 2010; In my🦚 experience🛠️ the big things🌑 don't teach you anything🤷‍♀️.; Nap Ghost

StashAugustine posted:

Hey, I'm picking up a project I left a few weeks ago and trying to figure out how I'm going to factor the behavior trees for my AI. I initially had a system with customized selectors- so there'd be a "check LOS" object that extends Selector with an additional check for line of sight before testing its children. The actual leaves would all be motion planning. However, I've seen other examples that implement it as a sequence where the first leaf node is a logic check (in this case, checking line of sight) and then after that you include the execution leaves. This seems a lot more flexible, in that it's easier to reuse the logic nodes, but also a lot messier to keep track of. Does anyone else have experience with this sort of thing?

Hey, I've just been working on a solution for this poo poo, I didn't see any other responses, and I think I've hit a good one. Please bear with me, I decided to change all of the words because that's how I work best; here's a basic translation:

Sequence => Process
Selector => Choice
Node => Thought
Leaf => Decision

So, the major thing in my system is that I split the thought process from the creature's capabilities in order to make maximally flexible trees. A basic "hunt down the player" thought tree, in my system, looks like this:

This means that choices, processes, and decorators all exist purely as junctions for other thoughts. There's only one form of choice, only one form of process. Additionally, there's only one form of attack, one form of find the player, et cetera.

The responsibility for figuring out how the creature which is using this thought tree finds the player or moves toward the player or attacks the player is left to that creature's brain. The one that I've built so far always knows where the player is, uses a hopping motion to get to the player, and its "attack" is just loading up a once-off damage collider before using the same hopping motion to try to touch the player, but the exact same thought tree could run a creature who spots the player by LOS and remembers their last location if the player breaks LOS, moves toward the player by crawling along available surfaces, and attacks by throwing a fireball as soon as it's within range, circling the player during its cooldowns.

The same thought tree could not run a creature that tries to hide from the player behind other allies, because that's a decision this tree isn't making; this one is "if the player is a long way away, get close; if the player is close, all-out attack; if the player is further than a long way away, keep checking to see if you see 'em yet."

The Always-Failure node on finding the player forces the Choice to run its other nodes, even when finding the player is successful; this is because "being unable to find the player" might provoke an actual response from some trees, but in this one it's purely something to do whenever it gets back to the Root.

Somfin fucked around with this message at 01:20 on Feb 25, 2021

# ? Feb 25, 2021 01:18

BabelFish: Jul 20, 2013; Fallen Rib

Speaking of art, Kenney of Kenney.nl fame just released a new tool for turning pixel art into 3d assets: https://tools.kenney.nl/kenshape/.

He also built Assetforge which is awesome in its own different way.

# ? Feb 25, 2021 01:30

commando in tophat: Sep 5, 2019

TooMuchAbstraction posted:

For indie dev, the thing I'd advise aiming for isn't so much careful use of polys as it is careful use of detail. Detail is what takes time to model, so you don't want to e.g. spend a lot of time modeling each individual bolt on some bit of machinery unless you know the camera's going to get close enough for that detail to be warranted. Feel free to make a 64-faced cylinder for something that needs to look round though; it takes just as much time as making a 12-sided cylinder and looks better.

In that case, I just hope you're having fun!

Oh yeah, I'm not modeling some details, that's why I wanted to paint on some textures like scifi-metal-plating and such to add some detail when you zoom in, but also don't want to spend too much time on it.

I'm definitely having fun (and learned a quite a bit, which was the initial goal of this project), at least most of the time. If I had any plans to make money with it, I would definitely go for unity or unreal.

BabelFish posted:

He also built Assetforge which is awesome in its own different way.

Kind of reminds me of Spore

# ? Feb 25, 2021 09:31

dhamster: Aug 5, 2013; I got into my car and ate my chalupa with a feeling of accomplishment.

Tried this out and it works great in the beta version of the steam client.

https://twitter.com/SteamDB/status/1364854014127583238

# ? Feb 25, 2021 10:34

The Titanic: Sep 15, 2016; Unsinkable

al-azad posted:

Speaking as a guy who does all of his art, a consistent aesthetic is far more important than quality or details. Everything being consistently crap is more accepted than having some low poly garbage mixed in with a carefully detailed portfolio piece. There�s nothing wrong with marketplace assets either but adapting them is an art form in itself.

This tends to be the biggest downfall of what may be otherwise inventive games.

I've seen some devs go through a wringer because they used a bunch of art assets, and that was the first impression people got because by now a lot of people can immediately recognize these assets.

It's like going through steam and seeing some game where the UE mannequin is used as the player. Like, come on guys.

But this also seems to come in a couple of exciting forms also.

One form is the mishmash of assets that don't match at all.

The second form is the game/demo that downloaded all the assets and is a 60GB demo that is like 10m of some barely functional prototype because they packaged the entirety of the marketplace assets, especially free ones.

# ? Feb 25, 2021 15:41

al-azad: May 28, 2009

It feels like a huge oversight that UE packs everything including unused assets and plugins. A friend did a stream where she packed down an empty project folder to sub 200mb and Tim Sweeney excitedly retweeted it with tears in his eyes.

# ? Feb 25, 2021 16:22

The Titanic: Sep 15, 2016; Unsinkable

al-azad posted:

It feels like a huge oversight that UE packs everything including unused assets and plugins. A friend did a stream where she packed down an empty project folder to sub 200mb and Tim Sweeney excitedly retweeted it with tears in his eyes.

The default for it is to package the whole content folder, which can include everything you've done or played with and ended up forgetting about and never using.

You can also specify an array of map names and the system will only package stuff that is used in those maps. This should reduce what your packaged size is.

# ? Feb 25, 2021 19:29

SubNat: Nov 27, 2008

Yeah, it would be nice if it was smarter about it, but the moment you just specify which maps to build the end result gets a lot smaller. And fishing out the plugins you don't use is like a few minutes at the start of a project.
But it's understandable that Unreal bowed out of the HTML5 market when it was like, impossible to make an empty project for web be smaller <20MB / ~8MB compressed. Having to roll out 100MB+ html5 apps put a dampener on that pretty quick.

Beyond that the issue is also a lot of people wrapping in assets/textures that are way too big, on top of cramming marketplace assets in.
Giant baked lightmaps, including tons of 4k textures, etc. It's the thing you learn to manage if you ever try to make a lightweight project, but UE has a ton of beginners who haven't yet learned how to use device profiles and etc to slim down sizes.
Lower bar to entry means way more people entering, after all.

# ? Feb 25, 2021 19:58

al-azad: May 28, 2009

For all the half baked features Unity keeps adding then forgetting about, I really like how easy it is to manage your project tree and optimize the game. The option to create a blanket rule for your textures on build, by default compressing then to 2k max, feels like they�re protecting beginners from themselves. Which makes sense because unity was big on web builds a decade ago.

I�ve reached a point where I�m counting cpu cycles and drawcalls with the intense interest a painter would have marking individual brush strokes. �Ooh, I gained .3fps average Atlasing these textures!�

# ? Feb 25, 2021 20:30

The Titanic: Sep 15, 2016; Unsinkable

Unreal is both deceptively easy to do and infuriatingly complex to genuinely figure out.

It will happily let you shoot yourself in the foot, and a lot of people do, and all you can do is just shrug.

But unreal also makes it very easy to get these huge bloaty things as well. Like mega scans and such. Like every game needs at least 200 70MB grass textures with complex shader connections and a million bitmaps.

I feel like being old has helped me to realize when a 64x64 size texture is "good enough" and where going for that incredible photorealistic stuff is just not a good goal to aim for.

But that's not to stop somebody who doesn't know how to use a modeling program from buying some ungodly detailed character and then nothing else in the game comes close. I see that a lot with FPS games. Like your gun is basically real and straight from Smith and Wesson, but you're shooting what looks like Minecraft zombies.

# ? Feb 25, 2021 21:50

Omi no Kami: Feb 19, 2014

This might not have a clear universal answer, but if I'm faking a day/night cycle by slowly shifting the color grading and shadows of a scene with static environment lighting, is it worth using a second directional light to add some minor shadowcasting at night? Like, here's midnight when the only shadowcaster is below the horizon:

It looks flat to me, and I'm assuming the flatness is due to the lack of shadows, but realistically 90% of the shadows you see at night come from manmade lights, not the moon. So is it worth sweating this at all, or is it easier to stick with flat environment lighting and rely on prop lights to break things up?

Edit: Oh, and for comparison, here's the same setup with a low-intensity moon:

Omi no Kami fucked around with this message at 06:31 on Feb 26, 2021

# ? Feb 26, 2021 06:21

Flannelette: Jan 17, 2010

The first one would look fine if it's cloudy and the other one looks good if there was some moonlight.
The full moon casts very noticeable shadows except right under something as bright as a street light.

# ? Feb 26, 2021 07:22

DaveKap: Feb 5, 2006; Pickle: Inspected.

I'm makin new pieces for IncrediMarble and the least interesting piece ended up making for one of those oddly-satisfying gifs.
https://i.imgur.com/etnT8MT.gifv

# ? Feb 26, 2021 07:53

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

When ships in my game are going really fast, they kind of skip over the waves. This is cool and fine, but it does make the camera kind of jittery. I'm trying to figure out ways to smooth out the camera that wouldn't also reduce its responsiveness when the player wants to move it. That is, if I need to smooth out bumps that are on the order of 1/10th of a second, does that necessarily imply a 1/10th second of "input delay" between when you start moving the camera and when it responds? I feel like that could make controlling the camera difficult.

This video is a little exaggerated but should give some idea of what I'm talking about :

https://i.imgur.com/uaZiU0k.mp4

# ? Feb 26, 2021 18:33

Ruzihm: Aug 11, 2010; Group up and push mid, proletariat!

You could try limiting the rotational delta of your camera's local up. Something like this:

code:

float previousUpAngle;
[SerializeField] float maxRotSpeed = 0.0872f; // 5 deg/s in rad/s

void Awake() 
{
    previousUpAngle = Vector3.SignedAngle(Vector3.up, transform.up, transform.right);
}

// Clamps transform's rotation based on delta from where it was clamped last frame.
void LateUpdate()
{
    // If it isn't already at this point, set transform to be where it "wants" to be e.g.,
    // based on player input, camera boom calculations, etc

    float curUpAngle = Vector3.SignedAngle(Vector3.up, transform.up, transform.right);
    float maxDelta = maxRotSpeed * Time.deltaTime;
    float cappedUpAngle = Mathf.Clamp(curUpAngle, previousUpAngle - maxDelta, previousUpAngle + maxDelta);
    
    float adjustment = cappedUpAngle - curUpAngle;
    
    Vector3 newForward = Quaternion.AngleAxis(adjustment, transform.right) * transform.forward;

    transform.rotation = Quaternion.LookRotation(newForward);

    previousUpAngle = cappedUpAngle;
}

Ruzihm fucked around with this message at 19:14 on Feb 26, 2021

# ? Feb 26, 2021 18:46

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

TooMuchAbstraction posted:

When ships in my game are going really fast, they kind of skip over the waves. This is cool and fine, but it does make the camera kind of jittery. I'm trying to figure out ways to smooth out the camera that wouldn't also reduce its responsiveness when the player wants to move it. That is, if I need to smooth out bumps that are on the order of 1/10th of a second, does that necessarily imply a 1/10th second of "input delay" between when you start moving the camera and when it responds? I feel like that could make controlling the camera difficult.

This video is a little exaggerated but should give some idea of what I'm talking about :

https://i.imgur.com/uaZiU0k.mp4

In that video, is the player controlling the camera?

Can probably give the camera some weight so it doesn't shift so fast over waves, but if the player inputs something then immediately override the weight and just do what they say.

# ? Feb 26, 2021 18:55

The Titanic: Sep 15, 2016; Unsinkable

TooMuchAbstraction posted:

When ships in my game are going really fast, they kind of skip over the waves. This is cool and fine, but it does make the camera kind of jittery. I'm trying to figure out ways to smooth out the camera that wouldn't also reduce its responsiveness when the player wants to move it. That is, if I need to smooth out bumps that are on the order of 1/10th of a second, does that necessarily imply a 1/10th second of "input delay" between when you start moving the camera and when it responds? I feel like that could make controlling the camera difficult.

This video is a little exaggerated but should give some idea of what I'm talking about :

https://i.imgur.com/uaZiU0k.mp4

What I've done to alleviate stuff like this in the past is have some separate actor acting as the camera boom that can flatten out and smooth the movement from the character. This maintains camera responsiveness and also helps smooth out stuff like a character running over bumpy terrain and causing the camera to bounce like crazy because it's just directly attached to the character at some socket.

# ? Feb 26, 2021 19:13

The Titanic: Sep 15, 2016; Unsinkable

Omi no Kami posted:

This might not have a clear universal answer, but if I'm faking a day/night cycle by slowly shifting the color grading and shadows of a scene with static environment lighting, is it worth using a second directional light to add some minor shadowcasting at night? Like, here's midnight when the only shadowcaster is below the horizon:

It looks flat to me, and I'm assuming the flatness is due to the lack of shadows, but realistically 90% of the shadows you see at night come from manmade lights, not the moon. So is it worth sweating this at all, or is it easier to stick with flat environment lighting and rely on prop lights to break things up?

Edit: Oh, and for comparison, here's the same setup with a low-intensity moon:

The pictures look identical to me.

But regardless of that, if you don't have a shadow moving during the day with the sun, I wouldn't worry about a moon shadow either. Stick with your setup and just keep the man made lights casting shadows.

# ? Feb 26, 2021 19:16

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Zaphod42 posted:

In that video, is the player controlling the camera?

Can probably give the camera some weight so it doesn't shift so fast over waves, but if the player inputs something then immediately override the weight and just do what they say.

All of the motion there is automatic. Some of it is caused by engaging the engine overdrive, which makes the camera move in an attempt to create a sense of speed, but the bumpiness from the ship skipping over the waves is the main thing I'm worried about.

The Titanic posted:

What I've done to alleviate stuff like this in the past is have some separate actor acting as the camera boom that can flatten out and smooth the movement from the character. This maintains camera responsiveness and also helps smooth out stuff like a character running over bumpy terrain and causing the camera to bounce like crazy because it's just directly attached to the character at some socket.

I'm not sure I understand what you mean, implementation-wise. Do you mean you have an empty that follows the player's averaged position (i.e. potentially laggy), and the camera moves in response to that empty (with no input delay)? That sounds like a plausible solution.

# ? Feb 26, 2021 19:36

Ruzihm: Aug 11, 2010; Group up and push mid, proletariat!

TooMuchAbstraction posted:

All of the motion there is automatic. Some of it is caused by engaging the engine overdrive, which makes the camera move in an attempt to create a sense of speed, but the bumpiness from the ship skipping over the waves is the main thing I'm worried about.

I'm not sure I understand what you mean, implementation-wise. Do you mean you have an empty that follows the player's averaged position (i.e. potentially laggy), and the camera moves in response to that empty (with no input delay)? That sounds like a plausible solution.

Yes, it follows the player's position, often times simply being a sibling of the player's mesh, and handles dampening and collision in various ways. In Unreal, you commonly use a "Spring Arm Component" as a starting point. In Unity, you essentially start from scratch.

Here's a random blog post with some neat images that I think help explain. https://www.allthingsgamedev.com/articles/creating-a-camera-boom-in-unity

Ruzihm fucked around with this message at 19:57 on Feb 26, 2021

# ? Feb 26, 2021 19:53

The Titanic: Sep 15, 2016; Unsinkable

TooMuchAbstraction posted:

I'm not sure I understand what you mean, implementation-wise. Do you mean you have an empty that follows the player's averaged position (i.e. potentially laggy), and the camera moves in response to that empty (with no input delay)? That sounds like a plausible solution.

I'm not sure what the unity terminology is, but that sounds accurate. Basically your camera is attached to a third party entity that in turn is connected via smoothing code to your character. The third party element can have delays or averaging or whatever you want to slap into it to smooth out the characters erratic movement, and your camera remains fully responsive because it's attached to that third party actor and itself has no sort of smoothing or averaging logic on it.

# ? Feb 26, 2021 20:01

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Awesome, thanks! I'll give it a shot.

# ? Feb 26, 2021 20:02

The Titanic: Sep 15, 2016; Unsinkable

It's also neat for car games too because you can also have some play in all axis, so your car can sort of "move ahead" of the camera and look like it's going faster, instead of the camera just being glued in place at some fixed distance.

Play with the values though and figure out what looks best at your speeds, because you don't want the camera to be too far behind. Set up some maximum distance it can go away etc etc.

I hope this helps.

# ? Feb 26, 2021 20:05

Fur20: Nov 14, 2007; すご▞い！
君は働か░い
フ▙▓ズなんだね！

Zaphod42 posted:

On the other hand if you make your game out of Lego people, having someone wave their arms in a very unnatural manner can actually look reasonably fine and nobody will complain about it.

this is true but at the same time if you make your game out of lego people, your product is visually indistinguishable from every other game that uses lo-res lego people. it's difficult!

# ? Feb 26, 2021 20:21

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

TooMuchAbstraction posted:

I'm not sure I understand what you mean, implementation-wise. Do you mean you have an empty that follows the player's averaged position (i.e. potentially laggy), and the camera moves in response to that empty (with no input delay)? That sounds like a plausible solution.

You don't even need the empty. Just put the script on the camera.

See the rest of my last post. I figured that the camera was being autopiloted I was just checking / asking a leading question.

You already have a script that is auto following the target. Just interpolate towards the target instead of instantly updating. You can add acceleration or just have a max speed per frame or second or whatevs.

Take the current camera pos, then where the tracking would put it, and shift the current pos some variable distance towards the target pos.

Zaphod42 fucked around with this message at 20:25 on Feb 26, 2021

# ? Feb 26, 2021 20:21

Superrodan: Nov 27, 2007

Your game takes place entirely on what is essentially a flat plane (water), right? Is your camera looking at a specific point ahead of the ship that is tilting with the ship's pitch as it goes over the waves and that is causing the issue? Would it be possible to just have the look ahead point not tilt with the pitch of the ship? Essentially have it X in front of the ship in the ship's yaw axis in world coordinates instead of local coordinates?

# ? Feb 26, 2021 21:15

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Zaphod42 posted:

You don't even need the empty. Just put the script on the camera.

See the rest of my last post. I figured that the camera was being autopiloted I was just checking / asking a leading question.

You already have a script that is auto following the target. Just interpolate towards the target instead of instantly updating. You can add acceleration or just have a max speed per frame or second or whatevs.

Take the current camera pos, then where the tracking would put it, and shift the current pos some variable distance towards the target pos.

So, that seems like it ought to be straightforward, but I'm getting absolutely terrible results. Like, this video shows a normal, non-laggy camera, and then it shows the "smoothed" camera:

https://i.imgur.com/M4nU6F9.mp4

All that I'm doing is this:

code:

lookPoint = Vector3.Lerp(lookPoint, player.transform.position, lerpFac);

(lerpFac is 1 at the start of the video, and .1 later when it goes all jerky)

Then the camera sets its own position and rotation via:

code:

transform.position = rotation * offset + lookPoint;
transform.LookAt(lookPoint + Vector3.up * aimHeightOffset;

I'm having trouble coming up with why that would create this kind of jitter. I'm guessing it has something to do with the physics tick rate, but the player's rigidbody has interpolation enabled, so its position should be smooth.

# ? Feb 26, 2021 21:23

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Yeah you don't want to lerp because the target position is constantly moving.

It doesn't make sense to go 10% of the way from A to B and then next frame go 15% of the way from A to C and then next frame go 20% of the way from A to D, right?

So you gotta put a bit more thought into how the camera moves.

One approach is just keeping an array of the last few frames of positions and averaging them.

Another is you can subtract one vector3 from another to get a ray from one to the next, then normalize it, and then multiply it by a fixed length.

Then like I said as it moves you could potentially scale the fixed length so the camera accelerates and decelerates and give it more smooth motion like that.
Like store an internal camera velocity in each direction, and increase them over time, that sort of thing. Imagine there's two cameras, the locked one and a second which is constantly chasing the first one.

Zaphod42 fucked around with this message at 21:31 on Feb 26, 2021

# ? Feb 26, 2021 21:28

Firgof: Dec 27, 2009; The Librarian is pure.
Former Star Ruler 2 Dev.

TooMuchAbstraction posted:

So, that seems like it ought to be straightforward, but I'm getting absolutely terrible results. Like, this video shows a normal, non-laggy camera, and then it shows the "smoothed" camera:

https://i.imgur.com/M4nU6F9.mp4

All that I'm doing is this:
code:
lookPoint = Vector3.Lerp(lookPoint, player.transform.position, lerpFac);
(lerpFac is 1 at the start of the video, and .1 later when it goes all jerky)

Then the camera sets its own position and rotation via:
code:
transform.position = rotation * offset + lookPoint;
transform.LookAt(lookPoint + Vector3.up * aimHeightOffset;
I'm having trouble coming up with why that would create this kind of jitter. I'm guessing it has something to do with the physics tick rate, but the player's rigidbody has interpolation enabled, so its position should be smooth.

Is this Unity?

If so, you'll want to do the camera movement in the FixedUpdate() step rather than Update() if you want it to be exactly where the physics presently are. If you're not doing that already, I mean. If this is occurring in FixedUpdate() then I guess the Camera's pos-update is being called ... before the ship position update?

# ? Feb 26, 2021 21:39

Superrodan: Nov 27, 2007

Looking at that code, I'm a little confused on the logic of why the look point is being used at all in the formula to determine the camera's position. I would have guessed that the camera should update its position based specifically on the position of the boat, and its look vector should be determined by the look point.

# ? Feb 26, 2021 21:52

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Superrodan posted:

Looking at that code, I'm a little confused on the logic of why the look point is being used at all in the formula to determine the camera's position. I would have guessed that the camera should update its position based specifically on the position of the boat, and its look vector should be determined by the look point.

See the previous conversation that led up to this? He had it simply updating based on ship position but the problem was it was rocky. So you add some interpolation between current position and target position to make it smoother.

Firgof posted:

If this is occurring in FixedUpdate() then I guess the Camera's pos-update is being called ... before the ship position update?

I think that would result in consistent lagging behind the target or no problem at all, right? This kind of stair-stepping issue is something different.

I'm pretty sure its the lerp, lerp doesn't work for this.

# ? Feb 26, 2021 22:02

Firgof: Dec 27, 2009; The Librarian is pure.
Former Star Ruler 2 Dev.

Zaphod42 posted:

See the previous conversation that led up to this? He had it simply updating based on ship position but the problem was it was rocky. So you add some interpolation between current position and target position to make it smoother.

I think that would result in consistent lagging behind the target or no problem at all, right? This kind of stair-stepping issue is something different.

I'm pretty sure its the lerp, lerp doesn't work for this.

Not necessarily. Update() runs once per frame where FixedUpdate() can be run 0, 1, or tons of times per frame and is sync'd to physics updates (anything with kinematic transforms etc). It'd depend on your physics system settings and the present load on the system. I'd put it in FixedUpdate() anyway just because it's mean to follow a physics object, so it makes sense for it to move every time said physics object might move.

Could also be the lerp but I'd check that out just in case, unless you want camera updates to not be bound to when physics calcs are performed but rather independently of those calcs.

# ? Feb 26, 2021 22:10

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Thanks for the advice, y'all. Turns out this was something unrelated! The camera doesn't look directly at the player, but rather at a point in front of them. This keeps the view biased so that you can see more of what's in front of your ship. But I'd been doing it by adding player.transform.forward * distance to the point the camera looks at. And that forward vector could have a nontrivial Y component when the ship encounters waves, which meant that the point the camera was looking at was wobbling even moreso, thanks to the multiplier. By zeroing out the Y component of that vector, I fixed the wobble and now things are nice and smooth. After all, the player's motion in X/Z is typically smooth; it was just the waves that were giving me trouble.

Firgof posted:

Is this Unity?

If so, you'll want to do the camera movement in the FixedUpdate() step rather than Update() if you want it to be exactly where the physics presently are. If you're not doing that already, I mean. If this is occurring in FixedUpdate() then I guess the Camera's pos-update is being called ... before the ship position update?

Doing camera position updates in FixedUpdate is unwise, because it means that the camera will only update at whatever your physics tick rate is, which is frequently lower than your display update rate. It's a recipe for super jerky camera motion. This is why I mentioned that the player's rigidbody has interpolation turned on -- that causes its physics position to be updated even on non-physics frames. You can either interpolate (which AIUI smoothly blends the position based on the last two physics frames) or extrapolate (use the last physics frame and the rigidbody's velocity).

stealth edit: I guess if your physics rate is greater than your display rate then this isn't an issue, but that's not the case in my game. Physics is expensive enough that I have it running at less than 60Hz.

# ? Feb 26, 2021 22:17

Firgof: Dec 27, 2009; The Librarian is pure.
Former Star Ruler 2 Dev.

TooMuchAbstraction posted:

Thanks for the advice, y'all. Turns out this was something unrelated! The camera doesn't look directly at the player, but rather at a point in front of them. This keeps the view biased so that you can see more of what's in front of your ship. But I'd been doing it by adding player.transform.forward * distance to the point the camera looks at. And that forward vector could have a nontrivial Y component when the ship encounters waves, which meant that the point the camera was looking at was wobbling even moreso, thanks to the multiplier. By zeroing out the Y component of that vector, I fixed the wobble and now things are nice and smooth. After all, the player's motion in X/Z is typically smooth; it was just the waves that were giving me trouble.

Doing camera position updates in FixedUpdate is unwise, because it means that the camera will only update at whatever your physics tick rate is, which is frequently lower than your display update rate. It's a recipe for super jerky camera motion. This is why I mentioned that the player's rigidbody has interpolation turned on -- that causes its physics position to be updated even on non-physics frames. You can either interpolate (which AIUI smoothly blends the position based on the last two physics frames) or extrapolate (use the last physics frame and the rigidbody's velocity).

stealth edit: I guess if your physics rate is greater than your display rate then this isn't an issue, but that's not the case in my game. Physics is expensive enough that I have it running at less than 60Hz.

Fair points, all! Glad to hear it got cleared up. Still super excited for this game by the way. If you ever have a closed beta lemme know as I'd love to sign up.

# ? Feb 26, 2021 22:24

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Firgof posted:

Fair points, all! Glad to hear it got cleared up. Still super excited for this game by the way. If you ever have a closed beta lemme know as I'd love to sign up.

Hey, come on by the Discord and I'll add you to the beta testers group! The current build's a little out of date but I'll be putting up a new one once I get the next mission done.

# ? Feb 26, 2021 22:32

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

I spent this week working on a wrist-mounted VR UI. Feels pretty good and responsive now.

Adding little beeps and boops to acknowledge inputs really makes a world of difference on the perceived responsiveness.

Firgof posted:

Not necessarily. Update() runs once per frame where FixedUpdate() can be run 0, 1, or tons of times per frame and is sync'd to physics updates (anything with kinematic transforms etc). It'd depend on your physics system settings and the present load on the system. I'd put it in FixedUpdate() anyway just because it's mean to follow a physics object, so it makes sense for it to move every time said physics object might move.

Could also be the lerp but I'd check that out just in case, unless you want camera updates to not be bound to when physics calcs are performed but rather independently of those calcs.

Yeah I'd put it in FixedUpdate() or otherwise use the Time.deltaTime as a scaling factor on the distance, I just think that's a separate issue. But definitely worth doing.

TooMuchAbstraction posted:

Thanks for the advice, y'all. Turns out this was something unrelated! The camera doesn't look directly at the player, but rather at a point in front of them. This keeps the view biased so that you can see more of what's in front of your ship. But I'd been doing it by adding player.transform.forward * distance to the point the camera looks at. And that forward vector could have a nontrivial Y component when the ship encounters waves, which meant that the point the camera was looking at was wobbling even moreso, thanks to the multiplier. By zeroing out the Y component of that vector, I fixed the wobble and now things are nice and smooth. After all, the player's motion in X/Z is typically smooth; it was just the waves that were giving me trouble.

Nice!

# ? Feb 26, 2021 22:46

Omi no Kami: Feb 19, 2014

Spent this week screwing with dumbass realtime lighting stuff. Shadows are still garbled and weird, but it's nuts how long it took to get it even moderately okay-looking.

# ? Feb 27, 2021 07:51

Lork: Oct 15, 2007; Sticks to clorf

TooMuchAbstraction posted:

When ships in my game are going really fast, they kind of skip over the waves. This is cool and fine, but it does make the camera kind of jittery. I'm trying to figure out ways to smooth out the camera that wouldn't also reduce its responsiveness when the player wants to move it. That is, if I need to smooth out bumps that are on the order of 1/10th of a second, does that necessarily imply a 1/10th second of "input delay" between when you start moving the camera and when it responds? I feel like that could make controlling the camera difficult.

While you seem to have resolved the immediate issue, the question that came to mind when I saw this is: why does the camera need to care about the y position of your boat? Its height is only ever going to very slightly go up and down on a temporary basis, so it would be easy to have it orbit around a point that follows your boat on the xz axes but with a fixed height, and then you would never have to worry about it again. Just something to think about if you hadn't already.

# ? Feb 27, 2021 08:32

Adbot: ADBOT LOVES YOU

# ? Apr 19, 2024 10:05

Hel: Oct 9, 2012; Jokatgulm is tedium.
Jokatgulm is pain.
Jokatgulm is suffering.

Lork posted:

While you seem to have resolved the immediate issue, the question that came to mind when I saw this is: why does the camera need to care about the y position of your boat? Its height is only ever going to very slightly go up and down on a temporary basis, so it would be easy to have it orbit around a point that follows your boat on the xz axes but with a fixed height, and then you would never have to worry about it again. Just something to think about if you hadn't already.

This thread just a while ago did encourage them to add ramps you got jump your ship off, some there might have been a reason to care about elevation.

# ? Feb 27, 2021 09:20

The Something Awful Forums > Discussion > Video Games > Making Games Megathread: Congratulations on releasing the horniest game of 2022

«‹›1358 »