Making Games Megathread: The Normals are Stored in the Balls

The Something Awful Forums > Discussion > Video Games > Making Games Megathread: The Normals are Stored in the Balls

«‹›1363 »

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

TooMuchAbstraction posted:

I spent today working on implementing superstructures for my ships. Superstructures are basically buildings that go on the deck to provide internal spaces for whatever -- radar, fire control, damage control, etc. In my game what they do is provide a "volume" stat that can be used to purchase such systems, so e.g. a level-2 radar room might require 100 volume and give a radar range of 300m. To reduce the fiddliness for placing them and make them a bit more realistic-looking, I allow them to intersect with bridges and smokestacks, at the cost of reducing the amount of volume they provide based on the degree to which the parts' bounding boxes intersect.

The big problem I have with this first-pass implementation is that you can basically overwrite the bridge with a big blocking superstructure, which looks ugly:

If you missed it, the bridge is a bit left of middle on the ship.

I'm not sure if this is actually a gameplay problem though -- you have to pay full price for the mass of the superstructure, while getting little benefit in terms of usable volume. It just looks ugly. I guess I could mitigate it by limiting the height of superstructures that I allow to intersect with things like bridges, but that sounds irritating to implement and hard to communicate to the player. I could also only allow bridges to be placed on top of superstructures, not intersecting them, but then you need to find a single superstructure block that's big enough to provide a base for the entire bridge (a part can't be supported by two other parts, only by one).

Any ideas or opinions?

Wow you're really building the armored core of battleships huh (looks great now that they're less flat!)

I wonder if that isn't too fiddly and it wouldn't be better to just have a selection of superstructures that each come with a single function or a package configuration. But it depends on the focus of the game, being fiddly could be fun, building and tweaking the ultimate battleship almost like kerbal space program or something?

I would generally say KISS - keep it simple, stupid. Like, the bridge, I would just have the bridge be a default structure on the ship that you can't interact with. Its a core component. Superstructure add-ons would be placed around it and not intersecting. Then you can personally design a bridge structure that looks cool and has whatever reasonable base volume makes sense or something.

The important bit here is to make sure that choices are meaningful choices. I think "do you want all guns or half guns and half radars" sounds cool, but "just make sure you don't do too much X and balance your volume with Y" just sounds like busy work more than meaningful fun play choices. Does that make sense? But again, different types of games appeal to different people in different ways so its really hard to say :sweatdrop:

# ? Sep 28, 2019 01:32

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 14:17

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:

Wow you're really building the armored core of battleships huh (looks great now that they're less flat!)

I wonder if that isn't too fiddly and it wouldn't be better to just have a selection of superstructures that each come with a single function or a package configuration. But it depends on the focus of the game, being fiddly could be fun, building and tweaking the ultimate battleship almost like kerbal space program or something?

Yeah, customizing your warship is basically half the game; the other half is taking it out on missions. I want the customization to be accessible, but I also want it to be reasonably involved. I think the best way to achieve that is to have a number of factors that the player has to keep balanced, but each factor does something straightforward. So like, the things you can "buy" ship upgrades with are displacement, volume, and deck space. You can buy more volume by trading in displacement (superstructure has mass) and deck space (superstructure takes up space). You can buy more armor by trading in displacement (armor has mass). You can buy more weapons by trading in displacement and deck space. And so on. Balancing those competing needs is the main puzzle of the ship designer.

Early on (maybe a month or two ago) we discussed, in this thread, having dedicated "rooms" for particular functions, so like there'd be a radar room you could build, or a sonar room. This was before I'd committed to having superstructure be a thing, and I was contemplating having the player have to place the rooms inside of the hull, which definitely would've been too fiddly. Imagine playing a 3D jigsaw puzzle. Conceivably I could have superstructure rooms that each have dedicated purposes...but I think it'd probably still be more fiddly than I'd like. The nice thing about having a generic volume stat that you use to buy upgrades is that I can just provide a set of generic rooms of various shapes, let the player figure out how to arrange them effectively (or to suit their aesthetic desires), and then they can buy whatever with the volume. If each room has a dedicated purpose then I have to make a bunch of differently-shaped rooms, and decide how effective they should be (how much do I boost the radar range of this room which is the next level up from the previous room but also kind of awkwardly-shaped?).

quote:

I would generally say KISS - keep it simple, stupid. Like, the bridge, I would just have the bridge be a default structure on the ship that you can't interact with. Its a core component. Superstructure add-ons would be placed around it and not intersecting. Then you can personally design a bridge structure that looks cool and has whatever reasonable base volume makes sense or something.

