Hi everyone. I would like to ask some advice with regards to scripting habit in C#.

I am currently reading Introduction to Game Design, Prototyping, and Development by Jeremy Gibson. Still practicing my scripting. I am trying to keep a good habit since I am still learning.

So anyway I seems to thought be able to find out through scripting, I find myself too "naggy" or "redundant" in my codes. Does it even make sense? lol. Anyway here is an example.

Both codes achieve the same result BUT, one of them is shorter.

Vector2 FindCoordinates (){
		Vector2 currentCoordinates = CalculateMouseClickToWorldUnit ();
		float currentX = currentCoordinates.x;
		float currentY = currentCoordinates.y;

		Vector2 roundOffCoordinates = new Vector2 (Mathf.RoundToInt(currentX), Mathf.RoundToInt(currentY));

		return roundOffCoordinates;
		
	}

2nd one.

Vector2 FindCoordinates (Vector2 rawWorldPos){
		float newX = Mathf.RoundToInt(rawWorldPos.x);
		float newY = Mathf.RoundToInt(rawWorldPos.y);
		return new Vector2 (rawWorldPos.x, rawWorldPos.y);}

My question is,

Does it matter? Does long lines of codes decrease performance of a game?

I will be pursuing to build a 3D game after I build up my skill but what are the other ways to maintain a good habit in scripting games?

Thank you all.

The second one has a typo :)

Other than the typo, I like the second one better. It doesn't really affect performance, it's just nicer to read.


For more complicated code, it is sometimes good to write functions like the first one. The variable names you use for your intermediate calculations can make it easier for someone to understand your code.

They both look fine to me, if what the thing is doing is clear then I don't see any other real concern. I wouldn't worry about lines of code other than it tends to make it harder to follow when you write more.

Most performance loss in programs is from doing things that take a lot of time(memory allocation/copying/loops that operate on large blocks of memory.)

Ops! Spotted the typo!

Thank you very much Nypyren and Satharis! :)

Most performance loss in programs is from doing things that take a lot of time(memory allocation/copying/loops that operate on large blocks of memory.)

Hi Satharis, could you explain further and show me an example what does it mean by "memory allocation/copying/loops that operate on large blocks of memory."?

Hi Satharis, could you explain further and show me an example what does it mean by "memory allocation/copying/loops that operate on large blocks of memory."?

It's hard to give concrete example of just random code that runs slowly, but I can break it down by subject more.

Memory allocation: For C# that's using new. Arguably this isn't as big an issue is it is in a language like C++ because they both handle allocating memory differently, generally it's much cheaper for memory to be handed out in C# due to the way the memory is tracked. However you could stick to a logical rule that you should hang on to objects you create with new until you are done using them, don't create dozens or hundreds of new objects in a function and continuously throw them out.

Copying: Specifically deep copies in a language like C#, which is copying all the values in one thing to another thing. Your CPU is essentially working in terms of numbers of operations, so doing less of something is usually better performance. For instance calling that rounding function may be just a copy of the one float value to a parameter and then a simple operation on it. That runs fast, in comparison you can imagine copying a giant object with an array of 100 variables in it would be much more expensive, you're doing n times more work than just copying one variable would be doing. That can be particularly bad if you end up copying many of these large objects without realizing it.

Loops: Loops are pretty much the main cause of performance loss, but that should be obvious because they are flat out running an algorithm many times over. You can imagine taking the square root of 20k numbers would be pretty slow compared to you rounding two floats. Games tend to be doing a rather insane amount of processing every frame, even just to build the information to render things intelligently.

Most of the time the rule is: don't worry about performance. At best you're guessing what runs fast, and in many circumstances what runs fast may not be what you think it is(something that is using more cycles can run faster because the cpu spends lots of time waiting for data to be pulled from RAM, as an example.) But you can be mindful of not doing extraneous work that you don't need to do. If you're writing a loop think about the amount of work it is doing and how you can simplify that.

Usually my motto is to worry about how something looks, how easy it is to read and understand, and worry about performance if it becomes an issue or you know the code you are writing is doing a lot of work.

I find myself too "naggy" or "redundant" in my codes. Does it even make sense?

It does. There is a trade-off between compact code (more code at a single screen), and clear explaining what code is doing. Within clear explaining (I consider that the more important one), there are many subtly different ways to achieve it.

There is no "one is good and all others are bad" here, there are a lot of good habits. They are different in their strong and weak points.

If you feel your code is too redundant, work on making it more compact. Likely, in some time you'll find your code is not redundant enough, and you work on that problem, adding a bit more redundancy, until you're happy with it again. It's a natural process, you're looking for the sweet spot in your code style, and your current style is not optimal, you found. Adapt, and try the new idea for a while to see if you like it. If not, change it again.

In my entire programming career, I have been tweaking my coding habits and style, it's still not done (likely never will be done), but the changes get smaller and less frequent.

Does long lines of codes decrease performance of a game?

Length of the line is not relevant at all. What is relevant, is what computations you perform. For example, doing a lot of small additions to a string in C# means you are creating a lot of intermediate strings that you immediately discard again. (Each "+" is performed separately, and you need the result of the previous addition exactly one time only.) That wastes time and space. In such a case you better use a StringBuilder, which is specifically designed for this case, it makes a lot less intermediate results.

See also https://msdn.microsoft.com/en-us/library/ms228504.aspx

The computer does what you tell it to do, so if you tell it to go to the other end of the street by going three miles in the opposite direction first, that's what it will do. Being clever in giving the computer directions what to do, is what counts. However, being clever is only needed in very few cases, all other cases (around 97+%) are irrelevant, the gain is too small to be worth the trouble.

In general, the best approach is to always write code that is as clear as possible, so you (or anyone else reading the code) can easily understand what happens. That solves your performance problem for about 97% (Cpu cycles are cheap, making the code easy to understand means you can work more efficient).

For the remaining 3%, you either don't care (You stop optimizing as it's "fast enough"), or you do care, but in that case, you cannot predict why it's slow (When I have such a problem, I always take a guess what is the problem, then I go and find out for real by profiling. My guess is always wrong, it is often something simple and stupid, you'd never consider to be a performance problem.)

As you cannot predict where a performance problem is going to appear, the quickest way to deal with it, is wait until you found you have such a problem, and then fix it.

what are the other ways to maintain a good habit in scripting games?

You're doing that already. Don't blindly stick with a habit, keep an eye on how you're doing, and at what areas you might be able to improve. If you find one, make that step, and improve.

Worst case, your idea was less good than you thought it would be. In that case, you can always revert back to the previous habit.

I don't consider reverting an idea as a failure. By trying, you have discovered why it doesn't work, which is useful knowledge that you gained for the future.

Thank you so much for the detailed explanation Satharis and Alberth.

It really helps me understand more!

Thank you!