Remastering Day of the Tentacle and Grim Fandango

[Music] good afternoon my name is Oliver Frankie and I'm here today the smart cook to talk about some of the lessons we learned from her mastering the classic LucasArts adventure games day of the tentacle and grim fandago and we're gonna be talking about the general philosophy we used when working on these projects as well as the kind of the process bill following and of course there will be lots of like unique challenges we were facing you know when working on these games and just in case it's spin mooom you know 20 years since you've seen they've tentacle grim fandago here's just a super quick reminder buenos Diaz alright so not fancy but just we want to give you an impression about we're gonna be talking about now we're probably gonna get into the meat of the talk just a few words

about access to speakers as I said my name is Oliver Lansky and I was the lead programmer on the authentical remastered and for the last seven years I've been working for Double Fine productions in a role of the lead programmer on various projects like for example broken age and most recently full throttle remastered before Double Fine actually used to work for Lucas arts where as part of the team that brought you the Monkey Island special editions so for me as a lifelong adventure game fan as well as a programmer was a really cool opportunity to kind of you know help to bring these games to a whole new generation of players as well as like hardware and to make them accessible again and this also allowed me to kind of see how the adventure game genres to evolve over the years as well as kind of the development process behind these games and hello everybody my name is Mark cook and I'm the CEO of a studio here in San Francisco called shiny shoe that I founded five years ago and like Oliver

I've worked on a bunch of different games throughout my career but recently we've been working with Double Fine on all of these Tim Schafer designed classic adventure game remasters so Grim Fandango day of the tentacle and now we have full throttle in production but today I'm here to talk about grim fandago and if you look closely at my little game list here you'll see that it pops up twice and that's because not only did I work on the remaster as both a producer and as an engineer I also was an intern at LucasArts in 1997 and worked on the original writing code that I'm certain was thrown in the garbage can the second I left for the summer but that does give me a little bit of extra perspective about kind of the some of the challenges that we had during the remastering process so I'm gonna hand it back to Oliver who's gonna go over our philosophy of what we think goes into making a good remaster which is really good the kind of thread that ties the two games together and then Oliver is gonna talk about day of the tentacle so take it away all right thanks mark well the most important point I want to make

here is that everyone on the remaster team really was a huge fan of these classic games you know we all played them and we were younger and you know we liked the writing and the humor and the puzzles and art style and we really didn't see any reason to change that and what we didn't want to change was to you know how easy it is to play these games and more specifically to make them available on platforms that they previously weren't on like you know contemporary consoles or mobile devices and while doing that it was important to us to stay true to the original artistic intent so that the games you would end up releasing would be something that we would be proud of but also the development team would be happy with and now of course we're talking about remastered versions so we want to improve the fidelity wherever it was possible now doing this you know while staying kind of close to the original art style but still using you know the hardware that we have and its capabilities to create a kind of a beautiful modern version of the same game now there are some features that

really didn't hold up very well over the 20 years and we wanted to modernize those delicately so that you know the game conforms to one on standards but still the original gameplay is preserved and of course it's not a big surprise when the original games shipped back in the 90s they shipped with bugs and we wanted to take the opportunity we had with these remastered versions to fix as many of these bugs as possible to create a much more polished experience and then of course lastly we wanted to do something for you know hardcore fans of these games I'm sure there many people here who you know played these games a whole bunch of times and all the puzzles inside out and you know for you we wanted to add features like the developer commentary or the concept art gallery so there's something extra to explore and I want to kind of point out that this is not just an you know a kind of theoretical framework we made up here for GDC because we needed you know something for the for the talk as a takeaway point but we really believe that this is a set of rules that helps you to take a good classic game or even a great classic game and turn it into a very strong remastered version and

thankfully most players as well as the press seem to agree with us and we got a lot of positive feedback from players and the press and both devon degaul and grim Finnegan combined moved more than five million units which made them actually more successful than the original versions so that was kind of a real big honor but now let's see how this applies to you know real project and the next 20 minutes or so I'm going to talk about how we got from this to that now the original version of day of the tentacle was released in 1993 and was co-led by industry legends Tim Schafer and Dave Grossman and in this sequel to Maytag mention you return to the mansion with Bernard Laverne and hoagie to investigate and stop a tentacle invasion and this game will often come up if you ask people what their favorite adventure game is you know people just you know love the art style and the humor the kind of historical context so it really was you know made this a prime candidate for a remastered version and the

remastered version was released last year so you can now play the of the tentacle remastered on PlayStation 4 and Vita you know desktop platforms as well as iOS mobile devices and with all of these remastering projects our process really starts with game archaeology and what I mean by that is we essentially you know have to go through and identify and sort through lots of files associate with the original project or if you want we have to excavate the gaming artifacts which is a much more cool way of presenting the same thing now in this case it's meant that the team could go up to Skywalker Ranch north of San Francisco to look at the physical archives to scan some of these original concept art paintings for the concept art gallery of course for me as a programmer what's much more interesting is the digital game archaeology now the way the archiving process worked in the 90s at LucasArts was dead at the end of a project the acumen team would come and would make an image of all of the developers computers and this is what we got back from the archiving team so the first step really

