• Recent Video Tutorials

  • Programming Aesthetics Learned from Making Independent Games



    Jonathan Blow, creator of Braid, talks about his experiences and learned best practices he learned by making independent games. He was invited by UC Berkeley’s Computer Science Undergraduate Association to give this talk and posted this slide-based video on his blog.

    "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?"
    Watch the video located at www.the-witness.net.


    Video Author: Jonathan Blow
    Comments 12 Comments
    1. Traveler's Avatar
      Traveler -
      This is pretty interesting to listen to. The Doom anecdote was pretty funny.
      Thanks for posting.
    1. WILL's Avatar
      WILL -
      Thanks! I highly recommend this for anyone who is used to complex structures using Object Pascal in their projects. He explains some pretty interesting things about how you can code your games and avoid pitfalls that kill projects.
    1. Ingemar's Avatar
      Ingemar -
      My interest dropped when finding out that he used C++. A project like this done in FPC would be much more interesting.

      However, I really like the message at 23:30: "Almost all applied CS research papers are bad". And he is right. Complex solutions to non-problems are common. But ironically I think C++ is one of them.
    1. WILL's Avatar
      WILL -
      He might have used C++, but that doesn't mean his ideas and techniques can't be applied to Object Pascal. In fact he doesn't actually get into specifics about any language, instead he speaks in general about the coding for games. In fact I've seen many examples ofwhat he says what not to do during many past PGD Annuals and other non-competition projects here on PGD. Even my own projects in certain areas too. Many of us can learn a few things from what he has to say to be honest.
    1. Ingemar's Avatar
      Ingemar -
      I have one rule of thumb: Simplicity. Few seem to understand what it is. They happily agree that simplicity is good, and then they make complex solutions with dependencies all over the place.

      And those complex solutions ruin productivity. "Industry average" is quoted at 3250 lines per year. That's insane! That is more like a week or two. But if I would pick up someone else's C++ code, I would spend half a year just trying to figure out how the mess works, and then slowly try to make meaningful changes. I would work harder, be unhappier, and get less work done. Yes, that's why I don't do that. But I would earn twice of what I do now.

      So Jonathan Blow seems to know what simplicity means. "A generalized system is usually worse than a specific/hardcoded one". Yes. Code reuse is a myth. Don't try to make everything 100% reusable because it will eventually turn it unusable!

      In the past, I tried to get started with 3D games by building myself a 3D gaming framework. It just grew and grew and never got good enough to make a game. I was unfocused, trying to make a big system that could do anything. Now I keep the best parts, truly practical things like linear algebra stuff, but the rest I can hard-code for my project. I find more reusable stuff to isolate over time, but I have learned not to make that a priority.
    1. WILL's Avatar
      WILL -
      Yes exactly, this is what the talk is all about. I know a lot of other indie devs out there who try to make all these complex systems for their games, but never finish because they are so caught up in their object models and neat way of doing things, but they never just make the darn thing do the job without a degree of fiddle-faddle-ing with this or that. You look at my code and you might think that I've done too little, but there is a sort of purpose to that. I just don't want to get caught up in other things than designing my game.

      Not that I couldn't stand for some improvement, I have flaws too, but overly complex code is something I've been avoiding since my first big game project/engine that, surprise-surprise never got finished. Then again I've not finished many other projects, but I have other reasons for those.

      This is why I posted this, it makes you think about these things. I'm happy we managed to get a good discussion out of it too.
    1. Winwardo's Avatar
      Winwardo -
      Watching this certainly helped with my computing project for school i'm doing in Pascal - I realised it doesn't need to be all really well written and super clean and everything, at least not yet. It simply needs to do what it's supposed to first. It really sped up my development of it.

      Of course, now I need to rewrite a fairly large chunk of it now that it works so I can get good marks for the project for being consistent and readable, but that's just rewriting stuff I already understand, and doesn't require thinking up new solutions as such.
    1. Ñuño Martínez's Avatar
      Ñuño Martínez -
      It would be great if there's a transcription. I can understand a lot of things but there are parts that I don't.
    1. paul_nicholls's Avatar
      paul_nicholls -
      Quote Originally Posted by ?ëu?±o Mart??nez View Post
      It would be great if there's a transcription. I can understand a lot of things but there are parts that I don't.
      There are slides and a mp3 that you can download...does that help?

      cheers,
      Paul
    1. chronozphere's Avatar
      chronozphere -
      This is a real gem. Good stuff! I felt like I was allready aware of some aspects he discussed, but as he said, there is a big difference between "knowing" and "deeply understanding".

      I still feel that I could learn alot from these lessons as I tend to have an "academic" way of programming where you would generalize alot and use more complex datastructures than neccesary. I also find it hard to anticipate on what kind of functionality I need in the future, so I use that as a (false) argument to justify my overly complex/generalized code.

      You should always prefer the easiest-to-implement option. However, it's a matter of balance. In JAVA you can use an array or an HashMap and both are just as robust and as easy to use, while the latter is way faster for lookups. After I did some JAVA, I did another pascal project and I had the desire to implement my own Hashmap class, because there wasn't a solid generic one for both FPC and Delphi that supported generics. I found out that it was rather hard and errors kept creeping in. The alternative of using simple arrays made me feel dirty somehow, so I was stuck in an state of indecisiveness. Fortunately, talks like these take these problems away so I can be more productive again.

      Quote Originally Posted by Ingemar View Post
      My interest dropped when finding out that he used C++. A project like this done in FPC would be much more interesting.
      The fact that this guy makes use of C++ doesn't make this talk less valuable in ANY way. The way of programming in C++ is very similar to the way you program pascal. Same level of abstraction and the same constructs (classes, functions, pointers, inheritance, records/structs etc etc....). Only the syntax and some other aspects are different.
    1. Ingemar's Avatar
      Ingemar -
      Quote Originally Posted by chronozphere View Post
      The fact that this guy makes use of C++ doesn't make this talk less valuable in ANY way. The way of programming in C++ is very similar to the way you program pascal. Same level of abstraction and the same constructs (classes, functions, pointers, inheritance, records/structs etc etc....). Only the syntax and some other aspects are different.
      Of course it does. Obviously it would be more encouraging and more informative if it was about FPC. That doesn't mean it is worthless, far from it, especially for his view on simplicity and productivity that I commented on in my second comment. And I stand by my claim that C++ (as well as Java) is yet another complex solution to a non-problem.

      As Winwardo said, this kind of input helps you to remember to focus on the real problem instead of managing and repackaging code that you will never reuse anyway.

      And here I am, working on my iPhone framework instead of writing applications. Write the application first, repackage once you see what you want to reuse. I think that makes sense.
    1. Ñuño Martínez's Avatar
      Ñuño Martínez -
      Quote Originally Posted by paul_nicholls View Post
      There are slides and a mp3 that you can download...does that help?

      cheers,
      Paul
      Slides helped some, but not all. BTW, I can understand most of it.
  • Help the Community

    Donations help cover the cost of web hosting!

  • Community Affiliations


    Pascal Gamer Magazine

    DelphiGL Community (German)

    Free Pascal meets SDL

    Pascal Programming for Schools

    Independent Games Developers Contests (Russian)

    DelphiFeeds.com