Article
videos/paris08-panel-ricardo-icon

Crytek’s Ricardo Pillosu on Scripting (Paris Game AI Workshop ’08, Video)

Alex J. Champandard on July 5, 2008

Last week’s Game AI Workshop, organized by AiGameDev.com and the LIP6 University, was a great success — especially considering the whole thing was set-up in less than 6 weeks. The room of 50 sold-out, and we squeezed in a few extra local students and people from GDC!

We arrived back from France a few days later, after visiting a few Parisian middleware studios — including our workshop sponsor Spir.Ops. It’s taken this long to get some of the material online partly because I went straight to Amsterdam on Sunday for some on-site work.

The primary reason I haven’t posted about this before, however, is that we’ve been putting the final touches on a new part of the site for Insiders. It’s been in the pipeline for months, but put on hold while we organized the workshop. Now we have some amazing content from Paris, everything is finally coming together and we’re practically ready to launch. It’s going to be entirely free; all you have to do is sign-up. (If you’re registered in the forums already, you’ll be the first to know and it’ll be a painless process to get access.)

As a teaser, here’s one of our panelists from the industry session, Ricardo Pillosu, from Crytek. I asked him how he felt about scripting in general, and in particular Lua. The video is about 2 minutes 45 seconds, out of the whole 7h day recording! Click to find out what Ricardo replied…

The bit before the recording includes the opinions of Phil Carlisle (formerly Team 17 and Garage Games), and Axel Buendia (from the Spir.Ops AI middleware company). Shortly after, we also discuss the process of scripting a little more, including the approach that Electronic Arts takes.

You’ll be able to get the full recording for the Industry Panel in the AiGameDev.com Insider’s area when it launches — so stay tuned! In the meantime, if you have any comments or questions post them below.

Discussion 16 Comments

Jare on July 5th, 2008

I'm certainly in the opposite end: the more I use scripting in games development, they more I realize how productive it can be. Of course, as with C++, it's also a shotgun that can blow your entire leg if you don't exercise the appropriate caution: 1 - Invest in on-the-fly script creation and modification technology. Restarting the game is a timesink for the designer just like the compile-link cycle is to the programmer. 2 - Identify debugging needs and provide suitable tools (a full-fledged debugger as the ultimate ideal, but flexible logs, traces and histories can go a long way). 3 - Monitor performance and resource bottlenecks periodically. Be ready to move consuming pieces of code back to C++. Schedule time for this until the very last day. 4 - Ensure that software engineering practices scale with the size of the script codebase. This [u]absolutely[/u] includes programmer time to write and refactor designer-written scripts, and eventually write that complete debugger. In my experience, #1 and #2 happen naturally but later and clunkier than they should, #3 is done only when alarms are ringing (i.e. when it's already late and you're in a rush), #and 4 almost never happens. #1 and #2 reduce the productivity gains from scripting, and #3 and #4 generate the kind of hatred Ricard describes.

alexjc on July 6th, 2008

Hi Jare, Thanks for your insightful comment. You're right about the potentials of it being a solid solution technically (e.g. late binding). Ricardo mentions this, although he also stresses the dangers too. The guidelines you mention are indeed very sensible in that regard, but you're right that not many companies apply them. I've only ever been impressed by Blizzard's usage of Lua. That seems incredibly robust and well thought out. Back to the audio, what was missing just before was me asking the other panelists about scripting in the context of designer control. In that respect, I agree with Ricardo that everyone thought five years ago: "Hey cool, we can just integrate a scripting language and all our design problems are over." The reality is that most designers can't (and shouldn't) script to save their lives, and those who can don't necessarily have the experience. So, in that sense, I think scripting was a bit of a Trojan horse (if you use it for more than just a configuration language). From the design side, you need to instead rethink your interface, what data you expose at what level, how you allow changes at runtime, and how you explain errors. All this is independent of the scripting language, and that's been missing all along for many studios... Alex

Jare on July 6th, 2008

