Re: Battle Field audiogame
@20 is (sort of) wrong. Every point they make is correct in isolation, but we're talking about audiogames. No one needs anything faster than Python for an audiogame unless it's the world's biggest audiogame MMO.
I would like to take this moment to remind everyone that SoundRTS is in Python and isn't using any of these C libraries that people keep trying to bring into the discussion. After it was optimized it was handling upwards of 5000 units in realtime, and could probably have handled a lot more than that, except that getting more than that into your map in any reasonable length of time using normal gameplay is hard enough that I've never seen it happen--indeed, someone's usually won well before the 5000 unit point and I only ever really saw it because there was a group of 3 or 4 of us who all played together obsessively for a couple months. Python's data structures are fine.
Our games, even the biggest games we have, are as sophisticated as the sighted equivalent of 1995, minus the graphics, which even back then was most of the computing power. Computers have increased in performance by hundreds of times. People can run games from 1995 inside a Windows emulator inside their browsers on a high-end phone. Python is maybe 10 to 20 times slower than C, and we are also not doing graphics. If you're reaching for the Python science stack to make your game fast enough, then either you're overcomplicating your life tremendously or you have the single most complex audiogame ever produced by a mile.
Better algorithms, i.e. spatial hashing for collision, will probably solve any performance problem you face. Better storage methods, i.e. interval trees instead of lists of lists, or even just storing your tilemap in one flat list and doing some very basic math, will solve your ram issues.
I don't think people understand the difference between machine learning and everything else. Those nice Python science libraries aren't meant to run on anyone's machine inside Py2exe and in fact need a GPU, usually specifically an NVIDIA GPU, to really get all the performance out of them. They're designed to handle datasets in the terabytes on supercomputing clusters, and some of them even expect that you're going to have the Cuda compiler installed. They're actually very pleasant to use, but if that's not the problem you face today, it's probably not worth worrying about using them.
If you go take F# or Scala and go to town on the functional features, you will end up with something slower than Python because of the copying and the fact that really those features aren't so great when the problem is mutate every game entity. You can eventually end up with something faster, but it will take a lot of effort. Functional programming has places where it shines but is first and foremost about expressive power and generally assumes you're always making copies of things, so if V1 of your game copies every game object on every tick go for it. Otherwise you'll be optimizing your code a lot to equal Python. But again, since this is audiogames, the performance hit really doesn't matter--you can be 10 times slower than Python and still have a playable game. If you want a native language Rust isn't a bad choice except that learning their lifetime system isn't exactly new programmer friendly (and I say this as someone who contributed a big patch to their compiler).
Game networking is the normal game loop, plus before you tick you read all incoming messages and after you tick you write all outgoing messages. Python isn't necessarily the best at state of the art networking, but again, this isn't something you need state of the art networking for, and in general Python is good enough at networking that there are very large companies relying on it as their business (for example Zapier).
If you're new to programming and you're considering threads to solve a problem, chances are you're not going to solve the problem and will just be adding the new problem of threads.
BGT doesn't have threads. BGT doesn't have concurrency. BGT doesn't have functional programming. Python has threads, concurrency, and some functional programming. I'm not sure why people keep trying to reach for harder, more foreign things to write their games in.
I would love to live in a world where audiogames had 20 years of innovation that we don't have, where people solved all the problems with things like true 3d environments that we probably can't solve ever, and where all of these concerns people keep bringing up are actual problems that we need to solve. Instead, the world we actually live in is one where our games are, as I said, the equivalent of 1995, and most people on this forum own a computer with the computing power equivalent to a 1995 supercomputer. I mean seriously, in addition to my point about running games in the browser, doom runs on pocket calculators from 5 years ago.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
