TV3D vs 3d Gamestudio

[ghostryder]

Exactly the type my example shows. To load the exteral level, pass along variables be it stats, health or inventory items to do that in C++ would be a nightmare. Simply have the the ability to load the level geometry is merelt incidentel-you still need to have the level interact with the game.

[pizzayoyo]

Exactly the type my example shows. To load the exteral level, pass along variables be it stats, health or inventory items to do that in C++ would be a nightmare. Simply have the the ability to load the level geometry is merelt incidentel-you still need to have the level interact with the game.

I'm not sure if i understand you correctly.

In a game, all you would need was one function lets say called LoadLevel that takes a level filename and does what it needs to to load it in the engine. This function can be used over and over again for all levels. So it wouldn't realy be that hard. That is what all games do.

[Mixael]

If I lack technical members and C++ coders and mostly have artists and animators I'm looking at engines that have simplified scripting language and not ones relying on complex languages that take years to get productive in. It's just not practical.

In fact I would absolutely hate to code a complex RPG game in C++ or Visual basic even if I knew both very well as the code management would be a nightmare. In script languages for instance level jumping is handled globally with about 50 lines of code.

I had to jump in here, due to what I have quoted (and I hope I got all of it...I'm writing this at work and trying not to get in trouble for "playing" ).

On one hand, when you mention lacking the programmers (or ability to program yourself), I can follow what you are saying...you need the "difficult" part handled for you.  Before I learned ANY programming languages, I needed the same help.

HOWEVER, you make the mistake of assuming that using C++ or VB (in any of the multitude of flavors of both), or even C#, you can't use scripting languages.  I must ask if you've ever heard of Python, or Lua, or similar FREE scripting languages?

While I am learning C++ at the same time I'm learning TV3D (I also have VB6 and VB .NET 2K5, so I can fall back on some stuff while learning ), it isn't the easiest thing in the world to do.  I have the luck, or whatever you want to call it, to have used several other languages that I can fall back on to ease the transition into c++.  But, I know I can use TV3D to make my GAME enginge that in turn uses a scripting language to do the other stuff...like control level loading, combat, and all that other stuff.

In ANY package that has a scripting language, you essentially use the same method as in C++ with TV...you create and use an interface between the two that lets you talk back and forth, and even control your enginge from a script.  (Albeit, in some engines that interface is hidden from you - mostly - and you are responsible for it in C++, et al.)

And these scripting languages, in the most part, have ready samples on how to create the interface.  They may need modified for a particular purpose, but the basics are there.

In short, Unlesss I'm missing something important (other than the programmer availability for a project), your statements that I quoted are, if not wrong, incomplete.


Michael

[ghostryder]

No you are correct. If you can get a good coder to tie a scripting language to the egine like Lua you are good to go. however, I am not wrong about level loading. In C you copy all level code and change level names- and that is quite different than how a script language handles it, and in a RPG that would be some long code.

This last project we tried to to tie Irrlict engine to Lua-but because critical areas of the engine was unfunished we were unable to although all indications at first glance looked like it was possible. There was even several answers on thier forums saying as such but alas time in chat spent with the engine developers showed this ability was a year away.

even here again you still have your shaders and particle effects to deal with, not to mention physics, and if anyone has ever looked at Newton or any of the others you know your be hard pressed understanding it enough to get it working wthout a solid knowledge of C. So getting Lua to work would only be part of the battle.

[Mixael]

No you are correct. If you can get a good coder to tie a scripting language to the egine like Lua you are good to go. however, I am not wrong about level loading. In C you copy all level code and change level names- and that is quite different than how a script language handles it, and in a RPG that would be some long code.

This last project we tried to to tie Irrlict engine to Lua-but because critical areas of the engine was unfunished we were unable to although all indications at first glance looked like it was possible. There was even several answers on thier forums saying as such but alas time in chat spent with the engine developers showed this ability was a year away.

even here again you still have your shaders and particle effects to deal with, not to mention physics, and if anyone has ever looked at Newton or any of the others you know your be hard pressed understanding it enough to get it working wthout a solid knowledge of C. So getting Lua to work would only be part of the battle.

I'm confused here.  You started off saying i was correct about getting a good coder to tie the scripting  language to the (C++, VB, you name it) game engine being good to go, then say that level loading, etc is different (in C) than in a scripting language?   If you (or your code-guru-type) gets the GAME ENGINE working, with a good interface to the scripting language of choice, and a neat game-script-GRAPHICS stream, then there is no difference between you doing it with your scripting, and me doing it through MY scripting (with the exception that I am using C++, not GS.

Having said that, I believe YOU are confused, as well.  (I mean no offense, by the way.)  Both TV3D and Irrlicht are GRAPHICS ENGINES.  They are not game engines.  YOU have to tie them together via code OUTSIDE of the code the contain.  In other words, if you have a scripting language and either Irrlicht or TV, YOU have to write the engine that uses both.  

What I mean is this:  The scripting language (well, the actuall scripts anyway) are the tracks of a train...they take it where you want it to go.  The GAME ENGINE (that you write, not an outsider) is the train...it does the work of making sure everything goes together.  The graphics engine (Either TV or Irrlicht) is the landscape and scenery you see while you're on the train.  Script guides the game engine, graphics show the "view" and the game engine kinda holds it all together.

Your second paragraph, by the way, is what i'm refering to.

Now, about shaders, physics, particle effects, and so on...You don't HAVE to use them

I'm gonna ignore the physics part 'cause I don't know much about it, but shaders and particle effects you can get from freeware tools.  And they even (some not all of them) drop out the c/c++ code you need to implement them.  Granted, you may have to search HARD for them, but they are there (at least for TV, OGRE, and I *think* Irrlicht that is).

And ghostryder, you can PM me and we can continue the conversation there, if you'd like.  I just think we're getting a little off topic for the forum now.    

Finally, for THIS post at least, I hope I'm not coming across as angry or argumentative, as I'm not trying to be.  If I am, let me know.

Michael

[ghostryder]

Not at all Mixael. My point is when comparing the two, TV3d and A6 what you think I am confused about is exactly what seperates the two engines. You can, if you have the coders put the pieces together to get close, buy some external tools and tie a LUA scripting language ---- but that is a big IF - as you need a good coder (someone just learning will not be able to handle it)

It goes back to the saying, you level fastest when working at your own level, and if you jump in over your head in this your get bad results.

c++ coders are extremely hard to find. Our team would love to jump to a rendering engine for the added speed and flexability-but we lack funds to hire such a person. (which is exactly why we are looking at enginines in these price ranges.

[Mixael]

AH!  And the demon of trying to gather meaning only from the written word strikes again  (That's why I used the word confused..it's often difficult to get the proper message without aural and visual clues to go with the words.)  

I'm sure I said it, but I might have glossed over it, but I agree that not having a coder makes the use of an external scripting language - like Lua - uh, makes it problematic.

I don't know how hard it is to find coders, as I'm not looking for one.

But, as a last point, I thought you need to work above your level (not over your head, barely out of reach).  If you only work at your current level, you won't reach the levels where you can do what is "over your head" at this time.

Maybe that is just a matter of semantics.

Mixael

[Mixael]

I've been looking at the A6 package, and can't seem to come to grips with one thing about it...the scripting is in a C derivative.  A non-coder is STILL going to have to learn to program (somewhat), and the true "power" of the A6 engine is it's c/c++ sdk.  For what it's worth, and this is my OPINION, not authoritative fact, I'd rather stick with TV.  

It seems to me that oyu can either use "bolt together" peices to make a game - albeit a very generic, not very unique look-alike to others game - with A6 as is, but you'll still need a coder (at least that can learn the scripting language quickly) to do a truly unique game.

*"unique" meaning truly yours as opposed to the bolt-together pre-fabricated pieces that come with the engine.  There is not any real way to get around having to have a programmer, even with the A6 engine.

ghostryder, I'm not wanting a flame war, just putting forth my opinion on the subject.  


Michael

P.S.  Thank you for remaining civil in our exchange of ideas, as all too often one or the other in these discussions gets a little hot under the collar.

[darqSHADOW]

ghostryder, for all of your touting of scripting you are missing one MAJOR point with it.  Scripted games are NEVER going to be as powerful or as diverse as a programmed game -- you simply cannot do everything in scripts.  Scripting engines (referred to as game engines most of the time here) will limit what you can do, no matter what.  TV3D is not meant just for games, in fact the majority of people using us do NOT make games, they make real-world applications that are deployed across thousands of sites.  Therefore TV3D was written from the ground up with this in mind, we did not want to make a point and click game maker -- that was never our goal, and explains why TV3D is not for you.

DS

[jviper]

People knock the modeler MED

MED? What's MED?? I never heard of a moddler named "MED". I tried to google it, but Mr Google thinks I'm talking about music and anatemy (although I did score a couple of pics of some .........................anatemy of the Fem......)

Anyways, just wondering what that was. Did you post a link?

[Zaknafein]

http://en.wikipedia.org/wiki/Gamestudio#The_model_editor_.28MED.29

[eloadrin]

People knock the modeler MED. Why? s it lacking? not really. It just lacks the 'auto click' features of high cost modelers like MAX.

Auto-Click Feature? You must be joking. I wish they had that, but trust me they don't. Of course they make things simpler, and are more powerful than smaller editors, but they all have the same functionalities in common.

it's just your have to do the work.

 You go download a trial of lightwave 3d, and tell me about all the auto-click features it has. This would be a nice one to here :wink:. For me, it was one of that hardest interfaces to get around. Also, let me know when the program did all the character modeling, textures, normal maps for you. If you find a high end software that does that let me know, I'll go buy it.

[Uglytruth]

Exactly the type my example shows. To load the exteral level, pass along variables be it stats, health or inventory items to do that in C++ would be a nightmare. Simply have the the ability to load the level geometry is merelt incidentel-you still need to have the level interact with the game.

Setting aside that persisting C++ objects (game state, levels, scene objects, etc) is not nearly as arduous as you make it out to be, you can't judge TV based on the capabilities of, or your comfort level with, C++. All of those tasks you mention are stupendously simple with managed code.

People get really religious about engines for some reason. It all boils down to requirements. If your team has no programmers, you'd be a complete fool to use TV, and you chose well when you decided to us A6. If, on the other hand, you need to produce something that's out of the scope of what A6 can do easily, TV gives you the power you need, and as VS is such a cushy development environment, you'd be a fool to try to force A6 to do something its designers didn't envision (or else, why didn't id, Unreal, and Valve simply use A6?).

A6 *is* a game engine. TV can be used to *build* a game engine (and one superior to A6). Depends on what you want to do.

[darqSHADOW]

Probably one of the best descriptions of TV vs anything I've seen yet, Ugly...  Good post.

DS

[Mixael]

Uglytruth, I agree with darqSHADOW, excellent description.  What I was trying to explain, though, is that even with the A6 engine, the OP will need a programmer, or someone that can learn the scripting language, to do anything but "point and click".  I've looked at some of the scripts in SED (that's the Script EDitor, by the way ), and they seem to me to be build similarly to VS .NET...at least SED looks to be a near clone IDE-wise.  

After looking at A6, I realized that it would take a greater effort (for me, anyway) to learn the engine than it would to continue to learn and use TV..even with learning C++ at the same time.  

Of course, I believe in trying to push myself to do things that I can't do, yet, just to learn and get better at the programming!

Uh, that's all.  (I bought my license for TV because I REALLY like it, not because it's better/worse than any other.  For my purposes, it's the best fit.  Your purposes may need something else...A6, Torque, Unreal, what ever.  Let the project and team be the guide, not what someone else says.)

Michael

[jviper]

programmers are under-rated

[BlindSide]

I used A5 for a little while before I started using TV exclusively, and when A6 came out I went ahead and tried that as well, as I wanted shaders.

A5/A6 is NICE. It is - I found it to be well made, it was fast to make game prototypes, all the tools were right at my finger tips, etc. Conitec's product serves its purpose well - to create an environment for non-programmers to be able to create their own games.

However, I quite quickly grew out of A5/A6. It just doesn't offer the flexability I needed. And honestly, if you're going to end up coding c++ plugins for it, why not just switch over to a full 3d Engine that offers greater speed, and a plethora of flexability?

Additionally, there are claims that finding a c++ coder is difficult. I guess this might be the case, somehow I never thought it would be, but fair enough - I can barely write in c++. But I can do just fine in Basic and C#. TrueVision offers the option of being able to write your app in almost any modern language - heck, you can even mix languages. So if you're having trouble finding a C++, consider perhapes looking for a C#/Basic coder (and there is absolutely NO shortage of those) - or even, perhapes, taking a stab at learning Visual Basic yourself (it's quite easy).

To sum things up, I have nice little comparison for everyone. A5/A6 is like the old QBasic microsoft brought in. It was designed to be easy for non-programmers to comprehend, and fast to write simple programs to get the job done with. A few adventurous people have even managed to create some pretty elaborate work with it, but that came with a lot of hacking/frustration. TrueVision3D on the other hand is more like C - sure, you needed to get your hands dirty and learn a not-as-friendly-as-qbasic language, but you got a serious upgrade in speed, better structured code, access to advanced programming concepts such as pointers, and the ability to access hardware. Oh, and you could compile to an EXE instead of running things all interpereted like =)

A5/A6 is nice for the new, solo developer. It's also great to prototype with. But for anyone into serious development - you'll need a 3D engine, not a game package. TrueVision is about the easiest 3D engine you'll find - consider it.

[Waterman]

... like the old QBasic microsoft brought in. It was designed to be easy for non-programmers to comprehend

Beginners All-purpose Symbolic Instruction Code...

While you are such a beginner, i on the other hand seem to be totally out of focus, just using A Programming Language (APL). Sounds like it was something i found on the street.

[Brac]

Hey Waterman, just out of interest. How on earth did you make TV work with APL and which interpreter are you using? Can you point me to some resources, i absoutely need to get something done with APL, all this managed code can get boring at times...

[Waterman]

Hmok, sorry for this side step in this discussion thread. Dyalog APL, www.dyalog.com.

Read the language features, especially about namespaces and objects, they are fairly informatively written.

It's basically about executing (typing by hand and pressing Enter, or running from code):

#USING = [assembly]

Then creating an object:
Instance = Class.New, or
Instance = OtherClassInstance.CreateSomething
(NOTE! No pre-definition of "Instance" needed, in fact nothing needs to be pre-defined - that's the "loose typing")

Then calling methods:
Instance.Render

Then the nice little things:
Instance1 Instance2 Instance3 = [created in whatever way]
(Instance1 Instance2 Instance3).Render

Or:
X = Instance1 Instance2 Instance3
X.Render

X,=Instance4    // Add Instance4 to the array of instances
X.Render

Or:
X = Class1 Class2 Class3
Instance = X.New // Create an array holding instances of different classes
Instances.ExecuteCommonMethod  // Execute for all instances a method that they all support

To be extreme:
Instances.Z = 5  // Can add identifiers anywhere; kind of adding properties. Now all instances "carry" a variable with the value 5

Then:
A = 1 + Instances.Z  // Now A holds an array with 3 elements: 6 6 6
A = Instances.(1 + Z)  // This would do the same

Or:
A = +/ Instances.Z  // The value of A is now 15 - the + was "scanned" over it's argument, effectively this was a loop executing.

A = +/ Instances.Z[1 2]  // This adds only the 2 first ones together, A now holds 10

And so on, probably bad and boring examples, too complex. Two warnings:
- High price
- Life time addiction