TGE 2.0 feature wishlist

#21 You're missing the point about scripting language support.

The preferred way to support them is to have a generic scripting interface, which can then accept modules for various languages.

So someone could use the TorqueScript module if they wanted, or the Python module, or the Lua/JavaScript/VBScript/etc module.

The point is to make the engine FLEXIBLE for people to do what they want. Not take away features like TorqueScript for those who like it, but to make it easy for those who don't to use what they DO like without shredding engine internals.

See the Nebula scripting interface if you want an example of what I'm talking about.

#22 I understand that, but the suggestions above don't mention a 'generic' scripting module. They mentioned replacing the current script language with Python, something entirely different then what you state.

The other issue with creating a 'generic' scripting plugin interface is that of dealing with code convert.

What I mean is, what will then become the official scripting language? After all, tutorial resources have to be submitted in some form. Will the current scripting language still remain the official standard for the engine? How will people then submit tutorials on how to do certain things in script? In both languages, one language, or the other language, or more? Is it up to the tutorial readers to convert code snippits to other languages themselves? And if the current scripting language is to remain the standard will then GG only accept tutorials using script in that form and reject others?

Just a few questions worth looking into I think.

#23

Quote:The two projects I was referring to are GORPE and ActionRPG.

Ahh, ok. I wasn't thinking of those as demos either, but I am looking forward to both with great anticipation :)

#24 Robert,

Replacing cs with Python or some other standard scripting is a win win for almost everyone. Why use a propritary language when you could use a standard one? Keeping cs around becuase it's easier is rather silly. By that logic why not drop C++ from the engine and use VB?

Look at it this way: Python/Perl/Lua are all prodcuts in and of themselves. Torque script is one small piece of a product and doesn't have near the engineering effort applied to it that the "real" languages do.

#25 Donovan: Why fix what isn't broken?

I'm not trying to be sarcastic, I honestly don't understand what benefits switching to python provides, apart from possibly using some other people's python libs that are floating around.

Even if I take as given that it's better to be on a standard language, why standardize on Python? I'd probably argue for Scheme or some other LISP variant as opposed to Python.

EDIT: Also, is Python even really a standard? Does it have a standards body overseeing it like C/Java/Scheme and so on have?

#26 I am just wondering. I don't know anything about Python other than it's a scripting language. What are the advantages over cs? I'm wondering because I have become very comfortable using the cs and would dread having to learn another language.(Not saying I wouldn't go and learn it. I would just probably bitch and moan until I learned :) )

#27 Agreeing with the above, furthermore, why take cs out of the equation? Why remove the end line users ability to decide for themselves?

I don't know Python, and quite frankly, if I were "forced" to learn to stay current with an engine that allready posseses a proven, and viable script language, well that would piss me off to no end.

Make it an optional thing, and I may experiment, but the choice will be there... BIG difference.

Killing cs altogether is a BAD idea (IMO).

#28 My only wishes:
1) fixed sound
2) bump-mapping

#29 Make it plugable and you can use whatever flipping scripting language you want. We really need to get out of the monolithic mindset here. The word "replace" does not exist. Try "swap".


(C: (More IP infringement, heh)

#30 Mark:

We're past that. There's still the question of what the official documentation and tutorials should use as 'the' Torque scripting language. I don't want to need to know 2 scripting languages just to read through the code snipits section.

#31 Back on topic....


Since my current usage is machinima, the enhancements I favor are anything that improves visual quality and realism.

-shaders
-facial animation and lipsync
-anything to improve indoor rendering, lighting and detailing

#32 My wishes:

1. better sound engine. I've been working on this here and there myself, so if you want community contributions, I'm willing :)

2. A nice DTS library to make writing exporters easier. Right now, the only full featured support is for 3DS Max which is way out of a lot of peoples price range (me).

3. More modular design, especially with the editors. I think its kinda cool that the editors can be run in the game, but sometimes it makes more sense to have a stand alone editor. Also, a more modular engine would hopefully make it easier to write 3rd party tools that can hook into the renderer for previews and other fun stuff.

#33 There is no reason why GG can't continue to use TorqueScript as the standard for documentation, just like they do today, if the scripting interface is modularized to natively support addition of different script modules.

At the same time, there's no reason why one couldn't post resources or snippets today that would depend on TGEPython or PyTorque, for example. Even though there's no python support in HEAD.

In the long run it comes down to who's doing the work for those resources and snippets, and what scripting language THEY want to use for it.

More choices are good. Locking out choices because one doesn't want to learn different options is silly. I don't have any burning desire to learn Lua, but I'd love to see a Lua module for TGE. More options will help broaden the community even faster. And that's better for everyone.

#34 Well I would think that the benefits of using a language that exists outside the context of a game engine would be apparent but I guess not so let's go over a few:

1) You can go to the store and buy a book on it right next to the C++ books (Note: NOT next to the scripting books but with the programming books).

2)You can make use of class libraries and the like written by a wide variety of folks.

3) You can take your game logic code and move it across engines/platforms since your not tied to a propritary scripting language.

4) The interface between the scripting language and the C++ backend is much cleaner and natural. This means you code is easier to understand and maintain.

5) It's the direction the rest of the industry is heading. More and more companies are either a) Switching to using open langauges for their scripting engines. or b) Complaining about how they couldn't accomplish task 'x' in their post mortems because of their propritary scripting language.

#35 Well I hate to sound like a jerk, or what have you, but I just have to play devil's advocate on this scripting issue.

I don't see any benefit of replacing the current script. I do however, see a benefit of modularizing the interface so that languages can, in effect, be plugged in.

With that said, my below arguement is directed towards the idea of replacing the current language with Python.

