|
Return to binary input. Assign one team to 1, another to 0. Each individual team has to work together to decide when it is appropriate to input their bit, and they have to work together to decide what the sequence of input is.
|
#
?
Jul 12, 2023 20:31
|
|
|
|
| # ? May 9, 2024 21:59 |
|
|
Pollyanna posted:Video games can involve some very complex, high level logic and architecture. How do you handle that with C, and how does that differ from app development’s requirements? Keeping this a bit brief, since I'm at work atm, might try to expand on it later. The reason I wouldn't want to do non-game app development in C is mostly that there are decent frameworks in other languages that make things simpler, and apps generally don't need the performance of games. The framework bit’s also true for games, but I actually enjoy writing the lower-level stuff there, and I was talking about what I use when programming for enjoyment. At my real job - also in games - we use C++, and after using it for over 20 years, I'm pretty sick of the relative complexity and cognitive load. Most of the C++-y stuff I need can be accomplished with function pointers and macros if it's actually necessary. C was used for games before C++ was, and it's been used for entire operating systems. It's not incapable of handling complexity. There are definitely things C++ makes easier, but I prefer the simplicity of C when programing for fun. Macichne Leainig posted:I'm also curious, do you do your own engine kind of stuff? I was reading about how the dev for HROT wrote his own engine for that in Pascal and it gives me some serious impostor syndrome because most of what I do is UI mockup garbage (i.e. not even functional half the time) Yeah, in my personal projects I've started doing my own engine-level stuff since the available engines all annoy me in one way or another, though as mentioned, it's for fun. If I was actually trying to ship something in a reasonable amount of time and make money, I'd likely use an off the shelf engine and whatever language that required, and deal with the annoyances. chglcu fucked around with this message at 20:41 on Jul 12, 2023 |
|
#
?
Jul 12, 2023 20:36
|
|
|
I mostly do microcontroller programming. Everything is still small and close to the metal, but now with 32-bit ARM cores and dozens of kbytes of memory, so not totally cramped. C and (simple) C++ feel just right for this environment.
|
|
#
?
Jul 12, 2023 21:57
|
|
|
I tried doing game dev as a hobby but quickly realized that I don’t have any good ideas. 
|
|
#
?
Jul 12, 2023 22:21
|
|
|
Pollyanna posted:I tried doing game dev as a hobby but quickly realized that I don’t have any good ideas. You can just remake existing ideas. It's a hobby, you're allowed to be unoriginal. 
|
|
#
?
Jul 12, 2023 22:23
|
|
|
NO 
|
|
#
?
Jul 12, 2023 22:24
|
|
|
I constantly dabble in game making, but I also refuse to learn any existing engine so my project folder is littered with half written game engines.
|
|
#
?
Jul 12, 2023 22:59
|
|
|
I’ll be hosed if I write a game engine, that poo poo takes entire divisions.
|
|
#
?
Jul 12, 2023 23:09
|
|
|
Writing a general purpose engine does, yeah. Writing only what you actually need for a given game and then building on it in the future, while still a lot of work, is doable, though.
|
|
#
?
Jul 12, 2023 23:11
|
|
|
You start simple, with a square moving around a 2d map, then you just gradually add in the 3rd dimension and more polygons until you've recreated UnReal. That is how a demo becomes a product!
|
|
#
?
Jul 13, 2023 00:24
|
|
|
chglcu posted:Writing a general purpose engine does, yeah. Writing only what you actually need for a given game and then building on it in the future, while still a lot of work, is doable, though. Yeah, I'm not writing like Unity here. I'm writing like the foundation of a very specific games supporting a narrow set of features but never actually making content beyond placeholders for testing.
|
|
#
?
Jul 13, 2023 01:39
|
|
|
The game is the content, though. You only write just enough engine to go wide on the content.
|
|
#
?
Jul 13, 2023 02:47
|
|
|
"Engine" is the most overloaded term in game programming. A generalizable underlying system providing the common structure between several games is a very handy thing to have in a stable state before you start working on the game itself. If you're experienced enough to know what you need from that system, you can even build it in advance, but you get a better result if you've got the needs of an actual game driving out the engine's features. However, it's difficult to make the engine and the game at the same time, which is a particular problem for one-programmer projects. It's a difficult paradox and I think the only thing for it is to suffer until you learn what you need to know. However, it doesn't take much to make an engine. At minimum, you're going to want things like: input, rendering, audio, asset loading, state management (hint: use ECS), and perhaps some debugging hooks. There are better and worse ways to make each of those parts, and unfortunately, all this poo poo is pure architecture, so you might end up locked into some bad designs. Whether you use an existing engine or make your own, it's important that it be a good fit for the scale of the project: the scale of the project determines the size of the team, and the size of the team determines how deeply each programmer can specialize, and therefore what kind of power they can handle. An inexperienced programmer should not attempt to make an engine, but might benefit a lot from using somebody else's, if it's a good one. Of course, even building a game without an engine can be very educational.
|
|
#
?
Jul 13, 2023 03:18
|
|
|
A recent series of meetings has me wondering if my current team is even a sane place to stay in the near future, and now I realize I don't have a lot of idea what other options I can look into. I'm currently a python dev (I've done some C# but not professionally) and I've been recently promoted at a FAANG and I'm one of the stronger devs on my team. My background is in incident management work, which has a lot of useful overlap with any sort of production service supporting team in terms of 'how do you get poo poo done in enterprise'. I haven't got any frontend experience unfortunately, but I've done a lot of infrastructure management work in one way or another (both programmatic and just general sysadmin stuff historically). What sort of job titles should I be looking for? I haven't actually had to job hunt as a dev yet, managed to get my current and previous gigs through industry contacts (and obviously I'll start talking to them again too). SRE seems promising as a general sort of 'must write code but understand uptime' sort of deal, but I'm trying to avoid getting back into massive oncall again after a decade of waking up at 3am.
|
|
#
?
Jul 13, 2023 05:44
|
|
|
Falcon2001 posted:A recent series of meetings has me wondering if my current team is even a sane place to stay in the near future, and now I realize I don't have a lot of idea what other options I can look into. Devops would work.
|
|
#
?
Jul 13, 2023 07:18
|
|
|
Pollyanna posted:The game is the content, though. You only write just enough engine to go wide on the content. See I don't really like writing stories or making characters, but when I play a game I always think about "I wonder how they handle pathfinding", "I wonder how hard it is to set up n-body physics in this game", or "What does the code that makes this pawn decided to take a poo poo look like?"
|
|
#
?
Jul 15, 2023 01:09
|
|
|
Ah, you’re John Carmack.
|
|
#
?
Jul 15, 2023 01:29
|
|
|
I mean it’s basically what people preach these days. Do you want to make a game? Grab an engine and make a game. Do you want to make an engine? Fine make an engine but don’t trick yourself that you’re doing it to make a game.
|
|
#
?
Jul 15, 2023 02:15
|
|
|
i remember learning three key principles of oop: encapsulation, polymorphism, and inheritance but now we know: - encapsulation is just modularity, and non-oo languages have this too. also mutable state is bad - parametric polymorphism is independent of oop, we are only really talking about subtype polymorphism here - inheritance is usually a bad idea the only true oop feature is dynamic dispatch, and in mainstream oo languages that means nominal subtyping which means class inheritance hierarchies. and we have already established that these are bad. therefore oop is bad, qed
|
|
#
?
Jul 15, 2023 06:37
|
|
|
wilderthanmild posted:See I don't really like writing stories or making characters, but when I play a game I always think about "I wonder how they handle pathfinding", "I wonder how hard it is to set up n-body physics in this game", or "What does the code that makes this pawn decided to take a poo poo look like?" NPCs that shitpost to Twitter. What a time to be alive.
|
|
#
?
Jul 15, 2023 07:32
|
|
|
DELETE CASCADE posted:i remember learning three key principles of oop: encapsulation, polymorphism, and inheritance I wasn't in the industry as OOP became The Thing™ - I was born into it being the defacto, so my perspective is skewed here, but my take is that things like Inheritance becoming a staple pattern of OOP in it's hayday meant that everyone seemed to want to turn every problem they could into a nail that the Inheritance Hammer can smash away at. I don't think Inheritance necessarily is bad on it's face - it's a feature with tradeoffs, and ought to be wielded carefully. Maybe more carefully then it has been in the past.
|
|
#
?
Jul 16, 2023 05:26
|
|
|
Implementation inheritance (and the corresponding "design all your classes so that some other programmer can come along and override half the public methods while leaving the other half untouched and your class still functions in a useful way" bullshit) is a total misfeature. It has zero good uses, approximately one okay use, and a bunch of potential for misuse. (The one okay use is facilitating code re-use within a strictly-controlled hierarchy, which is an okay workaround, but mostly reveals that your language is lacking in other good ways to facilitate code re-use). Subtype polymorphism is pretty good, though.
|
|
#
?
Jul 16, 2023 05:50
|
|
|
This is one of the things I've been interested in seeing with Golang and Rust: because they don't do classes, I see people using OOP patterns in there... but since classes and inheritance work so differently, it feels like a round peg in a square hole. I wonder what patterns will be evangelized as those things become more ubiquitous. Then again, we should separate concerns and organize things in a way other engineers can understand... and OOP patterns are what they understand, so it's not wrong, but culture changes faster than language specs.
|
|
#
?
Jul 16, 2023 14:36
|
|
|
What do you call the thing in stupid Java programs where every single class has a matching interface even if there is only one implementation? I hate that.
|
|
#
?
Jul 16, 2023 15:00
|
|
|
smackfu posted:What do you call the thing in stupid Java programs where every single class has a matching interface even if there is only one implementation? I hate that. C# does that too, it's a pattern for testing so every class can be mocked. I don't think there's a pithy name for it. I hate overuse of DI containers where you eventually reach the point where debugging consists of setting random breakpoints and hoping that's the one that you need. I was just dealing with that on a very large code base that I was unfamiliar with. Exceptions would get thrown deep in the bowels of the application and get swallowed and I couldn't step my way into the problem. Took two days to realize it was a missing file because I didn't have git lfs installed.
|
|
#
?
Jul 16, 2023 15:21
|
|
|
Splitting interfaces and implementations also helps with build times - if you have to compile a hundred different files sequentially (or worse, all at once in a single compiler invocation because they're circularly dependent), that takes forever compared to compiling just the interfaces all in parallel, followed by all the implementations (again in parallel).
|
|
#
?
Jul 16, 2023 16:18
|
|
|
Jabor posted:Splitting interfaces and implementations also helps with build times - if you have to compile a hundred different files sequentially (or worse, all at once in a single compiler invocation because they're circularly dependent), that takes forever compared to compiling just the interfaces all in parallel, followed by all the implementations (again in parallel). That might be true but I don't think it's the reason anyone does it
|
|
#
?
Jul 16, 2023 16:42
|
|
|
New Yorp New Yorp posted:That might be true but I don't think it's the reason anyone does it It's literally the reason I'm doing it right now to the software I'm working on, FWIW. Judiciously, of course - just to the problem children that show up all on the time on our build critical paths.
|
|
#
?
Jul 16, 2023 16:45
|
|
|
Program to an interface, and not an implementation!  I will not pretend I'm not guilty of this as well.
|
|
#
?
Jul 16, 2023 16:58
|
|
|
New Yorp New Yorp posted:C# does that too, it's a pattern for testing so every class can be mocked. I don't think there's a pithy name for it. Yeah, I vaguely remember that being a thing but now everyone using Java just uses mockito which I assume uses reflection to do this magically for you.
|
|
#
?
Jul 16, 2023 17:00
|
|
|
smackfu posted:Yeah, I vaguely remember that being a thing but now everyone using Java just uses mockito which I assume uses reflection to do this magically for you. Only for extendable classes. Final classes cannot be mocked, for example.
|
|
#
?
Jul 16, 2023 17:21
|
|
|
Love Stole the Day posted:This is one of the things I've been interested in seeing with Golang and Rust: because they don't do classes, I see people using OOP patterns in there... but since classes and inheritance work so differently, it feels like a round peg in a square hole. I wonder what patterns will be evangelized as those things become more ubiquitous. Then again, we should separate concerns and organize things in a way other engineers can understand... and OOP patterns are what they understand, so it's not wrong, but culture changes faster than language specs. Go has something similar which is to embed structs and/or interfaces but yeah that’s full of awful footguns especially when using anything from the atomic or sync packages and definitely if the type has custom marshaling or unmarshalling behavior. Go’s equivalent in terms of bad stuff that’s cargo-culted is micro-interfaces repeated everywhere because idiomatic Go says you should “accept interfaces and return structs.” Each accepted type that’s not a primitive becomes a ThingDoer and the compiler complains if you’re not passing a struct that implements it rather than complaining that a type doesn’t explicitly implement an interface. It makes actually finding implementations of an interface extremely painful even with an IDE that has “go to implementation” because guess what gomock does when you’re generating mocks? Yeah 
|
|
#
?
Jul 16, 2023 17:51
|
|
|
Blinkz0rz posted:Go’s equivalent in terms of bad stuff that’s cargo-culted is micro-interfaces repeated everywhere because idiomatic Go says you should “accept interfaces and return structs.” There's some bad idiomatic go, and this is absolutely the worst one. Luckily I've never seen people actually doing this because it's just so insane and hard to work with.
|
|
#
?
Jul 16, 2023 18:46
|
|
|
Judge Schnoopy posted:it's just so insane and hard to work with. But enough about Go
|
|
#
?
Jul 16, 2023 19:19
|
|
|
Judge Schnoopy posted:There's some bad idiomatic go, and this is absolutely the worst one. Luckily I've never seen people actually doing this because it's just so insane and hard to work with. It’s not awful when you think about DI and being able to couple use to behavior rather than identity but it can absolutely miserable to jump into a codebase where it’s been applied everywhere.
|
|
#
?
Jul 17, 2023 00:51
|
|
|
Mocking should be a tool of last resort when you can't figure out any other way to test some code, and as such going out of your way to ensure that every class in your codebase can be mocked is just a bad idea.
|
|
#
?
Jul 17, 2023 04:24
|
|
|
|
|
#
?
Jul 17, 2023 07:11
|
|
|
Mocking is the test strategy to apply when the purpose of the component is to communicate with another component in a particular way, and that second component is either not under your control, fundamentally has side effects, or both. Inject a mock of the inconvenient dependency into the component under test and assert that it interacts with the mock in a manner that conforms to your assumptions about the real version. Almost every system that does something useful will contain components best tested in a mockist way, but it shouldn't be your go-to. Put as much as you can into pure functions.
|
|
#
?
Jul 17, 2023 09:08
|
|
|
Test fakes are superior to mocks in just about every single way. The only exception is the "nobody has written a test fake for this particular inconvenient dependency yet and I don't wanna do it just for this test" scenario.
|
|
#
?
Jul 17, 2023 09:26
|
|
|
|
| # ? May 9, 2024 21:59 |
|
|
Jabor posted:Test fakes are superior to mocks in just about every single way. The only exception is the "nobody has written a test fake for this particular inconvenient dependency yet and I don't wanna do it just for this test" scenario. If it weren't proprietary code I'd post an example of just how awful test fakes get in a Go codebase. That's not to say they're not useful for simple logic but they have a tendency to balloon miserably and can end up taking a lot of work to maintain the internal bits that actually allow you to validate the expected behavior under test.
|
|
#
?
Jul 17, 2023 13:11
|
|