Strictly Project-Based LUA training? Written and/or Video

[Wolfsong]

Hello all,

 

So I've hopped into trying to learn Lua scripting a few times now, watching videos, reading documentation and even having a Skype-based tutorial with Rick from the forums here. Videos and Documentation are either super-specific, or too generalized and lack context. Training with Rick is great and he's explained a lot of things to me. However, I find that I like to have a way to sorta "rewind" or "read back" through something if I'm not certain how it works, or what to do, etc. A real-time tutorial is great, but it lacks that "rewind/read-back" option - I doubt Rick wants to be available at any/all times to recap or repeat something we've discussed in a previous lesson .

 

I've read through the Lua documentation here and find that, while I'm able to absorb the earlier sections just fine, from the bit about "Tables" and on, I'm losing the plot lol.

 

I think how I would learn best, is to have tutorials that are specifically project-based, preferably staring off basic, and building from there. I'd like to be able to rewind, or read-back through bits that don't click with me the first (or 2nd or 3rd or...) time, so I can re-read, or maybe re-do that part, 'til it sinks in. Most importantly I feel like the ability to do so at my own pace is really important, which is why I'd prefer written or video. Preferably written.

 

In the Googling I've done, I can't seem to find anything that really fills that niche. I've checked Udemy and, interestingly, couldn't find anything based on Lua (possible opportunity there for any would-be instructors).

 

I feel like Lua is something I can wrap my head around, but I feel like I need the training to be very organized and deliberate in its delivery and progression, as well as being specifically project-based. Not just "here's code that does a thing, and here's how you write it.. now on to the next topic..."

 

Anyway, if someone has come across training like that, and can maybe point me in that direction, that would be awesome.

 

Thanks!

[Thirsty Panther]

So if I understand you correctly you want a video tutorial that takes you thru the making of a game from start to finish.

Have you tired the marble game tutorial.

http://www.leadwerks.com/werkspace/page/tutorials/_/marble-game-r21

 

Or Jorns Project Saturn.

You can also get the scripts used.

http://www.aggror.com/

 

There are other sources such as the Blogs here on Leadwerks (Tipforeveryone is doing a great series on FPS character controller).

There are also some others on Youtube but these tend to be shorter and on specific scripts.

[mdgunn]

Thirsty Panther's suggestions are good ones....

 

I'd also suggest a few other things:

1. keeping the thing you are trying to solve very simple and isolated. For example, create a test project where you experiment and build your knowledge, create a blank map for your specific problem of the time, solve that problem with cubes or whatever in the simplest way possible.
   
2. Consider creating your own project template where you copy in your own own scripts you've built up over time. Just copy the blank project in steam to a new location and give it a new name. Copy in various starting assets from FPS template. E.g. sounds, hud materials etc. So the FPS controller works (its needs various sounds etc). I then tend to create a sub-folder in the scripts folder with my initials on and put scripts in there so its VERY obvious where my own scripts are.
   
3. The example scripts (particularly the FPS controller and associated scripts - i.e. projectiles etc) are worth studying and tweaking.
   
4. The online help system has some useful simplified examples which are worth checking out and tweaking to build understanding.
   
5. Work shop items have some useful scripts with them. Beware though some may not be best practice (e.g. may process something when they should be doing a check and avoiding running code) but they often solve a focused problem. E.g. camera dolly, smoke mine, multi-level elevator etc.
   
6. I almost always start from an existing script. E.g. the switch one where some of the basics are in place that are hard to remember (e.g. syntax for script parameters, exposing a function to be called by the flow graph - if you use it).
   
7. System:Print is your friend (but your enemy if running in release code). If you're not sure what's going on System:Print the value and look in the console output. Long term you want a better strategy but for understanding problems it is quick and easy to put in place (and comment out).
   

 

In general lua is fairly simple at the level you will 99% of the time be using. I don't think there is too much you need to know.

Tables are one of the key features that make it a bit different to some other languages but I would not worry about knowing everything about them.

 

The important thing is that they are a container which can hold values, other tables or functions. Because you can have these 3 things in there this gives you a simple mechanism to construct a sort of 'object' where you can store values in slots, create lists of items in sub-tables and work on those values and lists with functions.

 

