Leadwerks needs tools like this...

[Rick]

I'm saying remove it from the "core api" and instead bring it to Leadwerks via the toolsets which are created from the Leadwerks core api. Clearly it's needed, but where it resides is the question. Should decent looking water really be part of the core api? We clearly differ here. I think it shouldn't be part of the C++ api. Water is a game specific thing. Putting it in the api wouldn't make sense, since the api is used to build game specific things. It belongs in the toolsets because water would be created from the api. Same with pathfinding.

[cocopino]

@ Red Ocktober:

As I understand you're making a submarine game so water is probably a big concern

Over here: http://developer.leadwerks.com/SDK/ you can still download version 2.24, I believe all the old (Blitzmax) water code is in the BMX/Framewerk directory.

[Guest Red Ocktober]

I'm saying remove it from the "core api" and instead bring it to Leadwerks via the toolsets which are created from the Leadwerks core api. Clearly it's needed, but where it resides is the question. Should decent looking water really be part of the core api? We clearly differ here. I think it shouldn't be part of the C++ api. Water is a game specific thing. Putting it in the api wouldn't make sense, since the api is used to build game specific things. It belongs in the toolsets because water would be created from the api

 

what friggin toolsets... there aint no toolsets.... they have to be created... then tested... and ya don't have to bring it into leadwerks... it was already in there (see tutorial on water if ya don't believe me)... just put it back...

 

hullllooooooo.... haven't ya been listening all this time...

 

 

i don't care how he implements it... i don't care wether it's in the core api, outside the core api... in a script... in an externall dll, or borrowed from steven jobs... just implement it... give us back some decent water and give us back the bullet holes...

 

so we don't have to spend another month or two doing it ourselves...

 

[added]

hey there coco...

 

yeah... did that already... only to have the thing fail on me time and time again... there seems to be some issues using multiple version on the same system...

 

i have been thinking of reverting entirely to the old code though... until the latest stuff finds which road it wants to travel...

 

i'm gonna give josh a lil more time though... and LW isn't my only option... i've got the sub thing working in torque and 3drad...

 

--Mike

[Rick]

What evidence do you have for making such a statement? The exact point I'm trying to make is that this is not currently known and proven without doubt. What type of game are you referring to? Are you including all game genres in here! No one has pushed this engine yet and I don't buy those sorts of statements!

 

I don't disagree with you, but it's my view that the reason isn't the API. It's the lack of tools around it, and honestly you can look at the other engines to prove that statement. The other engines that have AAA games made, have many tools that complement the engine. So since UDK hasn't produced a game without their tools to aid in that production, it seems logical that the toolsets could be the reason for that engines ability to produce complete games. Nobody is programming games from scratch with a core api anymore. They build tools first, like I think you have done, around api's, OR you use something like UDK that did all that already for you. Leadwerks's API is a state of having to build tools to help aid your game dev, but that's the stuff that Josh should be doing. He should be making the tools to help us make the games.

 

I want what you want. I want the tools to make a finished game. It just sucks that Josh's vision to do this started out differently than the way most every modern engine that games are made with do it.

 

 

It seems the issue you have is that you were told LE was one thing, and now it's changing and you don't like that. That's no doubt what will happen to the existing customers of LE. I know Josh says all 3 aspects will be equal, but there will be points where he works on one, where the coding people will get pissed, then the other where the scripts get pissed. Having these 2 ways of doing something is a task that I don't think can stand. It gets messy that way. Just look at Torque. C++ vs scripting and it's just a messy system.

[Rick]

i don't care how he implements it... i don't care wether it's in the core api, outside the core api... in a script... in an externall dll, or borrowed from steven jobs... just implement it... give us back some decent water and give us back the bullet holes...

 

3.0 will do that. It'll just take time I know he had this other stuff in there, but sometimes it not just as easy as dropping it back in. He might have changed things behind the scenes to make implementing some of these a little different and time consuming.

[cocopino]

I know Josh says all 3 aspects will be equal, but there will be points where he works on one, where the coding people will get pissed, then the other where the scripts get pissed. Having these 2 ways of doing something is a task that I don't think can stand. It gets messy that way.

 

I disagree about it being messy per se. I think scripting can make code leaner/cleaner: Leadwerks is an entity based engine and now entities can have their own customized scripts. I think that's all it should be used for, at least that's all I'm gonna use it for.

[Guest Red Ocktober]

It seems the issue you have is that you were told LE was one thing, and now it's changing and you don't like that.

now you're starting to see the picture... the light bulb has been turned on

 

not only was i told one thing... i had that one thing in my habnds... and was off and running... with it... then the world changed without warning... flat water... no refractions...

 

but we did get underwater caustics... so... i waited for things to improve... and i waited... and, well...

 

but it's not just the water... all of a sudden, existing code wouldn't work... come to find that functions were either eliminated or renamed.... enitre modules renamed... without warning...

 

now lua... ok, i can live with it... it's just another coding syntax... embrace it... why not...

 

but now you guys are coming up with all this quest3d like point and click to join the lines and boxes type ****... this is not what i bought in for... never did i forsee this stuff... if i wanted this i would've licensed quest3d years ago...

 

 

Just look at Torque. C++ vs scripting and it's just a messy system.

i have looked at torque... i have a license for a few of there tools... as a matter of fact, i'm concurrently developing the sub thingee in Torque (see below)...

 

 

 

it's not messy at all... at least not from the perspective you seem to be looking at it from... everything in the torque api can be accessed from script, but since torque came from a first person shooter engine that powered the old tribes, if you want to do something outside that vein, you're gonna need to mod the engine code... otherwise, scripting is sufficient...

 

