Re: Battle Field audiogame
@26
I'm not sure arguing with you is worth it because you seem to be taking this way too personally; but I will try. As I said your points in isolation are correct, however together they lead down a not so great path for games. Also, I do know what I'm talking about; I spent 6 months working on the Rust compiler (source), have 15000 lines or so of C/C++ to my name before we count work, have worked on massively distributed media transcoding projects and systems with entirely custom database solutions among others, and my current job uses both haskell and OCaml. I'm not saying "I am an authority, so shut up" but it would be nice if you didn't yell at me because you think I don't understand the basic characteristics of programming languages, especially ones that I actually like.
Firstly, no one knows how to do a 3D game for the blind, and we don't even have the audio technology for it. We have audioquake from a long, long time ago, but almost no one could play it because the controls were absurdly complicated--indeed there were more controls than keys on your keyboard. Secondly, I'm not sure where the game having to be 3D entered the discussion. Thirdly, Quake was 3D and 1996, so my points about how computers are 1000 times more powerful than back then and how Python isn't even close to 1000 times slower than C still stands. Fourthly, there are at least 2 or 3 muds who have done 3D in moocode for the last 5-10 years or so without a problem, which as far as I know is on par with or slower than Python.
But also, games aren't data processing. Functional programming is great, but not so great if you have mutable data all over the place, and this is especially true of something like Haskell where the IO monad creeps into everything. Additionally, those approaches scale most often because problems are trivially parallelizable. But also, as I said, it doesn't really matter whether you use functional programming languages or not either, because anything you use is going to be fast enough for anything you might want to do within the limits of what audiogames can be. If you have a proposal for some new form of audiogame that is somehow more computationally intensive than sighted games from the 90s this becomes a different discussion, but that would be the first proposal along those lines that I have ever seen.
I think it's worth closing on the point that Haskell, F#, etc are not really new to programmer friendly languages, and that if someone is asking "is Python suitable", then probably those languages are going to be like a brick to the head. In the very, very unlikely chance that Python is too slow, you get out Cython and you throw it at your problem, but until that point the most crucial requirement--that the language be easy to learn--is met.
Don't worry about performance. Write it in a tool that you like. In the unlikely chance that you prove performance is a problem and you can't fix it with a better algorithm, you've found a good problem to have and can worry about it then.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
