TorqueBASIC: A Scripting Language

#101 LabRat,

Check your email when you get a chance. :)

#102 Why argue?

Those of you who don't want to do a BASIC implementation can go on your way and forget about this until it matures into something that effects you (if ever). Those of you who do want TorqueBasic would be better served getting started (get organized first) rather than spending your time and energy defending your position.

#103 I'd recommend Blitzbasic over darkbasic, it's more of a C/Basic hybrid and has had a lot more published games that Darkbasic, and a more popular syntax amongst experienced programmers that use it more for its shortcuts or prototyping. The entity system is particularly nice and what in my opinion makes it more versatile then darkbasic.

I think the main reason DB isn't as successfull is that it doesn't have the stability from one build to the next to make it a viable platform, and the language and syntax isn't as elegant despite it having more buzzword graphical features.

I'm a bit of a newbie to programming myself and what I noticed from code pasted earlier is that there is an overuse of strings whereas something like basic will allow you to simply type in coordinates for simple transforms of cameras/lights, entities, textures etc, as well as define strings, and create functions for more complex operations.

Since my interest is almost exclusively game art and design and would normaly build most functions like AI and path finding in a 3d app I'm probably not the person that you guys are trying to target, but having a simpler alternative for the most basic tasks seems a good idea to me. My first taste of programming in basic was 20 years ago in BBC basic, I think a basic as simplistic as that, relying on goto with numbered lines would be a mistake. And that seems to be the general interpretation of what basic is for those that havent looked into how things have developed outside of C++

#104 Guys,

This thread, while interesting, has turned into a giant debate, discussion and argument over apples and gasoline. Discussing the merits of one BASIC over another doesn't get anyone any closer to the end goal here. I would suggest that whomever is interested in making this a reality to get together and do it.

Something like:
1. Get a team together of people who are truely interesting in doing this and producing results
2. Put together the problem statement (How to build a BASIC langugage interface for Torque, or whatever it is)
3. Put together a brief plan of how you're going to attack the problem
4. Start producing and get the basic implementation done to show progress (like a simple TorqueBASIC script that just gets a splash screen going would be a good start, 1 TorqueBASIC script and the TorqueDEMO.EXE)

#105 @Bil,

Sounds like far too much work :)

How about this instead:

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6083

T.

#106 If you're determined to go ahead with this, might I suggest that you change the file extension you're currently using (.bas) to something that will not clash with syntax highlighters and/or file association for other BASIC dialects.

.bs or .tbs would be more logical choices. Although both are already used by other programs according to FILExt, they don't clash with anything related to BASIC.

#107 Whilst I agree with most people here saying that sticking with the current c style of torquescript is better for people to learn, not everyone who might dabble with script files wants to be a programmer. Some just want to make modifications to the game or small mods for it. Being able to do this in torqueBasic would allow many more people to dabble in this way with whatever limited programming knowledge they may have. I can only see it as a benefit adding usability.

As for the .bs suggestion, is that a subtle dig or a serious suggestion!?

-Z-

#108 Z,

Totally agreed. May even finally be able to convince N to do some of my work for me >:)

T.

#109 An idea about the file extension. Could all languages use the same extension and then have a directive at the top of the file that says what language the file is in. So you create a new file extension like .ts or .tscript for "Torque Script" and then the engine defaults all files to be TorqueScript by default. If you want to write in Torque Basic you would then have a @Language=TorqueBasic at the top of the file.

This way I won't get the .cs clash with c# files, which would be nice.

Mike

#110 There is already a fallback to .cs so with TorqueBASIC anything that's not handled explicitly by a parser is treated as TorqueScript.

Also, you can do that with stock TGE. Just rename the .cs files to something else and exec them ... it will still work. To change the top level main.cs would mean a small engine change (its easy to find) but no biggy. That's how the GUI system works (e.g. .gui files are just .cs files renamed).

So specifying the language in the file itself would not really gain anything, but it's possible. There are some possibilities on that front in another area that someone suggested to me privately earlier, but I'm not going to go into that now.

T.

#111 -Z-: The .bs suggestion was serious, though I could see where it might not be taken so, which I why I suggested another alternative.

.cs is the extension for "Console Scripts", though it could also apply to "C-style Scripts" or just "C Style".

.bs could mean "BASIC Scripts", "BASIC-style Scripts" or "BASIC Scripts".

.tbs could mean the same things with "Torque" at the beginning.


Mike Jarosch: Whilst it might be possible to modify Torque so that it could tell the difference between file types using a doctype declaration as you suggest, the main problem is with other programs or the O/S not knowing the difference.

You're unlikely to place C# files in a Torque directory, so it doesn't really need to check. The problem is with code editors using the wrong syntax highlighter/checker or operating systems trying to open console scripts with the wrong program.

Sticking to the reasonably safe 3 letter limit for file extensions means there are bound to be clashes, as there are many thousands of different file types out there.

#112 BASIC scripts can never be *.BS. They must always be *.BAS. ;)

#113 Could be .tqb (Torque Basic) AFAIK, it's not used much. ;)

#114

Quote:Could be .tqb (Torque Basic) AFAIK, it's not used much. ;)

Agreed.

#115 TorqueBasic Compiler/Interpreter in the works. Being written in torquescript.

#116 In my opinion this is the problem with torque and making games with torque if
you want new people and every one in general to have an easier time making
games then you need to cut down on the steps required to get something done.

Programmers

To be a TGE programmer you have to have the source, the source requires
a compiler.

Source, Compiler (find a free one or buy one), Compiler Setup, Compile the Code,
Exe is created unless you have problems, Fix Problems, and Compile again.

At each given step you lose people.

For every few people that buy the torque source, actually have the compiler needed
to compile it, and every few people that have a compiler actually know how to use it
to set it up properly to compile torque, and every few that have problems can actually fix them
to compile the exe. ect ect ect

The process is like this for almost every single type of job/group for TGE development and some could be really bad depending
and rely on other people.

Im opinion Torque Script is fine as is.
I dont see basic being robust enough to do what is actually needed
torque script is easy like basic but robust enough to get everything done
and more.

Script Editing inside the torque engine is a main thing I would work on first.
That itself could be a major learning tool.

Imagine opening up show tool, loading the model, opening a script window
and learning how to play animations and do whatever right inside the engine.

I dont know im just babbeling and some of the items above are apart of game development
you have to live with.

It sure would be easier if we didnt have to leave the engine so much though.

(hooray for noticing the really old date)

#117 I am sorry but i don't agree with you. When i purchased torque i havent a clue about C++,Compiling C++,Torque Script
Milkshape,modeling...etc etc etc. My only experience was with 3DGame studio (which is way more complicated, and way more expensive)

With Getting started documentation (if one takes some time and read it) I was able to start a few hours after CVS-download.
I am getting grip of torque script 8 months after purchase (I have very little free time). Hell I am working in VB for 6 years now and I am still learning,
altough had write a lot of applications. So what I want to say is: You will get back exactly what you put into it.
Don't get me wrong, I would like to see a VB like script, but it wouldnt work very well (there is too many IF-s and GOTO-s).

#118 Im not saying torque is over complex or anything.
Im just saying some of the processes we go through to
make games with torque could be easier and scripting is one of them.

Editing Scripts and Debugging from within the game
would be pretty nice.

Hopefully I can put some of the ideas in motion real soon.
I just need to do some dirty work first like some new torque GUI controls
to help push the in game script editor.

#119 I for one think this is a great idea.
Sounds Good!!!!!









Bob

#120 The more different languages Torque can support the merrier.

Good luck Frankie!