= 27d567bc2d48d9f40e9ccc20ea370b15)
fezziwig comments on June 2014 Media Thread - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (95)
Just a matter of time. We're already a long way from assembler, and the indie games represent the low end which will gradually eat the high end's lunch.
Given Haskell's excellent concurrency support, I'm not sure that's true.
Unfortunately perf isn't the only roadblock here; middleware is a real problem too. Even if you write your game in Python, your AI, physics, and tree-drawing components were all written by somebody else, in C++. No matter how good your bindings are you have to do some data conversion every time you talk to one of those libraries, or else use C++ data types in your Python game engine.
That's not to say that soft real time constraints and tight bounds on memory usage and so forth aren't also hard problems, just that even if you have those things you still need the ability to carve out 12 bytes, put 3 4-bytes floats inside, and give it to Havok unaltered. Eventually people will port Havok and SpeedTree and such to your HLL (or write new better ones), but it's a chicken and egg problem: no one will do that until there's a robust market of studios using the language.