

17 Ways to Reduce Your Turnaround Times While Prototyping Game AI - hhm
http://aigamedev.com/methodology/reduce-turnaround-times

======
Hexstream
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).

~~~
pmjordan
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
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
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.