was to go through this like long list of files they were often like conflicting or complementary and sometimes redundant to come up with some kind of master list that would you know form the foundation for the remastered version now for the remainder you know I'm sure you're not very interested in various documents and design documents for the so for the remainder of the discussion of their technical I'll focus on the source code needed to compile do technical the original version as well as the original binary pack files and before I'm gonna show you how we use that to create the remastered version I want to take you in a brief historical detour to talk about the engine to create the original version with now probably many of you know that the helical was created with an engine called scam now scam is an abbreviation that stands for script creation utility for maniac mansion so as the name gives away it was a piece of technology developed in the mid-to-late 80s at LucasArts for the cult classic

adventure game reenact mansion and in many ways scam really was a revolutionary piece of technology and I'll go into that a little bit more in just one second but of course what's much more important is that scam powered a lot of great games so here you can see all the twelve games made at LucasArts over a course of ten years and really I consider all of these kind of classics now I'm really curious who you and the audience has played at least two of these games please raise your hand Wow nice nice all right wait wait that's one more who you're in the audience has played every single one of these games Wow fantastic well then awesome now one thing you notice is that Grim Fandango is not in this list and that's not because I want to be mean to mark actually mark for later cover why grim is not in this list now as me is an adventure game fan as well was programmer the first question I ask myself is you know what made scam so special like why was it used for so many

fantastic games and what we figured out pretty quickly was that scam really was the first major reusable game engine because you have to bear in mind in the mid to late 80s it was still pretty common to write your entire game including the gameplay in seorim assembly now with scam the developers went a completely different direction by moving all of the gameplay logic into a high-level domain-specific language that he called scam so in other words Minik mentioned introduced scripting or at least popularized scripting in the games industry now of course scripting back then had the same you know benefits that it has now that is much faster and easier to you know write script and iterate on that and I really believe that this like improved turnaround time really kind of empowered the development human like you know help them to be more creative because they could try out various ideas I quickly like you know check this out and if didn't work they could just move on to something else now they're whole bunch of other things that scum really you know had mind-blowing features and I'm gonna be teasing you because I don't

have time to talk about it but if you're interested in that please finally after the presentation and I can talk about some of those now one thing I do want to mention those just like today the actual gameplay scripts the text version wasn't used when you know running these games instead they were turned into a bytecode representation that was then executed by the sputum engine layer now in addition to you know running the gameplay scripts speed him also did other engineer things like you know create a frame buffer and here was audio and input in memory and favio and whatnot now one thing that's kind of important here is that sputum was very portable and there was despite the fact that a lot a lot of the code in sweden was actually implemented in assembly so that would run fast enough on you know a Commodore 64 and other platforms but due to a design decision made from the very first version of scum that was that every single function in sputum had to have a C implementation it made this very very portable if that

really helped us with the mister remastered version because all we needed to do is to get the C code and you know make it compile and with modern compilers of course you know there were some changes we had to make because compilers had changed over the years but you know we had the game compiling pretty quickly now like I said in the beginning one of our goals was to stay true to the original version and we wanted to go further we actually wanted to run the original gameplay scripts with the original data against the original gameplay against the original engine in other words we wanted to run the game in the sandbox so as far as day of the tentacle is concerned it is still running on a dos computer in 1993 and then our remastering framework essentially just wraps around that so every frame we look at the internal state that scum has and then reinterpret that using the remastered content so for example in this case we asked the game you know which environment are you in well it's the office so we're gonna look up the textures associated with the office background and draw those instead of the original image same four characters you know which characters are

visible and where and what's the animation state you know we find that out and then we use the high resolution remastered animation sprites instead of the original sprites and of course you know the same applies to audio now this design has one major benefit and that is that the original game still produces a completely valid frame buffer which means we can very easily you know blend between the remastered version and the classic version now here is a specific example how that looks in the game and this really very quickly became a fan favorite you know people love like toggling back and forth between these two versions and kind of comparing them and as a program I kind of find it a little bit amusing because all we do is blend between two textures and do some translation but it just shows you that sometimes you know the simplest feature really can can add a lot of value to your to your game now I mentioned that we draw remastered content rather than the original one but so far I haven't we talked about where that comes from and despite what some people on the internet

might claim the remaster art is not created to some kind of automatic process or upscaling filter or something like that people on team will get very angry if you assume that every single image in all of the our remastered games has been hand crafted by an artist and this process really starts with content extraction so in other words we run some code on the original binary pack files to extract out all the images associated with the different backgrounds and doing animation sprites and other things like you know audio and you know compiled bytecode and stuff like that and because this will be the foundation the starting point for the art team for their remastered process and at this point we also do apply content upscale so here is a quick comparison between the pixel density of the original version on the left and the remastered version on the right so you can see there quite a lot more pixels that we can play with and you know this is really you know what we wanted to do as I said we've wanted to you know improve the fidelity but not

you know deviate too much from the art style we wanted to stay true to that original version but just you know make it more high-resolution now we can finally start actually looking at how you know these assets were remastered for environments these were painted in Photoshop and we had an automatic import process that would take these extracted upscaled images and turn them into a Photoshop file now you can see on the right-hand side the the scene layout is actually very well defined in using Photoshop folders and layers and naming conventions there and this would later become helpful for the exporter now once we have this we can hand it off to an artist and they will go and paint over the original version and once they're happy with what they have or just want to see how the current version looks in the game they can run an automatic export process that will then use the meta information stored in the same structure to export all the remastered high-resolution sprites at this point artists can also add additional images that might be necessary like for example

