Josh

I promise we are not gimping the engine to make a point and click game maker. The plan I have designed makes the engine easier and better for both programmers and non-programmers, and it allows them to work together. C++ programmers will still be able to write their games. Script programmers will be able to create reusable components designers can use. Designers will be able to drag and drop parts to make a game. It's about designing a cost-efficient workflow for groups of people to produce games, instead of making a game engine for idiots. Typically you would have one or two programmers designing the basic game, a handful of script programmers designing components, and a lot of designers making the game levels. John Carmack doesn't program every single monster scare in Doom 3. He just provided the basic framework, and the level designers planned the action.

That's correct.

shaders.pak\postfilters\ssao.frag.

It's been done: http://leadwerks.com/werkspace/index.php?/topic/730-video-to-texture-via-libtheoraplayer/page__p__6458__hl__theora__fromsearch__1entry6458

Adjust the "General>Order" property of each road to control what order they are drawn in. Use the "Road>Terminate" property to make them blend smoothly.

http://www.leadwerks.com/wiki/index.php?title=TFormPoint

This includes a beta of Dave Lee's the Zone scene: http://leadwerks.com/werkspace/index.php?/topic/2065-lesdk-232-r5-link/ I had to use an alternative download method due to the problems we have had recently with large downloads.

http://www.leadwerks.com/sync/engine2.3/LESDK2.32r5.exe Enter your registration key for BOTH the user name and password.

Unless you post a program that demonstrates the problem, we're all just speculating about what the problem might be.

I'm not working on version 3.0 yet. I want feedback now so I can plan the tools for 3.0. I am working on version 2.32r5 right now.

If the vertex sway effect is used, the vertex color will not be visible in the pixel color.

That's the same as what I wrote above.

How would you suggest doing that? Something like this?: function object:Update() if self.super~=nil then if self.super.Update~=nil then self.super:Update() end end self.entity:Turn(1,0,0) end It seems like the "code blocks" paradigm really has nothing to do with C++ inheritance.

If we have multiple scripts attached to a single entity, should redundant functions override previously declared ones, or should the functions be executed in sequence? Example of two scripts attached to an entity, in order: function object:Update() self.entity:Turn(1,0,0) end function object:Update() self.entity:Turn(-1,0,0) end

I think we can satisfy both groups. By providing more high-level structure, we can help programmers to make scripts and programs that the rest of the community can use.

It's trivial to add horizontal displacement to the terrain shader. I tried it before, but didn't see anything amazing. I think what you are mostly seeing in the above shot is a nice rock texture, and a little displacement along the normal improves the effect.

This might help: http://blog.wolfire.com/2009/06/cliff-rocks/

Once we are able to start in earnest, I will have a better answer than that. There's a lot of groundwork to prepare.

I would make a wide flat rock model and just align it to the cliff. Crysis used this technique, and the results are good.

This is a quick blog to fill you in on some of the features planned for Leadwerks Engine 3.0. -Any entity can be a physics body. The body command set will become general entity commands, i.e. Entity.SetVelocity(). You can make an entity physically interactive with Entity.SetShape( shape ). -Any entity can have any number of scripts attached to it. The basic model script functions will be supported for all entities, plus specialized script functions for certain entities. For example, particle emitters will have an optional script function that is called when a particle is reset. This could be used to make a fire emitter "burn" a mesh. Script functions are called in sequence, so you can attach a chain of scripts to an entity to combine behaviors. -Prefabs will be supported, with the ability to drag entities together to make a hierarchy, add lights, emitters, and other entities, attach scripts, and then save a prefab. -Record screenshots and movies from the editor! -Tons of scripted behavior you can attach to your own models, and lots of scripted assets you can download. Basic AI features will be supplied. -The editor is being designed so you only need a mouse to make games. If you want to script or program or make artwork you can, but at the simplest level, the whole workflow can be controlled in the editor, with reloading assets, automated imports, and lots of drag-and-drop functionality. That's all for now. I can't tell you some of the coolest features, but this gives you an idea of where we are headed.

I agree that the quality of the conversion and features may suffer, but this is something the overwhelming majority want, not just Rick. So the trick is to give the public what they want, without letting them hurt themselves. The best way to think of it is to assume the user does not have a keyboard, and can not run Windows Explorer. Then you understand what they generally want, in terms of ease of use. This isn't so much the current user base, but the "designers" and beginners that we expect to join later on. If we can also streamline the workflow for the professionals and save them time, then that's great.

I would like to hear more about specific features and workflow you guys want, instead of the merits and problems of specific software. I will be basing the version 3.0 workflow heavily on user input, and a good discussion of what you want will help me a lot. Thanks!

The project wizard will create a LEO project for you automatically.

Since scaling is not support by the physics system, collision won't work properly if you scale an object. I am adding a new geometry type based on the CSG brushes used in 3D World Studio, and it will be better for triggers and zones.