Torque Script has been around long before Torque and Tribes 2. It's roots go back 5+ years. The language is designed specifically for this engine, serving no other purpose then to drive the game rule logic. Python, on the other hand, is a general scripting language, designed for 'anything' and as such carries the overhead, inherit in its design, as such. Since Torque Script has such a tightly nit connection with the engine itself, it stands to reason that the security inherit in the scripting language's functionality would be far more capable to deal with unsecure code than Python would be.

Quote:
1) You can go to the store and buy a book on it right next to the C++ books (Note: NOT next to the scripting books but with the programming books).

As such, you can come right here and learn from the tutorials and various posts on how to script in the Torque Scripting Language. Furthormore, Python books bought in stores won't teach you how to rewrite the scripts currently in place in the engine, nor will it teach you Torque specific scripting related problems and solutions. Since Torque Scripting is such an intrigal part of the engine, when you learn how to script in TGE Script you also learn how to be productive in TGE right away, whereas in Python you would have to learn the language first, and then learn Torque specific solutions.

Quote:
2)You can make use of class libraries and the like written by a wide variety of folks.

The same applies to TGE Script. People submit resources everyday on how to do a specific thing in the TGE Script. And since these resources are immediatly applicable to the engine, there is no need to 'make it work' with the engine, unlike Python where these public class libraries may need adoption in order to work with the engine correctly.

Quote:
3) You can take your game logic code and move it across engines/platforms since your not tied to a propritary scripting language.

How is this any different with our 'propritary' TGE Script? I seem to be able to move my script game logic from windows to linux to mac just fine, try it, you'll see.

Quote:
4) The interface between the scripting language and the C++ backend is much cleaner and natural. This means you code is easier to understand and maintain.

I don't agree. TGE Script is a compiled language. When it is compiled it is enhanced to maintain the maximum in performance and the maximum in security, because it is built specifically for the engine, and as such, provides the cleanist backend you can get from script to code.

Quote:
5) It's the direction the rest of the industry is heading. More and more companies are either a) Switching to using open langauges for their scripting engines. or b) Complaining about how they couldn't accomplish task 'x' in their post mortems because of their propritary scripting language.

I don't agree once again. The game industry seems to be moving more to opening up their engines to modification, yes, but to open languages that aren't propritary, no. The latest example is Unreal Tournament 2K3, its scripting language is propritary, resembling Java. The only difference between it and TGE Script is TGE Script more closely resembles C/C++(a language more game programmers are already familiary with).

Honestly, to a new person with the Torque Engine, what would be easier to understand? TGE Script, or this:

class AIPlayer(SimObject):    def __init__(self,classname="AIPlayer",objectname="Anonymous"):        SimObject.__init__(self,classname,objectname)         self.registerObject(AIPlayer)

from tgenative import *
from tgepython.console.simobject import *        
class pyD20Player(AIPlayer):   
   def __init__(self,objectname="pyD20Player"):      
     AIPlayer.__init__(self,objectname)      
     db=self._tge      
     TGEExport(pyD20Player.onSpawn,objectname,"onSpawn","poot",2,2)      
     self.registerObject(pyD20Player)               

   def OnSpawn(self,args):      
     print  "Python OnSpawnCalled"            

   def Initialize():           
     pyD20Player()

#36 1. Open_gl EVERYTHING!!!!!!!!!
2. Boats, bump maps, more power to licensees!
I love torque script but i would rather use python. Just becuase theres more and better resources for programming with python.

#37 That sample pretty much annoys the hell out of me...

It's out of context, the formatting is screwed up, it's also a merge of two code snippets because I am sure it just wasn't ugly enough...

You can't even do what that code is doing in TorqueScript!!!!

Now, I highly doubt .cs is going anywhere... so this is really just a lot of noise outside of constructive ideas where .cs or Python support could be better... I've already been working my ass off on the later...

-Josh Ritter
Author of TGEPython

#38 1. The One thing I would like to see is a DIF SDK. Similiar to the DTS sdk already included. I would like to see clearly how DIF's are read by the engine and What is exactly wrote in the file. I have managed to weed through about half the exporter but I still have alot of questions.
This would also help promote better texturing techniques. Shaders might not be needed maybe the use of Normals would be easier. Also it might help in the implementation of a true TGE world editor (similiar to UnrealEd or Quakes Radient editors). 5 weeks if you understand DIF. The SDK would not even need to be a compiliable project just the nuts bolts of DIF.

2.Exterior/Interior Static lighting would be my second choice. This is desperatly needed. I am not sure of all the detailes involved in implementing this so I would hate to give an estimate on time but I would think it wouldn't be that bad. In fact I am surprised it Hasn't already been done.

My thoughts on changing the Scripting language Simple is better. If your going to do anything to it DUMB IT DOWN. Something along the lines of MAX SCRIPT or MAYA's Script language. Please don't make it any harder on us less "Programming" inclined people.

Thats me!
Matt

#39 The only thing I would like is standardization of the engine and a bit more work done on documentation.

Shaders, cg and curves I think are better left for individual developers but should hvae some structure in place to make its developement easier.

BTW Stan figured out what happened with merging the terrain manager with my code. :) - ( Compiled the wrong version of the source code. )

#40 curves shading and cg is what engines do... Why make an effort to leave them out. That seems alittle backward. No offence but wouldnt that be literally and purposfully retarding torques standardisation? People buy code cretures and 3dgs becuase of fetures mostly graphical. If its one thing tge2.0 should be is a all purpose game rendering platform, and thats the bare minimum. Im not demanding it have whatever feature. But lets be open minded, and not talk about excluding features that 99.9999% of people would want to use. It is a valid point that torque script cant compare to other available scripting languages. And i think GG's could save alot of time and money by using 3rd party systems like python.