the outlines for the object highlighting feature is one of these examples or parkour sprites although we didn't really use them all that often now before I'm going to talk about how what tool we used encounter pipeline behind your mastering animation data I want to very briefly talk about how scum represented animations internally characters were represented to a data structure called actor and an actor video was just a packet of values they've had like position and scale and which environment they were in but it also contained a pointer to a costume so just like a real actor you know performing in a play before you step onto the stage you're gonna put on a costume and through the course of a play you might actually wear different costumes and so this kind of a similarity to a stage play you'll actually see multiple times throughout the design of skin now a costume internally really just kind of contains all the animation data necessary for a cutscene or a certain gameplay action so internally it's a truth tree structure that can have one or more animations each one of these animations can have

one or more animation instances called shores and I'm going to get back to those in just one second and then finally each chore or animation instance can have one or more animation layers there historically called limbs and this layered structure was used mostly to make it much easier to alter those animations back then but also to save like memory runtime memory as well as you know performance to have optimal performance because for talk animation that you can see here really only laverne's head is moving so the game represented this animation with one animation layer two had just one sprite like a static body and then one animation later just contained a head that would just do kind of various bobbing animations and whatnot now getting back to animation incidence this is essentially represents as an animation within a specific context so an example you can see here for walk animation the different Shores would represent two different directions because he would need to display different sprites obviously you know depending on which direction you would

walk in now the point I want to make you is that the animation data is actually pretty complex and we need to represent this for throughout the room a stirring process but not only that when Zdenek originally shipped in 93 it was considered to have a very fluid animation style and this meant and technical terms there are lots and lots of unique animation sprites that had to be remastered so here you can see all the nearly 8,000 unique animation sprites that had to be painted or repainted of course all like scaled down and we knew right from the beginning that we wouldn't be able to handle this internally like how the art department was actually pretty small and they were all busy just remastering the environments and so this really drove our decision when it comes to the tool now since costumes represent 2d animations we quickly this use flash which seemed like a very obvious choice so just similar to to the environments we have an automatic import process that takes all of these extracted upscaled images and brings them into flash so

there's one flash file for each costume and you can see there's actually the animation structure is represented in is flash file layer so kind of represented vertically through follows and layers and animations animation instances are represented through frame sequences horizontally and this layout allowed the animators to kind of scrub through animation very quickly and also toggle on and off layers to kind of compare the current version against the classic so as I said we sent us off to the outsourcing company they then painted over those and created like handcrafted representations and once they were happy with that he sent it back to us and we ran an automatic export process that similar to the environments would extract out all the the the remastered sprites and so again this is a environments and animations are like two very specific examples how we improve the fidelity and the remastered version was staying true to the original intent and staying true to the original version was also important in this room because as rumor has it when the original team was working on the other Senecal one

Gilbert came by one day and noticed that one environment in there the tentacle is actually as big as the entire game of maniac mansion and so you continued wouldn't be funny if you could just play maniac mansion within they were tentacle and of course if game developers we always do the most important thing first so of course this feature was added and you can actually play maniac mansion in the original version of day of the tentacle now the way that was done back then was pretty interesting because when the player interacted with the computer and weird weird adds room the game would essentially suspend the execution of the day of the tentacle process and then launch the McMansion executable now the playable interact with mimic mentioned executable until you know the playable time of that and then it would resume execution of the day of the tentacle executable restore the state and you would continue playing there the tentacle now I still have to admire like this is a pretty nifty easy way to like essentially embed a completely different game in your own game but for the remastered version we really didn't want to go down this world because dealing

with processes like that most did not seem like a very smart way especially on consoles and embedded devices so instead we chose the second most painful way by using or including the entire source code for manic mention in the game in addition to the entire source code needed for there the tentacle now admittedly they both use the same engine but different versions and while there are some similarities between those two versions there were actually pretty significant difference of course you know scammers has seen assembly code based so that means there's a lot of kind of global State and even sometimes these functions they at the same name they might have a very different implementation internally of course we all know the technical term for this for this situation which is of course dad so we solve this by painstakingly detaching these namespaces and making sure that minik mention uses unique namespace and this took us a while also to make sure that we didn't

access random memory and whatnot but it does work and in the remastered version you can actually play the original and remastered version of me I mentioned so I'm actually quite a quite proud of that now I want to shift gears a little bit because I want to talk about strategies we used to modify the classic game and as I kind of hinted at in the beginning just as opposed to fixed box that people could run into back in the 90s that we wanted to fix as well as issues that really only became apparent in the remastered version and I don't unfortunately don't have time to go into the reasons behind it but while we had a text representation of the gameplay scripts we were not able to recompile those so in other words we had to deal with the the binary bytecode that was included in the pack files and this left are there's two options to modify the original game now the solution we used most often was state mutation in other words we allowed the remastering frame but not only to look at the internal state and reinterpret that but to actually push values back into the

original scum sandbox and therefore change you know the behavior now another approach we used but not quite as often as bytecode patching in other words we would change the compiled gameplay scripts before T would be executed by the scam interpreter and therefore change in the behavior now I'm gonna show you essentially examples in this kind of combination although in reality every possible combination can be used now the first back I'm gonna discuss is this one now in this puzzle sorry there will be some spoilers unfortunately if you don't wanna use spoilers you know you want to cover years now in this puzzle you have to catch these T's that are moving away from you but span out but there's a back that if you leave the room kind of too quickly the game actually ends up in an available state so you can see at the top the incorrect behavior I'm actually pointing with my mouse at the teeth but the game reports I'm you know pointing and degrading what is supposed to happen

