Josh

I'm trying to stay away from anything that isn't cross-platform (especially given that MS thinks all windowed programs are now "legacy apps"). The future of Windows looks very uncertain, and now more than ever I would avoid becoming dependent on any one desktop OS. Just read this article to get an idea of what they are thinking: http://blogs.msdn.co...experience.aspx

Of course. If no shader is explicitly assigned, the engine chooses one for you based on textures and animation properties.

After putting together a pretty complete model of how the logic editor would work, I found myself unsatisfied with the properties dialog. I originally intended to make a standard properties dialog that opened in a separate window, with "OK", "Cancel", and "Apply" buttons. However, the logic editor and properties dialog were both being opened in separate windows that were a child of the main window, with no strict draw order between the two of them. I found it confusing to select an entity in the logic editor, and then have to go to a separate window to modify its properties. I tried moving the properties dialog into the scene browser panel, in the side panel on the right. There was a nice big empty space for it, and it looks appropriate. Normally I do not like interfaces like this because it means the data has to be continuously synced even when you are just editing in the viewports. However, with some clever coding that keeps performance in mind, I think I can get around this problem. It certainly feels a lot simpler to work with. With this many features in the editor, I want to be careful to retain the intuitiveness of programs like 3D World Studio, Property groups are separated by tabs, which I find to be a lot easier to use than a big vertical stack of properties as high as the screen. It also makes editing faster because I only have to fill in the values of the currently visible properties tab. I think it also makes sense to open assets in their own window, while modifying object properties in the property dialog embedded in the main window. You will spend more time modifying object properties while editing. Assets are something that only need to be adjusted once in a while, because they should be left alone and reused many times. The whole properties interface is a class that lets you build an interface, without actually knowing what each control does. The editor entity class has functions to get and set property strings, which can include position, rotation, and other basic stuff. It's quite nice because it allows me to add lots of new properties without having to hard-code any dialogs.

I never thought about it, but you can even do insane things like plug other engines into Leadwerks3D. For example, you could make a Blitz3DSDK-based renderer for it!

Yes, the script debugger in Leadwerks3D is very good.

OpenGLES 2.0

I should have described that better: "mobile graphics that don't suck". I hadn't thought of that, but it might be a good shortcut to get the best of both. It sounds crazy but it would actually work, without requiring two copies of all meshes.

The basic renderer is supposed to have graphics around the level of Source Engine. That will be our baseline, across the board.

That's correct, but at the same time Leadwerks3D offers much better support for C++ programming. The documentation is all C++, it uses proper classes and syntax, and has much better debugging. I think this is important so that beginners have somewhere to graduate to after they master the basics. It also ensures we have a shot with the professional studios. Other engines that didn't offer direct C++ programming flopped with console developers. You have three levels you can work at with Leadwerks3D: -Synapse (No programming) -Script (basic programming) -C++ (low-level programming) These aren't mutually exclusive, since they all work together. In fact, teams of people can work at different levels on the same project together. The C++ programmer would write the basic game structure, while the script programmer would write special gameplay scripts and expose functions to be called in Synapse. The level designer would build the scenery and connect objects together to create sequences of events and control the flow of gameplay.

I thought everyone, for the last three years, was complaining about wanting a better art pipeline and more gameplay support? How many times have I heard "Leadwerks is a graphics engine, not a game engine"? Since I have to do it anyways, mobile makes a good stepping stone to get those features into place, and then we can just scale up the renderer. Most of the new rendering features are already researched, and the engine is being designed to be extremely scalable. If you start your game when Leadwerks3D is released, you'll be able to upgrade the engine in the future, and the rendering will be upgraded. This community needs to focus more on game making, anyways. It could be a good thing for us. I'm pretty happy about the prospect of how the new features support gameplay mechanics. In the past, it was left entirely up to the end user to implement a system of their own. Soon we'll have a system in place that lets us made plug-and-play interactive objects.

It's like Kismet, but more usable IMO. I always found Kismet to be bewildering.

Dynamic navmesh pathfinding, multiple scripts attached to any entity, and "Synapse" the visual logic editor. This creates a framework for game interactions that is very easy to make plug and play components for. You can conceivably make a game with this, with no programming at all, but it doesn't retard the capabilities of what a good coder can do with it. I wouldn't have been happy making a fenced-in game maker type thing.

Totally agree. MC3 is pretty much unplayable. I think Apple is going to come out with a living room product that comes with a GamePad, and all the control issues will go away. It's pretty easy to program mouse controls for PC, and then touch for mobile. To balance it out, you'll probably have to make the damage enemies do much less for the mobile build, or something like that, but you can get one game playing on both.

At some point, all the graphical capabilities of LE2 and more will be rolled into Leadwerks3D. It takes a lot of time to make a visual game editor. And there will be two interns as of June 1. :

Most mobile games are still really horrible quality. 3D games are actually still very rare. It's a sweet spot where most indies won't put the effort in to make a good game, and most pro studios aren't dipping in yet. You are right that if you want to make a really lousy game, it won't make you rich. If you make a decent game on mobile, it will by default be in the top ten, since there aren't very many good ones.

Yes.

You can't make a 3D engine nowadays and not support mobile. That would be ignoring 90% of indie devs. The best I can do is use sales of the mobile licenses to support development of the high-end features. That's likely to be possible in the future.

If you're serious about making games, mobile is where all the opportunity is. You can release an okayish game on PC and you won't even be able to give it away. Release the same game for mobile and you're a superstar. I'm still building the engine to be scalable, because I want to return to high-end PC graphics, but trying to make a business on that alone will fail.

That's the plan.

The point of Leadwerks3D is to make a game engine with a really easy to use editor, a framework for game interactions, and support for mobile. I already know how to do high-end graphics, and they can be added on later, but a good foundation has to be in place first. I don't want to make another high-end renderer only a few people can use.

It doesn't matter how well you know 3ds max. It's still more mouse clicks to do the same thing.

For the record, "hybrid" forward-deferred rendering is not "modern". It's a half-baked technique for slow hardware. For rendering, we're focusing on mobile-level graphics across all platforms for the initial release, since the art pipeline and gameplay features are the real point of the new software. That was something I misunderestimated the importance of in LE2.

Okay, so I think we have established this is going to be a competitive advantage for Leadwerks. I counted 5 smileys in one post. XD

I found a way to make it really obvious which object is which. Selection in the scene tree, viewports, and logic editor is always consistent.

All those calls to glEnableClientState() should have a corresponding call to glDisableClientState after the call to glDrawArrays().