I think the confusion comes in the way the code needs to be written to talk to these things (e..g self.whatever Script:whatever) it's a bit odd but try to get through it. Leadwerks also has conventions for how it talk to lua (e.g. defining parameters and exposing functions to flow graph). These are not really LUA, just how leadwerks uses lua. Studying existing scripts is the best way to get comfortable with the conventions.

 

Suggest your focus on some things (in isolated test project) like:

- System:Print

- types such as booleans (checking a boolean condition before running chunks of code is a good practice).

- loops - useful but avoid doing many loops if you can (e.g. keep a reference to an object or thing so you can operate on it straight away) and if you have to loop exit out as soon as you have the answer see LUA loops.

- Knowing how to loop through a table (check out key/values/pairs)

- some built in table functions

- manipulate strings

- casting an object - So if you have a list of items you might need to cast it to the right thing so your code can access it properly (e.g. an entity etc.)

- Understand that all objects are global unless you declare local, so most of the time you SHOULD declare local in your objects. Global is usually bad as if something else creates something with the same name you have issues. It can be useful in games, where you work along and understand ALL the code, to have some limited globals though as on small amounts of code it can be a quick and easy solution.

 

OK this has got way bigger than I had thought it might. Better cut it short here.

 

Suggest that it might be good if you generate a bullet point list of all the things that you can think of regardless of whether they seem silly or not. It's probably impractical to think that you'll get answers to them all here but I'm kind of interested in what you might list.

 

I'd like to think I might do a tutorial or something to help you out, but it would probably take some time to do and I'm not sure I'll get round to it. If I do your list might be useful.

 

Personally I think you have a very valid point about there being a bit of a gap in how you actually sensibly progress on on non-trivial project. Anyway maybe if you do a list and maybe high-light a couple of things that might help most then we may be able to get you on the right track.

 

If you read all that and got this far....you have too much time (me too? - really need to get back to work)....you should be learning LUA in Leadwerks!

[mdgunn]

I understand Josh sees a need for better learning material too and the plan was to have more templates (and probably of a more in depth nature) at some point in the future. I don't believe there is time scale on this but I think it has been considered high priority by him in the past.

 

This would probably significantly close the gap that you (and many others) are experiencing. I hope there is some progress or announcement on this soon.

[Wolfsong]

So if I understand you correctly you want a video tutorial that takes you thru the making of a game from start to finish.

Have you tired the marble game tutorial.

http://www.leadwerks.com/werkspace/page/tutorials/_/marble-game-r21

 

Or Jorns Project Saturn.

You can also get the scripts used.

http://www.aggror.com/

 

There are other sources such as the Blogs here on Leadwerks (Tipforeveryone is doing a great series on FPS character controller).

There are also some others on Youtube but these tend to be shorter and on specific scripts.

 

I understand Josh sees a need for better learning material too and the plan was to have more templates (and probably of a more in depth nature) at some point in the future. I don't believe there is time scale on this but I think it has been considered high priority by him in the past.

 

This would probably significantly close the gap that you (and many others) are experiencing. I hope there is some progress or announcement on this soon.

 

 

I had glanced at the marble tutorial, in fact, and intended to give it a go. I just wasn't sure if it was something that really starts with absolute basics and builds up, or if it's tossing you in at the deep end, assuming you've grasped everything else up to that point (since it's the last in a series of Lua tutorials). It could end up confusing me more, rather than helping. Unfortunately, I lack the familiarity with Lua to know if that's the case or not. So, I've been looking for other sources that build a bit more slowly, over the course of a number of different, but increasingly complex projects.

 

I have a feeling that I'm somehow making this all complicated than it needs to be lol. I've tried learning other languages and always seem to hit the same wall, where as long as the concepts and related syntax are straight-forward enough, I'm fine. But then, at some point, the code starts to become less about straight forward numbers and words, and all these symbols are being mixed in, with nested parentheses and periods and colons and all this stuff going on without context or explanation - it becomes "just type "this" and "this" happens". At that point I'm completely lost. I guess there's something I'm expected to understand or grasp by that point for that stuff to make sense. For some reason I'm just not grasping it.

 

I've tried reading through an existing script, but it's the same problem I bump into. It makes sense as long as it's basic/simple stuff. But then it gets into crazier things, and I'm completely lost again. Further, sometimes even reading the documentation doesn't help, because even documentation will, after a point, assume understanding of previous concepts that I still won't understand.

 

It's really a mess lol.

 