is what you can see the bottom where the game actually correctly reports that you're you know you can interact with the trap teeth and this is important because this is a you know object it's needed for the critical parts of the game and if you can't pick it up you cannot finish the game now by looking at the original gameplay scripts for this puzzle we quickly figured out what's going on so every frame while these T's are kind of moving away from you the game essentially checks you know whether or not they're close enough to degrading in the floor and if that's the case then a game was had a variable called teeth code to true then I will stop an animation that's supposed to move these teeth from wherever they are to the center of the grading that will wait for that and once that is done it will set a touchable flag meaning that the player can now interact with this object again now as a program I won't take you long to realize that there's a race condition here because of script execution is terminated for whatever reason like for example leaving the room the touchable flag will never be set and therefore you can never pick up this object now this may seem like a pretty bad issue but it

was surprisingly easy to fix because all we need to do is for you know identify this specific instance so if you're in a convention room with burnout the t-score variable set is set to true but a touchable flag is set to false then we found this issue and changing it was easy because the touchable flag is just a bit in a long bill array in the Spearin engine so we just essentially overrode a bid and therefore near the game you know could be could be played now the second bucket I want to discuss is one that we've fixed using byte code patching and there was a issue that only really appeared in the remastered version and it had to do with the intro cutscene now if you take a look at the top right corner you'll see there's a bur just kind of hanging out statically that's wrong and then it starts moving and then eventually they all just kind of all disappear at the end now I'm gonna focus for the remainder discussion I'm gonna focus on just this birds disappearing now again looking at the original gameplay scripts we quickly figure out what's going on essentially what the game does every frame it checks

whether or not the exposition of bird - which is the bird in top left corner you can still see is smaller than the center of the camera - and 75 pixels hmm a hundred and seventy-five pixels hmm well this behavior becomes pretty obvious when you oh but once you overlay the original four by three aspect ratio on top of this so what the gameplay programmer did back then is essentially cull against the original four by three view frustum obviously you know the person could know that we're gonna be master the game it's a 16 by 9 aspect ratio later on so we need to fix that we have extra pixels at the you know left and right side of the screen so the problem mr. hamund 75 is not a variable so we can't use state mutation like I showed you earlier there would be other ways to solve this problem for example we could change the implementation of the comparison operator or the subtraction to essentially trying to fool the engine into believing that the state is different but that seemed pretty happy for you know a bug like this but so we really wanted to change

175 now thankfully this is a little value which means that's actually stored in the byte code now here's the biker for the code snippet I just showed you so what we need to do is we need to find 175 which means it's time for a hex quiz [Music] now in case you'll be looking at this spot you're absolutely right this is 275 we're looking for and if we change it to something bigger for example in 250 indeed the birds will continue to fly to the left and you know this bug was solved and you know solving an issue like this with biker patching was pretty gratifying for me as a programmer because it made you feel like a real bad hacker you could go in like you know modify the byte code all right so this is all the time I have to talk about diode tentacle and I hope you found this interesting and now I'm gonna hand it off to Mark who is going to talk to you about grim fandago and you'll see that actually a lot of similarities but also a lot of unique challenges that we have faced with this project so okay thanks Oliver so we are

gonna take a trip from 1993 when day the tentacle is released all the way up to 1998 when Grim Fandango came out and we're gonna do a very abridged kind of evolution of technology and design that changed in the industry during this time so the next major evolution of the sputum scum engine was full throttle which incorporated full motion video as its kind of technological advancement which came from the rebel assault game and the insane technology is what it was called and so that was like one step in the direction but then between full throttle and grim fandago came quite a big change in the game industry and I think anybody who was a gamer at the time or a game developer probably remembers what was going on and that was the rise of real-time 3d so mario 64 was released Tomb Raider was released Resident Evil desktop PC graphic accelerators were starting to become a thing and these definitely had an

influence on the design of Grim Fandango and on engine changes that took place in that game I'm gonna guess that probably everybody here is familiar with Grim Fandango due to the number of hands that went up for 4 day of the tentacle and scum games but just briefly in case you don't know what it is it's an adventure game it's a story about Manny Calavera who is the character standing in the middle dresses death and he's a travel agent in the land of the dead and what travel agents there do is help people transition into the afterlife who are recently deceased and kind of the quality of your transport to the afterlife depends on how good of a person you were in the flesh world so if you were a bad person to get shipped up in a crate if you're a good person you get a ticket on the number 9 train and like all great adventure games of the era gameplay involves navigating through the land of the dead talking to characters solving puzzles managing your inventory and so on and it was very well reviewed it at release and many people consider it a cult classic or just a classic and so it's definitely primed for remastering

but the original team decided that they did not want to use the sputum scum engine because they wanted to add real-time 3d to the game and that was an interesting decision I thought and because I had been an intern at LucasArts and because I had talked to the lead programmer Breton mogul mogul F ski before I wanted to ask him more about that so I've got some details on why that happened but yeah they created this new engine called the grime engine and the grime engine supported pre-rendered backgrounds at 640 by 480 with 16-bit color and real-time 3d characters composited on top and it was the first adventure game at LucasArts to use real-time 3d now like the sputum engine its engine core was pretty darn game agnostic it was written in C it handled typical engine things like memory management resource management animation and so on and it really didn't know very much about what an adventure

