|
our engine just uses a brute force search with a fixed iteration count and some good initial guesses
|
# ? Apr 9, 2020 18:55 |
|
|
# ? May 26, 2024 18:40 |
|
Well, I don't want just any solution in this case, I want the solution with the smallest t that is greater than 0. I have previously implemented a similar quartic equation solve for a similar thing of calculating the moment at which two circles collide where they each have a position, velocity, acceleration and radius, because I was aiming to do a reproducible physics game (like a pool table but a more involved game), and to me it seems easier to just do that right the first time, with math, than to gently caress around with trying to handle all the piddling edge cases where things end up slightly overlapping or whatever. My system there was to calculate the minimum t where *anything* collides, then as long as the time hasn't reached t yet you can trivially calculate the position of every object in the game for many frames. It was a sparse environment, so you wouldn't ever have the horrible situation of like 50 objects crashing into a heap. Player actions that change the state were treated the same way as a collision, triggering a system recalculation after the action. Then when frame-time exceeds that "something changed" t, you change the initial state of every object to the new state immediately after that collision, and do all the collision calculations again to calculate a new t. Worked great, then I got distracted and never made the game. Very painful to do with any shape that can rotate though, so in my physics engine it was a requirement that everything be circles/spheres or non-rotating lines/planes. (Also it cleanly resolved the usually problematic tiny overlaps caused by floating point imprecision, because it only looked for collisions where things become intersecting, not collisions where they exit each other's radius. Though there was a tiny tiny chance that two separate collisions at the exact same moment could lead to the newly calculated positions of everything after the first collision containing the two objects that weren't involved in that collision already overlapping by a floating point imprecision amount, which would then allow them to pass through each other. That's fixable too, but it never came up so I didn't.)
|
# ? Apr 10, 2020 00:42 |
|
nickmeister posted:Great, I'll look into that. I did some googling about python, text-based games, etc. But the only solution I could find on my first search is "...ooh.. I don't know? multithreading? but multithreading is actually bad? uh..." Yeah you probably want to go ahead and do a client/server model if you want a real solution and to be able to get on your way with making the fun game stuff. Ran across this nice little https://github.com/Frimkron/mud-pi server that really takes all the networking and nonblocking input stuff out and leaves you with a really simple skeleton to start your mud! It's really nice and straightforward, check it out: code:
|
# ? Apr 11, 2020 23:16 |
|
I'm playing around with Compute shaders in Unity and am currently passing a large array of uints into the shader as a ComputeBuffer. I need to send 3 floats into it too though and thought I'd try and be clever and just encode them into the already existing array rather than introduce more buffers. So I tried to encode them with:code:
code:
Weirdly if I do: code:
Anyone got any idea why asfloat doesn't seem to be doing what I expect. Or any tips on debugging shaders generally?
|
# ? Apr 12, 2020 02:41 |
|
What is the type of Bounds.Min? Vector3?
KillHour fucked around with this message at 06:06 on Apr 12, 2020 |
# ? Apr 12, 2020 05:59 |
|
kaffo posted:+1 for PID controllers. You can spend ages tweaking them, but once you put in the right magic numbers some sorcery happens and everything becomes butter. Totally not ashamed to admit I learned a lot about pratical PID in From The Depths. Then you bump the enclosure and introduce a permanent steady-state error.
|
# ? Apr 12, 2020 07:13 |
|
Spek posted:Or any tips on debugging shaders generally? Use Renderdoc, it's a godsend for debugging GPU stuff on Windows and Android.
|
# ? Apr 12, 2020 11:59 |
|
KillHour posted:What is the type of Bounds.Min? Vector3? Yeah, I should have mentioned that.
|
# ? Apr 12, 2020 18:41 |
|
Spek posted:Yeah, I should have mentioned that. Can you share the code where you're making your buffer? My understanding of compute buffers is that they don't care what data is inside them as long as they all have the same stride - you shouldn't need to convert a float to a uint before adding it to the buffer.
|
# ? Apr 12, 2020 21:55 |
|
KillHour posted:Can you share the code where you're making your buffer? My understanding of compute buffers is that they don't care what data is inside them as long as they all have the same stride - you shouldn't need to convert a float to a uint before adding it to the buffer. I'm converting it to a uint because the array I use to create the compute buffer is a uint[], but the value itself needs to be a float. Is there just a better way of doing this? My thought was getting the uint that has the same bit/byte layout as my float and then treating it as a float in the shader should work. I just don't know why it doesn't. I've never written a compute shader before and am basically just learning by a few references and the incredibly sparse Unity documentation. So I'm quite probably doing things terribly wrong. I'm creating a sparse voxel octree on the GPU to run marching cubes against: code:
|
# ? Apr 12, 2020 22:52 |
|
nickmeister posted:Great, I'll look into that. I did some googling about python, text-based games, etc. But the only solution I could find on my first search is "...ooh.. I don't know? multithreading? but multithreading is actually bad? uh..." I've been using https://github.com/twisted/twisted for a similar project, client-server online game, not text based though. Twisted has modes of configuration for running off a variety of i/o types (select, epoll, etc). As a networking engine it implements the reactor pattern which I thought was very intuitive to code in, as an extremely novice game dev. My project is an electron client that talks to a twisted server over udp, it was pretty trivial to get something set up and handling udp input is as simple as defining a datagramReceived function and parsing whatever data the client sends. In my case I am just sending json blobs packed with msgpack, so in the receiver function I just unpack and dispatch. Since it's a multiplayer game you'll almost certainly need a "normal" event loop, twisted has a cooperator class which has some options for running both twisted's networking loop and your own game loop.
|
# ? Apr 13, 2020 18:48 |
|
Well I still have no idea what I was doing wrong but after a couple days break I realized I was needlessly complicating things anyway and didn't need to those values in the shader I'm running the marching cubes algorithm in chunks so I go through each voxel and on the positive-side border voxels I need to query their neighbours to figure out what the border of the chunk will look like. I was passing in the size of the chunks to calculate the offset for when I looked into the neighbours' octree. Then I realized if I'm querying the neighbour node I always want the position to be 0 in that chunk. IE if I'm checking the X neighbour I always want the x value I check to be 0. If I'm checking the XZ neighbour I always want both x and z to be zero and so on.
|
# ? Apr 18, 2020 17:54 |
|
Does anyone know of some video lessons that teach how to make FPS or RTS games in Unity with best practices that assumes I already know how to code? I bought a few on Udemy, but it seems they all go through the basics of coding and end up being 80+ hours.
|
# ? May 1, 2020 10:23 |
|
Boz0r posted:Does anyone know of some video lessons that teach how to make FPS or RTS games in Unity with best practices that assumes I already know how to code? I bought a few on Udemy, but it seems they all go through the basics of coding and end up being 80+ hours. Are you looking for the programming specifics, or how to make them fun/enjoyable? For RTS, most of the problems are unit nav, micro combat, and macro decisions. Most of that stuff is covered in GDC talks from the AI summit or the game ai pro and ai game programming book series. Also check out the article on the network stuff for agree of empires 2. FPS is going to have a lot more resources generally; lots of available content on the GDC vault. None of the technical talks will cover making them fun. It's very easy to make a mechanically competent game that's frustratingly boring. I don't have great insight into how to solve that, but there may be something on combat balance on the vault as well.
|
# ? May 1, 2020 12:15 |
|
What kinds of processes or design styles are used in the professionally for programming teams? Is it the same as other engineering shops or is it radically different? For context, my partner is pushing me to get back into things with some simple projects but also wants me to do things more seriously than just cobble things together. She's been hitting me with slides from her grad level comp/elec engineering design courses, human-computer interaction diagrams, and other things that I barely understand. I do trust that she knows what she's talking about*, but I feel like game dev is unique and doesn't fight those paradigms. I do doubt that the later is the case, but if game dev does work on a different schedule of things, what would that be? *She's regularly does screening of candidates and following good design processes is literally her screen.
|
# ? May 2, 2020 05:19 |
|
BirdOfPlay posted:What kinds of processes or design styles are used in the professionally for programming teams? Is it the same as other engineering shops or is it radically different?
|
# ? May 2, 2020 05:35 |
|
There's a very wide range of engineering maturity in game development, even among high-profile professional outfits.
|
# ? May 2, 2020 06:17 |
|
Bongo Bill posted:There's a very wide range of engineering maturity in FTFY
|
# ? May 2, 2020 06:49 |
|
roomforthetuna posted:I've worked for three game companies and none of them had a single automated test (no unit test, no integration test, no end-to-end test), but it was over 20 years ago so that might have changed. They also didn't have any sort of diagrams in their design process, just concept art, final art, and level design. One game I worked on had some automated testing, and I don't think it ever found a single useful thing that wouldn't have been immediately obvious to everyone on the team (like on the level of "someone broke the main menu and you can't start a game"). Despite its extremely basic testing, it still broke all the time as the game was being developed and required programmers to spend time getting it running again.
|
# ? May 2, 2020 06:49 |
|
I like how all of y'all immediately started talking about testing. Does this subject and testing just go hand-in-hand?roomforthetuna posted:I've worked for three game companies and none of them had a single automated test (no unit test, no integration test, no end-to-end test), but it was over 20 years ago so that might have changed. They also didn't have any sort of diagrams in their design process, just concept art, final art, and level design. I freelanced for a bit, and the closest I got to a code review was someone going "ayup, don't know what else to say." Part of me assumes that in a professional setting it would be different, but maybe not?
|
# ? May 2, 2020 07:42 |
|
I'm not sure how to interpret "processes or design styles". There's no rigorous single process for game development, other than lots of producers hitting people with hammers to get the game to come together after it's out of prototyping and onto full production. On the subject of testing, we have testing for our low-level utilities (math, vfs, some file formats, string utils, memory allocators, data structures, you know, the basics every game engine has at the bottom somewhere), but very little above that. It's caught a few bugs, and isn't too difficult to maintain. For code that changes a lot, has lots of "emergent gameplay" consequences and has no clear testable outcomes, like camera and AI code, I can't even think how a testing methodology would come into play. Maybe something in the form of League of Legend's test framework, but they clearly have different requirements than most game developers.
|
# ? May 2, 2020 07:49 |
|
ECS is the only architecture I've seen that I've only seen in games. Lots of the less gifted engineering teams rely on singletons for basically everything because someone read gang of four and somehow picked up that singletons are good (they are, but for things like memory mapped IO or other things with physical limitations). If anyone has been struggling with a way to address that, make a wrapper for the thing that doesn't have a public accessor. After you've converted all uses of the singleton, refactor the wrapper to instead use local state -- now the only thing left is to address any lifecycles issues where you were just creating new instances of the wrapper and relying on its implementation being a singleton; you can find these by logging the call stack in the constructor. Process-wise it's basically the same as the wider computing industry. For better and worse.
|
# ? May 2, 2020 11:37 |
|
leper khan posted:Lots of the less gifted engineering teams rely on singletons for basically everything because someone read gang of four and somehow picked up that singletons are good (they are, but for things like memory mapped IO or other things with physical limitations). If anyone has been struggling with a way to address that, make a wrapper for the thing that doesn't have a public accessor. After you've converted all uses of the singleton, refactor the wrapper to instead use local state -- now the only thing left is to address any lifecycles issues where you were just creating new instances of the wrapper and relying on its implementation being a singleton; you can find these by logging the call stack in the constructor. This always makes me feel like a fool but I've been programming games for over a decade and I still don't get what problems singletons are supposed to cause, and nothing I've read on the subject has helped me understand. Like, say I've got an enemy that can shoot big fireball projectiles and I decide I want to make them cause some screen shake when they explode. I have naively set up my camera as a singleton so in the fireball projectile's OnHit function I call GameplayCamera.Instance.ApplyScreenShake(shakeAmount, shakePosition). Or maybe ScreenShakeHandler.Instance.ApplyScreenShake if I have it split out like that. But this is bad, and is going to cause me deep regrets later? What advantages are to be had from doing it differently?
|
# ? May 2, 2020 23:15 |
|
There's two radically different complaints about singletons. One camp says they're bad because those people are still (still!) OOP purists. They will lampoon you about reusability, in case for example you wanted two cameras in the future. The other group don't like singletons, for one of the same reasons they don't like OOP in the first place, which is that there's no reason to have any class instance at all. They go cross eyed trying to listen to you about why you need a class instance of something there is only one of.
|
# ? May 2, 2020 23:54 |
|
The singleton pattern as traditionally described mitigates some of the pains that accompany the introduction of global state, but it's still introducing global state. Intuitively, it seems to make sense that there'll only ever be one screen and one camera to which shaking should be applied so it's no biggie, but that assumption won't always hold true. Specifically, if you want to test that fireball collision code, it is useful for there to be no screens or cameras, just a mock. More generally, the problem isn't that you have only one GameplayCamera; the problem is that your fireball collision method acquires a reference to it by calling GameplayCamera.Instance. Dependencies should be injected. In object-oriented terms, make it a constructor parameter. Your fireball collider know that it needs something that can be made to shake when the fireball explodes, but it shouldn't be responsible for knowing or caring where that something comes from. Dependency injection frameworks often use the term "singleton" to refer to dependencies which the framework knows not to create more than one of, which is a cleaner way to handle it. Code grows in complexity more slowly when you minimize the incidence of a method referring to any value that wasn't provided as a parameter either to the method itself or to the constructor of the owning class.
|
# ? May 3, 2020 00:03 |
|
Triarii posted:This always makes me feel like a fool but I've been programming games for over a decade and I still don't get what problems singletons are supposed to cause, and nothing I've read on the subject has helped me understand. Two things I can think of: What if the user moves your application to another screen, and that screen is controlled by another graphical device? What if the user turns on VR? Then off again?
|
# ? May 3, 2020 00:07 |
|
Bongo Bill posted:More generally, the problem isn't that you have only one GameplayCamera; the problem is that your fireball collision method acquires a reference to it by calling GameplayCamera.Instance. Dependencies should be injected. In object-oriented terms, make it a constructor parameter. Your fireball collider know that it needs something that can be made to shake when the fireball explodes, but it shouldn't be responsible for knowing or caring where that something comes from. I see this line of reasoning a lot, but any time I've tried it in practice I end up with code that's much harder to work with. Like, the fireball would need to be passed a camera reference by the enemy that spawns it, which would need it passed from the building that spawned the enemy, which would need it passed from the enemy base generator that spawned the building. Now I've got a bunch of classes with references to a camera that didn't care about it before. And then the next day a designer says "the screen shake's terrible, remove it" and I have to decide whether to leave all that in place in case we need it again someday, or try to be tidy and clean it up (while checking whether someone else has started using it for other functionality in the meantime). And that's just for the screen shake - the fireball might need references to a bunch of other objects to play sounds and whatnot as well, to the point where most of the code of some classes is entirely concerned with passing dependencies around. Absurd Alhazred posted:Two things I can think of: Ideally that would all be handled privately by the GameplayCamera - maybe it's shuffling its internal state around like mad but the fireball doesn't need to concern itself with that.
|
# ? May 3, 2020 00:51 |
|
The fireball doesn't need to own the logic for handling what happens when it explodes. The fireball can just be data, and the logic can live elsewhere.
|
# ? May 3, 2020 00:53 |
|
each fireball has it's own compressed neural net for control and explodey purposes
|
# ? May 3, 2020 01:33 |
|
This is why composition is normally preferred over inheritance in game design and everyone eventually settles on ECS to do that. The "better" pattern is i to have a the fireball spawn an explosion entity on hit and the system that cares about screen shaking iterates over all the explosion entities to do so.
|
# ? May 3, 2020 01:56 |
|
I enjoy that all the reasons for not using a singleton (or global state) that have just been given sound completely awful from the perspective of game development. If you want to test your fireball screen shaking explosion code in game dev, you throw a fireball and see that it does what you want. Making your code more complicated and verbose so you can use dependency injection to let the fireball know about the function it needs to call so you can unit test a visual effect, which is a type of unit test that is a giant pain to write and 99% of the time is worse than useless (because now you have to also update the test every time you alter the effect slightly, so it creates more work, and it literally never catches something you wouldn't have noticed immediately without a test) just sounds ridiculous. The point of "what if you want to have two screens later" is almost valid, except the work of moving the code from a singleton to something else later if you need to takes like an hour and five minutes if you do it later, vs. an hour if you do it now. So if it turns out you didn't ever need it, you wasted an hour, and if you go the other way and it turns out you did need it, you only wasted five minutes. You almost never turn out to want something later that you didn't plan to want now, since in game dev you're more likely to remove features from the plan than you are to add them, so making it extensible "just in case" is a loving terrible bet. The only slightly reasonable reason to avoid singletons in games is that it's easier to reason about code that you know can't do anything it hasn't explicitly been provided an interface to do. But even that is still bullshit because you always end up giving all the code access to loads of poo poo it needs to do, so now it's basically just as hard to reason about and now it's hard to read and write because everything has a ton of constructor parameters of dependencies that are each used once - and anything that needs to construct one of this thing now also needs all the same dependencies. With singletons you instead can have a zero parameter constructor and it just calls the things it needs. The "reason about it" rationale makes sense in something really critical like a space shuttle control system, where you need to be extremely careful and 100% validate every piece of code and people are independently writing modules so the ability to reason about your part is vital, but for games it just means you're creating a bunch of unnecessary work for yourself (and others). The fireball is a great example, imagine you have the gun that fires a fireball, that doesn't need to do anything with the screen, but now it's dependent on the screen controller so it can call the fireball's constructor (or it needs to be given a fireball factory, which either comes from a singleton or you have to have another layer of complicated routing system to provide factories to things). tl;dr: KillHour's point is right, basically.
|
# ? May 3, 2020 04:36 |
|
Yeah, that's true. Games are inherently massively stateful and have tons of side effects. The usual arguments against singletons are about why you shouldn't be using them with object-oriented design, and object-oriented design is problematic for games for other reasons.
|
# ? May 3, 2020 06:56 |
|
You can definitely untangle global state later, but it can be annoying to do so. I tend to consider reusability an overstated trait of code, I'd rather simpler code that can be copied and changed; often times "direct" reuse is not helpful, especially if it complicates the system in the process. "Dependency injection" often seems like a crazy idea to me. Apparently passing arguments to constructors was too difficult so we built a system to automate passing arguments, and now debugging anything is 6x the hell.
|
# ? May 3, 2020 07:03 |
|
Absurd Alhazred posted:Two things I can think of: How are either of these related to the GameplayCamera? Ideally this is just a math class that can build proper view and projection matrices. Screens shouldn't matter here.
|
# ? May 3, 2020 07:05 |
|
This is why I like to use events. The fireball example above I wouldn't put any screenshake code in there at all, I would just emit a 'fireballExploded' event with appropriate data attached and anyone who wants to subscribe to that can do so. So I'd have a function in the camera to listen for the event and shake.
|
# ? May 3, 2020 07:50 |
|
I'm down with the whole ECS but there is some cases where it doesn't work for me.. or at least I haven't found good ways of dealing with in the way that ECS wants you to deal with it. For example the "player" class. I often find that the player class is always a huge mess because there is a lot of complicated state machine things going on, timing things going on, controller heavy code. So what I end up doing is making a system dedicated just for the player that ends up querying a ton of components because yes I need them all right now. So the 'update' doesn't really end up looking that much different from a player class from OOP.
|
# ? May 3, 2020 08:18 |
|
xgalaxy posted:I'm down with the whole ECS but there is some cases where it doesn't work for me.. or at least I haven't found good ways of dealing with in the way that ECS wants you to deal with it. I would probably make _several_ systems that only get used for what I would normally put in a player controller.
|
# ? May 3, 2020 11:26 |
|
xgalaxy posted:I'm down with the whole ECS but there is some cases where it doesn't work for me.. or at least I haven't found good ways of dealing with in the way that ECS wants you to deal with it. ECS and OOP aren't incompatible or anything, as long as you have a clear idea of what each format will handle it can be extremely helpful to use both simultaneously, with ECS preventing inheritance bloat and OOP preventing component bloat.
|
# ? May 3, 2020 11:56 |
|
I do find it out hard to comprehensively unit test my project in Unity and gave up on that notion, but there are a few integration tests I can run to make sure I'm not completely hosed. I get the impression the Unity Test Framework has a lot more to it than I'm even thinking of using and I could very well be testing a lot more in-game logic with it, but I've been finding most bugs in layers below that. If it's completely misbehaving, at least I have an idea of where. Most of the stuff that I've managed to pack away into separate projects have a pile of unit tests piled on to them; stuff that can be separated like that tends to be stuff that can be made into neat little things that are easier to test. I kept screwing up some important parts of working on levels in the scene editor so I made a little editor GUI to run checks and tell me what I screwed up. I guess that's different from code tests though. My major bug is that I'm doing all this stuff instead of finishing a game. leper khan posted:ECS is the only architecture I've seen that I've only seen in games. quote:Lots of the less gifted engineering teams rely on singletons for basically everything because someone read gang of four and somehow picked up that singletons are good
|
# ? May 3, 2020 13:13 |
|
|
# ? May 26, 2024 18:40 |
|
roomforthetuna posted:The point of "what if you want to have two screens later" is almost valid, except the work of moving the code from a singleton to something else later if you need to takes like an hour and five minutes if you do it later, vs. an hour if you do it now. So if it turns out you didn't ever need it, you wasted an hour, and if you go the other way and it turns out you did need it, you only wasted five minutes. You almost never turn out to want something later that you didn't plan to want now, since in game dev you're more likely to remove features from the plan than you are to add them, so making it extensible "just in case" is a loving terrible bet. Unmaintained, untested, unused code paths are extremely prone to software rot.
|
# ? May 3, 2020 20:24 |