G
GM029
Guest
Is there an actual testing method? Do you just test on the oldest hardware you have lying around?
I'm pretty sure my game could run on a toaster.
I'm pretty sure my game could run on a toaster.
-
Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
D
DarthTenebris
Guest
As far as I know, simply mentioning "Windows 7 or later" is a pretty safe bet for Windows games. For Android games, that depends on the project you have. If you're not using any extensions, then whatever minimum API the manual suggests should be safe to follow. If you're using extensions, then take a look at their documentations, they might require a higher Android API version. No experience with any other platforms though.
Hope I helped!
Hope I helped!
The easy ones first.
RAM: Measure your game's peak RAM usage during the most RAM-intense scenario. Don't have memory leaks. Add 2 GB on top for the operating system's average memory usage. Round up to nearest integer.
Disk space: Your operating system tells you how much space your game takes up when exported and uncompressed. Include potential save files or additionally downloaded data. Round to nearest tens, hundreds, thousands... as you see fit for the sake of simplicity (don't tell your players they need 439662464 bytes of free storage space).
VRAM: Sum of the memory consumption of surfaces and texture pages you hold in VRAM at the same time. 32 bits per pixel.
Now the harder ones...
CPU: Test it. On a lot of different hardware, preferably. If it lags, it doesn't meet the requirements (or you did a crappy job at optimization). If it crashes when you dynamically load sprites that have widths or heights divisible by 8 (speaking out of experience), it's messed up beyond all recognition and you should probably call an exorcist.
GPU: Same as above, with the added notion that any strange visual artifacts translate to partially impaired compatibility. If multiple tests with different hardware yield such results, there may be a problem with your code rather than the hardware.
OS: Try running it. Ask others who have operating systems you don't have to run it. If it starts, it probably works. Maybe.
No way to guarantee this one without expansive (and therefore probably expensive) testing, so might as well just slap "Windows 7 or higher" on it for Windows targets.
HTML5 needs testing, but then again, do you ever see system requirement lists for browser games?
Mobile platforms have specific guidelines regarding API and therefore OS compliance, so you can look that up externally.
Err on the side of caution here - make the requirements too low and you might face an influx of people who barely meet the requirements complaining that the game complains about running out of RAM during your game's most intense moments on their potato. It's better to raise the requirements by a step in such cases. Gamers are notorious for attempting to play games even if they don't meet their system requirements, anyway.
If all else fails, there's always this.
RAM: Measure your game's peak RAM usage during the most RAM-intense scenario. Don't have memory leaks. Add 2 GB on top for the operating system's average memory usage. Round up to nearest integer.
Disk space: Your operating system tells you how much space your game takes up when exported and uncompressed. Include potential save files or additionally downloaded data. Round to nearest tens, hundreds, thousands... as you see fit for the sake of simplicity (don't tell your players they need 439662464 bytes of free storage space).
VRAM: Sum of the memory consumption of surfaces and texture pages you hold in VRAM at the same time. 32 bits per pixel.
Now the harder ones...
CPU: Test it. On a lot of different hardware, preferably. If it lags, it doesn't meet the requirements (or you did a crappy job at optimization). If it crashes when you dynamically load sprites that have widths or heights divisible by 8 (speaking out of experience), it's messed up beyond all recognition and you should probably call an exorcist.
GPU: Same as above, with the added notion that any strange visual artifacts translate to partially impaired compatibility. If multiple tests with different hardware yield such results, there may be a problem with your code rather than the hardware.
OS: Try running it. Ask others who have operating systems you don't have to run it. If it starts, it probably works. Maybe.
No way to guarantee this one without expansive (and therefore probably expensive) testing, so might as well just slap "Windows 7 or higher" on it for Windows targets.
HTML5 needs testing, but then again, do you ever see system requirement lists for browser games?
Mobile platforms have specific guidelines regarding API and therefore OS compliance, so you can look that up externally.
Err on the side of caution here - make the requirements too low and you might face an influx of people who barely meet the requirements complaining that the game complains about running out of RAM during your game's most intense moments on their potato. It's better to raise the requirements by a step in such cases. Gamers are notorious for attempting to play games even if they don't meet their system requirements, anyway.
If all else fails, there's always this.
G
GM029
Guest
Thanks! These are great.
The absolute simplest way to determine system requirements:
- Check your main machine's system specs. (E.g. right-click windows symbol in taskbar and pick "System" from the menu that pops up)
- Write those as the system requirements.