game was so very modern but given that you must imagine that there had to be some kind of scripting language to actually implement the game and you would be right and given that there's this domain-specific language that had proven itself over many years and had shipped in many successful games you might think that they would use scum well that's where you would be wrong they switched to Lua and I believe this was primarily driven by Bret and if you want to ask about more details he's actually here now but yeah this was interesting historically I think as Brett told me that there was a lot of kind of internal contention to make this switch both to a new engine and to a new scripting language because some teams at LucasArts had tried to make the switch in the past and it hadn't worked out but Bret said he had a good dose of naive conviction and was able to convince stake holders and switch over to the new technology and so that affected our approach in the remastered engine and there are some similarities to what was

done in day of the tentacle and some differences we started out very similarly we took the grime engine we had the full course for both the C code in the Lua code and we got it compiling on a modern platform and so most of that was stubbing out a handful of things that you know we're old windows technologies that didn't make sense anymore initially and also fixing some compiler issues similar to day of the tentacle there were some you know undefined behavior and compilers had changed so but it didn't really take that long to get up and running the major difference between what we did with day of the tentacle and with grim fandago was instead of trying to mostly sandbox the original engine we made a lot of modifications to it directly and there's a couple reasons for that but we added things like a modern renderer to it and we added the ability for it to emit draw calls both to the original software renderer as well as to our modern renderer to support things like toggling between the two render modes like Oliver showed and day of the tentacle we added you know we threw away all the direct calls to

Windows because it had only shipped on Windows in the past and added modern interfaces to interact with the seven platforms we ship done we shipped on ps4 PS Vita Windows Mac OS Linux iOS and Android and here's where the big difference was when we added 64-bit support fixed bugs and added new features we did that by modifying grimed directly including the Lua code unlike the the tentacle project where we didn't really touch the original scheme code and part of the reason for that was that there were vastly more bugs in grim fandago but you know the we also changed I think more about the core gameplay in a way that couldn't be modified via state inspection only so that was another one of the reasons why we needed to modified directly alright so like Oliver laid out in our philosophy one of the key components is improving fidelity and staying true to the original artistic intent so this is

an image from the classic game and although I think it still looks cool there are some things that are starting to look a little bit old about it Manny's face for example the texture looks a bit low resolution there's you know some stair-stepping and so on within his face also the edge of his head on the 3d model is pretty aliased they're stair-stepping up and down both sides there as well his shadow is a bit of rectangle and we felt that we could improve all of these things in the remaster and I think it's important especially for a game like grim fandago where a lot of people are going to be familiar with it to have an immediate visual impact when people put up the game and immediately see something that that's striking so this is ultimately what we ended up with in the remaster and we're going to go into detail about how we accomplish this so at a high level in the remastered renderer one of the most important things we wanted to add was deferred shading and the reason for that was old 3d games

typically had very primitive lighting and grim fandago was no exception and we really wanted to try to ground the characters into the pre-rendered scenes better the existing pre-rendered environments had really cool lighting is really beautiful but the characters felt a bit like they didn't quite fit or any of the real-time 3d which included some objects as well and so by implementing differentiating we kind of gave our artists leeway to add a ton of lights into the scene like a new lighting rig for the remaster to try to really make the characters feel like they fit better into the into the scenes we added shadow maps to try to improve the shadow quality you can see some of that there on the left of course we had to implement arbitrary high resolution support grim fandago was originally 640 by 480 only so on all the different platforms we shipped on we had a whole bunch of resolutions we had to hit we implemented FXAA to improve edge quality on both most

platforms we had plenty of GPU cycles left over so this was kind of an easy win but critically I'm going to keep reiterating this we tried our hardest not to go crazy with graphics features and just throw all kinds of things at the game that didn't really feel like it would have made sense within the context of the original we wanted to do a better representation using modern technology of what we think the original team would have done if they had access to the same tools and here's a side-by-side comparison of the two on the left is the original game and on the right is the remaster and I don't know how well you can see it exactly but I hope you can tell that it's higher resolution on the right the lighting hopefully feels like it fits better within the scene the shadows are definitely very different but there is one kind of big elephant in the room between those two side-by-side videos and that is the backgrounds are exactly the same and that's because of a

roadblock we hit in the archival process in the archaeology process so the backgrounds were the pre-rendered backgrounds were authored in 3d in a program called Softimage and that's where they were modeled that's where materials were applied I believe that's where they were rendered out of as well and all the lighting rigs were set up but we had none of that data none at all and as far as I know it doesn't exist anywhere so Bret if you know where it is I wish we had gotten access to it because I mean at at a minimum it would have been awesome to just like open that data back up and rear ender those scenes using like a modern ray tracer or something but given our budget and timeline we couldn't totally recreate this data from scratch that it was just not an option so we did what we could but we were left in kind of a similar position of David the tentacle all of the remastering came from extracting assets from the game that had shipped initially and then we that kind of caused us to have to come up with some creative ways to be able to to improve

