3 ms·

Those tools exist. Time travel debugging has existed in product-ready forms since the early 2000s let alone the advancements since then. The problem is that ga

by Veserv 2y ago

Those tools exist. Time travel debugging has existed in product-ready forms since the early 2000s let alone the advancements since then. The problem is that game development companies are willing to invest money in buying quality tools to make their developers productive, where as traditional trillion dollar software companies prefer to let their developers wallow in filth. Getting a company to invest 5,000$/yr into making their breathing revenue machines that cost 200,000$/yr and produce 1,000,000$/yr in revenue is like pulling teeth in this industry. Companies with breathing electrical engineer revenue machines do not bat an eye at 50,000$/yr in making them productive. Think about how much cool and effective tooling you could get with that kind of budget. But if you are not willing to spend even one coffee worth on your tooling, then one coffee of productivity is all you get to have.

agumonkey 2y ago
It's still strange to see this contrast between game dev doing magic for small salaries versus big corps paying huge lumps of money for CRUD++ (sorry for being exaggerating here). It's also cultural.. when everybody in the room thinks a REST api is state of the art, you'll have a hard time selling them more R&D.
- corysama 2y ago
  A game dev I know went to work for Google on Android. What he found was a team full of people who had given up on gdb back in uni, had worked for Google their entire career, printf debugged all day every day, took forever to fix anything, and everyone was fine with that because that’s all they’d ever known. It was a shock because in gamedev debuggers are a Big Deal. The vast majority of AAA gamedev happens in Visual Studio’s debugger or some alternative that is at least as capable.
  - agumonkey 2y ago
    Interesting. And scary.. and depressing (about Google). Gamedev has always had a special relationship with ergonomics (dev ux, dx) I assume (due to the interactive nature of their product)... Reminds me of Naughty Dog developing a whole lisp DSL to be able to try different game designs on the fly on PS1. That said gdb and similar debuggers are still too limited IMO, there's so much we could add on top. Well maybe I'm not aware of improved variants.
    - Veserv 2y ago
      The GDB feature set has been largely unchanged since the 80s and even then mostly just parroted the design of other CLI debuggers from the 70s. Of course it is limited, you are talking about technology that was not even cutting edge nearly half a century ago. To be fair, the core components of a low level debug agent are still largely the same, so it is not like the technology is bad per se. It is just that it only constitutes table stakes, a bare minimum foundation, these days. Even looking at 20 year old technology like time travel debugging that allows you to time travel execution back and forth gives a far better idea of what people are missing by using primitive tools.
    - lioeters 2y ago
      > Naughty Dog developing a whole lisp DSL to be able to try different game designs on the fly on PS1 The DSL was called Game Oriented Assembly Lisp. > It supports a long term compiling listener session which gives the compiler knowledge about the state of the compiled and thus running program, including the symbol table. This, in addition to dynamic linking, allows a function to be edited, recompiled, uploaded, and inserted into a running game without having to restart. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp Found more info on that here: https://lisp-lang.org/success/graphics/ https://lisp-lang.org/success/graphics/ > Naughty Dog Software used a Common Lisp DSL to write the Jak and Dexter series of games for the Play Station. > Naughty Dog co-founder Andy Gavin, says the unique capabilities of Lisp enabled fast development and execution of character and object control – something that was needed to fully realize the numerous 3D creatures and devices which interact with the player in real-time (60 frames per second). > “Lisp was just the best solution for this job,” comments Gavin. “With leading edge game systems like ours, you have to deal with complicated behaviors and real-time action. Languages like C are very poor with temporal constructs. C is just very awkward for a project like this. Lisp, on the other hand, is ideal.” > As Gavin explains, “With Lisp, one can rapidly develop meta constructs for behaviors and combine them in new ways. In addition, Lisp allows the redefinition of the language to easily add new constructs; particularly those needed to deal with time-based behaviors and layering of actions. Contrary to popular belief, there is nothing inherently slow about Lisp. It is easy to construct a simple dialect which is just as efficient as C, but retains the dynamic and consistent qualities that make Lisp a much more effective expression of one’s programming intentions.”
  - dboreham 2y ago
    Same, see my post above. Many of the printf-debugging people I've run into also came from Google.
    - agumonkey 2y ago
      I'm a bit shocked that Google is so full of them. That said the FP link seems weak, in theory (sic) functional programming will make you think about domains beforehand so the debugging game changes. But if it's mild FP over brittle ecmascript 5 libs... then it's another story.
dgb23 2y ago
The hard part of game development might be more centralized around complex, big programs that simulate game logic and push tons of complex and mathematically sophisticated data to GPU‘s. On the contrary the complexity web development, distributed systems emerges from many communicating processes, that execute in different environments. A sophisticated debugger might help the former category more than the latter. There’s no shortage of monitoring products that act on the distributed systems level.
theamk 2y ago
I think you are expecting too much. I've worked with expensive software before (embedded stuff, few K$ per seat) and it it was horrible - missing features slow, crashes a lot, horrible SDK designs. Yes, maybe it did generate some magical code (I have no way to check this) but the dev UX was terrible. I am working with clang & command line build system now and this is so much better. If someone offered me an expensive IDE I'l do all I can to make sure I don't have to work with it.

by Veserv 2y ago

agumonkey 2y ago

It's still strange to see this contrast between game dev doing magic for small salaries versus big corps paying huge lumps of money for CRUD++ (sorry for being exaggerating here). It's also cultural.. when everybody in the room thinks a REST api is state of the art, you'll have a hard time selling them more R&D.

corysama 2y ago
A game dev I know went to work for Google on Android. What he found was a team full of people who had given up on gdb back in uni, had worked for Google their entire career, printf debugged all day every day, took forever to fix anything, and everyone was fine with that because that’s all they’d ever known. It was a shock because in gamedev debuggers are a Big Deal. The vast majority of AAA gamedev happens in Visual Studio’s debugger or some alternative that is at least as capable.
- agumonkey 2y ago
  Interesting. And scary.. and depressing (about Google). Gamedev has always had a special relationship with ergonomics (dev ux, dx) I assume (due to the interactive nature of their product)... Reminds me of Naughty Dog developing a whole lisp DSL to be able to try different game designs on the fly on PS1. That said gdb and similar debuggers are still too limited IMO, there's so much we could add on top. Well maybe I'm not aware of improved variants.
  - Veserv 2y ago
    The GDB feature set has been largely unchanged since the 80s and even then mostly just parroted the design of other CLI debuggers from the 70s. Of course it is limited, you are talking about technology that was not even cutting edge nearly half a century ago. To be fair, the core components of a low level debug agent are still largely the same, so it is not like the technology is bad per se. It is just that it only constitutes table stakes, a bare minimum foundation, these days. Even looking at 20 year old technology like time travel debugging that allows you to time travel execution back and forth gives a far better idea of what people are missing by using primitive tools.
  - lioeters 2y ago
    > Naughty Dog developing a whole lisp DSL to be able to try different game designs on the fly on PS1 The DSL was called Game Oriented Assembly Lisp. > It supports a long term compiling listener session which gives the compiler knowledge about the state of the compiled and thus running program, including the symbol table. This, in addition to dynamic linking, allows a function to be edited, recompiled, uploaded, and inserted into a running game without having to restart. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp Found more info on that here: https://lisp-lang.org/success/graphics/ https://lisp-lang.org/success/graphics/ > Naughty Dog Software used a Common Lisp DSL to write the Jak and Dexter series of games for the Play Station. > Naughty Dog co-founder Andy Gavin, says the unique capabilities of Lisp enabled fast development and execution of character and object control – something that was needed to fully realize the numerous 3D creatures and devices which interact with the player in real-time (60 frames per second). > “Lisp was just the best solution for this job,” comments Gavin. “With leading edge game systems like ours, you have to deal with complicated behaviors and real-time action. Languages like C are very poor with temporal constructs. C is just very awkward for a project like this. Lisp, on the other hand, is ideal.” > As Gavin explains, “With Lisp, one can rapidly develop meta constructs for behaviors and combine them in new ways. In addition, Lisp allows the redefinition of the language to easily add new constructs; particularly those needed to deal with time-based behaviors and layering of actions. Contrary to popular belief, there is nothing inherently slow about Lisp. It is easy to construct a simple dialect which is just as efficient as C, but retains the dynamic and consistent qualities that make Lisp a much more effective expression of one’s programming intentions.”
- dboreham 2y ago
  Same, see my post above. Many of the printf-debugging people I've run into also came from Google.
  - agumonkey 2y ago
    I'm a bit shocked that Google is so full of them. That said the FP link seems weak, in theory (sic) functional programming will make you think about domains beforehand so the debugging game changes. But if it's mild FP over brittle ecmascript 5 libs... then it's another story.

dgb23 2y ago

The hard part of game development might be more centralized around complex, big programs that simulate game logic and push tons of complex and mathematically sophisticated data to GPU‘s. On the contrary the complexity web development, distributed systems emerges from many communicating processes, that execute in different environments. A sophisticated debugger might help the former category more than the latter. There’s no shortage of monitoring products that act on the distributed systems level.

theamk 2y ago

I think you are expecting too much. I've worked with expensive software before (embedded stuff, few K$ per seat) and it it was horrible - missing features slow, crashes a lot, horrible SDK designs. Yes, maybe it did generate some magical code (I have no way to check this) but the dev UX was terrible. I am working with clang & command line build system now and this is so much better. If someone offered me an expensive IDE I'l do all I can to make sure I don't have to work with it.