I hadn't considered baking the bridge into the hull. The game I'm using for inspiration doesn't do that, and I think it introduces some neat aesthetic and design options to be able to move it around. Like, you can make an "all forward guns" ship where you have a three-deep array of turrets overfiring each other, with the bridge pushed about as far astern as it can be while still physically fitting on the deck.

That said, it sounds like you're in favor of not having the superstructure overlap the bridge. I can understand that. I think I need to do more ship designs using superstructures so I can get a feel for what looks good.

quote:

The important bit here is to make sure that choices are meaningful choices. I think "do you want all guns or half guns and half radars" sounds cool, but "just make sure you don't do too much X and balance your volume with Y" just sounds like busy work more than meaningful fun play choices. Does that make sense? But again, different types of games appeal to different people in different ways so its really hard to say

Oh sure, absolutely you want meaningful choices. I think that meaningful choices will come from finely balancing the relative costs of all the different parts, more than anything else. Odds are the player will want as little superstructure as they can get away with, since superstructure isn't more guns...but how valuable is dedicating some rooms to an autoloader that increases your rate of fire, or an advanced fire control system that helps you aim? And you'll want to dedicate some space to radar and sonar (though I will almost certainly bake those into the bridge to some extent, since playing without them whatsoever would likely not be fun).

Warship Gunner 2's approach to this was to not have superstructure at all, and instead each ship had a set of slots for miscellaneous systems, with the number of slots depending on the ship class. It was a simple and gamey system, and worked fine from a gameplay perspective, but I want superstructure for aesthetic reasons as much as anything else, and feel like it should do something to encourage the player to make use of it. I guess the trick is to make it so the player doesn't feel like superstructure is a tax they have to pay on their ship to get what they want.

# ? Sep 28, 2019 04:52

Omi no Kami: Feb 19, 2014

When building low-poly characters, is it generally preferable to minimize vertices, or to preserve symmetry? Like, here's a really crude waist and upper body:

I'm going to need a bunch of (comparatively) complex geometry around the sternum and clavicle to show the contours of the upper chest, but since this is a low-poly figure I actually want everything below the ribs to be as flat as possible, so I can paint in abs or ribs or skin or whatever. My natural impulse is to add a vertical edge loop and only futz with the top half of it, but that means I essentially have an unused edge around the lower ribs and stomach, and a matching one on the back.

So I should be using a knife to specifically cut more complex edges in around the chest and collar, or is it better to do what I've been doing and keep everything super-duper symmetrical at the cost of having some wasted edges?

# ? Sep 28, 2019 07:43

Your Computer: Oct 3, 2008; Grimey Drawer

Chev posted:

See, that's a good thing! Look at it like this: when the filtering had thresholds you immediately noticed because it felt jarring. Preventing people from noticing is the whole point!

Congrats on making it work!

I guess that's true huh :sweatdrop:

thanks!

It turned out that CalculateLevelOfDetail returns an already floored value so I had to calculate the mipmap level manually, but since you already mentioned the ddx/ddy stuff I thankfully knew what to google. Not gonna lie the function is like black magic to me, but it works and I get the same lod value (+ fraction!) so I'm happy :v:

Omi no Kami posted:

When building low-poly characters, is it generally preferable to minimize vertices, or to preserve symmetry? Like, here's a really crude waist and upper body:

I'm going to need a bunch of (comparatively) complex geometry around the sternum and clavicle to show the contours of the upper chest, but since this is a low-poly figure I actually want everything below the ribs to be as flat as possible, so I can paint in abs or ribs or skin or whatever. My natural impulse is to add a vertical edge loop and only futz with the top half of it, but that means I essentially have an unused edge around the lower ribs and stomach, and a matching one on the back.

So I should be using a knife to specifically cut more complex edges in around the chest and collar, or is it better to do what I've been doing and keep everything super-duper symmetrical at the cost of having some wasted edges?

I think it will depend on how low poly you're making something. Clean edgeloops are nice, but generally you don't want to waste polygons when you're doing low poly stuff. To figure out if something is wasteful, I always ask myself these two questions - 1) does it aid in creating shape and 2) does it aid in deformation? Anything else is wasteful when you're trying to squeeze something down to as few polygons as possible.

