Rick

Not override, complement. You would have 2 class scripts attached to the same game object. They could be doing completely different things. That is where you have to be careful though. In Josh's example in the first thread, that would be an example of something that would be an issue. He knows that so he's asking in a situation like this, what do we think would be the best action. If I attach 1 script that Joe Blow created and it moves the controller, and I attach another script that Mike Chang created and it also moves the controller, what should happen? Who wins that fight? Should 1 script win over the other, or should they both just run their Update() function and let whatever happens happen. My vote was to let them both run, and leave it up to the person making this object to realize what both scripts are doing.

It seems the fear some have is that you will or are, focus(ing) on 1 aspect of those 3 more than the other. I think you can do all 3 at the same time though. They all sort of flow together. The core API is strong enough as it stands (well once in C++ maybe) to support the other 2. The funny thing about that is that's exactly what flowgraphs do, and as long as the community can extend the flowgraph objects using Leadwerks code, it won't be gimped ever. You can make an entire unique game all with point and click via flowgraphs, and it in no way would be gimped. Flowgraphs are just logic. It doesn't matter if it's created by typing or visually. It's kind of like thinking that Visual Studio gimps making Windows UI because it has a visual interface as opposed to typing the code for all those controls out. It's just not true.

You are right. I can only talk about the direction it seems to be going today. Some won't be happy with that but some will. I'm sure Josh is well aware of that. No doubt it's a risk. Not saying it'll get there any time soon. I've never stated a timeline. It'll take a really long time, but that doesn't mean he shouldn't try. I haven't, but that doesn't mean I can't see trends. I don't wear/buy designer pants, but that doesn't mean I can't see the trend to what the "kids" are wearing these days. It seems rather clear that the trend is going more visual programming to make games. Programmers are still needed to extend the visual objects, but game studio's would rather have designers being able to use these visual objects to piece together logic for how a game works. I'm working with the same amount of information you are. I'm just looking at what Josh posts, and reading in between the lines like everyone has to. Josh says he's been in contact with people about getting capital. He's moving towards more platforms that are less powerful than PC's. Things like iPhone and such. This is much like Unity had done. It seems very obvious to me that if someone is going to put a bunch of money into Leadwerks, it has to be able to sell to the masses to make that money up and then some. You do that by making a very comprehensive editor because that becomes the face of your engine. The editor does need to sit on top of a very good API also though. So I'm taking all the fragmented forum posts that I see Josh make and form an opinion on the direction I see it going. I talk about those opinions, you get pissed and post against them. And so the world goes 'round. [EDIT] The things I've said about Josh's views on artists being the people who make games are things that he has said. He's made a blog about it in the past. I'm not making these things up. When you get this kind of information about what Josh is thinking and that this engine is a business, you can start to see why things are done the way they are or the way they will be. I'm not saying I'm dead on, but watch and see. It almost seems like a natural progression for an engine. He's switching it to C++. He went more towards scripting. My thought is it's no doubt he'll go more towards flowgraphs. It's the evolution and has been fun to watch. Every one of those things Josh started out against (or he made it seem that way), but eventually he learns about them, and since he thinks artists make games, and these things allow artists to do more, it's clear that becomes the path. I'm just extending the line with the information I have.

Exactly. Now just think about being able to attach more than 1 script to a model, and each script has an Update() method in it, and the engine is going to call one or both of these Update() methods for this model. That's the issue Josh is asking. Should it call both, or just 1 of them? My argument is both. Just to clear this up, today (and I know this is what you are saying) we put models into the editor palette. I get that this is how it works today. But take that out of your head for a second. Let's imagine you don't have access to any sort of int main(). Instead you just have what we'll call Game Objects. In Leadwerks terms these are basically just TPivots. They just have pos/rot/scale and that's basically it. Now you can attach multiple things to these Game Objects like models, sounds, scripts, particles, etc. So in your example here is what you would do. 1. Create a submarine model. 2. Create a script that acts on a game object that has submarine behavior to it. 3. Drag an empty game object into the editor palette. 4. Attach the submarine model to it. 5. Attach the submarine script you wrong to it. This would be the long way to do it. The more common way would be to just drag the model into the palette and a game object would be created for you automatically and the model attached to it. Then you attach your submarine script to that game object. It's important to separate out the idea of a game object vs a model and other assets, because a game object doesn't always have to be a model. It can just be logic. These are the basics around the "Thingoids". Logical entities instead of model based. Triggers, rotators, movers, etc. Things that don't have an in game visual aspect but run code instead. For example I've created Spawner objects. I attach a spawner to a trigger. When the trigger is hit it fires an output message to the spawner object. The spawner object receives this as input and runs code to dynamically instantiate some other game object, like a zombie or something.

