|
Doom Mathematic posted:A lot about games is totally subjective. If it looks pretty when it renders, it doesn't really matter what the unit tests (or any other kind of automated tests) are saying. If the game is no fun to play then it doesn't matter how many of your unit tests are passing or how many of them would need to be broken to fix it. Play testing overrules everything. say what you will about blow his arguments against unit testing make a lot more sense than this
|
#
?
Nov 12, 2019 18:25
|
|
|
|
| # ? May 17, 2024 16:10 |
|
|
Xarn posted:He said that before he really started, and what he means by compiler is a front-end to LLVM. the original Jai implementation used a hand-rolled x64 emitter when I saw it, is it now LLVM-based?
|
|
#
?
Nov 12, 2019 18:38
|
|
|
A lot of games are supposed to have deterministic rules, you could at least test those. Which apparently Factorio does, at least. Developers like Paradox seem to actually care about the quality of their code, and will rip out and replace poo poo that is unmaintainable long after a game releases, so it wouldn't surprise me to learn that they have some unit tests. You could even test the nondeterministic cases with a bit of Monte Carlo
|
|
#
?
Nov 12, 2019 18:50
|
|
|
the impression i get is that a lot of game devs (probably, correctly) see that unit tests are really hard to implement for good portions of their code and are just not worth the tradeoff. And then they throw the baby out with the bath water.
|
|
#
?
Nov 12, 2019 18:53
|
|
|
Suspicious Dish posted:the original Jai implementation used a hand-rolled x64 emitter when I saw it, is it now LLVM-based? Also it's not like "a frontend to LLVM" would make it somehow not a compiler. Frontend logic is an enormous part of writing a compiler.
|
|
#
?
Nov 12, 2019 18:59
|
|
|
I also suspect it to be against Blow's style to use LLVM. Blow's all about performance and speed, and LLVM's backend is very slow lol.
|
|
#
?
Nov 12, 2019 19:08
|
|
|
Suspicious Dish posted:I also suspect it to be against Blow's style to use LLVM. Blow's all about performance and speed, and LLVM's backend is very slow lol. The point of an optimizer is not to be fast, it's to make stuff fast. And nobody in their right mind would try to roll their own nowadays.
|
|
#
?
Nov 12, 2019 19:17
|
|
|
you can have both, though? LLVM is too slow for JITs, as Apple has rediscovered multiple times over.
|
|
#
?
Nov 12, 2019 19:39
|
|
|
Well, yeah, JITs need a different design than an ahead of time compiler. Not wasting resources on stuff that's rarely used is part of it, but also the languages used with JITs want different optimizations, too, than something C-like would.
|
|
#
?
Nov 12, 2019 19:43
|
|
|
Zopotantor posted:The point of an optimizer is not to be fast, it's to make stuff fast. And nobody in their right mind would try to roll their own nowadays. Yes, and we're talking about Jonathan Blow here sooo
|
|
#
?
Nov 12, 2019 19:46
|
|
|
Linear Zoetrope posted:While testing higher level meta-effects like "things with the same tag stack properly" might be useful, this in particular just sounds like data duplication. You're writing the same properties in two places and hand testing if they're out of sync. I totally get this and I've written tests myself that basically only test the integrity of the universe, that 1+1=2. But it's called unit tests for the reason that you can make a judgement about what constitutes a unit of computation in your software, what truths other bits of the software relies on and then devise a test for it. Mock what you need to mock, don't test the fundamentals of math but test the things that your components say or do to one another. Letting the game run for a while and confirm that the plumber kills the turtle is not really unit testing imo. The input and output of a unit test isn't necessarily something that's seen by the user, but something the program does under the hood. Games are no different than any other software in this regard, unless Doom 3 is somehow a single Java main method or whatever.
|
|
#
?
Nov 12, 2019 19:57
|
|
|
A great deal of graphics demos are coded as one giant main(), unfortunately
|
|
#
?
Nov 12, 2019 21:04
|
|
|
Dumb Lowtax posted:A great deal of graphics demos are coded as one giant main(), unfortunately Demos are to other software what a pointillist painting is to a photograph.
|
|
#
?
Nov 12, 2019 21:24
|
|
|
Zopotantor posted:Demos are to other software what a pointillist painting is to a photograph. I'd say they are more like sketches. Demos sometimes come across some cool new ideas but they are mostly quickly hacked together, which can later be utilised in a more sensible form.
|
|
#
?
Nov 12, 2019 22:11
|
|
|
Zopotantor posted:The point of an optimizer is not to be fast, it's to make stuff fast. And nobody in their right mind would try to roll their own nowadays. one of his top priorities for the language was to make compile times extremely fast you can see him show off demos and code live on twitch, seems to never take more than a second e: this is coding the actual game he plans to sell next, the grid-movement-teleport puzzle thing Doc Hawkins fucked around with this message at 22:38 on Nov 12, 2019 |
|
#
?
Nov 12, 2019 22:20
|
|
|
if he's done a lot of work with c++, i can understand the motivation
|
|
#
?
Nov 12, 2019 22:23
|
|
|
saying that LLVM is the best we have and that there's no room for possible improvement why even bother trying is either wrong, or just plain sad.
|
|
#
?
Nov 12, 2019 22:35
|
|
|
Xarn posted:Don't you know that games are the most complex and advanced software? I mean it is harder to write a game than a compiler. I have written several compilers and my day job is to be an academic researcher in compiler technology, and I absolutely believe compilers are easier to write than games. A traditional compiler is a pretty simple batch-mode program, basically a completely deterministic pure function. It may do complex things and it is hard to make it generate better output (this is why I have a job, after all), but as a context in which to write code, it's pretty comfortable. Simple debugging and fuzzing techniques work well. Games have way more stuff going on, a much less clear notion of what valid input and output may be, and tons of nondeterminism. Compiler frontends that provide more IDE-like services (e.g. Roslyn) are not as batch-oriented, but I'll still argue that the problem they solve is much more well-defined, and amenable to old-school systems design, than a modern game.
|
|
#
?
Nov 12, 2019 23:01
|
|
|
Programming languages actually have some interesting similarities with games in the sense that different mechanics tend to combinatorially explode in complexity rather than being naturally “additive”.
|
|
#
?
Nov 12, 2019 23:46
|
|
|
Both compliers and games have massive ranges of complexity depending on objectives. Compilers don't have to deal with terrible platform APIs so much, though.
|
|
#
?
Nov 12, 2019 23:56
|
|
|
Much like games, some programming languages are very bad while others are less bad
|
|
#
?
Nov 13, 2019 00:11
|
|
|
Ralith posted:Both compliers and games have massive ranges of complexity depending on objectives. Compilers don't have to deal with terrible platform APIs so much, though. Let me tell you about the special case for -[NSString length] in Clang's Objective-C support. Or the workarounds for outright broken standard libraries in Clang's C++ support. Or all the terrible language extensions that are only used in various platform headers because hey, they're shipped with the toolchain so why not be totally dependent on it? EDIT: Oh, and just on the implementation level the built-on-demand aspects of features like modules mean we get to deal with the wonderful world of efficient change detection and filesystem locks. rjmccall fucked around with this message at 01:22 on Nov 13, 2019 |
|
#
?
Nov 13, 2019 01:09
|
|
|
What I feel is also missing from Mr. Blow's decision to roll everything himself are things like interactive autocompletion and debugging support. In his live stream he's typically clacking away in vi or some such, which may not be the ideal environment for a lot of developers.
|
|
#
?
Nov 13, 2019 11:14
|
|
|
Are there any games that are developed in a modular fashion like a business app? I.e. with a pure "business logic" library where all the rules play out and the abstract game state evolves via ABI calls, and a separate "frontend" that gets the updated game state from the library and renders it in the engine?
|
|
#
?
Nov 13, 2019 13:48
|
|
|
I'm pretty sure all the Paradox Grand Strategy games are structured roughly like what you describe. But the comedy answer is Aurora 4x.
|
|
#
?
Nov 13, 2019 14:24
|
|
|
Ralith posted:Both compliers and games have massive ranges of complexity depending on objectives. Compilers don't have to deal with terrible platform APIs so much, though. Just terrible CPU APIs
|
|
#
?
Nov 13, 2019 15:22
|
|
|
Suspicious Dish posted:Probably the best-known example of testing in video games is Riot's test harness for League of Legends, where they record game playback and ensure very high-level things like "when I am this character with this spell with these stats, and fire at this enemy with these stats 5 times, it will eventually die". That's not unit testing, that's super high-level and just about the level that starts becoming helpful for games. That's not really a fair example of what riot actually does... https://technology.riotgames.com/news/automated-testing-league-legends That's almost four years old and it's just increased in complexity from there. The biggest problem of that twitter thread is the innate coupling of unit tests to TDD in his mind. One of my sound bites I use a lot is, "I don't believe in TDD personally but any code base that an engineer could develop on using TDD is one that is in good shape." And I still maintain that. Plorkyeran posted:Game devs tend to have very negative opinions on automated testing of all sorts, for some good reasons and some bad reasons. That's becoming more and more of a minority opinion among professional developers and I suspect is on the order of no more than developers at large. I know I'm working on recruiting someone from a medium sized insular organization and they haven't changed their process in the 16 years since we had started there, and that's one reason I'm able to recruit. NihilCredo posted:Are there any games that are developed in a modular fashion like a business app? I.e. with a pure "business logic" library where all the rules play out and the abstract game state evolves via ABI calls, and a separate "frontend" that gets the updated game state from the library and renders it in the engine? Mobile and Unity games tend to be like that. I worked on client predictive/server authoritative games for years where you'd run the same logic on the client as on the server as an anti-cheat yet responsive measure. Separately two projects enforce a no UnityEngine/UnityEdfitor boundary between Game logic and UI/UX one reason being to run it in a bog standard test runner outside of a UnityEditor
|
|
#
?
Nov 13, 2019 15:41
|
|
|
NihilCredo posted:Are there any games that are developed in a modular fashion like a business app? I.e. with a pure "business logic" library where all the rules play out and the abstract game state evolves via ABI calls, and a separate "frontend" that gets the updated game state from the library and renders it in the engine? Deserts of Kharak did this. A dev did a talk about their architecture and other stuff at GDC. Interestingly, despite being a 3d game the simulation layer only runs a 2d abstraction, and then the presentation layer fakes the third dimension (even including running a separate physics engine to make vehicles bounce on their shocks and get airtime from jumping off dunes) https://www.youtube.com/watch?v=wwLW6CjswxM
|
|
#
?
Nov 13, 2019 15:42
|
|
|
rjmccall posted:Let me tell you about the special case for [...] the workarounds for outright broken standard libraries in Clang's C++ support. Please do, this sounds fascinating.
|
|
#
?
Nov 13, 2019 18:17
|
|
|
Years ago there was an article about how an engine developer implemented scripting so level designers could write their own high-level game mechanics, but I can't find it now. I'm pretty sure it was a Star Wars game.
|
|
#
?
Nov 13, 2019 19:07
|
|
|
Suspicious Dish posted:saying that LLVM is the best we have and that there's no room for possible improvement why even bother trying is either wrong, or just plain sad. Also llvm may be low level but it is still a vm. The stuff I want to mess about with in my own language (closures/spaghetti stacks, calling conventions, object file formats) is exactly what llvm abstracts away from you so I wrote my own backend that goes direct to writing out machine code in ELF, MachO etc files. It's also a fun learning experience!
|
|
#
?
Nov 13, 2019 19:10
|
|
|
LLVM has practically never been a VM. It's a confusing legacy name for what is basically a compiler toolkit at this point.
|
|
#
?
Nov 13, 2019 19:12
|
|
|
DaTroof posted:Years ago there was an article about how an engine developer implemented scripting so level designers could write their own high-level game mechanics, but I can't find it now. I'm pretty sure it was a Star Wars game. Many games do this, hence the popularity of Lua. It's a bad scripting language whose main redeeming feature is being easy to integrate into a pre-existing codebase, so you can expose internal game stuff for designers/modders/players to tinker with.
|
|
#
?
Nov 13, 2019 19:22
|
|
|
Suspicious Dish posted:LLVM has practically never been a VM. It's a confusing legacy name for what is basically a compiler toolkit at this point. I don't mean it executes byte code, I mean it is an abstraction over the real hardware.
|
|
#
?
Nov 13, 2019 19:25
|
|
|
RPATDO_LAMD posted:Many games do this, hence the popularity of Lua. It's a bad scripting language whose main redeeming feature is being easy to integrate into a pre-existing codebase, so you can expose internal game stuff for designers/modders/players to tinker with. Yeah, very true. I thought of this article in particular because it included a lot of technical detail and examples of how the scripts' versatility exceeded their expectations. Unfortunately, my google fu is still failing me.
|
|
#
?
Nov 13, 2019 20:31
|
|
|
VikingofRock posted:Please do, this sounds fascinating. Compilers sometimes permit code to be written that shouldn't actually compile, and sometimes that code is in system headers. So, for example, there is (or used to be) a function in libstdc++'s hashtable implementation that returns false from a function that returns a pointer type; false used to be a valid null pointer constant, and while that stopped being true in C++11, we can't exactly just refuse to parse the libstdc++ headers, so instead there's a hack which just allows this as a null pointer constant when it appears in system headers. I think that's a bad fix; it would be better to have been more specific about the hack. For example, GCC used to have a bug where it treated the conditional operator as producing an r-value in a case where it was supposed to produce an l-value, and they relied on that behavior in std::common_type, and so there is literally a check in Clang when instantiating a typedef named type within a class template called ::std::common_type declared in a system header to strip references before binding the typedef, and without that hack some versions of libstdc++ won't work. The more general example of this is with template parsing. EDG was the first C++ compiler that implemented the name lookup rules within templates (mostly) correctly, but they intentionally hid that behavior behind a flag and implemented compatibility modes for how GCC and MSVC implemented templates, both of which were quite wrong on some fundamental issues according to the spec. Because compilers were using the wrong rules, people could write C++ code that compiled according to the broken behavior, and of course that included C++ library authors. Clang actually used the correct rules by default, and as a result we couldn't parse existing C++ library headers. You can't really stand on principle at that point; you have to figure out some way to make it work, ideally without completely surrendering to broken behavior everywhere. So we fixed libc++ (because it was new enough that we didn't really need to care about existing installs), and we put some hacks in the compiler to get around the libstdc++ problems. The problems in MSVC's headers were much more pervasive, and eventually we just had to add a compatibility mode for them which (IIRC) is only enabled by default within their STL headers.
|
|
#
?
Nov 13, 2019 21:26
|
|
|
DaTroof posted:Years ago there was an article about how an engine developer implemented scripting so level designers could write their own high-level game mechanics, but I can't find it now. I'm pretty sure it was a Star Wars game. Does anyone know how PS4 Dreams handles this? I don't think it allows players/designers to do any scripting, but the end results do look like highly customized shader effects and render effects as if they had. See the below "game level" made by someone inside Dreams while playing it, submitted to the big online collection players browse through. They achieved some pretty serious custom lighting effects at the timestamp linked. Do you know if you can type code at all in Dreams or is it all just done by players flipping a million flags in menus, and placing objects? https://www.youtube.com/watch?v=6v8BTanhMQw&t=91s
|
|
#
?
Nov 13, 2019 22:33
|
|
|
rjmccall posted:false used to be a valid null pointer constant, and while that stopped being true in C++11 praise be.
|
|
#
?
Nov 13, 2019 22:49
|
|
|
Dumb Lowtax posted:Does anyone know how PS4 Dreams handles this? I don't think it allows players/designers to do any scripting, but the end results do look like highly customized shader effects and render effects as if they had. See the below "game level" made by someone inside Dreams while playing it, submitted to the big online collection players browse through. You can buy a copy of the game right now and check their tools. They're pretty expansive and detailed. Their graphics tech is state-of-the-art in my opinion.
|
|
#
?
Nov 14, 2019 01:35
|
|
|
|
| # ? May 17, 2024 16:10 |
|
|
feedmegin posted:I don't mean it executes byte code, I mean it is an abstraction over the real hardware. Do you mean the IR?
|
|
#
?
Nov 14, 2019 01:42
|
|
