4 ms·

17 Ways to Reduce Your Turnaround Times While Prototyping Game AI

6 points by hhm 19y ago

Hexstream 19y ago
From reading this, I conclude that Lisp has MAJOR potential for developing big games in a quick and smart way. You'd develop and debug your game from within itself (REPL access in-game, restart support, etc), and then to ship it you'd make a compiler that compiles down to the proper runtime environment (C?) (so that you don't have to worry about lisp compatibility for the gamers and the garbage collector ruining the experience once in a while). It's a major undertaking, but the potential payoff is HUGE! DISCLAIMER: I don't know what I'm talking about (games development).
- hhm 19y ago
  Lisp was actually used for game development in the Crash Bandicoot games, and in other games by the same company. Later the company was bought and Lisp stopped being used afaik.
- pmjordan 19y ago
  Agreed. A lot of the techniques mentioned in the article are effectively impossible on consoles, which makes turnaround times even worse. (disclaimer: I haven't worked with all major consoles, so maybe some have decent compiler/debugger pairings) Lisp (or ANY dynamic language) could make a big difference. Some places reportedly have gone down that route. It'd be interesting to gather some data for game completion & schedule slip times and amount of high-level code used. I suspect there to be a strong inverse correlation. However, the attitude I encountered in the games industry (okay, my sample size is relatively small and geographically constrained) is that many people, particularly in the more senior positions are VERY resistant to learning anything new and only do so if they absolutely have to. You'd be surprised how many people still code in plain C even in situations where using some C++ features would save a load of time and even prevent bugs. A lot of build scripts and such were batch (!) files which contained horrendous hacks to get around the lack of proper flow control and scoping, and thus were effectively unmaintainable. We had a Lua interface, but that was mostly used for level-specific functionality, used by level designers, not programmers. Part of the reason for this was that the interface was so half-heartedly implemented - no debugging, no dynamic changes to the code. We had a full-on reflection system in C++, but for some reason there was no Lua interface for it. The other reason was that most programmers just weren't interested. And yes, I did volunteer for improving the situation (as I did in many cases) but that was shot down. Maybe that was just the particularly short-sighted approach taken at the studio I worked at.
  - bayareaguy 19y ago
    Games have to ship on time to succeed. Towards the end developers cut corners wherever they can. Perhaps your suggestions were good but came too late in the development cycle?
    - pmjordan 19y ago
      This was for speccing out the tech for the game that was about to go into production. I never ended up working on that because I left the company.

6 points by hhm 19y ago

From reading this, I conclude that Lisp has MAJOR potential for developing big games in a quick and smart way. You'd develop and debug your game from within itself (REPL access in-game, restart support, etc), and then to ship it you'd make a compiler that compiles down to the proper runtime environment (C?) (so that you don't have to worry about lisp compatibility for the gamers and the garbage collector ruining the experience once in a while). It's a major undertaking, but the potential payoff is HUGE! DISCLAIMER: I don't know what I'm talking about (games development).

hhm 19y ago
Lisp was actually used for game development in the Crash Bandicoot games, and in other games by the same company. Later the company was bought and Lisp stopped being used afaik.
pmjordan 19y ago
Agreed. A lot of the techniques mentioned in the article are effectively impossible on consoles, which makes turnaround times even worse. (disclaimer: I haven't worked with all major consoles, so maybe some have decent compiler/debugger pairings) Lisp (or ANY dynamic language) could make a big difference. Some places reportedly have gone down that route. It'd be interesting to gather some data for game completion & schedule slip times and amount of high-level code used. I suspect there to be a strong inverse correlation. However, the attitude I encountered in the games industry (okay, my sample size is relatively small and geographically constrained) is that many people, particularly in the more senior positions are VERY resistant to learning anything new and only do so if they absolutely have to. You'd be surprised how many people still code in plain C even in situations where using some C++ features would save a load of time and even prevent bugs. A lot of build scripts and such were batch (!) files which contained horrendous hacks to get around the lack of proper flow control and scoping, and thus were effectively unmaintainable. We had a Lua interface, but that was mostly used for level-specific functionality, used by level designers, not programmers. Part of the reason for this was that the interface was so half-heartedly implemented - no debugging, no dynamic changes to the code. We had a full-on reflection system in C++, but for some reason there was no Lua interface for it. The other reason was that most programmers just weren't interested. And yes, I did volunteer for improving the situation (as I did in many cases) but that was shot down. Maybe that was just the particularly short-sighted approach taken at the studio I worked at.
- bayareaguy 19y ago
  Games have to ship on time to succeed. Towards the end developers cut corners wherever they can. Perhaps your suggestions were good but came too late in the development cycle?
  - pmjordan 19y ago
    This was for speccing out the tech for the game that was about to go into production. I never ended up working on that because I left the company.