About optimization

[Baguettator]

Hi,

I don't have really deep knowledge in optimization for my game. And I would like to ask about what I (or we) could do for it when time to optimize the game comes.

For my own situation, my game uses lots of data (strings, int and some custom structs with many variables inside) because it is a simulation of a tabletop game.

I already made that the game doesn't "memorize" all the data of all the maps, instead the game reads txt files with data stored in. This replaces big arrays of structs containing hundreds of data with only 1 instance of the same struct.

It was a first step.

Now, my game has many many texts. Because, many things to tweak, many things to explain, many GUIs... and it's needed. Do texts (strings) have to be optimized ? To have a "lighter" game while running ? I thought that many texts could be used like that :

Code: ags

String Givetxt(int n)
{
  if (n==e_eventFood) return "This event gives food !";
  else if (n==e_eventTools) return "This event gives tools !";
}

void DrawEvent(int n)
{
  Labelevent.Text=Givetxt(n);
}

Instead of :

Code: ags

String events[2];
events[0]="This event gives food !";
events[1]="This event gives tools !";

void DrawEvent(n)
{
  Labelevent.Text=events[n];
}

If my texts don't need to be accessed for any reason (for example, if I need to know which event has been drawn, I can just memorize the "index" of the event with a single variable taking its value "n" in the DrawEvent function), it can avoid memorizing an array of strings, without beeing "laggy".

I think strings are loudest data in AGS, int are generally needed and can't be optimized I presume.

Am I right in this point of view ? Should I optimize like I said ? Or is it near no difference at all ?

[eri0o]

I only look into optimizing things that run many times in a frame.

About strings for custom things, as data, if you can have them in a separate file (that's packaged with the game using the $DATA$ token for reading), this can make it easier for you to change and update things ignoring the data structure in your game, which may also help you play with different things.

[Crimson Wizard]

Optimization is commonly done for:
- speed
- runtime memory
- disk space
- convenience of coding

Sometimes optimizing for one thing makes it worse in another. Sometimes it's okay, sometimes it is not.

But you should not optimize unless you have a proof that the current state is problematic.

I think strings are loudest data in AGS, int are generally needed and can't be optimized I presume.

If by "loudest" you mean "taking most memory", then that would be graphics.
You may put an effort optimizing memory taken by strings in script only to find out later that your game's memory requirement went down by 1%.
So before optimizing, try to have a good idea about how much do they take, and if that's really is a problem.

EDIT: also, strictly speaking, "ints" can be "optimized" by packing several values in one. Although nobody does this today, unless there are millions of values maybe.

[Danvzare]

From my own understanding, generally when it comes down to optimization, memory being used by variables such as strings or ints should be pretty low on your priority list. You can optimize things a bit there, use shorts instead of ints when the value doesn't go above 30,000, that sort of stuff. But any benefit will mostly be negligible.

What you actually want to do, is optimize any functions that are repeatedly executed.
For example, let's say you have a function that checks if the cursor is on the left side of the screen, the right side of the screen, or the center.

Code: ags

if(cursor==left) do this;
else if(cursor==right) do this;
else do that;

Now let's say this function runs every time you click. You expect people to click a lot, and for some reason, you also expect the cursor to be in the center 90% of the time. You'd want to optimize the function because it's running a lot, and the best way to optimize it would be to check if the cursor is in the center first, so it can skip the other checks.

Code: ags

if(cursor==center) do this;
else if(cursor==left) do this;
else do that;

This is a vast over simplification. But that's one thing can do when optimizing your game.
Another would be to look over your code and see where things can be simplified and made more elegant. Once again, the benefits are usually negligible, but if it's a function that runs a lot, it could add up.

In general though, you usually don't have to do optimizations unless you encounter an issue.
Doing so will also help with testing. Since it's a bit hard to know if what you've changed has made things better or worse, when you literally can't see a difference (because there isn't a problem with which to see a difference in).

[Crimson Wizard]

Now let's say this function runs every time you click. You expect people to click a lot

"Often" in human's perspective is not so often in CPU perspective. If the game is run in 60fps, then humans clicking is considerably less frequent, and usually not a problem. Something to also keep in mind: CPU can potentially do alot of things in a split second. Even if your operation is not so optimal, it may still be a fraction of what CPU can do, so it will do your inefficient operation and then rest, waiting for the next event, and nobody will notice anything. It becomes a real problem when the total work that CPU has to do at once exceeds a duration of game frame regularly.

I'm saying this, because in the past I've seen people trying to optimize things that are never going to be a problem (or asking questions about how to do that), but miss things that really would be nice to get fixed. I probably did the same...

Of course, your example of checking for the highest probable variant first is a valid optimization example on its own. I doubt that it will improve much in the described case, but such thing may improve alot in certain other situations, when the condition checking itself is slow. That is more relevant when hundreds or thousands of similar checks are done in a loop.

I remember a real case when switching an order of condition checks inside a AI logic improved fps in a game from 4 to 40 (not making this up).