The programmer behind this, Casey Muratori, has been helping out Jonathan Blow (Braid) on his new game, The Witness, and blogging about it.
For the more experienced game devs out there, the series is a fantastic read: http://mollyrocket.com/casey/ (starting post 6). Many of the insights apply to software engineering in general, not just game dev.
The series is pretty good overall, but his endless tirades against OOP (many of which are specious) drained much of my enthusiasm for his blog. Regardless, it's still good reading and this new game project is a great idea.
I hope this will turn out to be a great resource for experienced programmers interested in graphics, real-time processing, and the like. I wish I had the time to go through it.
However if your goal is to make games my advice, and I'm not alone, is to make games and use an engine. Your users will not know if you developed it from scratch in C. They won't even care if you tell them. Only programmers and game developers care.
Lots of gamers can tell when a game is a "Unity" game for example (due to lots of built in shaders and effects). I'd agree using an engine is a wise choice but make the decision very carefully. It can save a ton of time, but you still have to put in a lot of work to not let the engine dictate too much about the look and feel of the game.
The point I was trying to make is that developing a game from scratch is a labor-intensive way to make a game. You have to consider file paths, resource management, texture packing, file formats, parsers, and hardware. You have to think about abstract things like event processing, concurrency, simulation, reacting to inputs, etc. A mountain of work goes into lighting up a pixel on the screen. Doing it from scratch is essentially inventing the universe from the atoms up.
I like this kind of stuff.
However there are projects where I'm more interested in game play mechanics, art, music, and experience. I can still write my own shaders. I still write all of my own behaviors, AI, and controllers. But with an engine I don't have to worry about animation blending, input control, hardware platform differences, asset tooling, etc, etc, etc, etc.
I don't want to discourage anyone who is curious. I just wanted to push back against some of the nostalgia in the video. It's not all glamorous. I've spent my share of my youth slavering over cryptic compiler errors. Developing games then wasn't as much fun as it is today, IMO. It was different and unique in its own way. But the tools we have today are far, far better.
Absolutely right. I've gone through the dark times of wondering how to get the linker to stop exploding on me. And when speaking about developing a game engine, it's not just the work required to create feature X, it's the entire ecosystem. Making a sound play or wiring up PhysX is not difficult. Making fifty modules work correctly with each other is the foundation and is not easy or quick. Then there are editor tools, with modern engines providing a full editor suite that would take a team years to make. In the case of Unity, you get correct play-in-editor as well as truly live editing, which allow for incredibly rapid iteration (part of the true secret of efficient game development is being able to go from your shower "ah ha!" moment to a working prototype as quickly as possible). Then there's their asset store with a proliferation of not only art and sound but valuable scripts and entire systems or engines. And while I'm making my game, the middleware company is making my tech better by fixing bugs and adding features, with nearly-push-button support for over a dozen modern hardware platforms to boot.
I can see lots of reasons to develop a game engine from scratch, but they become less compelling every year.
Wow. I can't even begin to express how much the premise behind this series resonates with me. I've been looking for something just like this.
My only issue is that, although in C, the preview/introduction video seems pretty centered around visual studio[0]. In the FAQ you say that multi platform support for *nix systems will be added later.
How exactly will this work for those of us who want to follow along, but don't have Windows?
Answered in the Q&A video that followed the one you linked to. The project will be avoiding OS specific code as much as possible so I can't see a there being a dependency on visual studio. http://youtu.be/I5fNrmQYeuI?t=11m21s
Judging by the initial video, you won't be able to follow this without a Windows machine. The author plans to implement a game from scratch (no third party library will be used) in C on Windows, which means he will use Win32 functions (OS specific code) for creating a window, reading/showing image files etc ...
If you want to follow along from day one I suggest you install Windows in a virtual machine (you can download a legal copy of Windows and use it for about a month, just make sure you regularly save the code on your main OS). Alternatively, you can wait until the author will present how to do the same thing (window creation etc ...) on a Unix like OS.
I doubt he will use SDL, the author mentions in another video that he is interested in implementing his own render. Also, he claims he won't use DirectX or OpenGL.
He said he might you some OpenGL near the end. Hopefully, he does because using the GPU will allow for so much more performance. I guess he can make that a separate class.
You can actually use an unactivated copy of Windows 7 for longer by using "slmgr /rearm" in cmd (which needs to be run by right clicking cmd.exe and choosing the "run as administrator" option). You can extend the license 3 times (leading to 120 total days). It should be noted that you can apply it after the temporary licensing has expired.
I'm not sure if this applies to Windows 8 or 8.1, however.
Good luck writing anything but C89 with visual studio. This project sounds amazing and I'm going to probably try it but Microsoft has abandoned C for a while now so visual studio is a complete turn off for this use case.
I'm reasonably certain that this has started to change in MSVC 2013. They have stated that they have improved the C99 library support and unless I'm mistaken they have finally permitted mixed code and declarations.
They have implemented the C99 parts required by C++14 standard, plus few extra parts required by some well known open source projects. It remains open if they will ever implement the rest in MSVC++.
This looks very interesting, in straight C no less. Props to this guy.
I'll definitely be watching it, although I take some mild offense at the idea that I am somehow less of a gamer or game-maker if I decide to use an engine. Truthfully, I am not a very good programmer: I don't delight in getting into the guts of the mathematical algorithms that allow for the complicated physics calculations, AI pathfinding, or multiplayer networking, nor do I enjoy the tedium of hand-optimizing routines for tweaking performance. I just want to make games.
On the other hand, someone like John Carmack clearly does delight in some of these things, and he is ten times the programmer I will ever be. To boot, he has written this amazing Doom engine (to use an antiquated example) which he will license out to other developers! Why shouldn't I use it? What am I demonstrating by insisting that I do everything myself if it results in an inferior game?
There's nothing wrong with using an engine at all. For the same reason I use Numpy and don't bother making my own array manipulation classes.
Most of the time you don't need to reinvent the wheel because someone has probably spent a PhD implementing it better than you ever will. I think this is a perfectly valid excuse and I use it every day. If I didn't, I'd get no work done. With the libraries available few people should ever need to implement an FFT, for example. However, it's good practice to try coding some algorithms yourself to see how they work.
In terms of games, I assume the intent wasn't to belittle, but to try and show people what happens under the hood. It helps you make better decisions about which engine to use and what features to use within the engine. If you're given pathfinding options within your engine, to take a silly example, do you know enough about the algorithm to know which one would be best for your game instead of blindly choosing A*?
Understanding how the underlying code (probably) works allows you to make better decisions about which engines to use, which features you want and which you could brew yourself if you needed to.
Very cool and ambitious project. If I was 14 again, I would have been all over this. Back then, all I had was dusty library books. Now, totally not interested in making games, although I enjoy playing them! I'll probably skim just to see the algorithms he uses to handle AI, pathfinding and physics.
"If you want to make an apple pie from scratch, you must first create the universe." ~ Dr. Carl Sagan.
Is he using an existing processor / memory / motherboard?
Is he using an operating system?
Is he using a compiler, editor, IDE?
Is he using a standard library?
Is he using any 3rd party libraries?
Just because he isn't using an engine doesn't mean it's made "from scratch".
I've been playing around with bare bones assembly on Raspberry Pi. (Actually just following the baking pi tutorial.[1]) Maybe I should work up to a game from that level. That would be fun. I could go from Assembly to maybe a simple Forth interpreter (possibly the easiest language to implement from bare bones), and build tools and subroutines on top of that.
Man, you had me all hyped up until you typed emacs into a windows command prompt... Would have been such a badass ending if you hit nano from a shell. :(
Lost interest when it became Windows-only. Writing C on Windows is a nightmare and the chance of portability plummets if you aren't targetting a POSIX system from the start.
That's just silly. C is standard everywhere. Writing it on Windows is a matter of your facility with the IDE you choose, which can be a portable one if you wish.
The chance for portability depends on the graphics engine you choose or write. Our project (Sococo) is portable across Windows, Mac, iOS, Android and several versions of Linux. The Windows/graphic part is a tiny part of the code.
He's going to write his own renderer, he's not using SDL or anything. He's going to be opening his own windows and drawing to them directly. The chance at portability is extremely slim, and on top of that those of us who use saner operating systems won't get to enjoy it for a long time.
SO the portability effort is - opening a window and drawing? How is that difficult. Writing his own renderer means its pretty easy to be portable. He'd have to make a special effort to include platform code in what's normally a pure-math engine, right?
Will the game support multiple platforms?
Yes! Windows will be the first platform, since it is currently the most common gaming platform, but the series will later cover (at least) Mac, Linux, and Raspberry Pi. Portability will be a major topic in the series, so all the code will be structured to demonstrate how to write code that is easy to port to new platforms.
I realize that he's promised eventual support for sensible systems, but it's _much_ easier to write code that is portable from day one than to port something later. Everyone who's not using Windows will miss out on the majority of the project, too, having to wait until it's decided that portability is a concern.
If he knows he will be porting the game, why does he not abstract away the OS layer and perhaps even the graphics library? Then implement it behind some interface with for example SDL2 and OpenGL depending on platform.
Would not that save lots of time and ensure it works cross-platform from the start? To me, it just seems that you re-invent the wheel by not doing this.
He will abstract it. His style is to implement first, then figure out the abstraction, not the other way around. Plus he's done this before and probably has an abstraction in mind which will make that style work even better.
This looks like it could be really helpful for someone like me who wants to up their C game.
The video was top-notch, nearly gave me goosebumps.
The programmer behind this, Casey Muratori, has been helping out Jonathan Blow (Braid) on his new game, The Witness, and blogging about it.
For the more experienced game devs out there, the series is a fantastic read: http://mollyrocket.com/casey/ (starting post 6). Many of the insights apply to software engineering in general, not just game dev.
The series is pretty good overall, but his endless tirades against OOP (many of which are specious) drained much of my enthusiasm for his blog. Regardless, it's still good reading and this new game project is a great idea.
Oh, nostalgia.
I hope this will turn out to be a great resource for experienced programmers interested in graphics, real-time processing, and the like. I wish I had the time to go through it.
However if your goal is to make games my advice, and I'm not alone, is to make games and use an engine. Your users will not know if you developed it from scratch in C. They won't even care if you tell them. Only programmers and game developers care.
Lots of gamers can tell when a game is a "Unity" game for example (due to lots of built in shaders and effects). I'd agree using an engine is a wise choice but make the decision very carefully. It can save a ton of time, but you still have to put in a lot of work to not let the engine dictate too much about the look and feel of the game.
The point I was trying to make is that developing a game from scratch is a labor-intensive way to make a game. You have to consider file paths, resource management, texture packing, file formats, parsers, and hardware. You have to think about abstract things like event processing, concurrency, simulation, reacting to inputs, etc. A mountain of work goes into lighting up a pixel on the screen. Doing it from scratch is essentially inventing the universe from the atoms up.
I like this kind of stuff.
However there are projects where I'm more interested in game play mechanics, art, music, and experience. I can still write my own shaders. I still write all of my own behaviors, AI, and controllers. But with an engine I don't have to worry about animation blending, input control, hardware platform differences, asset tooling, etc, etc, etc, etc.
I don't want to discourage anyone who is curious. I just wanted to push back against some of the nostalgia in the video. It's not all glamorous. I've spent my share of my youth slavering over cryptic compiler errors. Developing games then wasn't as much fun as it is today, IMO. It was different and unique in its own way. But the tools we have today are far, far better.
Absolutely right. I've gone through the dark times of wondering how to get the linker to stop exploding on me. And when speaking about developing a game engine, it's not just the work required to create feature X, it's the entire ecosystem. Making a sound play or wiring up PhysX is not difficult. Making fifty modules work correctly with each other is the foundation and is not easy or quick. Then there are editor tools, with modern engines providing a full editor suite that would take a team years to make. In the case of Unity, you get correct play-in-editor as well as truly live editing, which allow for incredibly rapid iteration (part of the true secret of efficient game development is being able to go from your shower "ah ha!" moment to a working prototype as quickly as possible). Then there's their asset store with a proliferation of not only art and sound but valuable scripts and entire systems or engines. And while I'm making my game, the middleware company is making my tech better by fixing bugs and adding features, with nearly-push-button support for over a dozen modern hardware platforms to boot.
I can see lots of reasons to develop a game engine from scratch, but they become less compelling every year.
Wow. I can't even begin to express how much the premise behind this series resonates with me. I've been looking for something just like this.
My only issue is that, although in C, the preview/introduction video seems pretty centered around visual studio[0]. In the FAQ you say that multi platform support for *nix systems will be added later.
How exactly will this work for those of us who want to follow along, but don't have Windows?
[0] https://www.youtube.com/watch?v=F3ntGDm6hOs
Answered in the Q&A video that followed the one you linked to. The project will be avoiding OS specific code as much as possible so I can't see a there being a dependency on visual studio. http://youtu.be/I5fNrmQYeuI?t=11m21s
Judging by the initial video, you won't be able to follow this without a Windows machine. The author plans to implement a game from scratch (no third party library will be used) in C on Windows, which means he will use Win32 functions (OS specific code) for creating a window, reading/showing image files etc ...
If you want to follow along from day one I suggest you install Windows in a virtual machine (you can download a legal copy of Windows and use it for about a month, just make sure you regularly save the code on your main OS). Alternatively, you can wait until the author will present how to do the same thing (window creation etc ...) on a Unix like OS.
He'll probably use SDL for that kind of stuff.
P.S. EMACS!!!
Yeah, because SDL is not an engine, so he can still boast he made it from scratch.
I doubt he will use SDL, the author mentions in another video that he is interested in implementing his own render. Also, he claims he won't use DirectX or OpenGL.
He said he might you some OpenGL near the end. Hopefully, he does because using the GPU will allow for so much more performance. I guess he can make that a separate class.
You can actually use an unactivated copy of Windows 7 for longer by using "slmgr /rearm" in cmd (which needs to be run by right clicking cmd.exe and choosing the "run as administrator" option). You can extend the license 3 times (leading to 120 total days). It should be noted that you can apply it after the temporary licensing has expired.
I'm not sure if this applies to Windows 8 or 8.1, however.
Similarly you might enjoy reconstruct cave story:
https://www.youtube.com/playlist?list=PL006xsVEsbKjSKBmLu1cl...
http://www.reddit.com/r/reconstructcavestory/
Cheers
Good luck writing anything but C89 with visual studio. This project sounds amazing and I'm going to probably try it but Microsoft has abandoned C for a while now so visual studio is a complete turn off for this use case.
I'm reasonably certain that this has started to change in MSVC 2013. They have stated that they have improved the C99 library support and unless I'm mistaken they have finally permitted mixed code and declarations.
They have implemented the C99 parts required by C++14 standard, plus few extra parts required by some well known open source projects. It remains open if they will ever implement the rest in MSVC++.
However, VS 2015 will have clang integration.
This looks very interesting, in straight C no less. Props to this guy.
I'll definitely be watching it, although I take some mild offense at the idea that I am somehow less of a gamer or game-maker if I decide to use an engine. Truthfully, I am not a very good programmer: I don't delight in getting into the guts of the mathematical algorithms that allow for the complicated physics calculations, AI pathfinding, or multiplayer networking, nor do I enjoy the tedium of hand-optimizing routines for tweaking performance. I just want to make games.
On the other hand, someone like John Carmack clearly does delight in some of these things, and he is ten times the programmer I will ever be. To boot, he has written this amazing Doom engine (to use an antiquated example) which he will license out to other developers! Why shouldn't I use it? What am I demonstrating by insisting that I do everything myself if it results in an inferior game?
There's nothing wrong with using an engine at all. For the same reason I use Numpy and don't bother making my own array manipulation classes.
Most of the time you don't need to reinvent the wheel because someone has probably spent a PhD implementing it better than you ever will. I think this is a perfectly valid excuse and I use it every day. If I didn't, I'd get no work done. With the libraries available few people should ever need to implement an FFT, for example. However, it's good practice to try coding some algorithms yourself to see how they work.
In terms of games, I assume the intent wasn't to belittle, but to try and show people what happens under the hood. It helps you make better decisions about which engine to use and what features to use within the engine. If you're given pathfinding options within your engine, to take a silly example, do you know enough about the algorithm to know which one would be best for your game instead of blindly choosing A*?
Understanding how the underlying code (probably) works allows you to make better decisions about which engines to use, which features you want and which you could brew yourself if you needed to.
This is one thing that I always wanted to learn, but never knew where to start. I guess this will be a good place. Looking forward to it.
Very cool and ambitious project. If I was 14 again, I would have been all over this. Back then, all I had was dusty library books. Now, totally not interested in making games, although I enjoy playing them! I'll probably skim just to see the algorithms he uses to handle AI, pathfinding and physics.
"If you want to make an apple pie from scratch, you must first create the universe." ~ Dr. Carl Sagan.
Is he using an existing processor / memory / motherboard? Is he using an operating system? Is he using a compiler, editor, IDE? Is he using a standard library? Is he using any 3rd party libraries?
Just because he isn't using an engine doesn't mean it's made "from scratch".
Oh, don't be a party-pooper.
I've been playing around with bare bones assembly on Raspberry Pi. (Actually just following the baking pi tutorial.[1]) Maybe I should work up to a game from that level. That would be fun. I could go from Assembly to maybe a simple Forth interpreter (possibly the easiest language to implement from bare bones), and build tools and subroutines on top of that.
[1] http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/
I have just finished reading http://mollyrocket.com/casey/stream_0019.html that he links in the article.
Interesting, that though he mostly spoke about refactoring procedural C, it really reminded me how I would work when programming in Clojure.
Man, you had me all hyped up until you typed emacs into a windows command prompt... Would have been such a badass ending if you hit nano from a shell. :(
lool... i feel your pain :(
this is interesting and hardcore!
Oh yeah, very hardcore. http://xkcd.com/378/
Awesome, I'm definitely interested in this! It will be cool to be able to understand creating a game from scratch with C.
"professional-quality game"
Always happy to see component-entity systems or other modern game architecture patterns applied!
I'm amazed that people are totally unaware how a game works.
the devil is in the details: physics, path finding, matrix multiplication, space partitioning, graphic pipeline, and many other algorithms.
I don't think those feeds will teach how those things work.
This was one of the easiest purchases I've made in my life. I've been following Casey's blog for some time and his Wednesdays posts are amazing.
I can't wait to start watching the videos and of course, code along.
Lost interest when it became Windows-only. Writing C on Windows is a nightmare and the chance of portability plummets if you aren't targetting a POSIX system from the start.
That's just silly. C is standard everywhere. Writing it on Windows is a matter of your facility with the IDE you choose, which can be a portable one if you wish.
The chance for portability depends on the graphics engine you choose or write. Our project (Sococo) is portable across Windows, Mac, iOS, Android and several versions of Linux. The Windows/graphic part is a tiny part of the code.
He's going to write his own renderer, he's not using SDL or anything. He's going to be opening his own windows and drawing to them directly. The chance at portability is extremely slim, and on top of that those of us who use saner operating systems won't get to enjoy it for a long time.
SO the portability effort is - opening a window and drawing? How is that difficult. Writing his own renderer means its pretty easy to be portable. He'd have to make a special effort to include platform code in what's normally a pure-math engine, right?
I think you might be surprised how much code it takes to open a window and draw to it in C without using something like SDL.
It takes some boilerplate code that can be googled. Irrelevant how much; it takes little effort.
Taken directly from the website:
Will the game support multiple platforms? Yes! Windows will be the first platform, since it is currently the most common gaming platform, but the series will later cover (at least) Mac, Linux, and Raspberry Pi. Portability will be a major topic in the series, so all the code will be structured to demonstrate how to write code that is easy to port to new platforms.
I realize that he's promised eventual support for sensible systems, but it's _much_ easier to write code that is portable from day one than to port something later. Everyone who's not using Windows will miss out on the majority of the project, too, having to wait until it's decided that portability is a concern.
If he knows he will be porting the game, why does he not abstract away the OS layer and perhaps even the graphics library? Then implement it behind some interface with for example SDL2 and OpenGL depending on platform.
Would not that save lots of time and ensure it works cross-platform from the start? To me, it just seems that you re-invent the wheel by not doing this.
He will abstract it. His style is to implement first, then figure out the abstraction, not the other way around. Plus he's done this before and probably has an abstraction in mind which will make that style work even better.