It's why I'd like to find a series of tutorials that starts super simple, and builds over time, with each project building off previous projects so I'll have repeated, and better understand those earlier concepts by the time I start getting into the more complex stuff.

 

But again, maybe I'm just letting myself get all confuzzled by all the symbols and such going on. No idea why it's so difficult for me. I think it might be 'cause I tend to be a very visual thinker and will grasp complicated ideas through analogy many times. Programming is very much not visual, and seems to be quite literal in its application. So maybe that's the disconnect. I understand the concepts just fine. I can totally understand what the code is supposed to do, and what the end result should be. I just can't look at the code and understand how it's getting me to that result.

 

Anyway, thanks for the advice/feedback. I'll just keep chipping at it I guess lol.

[AggrorJorn]

A couple of tips

• The road to understanding programming is (for most people) long, frustrating and results are not always what you want them to be. Patience, trial and error, some more patience, watchting and reading tutorials are part of that.
  
• Programming can take a long time to grasp. I am not just talking about understanding syntax, that is in fact the 'easy' part. It is combining that syntax in to something useful and doing something creative with that syntax to perform tasks.
  
• In the beginning every next step in the game you want to make, no matter how small it may be, forms a challenge. This is what makes programming (or game development to be more specific) that dificult. There is no 1 road to do something. There are often many ways to get the same result and that makes things more confusing.
  
• Make the most basic game possible: a basic calculator game, bejeweled, minesweeper, tetris are on their own basic games but they give you a lot of practice on common problems.
  
• Changing scripts will get you only so far and is great for messing around. It sure helps when you want to see how certain 'tasks' are resolved by other, but getting your own logic/creation mindset is so much more useful When it comes to learning programming, start from scratch with your own scripts.
  
  • Make a new scripts that rotates an object
    
  • Make a new script produces a block every second
    
  • Make a new script that animates a model when you press space
    

  [*]Did I mention patience, trial and error?

Don't beat yourself up on where you are now. I used to be at that exact same spot many years ago, but in time things got better. progamming logic became more of automatic thing that runs in your brain in the background. Then you get a lot more creative with thinking up gameplay coding as well. It is not something that is learned in a matter of weeks unfortunately.

[Roland]

Couldn't say it better than Aggror, except even more patience, trial and error of course There are no shortcuts

[Wolfsong]

Hi all,

 

Thanks for the help/feedback!

 

I'll just forge ahead into it and figure this stuff out. It has to sink in sometime!

[Wolfsong]

TL;DR: Josh should write/sell a beginner's book on Lua programming. Even just an e-Book. I think he could do an excellent job of it, and make many people happy.

 

Long version:

To be clear: This post has nothing to do with Josh's tutorials here. His explanations are actually pretty clear and he does a better job of explaining things than almost anyone I've read/seen teaching programming in any form. For one, he uses analogies that can be understood by people unfamiliar with the subject matter, making it easier to grasp what he's explaining. It can't be overstated how helpful that is to someone who feels like they're staring at code from The Matrix. That's how tutorials for completely new users should be done, in my opinion. Josh, you should write a book on learning Lua for beginners. I'd pre-order it.

 

That said...

So here's a good example of why I find learning Lua (or any language) so impenetrable. Maybe other new users, or those who can remember back to when they were new can understand where I'm coming from.

 

Basically, I'm finding that - almost universally - people who write tutorials for programming, to be blunt, suck at it. They seem to have zero grasp of the concept that they're explaining things to complete beginners who do not yet have a grasp on all the terminology they throw around and take for granted. And so they launch into explanations using terminology and explanations that then need explanations, which then need explanations, ad infinitum. It becomes this ever-deepening rabbit hole of needless complexity and confusion - all over something that probably could have been explained perfectly clearly using common terms that new learners can understand, were someone more qualified to teach the concepts doing so (such as Josh).

 

I'm going through the Marble Tutorial and directly into the first part, I've hit something where I'm wondering "Well that's weird, why are those things different?"

 

Specifically this bit:

function Script:Start()
--Create a camera
self.camera = Camera:Create()
--Update the camera
self:UpdateCamera()
end

 

 

I'm looking at it, and wondering why is it self.camera in one case, but self:camera in the other? What's the difference between . and :? So, I go to Google. Several results later, I'm not quite sure I understand it, because the explanations launch into terminology that assumes previous knowledge of the language.

 

