I admit that, for Java, the gain in language expressiveness isn't worth taking the performance hit, because the former is so minimal. On the other hand, moving to a truly high-level language with half-decent performance (e.g. Ocaml, Clojure) might ameliorate the schedule slippages for which that industry is known.
I do agree, however, that this doesn't make C/C++ necessary for game programming. That's probably why modern game engines let you write a great deal of the game logic in a scripting language.
Of course, most C++ code I see - even in language performance benchmarks - doesn't vectorize either. g++ isn't particularly good at it and most people don't know how to do it.
Games are made in iterative process, you change sth, test, etc. You don't know if something is fun and looks good without testing it. And it's really hard to upfront design for fun.
Without side effects most of the time programming in this way is spent maintaining long arguments lists and passing them around to be able to add even very small features.
You want to play sound when player leveled up? Pass soundManager through this 7-functions-long callstack. Now you also want to shoot stars around the player on the occassion? Pass this ParticleEffect handle too. Oh, but the effects should vary depending on the region the player is in? Pass that information to that function too. And time of the day, while you're at it, so stars can be blue at night and yellow at day.
In the end you give up and pass WorldState variable to every function. I don't think pure functional programming is good for prototyping games.
I thought about this problem a little, and I think this could be solved by structuring the WorldState variable into a tree, and writing a script that you run after the game is done, that looks inside functions for which parts of the WorldState they really need, and changing them accordingly, so the code is easy to read and functional after the experiments are done.
Edit: Here's a guys experiences from making a game in Clojure a year ago:
http://stackoverflow.com/questions/9755882/are-functional-pr...
http://clojurefun.wordpress.com/2012/09/03/ironclad-steam-le...
Of course, Clojure has wonderful concurrency as well, so you can ameliorate the cost of using Clojure by spinning up more threads. However, games are a tricky thing to parallelize, from what I know. Especially as the only place you can actually make OpenGL calls is from the thread a program is started from.
I wouldn't recommend Ocaml for games though. Use Haskell or Go instead. Ocaml might be speedy, but it has a GIL, a la Python or Ruby. Also as far as I've found, there are basically no bindings libraries out there for opening windows or making OpenGL calls. And I might be misremembering, but the libraries that did allow you to use OpenGL used 1.x or 2.x versions, meaning you can't use a modern pipeline.
There is nothing worse in LD than seeing the voting screen filled with Windows binaries you don't want to download.
Here my entry this time if anyone's interested ;)
http://www.ludumdare.com/compo/ludum-dare-27/?action=preview...
For graphics or physics it's easy to make a demo - you render a spinning buddha or simulate a hundred balls, show how much CPU and GPU it takes and everyone can extrapolate this to the full game. I don't know what could be a sufficient prove of Ocaml viability other than a full game written in Ocaml.
I am not familiar with indies or mobile but I imagine, they are even less likely to risk as their chance for success is already pretty low and it would be rather reckless to add more unknowns from an untested technology.
AAA game engines are still all about performance and tight memory budgets due to the nature of the platforms they're developing on - consoles and PCs. Hence the aversion to garbage collected languages, although higher level languages usually make it in the engines as scripting languages for game logic: UnrealScript for UDK, C# and UnityScript for Unity, Lua for CryEngine... The industry is traditionally oriented towards C++ and imperative / OO languages, but there's a lot of potential for functional languages in the "embedded scripting" area. In his 2013 QuakeCon keynote [1], John Carmack talks a bit about his experience with functional languages, and how, for example, Scheme could be an ideal candidate as an embedded scripting language.
As far as smaller teams are concerned, and especially indie development, there is a lot of potential for OCaml, Clojure and other functional languages. Many mobile and indie dev teams already use a heck lot of C#, Python, Java and other specialized tools like Haxe, ActionScript. But all these languages have well liked and mature frameworks geared towards game development (XNA / MonoGame, PyGame, OpenFL, libgdx, ...), which is maybe what Clojure and OCaml are missing right now.
You can also check out the nice wrapper around the Processing library called quil: https://github.com/quil/quil
http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-...
Lambda the Ultimate has more discussion of the talk, including comments from Tim Sweeney:
While the article lists many plausible reasons why the pace of work turned out to be faster on the shorter project, there is also one that is not mentioned but perhaps the most important: complexity doesn't scale linearly. It's always faster to write the first 1000 lines of code from scratch than to add 1000 lines to a project that is quite large already, mostly because each newly added component has a growing chance to interact with an ever increasing number of older components.
This effect is particularly insidious, because often the long slow complicated thing that the product manager wants is just the sort of interesting challenge that developers enjoy. They don't point out to the product manager that there is a simpler solution, because that would take away the shiny toy. LD does not have this problem because the developer knows that she can't allow herself to go off on a 3 week exploration of compiler theory, because otherwise her product won't be ready in time.
But I am not dismissing your argument on the delay imposed by the extra layer between the project manager and the developer, specially if they have no programming experience.
I agree that complexity doesn't scale linearly. That's a very insightful thing to note. However, the fact that LOC correlates with "probability of a change causing unintended consequences" in many codebases is coincidental rather than causal. The underlying cause of the unintended consequences is almost always poor structure and/or poor planning.
Two words: cohesion and coupling.
Highly cohesive systems which are loosely coupled are far easier to extend and modify without fear of weird and unintended "spooky action at a distance" interactions.
1. Each module necessarily has access to functionality provided by all its "ancestors". In the best case, this number still grows logarithmically with project size, and accordingly the difficulty of adding or modifying code in a "leaf" module.
2. New libraries and language features are generally seen as a neverending bonanza. But before you can effectively modify a module you need to understand how it currently works, which necessarily involves understanding the external tools used in it (quirks and all). As the variety of these external tools increases with code size (at quite possibly a super-linear rate), the complexity of working with any given module deepens accordingly.
The Holy Grail of software development would of course be perfect layering: each layer completely masks its predecessor, and is no more complex. Someone who achieved it could indefinitely roll off as much useful code on day 500+ as they did on day 1. But I'm not aware of any practice or methodology that dares to even remotely promise such utopian benefits.
On the other hand companies generally put their very best developers on new products and features - i.e. writing those first 1000 lines. While the mediocre devs get to extend and maintain those products/features, by copy paste or what got you.
There are no external constraints on my work. When one artificially arises, I get my best work done, quickly. It doesn't burn me out because a rest comes afterwards.
I have no idea how to replicate this urgency consistently.
The nice thing about it is that it stops you from getting distracted on a constant basis and you have something done at the end of your sprint.
Also reading up on perfectionism might be interesting (hint: it often doesn't end with a perfect result but it is always time consuming.) YMMW.
Much better to eliminate distractions, in my experience (selective site blocker, headphones with white noise or coffee noise or wordless trance, and an IDE that never stalls.)
I don't think I'm a perfectionist, and agree it is to be avoided.
It's remarkable that modifying C++ headers is such a chore that it comes up as a reason for getting something done in a tiny fraction of the time for a roughly comparable task.
Couldn't agree more. Though I don't find it all that painful - lots of editors/IDEs have a 'go to header file' shortcut that makes this take a couple seconds at worst.
But then I have repeatedly wondered why IDEs don't seem to have a way to synchronize your cpp changes to your header automatically. Rename function in .cpp -> automagically rename function in .h. That's all you really want a lot of the time.
I want a tool where I can do this but in JavaScript on a canvas.
http://strlen.com/java-style-classes-in-c
You write all the code for your classes inside header files and include them inside another class in main.cpp. That way you get around "declare before use" rule using uncommon feature of C++.
Makes me wonder if it would make more sense to cram a 40 hour workweek into 3 days instead of 5. I think it'd be more enjoyable as well.
C++11 has been around since `past several years'!?
Yes, but it used to be called C++0x and the official spec was still in the works. However, you could actually use most of the features in GCC and some other compilers years before the spec was out.
http://www.youtube.com/watch?v=f90R2taD1WQ
His main point is that building a game is no longer about what you can do, but rather what you can get done.
His point about metawork really hit home hard. I'm at the end of a 4-year project now, and I'd estimate 90% of what I'm doing is what he calls metawork.
The major takeaway I got from it was that I should try doing some 48-hour projects myself - or perhaps find some 48-hour film competitions to enter - and see what the results are.
And, of course, write them up as a blog entry.
I discovered this when I started building game ideas in Javascript instead of Xcode. I'd have a skeleton pounded out in an hour or two, and I'd add features in minutes instead of hours. I took a list of things that I though would take me the weekend, and I completed them in an evening.
