Tommy Refenes - Programming games. The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company. I remember maybe 5 years ago I emailed a M.I.T. professor after seeing her on a PBS special talking about AI. I poured my brain into an email to her about my theories on AI development, how machines can be programmed to recognize environments, how emotions can be learned through experience,etc.
I spent a good 4 hours writing the email because I felt a connection to this professor’s work. It was an exciting email to write because it was something I was very interested in and I wanted to reach out and talk to someone about it. There was so much hope while I was writing it that maybe I would get a response back and I would have someone to talk to about this kind of stuff, maybe get me started on the path to creating advanced machine AI. Where do I start on my dream game idea? Conclusion. Game timers: Issues and solutions of variable framerate. December 25th, 2012 When I started game programming I ran into an issue common to most aspiring game developers: The naive infinite loop resulted in variable framerate and variable time difference that made the game nondeterministic.
It is a problem that Supreme Commander/Demigod developer Forrest Smith described well in Synchronous Engine Architecture (mirror). Since I came up with a simple solution in my last engine I wanted to share it here: Maybe it will save a few hours to someone :) ! Problem: Variable framerate and Variable timeslices. When I started engine development I used a naive game loop that would: Retrieve the time difference (timeslice) since the last screen update.Update the world according to inputs and timeslice.Render the state of the world to the screen. It looked as follow : int lastTime = Timer_Gettime(); while (1){ int currentTime = Timer_Gettime(); int timeSlice = currentTime - lastTime ; UpdateWorld(timeSlice); RenderWorld(); lastTime = currentTime; } Further readings.
Analyse du code source de 3 grands jeux. Analyse du code source de 3 grands jeux Si vous vous intéressez un peu au développement de jeux vidéos, foncez sur le blog de Fabien Sanglard qui a décortiqué pour le plus grand plaisir de tous les codeurs, le code source de 3 hits du jeu vidéo : De l'architecture du code, au moteur de rendu graphique, en passant par l'intelligence artificielle et j'en passe, tout y est minutieusement décortiqué et expliqué de manière très claire et simplifiée (même si c'est en anglais). Bref, ça vaut le coup d'y jeter un œil. Le mec est bon et ses explications passionnantes pour autant qu'on s'intéresse au sujet.
Enjoy ! Source Vous avez aimé cet article ? Doom Engine source code review. January 13th, 2010 Before studying the iPhone version, it was important for me to understand how Doom engine WAS performing rendition back in 1993. After all the OpenGL port must reuse the same data from the WAD archive. Here are my notes about Doom 1993 renderer, maybe it will help someone to dive in. January 13th, 2010 : Reddit annihilated my bandwidth (4 hours after publication). Back online.February 8th, 2010 : Slashdotted, moving videos to YouTube.com.
I can't keep up with 5000 visitors a day.July 23th, 2011 : Two videos surfaced about doom development: A Visit to id Software and Doom: Post-Mortem 2011. From designer screen to player screen Maps were designed in 2D by a level designer using Doom editor (DoomED). When the map was finished, it was sliced via Binary Space Partitioning. Trivia: Both DoomED and iBSP were programmed using....Objective-C on a NextStep workstation. Following is an example of the first map being recursively split: Recursion level 1 The big picture of runtime. La loop du jeu. Doom3 Source Code Review: Introduction. June 8, 2012 On November 23, 2011 id Software maintained the tradition and released the source code of their previous engine. This time is was the turn of idTech4 which powered Prey, Quake 4 and of course Doom 3. Within hours the GitHub repository was forked more than 400 times and people started to look at the game internal mechanisms/port the engine on other platforms.
I also jumped on it and promptly completed the Mac OS X Intel version which John Carmack kindly advertised. In terms of clarity and comments this is the best code release from id Software after Doom iPhone codebase (which is more recent and hence better commented). I highly recommend everybody to read, build and experiment with it. Here are my notes regarding what I understood. Part 1: Overview Part 2: Dmap Part 3: Renderer Part 4: Profiling Part 5: Scripting Part 6: Interviews (including Q&A with John Carmack) From notes to articles... Background First contact Download the code. Architecture When Doom3.exe starts up it: . Quake 2 Source Code Review. September 16th, 2011 I spent about a month in my spare time reading the source code of Quake II.
It was a wonderful learning experience since one major improvement in idTech3 engine was to unify Quake 1, Quake World and QuakeGL into one beautiful code architecture. The way modularity was achieved even though the C programming language doesn't feature polymorphism was especially interesting. In a lot of regards Quake II is a shining piece of software history since it is the most popular (in term of licensing) 3D engine of all time. Powering more than 30 games but also marking the gaming industry's departure from software/8bits color system to hardware/24bits color system that occured around 1997.
For all those reasons, I highly recommend anyone that appreciate programming to dive into it. I got a bit carried away with the "cleanup" process since there is more than 40MB of videos,screenshots and drawings in this article. First contact and compiling Quake2 architecture Quake. Rendition Bad : Quake 3 Source Code Review: Architecture. June 30, 2012 Since I had one week before my next contract I decided to finish my "cycle of id". After Doom, Doom Iphone, Quake1, Quake2, Wolfenstein iPhone and Doom3 I decided to read the last codebase I did not review yet: idTech3 the 3D engine that powers Quake III and Quake Live. The engine is mostly an evolution of idTech2 but there are some interesting novelties. The key points can be summarized as follow: Part 2 : New dualcore renderer with material based shaders (built over OpenGL Fixed Pipeline).
I was particularly impressed by : The virtual machines system and the associated toolchain that altogether account for 30% of the code released. As usual I wrote numerous notes that I have cleaned up and synthesized into drawings. Edit : Thanks for the support :) ! First contact Since the venerable ftp.idsoftware.com was recently decommissioned the code can be found on id Software's GitHub account: git clone Architecture The code Statistics. Duke Nukem 3D Code Review.