Okay, so the preferred method of script embedding...?
Okay, so I''ve done a little bit more reading on script engines and embedding them in C++. My question to pose to you now is...
... are there any code examples out there of scripting languages like Lua or Python being used in a generic gaming engine? I can''t seem to find any... there''s an aweful lot of abstract-level discussion about Scripting in the forum and in other places online, but very few places it seems where the abstract is shown in practice. I''m curious about seeing how people implement the abstract concepts of scripting... as it stands, I''m pretty clear on what scripting is used for, but not how it gets to the point where it can do what it''s used for. =) =)
Anyone have good resources for this sort of thing?
-Vendal Thornheart=) Programming for a better tomorrow... well,for a better simulated tomorrow. ;)
Your subject and your actual questions are completely different. Threw me off a bit. Re the subject: there is no "preferred" method of embedding scripts, there is no established canon of architecture. Software engineering is really like a craft, particularly the variants employed in a competitive industry like game programming, and that means that new approaches to solving the same old problems are always welcome and will always be put forward. Experiment, Learn, Implement.
Non-commercial engines... Well, there aren''t many worth talking about. Developing an engine takes time, and it takes even more time when you don''t have a salary, a budget or a team of skilled programmers dedicated to the task day in and day out. QuakeC and UnrealScript notwithstanding, embedding scripting languages in engines and so forth is a fairly recent development and therefore a lot of non-commercial engines haven''t fully gotten a grasp of it, or would have to substantially revisit their architecture to provide that functionality.
Personal engine projects... They''re personal, which means there''s a high likelihood the code will never be made public, and they take even longer than non-commercial engines, in general. Also, they tend to be executed by persons who are learning (ie, most of us) and therefore involve a lot of experimentation. Hence the theorizing-without-application you speak of.
But I''m just being polite. Game programming involves a lot of initiative and DIY mentality. Stop wating for others to show you how they do it; go try it for yourself! This is the negative impact of the Internet''s boom in popularity - everybody wants to get "answers" online. Experiment, Learn, Implement.
quote: Original post by VThornheartThere really isn''t that much information about commercial engines because so few of them have public interfaces (for the most part, only FPSes do in order to enable mods). Consequently, a lot less is known about them aside their output capabilities.
... are there any code examples out there of scripting languages like Lua or Python being used in a generic gaming engine?
Non-commercial engines... Well, there aren''t many worth talking about. Developing an engine takes time, and it takes even more time when you don''t have a salary, a budget or a team of skilled programmers dedicated to the task day in and day out. QuakeC and UnrealScript notwithstanding, embedding scripting languages in engines and so forth is a fairly recent development and therefore a lot of non-commercial engines haven''t fully gotten a grasp of it, or would have to substantially revisit their architecture to provide that functionality.
Personal engine projects... They''re personal, which means there''s a high likelihood the code will never be made public, and they take even longer than non-commercial engines, in general. Also, they tend to be executed by persons who are learning (ie, most of us) and therefore involve a lot of experimentation. Hence the theorizing-without-application you speak of.
But I''m just being polite. Game programming involves a lot of initiative and DIY mentality. Stop wating for others to show you how they do it; go try it for yourself! This is the negative impact of the Internet''s boom in popularity - everybody wants to get "answers" online. Experiment, Learn, Implement.
Aye, that is true... I should simply experiment. I guess it''s just a fear of learning it the wrong way and ending up with a jumbled understanding of what''s going on, or rather what should be going on. I''ll have to see what I can do though, especially if there isn''t really an established "wrong way" to do it. =)
Maybe it''s just a personal idiosynchracy, but I often program in fear that how I''m programming it isn''t the way it should be done. Does anyone else ever experience this, or do I need to calm down and not worry as much? =)
Maybe it''s just a personal idiosynchracy, but I often program in fear that how I''m programming it isn''t the way it should be done. Does anyone else ever experience this, or do I need to calm down and not worry as much? =)
-Vendal Thornheart=) Programming for a better tomorrow... well,for a better simulated tomorrow. ;)
quote: Original post by VThornheartYes and yes. Did you know that Perl''s philosophy is "There''s More Than One Way To Do It" (TMTOWTDI)? Did you know that Python''s is to "make the simple things easy and the hard things possible"? More important than obsessing over doing it the "right" or "wrong" way is actually doing something!
Maybe it''s just a personal idiosynchracy, but I often program in fear that how I''m programming it isn''t the way it should be done. Does anyone else ever experience this, or do I need to calm down and not worry as much? =)
Furthermore, it''s easier to give you constructive criticism and advice when you''ve done something because it gives your understanding a concrete reference for your understanding.
Hmm... a good point, on all fronts! =) I''ll try my best to take your advice to heart. =) Thanks, I think I needed a bit of a kick in the butt to start doing something and stop analyzing it. If there''s one thing I do too much of, it''s question what I''m going to do before I do it. =) Most of the time I end up not doing it at all as a result... and as you point out, that''s not very productive. =)
-Vendal Thornheart=) Programming for a better tomorrow... well,for a better simulated tomorrow. ;)
Hey, Oluseyi, mind if I reuse your arguments? You''ve formulated them so well
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)
![](smile.gif)
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement