Rick

This is my early prototype of visually programming the Leadwerks Engine. Every LE function is fully mapped out dynamically thanks to the LE.NET DLL and the use of reflection. I modified LE.NET some to include method attributes that puts each method in a category based on the where they are in the wiki, then dynamically build the menu structure you see from those attributes. The program is in .NET 4.0 (if that wasn't obvious), but the resulting code that it'll generate could (in theory) be any of the supported LE languages. **The result triangle is wrong in that picture. It should be pointing down as to show the result is being pushed out from the method node and you can store it in a variable. Next on the blocks: - Make connectors functional - Make variable creation - Make some basic programming structure nodes (conditional/loop) - Make the code behind of the nodes Currently the canvas you see would be all inside the main function. After I get the above complete comes the truly interesting part of visually creating classes and your own methods. It's basically visual OOP with the LE library. I don't plan on implementing the .NET library this way as the code behind should be somewhat generic to most programming languages.

Do you know if there is a technique to let artists create the the styles for procedurally generated GUI's? Not sure if they make some sort of very basic scripting or something instead of hardcoding it.

I know you can skin Windows XP and earlier with images. Blinds I think is a name of some Windows skinning software where you specify images and offsets and such for the different aspects of windows.

I think the engine doing automatic loading is fine as long as it tells me about it in a callback Both load and unload (I want the actual entity before it gets unloaded in that callback so I can relate it back to the class object I'll have tied to it. that way I can tell that instance to chill until it's model gets loaded again)

Callbacks

I think we have two things going on. 1) Models loading automatically from an sbx file based on a camera value. 2) Users loading models themselves outside of an sbx file. For 1 I would love to have a callback that passes in the loaded entity that is on the same thread (or I can copy) for me to do what I want with. At that point it would be no different really then what we do today. We could read keys on that entity that were in the sbx file and decide what to do with it. 2 seems like it presents a different issue and a callback might not be the best way, unless we can maybe attach other data that will get passed to the callback with the entity once it's loaded so we know what loaded and when.

callbacks would be nice so we can know when a model is loaded. I always wrap LE models in my own classes because I wrap other variables and functionality with them and would need a way to know when a certain model got loaded. So I would need a callback that passes the loaded entity into it that I can then store in my class instance. If you can make that entity on the main thread by that time then even better but I need to know when and what model just got loaded by the engine. Why would it mater if it's static or animated? I would want animated models also.

I thought it obvious a better example would be WoW vs Starcraft. 2 different games by the same company using 2 different GUI designs. You've just listed sequels which makes sense that you'd keep the GUI the same as to not confuse customers. It's not about risk but consistency at that point.

Vector GUI's are just less extendable than image based. Normally they'll allow you to just a virtual draw method and make you do all the drawing for the look you want/need. Image based just has you setting some settings like the 9 images, offsets, etc which is much easier and in the hands of your artists which is where you want it. That being said if you know what you want for your game then use whatever you want. Just a shame it won't be all that reusable. I mean you can't have all your games looking the same GUI wise

What do you mean by activated? I assume updated is the entity update callback that is part of LE. If so that's not really what I meant. What I meant was to have the TModel loaded in thread B and when it's fired a callback in fired on thread A where the TModel is passed in so thread A could then do a simple and fast memory copy into an object that resides in thread A.

maybe callbacks when models are fully loaded from a loading thread and we can copy the data to our main thread which should be faster.

RakNet runs on another thread. You basically poll to see if any data is ready in your main loop, but it doesn't freeze your main loop. It's possible because you aren't doing anything LE specific in the RakNet thread. You are just passing data around. Once you have that data in your main LE thread you can then call LE specific functions. I don't know if RakNet works with BMax.

I don't understand what the fx is used for? Also when you add new models (triggers could be a model) it already gets a unique name. Why do you need this kind of naming convention. Knowing why might help us help you better.

There is irony in that statement somewhere

Fluids would be sweet. You would think there would be some common algorithms for different kinds of material breakage that they could use in their library. Like glass, concrete, wood, etc. This could at least give the users some base/most common stuff.

RakNet ftw The way I see it, if you are expecting anything short of buggy network code from LE 3 you are expecting to much. Much like Josh uses a physics library he would be wise to use a tried and proven networking library as well that has all these features in it already, or honestly better yet, we should just use said libraries ourselves

I don't think the animation tutorial is very good. It's pretty limiting as you've found out. I don't use fmodf() for animations. Instead I created a timer class and use the old 2D style of animation where you inc frame by a timer and if it's past the frame loop it back. Then to handle blending I personally just run Animate() on every registered animation (sort of). The difference would be the blend value. Most of the animations will have a blend of zero and pretty much only 2 animations would have a blend value when going from 1 to another. Other people store more of an active list of animations and play all the animations on the active list. That's the more efficient way but then you are managing that list, so for my demo's I just play everything I registered. So for example here is what I do in my player class that has the following animations Animations["idle"] = new Animation(this, "idle", 0.0F, 200.0F, true, 40); Animations["run"] = new Animation(this, "run", 322.0F, 341.0F, true, 40); Animations["jump"] = new Animation(this, "jump", 379.0F, 410.0F, false, 16); So now I've registered 3 animations with this player. I generally set "idle" as the active animation right away after initializing the animations. Each animation object has it's own blend value. Very important thing to note as when looking at the tutorials it only uses one so your brain might not be in that mode The Update() method of the Animation objects is called for every animation you registered every frame. What I do is right away say if blend <= 0.0 then just return right away to save time since there is no sense in trying to playing an animation with a 0 value blend. When you switch animations the idea is to start a process for the old animation object to start decreasing it's blend value which would most likely have been 1 since it was active and player. At the same time you tell the new animation to start increasing it's blend value. These decrease and increase is done at a given interval you see fit. Again I activate timers inside the animation object to increase/decrease every so often. Internally once the blend value reaches it's max/min it'll stop it's timer. Now you've just blended from 1 animation to the next. So when talking about managing a list of active animations I don't do it but you will notice that I will then have the overhead of each animation object calling it's Update(). Since I have a blend check right away and return the overhead is still pretty small, but if you managed an active animation list, you would be looping through less animation objects because you would be managing this list and adding/removing animation objects as they come in and out of having a blend value > 0. I just accept the overhead of calling every Update method as most get out really fast anyway.

I've played a little with UDK's Kismet and I've looked at Josh's implementation and since you extended that, do you plan on having multiple input/outputs and parameters? Not sure if you've messed with Kismet before but it's a nice base to go off of. At the time Josh's implementation didn't have these parameters but maybe you extended it to have this? Now you have me excited about doing my C++/LE flowgraph system again

So I seem to remember small bodies moving fast sometimes miss collisions. Are you finding that with this method?

I bet I can predict this for you now

Well, I'll try to get threads going again So I had this up right before the site went down and I know mumbles had a lengthy post about it and not sure if anyone else had comments. My idea around this is making a square in the center of the screen that changes size based on running/walking/etc. Then when firing bullets find random x & y values inside this square area and cast a ray out from that point into the 3D world to see where the bullet would hit. Other thoughts/ideas on how people do this?

I think I should have clarified my response. I mainly meant for the client character, it should control it's physics and send it back to the server. As far as world items, it's not done very often in multiplayer games and the reason is because it doesn't work very well. Like you said the server should control this, but the clients can also interact with it and the feedback the client would get if the server controlled everything is horrible and so it's generally why you don't see in games. You would need client side prediction on the physics but then the server would have to correct his data and sent the corrections back. Josh tried all this a few months back and the result was "bad" in my view. Unless you are neighbors with the server it's a pretty bad simulation. I seem to remember Josh thinking it was good for people close but realistically online games can't rely on that.

RakNet is just a networking library. You'll have to know C++ to get it working. If you know C++ then it's just a matter of linking it into your program and sending messages between client/server. I've used it before and I really like it. http://www.jenkinssoftware.com/ RakNet also now has C# so you could use that also. This is a very good networking library and has been used in commercial games. It's free for projects under $250k.

You can have the client do the physics and check for cheating on the server by checking abnormal numbers. I think Josh kind of proved when he was doing all his tests that doing physics all server side had some issues that in my book weren't acceptable.

LE has networking code but it's pretty sketchy. If I were you I'd use RakNet or SDL for networking. It's been tried and true.