Likewise, don't worry about triangles. When you're working with high poly meshes you generally want to keep things in quads for good edgeloops and clean topology (still with the intent of creating shape and aiding deformation), but when you're working on a low poly mesh you don't have the luxury of keeping everything in quads. In your example, it would make more sense to add extra edges to the top of the mesh while keeping the bottom the same (introducing some triangles at the border between them), rather than adding a whole lot of polygons just for the sake of keeping everything in quads :v:

speaking of low poly, now that I've gotten my filtering sorted out I've gone back to doing some more 3D modeling and I started working on this low poly skele (with some vertex paint)

it's at 709 tris right now, but there's a lot I could optimize still. I figure it could serve as a nice and easy to animate placeholder player :skeltal:

# ? Sep 28, 2019 10:18

Chev: Jul 19, 2010; Switchblade Switcharoo

Your Computer posted:

It turned out that CalculateLevelOfDetail returns an already floored value so I had to calculate the mipmap level manually, but since you already mentioned the ddx/ddy stuff I thankfully knew what to google. Not gonna lie the function is like black magic to me, but it works and I get the same lod value (+ fraction!) so I'm happy

Ah, didn't know that about calculateLod, the docs are pretty inconsistent. Not that it matters since you got it working anyway.

The ddx and ddy functions are easily some of the trickiest functions to understand in shader languages, because they kinda break the usual rules. Normally in a pixel shader you cannot access data from a neighboring pixel, you always work on a pixel shader in isolation and if you want a neighboring value you have to get it from a texture you rendered earlier. The ddx and ddy functions are the exceptions to that, they give you the difference in a given value between your pixel and an adjacent one in the horizontal (ddx) or vertical (ddy) direction. There are some quirks to it so you can't use it for, say, edge detection or anything like that, it's specifically intended for getting derivatives, ie rate of change of values over a single polygon's surface.

When measuring that on UVs, the length of ddx or ddy (whichever is biggest) gives you the maximum rate at which your texture coordinate is changing from the current pixel to its neighbors. The idea of mipmapping is that rate of change needs to be less than the texel size of the current mipmap. If it is bigger, it'll "miss" texels in-between two pixels, the phenomenon called aliasing which we seek to avoid by using mipmaps. Since we know the formula to get the mipmap index from the texel size, we just apply the same formula to that rate of change to get the desired mipmap level or combination thereof.

There, that was most of the details you don't need to know.

Chev fucked around with this message at 12:37 on Sep 28, 2019

# ? Sep 28, 2019 12:26

Incrediblastic: Oct 29, 2010; I eat food.

Sorry If I seem to be tooting my own horn a alot with posting my progress without contributing to the ongoing discussion,but I haven't used a single shader in my life and don't know poo poo about battleships.That skelington is hella cute though.

So since I found out that coding games is a good way to escape existential dread,I signed up for the weekly game jam-this week's theme is "Crazy Golf" and of course my mind went the :science:

route.I now have prototype of a 2d top-down golf game where you manipulate the very equations of physics to make the obstacles exert forces that are beneficial to you and use that as the golf club.To play you press and hold a button to temporarily turn on your force field and that counts as one par (IDK if that's the correct wording). Obligatory screenshot:

Since my mistake with my previous game was that I made it too difficult,I'm worrying that this also isn't meant for normal human people.But I have fun testing it and programming games are a thing ,so maybe there's a whole handful of people who would like a math programming game.

Also,Godot is starting to feel like the python of game engines - There's a base expression class,so implementing the main mechanic was literally 'import antigravity'. And using it in general feels python-esque somehow.

# ? Sep 28, 2019 13:22

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

Incrediblastic posted:

Sorry If I seem to be tooting my own horn a alot with posting my progress without contributing to the ongoing discussion,but I haven't used a single shader in my life and don't know poo poo about battleships.That skelington is hella cute though.

Look at this goon, not contributing to the conversation when they don't know anything about the topic. :v:

More seriously though, while technical conversations are hard to contribute to without understanding the underlying stuff, pretty much anything else is fair game for you to inject your opinion. It's entirely possible you'll be ignored, but also entirely possible that you'll poke some brain cells in the right direction to come up with a clean and elegant solution.

Also don't worry about using this to post progress updates. It's not like you're spamming the thread. And your game idea sounds cool! I bet you could make it accessible if you spent enough time tweaking the UI. All games are impenetrable in the prototype phase; hell, my game's basically impossible to interact with without knowing the control scheme, which is not documented anywhere. What exactly does "manipulate the equations of physics" mean though? Like, F=m_1 * m_2 * G / r^2, what part(s) of that can I change?

# ? Sep 28, 2019 14:35

Your Computer: Oct 3, 2008; Grimey Drawer