[QUOTE=alexjc;3417]The reality is that most designers can't (and shouldn't) script to save their lives, and those who can don't necessarily have the experience.[/QUOTE] I won't deny that I look at the whole thing with the eyes of a programmer that has been part-time designer, technical artist and even producer, which means I'm all for multi-skilled developers. I encourage all designers to 'get their hands dirty' with implementation, programmers to watch artists at work with the tools, and artists to 'play the game in their head' before they build their assets. To me the ideal is to have a programmer structure and write the first script of every type, possibly of every mission, according to the initial design and with the involvement of the designer that designed and/or will maintain and iterate that mission. This way designers don't lose touch with the practical aspects of implementing their designs, and likewise programmers become users of their own interfaces and systems. Communication and trust between two developers who understand each other's work at that level is as fluid as the personalities and the pressure allow. In Praetorians, the AI programmer and the designers did a fair amount of this. Of course, it helped lot that the AI programmer was Sergio :) and that the main designer / scripter was a former AI programmer himself. Ideal eh? However, another scripter was an absolutely non-technical guy (he hadn't even [i]used[/i] a PC before joining the team), but he was able to pick up the basics of programming, and apply the patterns that Sergio had burned in the scripts and explained to him. If we could do that in a project with rather limited resources, it should be even more doable in a larger project, but bigger teams tend to push people towards more specialization and less awareness of the game as a whole, so it's necessary to actively encourage this collaboration.

MieszkoZ on July 6th, 2008

