Lennaerts performance tips

Stats

1,125 visits, 2,156 views

Translations

This tutorial hasn't been translated.

Tools

Recently been going through code, trying to find methods to improve and actually came up with some simpe things.

1. Approach

Check how you approach your game mechanics.

A very simple example:

instead of updating the score text every tick, you can update it after a bullet hit.

This reduces an event 60 times per second to only when its actually needed.

Also, Its not always you require something to happen 60 times per second, I am a great fan of using things like every 0.1 second, thats like 5/6 load reduction on that event.

The same goes for all other on screen related information your trying to update, like here with bullets fired:

2. Objects

By defauly I now use an extra layout to stuff all my objects in which are not yet needed on the layouts. when I need it, I spawn them. They appear quick, and values become persisitent and objects are no longer outside of any layout, reducing/removing flickering on various fronts.

3. Know your events

There are quite a few events in CS2, some perform every tick. Keep this in mind when you perform actions, as actions related to an event that runs 60 ticks a second, also performs your actions at 60 ticks per second.

This spawns 60 bullets per second, with a bullet it would notice. but if you would spawn an object, or created at a certain point, you wouldnt notice it.

4. Sizes

This goes for near everything in CS2, the bigger something is, the more heavier it will work on you processing/rendering.

This especiallly counts towards the project view size.

Having something at 1900x1600 looks great on big screen ... but all those pixels become futile when rendered on a mobile phone.

5. Banners

One of the greatest laggers in my games are the loading and fetching of banners.

Implement these smart, like not loading a banner mid game play, but during a menu, or at the end of a level.

6. Behaviours on objects

If you have an object hiding out of sight, waiting for a moment to come into play, it is not needed to have (for example) physics enabled on them. Enable them when they are needed.

7. Disable game elements with groups

I use groups to have parts of my game working or temporarily disabled when not needed to save processing.

Like, if you enter the menu system, it iss not needed to have units run up and down, or that your player is able to move etc. this also goes vice versa, you do not need aworking menu while you are in game. Disable the listeners.

Also, if you apply groups, your code will look neat in a nice overview where you can easily find back game elements.

this is an example from a game of mine, (work in progress atm) You can see the subdivision I made for controls. below my controls are player and menu (controls).

At level start my player is disabled.

At main menu start, my game over menu is disabled.

This way I dont have to add the condition that something needs to be visible if I accidently clicked it because its at some hidden layer.

8. Event triggers

The more event riggers you have, the more active event listeners are running. Approach your needs smart.

If you have a on screen keyboard, there is no need to listen to if either of the alphabetletters is being pressed, stick them in a spawned item and give the items variable names which reference their value and simply use one event trigger with the spawned item; which also checks the variable.

The more event triggers you have listening waiting for game changes, the heavier your cpu is working every tick in order to catch the changes.

9. Sub events

With the use of sub events, you can tie a lot of events together, this is especially helpfull if you have a single event needing to do several things.

You do not need 4 listeners indicating a certain key is pressed, by means of simple sub events you can have all the needed action placed under 1 event with a couple of sub events.

I use the player control here not only to move rotate angle, but also to set some background effects in effect. Which could also have been called by something running on tick, also detecting when the button is down. Now there is only one listener.

10. when in doubt, ask

If you have designed something, and it is not working as you expect it, ask on the forums. Many a time someone will bite into a certain approach and will not let go of that approach, causing huge time development issues. Ask around, many other people will try and help you find a better approach.

Lennaert

  • 0 Comments

  • Order by
Want to leave a comment? Login or Register an account!