the fidelity so one of the easiest wins that we thought we could do immediately was improve the texture quality so we wrote a little tool that would extract all the textures from the original game blow them up to much higher resolution often going to like 1024 by 1024 maps and so here's an example of that this is Manny's face it's the same face texture we saw earlier and you can kind of see why you know the texture looks a little bit faceted and and it's not very high resolution so what it's Maggie's close to the camera it's gonna look low res and so we handed these off to the artists and this is the result for that texture and I'll admit that doesn't look super exciting really because it's just literally a higher resolution version of the exact same image but that's again coming back to the sticking to the original intent we didn't want to make Manny look different or shiny or anything like that we just

wanted it to be a higher resolution Manny but still totally keeping the original art style intact but when we're dealing with this kind of low resolution source data there are some interesting things that can happen and I want to show you an example from this texture so this is a tiny texture that was used on an object in the game and after it went through our process and got blown up it looked like this and this is what was handed to an artist on our team and who was tasked with remastering this texture and they weren't told what the context of this was they were just handed this and asked to paint it over and this is what we ended up with and this says go low flake this texture is not supposed to say go low flake and unfortunately the slip through the cracks and we ended up shipping this and there's some of the fan response yeah fans weren't happy so we did and we're sorry about that but we were able

to fix this in a patch thankfully and we were so tickled by kind of the response and the silliness of it that we put a bottle of go low flakes in all of the remastered games so there's one in day of the tentacle and we're sneaking one into full throttle as well all right let's talk lighting so like I said earlier lighting in early 3d games was often very primitive in comparison to what we have today so we are still facing a major problem that we wanted to remaster the lighting of the real-time 3d but we had no source data for the backgrounds we had no reference really to create a real-time lighting rig so our challenge was how can we create an artist friendly authoring pipeline to author lights for the remaster so what we did have though is the extracted data we had 640 by 480 color maps at 16-bit color for the the pre-rendered backgrounds and we had 640 by 480 Z bitmaps as the original team called them which were essentially pre calculated depth buffers

and in the original game these were used for occlusion mostly so that the real-time 3d would like if Manny was standing behind the chair on the lower left that it would occlude the the pixels rendered through the real-time renderer but what we did was we took these two maps oh we had one other thing I should say we also had the camera position in the orientation for what where this was rendered from and so I want to give a shout out to a guy named Brandon Dillon who is an engineer at Double Fine and came up with this idea but what we did was we took every single pixel of the Z bitmap one by one created a quad in Maya and then mapped one pixel of the color map onto that kind of doing like a reverse projection of that so if you're thinking of like well what would that look like and you're thinking this is gonna look like some crazy mess of quads just floating in space yeah it kind of does look like that there it is so this is Manny's office and this is a composite it's not just from one camera angle I believe there were four

pre-rendered cameras in this scene and this is the sea of little quads for all four of those and although you know clearly we're not going to be exporting this back into some kind of game format this was enough reference material for our team to be able to place lights I mean as I look at it and I hope it's it's obvious you can kind of see like where the walls are where the desks are where the windows are and so on and here's that same scene again with some of our remastered lights in there and to try to to match what was authored in the original backgrounds we had to add a number of different light types to try to kind of capture the mood so we had directional lights that could be bounded within a box or a cylinder sometimes it was a little bit hard to tell exactly what was going on in the original lighting rig so this helped control that and allow us to try to match it more closely of course supported point lights spotlights something we called a

gradient light which is essentially a ambient but also has a height component so that we could try to often darken the characters towards the bottom of the ground to make them feel more grounded in the scene and finally we added a little bit of light animation although this was really sparingly used in the remaster it was just kind of a like a nice little thing we could put in a little bit of extra polish here and there we didn't go crazy with it we only put it in places where it felt like it would have made sense within the context of the original game all right let's look at shadows this is the original game and Manny's got his Boxey shadow underneath him and although it certainly helps ground him within ground him within the scene we thought that we could improve this as well so like I said before we added shadow maps and we took those Z bitmaps and used them as a way to you know have a depth buffer available to us for when we're rendering from the lights

perspective in addition to that we added a feature we called light blockers which was essentially geometry that would be rendered when you were rendering from the lights perspective that would block light and create shadow and that was used for two things one to try to make the shadows match more closely to where the shadows were in the pre-rendered environments but it was also used in a handful of places to try to add some extra cool shadow fidelity that wasn't really there to kind of really you know added a little bit of extra polish and here's what it looks like in the remastered for this scene all right let's change gears and talk about controls this is one of the places where we really wanted to try to modernize delicately the original game shipped with something that is now notoriously known as tank controls that was the default control mechanism and I think there are some good reasons for why Grim

Fandango shipped with tank controls but most gamers these days don't really like tank controls that much so we felt that this was an area where we really needed to make a change to change the default in the game so this is what it looks like in the original I think little tank sounds chugga-chugga-chugga it's good to go and you can move forward makes it out of his office he's got turn to go down the hallway yeah it's a little bit unintuitive for people so like I said the original game shipped with ten controls as its default but I had forgotten this but it also had an optional camera relative control scheme and you know when I saw that I was like oh whoa I totally forgot about this like let's just turn this on and see what happens and it had some serious problems that we had to address to make this the default which is of course what we wanted to do and I'll show those in just a moment but as a brief side note I

