By definition, I don''t think you''ll ever find a programming language for non-programmers. What you might find is a language that is designed to be quickly learned by people with no experience. I think Python might fit the bill, especially if you provide a good interface - which means "don''t just map your C++ functions into Python functions and hope for the best". Also the provision of several heavily-commented examples will help ''non-programmers'' see what can be achieved quite quickly.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

quote: Original post by OctDev
Basically, waht I was getting at was whether to use a well established albeit generic scripting language, or whether to write my own specific yet funtionally limited scripting language. A scripiting language written specifically for the game would be simpler, and would be geared more towards allowing the non-programmers to make uncompiled changes easily.

And would be a non-migratory skill. As much as possible, use tools and techniques that can be transferred to other projects, other groups and other establishments. That way, people working with you are also acquiring broadly useful skills.

Oluseyi: From what I've seen of the WarCraft 3 community, the people trying to create scritps don't have any kind of programming knowledge at all, so I don't have to worry about 'bad habbits' =-) I'll probably create a GUI something like ActionScript for Flash (not the advanced mode), where it autoformats everything to make it nice and readable and has all the functions in a nice categorized list to make finding them easy. I might go so far as to create a GUI like the world editor of warcraft 3 where you pick functions from a dropdown and each argument is a 'hyerperlink' that lets you pick what goes in that blank, but I'm not sure how to make it easy to use (the one for WC3 is only easy to use for simple statements, because there is no way to quickly copy only portions of a statement, so if you need to create a formula ((((X+5)*3)/Y)+7) (which is how it ends up looking because it puts parens around each op), it takes 9 clicks for each place you need it (plus picking the variables from a list and typing in the numbers) and you must recreate it each time you need it (though if its just being stored in a variable, you can copy that entire action).

[edited by - Extrarius on March 21, 2003 8:43:28 AM]

quote: Original post by Kylotan
I think Python might fit the bill, especially if you provide a good interface.

I think that is the route I am gearing the future towards.



The Tyr project is here.

quote: Original post by Oluseyi
And would be a non-migratory skill. As much as possible, use tools and techniques that can be transferred to other projects, other groups and other establishments. That way, people working with you are also acquiring broadly useful skills.

Keep in mind that I am haven''t used Python, and am going off of the seeming consensus of above posts...

I agree and disagree . It is great to learn new skills and be able to apply them outside of your current project. However, I don''t think it is a great idea in this case. The focus is on allowing the artists/designers quick access to tweaking their work in game. It is not on teaching those same people how to program, or how to program while interacting with whatever engine the programming team is developing. It would be much better for a programmer to develop a simple interface that allows the artists to accomplish specifc tasks. Time and money are better spent letting the artists focus on art.

You could also argue that you are establishing a migratory skill for your script engine implementing programmer, rather than attemtping to establish a migratory progamming skill for your artists.

I also assume it would probably take 1/10 the time (by the end of the project) for 1 programmer to implement the needed systems than it would take to train the artist and then later drop eveything to help them when they are stuck. I would say that this is roughly per artist as well, so multiple artists is going to add to this alot. While it is always good to invest in your employees/team members, this becomes ridiculous. It is also unlikely that you will have the same artist 10 projects from now, so there is no payoff.

So it seems to be a non-benefit to train the artists any more than is necessary, concerning programming. Now, if it was a modeling technique, or something to do with their specific profession, I would wholly agree.

It isn''t the facilities available, but rather then facilities the user is required to use. As a general rule the users would only create new types of objects because A) you failed to do it for them; and B) you integrated scripting in such a manner that requires them to write large complex scripts. If all they need is a couple of if statements and a couple of function calls why would they use the full facilities and capabilities of python? You are right to not want to impose a burden upon the user, but you do that by insuring they can write small scripts to accomplish the vast majority of tasks they are likely to need to perform.

I just thought I''d note that the latest boost has just been released and Spirit is now a part of it.

quote: Spirit is an object-oriented recursive-descent parser generator framework implemented using template meta-programming techniques. Expression templates allow us to approximate the syntax of Extended Backus-Normal Form (EBNF) completely in C++.

Spirit is an awesome library, but it depends on partial template specialization which VC7- don't support =-(

[edited by - Extrarius on March 21, 2003 12:46:47 AM]

quote: VC7- don't support

there are always free alternatives, or you can upgrade when vc7.1 comes out.

[edited by - petewood on March 21, 2003 8:03:31 PM]

I've tried bloodshed (have to use it at school in one of my classes), and it was really buggy. If you put a block comment in a member function, it would cause an error and abort compilation. The IDE also feels messy, and so far I like .Net except for the lack of partial template specialization.

[edited by - Extrarius on March 21, 2003 12:46:38 AM]