My two cents from my (not that big) experience: [quote=alexjc;3417] The reality is that most designers can't (and shouldn't) script to save their lives(...)[/quote] Sadly it's true. Working in three decent studios so far I haven't met a single level designer that could script. Some of them were eventually forced to do so, but they weren't too happy about that (and had a lot of troubles getting to 'feel' scripting, to be honest). [quote=jare;3416]1 - Invest in on-the-fly script creation and modification technology. Restarting the game is a timesink for the designer just like the compile-link cycle is to the programmer.[/quote] True, true.. One of the cool features we have at the studio I'm working currently at is that of 'scripts reloading'. Whenever you run the game or an editor and you change some AI scripts all you need is reload them. Ingenious in its simplicity and so easy to do with lua :) Actually I can imagine my life being a lot tougher without this little thing. [quote=jare;3418]In Praetorians, the AI programmer and the designers did a fair amount of this. Of course, it helped lot that the AI programmer was Sergio :) and that the main designer / scripter was a former AI programmer himself. Ideal eh? However, another scripter was an absolutely non-technical guy (he hadn't even [I]used[/I] a PC before joining the team), but he was able to pick up the basics of programming, and apply the patterns that Sergio had burned in the scripts and explained to him.[/quote] I could never overstress how important this kind of cooperation is. It's always a good thing to have a designated level designer or scripter that's a connection between AI programmer and the rest of level design team. I've been once in this kind of close cooperation scheme and it resulted in all of AI design/development go a lot smoother, with very quick turnarounds, instant feedback on new AI features and bugs being identified and fixed quickly. Unfortunately designers still didn't script, but they successfully used script patterns prepared for them.

PaulTozour on July 6th, 2008

I interviewed with Infinity Ward last week. The thing that struck me more than anything was how many technically competent designers were on the team, and how well they could use Infinity Ward's (rather advanced) scripting system. I've worked at 5 studios so far, and I've never worked with a design team that had more than 1 or 2 designers capable of doing scripting at more than a basic level. Infinity Ward has more than a dozen designers who can work at that level, and they can often implement major new features with little or no help from the engineers. So apparently that's the key to outselling Halo ... Hire highly skilled and technically competent designers.

MieszkoZ on July 6th, 2008

[quote=PaulTozour;3428]Infinity Ward has more than a dozen designers who can work at that level, and they can often implement major new features with little or no help from the engineers.[/quote] So it is possible, and I'm not a dreamer! (hmm.. maybe the later part is still true ;) ) Thank you, Mr. Tozour, you brought me hope.

Ricardo on July 6th, 2008

Hi Jare, nice to hear from you ;) [QUOTE]In Praetorians, the AI programmer and the designers did a fair amount of this. Of course, it helped lot that the AI programmer was Sergio :) and that the main designer / scripter was a former AI programmer himself. Ideal eh? However, another scripter was an absolutely non-technical guy (he hadn't even used a PC before joining the team), but he was able to pick up the basics of programming, and apply the patterns that Sergio had burned in the scripts and explained to him.[/QUOTE] While this situation that you explain here is ideal, sadly is very difficult to scale to a team of 10-20 designers. At this point is clear to me that we have to stop and rethink the whole process: "what a designer is good at?" (no jokes here please ;) If you ask them how they are going to design a certain action bubble they describe it like a movie [I]"then the bad guys appear and ... (add random explosions)"[/I]. We need a language / tool / protocol to let they make it happen in the game, without having to worry about functions or variables. In this sense I like the approach Isla did in Halo 3 and the way designers describe each encounter. Also, CryEngine's flowgraph is an interesting approach to visual programming. Those effords are on the right track, but there is still a long way to go. It´s up to us to let them express their creativity in an easier way.

MieszkoZ on July 6th, 2008

[QUOTE=ricardo;3430](...)CryEngine's flowgraph is an interesting approach to visual programming.(...)[/QUOTE] There's also Unreal Engine's Kismet serving the same purpose (and in my opinion doing it a level of magnitude better). [QUOTE=ricardo;3430]Those efforts are on the right track, but there is still a long way to go. It´s up to us to let them express their creativity in an easier way.[/QUOTE] That's true, a really long way. Those named tools are really 'Visual Programming' tools, since they express programming concepts and programmers' ways of thinking about things. The problem is it's (almost) only us, programmers, thinking this way. Giving designers a tool to 'code' stuff with arrows and boxes doesn't change the fact, that for them it's an artificial way of looking at things. It gives them a lot of power they don't really know how to use. So like Ricard said, it's up to us, and don't make it easy for ourselves and just visualize code for them. We need to think harder and try to build tools that fit Their perception of game world!

zoombapup on July 7th, 2008

I come back to looking at flash. Particularly, I look at the flash timeline and I think "this seems to work for designer types" and it makes me wonder if that isnt a better meme for designer control. After all, most of the scripting done in a game is either level flow or cutscene. Cutscene's would work amazingly well using a timeline. If you added event based timelines, you could essentially program everything using just changing timelines and events. I guess if a timeline tool ended up being reduced to a script. Then it might actually work. I wonder if anyone has done any work on this. It would be a very interesting read. Maybe I'll propose it as a project for my students.

MaciejS on July 7th, 2008

[QUOTE=MieszkoZ;3431]There's also Unreal Engine's Kismet serving the same purpose (and in my opinion doing it a level of magnitude better). [/QUOTE] Is there a possibility to "force" Kismet to generate source code for the scenario that we set up in the editor? I'm programmer, not designer, so perhaps I'm biased but every screenshot from "visual programming" tools makes me cringe. First example that I found on Google: [url]http://www.roboblitz.com/RoboBlitzEditorWiki/images/KismetWall.jpg[/url] . How the hell am I supposed to tell what does it do? In the perfect world, you'd be able to generate script from that diagram, perhaps even modify it, if you wanted (with diagram updating itself of course)... Re: Infinite Ward - download COD4 SDK if you're interested in their scripts, complete mission flow is hardcoded there.

MieszkoZ on July 7th, 2008

Hi Maciek! Glad you you joined us :) [QUOTE=MaciejS;3448]Is there a possibility to "force" Kismet to generate source code for the scenario that we set up in the editor?[/quote] None that I'm aware of, but on the other hand I'm no Unreal Engine expert (yet!). But it shouldn't be to hard to implement since like I said it's 'visualized code'. [QUOTE]I'm programmer, not designer, so perhaps I'm biased but every screenshot from "visual programming" tools makes me cringe. First example that I found on Google: [url]http://www.roboblitz.com/RoboBlitzEditorWiki/images/KismetWall.jpg[/url] . How the hell am I supposed to tell what does it do? [/QUOTE] Man, this screenshot is scary! If you'd like to see how a proper Kismet diagrams look likes I strongly encourage you to take a look at one of tutorial videos like [url]http://www.3dbuzz.com/vbforum/sv_video.php?v=104[/url]. Like with 'real' code, you can have a nicely structured one and a spaghetti one. This screenshot is as spaghetti-ish as it gets! [QUOTE=zoombapup;3447]I come back to looking at flash. Particularly, I look at the flash timeline and I think "this seems to work for designer types" and it makes me wonder if that isnt a better meme for designer control.[/QUOTE] That's ingenious! Great idea! [QUOTE]Maybe I'll propose it as a project for my students.[/QUOTE] Make sure you do that :) Those pure, young minds always code up with something fresh and innovative! Just make sure to let us know how did it go ;)