i like Leadwerks lighting... that's the hook for me... Josh has done a real decent job with his deferred rendering algoritms as applied to the lw rederer... all this lua diversion is, in my opinion, a diversion...

 

but hey... he's the man with the vision... and i'm, by choice, along for the ride...

 

but that doesn't mean i can't bug the hell outta him every now and then...

 

 

--Mike

[Rick]

I agree the scripting side will be nice and clean and structured. I'm saying trying to manage both the C++ api and the scripting stuff can get messy for Josh to do. It probably would have just been better if he just had the scripting stuff to start with and the API supported that and that's what he exposed to people. Kind of like most the engines do today. Generally they only expose the scripting side of things you their users. Leadwerks is unique that way, but I have to wonder if most engines do that for a reason.

[cocopino]

What strikes me most after my absence, reading several threads here is that so many people are using Lua as the predominant language...

Do they have access to other tools than I have or are they just not used to having an IDE?

[Rick]

now you're starting to see the picture... the light bulb has been turned on

 

I get it, but I can't understand why you guys thought that way. Leadwerks just can't stay as an API. That seemed obvious to me after trying out other engines. If it wants to survive it has to go beyond the API, and there is no doubt in my mind that at some point, even though Josh says otherwise, it'll be all about the scripting structure for Leadwerks much like it's all about scripting for UDK, Unity, and Torque. I think it's the evolution of a game engine. It just seems inevitable.

 

I thought Torque's scripting structure was horrible (although it's been 3 years since I've playing with my version I bought). I know I hear that often on these boards too when a comparison thread pops up. The way Unity does it's scripting structure seems to flow much better.

[Rick]

What strikes me most after my absence, reading several threads here is that so many people are using Lua as the predominant language...

Do they have access to other tools than I have or are they just not used to having an IDE?

 

It allows for faster development since you don't have to compile. Just hit the run button and see your code at work. Press the stop button, make a tweak, and press play again. Your code is now running again and it only took about 2 seconds. Plus it allows for some kind of structure of objects. In C++/BMax generally people don't create things to be reused even though it's ideal for reusability. I'm not really a fan of Lua, but I do prefer not having to recompile every time I want to test a change. Although I miss being able to step through code. Ideal situation would be a scripting language where I could step through it line by line like I can in an IDE. Lua can do that in certain editors, but not with how it's implemented into LE.

[cocopino]

"It allows for faster development since you don't have to compile. Just hit the run button and see your code at work."

 

Well, I'm used to typing 30+ sentences at once when programming before hitting the run button but this will 9 times out of 10 result in an Editor crash

[Rick]

 

It is strange how it does kind of change how you program. When you know it takes no time at all to test something small you are more prone to run after every little small change you make it seems. At least I've seen that happen with me. That can be good and bad I guess.

[Pixel Perfect]

I don't disagree with you, but it's my view that the reason isn't the API. It's the lack of tools around it, and honestly you can look at the other engines to prove that statement. The other engines that have AAA games made, have many tools that complement the engine. So since UDK hasn't produced a game without their tools to aid in that production, it seems logical that the toolsets could be the reason for that engines ability to produce complete games. Nobody is programming games from scratch with a core api anymore. They build tools first, like I think you have done, around api's, OR you use something like UDK that did all that already for you. Leadwerks's API is a state of having to build tools to help aid your game dev, but that's the stuff that Josh should be doing. He should be making the tools to help us make the games.

Tools aid productivity; they do not prevent you from making a game. So long as you have a solid core API then all is well. It may take longer, you may have to develop the tools you need if they are not already provided, but it all rests on a solid foundation.

 

All I'm saying is, I don't want to wait for Josh's future toolsets and even if I did they might not prove to be suitable for what I want to do. So I'm quite happy to invest the time to build my own tools tailored to my particular requirements. I may be in the minority but I bought the engine in good faith and nothing in the EULA said I was required to only walk the path that Josh laid!

 

But if I'm to put that work in I want to be sure if I hit problems with the API then I will get support from the Developer. What if I find for example that the line picks are way to slow and inefficient once I have a fully populated interactive game world up and running, if I log that or add it as a request that it is not going to sit there ignored because it doesn't impact directly on the current development drive for a future product version.

 

Change really does not bother me, in our industry we are constantly immersed in change. Josh can take the engine where ever he likes as far as I'm concerned so long as he maintains and supports that core API. From my point of view that is the engine's strength and that's what I've invested in. But I believe it inevitably will be found wanting in some areas as people start to push the engine more.

 

I'm not going to say any more on this matter because I really think I have expressed my concerns clearly enough. All I'm asking for is clarification that if I run into a potential show stopper somewhere down the line regarding the API the developer will respond to that in a timely manner. That will allow me to justify putting the effort in that's required at this point of my development.

[Josh]

I'm not sure why people think Leadwerks 3.0 will only be programmatic or point and click. It won't be just me working on it. I will probably end up writing very little of the code, and spend most of my time instead documenting how I want the programmers to write it.

 

When you see how it works, I think you will understand how the programming, script, and design mode work together. There's the step of programming game behavior, but there is also game production, where you are setting up interactions that are unique to one level. That's a stage we haven't really gotten to, and this will make it easier to achieve that, without taking away your freedom to focus on more basic aspects.

[ConradAlistair]

if the engine is strong in all aspects, than most anyone will be comfortable getting started on a project. and from what i can tell, thats part of what josh plans.