Seems your view on what this can be is a not happy one Would you consider Crysis engine to be a lowest common denominator because that's what Leadwerks is leaning towards and most people would disagree that it is that. Hardly any engine would fill you with confidence then. The trend on game engines is to be the component based. You can have a component based engine and still be very very powerful and flexible.

You are sort of there. When dragging an object to the editor pallette you wouldn't want that to have it's own standalone class/script where you override methods. The reason is you generally will have multiple objects in your scene that are similar/same and should provide similar functionality. So if each was it's own standalone class/script you would be copying and pasting code to each objects class/script. So that's why you allow attaching scripts to the objects. Because you can attach the same script to all these objects so they can share the functionality. The ability to do this gives the functionality you talk about above, but it also allows for different functionality to be implemented as well. When a script (which is just a class definition) is attached, the engine will create an instance of the class inside the script and start calling the functions. So the user is defining the class and how it works, and the engine takes care of creating instances of that class.

Think of the existing object as a model in your scene. That object gets instantiated and along with it, the scripts that you attached to it also get instantiated. Now when the main engine loops through all objects in a scene, it also loops through all the instances of all the classes attached to it. Generally 1 script contains 1 class definition (in the Lua implementation today), so I'm using the term script/class in this case interchangeably. Well we are overriding script functions in todays Lua implementation when it comes to entities. That's probably the key thing to point out with this discussion. This would be scripts attached to entities instead of the stand alone scripts.

It's really no surprise Josh is going this route. He's said a number of times that he feels artists are the people who make games. Making a more user friendly, more efficient editor helps those artists put actual functionality into their games. It also helps programmers create more modular code that artists can plug and play because it puts a design around how these modular code pieces are to be created/used. It's an interface that programmers can follow to allow for easier sharing of functionality/code that all can use. Currently every program creates their own structure and so sharing code is not very streamlined. A common interface is required for that and it'll only be accepted if it comes from Josh because everyone accepts his design as officially supported.

