The Early Days of Id Software - John Romero @ WeAreDevelopers Conference 2017

[Music] [Applause] [Music] thank you very much I'm holding okay go ahead everybody yes okay all right finally I'm ready all right all right well welcome everybody I'm John Romero co-founder of his software and I'm going to take you on a journey back to the beginning of its software are you ready to be entertained yeah all right I do realize that some of what I'm about to say may sound insane but we were in our 20s when we started a software and we didn't know that there were any limits so I grew up in this wonderful small town in Northern California named Rockland population was only six thousand people so in the 70s I was massively addicted to spending loads of time in decades and playing all the games there and getting really good at them with anyone else in our case over here now yeah there are some people well in 1979 it looked like this before anyone had a computer at home including me I went to the local college when I was 11 years old and I started learning basic from the college students I just went up to them and I started asking what the words were on the screen that he showed me their listings and I just started writing down the words and started experimenting with them on this HP 9000 mainframe that was in the next room so to keep me at home my parents got an Apple 2 plus so I was done going outside I spent all my time programming games on that computer so a few years and 20 Apple 2 games later I finally learned 6502 assembly language it was a language that all fast arcade games were written it then I could really make some 80s games like these except not quite not quite arcade games about home computer games which were on the Apple 2 so we'll just say that the Apple 2 was my personal home arcade as well as 1 million other Apple owners so when I was a sophomore in high school which was I believe second year of secondary school here I did some programming for the Air Force when I was 15 years old we lived in England than and my step father worked for the Air Force so in order to get into the high school programming class I had to show the teacher that I could program in 6502 assembly language and I ended up at the aggressor squadron the next day so it's literally coding in a bank vault and because I was a kid they gave me false data to use with my code so I can't tell you what I was programming because that's classified it's odd but a true story so after high school I kept making games and by 1987 I was working at origin systems my first job was porting 2480 an RPG from the Apple to the Commodore 64 so by this time I had made 74 games in three previous games startup companies which were these capital idea software inside out software where i ported Might and Magic two to the Commodore 64 which some of you may have played I think yeah and the company called ideas from the deep and I was 21 years old so went to work at a company named soft disk at the start of 1989 and I learned how to program a DOS PC there for the first time and was making a small game or utility every single month for about a year then I created a game product called gamers edge at soft disk and I had to hire a team of game developers so it's fine only going to have a team so I hired John Carmack and Adrian Carmack not related into my department for programming and art and then Tom Hall came in at night to help us out since he was already softest and he loved making games so this is the first time that any of us had actually worked with another person on a game we had been making them all alone for ten years each and it was pretty incredible so while creating our first game together floored ax which was the screen a couple screens ago John Carmack discovered what we call the smooth scrolling trick on the PC so Tom Hall and John stayed up until 5:00 a.m. making a demo called dangerous Dave in copyright infringement because it was basically a ripoff of mario so the next day I saw the disc on my desk and I ran the demo and I watched the screen scroll smoothly pixel by pixel and it was a massive Eureka moment for me it was like a bolt of lightning so I'll elaborate why in a moment but it's software was born that instant on September 20th of 1990 so one thing led to another and we spent a week putting together a demo of Super Mario 3 for Nintendo we had the cool scrolling tag why wouldn't we use it for Mario obviously so we sent it to Nintendo they really liked it but they decided not to publish our game or to take on this port because they decided to only publish their intellectual property on their own platforms so this was a Nintendo which was a pretty smart move so no problem we just use the technology for a different game which was called the Commander Keen trilogy yeah Commander Keen anybody to remember Commander Keen a few people so why would a side-scroller be a huge hit in 1990 well because no games on the PC could scroll horizontally smoothly per pixel on the PC which had been out and available since of 1981 but in nine years no one had figured out how to make the screen scroll smoothly per pixel until the dangerous save and copyright infringement demo which led to Commander Keen so does anyone remember the original duke nukem game pictured here alright duke nukem so it scrolled by in chunks of eight pixels like other games of that era which was why Commander Keen was such a revelation so the reason why it's duke nukem scrolled with any speed is because I taught todrick logo how to do it while he was programming the game called Dark Ages the game he made just before duke nukem so the Commander Keen trilogy provided the start of its software and we made these three games in three months it's probably about two and a half from September 20th to December 14th so it was a massive hit for us and it was super popular people cosplayed as commander keen 4 years at events so the game pioneered the creation of game engines we designed the game as an engine that operated on different data for different games so the only way to get the trilogy done so quickly in fact in 1991 when we're working on keen 4 we started licensing the engine for the first time so as the beginning of the modern engine licensing business so development on our game isn't very very smoothly because in quickly because we've stuck to some core principles that are important even today so through the talk I'm going to highlight some of our core principles that is software I'd like to highlight something else right now namely this photo is anybody seen this photo before yeah no probably not well it's a picture of us at our lake house in Shreveport Louisiana when we were starting to make games together so the funny thing is that people have asked me for years what is in this picture so I analyzed it recently and decided that I'm going to show you what's in here this is see so this is John in me in early September 1990 we were working on the Super Mario 3 game the Super Mario 3 demo that we planned on sending to Nintendo we both worked on the huge DMD table that John had we used to play D&D on the weekends and those sessions led to the ideas for future games like doom and quake this is so this is this is us again there's a whiteboard here computers were brought home on the weekends from the company don't do that you need to have your own computers at home back then it was hard to get a 386 so this pic was taken on a Saturday or Sunday because we worked at home on the weekends on the game on top of the monitor is one of those old Intel reflective astronaut plushies to my left is my notepad which is a task list of bugs to fix and that's our high level task list of what had to get done the finish the demo and this is Tom Paul's area where he was doing all the graphics for the demo he recorded gameplay on a VCR and he played it back pausing the action so he could duplicate the tiles of Super Mario 3 exactly in deluxe paint 2 which was the Photoshop of the 80s so the TV set had a 13 channel selector on it and it was connected by an RF modulator so it's very old-school so it's software was founded formally on February 1st of 1991 and we made 12 games that year Shadow Knights danger saving the Haunted Mansion rescue Rover hovertank love a little love so we actually took two months to make each game but we made two games simultaneously and this was due to us having 10 years of intense game development experience prior but it was also due to our first principal back then we had no prototypes just make the game polish as you go you don't depend on polish happening late I always maintain constantly shippable code this is how we made so many games so quickly we had the entire game in our heads we knew what it was we just needed to quantify what needed to be done and then went about working on it until the game was finished so there were no prototypes for our early games we just made them so remember we were a small team of four people and we could do this back then large teams definitely require more planning so here's a quick story one day it rained really hard and cross the lake in Louisiana rose up and it was flooding everywhere and I needed to get to work like we were working furiously on our games and I had the it back in keep on coding so I just got ready go down the street in the car and everything can saw this the entire road was flooded so basically I got out and I waited through the floodwater dodging water snakes all the way to the house where we had it software and it took another shower and then got backed back to work we were all so excited to be making our own games 24/7 you know also note that during this year of 12 games that we were making we also moved its software from Louisiana to Wisconsin so that takes a lot of time out of game development but we couldn't afford to have anything go wrong while we were making our games at such a pace that we created another principle that kept us developing quickly so it's incredibly important that your game can always be run by your team bulletproof your engine by providing defaults on load failure so if you have a hundred people trying to develop a game that will not run you're paying for a hundred people to sit around and wait for it to get fixed so we recognize the importance of keeping the game always playable and decided to bulletproof the engine by making all the input solid game engines typically fail because of trying to load bad corrupted or non-existent data so checking for this in providing a standard default for a failure case will keep the game running quickly you know and show you what's missing so if you fail to load a sprite you're trying to load a sprite and fails to show a bagel so the things on same songs not working play something horribly wrong for the game if you're missing the sound effects do the same thing something really annoying so after 1991 its software's first stage of company development was complete and another important principle within the sect at this point keep your code absolutely simple keep looking at your functions figure out how you can simplify them further we wrote all of our games up to an including quake in straight C know C++ so stage 2 is about ready to begin for us in August of 1991 we decided to move to Madison Wisconsin so Tom Hall and I visited at that time and we found it to be really nice as tom used to live there while he was in college so moved all four of us up there and we continued working on our games only four months later we were found dead in the snow victims of Wisconsin's brutal winters that we did not research so the moral of the story is do your research we knew how to program an assembly language but not to ask Tom Hall Hayes what our winters like up here so after six months we moved to Texas so we had new principal great tools help make great games so spend as much time on tools as possible I wrote a tile editor a 1991 named Tet for tile editor Ted was used for 33 shipped retail games several of which were even 3d games like hovertank catacomb 3d Wolfenstein 3d spear of destiny rise of the Triad corridor 7 and others so it was January 1992 and we decided to go all 3d based on catacomb 3ds promised to this game here it looked cool it just didn't play very cool so Wolfenstein 3d took four months of development to get to its share were launched with one episode of levels and it took two more months to finish all six episodes and to write a handbook for this game in the first month it sold 4000 copies all priced at $60 each the spear of destiny took two months it was a prequel to Wolfenstein 3d and it was retail only and soon after that Tom Hall traveled to Kentucky to work for a couple months on Wolfenstein VR yes this was 1992 VR so it was awful back in the days of Commander Keen I had discovered a small three-person game company named Raven soft Raven software while I was up in miss Madison Wisconsin and I called them up and went over and we introduced ourselves and flash-forward seven months later and we did Lord with them they modifying the Wolfenstein 3d engine and then licensing it to them for a game called shadow caster shadow casters tech improvements were sloping floors lighting in the fog this engine looked slightly better than Wolfenstein 3d but it wasn't good enough for our next game so John Carmack spent some months thinking about how much more advanced this new engine should be for the game that we decided to call doom yeah based on the rapid development of our previous games we came up with another important principle we are our own best testing team and if you'd never allow anyone else to experience bugs or see the game crash I know it seems impossible but don't waste other people's time test thoroughly before checking in your code no throwing it over the fence for testers to find it and put it in a bug report and then you get to fix it later it's a wasteful cycle let's do it right then so after 1992 with software a second stage of company development was complete along with another principle as soon as you see a bug you fix it you do not continue on if you don't fix your bugs your new code will be built on a buggy code base and then ensure an unstable foundation if you check in buggy code someone will be writing code based on your bad code and you can just imagine the cascading effect there so the ideas for doom came from our D&D campaign which was full of demons we also love the movies Evil Dead and aliens so dooms design was a mash-up of ideas at the beginning of Doom's development we created a new core principle which was use a development system that's superior to your target to develop your game so before doom we were making games for das while we were developing on das and we knew that we could do better if we use more powerful computers in a more advanced operating system to develop our games so we developed doom on next step workstations that are far superior to das next step eventually turned into OS X / OS 10 and this also meant that one of our core principles was upheld which was that great tools helped make great games so we could make far better tools on next step Doom add in quake ed were two of the most important tools that we had and this was a screen from 1993 which you would not find in das so these tools they really helped us create levels and to test them very quickly so you might not have known this I have but we had 5 people on our team creating doom after Tom Hall left during doom we hired Sandi Peterson and David Taylor which brought us up to six people so unbelievably while making doom we had to stop all game production and create the super nintendo Court of Wolfenstein 3d as fast as possible so because we were starting from scratch never having programmed a Super Nintendo it took us three weeks because we had the the hardware then we jump back to making doom again can wasting time so we uploaded the shareware version of doom to the University of Wisconsin server on December 10th 1993 so the excitement for the game was unprecedented people were creating files in the upload directory that were sentences like when will we see doom we got random phone calls the office asking when it would be out so a quick story during the final days of Doom's creation we worked 30 hours 30 hours of the day so he had the game running on all computers in the office to ensure that it was solid however on a couple of computers the game froze up so the menu could be brought up at the gameplay stopped John Carmack thought about what could possibly be happening and he figured out the solution without doing any debugging so he was correct in his solution we finally uploaded the game after the 5 minute fix and more testing so the beginning of 1994 I started working with Raven software and developed heretic using the doom engine anybody here play heretic yeah heretic I wanted to see how an inventory system in a man in a medieval version of Doom would play out so it turns it turned out great and who thought the result was was excellent we want to keep on working with them so we also made zoom 2 in 1994 took us 8 months and it was released on October 10th so in addition to this we did the Jaguar doom port ourselves so again we were multitasking and making multiple games so two games in 1993 and then three games in 1994 in 1995 we started working on quake we had nine developers meaning four designers three coders and two artists so I was the only one to do both coding and design I wrote quake ed and experimented with level design in full 3d again we started with a clean codebase we had no code from doom using quake which was basically another of our principles of development was write your code for this game only not for some future game you're going to be writing new code later because you'll be smarter also you're not tying yourself down to the limitations of your passcode so invent new things so quick tension was being developed by John Carmack and the rasterization was by Michael Abrash people here know Michael Abrash Michael Abrash is an awesome programmer you should all know who he is look at dr. Dobbs Journal if you want to you want to see Sir John cash worked on the network code in John cash went on to become the lead programmer of World of Warcraft so another quick story this relates back to our belief that developing in a superior operating system can result in a better game so while making quake we made a deal with crazy per computers to buy a Cray 6,400 super server for half price so our plan was to have our development team connected to it to BSP in light our maps as well as crunch whatever new kinds of data that we would create with our next games engine the computer room in quakes DM 3 level was going to be full of Craig computers as a reference to this new hardware that we're going to acquire unfortunately Cray was bought out by Silicon Graphics before quake was finished and the whole deal fell apart so the computer room in quake was filled with the usual rectangular mainframes and so that Z shaped Korea computers sound for publishing heretic I started working with Raven on hexon I wanted to see how an FPS would play with a hub level system and character classes in hexam launched on October 30th of 1995 during a deathmatch event called deathmatch 95 that was happening at Microsoft's campus in Redmond anyone here play Hexen yes good it's a good game so month later I got Raven started on my next game design which was called hecatomb he would be the third game in the series heretic Hexen and hecatomb but hecatomb was never finished it was turned into Hexen - because I had left his software at that point it's so and it also was not the same game design during this time we noticed a small game company making some nice games like raptor call the shadows and we brought them down from Illinois to Texas to make a game that we would publish they called themselves rogue entertainment and about 14 months later they released a game called strife which used the doom engine anybody play strife was an FPS RPG and it was really really fun and it's on Steam right now it showed that by combining genres we could actually make a really fun fps nowadays we have games that are you know fps RPGs like destiny in other ones but strife came first also during 1995 we made the ultimate doom which was a retail version of the full version of doom with an extra episode that we created specially for it and the master levels of doom which was a 21 levels plus thousands off the internet so with software was still 9 developers in size we released two games in 1995 while we're working on quake work continued on quake and 14 months after starting we released queue tests on February 24th of 1996 for the world to test our internet gameplay during the next four months we worked very hard to complete quake we also released final doom which is created by team TNT and the Kasauli brothers and Death Kings at the dark Citadel which is an additional set of levels for hexlen so one important principle that helped us get quake done faster was this one encapsulate functionality to ensure design consistent see examples of this in quake would be simply the torches that were on the walls we could have made us level designers place a torch model and then a fire model and then a torch sound entity you know all at the same location but then if we needed to move a lot of stuff around you know something could have gone gotten left behind it was far easier to just create a torch entity that had all the functionality already built into it so also the water in the game needed sound effects as well and we needed to play sound entities all over the place to fully cover all the water areas so you would hear it everywhere but if the water got modified you know then moving all those entities around and deleting them and all that stuff that would have been a big mess so it was easier to just make the game play water sounds when the water was actually being rendered on the screen so as a renderer level feature and it was out of the designers hands which ensured consistency and it saved memory so we did the same thing for the sky audio and quake as well I released quake shareware on June 22nd at 5:30 p.m. on the University of Wisconsin at Madison's website time for another quick story so while Michael Abrash was programming the renderer he was interviewing CPU instructions with FPU instructions to calculate perspective correct texture mapping so sometimes while he was playing the game on for just one frame the game would show a completely different place in the map so he isolated the only instruction where they could possibly happen and determined that it was impossible for it to be an invalid value basically to return a zero so he had a friend from Intel come to the office to go through his code and go over his analysis and his friend agreed with them and told them that there was a known error with the floating-point divide instruction on the Pentium it was a hardware error because the computer was overclocked so there was nothing that we could do about it so we left it alone so this bug is actually known as the pentium fdiv bug you can find that on wiki so quake is a game that introduced the world's mouse look high-speed true 3d and internet multiplayer clans sprung up immediately as did eSports and tournaments everywhere so quake World launched 5 months later so making games was and still is our life like we love it more than anything else as you can tell by our release of 28 games and 5 and a half years by less than 10 people many of the games were released that user license technology over the years so here are some more core principles that we learn from doing all of this work try the code transparently tell your lead and peers exactly how you're going to solve your current task and get feedback and advice do not treat programming like each coder is a black box the project could go off the rails and cause delays programming is a creative art form that's based in logic every programmer is different and will code differently don't wait basically don't waste time focusing on a rigid coding style it's the output that matters so we keep making we keep working to make great code and it's in our blood as I'm sure it's in your blood as well as why you're here it we are developers you want to be the best so go be your best and thank you very much for inviting me to speak here if we're developers and I'll do QA right after this thank you [Music] okay now we need a microfilter well first of all we have a question here that people are someone's put through the app this is from person whose name I'm not going to attempt to pronounce what is your favorite game that's difficult I really like a little Warcraft a lot Chrono Trigger was previously my number one game for a long time and it just made number one RPG of the top 100 RPGs just a few days ago on an IGN on IGN list I really like Ghost Recon a lot the original Ghost Recon but you know minecraft and Wow or probably the two games I could just jump in and just stay in so I'd have to say that those two you're kind of even nice okay now you can still sending questions because we need some more does anyone want to shout something out and I'll repeat it so everyone can hear any hands one guys you will not get this opportunity again yes right here what is my favorite programming language right now I think it's Lua I really like it we're doing a bunch of work right now in unity and c-sharp and and we've been using Lua for years and if you're not a game developer you probably be surprised to know how many games are made in Lua has anyone here heard of grim fandago awesome game that the game is all Lua in fact Lua controls the game engine it's the main loop versus the game engine being the main loop but a lot of games use Lua and just hundreds and hundreds of games have been published with Louis World of Warcraft uses Lua for all its UI so I'd say Lua that's because it's a kind of the perfect language to teach people how to program in and it's powerful enough that you can make games that our performance all right now I certainly got tons of questions here well done thank you here's an interesting one do you think your principles that you outlined here can be deployed nowadays in the game industry oh definitely yeah I mean that's kind of I gave this talk to King calm for the first time and to 700 programmers so I think there's more here and and you know I think with the exception of the no prototypes which is just a need software only kind of thing I think pretty much everything else is extremely important and there's other things that that we learn from developing that are I think still really true and really help developers basically progress faster one probably one of the biggest pieces of advice that I have is to when you're programming only program for maybe a few minutes and then test your code immediately don't write code for half an hour even you know because now you're getting into a lot of deeper bugs versus something that's that's pretty quick so if you write just a few lines and you run your code and it breaks you know exactly where the problem is versus a half hour writing a whole system or a bunch of inner leave functions now you're diving into a bunch of code and trying to figure out something that may have several levels of error in it versus you just typed a few lines and rabl the test your code and you know exactly what the problem is so you avoid deep debugging if you just test your code quickly so highly iterative development I think is pretty much the best thing you could do all right I've got really interesting one here from Mach oh and I also had this question of Iran which is what did you use for version control back in the day version control did not exist back in the day for us so I mean starting in the 80s on the Apple - you had a floppy disk and if something happened to it your code was gone like there wasn't even really hard drives back then to kind of save it and backing up man you had to have two drives so you copy from one disk to put on another disk so even with his software our version control was the fact that everybody had a copy of all the code on everyone's hard drive so something happened you could just copy it over and at the beginning before before the end of 1991 we basically use this copier files onto disks and just pass disks around so I used to draw all over the disks so everybody had a special disk just for them and so it's like this is Romero's fortress or whatever and you know everybody would have their own little drawings and stuff and some of those are we still have those disks around but those were our copy wewe tried anything that we could we tried serial cable stuff and it basically came back to just sneakernet walking floppies back and forth until we got a an actual heart a hard drive file server Novell NetWare three one one file server in November of 1991 and in I had mentioned that John cash was the network programmer for Quake we hired him from Novell directly to it to do that and anyway so we're we were big fans of Novell back in the day so then my first version control wasn't until probably 2000 and no it was probably 1998 I'd say with a sourcesafe okay and so nowadays I prefer SVN for you know more indie kind of projects and then perforce for game projects and because we make games in the same location I don't use git because git is really good for big distributed groups mm-hmm so wouldn't use it good all right I'm sure there's going to be some nightmare tonight from the floppy disk story all right Blas asks opinions on LP versus functional programming in game des do you have opinions on this I think functional is something that people like to do because it's cool I think it's lame walk sock it's fun to take procedural code and turn it into functional code I think that's a cool thing to do but it's not performant and when you're making games you have to do it quickly I'm not saying we use go twos but but we don't use functional programming just because it's it's a little too restrictive we need global state you know we don't want a ton of returns from functions that are nested so yeah we we functional cool this hasn't rung it's like some programming but we we just do it just because sometimes it's fun to do it and it's not actually in the game it's just like oh I turned it into a functional I turn all this into functional code it's pretty cool okay it's cool and logic sense right all right and see what we have here okay from Andrey Andrey asks would you publish a game in steam first if you develop a game nowadays or would you rather publish it yourself well publishing yourself doesn't mean you can't put it on Steam so we just made an indie game called gunman taco truck and it's about your last Mexican in the United States any start in San Diego and you are trying to get to Winnipeg Canada where they have no taco truck from they need tacos really bad and so this is post nuclear apocalypse so the United States is basically turned into all mutants most of the animals some of the humans have become mutants and in your job is basically to go down the highway to the next sanctuary city blow away all the mutants are trying to destroy your taco truck because you have a big gun mounted on top you blow everything away and when you blow stuff away you pick up the meat because you're serving that meat in the next as tacos so you're serving up the roadkill to everybody and then you're moving on to the next town and so at all all the roadkill changes all the tacos change and you're just trying to get enough money to get the gas to get to Winnipeg it's a really funny game I got to take that out okay Florian asks VR and game development how do you see the future I think how do you see the future of the eye in game development I think VR might be cool for level design I think it might be fun to do design and in that I haven't felt any limitations doing level design it with you know with 2d monitors so we'll see I mean I haven't tried the Unreal 4 stuff yet but I know that they have er oculus headsets working with the the level design tools in there most of the time though when you're doing stuff in a modern editor you're placing static meshes versus doing BSP stuff if you're doing BSP it's kind of temporary because the goal is to replace all the BSP with static mesh so you're really just doing a lot of placement so you can do it in VR or you can do it on a screen you still 3d no matter what it just depends is it more fun probably more fun in VR all right and here's one from Tom who asks how did you not get distracted and just spend all your time playing games no internet in the 80s there was no internet like I didn't even have a modem until probably 88 I think so there was just not there's nothing pops up on your screen your computer could only run one thing most of the time it was running a command prompt and then you would run your program so there's zero distraction phones back then we're crappy so like we did get phone calls so we just kept making games that's all we did so we would go have food come back there's zero distraction and nowadays it's insane right now adays have fun not being distracted trying to do anything so you actually have to be super disciplined nowaday mean we were really disciplined back then nowadays I think you have to be even more disciplined to keep yourself super focused you have to like hug me basically quit out of everything and stop background tasks or anything yeah I'm not sure exactly if he meant distracted from other things I'll distracted from playing the game itself that you're making right now well you have to play the game that you're making it's really important really big dev teams a lot of times they don't play the game that they're working on and that kind of ends up in being a game that's less than stellar but it's really important to play your game and make sure that it's fun and it's doing well and it's fast and you know it's at the point that you're making your game if you could release it right then it should feel fast it should not be buggy and it should be fun and that should happen all the way from alpha until you actually do your release before that point sits completely unfinished right this person is everyone else yeah oh yeah how do you make sure that your game is going to run fast when on mainstream machines versus the development machines so it's important that you have normal computers at your office that you can test your game on so you're developing on crazy machines and then you basically get a machine that is you can buy crappy machines it's pretty easy just buying you buy some and you have any of your company and you test it on that so if you can when you're working with a publisher you kind of as soon as possible you determine with the publisher what is minimum spec for for this game and you get that computer and that is the that's the lowest that you can go so you make sure that your targets are kind of being hit every time you make new builds you can go run them on that and if you have a really great build system to use Jenkins and you have push notifications to slack and all the kind of cool stuff and you have really good unit tests you could actually use bots to measure frame rate on the crappy machine to make sure that you know you don't have to have a QA person running through it and in telling you it runs badly in some area you could actually have unit tests and stuff to actually do that for you all right Michael all mikail asks what advice would he give to people that want to start making games my advice is to go home and do that right now there's no reason why you can't make games today there's nothing stopping you no one you don't need permission to make games because I've had to tell people forever you can go and download everything for free all the information that you need is free everything is out there everybody is run into all the problems are all on Stack Overflow you know you basically just start making games immediately and my advice is start small make very small games something that you think is ridiculous like pong have fun making pong if you're not a programmer you know and you need to learn how to make the game so if you're not a coder don't shoot for the stars that you're not making an RPG try to make something like pong and see how that experience goes for you then try to make space invaders and then try to make pac-man you won't still even see how hard it was to make those games when they were created in the late 70s and in 1980 but you'll get a sense of how hard it is just to make a game run well and just to architect a game good so do it I would say use Corona SDK at kernel apps calm which is a Lua based SDK that does not put you into an IDE it's basically use whatever editor you want sublime whatever and and you just have your your simulator over here your code over here both on the same screen type in some code save it it reloads it's being super iterative almost the way the Swift 3 has playgrounds but this is cross-platform this goes on Windows desktop Mac OS X desktop Android in iOS so you can have your your game on all those platforms could you say the name again it's called Corona SDK Rhona if you just do a search for that you'll if it's a dream it's amazing cool all right we've got time into more and I've got two questions about bugs all right so first of all Paola asks what is your favorite bug that ended up as a feature in a game if such a such a thing exists to use I don't know if it's a bug so silent BFG in Doom does anyone know about that the silent BFG so if you're playing doom when you make a sound as a player you have one sound channel for the player so every sound that you make is on one channel and you can cut off the your own sound in on that one channel because there's all these other sounds going on especially a multi player you're going to hear other people and all the stuff going on in the environment we had to make sure that the player sound was dedicated on the channel so when you shoot a gun that makes noise when you hit the wall you go on the wall because you're looking for secrets hopefully that makes noise but I will cut off other sounds and so the BFG when you start it up it actually has a big long build up before it actually takes off and so if you fire the BFG while you're in front of a wall and then you hit space you cut off the sound of the BFG and that's network cut off as well that's not just local on your machine it cuts it off over the network so the other players and deathmatch don't know you just fired the BFG then you basically just step out and they think you didn't do anything into being way to be FG work is very special you could launch the BFG into one room strafe over and look in the other room and when it hits the wall on the other in the room you fired it into you'll kill everyone in the other room it's a really crazy way this program that you take advantage of the silent BFG trick and then the way to BFG works and you can just like destroy people pretty quickly that was a cool feature that sounds luckily for me it's definitely a feature alright and the last one we have also unbooked we like to hear other people's pain as well what was the most time-consuming bug you have personally had to deal with what was it there was a bug when I was implementing compression as it really does if compression and decompression on a Power Pocket PC platform device and there were a lot of issues while there were two problems but there are a lot of issues with that one the API was pretty badly documented and when I finally got it working what I did was I had it up the hundreds of files into one big zip file and when I was trying to pull files out of that they had to decompress basically the whole thing to get at that file which is a really bad way to for me to organize my data I found out that the best way to do it is if every little individual piece of data and then just pull it out and unzip it that was like an eight-hour nightmare because of the way that you have to work with pocket pcs or yeah it was Pocket PC back then and then the other one was the first time I was trying to connect Lua to my C++ code Lua has a C interface that you basically go from Lewis C to whatever and I was using to do it quickly I was going to use a whole bunch of other people's glue Lua glue and none of that stuff worked and it was taking I was on my fourth day of trying to get it to work and I even had an expert an expert person who had gotten me into Lua those trying to help me get it working and finally on the last day I was like I can't spending more time on this if I don't get this connected I'm not using the language which would really suck because I think the game would go a lot faster in development if I had it connected so I finally basically said I'm not using anyone else's garbage I'm going to look at the Lua manual and I'm going to read what it says and do it myself and took 30 minutes because ridiculous stupid reads manuals do that and do the work yourself PM uses take note yes alright well I think I should show you if you go on for hours with this we've got more to do so I would like to say big thanks to John and ebony everyone give them a round of applause that was absolutely fantastic alright thank you [Music]

Channel: WeAreDevelopers

Views: 108,987

Rating: 4.958457 out of 5

Keywords: John Romero, The Early Days of Id Software, WeAreDevelopers, Conference, WeAreDevs, id Software

Id: KFziBfvAFnM

Length: 50min 5sec (3005 seconds)

Published: Tue May 30 2017

Reddit Comments

[u/[deleted]]

He never gets tired of telling his story, and as a 90s kid who grew up with Keen and Doom I never get tired of hearing it.