William on July 7th, 2008

[QUOTE=PaulTozour;3428]I interviewed with Infinity Ward last week. The thing that struck me more than anything was how many technically competent designers were on the team, and how well they could use Infinity Ward's (rather advanced) scripting system. [...] So apparently that's the key to outselling Halo ... Hire highly skilled and technically competent designers.[/QUOTE] Great observation. Haven't met any of the IW guys, but I have browsed through their scripts for MoH:AA, CoD, CoD2 and CoD4. Given that they haven't changed much of their approach (of writing customized AI for every level and cinematic encounter), I was surprised they got their AI as robust as they did for CoD4; I've spent a good time doing unexpected things in-game, and had troubles finding the AI to act inconsistent with my actions. Wrt hiring: hasn't IW retained most of their key staff getting from MoH:AA to CoD4?

zoombapup on July 7th, 2008

[QUOTE=PaulTozour;3428]So apparently that's the key to outselling Halo ... Hire highly skilled and technically competent designers.[/QUOTE] Off topic I know, but I think the key here is to create a more compelling game :)

PaulTozour on July 7th, 2008

[QUOTE=William;3462] Wrt hiring: hasn't IW retained most of their key staff getting from MoH:AA to CoD4?[/QUOTE] My understanding is that yes, voluntary turnover has been extremely low for IW.

PaulTozour on July 7th, 2008

[QUOTE=zoombapup;3463]Off topic I know, but I think the key here is to create a more compelling game :)[/QUOTE] Perhaps that's in the middle of the causal chain ... I'm guessing it goes something like this: [INDENT][B][COLOR="Blue"]better designers -> more compelling game -> better sales[/COLOR][/B][/INDENT]

BeniGR on July 13th, 2008

[QUOTE=MieszkoZ;3431] That's true, a really long way. Those named tools are really 'Visual Programming' tools, since they express programming concepts and programmers' ways of thinking about things. The problem is it's (almost) only us, programmers, thinking this way. Giving designers a tool to 'code' stuff with arrows and boxes doesn't change the fact, that for them it's an artificial way of looking at things[/QUOTE] Talking about visual programming tools like the Flow Graph in Cry Engine, although a powerful tool (and good step forward), I agree with Miezsko. You can do really cool stuff just linking a few nodes, but it could also be a Trojan Horse in the wrong hands. (Just check some mod forums, and you will find some crazy stuff). Also you will find yourself creating nodes for everything, or give access to all kind of functionality inside the game / engine (you need still a coder to satisfy designer wishes =)). The designer probably doesn´t know that using certain nodes could be expensive, or that they could optimize their graph, and they could do the same with less links and boxes. That´s because I would like to see more designers like those ones in Infinity Ward that Tozour mentions. About scripting, I think it´s good if used in the right way. Also I find it quite useful for quick prototyping; as long as you know where to draw the line, all it´s fine (Jare wrote some good guidelines on his first post). I love the fact that you can change things, and hot reload, or that if I commit an error, the application won´t crash. (Although you can do similar things without scripting too...)

If you'd like to add a comment or question on this page, simply log-in to the site. You can create an account from the sign-up page if necessary... It takes less than a minute!