thought it was amusing that it was just the function signatures from the Lua code you can see where the inspirations came from so 10 controls were called Tomb Raider control because the early Tomb Raider games had 10 controls and Mario style control was the name of the camera relative clearly with from the inspiration from Mario 64 I think all right so I'm gonna show three videos in a row here and I need you to trust me that all of them were recorded on the PC and I am only gonna do one thing I'm gonna put my finger on the up arrow and just hold it and then we're gonna see what happens with the controls so this is the first major problem in the original camera relative controls so you can see Manny bouncing back and forth across this camera transition and I think anybody who has worked as an engineer on a 3d third-person game probably knows what's happening as soon as the camera changes and in this case

it's almost perfectly rotating around the up axis by 180 degrees the frame of reference for how your controls are calculated flips and so Manny is popping back and forth across this camera transition because he is just bouncing back and forth and yeah your controls are flipping and it just it feels very bad frankly for for a player and so I think this is one of the good reasons why the game was shipped with tank controls because it didn't suffer from this and I don't know what genius programmer or designer came up with this between 1998 when grim fandago was released and sometime later but the solution to this is to maintain the previous cameras orientation as the frame of reference for your controls until some later point for example when the player completely lets go of the controls or has modified their controls enough to indicate that they've recognized the camera has changed and they're changing their intent so that's

what we did for the remaster here's the second problem Manny doesn't slide against walls very well in the original camera relative controls he eventually gets where he's going all right he made it out I don't have time to really go into the details as to why that's happening but clearly something wasn't working right with with how he slid against wok boxes as they were called which kind of defined the the walkable space and you know most modern games do this a bit differently and although it's not really realistic what games typically do is just slide characters along walls to kind of make it easier to navigate and fumble your way through environments so that's what we did so typically if you're moving against a wall directly perpendicular you won't really make any progress but if you're coming at an angle you'll scale the players velocity by the angle of incidence and then kind of slide them along to make it so they can move

smoothly through the environment and so here's a video of both of those things in the remaster and while it's not that flashy I think this was really a big improvement in quality of life improvement for the remaster so he makes it across the transition slides along makes it out of the office so that became the default control scheme for gamepad and keyboard but one thing that was surprising perhaps in retrospect is that grim fandago had no mouse controls every other adventure game that LucasArts had produced up until that point had had mouse controls and since we knew also that we were going to be shipping on vita and on mobile platforms who wanted to add touch so we were really blessed to run into this guy named Tobias faff who was a Grim Fandango superfan and was essentially modding mouse controls into the original game and he was doing that right around

the time when we started the remaster and we asked him if he wanted to join the team and he graciously said yes and helped us get this into the game but when you're adding a totally new control scheme to a game like this you can't just enable the mouse I mean there's a lot of work you got to do and one of the things you have to do is give the player a way to interact with the world so we added a verb skull this is something that Tim Schafer requested we do specifically and the verb skull was something that Tim put into full throttle initially a new way to interact with the world in that game whereas the previous scum and sputum games had all pretty much used a verb bar that was I guess Tim felt was starting to feel pretty archaic so in in full throttle you click on things and this flaming skull tattoo pops up and you can select different verbs to interact with objects in the world and so since Manny's a skeleton timotha that he deserves his own verb skull as well so it worked really well but I will say that we kind of knew this going into

it but I want to warn you in case you do every master that if you're gonna put a totally new control scheme into an existing game you should expect to run into a lot of special case problems and these were just all over the place in Grim Fandango and it's not a problem of the original game was just things that had to be solved to to add mouse controls or touch controls so for example this is Manny's inventory which previously had no UI on the screen at all you could interact with it with the keyboard but we had to add a bunch of things on-screen to do all the different types of interactions and navigation that were necessary so I want to show one classic bug fix that is interesting more for historical purposes and gameplay purposes than it is technically admittedly but this is an image from kind of in the middle of the game and this is from the original and that's Manny on the left and a character named Domino in the middle and there's a bug in this scene where Manny is supposed to be able to come in and talk to Domino

and be able to have a dialogue tree with him that kind of gives you critical story information and there's you know there's a bunch of VO recorded for this and it's it's really an important scene but unfortunately in the original game many play I mean it's dependent on what players do but almost everybody when they get here can't talk to Domino and I'm gonna show you why so here's a script called dlg underscore Domino Lua and these are the first two lines of code in that file so there's a comment that says avoid loading this file twice and there's a function called check first time and then there's a string called dlg dominate Lua that is passed in and check first time is something akin to a c-style pound include guard and will prevent the Lua interpreter from loading this file twice I actually don't know why this was here because it is valid to reload the same Lua and replace functions that had already been defined in fact that's how patching worked in

grim fandago but it was there and so this was from the the script that controlled the dialogue with Domino at the beginning of the game here's dlg dum - Lua from the same scene look familiar yep cut and paste err so this was thankfully very easy to fix but I thought it was kind of interesting in a historical context that this was able to we were able to add content that kind of had been hidden for a long time from players in addition to a ton of other things that we were able to address but I thought this was the most interesting because of the extra content so to recap we went through our philosophy and kind of showed how it was implemented in both games we stayed true to the artistic intent and both day of the tentacle and grim fandago not going crazy even though we sometimes had some temptation we improved fidelity where we could with higher resolution better lighting

