By fun coincidence one of my personal projects has been the opposite; trying to build AIs that can experiment with generalized games.
The needs of a project like mine are going to deviate from other suggestions on here because I'm explicitly not working with neural networks or genetic algorithms. The lists other people have put up (esp nrmm) are really good for those, which is not to say mine won't have any overlap.
Given the choice between supporting something on my list or someone else's, you should definitely prioritize someone else's. If you want a lot of people to do research with your game, optimize for ML.
That being said, because I'm greedy, stuff that matters specifically to me, in order of importance:
- Encapsulated State: I want to be able to get raw access to the game's internal memory, esp through an API. Byte array is fine, labeled is also good. Basically any variables or memory that are used in game logic should be exposed. If possible, this state should be separated from any state information you're using for graphics, sound, etc...
Note that this does not mean you should encapsulate your entire game into 20 or 30 basic variables and just expose that. That's cheating. Classification of a game state is as important as building a strategy, so the point is to provide your state at a (relatively) low level with only a few abstractions, or at least abstractions that can easily be stripped out for training.
- Headless Mode: I want to be able to run the game on a server or in a low resource environment by disabling as much of the graphics stack as possible. Linux support is also obviously useful since the majority of the server world is using it.
- API-driven input: I want to be able to control the game without mocking button presses on a keyboard. Extra plus if your game is controllable via a scripting language like Javascript, it's trivial for someone to build their own adapter if they have something to call into.
- Serializing/loading state: Emulators are great for AI research because you can export out the entire state of the game and reload it later for testing/comparing results. This isn't essential, just really really useful.
- Easily recordable output: This is a tiny thing that just makes life way easier. If you can pipe your game's output to a video stream without recording it off a desktop (ie, can I stream your game from a headless server), then it just makes it a lot more attractive for building demos or toys.
Loads of bonus points if your graphical display can be run as a separate process from your game logic. More bonus points if they can communicate over a network. All of the bonus points if your graphics engine is embeddable in a web-browser or is similarly scriptable to your game logic.
And some stuff I don't really care about:
- Synchronous game logic: Most games try to keep their logic divided into synchronous chunks that are executed every frame. This is not particularly important for the types of research that I'm doing, async code is fine. Your game will probably be running on a remote server anyway, so someone in my position is hardly ever going to be looking at every single frame in series.
- Seedable RNG: It's nice. I guess. But unless someone is running your game locally and interacting with it via synchronous steps, they're going to be dropping random frames anyway. So it doesn't really matter.
- Extreme optimizations: I'm overstating this a bit - obviously your game needs to be optimized. If your game requires a GPU to run at a decent clip, that's a problem. BUT, if your game is fast enough to run reasonably well on limited hardware (especially in a streaming/headless mode), that's good enough. Aim to support single-core hardware and small dedicated devices like the Raspberry Pi.
This is terrible advice if you want to support reinforcement learning. In all likelihood you should optimize the crap out of your game for that. But, for the type of research I'm doing, I will practically never be running a game at more than 1-2x speed.
Portability and elegance > raw speed, unless you care about training a genetic algorithm or something.
- A fitness function: Honestly, probably not even the traditional ML crowd needs one. If you expose your game's state in a way that they can consume, then anyone can write their own fitness function on top of it. You don't hurt anything by adding one though, I guess.