On April 1, 2011, I was invited by UC Berkeley's Computer Science Undergraduate Association to come give a speech. This was pretty interesting because that's where I went to school, and I was once a member of the CSUA. I approached it this way: if I were going back to speak to my undergraduate self, what would I say to help him be most effective at making video games, programming-wise?
The talk's about 38 minutes long, with about 40 minutes of Q&A afterward. Here's a slideshow:
If the above embedded player doesn't work for you, or you prefer to download the files directly, here they are:
Thanks for such an interesting video. As an indie developer myself, I found it to be very insightful and thought-provoking.
If at all possible, I’d love to know more about the design and development process behind Braid, as I am currently developing a game for which Braid serves as the primary inspiration.
Any advice would be highly appreciated.
Jonathan, if you don’t mind taking questions:
To what extent do you value programming innovations within your game design aesthetic? More specifically, do you feel that games that aren’t pushing the envelope on the technical side of things are less likely (though not “guaranteed”) to deliver unique or interesting gameplay?
What I’m ultimately aiming at is your take on the integration of technical programming within the medium of video game design. So I’m not asking if you wouldn’t design a tabletop game or a card game, but, rather, if you feel that the video game medium is inherently dependent on programming & technical innovation.
What you talk about bit me hard in my second job. Instead of digging through tutorials till I learned something, and then doing the right thing I was supposed to quickly do the thing that worked. This meant:
*) Implement required functionality.
*) The smaller diff the better.
*) Do the simplest sensible thing that works.
*) Don’t implement elaborate mechanisms unless you don’t know how to do it simpler.
*) Only do what you are told to do. Additional / better functionality is not always better and means more code. +20% functionality and +80% code is not good enough. Don’t get any brilliant ideas, and certainly don’t implemet them before talking to superior.
*) Remove code when possible without breaking anything.
*) Do it fast. Preferably a few patches a day.
*) Don’t use comments. Don’t write documentation. Well written code is self documenting. Reverse-engineer (just read the code, really) when you need to know how parts of the system that you need to touch work.
It was quite a shock. I argued with my boss about this philosophy, but their system works, and I don’t know how. It is not a game, BTW, but a system for making web pages with tables connected to a database, and written in perl.
It also aligns somewhat with what I read on extreme programming, tough we used ‘peer review’ of diffs and manual testing rather than unit tests.
>> Well written code
>> written in perl
Implying code written in Perl can be even well-written.
Anyway, I’m much against “self-documenting code” philosophy (your other points are valid tho!). Why? I’ve read many sources that are supposed to be “self documenting”, but it was still hard job requiring trial and error to even get idea of what code is doing. Easier than if variables are called Variable1, variable2, etc. and functions function1, function2, etc., but still.
NOTHING, I say NOTHING can replace properly placed comments. Even quick description in header of function/procedure that explains what it is supposed to do is good.
Excellent talk Jonathan. Love your point on the internet / university shift. I would love to have grown up with all of the available information in todays world.
Some thoughts.
I spent nearly 4 years at the university and I barely remember any of it. What I remember the most is what I did during my spare time after class, tinkering with code, looking at open source code and finishing small projects. Considering that I had no programming experience I needed that time at the University. It’s a great place that allows you to explore interests in depth without major life factors getting into the way. So find a state school to look decent, hack when you’re not in class and milk financial aid as much as you can (do not put yourself in crazy debt for this thing). You might be surprised what you can whip up by the time you graduate if you explore hard enough.
The problem is that a lot of folks don’t want to explore that hard. They just want it to be given to them. They’re trying to find the perfect school that will hand them the experience they need. Just get out there and create things, meet people and love what you’re doing. Go create the experience.
Anyway, a few cents worth of thought.
Yeah I guess I wasn’t very specific about my experience in coding and such. Basically I have taken three programming courses, and prior to that I had zero programming experience, so all I know I learned from those three classes and the assignments we did in those classes. One was just an intro to OO and programming (what you would get in a high school AP class),intro to software development (basically advanced OO), and data structures and low level representation. We have courses in just about everything you need: AI, Parallel Computing, Graphics, and many more, but right now I am leaning towards hardware design and am spending most of my effort taking EE classes, and software wise I’ll take classes when I can, so I might not get a chance to take for example AI. I still want to learn how to do it in case down the road I decide to switch gears. I will have coding background, but there will just be some pieces I am missing.
I want to be able to teach myself some of these things in case I don’t get a chance to take the course. Or if something really inspires me I’ll know that it will be worth my time to take that course. As you said, you don’t need to take a college course to be able to produce good code. When I said I wouldn’t know how to make a game, I didn’t realize when I asked but I thought about it, and graphics is the only thing that would be stopping me from making a very simple game. I really know nothing about graphics.
Thank you for questioning my question to help me be more specific…
Where should I start with teaching myself graphics primarily in the context of video game design? Should I just find some tutorials and just start making simple games and learn by experience? If so any suggestions of programs/languages to start with?
Anonymous: I guess my answer is yes and no. Yes, a lot of technical innovation is necessary to help expand the space of games we can make. But for any particular game, the answer is no; the space we have access to now is already pretty huge, and it doesn’t require anything extra tech-wise to do something that is new design-wise and valuable to a lot of people.
Kevin: After just 3 programming classes, and if you haven’t been programming on your own, then yeah, I wouldn’t expect you to know how to make a video game. That is just not how it works! I would say just keep taking as many classes as you can (if you are able to — possibly graphics classes!), but also just be sure to do stuff in your spare time, because that is where you *really* learn.
For teaching yourself, yeah, there are a lot of tutorials on the internet. Some are better than others, but if you just pick one and start going with it, you’ll rapidly be getting valuable experience. I don’t have any suggestions of languages to start with, maybe just something you already have exposure to from the classes you have taken.
I think the title of the talk is too specific; I don’t make indie games but have been converging on a similar set of beliefs. On larger teams simplicity is even more valuable; but, I believe, also more elusive. I think my own desire for simplicity stems from both age-based wisdom and senility. The shorter-term my memory gets, the more practice I get reading my own “old” code, and the better I get at writing for my future self.
Coincidentally I just today got the idea to ask questions about simplicity in programming interviews; I don’t know why I didn’t have the idea earlier.
Are you the MySQL book author? I have your books! =D
Great lecture indeed, and great comment section as well.
I’ll try not to go into my graduation experience (here in Brazil) and my vision about game dev schools in this comment.
The core idea of the lecture coincide with my line of thinking and gut feeling when coding. For me it’s pretty cool, since I’m not that bright, and what I love about programming is being able to create cool stuff (period).
And it goes without saying that you have to make a good work with your foundation classes, and have a good plan on how to tackle things (without need to formalized the plan too much, though).
About eight months ago I got involved in my first indie game project (with C#/XNA, meh) -pretty simple turn-based management game. And hell, I just had to crunch and simply do stuff work, in a barely robust way. And it felt great, in contrast with the depressive unproductive routine that I had in my previous job.
Also on Life Time Spent metric, Retro City Rampage dev blog have a great entry on building time and productivity, with some practical coding tips. Notch (Minecraft) also made a post on simplicity and not rewriting code unnecessarily , if I remember well. Endorsing Jonathan PoV.
Q: As questioned before I would like to hear Jonathan’s opinion on tools like Unity and their impact in the Life Time Spent Metric. And why he prefer to build stuff from scratch. I’m personally fond of work “from scratch” right now, mainly for educational/career reasons. ’cause it’s not a bad idea to be able to be a tool/tech/lead programmer in the industry.
That’s it.
ps: This blog is getting really, really cool.
I don’t know very much about Unity. However, it’s clear that one could not build The Witness in Unity without rewriting a lot of Unity (or adding a lot of things that are not there, and declining to use most of what Unity provides). And we already had a simple graphics engine anyway. So when building our own systems, we can ensure that they are really what the game needs to be its best.
Thank you for answering my question Jonathan! i was going for the “game dev” course but know i’m going straight-up(>^) CS!
All this CS and programming talk reminded me of something… CS rap and sheet!!!11
♪♫♪♫♪♫ Code so clean you can eat off it.
If we can’t fix it, it isn’t broken.
Never test for a bug you don’t know how to fix.
I think therefore I create bugs.
Debug is human, de-fix divine.
There’s a bug born every minute, and two to replace him.
The Bugs Of Wrath
There are 2 ways to write bug-free code; only the 3rd way works.
Final message received from the Titanic: Fatal crash due to icebug.
Bugs Bunny was an optimist.
One small bug for man, one great program for mankind.
The bug is mightier than the fix.
Man does not live by bug fixes alone.
For every bug fixed, there is a bigger bug not yet discovered.
The bug stops here.
I have just begun to debug.
Bugs bugs everywhere, and not a fix in sight.
A feature is a bug with seniority.
Human knowledge belongs to the world.
Programmers don’t die, they just GOSUB without RETURN.
Debuggers have been made by bug-creators.♪♫♪♫♪♫
Yiah, nigguh! Science FTW! Thanks Jonathan!
Capcha: Spervo Coined ?????
> Patai Gergely / June 24, 2011
> Jon, your main points might even contradict each other in certain contexts.
> For instance, there are situations when the general solution is easier to implement
> than the specific one. Or there is an off-the-shelf well-tested clever data structure
> that takes less work to incorporate in your code than to create even the simplest
> viable solution from scratch
One of my lecturers put it that way: “Computer Science is not hard science. It consists of half-truths, that have limited appliability dependent on context. ” So yeah, there were some specific examples in the lecture, and a few people found them counter-productive in some cases. Those examples were there to illistrate “Do the simple thing that works good enough. do it fast, and move on. You can refactor later if needed” line of thought rather than presented as absolute truths. Its OK to use stuff like std, boost, and other libraries rather than implement linked lists and trees from scratch. School teaches us rules, so we know when and how to break them. We are taught all the rules just so we will know when and how to break them.
It seems to me, that the biggest obstacle in using simplistic data structures and algorithms as good enough is that optimized, clean and well structured code is, well how should I put it, way easier to mentally masturbate to. For example I really like the alborate data structure I came up for my program to test algorithms form my CS master.
I’m not into game development, but I can do some graphics when I need it. My advice to Kevin: After learning basics of programming learn to use a widget library next. They all use similar concepts, so once you know one, you’ll have easier time learning another if you need it. Stick to language you know. QT is pretty and widely used for C++, Swing for Java. Something like tic-tac-toe or minesweeper made with buttons on a grid layout seems like a good excercise. It won’t be time wasted, you’ll need to know how buttons, menus, labels, etc. work anyway. Plus you’ll be able to make a gui with input fields and “Compute” button for your projects at school rather than pure console interface. After that I’m not sure, I’m not there yet, but learning some SDL and OpenGL (for C++ programmer) seems like the next step.
Hi,
Excellent talk. Sad to hear the X360 certification process is so arduous; people will go to great lengths for their silly DRM :D.
I’m actually starting a new project on CryEngine 3, with a team I’m a part of, and I absolutely agree with most of the advice about premature optimization and complex algorithms—particularly, I’d add, on difficult-to-debug things like shaders. We actually had quite a few problems with that before; an indie programmer has to choose between productivity and innovation, and it’s a tough balancing act that should always err somewhat on the side of productivity.
One thing I’d also recommend (again from experience) is that the solo programmer use whatever external code is available to him. Even if it doesn’t accomplish exactly what he wants, if it’s satisfactory it will save him a lot of time.
For this project, for example, we have an AI that does some machine learning, and I was very wary of adding new features because this kind of system is not easily debugged. In the end, I opted to use simple neural TD-learning, straight out of the book, and after some reservations decided to do a minimal OpenCL port to boost performance, maybe even hundredfold. But now I’m done. No need to optimize the data structure (just arrays and offsets into arrays for the node connections) since it all fits on a GPU block on the target hardware, and no need to worry about cache efficiency since I’m in the basic habit of writing flat, modular code. Other than that, I’ll see where the bottlenecks are when I actually run it!
And of course I wouldn’t have done the GPGPU port if I hadn’t already been familiar with that platform for some years now.
Especially worth repeating: if you’re an indie, especially a new indie, DO NOT roll your own engine. Just don’t. You think you can do it, but you can’t. We’re using CryEngine 3 SDK when it comes out in August. If you don’t need anything that new, there’s open source stuff you can use.
Great talk, i really liked the part where you explained how productive you have to be as a indie developer. I am keen knowing more about the data structures and the array of records thing you talked, because a lot of time in development is spent on thinking about the framework.
Hello Jon, excellent talk!
This talk enlightened me a lot. I’ve recently been looking at the code my friends and I written for our game, and thinking about where it got too complicated than it should be, but I wasn’t very sure … and this talk really clarified many things for us.
I’ve got a few question though. You talked about optimizations, data structures, algorithms and generalizations, however what’s your take on “design patterns”? or it’s already covered by “don’t over-generalize things”? It’s like, for instance, should we simply stick to the most basic switch-case for state machines, or should we use a state pattern? (or even use a state machine lib? I guess no.) Or any similar situation like: we know there’s a pattern for this job, and the use of this pattern will make the related code “looks cleaner” and should have more “maintainability”, or have more “semantics” and “more expressive”, and blah blah blah, but it’s bound to be adding a few classes here and there. Thoughts? :)
And there might be a more “architectural” thing. We write our game code in a way that the game model objects never touch any graphic-related code or graphic related object directly, and vice versa, and then we use a composition object to hold the corresponding model and graphic object (so that they can communicate). This certainly made different parts of the code stays pure and don’t look spagetti, but we also find ourselves sometimes have to punch through an additional layer to add a specific functionality. Do you think this is clearly an over-architecture/abstraction?
To add some context, we used an open source graphic engine and we currently have around 15K LoC (code only) and 2 programmers, and it’s our first project over 10K LoC boundary. We sort of only did this in our spare time though, it was never a full-time project.
Thanks in advance!
It’s really hard to give opinions on concrete questions like this without knowing a lot about the precise situation / project.
And anyway, 15k lines of code is not really a big enough program that you start running into structural issues. So it probably doesn’t matter that much.
That said, one thing you said stuck out like a sore thumb. The idea of wrapping two objects in a third object just so that the other two objects “can communicate”, that just seems like the kind of severe overabstraction typical to academia and programming books, that only causes problems in real life (in part for exactly the reason you are talking about — any changes in procedure definitions / parameters / etc are now twice as much work to do as they were before). Why don’t you just, you know, let the two objects communicate?
Thanks for your reply, Jon. :)
Actually we did a similar project before, and that was such a super-rushed class project that we dare not look at that code anymore… however, during that period of time we also gained “some” knowledge of various methodologies “to write better programs”, and also we were becoming more comfortable with using some advanced C++ features and programming techniques. So, we ended up devising layers of abstractions and tried to write better quality code (or so we thought) and at some point we felt that the code looked good, really :p
“The second-system effect” just come to my mind. Funny thing is my friend and I both read the Mythical Man-Month even before we did both projects. Well..guess sometimes reading good books is just nowhere near enough when we’re really lack of experience. Maybe we even confused straightforward code with spaghetti code (by thinking that writing everything straightforwardly is bound to be spaghetti in the long run).
Still much to learn. Thank you again. :)
Totally off topic, but you sound kinda like Sean Maher. Just saying.
But more on topic, awesome presentation.
Haha, it kills me to hear The Witness being demoed and not being able to see anything. Still, great talk, very though provoking, especially as a student currently going through a CS program.
actually a lot of this stuff i learned from chris crawford’s writings; he covers most of these topics in his books and website, some of it dating back to the early 80s where he wrote his art of computer game design book. so these issues are age-old issues (although still relevant) in game programming. it’s good to see it again though (and reaching an audience which wouldn’t otherwise have seen these topics)
as an aside, it’s interesting to see line count, just as a curiosity. braid was a lot larger than the games i’ve made; but i still work in game maker / gml, which is a higher-level language. immortal defense had only 18k lines, but i made it in 6 months, so that’s 3000 lines a month. it’d be interesting to see line counts for other indie games
Thank you for the great lecture! This is all stuff I’ve been learning in my first few months at a game company — we never covered any of this in school.
Thanks for posting that – really enjoyed the talk. I came to a lot of the same conclusions with developing web applications, and more recently with games – like how designing things to be too general and abstract up front leads to wasted effort and an additional layer of complexity. And how large, many-line-of-code methods can be easier to deal with than a bunch of “properly modularized” small routines.
Cool to hear someone articulate these things so well.
I have spent the last 20 years involved in the research and development of my own tools.
Yes, you read that right…
Yet, I am also optimising the “years of my life per program implementation”.
It’s just that my game is quite a bit bigger than other lone amateurs normally attempt:
“METAVERSE”
Early on I realised that I’d never complete something of its scale without bugs in C++ or by using conventional content creation methods. Consequently, I don’t feel the last couple of decades has been a waste of time (although, there were a lot of paradigms like OO and FP to learn in enough depth in order to comprehend the “subtle negatives chained” to their ideas and what, less flashy, but more robust and integrated approaches had been unfairly overshadowed), as I am confident that my language will boost my productivity. Repeatedly. Also, my faith in procedurally-generated content – particularly, thematically consistent emergent narratives – and lack of financial pressures (it is a hobby project without deadline), free me from the majority of burdens you listed on your 9th Slide.
Actually, that’s inaccurate. Neither the R&D or the game design are a burden.
I am enjoying every minute of it – and to think I only started the project to avoid boredom!
Yay, go me!
Jonathan, I thought that a lot of what you had to discuss was really good information. I’d be curious to understand more about data structures as premature optimization. I totally get the ‘Doom’ example as we do similar things with our file formats where I work. It just seemed to me though that a lot of your argument came down to was ‘why write a hash table when an array is easier’. While I agree with that (and see it as a subset of your later ‘don’t do complicated things’ argument), I don’t see how that exactly translate to ‘don’t use’ in cases where maybe there already exists a hash table data structure to use, say from the STL or possibly a pre-existing company library.
It seems like someone would be able to write arguably simpler and clearer code by using an actual, let’s say, map with a reasonable interface than it would be to emulate a map with a array just because you wouldn’t have written a map.
The issue isn’t whether to use a hash table or not. That is one specific example and a decision one way or another does not matter very much. The issue is about the 57 different data structures you would end up having in a complicated program that does a lot of different things and has a lot of different data access patterns. And it’s not just typing in those 57 different structures (or using pre-written ones), it’s maintaining a running understanding of all the wrinkles of complexity that get introduced by doing that.
Keep in mind that interface is different from implementation! If I am using arrays to do stuff, I probably still use a very simple interface where you say, hey, give me the item corresponding to this name, or whatever — just like you would with a hash table. So there’s not any readability difference to speak of, there, when it comes to implementation differences.
But again hash tables are sort-of a red herring. The real issue is, like, I have some struct and I actually want to index it 3 different ways… then multiply that by lots of different data structures in the game.
Hello. I just wanted to say how much I enjoyed this talk. I very much agree with your programming style. I practically punched the air with delight when you got to the “straight-line” code section. I now have somewhere to send the next person who turns their nose up at one of my thousand line functions with half a dozen scope blocks!
The stuff at the beginning about what it takes to finish a game was something I hadn’t thought about before, but that also agrees with my experience. I guess it’s no coincidence that when I started to really focus on simplicity is also when I started to finish the games I started.
Jonathan
Thanks for the incredible lecture. Very useful.
I’m from a software engineering background, but have recently moved into another incredibly time-consuming field: animation.
The great news is: all your points about premature optimization also apply to being an independant animator.
Especially the “how many years of my life can I spend on this project” optimization problem, the “only protoype an idea until you work out whether it can go further” and the philosophy to “always work on your best idea”.
I’m in two minds about missing out on the video of The Witness. Maybe I’ll just bite my nails and wait for the official release.
Can’t wait.
–Phil
Regarding straight-line code: I do not agree with your reasoning for this recommendation. I would suggest use of anonymous namespaces (in C++) or ‘static’ functions (in a .c or .cpp file) to control the scope of something you know is local.
By extracting these blocks of code and naming them, we achieve a lot of implicit documentation and achieve a higher-level view. An optimizer will not have difficulty inlining the code.
Yeah, but even within a namespace or file, you have to build a mental understanding of that call graph, and that carries overhead…
I thought Jonathan’s inline code suggestion was a good one, but for different reasons than he outlined. Basically, I would rather have a somewhat long method with the code organized into “paragraphs” than to extract each of those paragraphs into separate methods for no reason other than to reduce one method down to a nifty series of calls. It’s nearly as easy to read/maintain the longer method, and much easier to read the rest of the code if it isn’t polluted by a bunch of little one-off private methods.
If I find myself writing very similar “paragraphs” two or three times in different places, then it’s time to go back and extract a method or even change the object structure. Of course, that’s in the context of a language and IDE that make such refactoring simple – and I’m not writing public-facing APIs where such changes ripple out to other people. I might have to reconsider the approach in a different scenario. Also, some people like to unit test *everything* including private methods. I’m not one of those people, but I would preemptively break things into small, testable chunks if I were.
Anyway, this situation is uncommon (for me, at least) because other design considerations usually limit the size of methods.
What engine/editor do you use? In-house handcoded?
Hi Jonathan!
Thanks for the lecture, was really helpful for me.
I’m currently learning computer programing as I would like to be making indie games in my life.
I’m coming to a point where I have to choose which University/College I want to study in for the upcoming years (I live in France). So, I am asking you: do you think that a video games-oriented school is a better choice than a Computer Science-oriented one? Even if, indeed, I know that I won’t probably agree to most of the design techniques I’m gonna study… Which one appear to be the “least worst”?
Thanks for all!
The answer to this question is usually no. There are a few good video game schools but most of them seem to be bad. I don’t know what the possibilities are in France and how good they are, but in the absence of this knowledge my advice is to go for the CS school. Either way, though, make sure it’s a good school, otherwise you might do better just learning off the internet.
Do you find Unit Testing a useful tool, as an indie?
I have never done unit testing and I don’t find it a very useful concept…
Sorry, I should be less specific and ask about any kind of automation of testing. How do you ensure that you learn about previously working things being broken after making code changes? If you’re a one-man team, it would be difficult to regularly manually test every single thing so I guess it’s just about being diligent?
As a one-man team especially, it is just about doing a good job and not breaking stuff.
Inevitably, yes, some things will break, but often when that happens it is a sign that those things need to be revised to become simpler.
Sometimes, though, breakage is just a fact of life, and I just suck it up and deal with it, fixing these breakages whenever they happen. Yes, it feels bad when things break like this and you don’t notice for a while, but I have never been in a situation where the amount of time spent fixing breakages like this exceeds the amount of time spent writing and running tests. In fact it doesn’t come anywhere close.
I imagine things would be very different for a bigger team, though.
is the synchronized slides/audio video still available?
Jonathan, thanks for helping me to realize how right I was all the time, when I was thinking of myself as being kind of ignorant. I had the intuitive feeling how to run things, but had trouble articulating the reasons.
This talk is a real weapon when having to argue with academics, performance nazis and occasionally myself. :D
Also thanks for using the words “acid trip” in your talk. ;)
Totally agree on the unit testing… been writing games now for 25 years, either alone or as part of a larger team.. never once in all that time thought that unit testing would come in useful! It’s academia coming up with abstract notions with no basis in the physical world and very glad you didn’t recommend it! ditto for all the other half baked constructs that are touted as productivity enhancing… sprints indeed!
…as a follow up.. in all the projects worked on, not one person in teams of 25+ experienced devs once considered unit testing as a good idea.
Back in the olden days (ah…), people just gravitated towards the ‘best way’ of doing things by refining the way they worked and the methods they used based on a combination of their own ideas, and ideas of others that they encountered… you ended up with 2 types of people:
innovators – made the new methods or ideas, and showed them through demos
subscribers -everyone else… once something was shown to be better, it was adopted
.. that mechanism evolved because it works… but the current status quo – and this is only my opinion – is that people have been allowed to assume the role of ‘innovators’ purely because they a) wrote a paper with a title that caused a high percentage of people to read it, or (worse) they didn’t write the paper, but agree with it, and b) the content of the paper went unchallenged… usually because it is wrapped in some kind of mathematical proof that no-one is either able (or can be bothered) to dispute.
result -> bad dev + programming practices adopted by the students… some of those become teachers, and the cycle repeats.. dont do it!!
If an idea or a new way of doing things is better than the old way, people can generally see the benefits and decide for themselves.. thats how progress is made… but its bothersome to me to see clearly poor methods being taught as the best way to do things, when they have not been universally accepted ‘in the field’ (or even tried!) , and instead only formed and accepted in academia, when by definition those 2 fields are mutually exclusive!
Thanks for giving a great talk. It really made me reconsider a few “truths” regarding code improvements. It was also eye-opening in the regard of respecting the opinion of people that are actually getting things done.
Hi…
Im trying to understand…you say to not premature optimize, and not care about other “super performatic” stuff, in order too speed up development, makes a lot of sense…But this goes tottaly contrary to the choice of language for a one man indie project (c++ plus directX, instead of flash, c#, java or whatever)..
When I heard you did Braid in c++ and directX the first thing I though was “wow, this guy is one of those performance fanatic ones that do all by himselves, awesome!”, I though you really enjoyed reinventing the wheel and stuff…so Im a bit surprised with the speech.
Dont get me wrong, since when I decided learn programming my focus is c++ and directX , Im one of those who ends up reinventing the wheel ( because I cant accept using things that I dont understand how they work, not because I think I can do better) ..
Lately I get introduced to c# and the difference in productivity is just scary, although I love programming in c++ and use d3d, I dont see much reason on using it for an indie project..I mean, getting stuff done is really what matter, and c++ is a big minus on the field.
So basically, why c++ if you not fanatic about performance? Does even the simplest c++ (“performance careless”) beats c# + unity or c# + XNA, at the point that the productivity of the later doesnt compensate? Was it more of a personal choice?(enjoying the language, more experience with it)..
It got longer than I expected, sorry, Im just really curious about your opinion. You see, I decided to learn programming because of games, and decided to focus on c++ and directX because of games, now all the indies coming in java/c#/unity are making me think about the direction I should take. And since you did REALLY great with the tools I most like, you are my main reference.
It is important not to prematurely optimize, but it is also important to be able to optimize, later on, the things that need to go fast. Slower languages / systems / engines prevent you from being able to do that. If you program in those systems from the start, you are locked in, and you are unable to improve the performance of your game later when you need to.
So please don’t be confused about what I am saying here. I am not anti-performance at all. I am saying that performance has its time and place, but that people are usually too worried about it. It is still important; the key is just to realize that most of the effort people put into worrying about efficiency is wasted, because it has negligible impact on the running code.
Thanks a lot, I really appreciate your insights! Congrats for Braid too, awsome game.
it’s vertices, not vertexes! :)
good talk, enjoyed it
nice talk. ironically (since the talk frames it as something you learn outside of school in the “real world”) in my very first programming class in college 14 years ago (Stanford CS106), one of the earliest slides simply said in big letters:
“premature optimization is the root of all evil”
of course it was somewhat tongue in cheek but the lecturer basically went on to make similar points as the first 20 minutes of the talk. great stuff, and i never forgot it
it’s unfortunate that this isn’t taught more widely though. now back in grad school, i see professors make this mistake all the time when instructing students how they should code :(
You do not know how much this had helped me Sir Jon! I am a 16 year old self taught programmer ‘making’ games on and off but generally crank more code than concrete games because I get caught up with designing the architecture of my code.
Then I learned KISS and YAGNI which made me think again on how important architecture is for my games. It made me remember you from Independent Game The Movie and decided to look up “Jonathan Blow Programming” in google and found this invaluable resource! Thank you again.
I would say that architectural decisions are terribly important. A bunch of tools you’ll never use aren’t.
These things are often best learned through refactoring. Just make something work. Then stare at your code. What patterns can be isolated from the monolithic mess?
Otherwise, even with the right architecture, you’ll probably get it wrong or not make anything at all.
There is such a wealth of information generated by brilliant people who have great things to say, but this is the first time I have heard any advice on what I really want to do from someone who does it. I don’t want to write code in a way that works for Blizzard or EA, I want to write games like Braid. Thank you for helping me do that!
I would like to hear your opinion on language choice. You sort of defended your choice of c++ to Giuliano Suminsky, and I’m of course aware of the performance advantages, but would you say you need to write in it so you can optimize later on down the road?
Obviously I agree with you and everyone else that c++ is unpleasant, but mostly I just like writing in Python. I’m not married to it, and if I need to switch to a lower level language, I will, but what do you think? And I know Eve Online is mostly in Stackless Python. I’m really more interested in what you think is best for a project more similar in scope to Braid or Terraria.
Python is only okay if you know for sure you will never need to make your game run fast. If it ever turns out that you do, then you suddenly have to rewrite the whole thing.
With something like Eve Online, I wouldn’t be surprised if the gameplay code is in Python, but I can almost guarantee you that the renderer and other heavy-duty, performance-critical parts of the game are not.
You might try a library that mixes C++ and python, like Panda3D. If you’re not doing anything technically fancy, that will probably let you live in python most of the time. (Disclaimer: I haven’t really used Panda3D, so can’t say if it’s the best C++/python lib … it does appear to be used for a number of commercial disney projects, and CMU student projects, though.)
What I’d like to see is series of tutorials about making simple, tile-based map editor from scratch (perhaps with libraries like SDL or Allegro to do rendering).
Also, deaf people would appreciate transcription of this talk. I’m not deaf, but my friend is and she has troubles with understanding this and I don’t know sign language so I can’t translate it to her in real time (we communicate mainly by using Notepad or old pen&paper in case computer’s not available).
He kept turning away from the microphone. Made a lot of it impossible to listen to.
This was incredible for me; answered a lot of questions that had been very vexing for me!
I’ve been absent for a while, but now I remember why I used to love this blog. Thanks , I will try and check back more frequently. How frequently you update your web site?