1. 12
  1. 5

    I realize that we’re heading toward the ultimate software engineer dream of making a type-checked change that’s run through a proven-correct compiler that does machine-learning driven, whole program optimization…but it’s going the exact opposite of the direction I want. It’s not helping me in my quest for creating fun.

    I actually think a strong type system creates an environment for faster iteration, and also reduces the number and duration of cycles by catching errors quickly - at compile time - rather than later (testing or runtime).

    Things like ‘whole program optimisation’ also probably shouldn’t be part of your core dev cycle.

    They might make things harder though, if they necessitate building a new executable of the entire game for every little change.

    Strong static type checking doesn’t necessitate a full rebuild of the executable, at most only of the module changed and then a re-link.

    Interactivity, I may have to grudgingly accept, is not trendy in computer science circles.

    Also disagree; every modern functional language I have used came with a very powerful REPL, usually more powerful than what I get from weakly/dynamically typed languages.

    At least I assume his interactivity point was in relation to his previous points.

    I don’t get to do much functional programming, and my Haskell is terrible. I fight with the type system, but each cycle is very short - enter a line or two, rerun, see errors, fix, rerun, see errors, … That cycle is far tighter than the dynamic equivalent - change a few lines, run suite of unit tests, see debug/runtime stack trace, trace through code, fix, …

    1. 5

      I think a lot of the comments in this thread are missing the point. The author says:

      Interactive tweaking beats a batch compile and re-launch every time, and great ideas can come from on the fly experimentation.

      My interpretation may be wrong, but I think the author isn’t looking for quicker compile times or quicker error addressing. At least in my (admittedly limited) experience, game design requires a very different set of tooling than other programming genres. One of the biggest things is not having to restart your game, and being able to interact with a running environment through code.

      Adobe Flash allowed this, as does Khan Academy’s code editor, there are also tools for C++ that allow it. The idea is that if I want to quickly edit an explosion’s color, or play with the behavior of an NPC, I don’t really need to worry about if there is some edge case where my code could fail, or if it’s a little glitchy, or if there’s a possible null reference exception if I walk through this wall I just put up. During the experimentation phase I should be able to have a way to quickly build a fragile yet easily modifiable mockup of what I will eventually finalize later.

      I’m not sure that any other programming genre requires this so much, besides animation (though that’s usually closely tied to game design anyway).

      1. 6

        As someone who has worked a lot on a medium sized project in a language with a strong, static and expressive type systrm (OCaml) and less on a large project with a weaker and less expressive type system (C++), better type systems absolutely help decrease iteration time, which is what this author seems to proritize, primarily through forcing you to make things less subtle and by making refactoring a LOT easier.

        It’s absolutely possible to go too far and have the types end up making iteration time slower, but I don’t think anyone with experience in both C++ (which most games are written in) and a language with a more modern type system (like Haskell or OCaml) would argue that C++ is closer to the ideal.

        1. 5

          better type systems absolutely help decrease iteration time

          A better way to phrase it might be that better type systems increase the time per iteration, but reduce the number of iterations needed.

          1. 4

            (as discussed below) I thin that better type systems also reduce the time per iteration, as within that iteration you hit issues sooner - compile-time rather than runtime.

        2. 2

          I thoroughly enjoyed a talk by Edwin Brady about Idris, especially because it put the systems under build in focus. The leading sentence was: “during development, programs are incomplete all the time” and then went on to describe how Idris solves that problem.

          Talk is available here: http://events.techcast.com/bigtechday9/barcelona-0900/?q=barcelona-0900

          1. 2

            “Rapid Iteration” and “Increased Type Safety” are a false dichotomy. I’m a .Net developer so I’m going to just cherry pick from my domain, but there are examples everywhere. F# for example is Statically Typed, with lots of type inference but also has a REPL, and even through libraries (think Akka.net) supports hot swapped code.

            1. 2

              Does anybody know of any programming languages or environments that support the sort of interactive game development Hague is advocating? I had seen Bret Victor’s talk before, and I’m not aware of anything that supports that kind of live tweaking.

              1. 1

                Exactly as he has shown, I don’t know, but Lisp and Smalltalk environments have support hot-code reloading for decades.

                1. 1

                  There is one that is used in production that I know of - ClojureScript’s Figwheel. Here’s an early demo of the author building a Flappy Bird clone in it. It’s since matured tremendously, and now this is the way everyone I know works with ClojureScript applications.

                  Elm’s Reactor has similar promise, though I’m less familiar with it and this mailing list message from Evan makes it sound like it’s currently in a non-functional state and it will takes some work to restore it. Playing with the live-reloading Elm tutorials on the Elm site is great fun, though.

                2. 1

                  Games are so different from every other field of software out there that I’d be loathe to draw overarching comparisons. AFAIK, nobody is asking game developers to drop everything in the name of typesafe, ‘correct’ code (although there might be an argument to make when it comes to netcode, especially when real money is at stake and/or cheating would ruin the enjoyment of others).

                  1. 3

                    I’ve spent the last 5 years in game development after 13 years in finance, and really, there’s very little that’s different between a game and a trading system. You have small pockets of intense, focused math; problems with modeling, caching, naming, and meaning; a giant never-finished bag of support tools and processes; and fewer resources and less time than you would ideally hope for. You have situations in which the non-technical are dictating the technical timeline. And you’re always hoping that something will be the magic bullet that buys you that breathing room for polish, so you’re always keeping your head up.

                    1. 2

                      I suspect that your company was a lot more concerned about the integrity of its customers' data, the correctness of the transactions you carried out, and about uptime, than seems to be the norm with respect to the equivalent metrics in the video game industry.

                      1. 2

                        Well you might suspect so, but everywhere I go I see dedicated, engaged, hard working game professionals, working on deep problems of scale, bandwidth, latency and state management. The failures you see in the industry are largely due to external third party publishers making calculated cost benefit decisions.

                  2. 1

                    A small re-ordering of the content would’ve forced the author to address some of this questions.

                    In the middle of the article comes his main thesis:

                    The one thing that does directly make a game more fun is decreased iteration time. Interactive tweaking beats a batch compile and re-launch every time, and great ideas can come from on the fly experimentation. The productivity win, given the right tools, is 10x or more, and I can’t emphasize this enough.

                    (Emphasis mine)

                    After this, he should’ve addressed his earlier questions one by one.

                    Does choosing C++14 over C++11 mean the resulting game is more fun?

                    Does using a stricter type system mean the game is more fun?

                    Does using a more modern programming language mean the game is more fun?

                    Does favoring composition over inheritance mean the game is more fun?

                    You could give an answer to all these questions by evaluating whether X allows a programmer to make changes faster than Y.