[Performance] Getter/Setter vs static

[adi4x]

I'm staring to make an AS3 game. I want to know something about performance. Here is my (theoretical) case.

Classes
Main.as Hero.as Ghost.as

The game action is simple: the Ghost must chase the Hero (and has to know its X Y position).

1. How to send the Hero X Y position to the Ghost(s) ?

1. Using getter/setter
2. Using static var - this seems easier

2. How many enterFrames events to use
Instead of making classes with their own enterFrame events maybe i should keep one class Game.as and search for collisions using a loop
Or maybe I should use one single Timer event ?

[TOdorus]

I think you can save yourself some trouble by using composition.

Each game object consists of a few subobjects. The ghosts and player could have different controller objects. The ghosts have an AI, the player the keyboard input. This makes it easier to make variations between ghosts in AI and handling (defined in another object).

If there only is one here I would use a static variable. Much more efficient.

The less events you have the better (performance wise). This also makes the game engine less complex. Accounting for events happening async is hard enough in applications, in games it'll be almost impossible.

[adi4x]

I was hoping to hear that static vars are OK to use since I really like them because are making the class communication very easy in both ways.

Most probably getters and setters are ok to use when you need unilateral communication. Still there are a lot of topics saying that getters and setters are evil

[YBAB]

I think you can save yourself some trouble by using composition.

Each game object consists of a few subobjects. The ghosts and player could have different controller objects. The ghosts have an AI, the player the keyboard input. This makes it easier to make variations between ghosts in AI and handling (defined in another object).

If there only is one here I would use a static variable. Much more efficient.

The less events you have the better (performance wise). This also makes the game engine less complex. Accounting for events happening async is hard enough in applications, in games it'll be almost impossible.

what is async? and what the hell is getter vs setter?

I was hoping to hear that static vars are OK to use since I really like them because are making the class communication very easy in both ways.

shouldn't you define any variables you need for class communication globally and use them to control logic?

like get the variable/set the variable? ie: if you have a listener that looks for changes in the players state for animations or adjustments in physics, you declare a var of playerState:String = new String (); or some crap and then lets say you have the input from the player, so you change the playerState to i dont know "run" or "landrun" and have functions that set properties because that variable holds a certain value...like playerMove("landrun") and/or gamePhyics("landrun"). and then sometimes you need a second var to kick yourself out of what ever conditional loops you have, or to restrict sections of script from running unless conditions all substantial are met (i figure this helps with render time)...

or am i completely off topic and doing this wrong/non-efficient.

[TOdorus]

I was hoping to hear that static vars are OK to use since I really like them because are making the class communication very easy in both ways.

I would make the hero a static variable. This isn't necessary for your game, but the upside is that you only would use one class for both the player and the ghosts. Both the player and the ghosts can be instances of the same class, and this class has an x and y property. You feed the ghost a target agent (the player in this case, but you're flexible enough to select another ghost as target as well), and it pulls the x and y out of the instance.

Your situation is really simple so a static x and y for a unique player class can work as well, but I'm saying this so you can use this project to learn to prepare for more complex situations.

Most probably getters and setters are ok to use when you need unilateral communication. Still there are a lot of topics saying that getters and setters are evil

Getters and setters are good. They have a pretty bad performance though. So when to use them? If this was Java, I'd say always as you'll pay for it later by having to rename properties to getter functions. In AS3 you can define a getter and setter and they are approached as a property. You wouldn't know if SomeClass.somePropery has a getter or not, you just get a result.

Now when to use them? If you're not sure that a property needs to be set by another class/instance, create a getter. If you need special functionality on a getter or setter, you should also create getters and/or setters. This helps to keep your code clean, but can be a bit of a fuzz at times.

This is because it is good coding practice to code defensively. A class should only expose functions and properties to other classes that are necessary. This isn't really an issue in a simple situation, but if your engine grows more complex, you probably won't remember that it is a really bad idea to set a variable from another class or that a function should be called from outside the class. It's all about organization. Look up more on Interfaces to get an idea on how this is used in complex applications.

If you do run into performance obstacles because of this, THEN you replace the getters/setters that can be replaced by a public variable. "Premature optimization is the root of all evil"

what is async? and what the hell is getter vs setter?

Asynchronous: you don't know when an event is going to happen. The most important aspect of this, is that you don't know what event is going to happen first. In games it may be important for the physics part, that things occur in a certain order. You can't really calculate all the movement for one part and then the other, for example. AI on the other hand, can run out of sync perfectly well. Say you give an AI the current situation. Now it takes five game cycles for the AI to have processed it's reaction and it responds. In the meantime things have changed, but this can be considered as a very human reaction time.

Also events are pretty cpu intensive compared to having one event which triggers a for loop.

shouldn't you define any variables you need for class communication globally and use them to control logic?.

As I've made clear in my rant on defensive programming: yes.

[YBAB]

ha ok, at least im not clueless then... i thought i was for a second.

[ImprisonedPride]

"Globals" are generally frowned upon in clean-code practice. Here's a Constants class I'm using for a current project that might help you:

	import flash.utils.Dictionary;
	
	public class Constants extends Dictionary {		
		
		public static function put(key:*, value:*):void { Constants[key] = value; }		
		public static function get(key:*):* { return Constants[key]; }		
		public static function getOnce(key:*):* { var o:* = Constants[key]; remove(key); return o; };		
		public static function remove(key:*):void { delete Constants[key]; }		
		public static function has(key:*):Boolean { return key in Constants; }
			
	}

Implementation:

import path.to.class.called.Constants;

Constants.put("some identifier", someObject);
if (Constants.has("some identifier")) {
	Constants.get("some identifier").doStuff();
	Constants.getOnce("some identifier").goodbye(); // or Constants.remove("some identifier");
}

Note that typically, the Dictionary interface is pretty slow, but it's the next best thing to hand-rolling your own hashmaps.

[Squize]

I'm not a fan of using Static's, or public vars.

I only ever use static vars for a config file, so I can turn debug flags on and off quickly, things like that. And I only ever hit up public vars in a class if it's near the deadline and I'm struggling

( In saying that I very rarely use actual getter/setters, I just have a public method that returns the value. I just find it easier to read, as I use composition over inheritance, so I'm not used to just being able to hit vars up directly like you would with a getter. Just one of my many weird coding hang-ups ).

Squize.

[truimagz]

Edit : Nvm