By storing a list of base class pointers to an object. In C++ terms it would look like: class GameObject { public: list<LEScript*> scripts; }; class LEScript { public: virtual void Update(){} }; class Script1 : LEScript { public: virtual void Update(){ // script 1 logic } }; class Script2 : LEScript { public: virtual void Update() { // script 2 logic } }; GameObject obj1; obj1.scripts.push_back(new Script1()); obj1.scripts.push_back(new Script2()); // now you look through all the scripts attached to obj1 and call the Update() method. This will call Script1 class and Script2 class Update() method. Script1 & Script2 would be defined by us in Lua files. Object/Entity scripts contain class definitions. That's how the current LUA implementation works. Although currently you can only have 1 Lua script per object (entity). What Josh is saying is that you can attach any number of Lua scripts to objects. You are correct in how it's implemented today. Josh is asking about how it'll be implemented tomorrow.

Simple drag and drop will allow more people to put substance behind their pretty screenshots easier and faster. That 1% is a never ending thing and is different if you ask people what they think it is. Every engine out there today still has that 1% that stays around. Sometimes that 1% can be "fixed" by adding tools around it to mask it.

This isn't really an option in this situation. He's talking about 2 completely different scripts (classes) attached to an object. In each script you are already overriding the Update() method. It just so happens that you have 2 scripts that both override the Update() method. Both scripts Update() method are going to be called by the engine. Josh just wants to know in the case that multiple scripts are trying to affect the same thing, what should happen. So there is no base method you can call. Both scripts are at the same level. No net change seems to be the more logical and less confusing way to handle this. Both scripts Update() will be called. It's up to the programmers to know the scripts attached to their objects and what it's doing. You wouldn't have to learn a new language behaviour. You just have to think about how this works differently. Netting the rotation value would give the same behaviour in C++. What's happening is the following: There is a base class, let's call this LEScript. It has a public virtual function called Update(). Each script you create derives from LEScript and allows you to overwrite the Update() method in which the engine will call automatically each cycle. If you have 2 separate scripts and you attach both to an object, then naturally the engine will call both scripts Update() function for that object. This would be how C++ would do it also. The scripts are just classes derived from another class. If in your object you stored both of your subclasses, the engine would cycle through all these subclasses stored with that model and call their Update() method.

Very cool man. Exciting!

Can't view this from where I am, but did you figure out how to get a collision callback for bodies that were created inside the editor?

I've been a fan of actually trying to merge the editor/engine executable files into 1. As soon as I seen 2 separate executables I knew there would be problems between the 2. I think finding some way to have them one and the same would be ideal. The code that runs the actual Leadwerks part should be separated from the editor UI so if we want to run as an official game it completely ignores the UI and just starts up the Leadwerks part. Would just need to make sure that when the game is released there isn't an easy way to just bring up the editor. I guess the other way would be to place all the Leadwerks processing between the 2 in a DLL and have both editor/engine share the 1 DLL so we know the code running the Leadwerk parts is exactly the same.

I never said to use Blender. I'm 100% against using Blender in any way actually. You must be mistaking me with Pancakes. Please don't talk about me not making sense when you haven't read the posts in this thread to see who stands where. "Hello kettle, this is pot, yeah you're black." Well at least we both are consistent with our views even if they are different. Is it really that hard to see that we have the same end goal, but we want to reach that goal in different ways? You think your way is right and I think mine is right. At least let's respect the fact that we both want the same thing. We just think differently on how to get that. I think it's about building better tools to surround/complement the existing API. You think the existing API isn't sufficient enough and tools should be considered after changes to the API. I feel like it's OK that we have different views, but we should probably try to stick to the views only.

We already know where this road goes so let's not go down it again.

Creating new things is what makes the world exciting. What Josh makes might end up being better than what is out there. That's the best part about software. Innovation can/will happen and it doesn't always require a large staff. Sometimes it just needs a new amazing design. The amount of change that Josh would need to do to Blender to make it the way he wants would basically be not much different than coding one himself. At least with coding there would never be any restrictions that always comes when editing another piece of software to be the way you want it.

Think of the programmers who just want to make a game too. We don't care about nitpicking the models. We want them to look somewhat decent, but we just want them in a format that we can use. I don't want to spend hours over conversions and screwing around with mat files. I'd rather spend my hours over making the logic of the game, because in my programmer mind, that's more important. From an artist stand point I can see where they might want to make sure everything looks absolutely perfect though.

I think this is what you get when a game engine evolves. I personally think trying to make your own engine from Leadwerks for the purpose of specifically making a game you have in mind at this stage is like trying to hit a moving target. I think you'd be better off picking a version and sticking with it (bugs and all) or this will be never ending for you. Either that or the design of your engine needs to be really separated from how Leadwerks does things. ie, not relying on Leadwerks with ini, Lua, etc and basically just using it's core API features that are related to graphics, input, & physics.

I think the problem that faces this is making the software be easy and functional at the same time for everyone. Adding all features into one exe is great, but if it's complicated to use, like I would argue Blender is, then it defeats the purpose of making the flow more productive. That may seem obvious but getting a good interface to do all of this in a manner that is natural for most people is tough. Again, Blender is a good example. It's clearly aimed at modelers, but over the years level designers have grown to expect something different. Some problems that arise is that from my understanding Blender started out as a modeling tool. Because of that the mentality of modelers and what they like in an interface generally isn't the same as level designers and what they like. Because of this, Blender's interface is more geared towards modelers than level designers. So if you are more comfortable with level design in tools like Leadwerks editor, Hammer, or 3DWS, you look at Blender and just think it makes no sense. The reverse is true also. Because these roles were separated out for so long, the tools built around the roles have taken different paths with common different interfaces. Most people lean towards one common interface than another, and when they need to change, it's hard to want to do that. Especially if you aren't getting paid to, ie indie/hobby game devs. So I shy away from Blender because it doesn't work like a normal level editing program but more like a 3D modeling program. Don't get me wrong, if I was getting paid I'd be all over learning it

I really think they have to convert. I can't count how many hours I've spent converting models manually from whatever format to gmf. It's such a pain in the work flow. You'd still have the ability to do it manually if you liked, but when I buy my models from Dexsoft that aren't/weren't convert to gmf already I would have to manually do that and it was a process that could have been automated already in LE editor. I did nothing special when converting. Note, that I'm just talking about the model and not materials. LE could make default material files that we can alter if need be after the fact.

1. Being able to drag many different model formats into the editor and having it automatically convert to gmf behind the scenes would be nice. 2. Being able to create prefabs. 3. Being able to have multiple scripts attached to game objects. 4. Not having to shut down the editor to see new things.

Hey, I'm just giving you reasons as to why people are not going head over heals for Blender as a game engine and instead love things like Crytek. If Blender doesn't accept these reasons, then it explains why they aren't looked at as a major game engine by most people. Software vendors don't last very long if they ignore the reality even if to them the reality doesn't make sense. Congrats, you have time to burn. Most people, however, are looking for certain things when they open an editor and when they are presented with something completely different, they realize that learning this piece of software will probably be a big chore and choose another piece of software. There is no doubt in my mind that Blender can do everything very well and can be used as a game engine, but much like a book, if the first few pages don't get your attention you aren't going to read it. If a person can't do something simple in the first 30 mins without reading docs, they probably aren't going to bother. I think Josh knows this which is why in LE getting a rotating cube on screen is fast and simple and most everyone gets there in 30 mins or less. Obviously a rotating cube is pretty worthless, but it's something and it's quick and easy and it keeps you coming back for more. Here is my first experience with Blender. 1) Open it up. I see a square on the screen. My first thought is, "I thought this was a 3D modeling program. Where is the 3D view? I'm expecting to see Top/Left/Front/3D view of this cube" 2) Change the view to 3D. Right click to try and rotate the camera, something that is pretty standard in game engine editors, but doesn't work that way in Blender. Left click, use wsad keys. Nothing. Well wtf. I have to read docs to figure out how to move the camera around this cube? Very lame. 3) I want to select this cube in 3D. I left click it but some sight is moving around. Left click and drag and it makes a line but doesn't look like it's highlighting the cube. I'd continue but I have to make some food. *sigh*

Not really. For some things most programmers find it easier to start from scratch with your own design than to have to use someone elses. And I mean the programming interface that Josh would have to use to modify Blender. It would probably take him more time to learn all that than to just make his own. I'd say it's not brilliant. To me a brilliant interface doesn't scare you off when you first look at it. It has nothing to do with it being new either. There are many programs out there that are very inviting and powerful. Blender is powerful but not inviting. 2 for 2 is the only way the word brilliant should be used. Because humans are complex. Sure as a programmer I can tweak an animation, but then the animator hears about it and now he's pissed. Also, I doubt it's ever as easy as just removing 10 frames. I'm going to need to know certain things about animation, but I spend all my time perfecting my programming skill so I don't know much about animation. So in a AAA game studio, would you want a programmer making those changes? No. You would want your animator doing that because that's his skill and there might be more things to think about than just taking 10 frames out.

It gets ignored for a few reasons. 1. The Blender interface is horrible. People look at it and run away. This is the very first hurdle to get over. 2. When making a game with other people, generally you have roles like level designer, animator, modeler, programmer, sound guy, etc. These people have industry standard tools to do their work and most aren't Blender. So they prefer to use what they know. Also the ability to edit anything game related in Blender is cool, but generally when your level designer is building a level, he's not an animator and so he'll never tweak an animation. Your modeler isn't a level designer and so they just make models. Etc. That's generally why your level design is separated out from your modeling. 3. The blender interface is horrible. Sorry, but it's the truth. It may be functional and amazing once you dig into it, but people have to get past the overwhelming feeling of when they first open it up, and honestly most don't. It's all about first impressions. And the first time you open Blender you have no clue what you are looking at. 4. Those screenshots they have under game engine aren't helping them either. They don't look that impressive.