A Literal Programming Language
by Will Harrison · in General Discussion · 03/28/2005 (11:09 am) · 146 replies
I just had this random thought. I'm not much of a programmer, but wouldnt it be easier if there was a programming language that was basically readable English?
For example, instead of this:
if (John.apples = 5 && Sally.oranges < 3) {
Jason.pears == 7;
}
You would write:
If John has 5 apples and Sally has less than 3 oranges then give Jason 7 pears.
Or in this case:
for (count=1; count<11; count++)
{
steeringWheel.rotate();
}
You could write:
Rotate the steering wheel 10 times.
Object names (steeringWheel) would be case-insensitive and could contain spaces (so you could say "Steering wheel" or "steering Wheel" and they would mean the same thing).... and the definite article "the" (e.g. rotate "the" steering wheel) could be be ignored by compiler.
For example, instead of this:
if (John.apples = 5 && Sally.oranges < 3) {
Jason.pears == 7;
}
You would write:
If John has 5 apples and Sally has less than 3 oranges then give Jason 7 pears.
Or in this case:
for (count=1; count<11; count++)
{
steeringWheel.rotate();
}
You could write:
Rotate the steering wheel 10 times.
Object names (steeringWheel) would be case-insensitive and could contain spaces (so you could say "Steering wheel" or "steering Wheel" and they would mean the same thing).... and the definite article "the" (e.g. rotate "the" steering wheel) could be be ignored by compiler.
About the author
#102
yes, it would be easier.. but with it you get a whole lot of complexity in designing the interface, and again for defining the range. If I made a manipulatot that allowed you to adjust the 'gravity' on an object, where do I bound it? between 0 and 1? between -10 and 10? Do we make the range unbound (give it is a space to type it in).. and , if that appraoch is taken, how is it easier than modifying it in script? How many of the say, player datablock tweakable parameters do we put into an interface to tweak? All 60-70? how do we fit this in a tweaker that fits on screen and is not cumbersome to work with?
The more that is done to make it easier, the more constrained you are in your design choices made by the people that create the objects you can modify.
With dRacer (as an example), we wanted to have really good handling on the cars. I have tried way to many racing games with poor physics and a bad feel, and we were not going to settle for anything less than what we thought had a feel on par with the best racing games out there. It took some custom coding, but I think we succeeded in what we were trying to acheive (and the Alpha Tech Dmonstrator getting voted best sinlge player game at the IGC backs up our perception of that success). If we had started with a pre defined set of rules that we tweaked.. I do not think we would have arrived at what we have now.
So, I hear what you are saying, and I agree, but the challenge is harder than it would first appear. A 'tweaker' would be great, but to get it set up, there would still need to be some coding and scripting that would need to be done to get it set up right.
As it is now, things are pretty good, with most of what one needs to do to prototype and test and idea being able to be mocked up with script. It gives the flexibility needed, and is relatively easy to get the hang of how to get it working.
As an example of the power of scripting, most of the major 3d apps have added a robust scripting language in order to allow end users to modify the interface and make tools to help with their workflow. The creators of the software recognized that they could not anticipate the workflow needs of all individuals, so they made it so we can modify it to our liking, make new tools that we find useful, and customize the working environment to suit the project at hand.
Can things be better? Certainly.. Editors need to be improved to make it easier for everyone to work.. the danger of defining a workflow, as evidenced by Adrain's comments on the art path, is that the more functionality you define, the more you constrain the creativity. It is a double edged sword. Right now, things are not that bad. Many of the game engines out there make it possible to rapidly prototype ideas using very little coding, and things will improve as time goes on.
04/19/2005 (10:50 pm)
Quote:Now compare doing all of that to simply having an interface in run-time where you could change these values on the fly and see the results. OMG, that would be 100x easier, and I'm sure you would agree. Remember, I'm talking about new users, but certainly this could benefit everyone as it makes everything faster.
yes, it would be easier.. but with it you get a whole lot of complexity in designing the interface, and again for defining the range. If I made a manipulatot that allowed you to adjust the 'gravity' on an object, where do I bound it? between 0 and 1? between -10 and 10? Do we make the range unbound (give it is a space to type it in).. and , if that appraoch is taken, how is it easier than modifying it in script? How many of the say, player datablock tweakable parameters do we put into an interface to tweak? All 60-70? how do we fit this in a tweaker that fits on screen and is not cumbersome to work with?
The more that is done to make it easier, the more constrained you are in your design choices made by the people that create the objects you can modify.
With dRacer (as an example), we wanted to have really good handling on the cars. I have tried way to many racing games with poor physics and a bad feel, and we were not going to settle for anything less than what we thought had a feel on par with the best racing games out there. It took some custom coding, but I think we succeeded in what we were trying to acheive (and the Alpha Tech Dmonstrator getting voted best sinlge player game at the IGC backs up our perception of that success). If we had started with a pre defined set of rules that we tweaked.. I do not think we would have arrived at what we have now.
So, I hear what you are saying, and I agree, but the challenge is harder than it would first appear. A 'tweaker' would be great, but to get it set up, there would still need to be some coding and scripting that would need to be done to get it set up right.
As it is now, things are pretty good, with most of what one needs to do to prototype and test and idea being able to be mocked up with script. It gives the flexibility needed, and is relatively easy to get the hang of how to get it working.
As an example of the power of scripting, most of the major 3d apps have added a robust scripting language in order to allow end users to modify the interface and make tools to help with their workflow. The creators of the software recognized that they could not anticipate the workflow needs of all individuals, so they made it so we can modify it to our liking, make new tools that we find useful, and customize the working environment to suit the project at hand.
Can things be better? Certainly.. Editors need to be improved to make it easier for everyone to work.. the danger of defining a workflow, as evidenced by Adrain's comments on the art path, is that the more functionality you define, the more you constrain the creativity. It is a double edged sword. Right now, things are not that bad. Many of the game engines out there make it possible to rapidly prototype ideas using very little coding, and things will improve as time goes on.
#103
this simply isn't true. You cabn actually duplicate the way torque works in blitz3D if you want to. Our vehicle and weapons set up in FMC was very much like the way you would set up something similar in TGE. You get to define your own art pipeline, and make use of the features you want, how you want them.
Here's an example of vehicles with weapons in an engine where vehicle and weapon set up was done in much the same way as you woudl do it in torque. 14mb
s93153354.onlinehome.us/FMC_Physics.avi
you can set up collisions in several ways, either coding your engine to automaticly make convex hull shapes. Make them yourself in 3dsmax, create nodes in max with nametags that the coder can use as handles for creating their oen colliion primitives, (or weapon mounts, and mounting pivotsm weapon attachnments, projectile firing points, muzzle flash spawn points. )Or you can use the collision modifier that the exporter supports to create your collision primitives in 3dsmax.
creating new weapons is no differebnt than in the code brett used above, create a type (like a class) and give it fields that define atribute etc, and you can make any number of weapons, player chatacters, vehicles with different parameters.
it's just a much more flexible exporter since you have the power to do whatever you please. You can make the best use of a tool like 3dsmax, or code, or combine the two to get whatever result you want.
JOE. I'd highly recommend trying our max exporter, www.onigirl.com/pipeline/
theres bult in viewer that you can run from within 3dsmax that lets you preview your work from within 3dsmax, with a button press. check it out.... I'd love torque to have such a well thought out exporter that supports a ton of 3dsmax features, and gives developers the freedom to develop games any which way they choose. You don't have the same kinds of creative limitations you get with torque. Someone could produce something like this with torque if they sat down and really looked at it properly. Someone that knows both 3dsmax and programming, understands the engine, and is willing to understand how simple the concepts behind the way the exporter works, would be able to produce something similar within 3 months.
Not all of it would be possible without a major rewrite as a lot of features aren't currently native within torque due to its emphasis on BSP and CSG type editing, but you could go pretty far and have an awesome tool that would really raise the bar in what torque can do for experienced developers, with a talented team.
Not going to help MOD people much, but not everyone is going to want their game totaly MODable anyway.
I urge you or someone else to take a proper look at it, because I know this would make a real difference to the quality of the games being developed.
If you do look at it, make sure you read the docs properly by checking the contents panel on the left when you open the URL pasted above.
www.onigirl.com/pipeline/What_are_B3d_Extensions_.htm
might be of particular interest if your short on time.
04/20/2005 (9:53 am)
Quote:the danger of defining a workflow, as evidenced by Adrain's comments on the art path, is that the more functionality you define, the more you constrain the creativity
this simply isn't true. You cabn actually duplicate the way torque works in blitz3D if you want to. Our vehicle and weapons set up in FMC was very much like the way you would set up something similar in TGE. You get to define your own art pipeline, and make use of the features you want, how you want them.
Here's an example of vehicles with weapons in an engine where vehicle and weapon set up was done in much the same way as you woudl do it in torque. 14mb
s93153354.onlinehome.us/FMC_Physics.avi
you can set up collisions in several ways, either coding your engine to automaticly make convex hull shapes. Make them yourself in 3dsmax, create nodes in max with nametags that the coder can use as handles for creating their oen colliion primitives, (or weapon mounts, and mounting pivotsm weapon attachnments, projectile firing points, muzzle flash spawn points. )Or you can use the collision modifier that the exporter supports to create your collision primitives in 3dsmax.
creating new weapons is no differebnt than in the code brett used above, create a type (like a class) and give it fields that define atribute etc, and you can make any number of weapons, player chatacters, vehicles with different parameters.
it's just a much more flexible exporter since you have the power to do whatever you please. You can make the best use of a tool like 3dsmax, or code, or combine the two to get whatever result you want.
JOE. I'd highly recommend trying our max exporter, www.onigirl.com/pipeline/
theres bult in viewer that you can run from within 3dsmax that lets you preview your work from within 3dsmax, with a button press. check it out.... I'd love torque to have such a well thought out exporter that supports a ton of 3dsmax features, and gives developers the freedom to develop games any which way they choose. You don't have the same kinds of creative limitations you get with torque. Someone could produce something like this with torque if they sat down and really looked at it properly. Someone that knows both 3dsmax and programming, understands the engine, and is willing to understand how simple the concepts behind the way the exporter works, would be able to produce something similar within 3 months.
Not all of it would be possible without a major rewrite as a lot of features aren't currently native within torque due to its emphasis on BSP and CSG type editing, but you could go pretty far and have an awesome tool that would really raise the bar in what torque can do for experienced developers, with a talented team.
Not going to help MOD people much, but not everyone is going to want their game totaly MODable anyway.
I urge you or someone else to take a proper look at it, because I know this would make a real difference to the quality of the games being developed.
If you do look at it, make sure you read the docs properly by checking the contents panel on the left when you open the URL pasted above.
www.onigirl.com/pipeline/What_are_B3d_Extensions_.htm
might be of particular interest if your short on time.
#104
My comment was not that you could not duplicate how the TGE exporter works in Blitz, it was a comment that design decisions made for individuals to make it easier end up constraining people. It is obvious that you don't agree with the decisions made by the individuals who designed the art path for the TGE and that you feel constrained by it.
It is not easy to get into.. and it does not, by design, allow you to do whatever you want. If you know how to use it, it is very powerful. It does take a little bit of bending to the way it wants to do things.. most of this inflexibility was designed to constrain the artist into creating efficient, working shapes, that would work as the engine expected.
The exisiting exporter for the TGE is a result of a process of repeated interation over the course of 2 engines, and multiple people pouding on it for a number of years on multiple projects. In fact, some of the design decisions around the way the exporter works were designed to make it easier for the entire team to work with it, and not just the artists. Many of the reviled features in the max version of the DTS exporter were actually added on the request of the artist (.cfg files, for instance)..
I have no creative limitations when working with the Torque or the related tools. But then again I am not one who requires that everything I want to do in max be made to be exportable into the engine. There are good reasons why certain features of max are not supported in the engine.. and again, some of the intolerance of the exporter is by design and at the request of the artists who were there, using it on a daily basis, making games.
It baffles me that you are under the impression that no thought went into the design of the exporter. A lot of thought went into it. Just because it does not give you the freedom you desire does not make it a bad tool for which is was designed, and this again, underscores my point.. the tool was designed to make it is easy to develop games. it does not necessarily make it easier to use in max...
If you want to rewrite the max exporter and parts of the engine to accomodate your work style.. no one is stopping you from doing so. I really have no desire to rewrite the exporter to support more features of the exporter.. as I do not feel constrained at all creatively. Then again, the exporter is designed for things like characters and vehicles.. it was never intended to be used for interiors.. and that is why the support for features which would make the creation of environments using max and the dts exporter kind of difficult. but.. if you want to slag a tool because you refuse to want to use it correctly, or you are unwilling to change your workflow at all.. that is your choice. For what I do, I feel no constraints.
I understand what you think the perfect development enviroment would be.. I just don't happen to agree. This does not make either of us right or wrong, it is just a matter of taste.
At the moment, there is nothing that is holding us back from making the games we want to make and getting the look and feel we want.
I know that you disagree, but I really wish you would stop blaming the tools for not working like you want them to work and just get on with the process of making games. If you want to use the TGE and want the tools to be different.. there is nothing stopping you or your team from doing so (the source is there)..BUT.. it seems that you have made up your mind. I have no problems with Blitz and I am glad it supports what you want to do. I really wish you would stop trying to convince everybody that the torque is in someway inferior because it does not work like you want it to.
Different strokes for different folks.
04/20/2005 (11:40 am)
Adrain,My comment was not that you could not duplicate how the TGE exporter works in Blitz, it was a comment that design decisions made for individuals to make it easier end up constraining people. It is obvious that you don't agree with the decisions made by the individuals who designed the art path for the TGE and that you feel constrained by it.
It is not easy to get into.. and it does not, by design, allow you to do whatever you want. If you know how to use it, it is very powerful. It does take a little bit of bending to the way it wants to do things.. most of this inflexibility was designed to constrain the artist into creating efficient, working shapes, that would work as the engine expected.
The exisiting exporter for the TGE is a result of a process of repeated interation over the course of 2 engines, and multiple people pouding on it for a number of years on multiple projects. In fact, some of the design decisions around the way the exporter works were designed to make it easier for the entire team to work with it, and not just the artists. Many of the reviled features in the max version of the DTS exporter were actually added on the request of the artist (.cfg files, for instance)..
I have no creative limitations when working with the Torque or the related tools. But then again I am not one who requires that everything I want to do in max be made to be exportable into the engine. There are good reasons why certain features of max are not supported in the engine.. and again, some of the intolerance of the exporter is by design and at the request of the artists who were there, using it on a daily basis, making games.
It baffles me that you are under the impression that no thought went into the design of the exporter. A lot of thought went into it. Just because it does not give you the freedom you desire does not make it a bad tool for which is was designed, and this again, underscores my point.. the tool was designed to make it is easy to develop games. it does not necessarily make it easier to use in max...
If you want to rewrite the max exporter and parts of the engine to accomodate your work style.. no one is stopping you from doing so. I really have no desire to rewrite the exporter to support more features of the exporter.. as I do not feel constrained at all creatively. Then again, the exporter is designed for things like characters and vehicles.. it was never intended to be used for interiors.. and that is why the support for features which would make the creation of environments using max and the dts exporter kind of difficult. but.. if you want to slag a tool because you refuse to want to use it correctly, or you are unwilling to change your workflow at all.. that is your choice. For what I do, I feel no constraints.
I understand what you think the perfect development enviroment would be.. I just don't happen to agree. This does not make either of us right or wrong, it is just a matter of taste.
At the moment, there is nothing that is holding us back from making the games we want to make and getting the look and feel we want.
I know that you disagree, but I really wish you would stop blaming the tools for not working like you want them to work and just get on with the process of making games. If you want to use the TGE and want the tools to be different.. there is nothing stopping you or your team from doing so (the source is there)..BUT.. it seems that you have made up your mind. I have no problems with Blitz and I am glad it supports what you want to do. I really wish you would stop trying to convince everybody that the torque is in someway inferior because it does not work like you want it to.
Different strokes for different folks.
#105
04/22/2005 (7:48 am)
I am not blaming the tools, just disappointed that no one seems to be looking past the late 90's and looking at new developments and techniques that have become more common place in the last 5 years. 
#106
Linux is a pain in the arse to learn, very quirky, very tricky and hard to learn the first time. If you use its true power you configure it through text files and command line lol... Now Windows is nice and shiny, it has nice fancy gui interfaces that let you point and click... but because of this the efficiency of the OS is much less than running a command line Linux, not even comparable... Theres a reason why the net is run off of Linux, theres a reason why OSX uses the same unix backbone... theres a reason why Torque is set up the way it is, with BSP and CSG geometry (the speed increase is more than enough for anyone to become an advocate of such) as well as the exporters. Torque may not be as easy as Blitz 3D, it also may take a few more steps to get some of the same features... but usually these steps mean increased efficiency in the long run
04/22/2005 (8:25 am)
This reminds me of the comparisson of Windows to Linux lol...Linux is a pain in the arse to learn, very quirky, very tricky and hard to learn the first time. If you use its true power you configure it through text files and command line lol... Now Windows is nice and shiny, it has nice fancy gui interfaces that let you point and click... but because of this the efficiency of the OS is much less than running a command line Linux, not even comparable... Theres a reason why the net is run off of Linux, theres a reason why OSX uses the same unix backbone... theres a reason why Torque is set up the way it is, with BSP and CSG geometry (the speed increase is more than enough for anyone to become an advocate of such) as well as the exporters. Torque may not be as easy as Blitz 3D, it also may take a few more steps to get some of the same features... but usually these steps mean increased efficiency in the long run
#107
On what do you base that assertion? Looking past the 90's? What developments and techniques are you specifically referring to?
Is attempting to use a tool designed to export characters and vehicles to export entire levels one of these new developments or techniques?
Or is it the 'I need a second set of UV channels so I can tile tiny textures AND make my own lightmaps' complaint that you always have, like tiling textures is somehow 'new' and render to texture was not something people used before the year 2000.
People are looking at the tools.. people are giving in thought. I personally am keeping up on the latest developments, and I share your concerns, but it really is kind of lame that you keep going on and on about it. What specifically are you referring to?
All I get out of your comments everytime you bring up these issues is that you refuse to change the way you work to get the features you want, and that the features you want are not supported the way you want them supported.
I have my own ideas of the perfect toolchain.. they are not the same as your ideas. I have no problem with that.. if we want something more or for it to behave differently, my team adds the support for what we want. If you have ideas that you want added, find a team that wants to add them, or go to a different tool.
Slagging a tool for not doing what you want is just lame. If the toolchain working exactly the way you want it to work is a high priority to you, then choose a toolset based on that.
I find the assertion that no one is 'looking past the 90's' pretty ignorant.
04/22/2005 (8:27 am)
Adrain,On what do you base that assertion? Looking past the 90's? What developments and techniques are you specifically referring to?
Is attempting to use a tool designed to export characters and vehicles to export entire levels one of these new developments or techniques?
Or is it the 'I need a second set of UV channels so I can tile tiny textures AND make my own lightmaps' complaint that you always have, like tiling textures is somehow 'new' and render to texture was not something people used before the year 2000.
People are looking at the tools.. people are giving in thought. I personally am keeping up on the latest developments, and I share your concerns, but it really is kind of lame that you keep going on and on about it. What specifically are you referring to?
All I get out of your comments everytime you bring up these issues is that you refuse to change the way you work to get the features you want, and that the features you want are not supported the way you want them supported.
I have my own ideas of the perfect toolchain.. they are not the same as your ideas. I have no problem with that.. if we want something more or for it to behave differently, my team adds the support for what we want. If you have ideas that you want added, find a team that wants to add them, or go to a different tool.
Slagging a tool for not doing what you want is just lame. If the toolchain working exactly the way you want it to work is a high priority to you, then choose a toolset based on that.
I find the assertion that no one is 'looking past the 90's' pretty ignorant.
#108
04/22/2005 (8:27 am)
Btw have you even seen TSE ? The Shaders, the Terrain, the Water ... lol... were you at GDC, Garage Games got a lot of attention to the new technology they are working on
#109
I think the new technology being talked about here would be things like VIPM meshes, occlusion culling, and so on.
04/22/2005 (9:24 am)
Shaders aren't /really/ a new technology. They're old technology in new clothes. And they're fairly easy to integrate into an existing architecture.I think the new technology being talked about here would be things like VIPM meshes, occlusion culling, and so on.
#110
04/22/2005 (9:29 am)
The new Terrain and Water show off a lot more than just shaders, I beleive it was mentioned at GDC using Frustrum Culling (correct me if I'm wrong GG?), Massive Terrain paging (with practically no limit)... etc ... the list goes on...
#111
Terrain paging will be nice, though.
I'd get a lot more excited about a more unified physics system, or an occlusion setup with somekind of a better collision structure (AABB trees, maybe) so Torque could finally drop the BSP levels.
04/22/2005 (9:37 am)
Frustrum culling is as old as the hills!Terrain paging will be nice, though.
I'd get a lot more excited about a more unified physics system, or an occlusion setup with somekind of a better collision structure (AABB trees, maybe) so Torque could finally drop the BSP levels.
#112
also note that the TGE does have occlusion culling on object occluded by terrain.. this is in no way nearly as robust as it could be, but it is not limiting us thus far. If we do get into a situation that requires it, we will do the work to make it happen. As for collision improvements, check out Clark's Plan
My remarks were not to say things could not be better (they always can).. they were made to point out that people have not stopped looking at what is out there.
04/22/2005 (9:52 am)
Note that we experimented with progressive mesh LOD back at dyanmix.. and the results of the tests were a little disappointing. The control over LOD was worse than static LOD, and the memory footprint over the regular static LOD shapes was larger.. at the same time we also looked at supporting patches. and a few other things.. also note that the TGE does have occlusion culling on object occluded by terrain.. this is in no way nearly as robust as it could be, but it is not limiting us thus far. If we do get into a situation that requires it, we will do the work to make it happen. As for collision improvements, check out Clark's Plan
My remarks were not to say things could not be better (they always can).. they were made to point out that people have not stopped looking at what is out there.
#113
BTW, torque may be fast considering all the effort being put into occlusion, LOD, collisions etc which are some of the benefits of BSP. But that also limits you unless you have a good hybrid system, it's hard to add detail to your environments without bogging the game down.
Of course blitz is slower, on the other hand if you develop with it intelligently this isn't always obvious. Many games simply don't need a lot of LOD, collisions or occlusion. My racing game for instance. Only areas around the track require collision. ODE uses a lot of CPU for the cars, particularly if its working with large triangle meshes. So like in many games games today, I use hidden proxy collisions to get better performance.
In my games case, I have 1400 collision polys, allthough the mesh is split into 14 100ish poly meshes and only the section a particular car travels over actualy has any calculation made on it.
thanks to the multitexturing capabilities, plus my experience with working on 3d games, the entire track is actually pretty low polygon. aproximately 30,000 when you take away a few lightmap rendering layers, and old non colapsed geometry.
making those collisions might sound like a pain, but thanks to 3dsmax excellent snapping and alignment tools, it really isn't and the benefits are huge. I still have room for a lot more polys in my level, my limiting factor is the CPU required for the physics and AI, which is substancial.
Because I don't have to use convex hull shapes with up to 4x the ammount of polys I actually need visible, I can produce a level in blitz that looks more detailed and uses probably as much as 30% the ammount of data that torque would currently need to process to produce a similar level, and considerably less collisions. I don't need LOD since 40,000 polys are trivial even for cards 5 years old. My geforce 2 on a 1ghz machine runs the game at 40-80fps the limiting factor being the CPU and ODE my new computer that has a old Geforce 3 averages around 170FPS.
04/22/2005 (9:55 am)
For me the art pipeline isn't about only making pretty graphics. Art isn't what makes a game good, it just helps. A good art pipeline allows a 2 man team to be flexible, and develop new ways of making use of their media, or use their tools more efficiently with a lot more flexibility. If you have experienced artists and coders that know their respective tools, and understand how an engine works, there is a lot that can be done to create a better product if you have a lot more freedom to be creative.BTW, torque may be fast considering all the effort being put into occlusion, LOD, collisions etc which are some of the benefits of BSP. But that also limits you unless you have a good hybrid system, it's hard to add detail to your environments without bogging the game down.
Of course blitz is slower, on the other hand if you develop with it intelligently this isn't always obvious. Many games simply don't need a lot of LOD, collisions or occlusion. My racing game for instance. Only areas around the track require collision. ODE uses a lot of CPU for the cars, particularly if its working with large triangle meshes. So like in many games games today, I use hidden proxy collisions to get better performance.
In my games case, I have 1400 collision polys, allthough the mesh is split into 14 100ish poly meshes and only the section a particular car travels over actualy has any calculation made on it.
thanks to the multitexturing capabilities, plus my experience with working on 3d games, the entire track is actually pretty low polygon. aproximately 30,000 when you take away a few lightmap rendering layers, and old non colapsed geometry.
making those collisions might sound like a pain, but thanks to 3dsmax excellent snapping and alignment tools, it really isn't and the benefits are huge. I still have room for a lot more polys in my level, my limiting factor is the CPU required for the physics and AI, which is substancial.
Because I don't have to use convex hull shapes with up to 4x the ammount of polys I actually need visible, I can produce a level in blitz that looks more detailed and uses probably as much as 30% the ammount of data that torque would currently need to process to produce a similar level, and considerably less collisions. I don't need LOD since 40,000 polys are trivial even for cards 5 years old. My geforce 2 on a 1ghz machine runs the game at 40-80fps the limiting factor being the CPU and ODE my new computer that has a old Geforce 3 averages around 170FPS.
#114
I'm just disappointed, because I know just how good something like TSE would be for people that have similar experiences to mine. I don't have time to learn to code well enough to modify torque, and I don't know anyone that knows both game engines and 3d apps well enough to modify torque in this way. Or at least, not anyone that isn't already working in the industry.
I'd pay about $500 -$1000 for a build of TSE with those features and an improved exporter, and I'm not alone. Just yesterday I discussed this with 2 other people in the same position I am, plus there is a lot of talk on the blitz forums about alternatives for serious experienced indies that are looking for something more powerful, allows similar flexibility, and makes proper use of that power.
Anyway, there's no point me continuing with this discussion, I've been with this community since 2001 watching with interest, hoping that someday things will changed. I'm only using blitz because it is the only alternative to torque that does what I want, and despite it's MANY limitations, it is good enough to develop the majority of indie games. And despite being DX7, you can still produce better more dynamic visuals than much of the competition.
Perhaps gamebench will be able to prove itself when its released, but I'm sceptical. I've used A6 and despite a couple of things it does seem to do better, I prefer torque.
I think there is a market for the tools I'm talking about, and its a product that many people would pay a premium for. The way my current exporter works would allow dvelopers to quickly develop exporters for a variety of 3d applications once an extension library had been written for Torque as the entire pipeline is mostly dependent on parsing custom child node data.
You could write your own exporter in maxscript, Mel etc, but still need someone to create the actual extensions for the torque engine itself.
04/22/2005 (9:57 am)
The way I work in blitz is similar to the way I have worked with commercial game engines in the past. I'm not saying either of us are wrong. And your way is definately more MOD friendly, and easier for that deographic to pick up and use. It also means that people with limited tools and exerience can easily modify the traditionaly FPS nature of torque games and have alot of fun doing it, and possibly get their mod published.I'm just disappointed, because I know just how good something like TSE would be for people that have similar experiences to mine. I don't have time to learn to code well enough to modify torque, and I don't know anyone that knows both game engines and 3d apps well enough to modify torque in this way. Or at least, not anyone that isn't already working in the industry.
I'd pay about $500 -$1000 for a build of TSE with those features and an improved exporter, and I'm not alone. Just yesterday I discussed this with 2 other people in the same position I am, plus there is a lot of talk on the blitz forums about alternatives for serious experienced indies that are looking for something more powerful, allows similar flexibility, and makes proper use of that power.
Anyway, there's no point me continuing with this discussion, I've been with this community since 2001 watching with interest, hoping that someday things will changed. I'm only using blitz because it is the only alternative to torque that does what I want, and despite it's MANY limitations, it is good enough to develop the majority of indie games. And despite being DX7, you can still produce better more dynamic visuals than much of the competition.
Perhaps gamebench will be able to prove itself when its released, but I'm sceptical. I've used A6 and despite a couple of things it does seem to do better, I prefer torque.
I think there is a market for the tools I'm talking about, and its a product that many people would pay a premium for. The way my current exporter works would allow dvelopers to quickly develop exporters for a variety of 3d applications once an extension library had been written for Torque as the entire pipeline is mostly dependent on parsing custom child node data.
You could write your own exporter in maxscript, Mel etc, but still need someone to create the actual extensions for the torque engine itself.
#115
04/22/2005 (10:05 am)
You do have some very good points... though considering that there might be a market in the tools your are illustrating, I strongly beleive there is a larger market for a team of Indies... ones where they have artists, modellers, and programmers... the programmers then would customize the engine to their games needs while the artists do the modelling and such... Doing this GG can then focus their attention on engine improvements, things that truly add power to it. Just my take on it at least. My team won't need the tool you suggest, in fact I highly doubt most serious Indie teams would truly need it, they might want it, but I'd happily trade that for more engine power and I'll handle any engine extensions my team needs
#116
A simple example being a subterranian mine system for a vehicle combat game I worked on taking up half a level, plus a 3km terrain outside the cave system. the cave system had 2 tunnel entrances, and half the level was occluded by slicing the entire level in 2 at the entrance with a giant plane. Negative occluders could punch a hole in an occluder plane that you coudl see geometry through, so naturaly at the cave entrance you placed these to cover the hole through which you could see the inside/outside. you might have 40 or 50 of these in a 250,000+ poly level (they only worked in one direction, so you would often use them in pairs hence the large number, placed in large terrain features, buildings, inside walls and floors etc.
As your player moves around the world, the engine checks the nearest occluder planes only and dynamicly picks the nearest 4 that obstruct the most of the world at any time.
This proved surprisingly efficient and gave us a lot of CPU left over for calculating the AI floorplan meshes and allowing for some outstanding dynamic AI, with vertex painted AI floormap behavioural modifiers for the terrain and interiors, effecting NPC's behaviour and tactics. we had a form of terrain paging too, but this was handled by an external builder hub utility that optimized level geometry and exported to a predetermined target platform. So you only needed to make everything for the highest spec hardware, and the builder woudl cut back on shaders and rendering effects depending on which target platform you picked to output to. The builder also had debug features that would spew out errors/inefficient areas of the levels and give ingame coordinates for artists to better troubleshoot problem areas.
the Occluders were placed by artists and level builders within 3dsmax, the collision geometry and AI floormaps were also made in 3dsmax, along with all the usual object placement, triggers and gameplay objects you would normay expect in an editor.
04/22/2005 (10:27 am)
The last commercial engine I used, which was for an Xbox and PS2 title, we had simple per poly frustrum culling for the camera, without any ranged draw in and manualy placed occluder planes that you placed within large pieces of scenery to mask out/occlude vast chunks of geometry. A simple example being a subterranian mine system for a vehicle combat game I worked on taking up half a level, plus a 3km terrain outside the cave system. the cave system had 2 tunnel entrances, and half the level was occluded by slicing the entire level in 2 at the entrance with a giant plane. Negative occluders could punch a hole in an occluder plane that you coudl see geometry through, so naturaly at the cave entrance you placed these to cover the hole through which you could see the inside/outside. you might have 40 or 50 of these in a 250,000+ poly level (they only worked in one direction, so you would often use them in pairs hence the large number, placed in large terrain features, buildings, inside walls and floors etc.
As your player moves around the world, the engine checks the nearest occluder planes only and dynamicly picks the nearest 4 that obstruct the most of the world at any time.
This proved surprisingly efficient and gave us a lot of CPU left over for calculating the AI floorplan meshes and allowing for some outstanding dynamic AI, with vertex painted AI floormap behavioural modifiers for the terrain and interiors, effecting NPC's behaviour and tactics. we had a form of terrain paging too, but this was handled by an external builder hub utility that optimized level geometry and exported to a predetermined target platform. So you only needed to make everything for the highest spec hardware, and the builder woudl cut back on shaders and rendering effects depending on which target platform you picked to output to. The builder also had debug features that would spew out errors/inefficient areas of the levels and give ingame coordinates for artists to better troubleshoot problem areas.
the Occluders were placed by artists and level builders within 3dsmax, the collision geometry and AI floormaps were also made in 3dsmax, along with all the usual object placement, triggers and gameplay objects you would normay expect in an editor.
#117
So if anyone with the coding skills needs someone like me to help them develop something like this, I'm definately interested. Jeremy and I discussed maybe trying to do it , but unfortunately he isn't very experienced in the key areas required to make a project like this feasible.
04/22/2005 (10:45 am)
BTW , I don't mean to sound like an arse, I'm just really passionate about certain things, but don't have the resources to make a difference all by myself. A few months ago Mathew Fairfax and I were considering working on some kind of a compromise modification to TGE. Unfortunately, at the time I was in crunch on a existing project, and by the time I was avaliable Mathew became bogged down in other GG stuff.So if anyone with the coding skills needs someone like me to help them develop something like this, I'm definately interested. Jeremy and I discussed maybe trying to do it , but unfortunately he isn't very experienced in the key areas required to make a project like this feasible.
#118
It is like you are arguing both sides of the coin. You don't want your freedom to be inhibited, but in your posts you are talking about poly counts and collision geometry and occulders , etc...
I still am not getting what you are driving at.. so, ok, you can use max to make your race levels.. for us we make race levels using a spline in the mission editor. All the collision, the geometry.. that is taken care of for us. Brett made a tool that allows us to just stick the terrain to the bottom of the track automagically..
here is a wireframe image of a Dracer track:
the tools created allow for one person to create a track..in a matter of hours... and they don't need access to max.. All of the current tracks were created by Brett using the editor he made. We don't have to think about where to place collision shapes or poly usage all that much.. The track system handles it for us. (and textures it too) a custom decal can be used for anything special on the track, and we can alter the profile of the track as much as we want. Most of what we have to worry about is making what we have look good and appeal to the audience in question. It required the creation of tech.. but right now, we are not inhibited in any way.. either artistically or technically (poly counts) with the approach we are taking.
here is how I deal with occlusion of static objects in our missions. I put them on the terrain.. and when they are not visible, they get occluded.
Here is a screenshot.
note the added red line for visibility of the hill in the foreground.
sorry, I am just not buying in.. I give up all this neat stuff for an 'advanced' exporter that 'allows' me to go in and have to place collision meshes and occluders? uh.. yeah.. that is what I call a step forward.. more like a step into the dark ages.
call it great for the 'MOD community or whatever you want to make yourself feel that somehow the processes that other people are using are somehow inferior. I am not going to knock your way of approaching game construction. Do it any way you want. I look at what you are doing and you keep telling me how it would allow for all this advancement, and I think to myself... ok.. I need to limit my track to under 30K ploys. and I need to pay attention to the collision meshes, which I make by hand.. I need to plan out and think about occluders..
pfft.. I don't need to think about any of that shit right now. Most of it is done for me, and I can worry about making the game fun. If we add some custom tools that requires the use of manually place collision or occluders, I would happily do it. What I like now is that this kind of tweaking is special case, and not something I have to worry about when making the game.
Does the current art pipeline inhibit small teams? You seem to think so.. I actually beleve the opposite. I think the TGE toolset enables small teams to do a great deal, and the plus side is that they don't have to have absolute control over everything (nor does it require the knowledge to use it) in order to get good performance. Another plus is that it does not require 3dsmax/maya/xsi in order to work.
Are there tradeoffs? yes.. there are. Do I think the tradeoffs are acceptable? yes, without a doubt. Does not having to place occluders and collision shapes make me stupid or somehow unaware how to make art for games? you seem to imply that it does. You are welcome to feel that way.
04/22/2005 (12:01 pm)
Adrain,It is like you are arguing both sides of the coin. You don't want your freedom to be inhibited, but in your posts you are talking about poly counts and collision geometry and occulders , etc...
I still am not getting what you are driving at.. so, ok, you can use max to make your race levels.. for us we make race levels using a spline in the mission editor. All the collision, the geometry.. that is taken care of for us. Brett made a tool that allows us to just stick the terrain to the bottom of the track automagically..
here is a wireframe image of a Dracer track:
the tools created allow for one person to create a track..in a matter of hours... and they don't need access to max.. All of the current tracks were created by Brett using the editor he made. We don't have to think about where to place collision shapes or poly usage all that much.. The track system handles it for us. (and textures it too) a custom decal can be used for anything special on the track, and we can alter the profile of the track as much as we want. Most of what we have to worry about is making what we have look good and appeal to the audience in question. It required the creation of tech.. but right now, we are not inhibited in any way.. either artistically or technically (poly counts) with the approach we are taking.
here is how I deal with occlusion of static objects in our missions. I put them on the terrain.. and when they are not visible, they get occluded.
Here is a screenshot.
note the added red line for visibility of the hill in the foreground.
sorry, I am just not buying in.. I give up all this neat stuff for an 'advanced' exporter that 'allows' me to go in and have to place collision meshes and occluders? uh.. yeah.. that is what I call a step forward.. more like a step into the dark ages.
call it great for the 'MOD community or whatever you want to make yourself feel that somehow the processes that other people are using are somehow inferior. I am not going to knock your way of approaching game construction. Do it any way you want. I look at what you are doing and you keep telling me how it would allow for all this advancement, and I think to myself... ok.. I need to limit my track to under 30K ploys. and I need to pay attention to the collision meshes, which I make by hand.. I need to plan out and think about occluders..
pfft.. I don't need to think about any of that shit right now. Most of it is done for me, and I can worry about making the game fun. If we add some custom tools that requires the use of manually place collision or occluders, I would happily do it. What I like now is that this kind of tweaking is special case, and not something I have to worry about when making the game.
Does the current art pipeline inhibit small teams? You seem to think so.. I actually beleve the opposite. I think the TGE toolset enables small teams to do a great deal, and the plus side is that they don't have to have absolute control over everything (nor does it require the knowledge to use it) in order to get good performance. Another plus is that it does not require 3dsmax/maya/xsi in order to work.
Are there tradeoffs? yes.. there are. Do I think the tradeoffs are acceptable? yes, without a doubt. Does not having to place occluders and collision shapes make me stupid or somehow unaware how to make art for games? you seem to imply that it does. You are welcome to feel that way.
#119
Passionate of not, your statements are often insulting and condescending. To read what you write, one would think that none of us have shipped a game before, or that we are totally clueless when it comes to art tools or production pipelines. Throwing in little 'well. the last engine I used, for an xbox and ps2 title...' just reeks of elitism.
If you want to find people that know what they are doing and are willing to work with you, it is my opinion that you would do better if you stopped trying to put everyone who is working on TGE down with your 'I worked on an xbox game so I know better' attitude. It is not making you any friends. If you stopped insulting everyone who's ideas differ from yours, and understood that improving the toolchain and pipeline for everyone. and not just 3dsmax users, is the goal.. and were willing to bend a little in your workflow and consider that there might be other ways of working that are just as effective (possibly more so).. then you would probably get more traction.
04/22/2005 (12:01 pm)
As for being an arse.. you may not intend to come off like one.. but you are coming off like one. I understand you are passionate about how you you want to do things. So am I.. right now we have a small team working on dRacer and a small team porting Thinktanks to the xbox.. at the cornerstone of the reason why we went indie was to prove it was possible to make good games with small teams, and to make the process a little less expensive, and within the grasp of those that can't afford or justify the expense of a $3500 tool. I want to improve the process.. I also want to make the process accessible to anyone who wants to do it. Passionate of not, your statements are often insulting and condescending. To read what you write, one would think that none of us have shipped a game before, or that we are totally clueless when it comes to art tools or production pipelines. Throwing in little 'well. the last engine I used, for an xbox and ps2 title...' just reeks of elitism.
If you want to find people that know what they are doing and are willing to work with you, it is my opinion that you would do better if you stopped trying to put everyone who is working on TGE down with your 'I worked on an xbox game so I know better' attitude. It is not making you any friends. If you stopped insulting everyone who's ideas differ from yours, and understood that improving the toolchain and pipeline for everyone. and not just 3dsmax users, is the goal.. and were willing to bend a little in your workflow and consider that there might be other ways of working that are just as effective (possibly more so).. then you would probably get more traction.
#120
Check out the video for it.
04/22/2005 (12:08 pm)
I also want to add that Clark is writing a network capable collision system for dRacer, which is also a base component of the component system. Check out the video for it.
Torque Owner Kenneth Porter
For an example of a popular programming language with more than one way to express things, check out Perl. (Torque Script reminds me a lot of Perl.) I find this "looseness" frustrating as I'm never sure what the proper idiom should be.
Terseness in C/C++ is a feature, something that English has evolved over time. Have you ever used a contraction? That's just a natural language example of shortening something the way we replace BEGIN/END with curly braces in C. This terseness allows one to put more information in the same space, in much the same way a picture is worth a 1000 words.
Note however how structure is hard to spot in natural language, and how we use indentation to make structure stand out in programming languages. The closest thing in natural language is probably poetry.