For example... This page

 

Now, the author of that article seems to understand they're relating this information to new Lua programmers. They specifically indicate that new users tend to be confused about the difference between the two. Perfect! They get it! This should totally clear it up. Wrong. Instead, I see paragraphs like this:

 

In the first example, string is the object and len is one of its methods (in this case, it gets the length of the string). The second example calls the Runtime object’s method addEventListener, along with some parameters/arguments.

 

Umm... What? Is that *really* how you explain something to someone new at Lua? So now I have to go looking up the definition of 'len' and 'methods' and 'string' and 'runtime' and possibly other things... just so I can, hopefully, understand the difference between . and :. Maybe I'm crazy, but if you're trying to explain new concepts to someone unfamiliar with the subject matter, referencing other potentially unfamiliar concepts to do so is probably not the best approach.

 

This is why I find most "newbie" programming tutorials to be counter-productive. The authors have no idea how to convey concepts to people who have little if any understanding of the subject. They write as though they're speaking to another programmer, and not someone completely new to it.

 

This is really more of a rant than anything, and I apologize for that. But if it inspires Josh to write a book on Lua for beginners, then it's worthwhile lol.

 

I just wanted to share an example of why I keep being put off of learning languages. I'm sure I'll "get it" if I just keep bashing my head against the wall, and keep Googling. But I just can't help but feel like that needn't be the case.

 

Or, maybe it's a sign I should just stick to graphics and stay away from programming.

[Rick]

It becomes this ever-deepening rabbit hole of needless complexity and confusion - all over something that probably could have been explained perfectly clearly using common terms that new learners can understand

 

I think you'll find that everyone has a different level that they like to go down to understand concepts. Some can just accept "that's how it is because that's how it is". Others need deeper levels to really get the concept. It's a unique experience for each person. That's what makes it so hard to do.

 

Your example is talking about tables. Tables in lua is the hardest part to understand because they are so flexible. The single most important thing to learn about with lua are tables and yes you'll probably have to bash your head with learning them for some time and even when you think you know everything about them you'll come across something you didn't know about them because they are so flexible and therefore can be used many different ways. They can be very simple if you use them that way but they can also be very complicated if you decide to use them that way too.

[Wolfsong]

Hey, Rick.

 

Thanks for the explanation.

 

I wish I was the type who was more "that's how it is because that's how it is". Sadly, I'm not. I've never been able to learn through pure memorization. I really need to understand why I'm doing what I'm doing. Why should I do it "this way" instead of "that way"?

 

So, while others likely just copy and paste, or type in the code in that example from the marble project, and move on. My brain sees an apparent discrepancy that isn't immediately obvious to me, and now "I need to know what's going on there". It becomes "Why is it . in one case, and : in another? It must be important in the context of the tutorial, so it's something I should understand and not just skim over it, or it'll come back to bite me in the rear later in some unrelated project". Until I'm satisfied that I understand that, my brain won't let me move on to the next thing. It's awful and I hate it, but well... That's why I like tutorials that start really simple and explain everything, leaving nothing un-explained, so you're building on knowledge as you go forward.

 

I hate my brain sometimes lol

[macklebee]

Its exactly the same thing in reality. The colon is for implementing methods that pass 'self' as the first parameter. So object:method( argument1, argument2 ) is the same as object.method(self, argument1, argument2 ) - where 'self' is the object.

 

I would suggest you spend more time on lua specific programming sites to learn more about the language. I use these two for reference:

 

http://pgl.yoyo.org/luai/i/_

 

http://www.lua.org/pil/contents.html

[Wolfsong]

Its exactly the same thing in reality. The colon is for implementing methods that pass 'self' as the first parameter. So object:method( argument1, argument2 ) is the same as object.method(self, argument1, argument2 ) - where 'self' is the object.

 

I would suggest you spend more time on lua specific programming sites to learn more about the language. I use these two for reference:

 

http://pgl.yoyo.org/luai/i/_

 

http://www.lua.org/pil/contents.html

 

Ah.. Thanks for the links. I'd checked the lua.org one, but really didn't like how they presented the info. I'll check the first link out, though.

 

Edit: Hmm... looks like that other link suffers the same problem of explaining one concept by throwing around terminology for a bunch of other, unfamiliar ones, which is what I was describing before.

 

Maybe I'll just try and find a good book on it lol.

 

Thanks!