Rick

That would be amazing to have that. I step through code all the time with VS. Stepping through code is almost a must these days it seems.

Any chance you'll be allowing us to step through Lua code?

All .NET for LE is community supported. Every member who has supported this has come and gone and come again. The .NET environment in LE is not the most stable. That being said I personally use what is referred to as LE.NET which is basically a 1 for 1 match to the LE library which means all methods are static (basically). There is however Leadwerks.NET which is more of a community layer that is OO in nature. Both seem to be pretty stable and open source.

The question would be do you know about game design? Unless you have the entire game design written down with milestones and tasks required for each of your desired positions, you will have a hard time getting people and a hard time getting the project complete. I don't know what industry you are in or if you are still in school, but programmers & artists would be sitting around doing nothing if the above is all the design doc that you have currently. If you are looking for a team like you listed you don't want each one to have a say in the game design (at first) because you'll never get anything done. You want to present them with a detailed plan and then get input from them in their respective areas where they will give experienced advice about why something will be hard or won't work. From my experience having just a loose idea of what you want and then bringing programmers and artists in and having them fill in the blanks just doesn't work. Would you tell carpenters, roofers, plumbers, & electricians to show up to the build site before you've even drawn up the detailed plans about what you need your building to look like? No, that's what an architect is for. You need to either be the architect or get someone who can work with you to be that architect.

Like a network message or an entity message? I assume network message since entity messages are tied to already created entities. That would mean we will get a network message callback that we can hook into for all LE network messages coming and going? That would be nice.

The deletion seems interesting. Will we be informed in any way of this deletion or would we have to pull from inside our classes that contain these entities to check them against null? For that matter the creation also seems interesting. How will clients be informed of this? A model entity is just another piece of data that your "Player" class would have just like it's name or health. So you would want more than just the model entity to be created remotely, you would want the "Player" class to be created, but since this model piece is a variable inside the overall "Player" class, it seems the 2 would have to happen at the same time. I feel like a callback would be required to inform the client that an entity is being created on it so we can then create an instance of the proper class and store the LE entity inside it. The reality is, from my side and I know others, LE entities don't stand alone. They are generally nested as objects inside a class that describes everything about a game object. A game object is more than just it's model entity. So I want to make sure when a client gets an entity ghosted on it, we have a chance to know about this so we can assign it to these greater game object classes. Will that be the case?

What's sync'd about an entity? Postion, rotation, scale? Anything else? There is generally more to what you'd want sync'd than that. Ammo count, health, etc. These are generally things that would be stored in a class. If we wanted to use this syncing method you have would we have to use entity keys for this data and have that get sync'd?

All very understandable, I just thought it was odd the attention you were giving to the graphics side of things, but I can understand the need for doing something other than programming. From my experience with the MAGIAM: A ) Your graphics and graphic detail basically needs to be bad to make the deadline. B ) Your gameplay needs to be very specific and requires you to take shortcuts to make the deadline. C ) You really have to draw out your entire design for the demo and be specific about every single goal you want to achieve. Then reduce your goals to be more realistic given the short time because they will almost always be to high at first. Honestly, I found the MAGAIM to be more about project management than making a game. It really shows you why games get features cut and have many bugs. It's strange because I think the people who actually make the game resources (programmers, artists) consider it an art, but it's also a business which means timelines need to be met to control costs, and that often conflicts with the "artists". This is most likely why most indie games never see the light of day. When you have nobody pushing you to complete something by a definite time, we all tend to try for perfection and it never gets done. We rarely want to settle for good enough even though it really is probably good enough.

Are these commands going to be able to not be network synced if we so want? There might be instances where I only want my local client to turn red. Also, are you looking at coroutines yet in Lua? I think coroutines are a must as it gives an amazing way to program sequence of events from Lua. It would allow for cutscene style programming.

This all looks great Pixel, but it seems you've bogged yourself down with art and level design instead of focusing on the gameplay to complete it within the given time. I'm kind of surprised actually that you would do that given I know how you feel about gameplay vs art.

Connector lines for in/out created. The bottom grid view will be to set method parameters if you wish them to be hardcoded values. Can also create basic programming variables. Next ==== Connect connectors to variables. Just have to get this visually down. Make a Start and Finish node. Start node will be what's looked for when generating code so it knows where to follow the in/out flow of the method. Finish node will be the "return" of the method. Finish will have 1 parameter which is the return type. If the method returns void you won't need finish but can still use it to break out early. Start node will only have and out, and finish will only have an in and 1 parameter. Parameters to the method. These will show up as menu items. It'll say something like Parameter Variables and allow you to add the same one as many times as you like, but instead of the code generation making a new variable when this is selected it'll use the parameter variable that is passed into the method.

These are all things raknet can do currently. You have to code them, but if you coded them using raknet it meets all those criteria while being multithreaded.

That's simply amazing!

VS or I'll riot. Oh man what's he going to do now

So was I. I enjoyed it because it showed many different aspects of things.

lol, I wouldn't call it a piece of ****. It's really good. No where did he say it was a trailer, it's a WIP video.

Like Drew said (but more in a 1 liner) the idea is to point your VS to the 3rd parties include and library folders.

Yeah, I think we understand what you are saying too, but then what you are doing is almost making 2 GUI's. One for development and 1 for the game when you could use the one for the game as your dialog also (the skin for that would just be lines so it looks like what you have). That way you are reusing your 1 way of doing a GUI to satisfy both needs. Valve's GUI is clean but if you say that same GUI in 3 of their different games you'd probably be like wtf Also it kind of fits their game theme. Anyway what you have looks nice.

I think you have the wrong impression about the 9 image way of things (which I guess is what I was referring to). You would never use a huge image with that technique. It would be made up of smaller images that get tiled/stretched/whatever other tricks you can do to make what looks like your huge image. You GUI looks nice, but your games theme seems to be more fantasy and the GUI is kind of more futuristicish/OSish.

Interesting. Yeah, the events are a pain to get all sorted out if you really want to be as thorough as possible. I've given my attempt at my fair share of GUI's with a few libraries and it's a pain.

I'm having a hard time seeing what the xml file would look like without images as the building blocks of your GUI. I guess the thing I always picture in my mind is winamp skins like http://www.winamp.com/skin/remnant/222243 for example. Now I know nobody is going to draw something like that out , but it would seem the xml file would be specific to your procedural implementation that is done in code and be somewhat "limited"?

But does that require programming? Seems like it would if it was drawing commands. You may be one of the rare few but most programmers aren't artists

Well, Mono could be used, but I haven't played around with Mono enough to be as efficient as .NET. Once this is all done maybe transferring it to Mono wouldn't be a big deal and that would make it cross-platform

I'll stick with 2D for now.

This is the building blocks for that. The canvas you see would basically be a function (in this case it's int main()). When you can create classes and class methods the canvas you'll see will be for that function. I'll probably add a treeview to show the class hierarchy somewhere, but the idea is that everything will have these basic building blocks. Once the basics are working then allowing templates and such can help people easily bring other peoples flowgraphs into their own. That's the idea anyway. Baby steps for now. That reminds me I need to add zoom ability so you can see more/less of the canvas.