If you've got, say, a meg to work with, it's really not worth it to try and do prime factorization of numbers for achievements. At that level any information about your character: name, items, level, progress, achievements are all going to fit quite easily. You'd be more concerned about saving world state. For example with a game like Oblivion where you have a persistent world and items stay around for a long time.
There's a saying in the software industry: Premature optimization is the root of all evil. It's usually referred to for performance, but I think the same holds true for file sizes. If you write your program correctly and the medium you're using has no problem with the file size, and it doesn't pose any delay you care about when saving/loading, then you don't need to worry about it.
If you spend a lot of time shaving off bytes here and there, you're likely to introduce some nasty bugs that stem from the clever and complicated algorithms you used. And that's a risk you shouldn't take if you didn't really need to optimize.
If you take the standard approach, for, say, a game like Half-Life, you've got health, armor, inventory (a list of 1-byte item IDs), your current level (1 byte), your current position, orientation and velocity (20 bytes for double-precision floating point numbers), your current weapon (1 byte), your weapon animation state, and maybe a few bytes for flags like reloading. All of this is a handful of bytes, but is nothing compared to the level data. You might the locations, orientation and velocity of entities on the maps, for 20 bytes each. Perhaps some of these have a few numbers for their current status (alarmed, idle, etc) and a number for the current progress in their animation. So perhaps 28 bytes. Throw in, say, a thousand entities and your file size is looking about 20-28K. Any reasonable number of achievements you care to tack on are going to be basically nothing.
If you did want to optimize on that, it would focus on the world state, where you could get the most savings. You might decide that you only need the position on powerups or enemies that are off screen. You might be able to effectively ignore areas that are inaccessible behind you to cut down on the numbers of entities you have to save.
Nope, I'm working at MSN, doing backend server stuff. Though some concepts I deal with are sort of similar, such as serialization of data ("flattening" a data structure to pass it over the wire to another computer). Anyway, yeah, XNA is a good way to get into game programming. C# is quite a friendly and powerful language.
If you've got, say, a meg to work with, it's really not worth it to try and do prime factorization of numbers for achievements. At that level any information about your character: name, items, level, progress, achievements are all going to fit quite easily. You'd be more concerned about saving world state. For example with a game like Oblivion where you have a persistent world and items stay around for a long time.
There's a saying in the software industry: Premature optimization is the root of all evil. It's usually referred to for performance, but I think the same holds true for file sizes. If you write your program correctly and the medium you're using has no problem with the file size, and it doesn't pose any delay you care about when saving/loading, then you don't need to worry about it.
If you spend a lot of time shaving off bytes here and there, you're likely to introduce some nasty bugs that stem from the clever and complicated algorithms you used. And that's a risk you shouldn't take if you didn't really need to optimize.
If you take the standard approach, for, say, a game like Half-Life, you've got health, armor, inventory (a list of 1-byte item IDs), your current level (1 byte), your current position, orientation and velocity (20 bytes for double-precision floating point numbers), your current weapon (1 byte), your weapon animation state, and maybe a few bytes for flags like reloading. All of this is a handful of bytes, but is nothing compared to the level data. You might the locations, orientation and velocity of entities on the maps, for 20 bytes each. Perhaps some of these have a few numbers for their current status (alarmed, idle, etc) and a number for the current progress in their animation. So perhaps 28 bytes. Throw in, say, a thousand entities and your file size is looking about 20-28K. Any reasonable number of achievements you care to tack on are going to be basically nothing.
If you did want to optimize on that, it would focus on the world state, where you could get the most savings. You might decide that you only need the position on powerups or enemies that are off screen. You might be able to effectively ignore areas that are inaccessible behind you to cut down on the numbers of entities you have to save.
Reply
Amber says "Hi", by the way. She says she's sorry she hasn't called you lately.
Reply
Oh, and "hi" to Amber.
Reply
Leave a comment