Rick

Wow. See this is what I'm talking about. Freaking shaders. I really don't want to learn you!

How's local test = objecttable[model].class.name Notify(test) Where model is from the one being passed to CreateObject()

I get where you are going and I see it often in AAA games. I was looking through the WoW data files and was looking at the animation names and you see stuff like Attack1, Attack2, etc. and all the models are based off that. That's valid.

Are you going for creepy? Most of your art has a creepy dark side to it from what I noticed. The character you describe that you want doesn't seem to be creepy at all though. I love your art btw. You are very talented. God I wish I could draw

The problem is not having client-side prediction is basically not even an option. The games of today all use it and players expect instant feedback in any sort of game that requires it, ie FPS, RPG, etc. Something like an RTS you can hide it in various ways though. This is often why when you give an order to a unit it says something or plays an animation like a solute before it actually does the task. To get it working correctly, you would need to use extrapolation for the other players on your client screen. Since you don't just want to set those players to the position when you get an update from the server, you want each client to guess where the other players are going based on where they were going before you got your last update. Then, when you get an update you see how far off is this player locally from where the server just said it was. That's where you interpolate between those 2 locations to smoothly move from where that player is to where the server says that player is over a few frames. At one point player WoW I had 2 accounts. I would open up 2 windows and would put one toon on follow from another. I could see this happening. On one of my machines I would stop running and locally it was instant, when I look at the other machine you could see it catching up and interpolating to get from where it was to where the server said the other toon was. It was pretty interesting to see actually.

hmm, I think the issue is that the settings dialog will be the same for them all though. The InitDialog() runs the same for all instances. So if you wanted to have a character that had a different animation name than another character you couldn't. I guess I was thinking that the xml file would describe animations for that given instance of the character thingoid instead of being a file that describes how the settings dialog box should look. In this case I get the fact that it wouldn't be the easiest because instead of settings in the dialog box they need to edit an xml file, BUT, follow me on my journey of thinking just now, I wonder if we could have the properties from the editor shell out to a custom exe that we create that makes editing the xml file easier. It could be a small little properties window that is more flexible in adding animations to the xml file. The result would be the xml file that the user selects into the editor settings dialog. [edit] Then in the setkey method, when the xml file gets selected, you parse it out and store the information in a lua table variable to that object. I'm curious to hear where you are going with this more though.

I actually agree. No one in their right mind buys a mac and thinks "This is going to be a killer gaming machine". Maybe it would be if people actually made games for it.

No, but when you say it, it sounds so pretty

Does this mean I get your other character model

Let's brainstorm! serious vs humorous the bomb dropped last week vs the bomb dropped 2 years ago male vs female badass vs normal vs clumsy vs arrogant vs angry family oriented vs loner I feel once you start to shape the personality of a character they start to come alive inside you. You start to get a picture for what they would look like.

This reminds me of a cool debugging feature you could implement into the network commands. Simulate lag.

Reliance, being the key word. Given the option for both and everyone is happy. The problem is most of the time you have level designers making maps that are using some stuff from modelers. Level designers aren't supposed to be true modelers. They are supposed to be more focused on the flow of a level.

You know, I think we could make a crude CSG implementation with lua alone.

Yeah, it wasn't something I was thinking about until I made my cube and it swallowed my editor model and I couldn't select it to move the cube around

Nice!

VicToMeyeZR, are you going to pursue this idea then? If so could you do the XML route and I could take the sqlite route. I'd like to have both options for people. If you come up with a structure I'll make a sqlite file that has a table with the same fields. Then in the setkey section we can fill out a lua table that holds all the animation information from the file they selected.

Remember that object.model is the small circle model that is use in the editor. If you turn on physics you can see them. They should only be used for when in editor mode. The problem I had is that when that model is inside the controller, because by default it shows up in the middle of the controller, you can't select it to move it around. So that code you posted makes it so the editor model ends up being 1/2 below the controller, which allows you to select it and move it around while in editor mode. I do the same thing with my Pi-Cube because the editor model is inside the cube, so I need to offset it so you can select it and move the model around. You could select the model from the tree view in editor mode, but it's just so much easier to do it in the graphics window.

You know what we should play around with for storing character animations. Instead of storing them in settings to the model which is limiting, we should store them in an xml file OR sqlite file. We could make a setting that points to the xml file/sqlite to use. This would be so much more dynamic.

There is no crouching state for the controller. You can't scale it on the fly and make it work currently. For now I would suggest storing 2 separate character controller at different heights. One for standing and one for crouching. Then swap them when you need them. I wouldn't create them on the fly either. Create them up front and swap them in when needed. It'll be faster and doesn't really use that much memory.

@Blitzbat, no I seem to remember that BMax doesn't have the needed features to get this working. The system uses templates to make it work. The code is sort of complex to understand but easy to use, if that makes sense. Defining an event and using it is super easy, but looking at how it works under the hood can seem confusing. I'll see if I can find it now. Been awhile since I used it.

That video and the excitement those guys are having for the tessalation is the excitement we should all have for it. This is the next advancement to the graphics in games. The visual benefits that you see there are simply insane and it's a fraction of the time to get it. That's what indie developers should be jumping for joy about. Instead of creating 3 differently detailed models of all these things you only need to create one. So much more emphasis is going to be on the texture side of things instead of the modeling side, and I think that's a good thing because I believe there are more 2D artists than 3D artists in this world. That opens the doors and jobs to all those amazing 2D artist that are out there. The more I see stuff like this the more I'm convinced that some day it'll all be texture based modeling in the future, where the code generates the models based off 2D textures instead of a model file. This could save a ton of space on the model size since you wouldn't need a model file and pretty much leave 3D modeling a dead art. Of course they would need to figure out animation then to go along with it. Look what we can do with 2D image information today. We can sculpt amazing terrains from 2D images and the information they hold so why can't we make any model with a few different 2D images? Given some sort of standard, code could take 2D texture information and turn a simple cube into a house, bench, gun, character. Things like http://www.enlighten3d.com/2008/09/12/create-3d-models-from-photos/ will make it into games in time. I for one, can't wait!

With the way he has it setup, you scale the edges and the corners stay the same. Scaling the edges doesn't mess anything up. Are you using C++ for this? If so I have a pretty neat event system you might be interested in. It allows for event programming similar to C# where class methods can be used for events.

Josh has said he plans on giving CSG to the editor. I think it's pretty much required. There are always parts of levels that level designers should be able to create from CSG and not have to rely on modelers.

I'm excited to see what you come up with man!

Very nice. I'll put this in my Thingoids. Thanks!