improved textures and so on we modernized delicately we showed you the controls in grim fandago we didn't talk about this but Dave the tentacle we also changed the default controls to make it more intuitive we fixed original game bugs kind of showed examples in both games and although we didn't get a chance to talk about this really yeah the extra extras were kind of like taking inspiration from The Criterion Collection so from film it's like you know people who are really familiar with this material to try to give them something something meaty and valuable to chew on so Oliver and I both want to say thanks to Sony Disney and Lucasfilm for helping make these remasters happen thanks to Tim Schafer and Brett and mobile FC for helping us prepare for the talk thank you of course of the classic game teams to the remastered game teams at double fine shiny shoe and super genius and thank you to two player productions for help on some of the videos and thank you all for coming I think we

have time for a few questions yes and then we're gonna go to the wrap-up room just outside of the room so either you can find us here and we go there together or you just go there and we'll find you there maybe some of the strange question and now you're armed with all this experience of remastering are you planning to make new games howie's adventure market completely bad now we cannot talk about that hey so regarding the backgrounds in the scum game remasters it's my impression that the backgrounds were originally hand-drawn and scanned did you experiment with trying to recover either the original drawings of the original scans and use those I guess or since you didn't end up shipping with it um what ended up being the blocker that menu upscale and

retouch yeah we didn't really investigate that and I think what probably would have happened is we would have found a you know 60% of those and then the remaining 40% would have been lost somewhere throughout the archiving process and you know fast it was really hard to see because we want to be consistent and enemy would have the issue like around we have some of them we can rescan them but how we how do we recreate the other ones at the same style that Peter Chan and some of the artists like create them originally so the answer is is no because we kind of knew that there were some holes in the archiving process specifically did a physical one thank you hi were there any technical reasons for not increasing the framerate of individual animations and you can take that any technical reasons no this was again trying to stick to the original artistic intent we actually did some experiments early on with increasing the framerate I think to 30 so that's not right yeah but decided that that was moving in a direction that

made the game feel too different from what they were trying to accomplish originally so we decided against it for artistic reasons thank you good good all right so hi I'm Brett lead programmer of grim fandago by the way this is this is the crew shirt by the way the team shirt devata shirt so I have a question about the animation group at night go we had awful data loss from Softimage animation to the real-time game engine because at the time the only math we could really afford to do was linear interpolation so did you do anything to improve the actual like keyframe interpolation in agreement go remastered order to stick it just just because it was too I mean worth it was a reason to stick with it we did not know yeah I mean we would have loved to have done something more with all of the 3d data but not having access to the source material kind of put us on a path where we decided to try to make as many improvements as we could within the

context of everything outside of that but not push harder on on trying to replace the models or the animation so yeah keyframe animations there should be should be should be valid data I would love to see this presentation actually end up as like add-ons to the game at some point like this is actually really good information at that so thanks for all offered to you so once a girl ugh about pushing forward and having him go back and forth I swear to god we fixed that I swear to god that game - done ship like that and I when you saw it when you held it down I'm like yeah that he keeps going in that direction and then like you said he did I was astounded so what what well add it to your bucket wrecker yeah I don't know I'm trying to figure out who's responsible I think it thank you so and some other remaster games you know they've talked about like recovering like you know a bunch of the different types assets and and interesting stories around even audio like recovering old voice like you have stuff that's like from the original game data wise but in some remastered games they've actually taken those and tried to enhance them

either remastering either the music even digging into like the old technology at which these audio files were recorded on which is like you know come pretty ancient stuff for that I was just kind of curious if you could touch on that at all yeah I can so actually the guy who worked on all that stuff is sitting right here if you want to talk to him but yeah there was we were using I'm use which in both games which is the original LucasArts technology that supported all kinds of dynamic music and in the remaster all sorts of things happen yeah there was extraction from the original dat tapes correct me from getting anything wrong Trevor for like the vo - because we didn't want to use the compressed material in the games that had shipped for grim fandago at least there was live okay we're running out of time but there was a live live band recorded extra music to really try to improve the fidelity and Peter McConnell the original audio director was involved in all that so yeah there was a lot of

stuff unfortunately couldn't fit into this talk but yeah if you want to talk more after we're able to yeah so yeah I'm sorry but we're out of time because we just tried to jam in as much information as it couldn't talk um so thank you again everyone for coming and your you can find us outside [Applause] trouble with that sort of thing and because we don't localize graphics that is something we have to worry about because we can't change it for another language I'm sorry the second question was the web portal yeah so I don't know a lot of the details because again that stuff that engineers implemented what I'm told is it redirects based on the locale from your IP so if you don't I believe there's a cookie that gets set and if you're a first-time user and you don't have anything it tries to figure out where you are in the world based on either IP or browser settings or something like that to initialize it you

know considering a lot of like developers and publishers in the States or kind of like you know ignorant about localization and they usually production and that seems like there was a huge leap from 2012 to 2015 and whom can you tell me what exactly happened to change that mindset yeah well I mean I think at Bungie a big piece of it was they went independent so the last game that they'd published they were still a part of Microsoft and be an internal at Microsoft they had Microsoft's localization team to work with localization had never really been something they needed to worry about internally it was something where towards the end of a project someone who who had another job would just be tasked with you know okay get the strings together to do a localization handoff get those assets implemented back into the game but there wasn't a need to have dedicated internal people so it was a combination of that I think and also just building this new IP and wanting to do things right and build a global brand

they wanted to make sure that we were taking a good approach to localization it's hard for me to say because I I came on after they'd already decided to start building a localization team internally so yeah half-half answer but sorry additional questions there all right thank you [Applause]