LUA Thoughts

[MichaelSch]

Alright guys... Just a worthless post really, but I just need to say that when I first got into Leadwerks, I came in with a huge dislike towards LUA. I bought the version with C++ support to avoid LUA, but I am messing with it just because of the greatness of public variables, and I have to say, now that I get how to use it, its fairly damn nice! Good work, loving the engine, and LUA now

-Michael S

 

EDIT: The ONE thing I don't like about LUA right now is the comments.. I want to use my // lol

[Rick]

public variables? what do you mean with this? you mean globals? those are bad things and shouldn't be used.

[nick.ace]

public variables? what do you mean with this? you mean globals? those are bad things and shouldn't be used.

 

I've heard this a bunch, but why shouldn't they be used? The only reason I can think of is ambiguity of global and local variables with the same names, but other than that, I can't think of a reason why they are bad.

[Haydenmango]

I use globals and my game works fine. There are some things that globals are actually useful for.

For example I can make my main player a global labeled player then every time I need to access my main player I can easily use the global.

 

The only reason I can think of is ambiguity of global and local variables with the same names, but other than that, I can't think of a reason why they are bad.

 

Yeah this is the main thing you need to look out for when using globals. You probably shouldn't create to many globals because you will have to keep track of them all but using a couple globals isn't a big deal. One other thing I ran into was when changing my map I have to reset most of my global values (especially if the global is equal to an entity) otherwise the global value will point to something that doesn't exist which will crash your game.

[Josh]

Globals are fine. The three reasons people object to them:

1. To satisfy some obscure programming principle that has nothing to do with making working products.
   
2. To allow expandability beyond what you will ever actually use, just because you are afraid of committing to an idea and have too much time on your hands. "OMG, maybe I will want to run two instances of my program in one EXE! BWAHAHAHA!!!"
   
3. The static initialization order fiasco. This is actually really bad, but it only applies to C++ classes.
   

 

But as Haydenmango points out, I would only use a global when you need it.

[Rick]

I've heard this a bunch, but why shouldn't they be used? The only reason I can think of is ambiguity of global and local variables with the same names, but other than that, I can't think of a reason why they are bad.

 

Then I'd say you probably haven't written more than, say, 50k lines of code yet in a single project (which is small for most any game). Think of how many systems a game needs. Think of maintaining those systems that you haven't gone into for a few months. If you have more than a handful of globals in your game it's going to be a nightmare to manage those for you, and for sure for someone else. It's best to isolate each of your systems in your game and just pass variables around. Is it really that hard to pass a "player" object to functions that need it? This way each system is on it's own and doesn't have their outside reliance on certain things. This also means you can easily reuse these systems without modification. How many people here actually finish a game? Not many. How many people here start many different games? A lot. Reusing systems that are 100% isolated helps speed all that up.

 

I had a bunch of other stuff here to respond to Josh and Hay but I don't want to start a war. I'm trying to give advice from my 13 years of working as a software developer has provided. Globals are a dangerous path that isn't even needed once you understand how to design systems. Programming isn't just about putting code in an editor. Programming is about design and you will NOT be wasting your time by reading up on some design patterns.

[Thirsty Panther]

 

 

 

I had a bunch of other stuff here to respond to Josh and Hay but I don't want to start a war. I'm trying to give advice from my 13 years of working as a software developer has provided. Globals are a dangerous path that isn't even needed once you understand how to design systems. Programming isn't just about putting code in an editor. Programming is about design and you will NOT be wasting your time by reading up on some design patterns.

 

Hi Rick do you have some recommended books or websites for programming design ?

[Josh]

@Rick you work on enterprise softwar, right?. How many people are contributing code to the products you work on? Less than 100 even? In that situation, what you describe makes sense.

 

If you need to just get products out the door, I favor a more pragmatic approach. Too many programmers have all these imaginary constraints on how they should work.

 

The person who plays your game will never, ever, ever care about the "quality" of your code. They just want to kill demons with a shotgun.

[nick.ace]

I didn't mean to offend or anything, sorry if I came in off that way. I have worked projects, in industry as well as in college, of various sizes including huge programs before not in a game dev setting. And I've been programming for 8-9 years with many different languages and such.

 

Anyway, there are certainly applications that would benefit from more local variables, but global variables also have the advantage of being centralized in one file/location. I absolutely hate when values are passed in through half a dozen classes before being usable, it becomes unwieldy at times. Maybe you like that due to the scalability, but a lot of games don't feature simplistic UI driven interactions. Also, there is a bit of overhead with passing variables that global variables eliminate.

 

Of course, there are situations where global variables can cause issues such as with threading, but as long as you don't just instantiate globals throughout your code, global variables can actually be a good thing because they can be easier to track.

[Rick]

Maybe you like that due to the scalability, but a lot of games don't feature simplistic UI driven interactions. Also, there is a bit of overhead with passing variables that global variables eliminate.

 

It's less about scalability and more about readability and maintenance. I'm not offended as it's anyones nightmare to manage if they wish to go that route . I'm just trying to help. Post the global benefits over at gamedev.net and you will hear an earful from everyone over there and for good reason. They are more passionate about it than I. At the end of the day it's referred to as lazy programming because 99% of the time you just didn't spend the time to think about the system you are designing to know how things need to interact. Like anything else the more your practice design the better you get at it.

 

The person who plays your game will never, ever, ever care about the "quality" of your code. They just want to kill demons with a shotgun.

 

It's not about that though Josh. It's about you being able to easily maintain that code later. Globals make that harder.

 

If you need to just get products out the door

 

Every software company needs to just get products out the door. It's how they make their money. MS is no different than you in that respect. These practices are followed for very valid reasons though even with needing to get product out the door. Namely because it's not that hard with practice to see that you don't need globals. The risk far outweighs the benefits.

 

I mean having a global player variable I get, it's still not needed, but I get why a person would do that, but it's a slippery slope.

 

Merry Christmas and Happy Holidays