Ylands:Best practices

Making a great game may not be enough - your game needs to run well as well. If your game runs slow, it may not be a problem, if it's a puzzle game, but, for example, an action game will very likely become unplayable. An even if your game runs great you may run into problems if it takes up too much memory on mobile devices.

And that is where optimization and knowing what to do and what to avoid comes in. Let us share with you some tips that will help you have great, nicely running games.

Platform:

You can make two kinds of games. PC only and Universal (PC + mobile phones).

PC Only

If your game is meant to run only on PCs, then you definitely have it easier. Every decent PC has enough power to run rather complex games so even poorly optimized games usually run quite well. The tradeoff is obvious - your game can reach substantially less players.

Universal

Making a game that runs well enough even on mobiles can be tricky. There is an extreme range of mobile devices from super slow ones to ones that can almost compete with computers. Even though players can affect visual details ingame to make the game run better it's up to you to optimize it as best as you can. The better job you do, the more devices (and therefore players) will be able to play your game.

So, let's get started.

Memory:

You won't run into memory problems on PC, but you surely can when running your game on mobile devices. To make sure your game won't be terminated by the device's operating system when it consumes more memory than allowed you should watch the memory gauge in the lower-left corner of the screen in the Editor (or click it to see more information). Try staying in the green. Going in yellow means potential problems and you shouldn't definitely be in red.

The rule of thumb when trying to save memory is - simpler objects (like building blocks, game objects) take less memory than sophisticated objects (like NPCs, animals etc.). Using more identical objects is better than using fewer unique ones so using one hundred items of the same type will consume less memory than having 5 different items.

Also the larger your map is, the more memory it requires (given that it contains terrain). The smaller the map, the better.

Please note, that this gauge shows only what is currently present in the open scene. If your game spawns a lot of / complex objects during runtime, this information may be less relevant.

Level design / game objects:

Some games can be made just with few blocks, other require terrains, sophisticated buildings, vehicles, characters, numerous particle effects. And so it's only logical that the more complex your worlds are the more attention you need to pay what you place in them.

The basic optimization rule is the same as with the memory - the fewer different types of objects you use, the better will the game run. But there are many more things to bear in mind:

• good level design is one, where players, no matter where they look, see the similar scene complexity. This means that if you, for example, have a mostly empty scene with one very complex area, when players look around and this area comes to view a visible stutter in game performance can be noticed.

• visually the most complex objects are NPCs and animals. They require quite a lot of both CPU and GPU power so if you're aiming at mobile devices (especially mid or low spec ones) you should be very careful with how much you put in your world

• there is no culling other than ignoring objects outside the camera frustum. In less technical language - what camera doesn't see takes up little to none performance. However, one needs to understand that these are the object positioned outside the camera cone (so it's above, below, to sides or behind the camera). Everything that is in front of you in this cone is rendered/calculated regardless of whether you see it or not. If you're looking into a wall, even though you don't see through it, the game does and still treats the objects behind it (performance-wise) as visible. The same goes for the terrain.

• a good game creator should check their game with the profiler we're providing exactly for these purposes - we will get to it shortly.

Scripting:

Scripting, when done without following some basic rules can result in games that run awfully slow so let us mention few things to do and avoid:

• best scripting is event-driven, meaning that unless necessary, you shouldn't perform any continuous loops checking for state changes, time elapsed etc. Before you run continuous loops in your code, check if there isn't a Game Logic that would suit your needs. Hook your code to Game Logic-specific events or listen for any in the game with Event Listeners.

• if you're performing anything very often inside very short Time Trigger event the chances are there is much cleaner and faster way of doing that

• note that every frame the game waits for the all the scripts to be processed and only then continues. This means that inefficient continuously running script will constantly lower your fps. If, on the other hand, you use from time to time very intensive scripting operations, this may create sudden fps drops. If this is your case, try not doing everything at once but spread the load over script executions. Remember, that consistently lower fps is better than high fps with noticeable fps drops.

• in general, the most performance heavy action is spawning a new entity. This may not be visible in the profiler since the actual scripting instruction to spawn something is fast but it can take time for the game engine to actually make the object appear. If you need to spawn object in runtime, consider having them ready in the editor and activating/deactivating them as needed as opposed to spawning and destroying them.