string ForePicture = "EmblemData.Fore_21"; string BackPicture = "EmblemData.Back_05"; Color ForeColor = (B=139,G=60,R=71,A=255); Color BackColor = (B=11,G=183,R=255,A=255);
int EmblemData = 21051402;
have in common?
The answer is that they’re exactly the same. Both are methods of storing data needed for an emblem system, which consists of a foreground picture/color and a background picture/color. The difference is in how the data are handled.
In the first example, everything is stored in a “raw” form that can simply be plugged into bits of code to achieve a result. The pictures are saved as UDK package paths that can be directly referenced, and the colors are saved as actual color variables. As a result, the code necessary to handle these variables is very light (and fast), with the tradeoff being that the save state is bigger.
In the second example, we have just an integer. But notice that 21051402 is the same as 21 5 14 2, which pretty much means “load foreground picture 21 and background picture 5, and set the colors to indexes 14 and 2, respectively”. Of course this system offers less control over colors since we have a predetermined set of colors to choose from (14 = purplish and 2 = gold), but storing just one integer in a save file is much less expensive on memory. The tradeoff? Well, obviously UDK has to do more work parsing the integer into something it can actually understand.
I bring this subject of save state efficiency up because I think it’s sorely missing from some recent UDK games (I won’t point fingers). “Who cares?” you might ask. “After all, UDK runs on PC’s! And most PC’s these days have more than enough RAM and processing power to handle even megabytes-large save files.”
However, UDK is also handling a whole lot of other stuff while it’s chugging away at your save system in the background. You may not think some innocuous overuse of data compression, or too many system variables in memory, harms your frame rate — but it does. Sure, the effects may not be immediately noticeable (A 1 or 2 FPS drop? Pssh…), but they’re still there; in the long run, your game becomes less stable and professional as a result.
The question is, how to balance save size and save complexity? Both examples up there had their respective flaws despite accomplishing the same goal, so which to choose? The answer is, it’s ultimately up to you and the needs of your project. Coming from a background in primitive 20-KB RAM TI calculators, I would most definitely choose a system than minimizes save file size and uses clever compression techniques (the above example is usually dubbed the “CONTRA line scheme”).
But that’s just me.