Rick

Probably both. I doubt the code will be secret.

Right, you can't use MoveEntity with physics bodies as it turns off the physics. You'd have to either use the controller or forces.

I think bounding boxes would still work wouldn't it? With the EachEntityInAABBDo() function you can ignore things you don't care about like the terrain and instead look for other things that are colliding and react. Or are you wanting to do your own gravity with this this? For gravity without physics on terrains only you could get the players x & z position, then get the terrains height (there are functions for this) of the same position, then position your players y value to that.

In the brainstorm drawing document on the right hand side feel free to use the chat to talk about things. The brainstorm clearly has a ton of stuff that we'll most likely have to start talking about what makes it and what gets chopped.

Could use the bounding boxes (AABB). It won't give you perfect collision checking but it could do the trick.

Message sent. Looking forward to this.

Either game is doable but scaling things down is an art right In your zombie example let's scale it down. I love the idea of being deep into zombie apocalypse that could be describe with some 2D pictures and narration that basically sets the stage for what you said. You have very little left (not many bullets let's say) and you need to get from point A to point B that will take place within 5-10 or so mins of gameplay. Remember we don't have to create an entire game with this. It can just be a tech demo for LE. In this case we would need zombies with some animation. 1 or 2 people on the team could purchase (of if they already have) some zombie models and they are the ones who control all that. The horror idea is great too. Doesn't really require any models but environment really so no real animation required. Puzzle design would be the key with this. We'd have to make sure feature creep or crazy complex puzzles aren't created. The ending could be left very wide open as leave the person wanting more. Storyline with this type of game is pretty critical. With the zombie game idea above you set the story up right away, but it's your basic zombie story so not hard. Then the zombie one becomes about fast paced survival getting from 1 point to another with limited resources quickly. I really like the idea of throwing players knee deep into an already developed story via some 2D art and narration at the start, throwing them right into the fire for some quick scary action. It shouldn't be to complex since they are just starting but would be cool to have the players adrenaline rushing right away.

That all looks really clean. I'm trying to think really hard about the downside of this design but not really seeing it yet. Could you describe how the connectivity between entities would work. Let's say I have a volume that I would like to attach some collision functionality to where if the collision is the player it turns on a light and plays a sound on that light. Then maybe shoots off some fireworks (emitter). How would we hook those together in your vision?

Is that actually working or is that just pseudo?

I would think it would be OK to make a new topic about this idea. A topic created by you gives you full control of the top most post to update over time. That seems like a good starting point for debate/ideas. One of the reasons I want to be part of this is I want to practice working on ideas that I might not 100% agree with. It's easy to work on your own ideas because you love them! It's much harder to work on ideas that aren't you own and you aren't being paid for, but I believe it's a good skill to work on. When it's in a team environment it's even more important to be able to play nice on a compromised idea, since really that's the real world. We probably all do this at work but things are made easier when we get paid That being said I would hope others would see it that way as well. To not just quit or not even start because their idea wasn't used. This process isn't meant to make any of us money, but to get LE some kind of community game and to be a learning experience with working in a team environment for a video game that you might not 100% agree with but still being able to turn something out.

That's what I was thinking the google docs would be used for initially. The people who want on the team or are on the fence can use google technologies to do the meetings and brainstorming to make these decisions. Something that's more organized than a forum that'll blow out into 10+ pages which isn't organized in some fashion and will be hard to follow. I agree it's not to a point of actually working on but there are better tools than this forum to brainstorm all these details on is all I was meaning.

I say google docs. Get that stuff setup Aggror and invite me

Are you still parenting? Parenting can lead to some funky stuff sometimes. Worth a shot to unparent if you are still doing it. Other things like mass maybe? Been awhile since I used controllers so can't remember off the top of my head.

That would be a pretty good system to follow too. I don't think it kills your idea of a flowgraph though. Either linking input/output with text like Hammer and HL or via a visual flowgraph, the idea of input/output is the same, it's just how you want to represent it. So if you go this route you COULD only allow 1 script per entity. Note entity NOT model. This would mean we would be required to be able to add phantom entities that have no visual representation and are there solely for functionality of scripts so that we can link inputs/outputs. I think that could get messy for the level so I still like the idea of multiple scripts, but I would love the Hammer/HL style of input/output linking.

With large terrain we have to fill it and that'll take awhile. I fear that's too big of a task to be realistic. There really isn't any harm in a small terrain to start with. I agree with shadmar. The zombie approach is always a favorite. Getting from point A to point B while zombies are coming at you would be some nice basic yet exciting gameplay. Could be in FP so we don't have to worry about 3rd person character model. We already have a weapon with the LE gun to start with. Involves shooting, and some basic AI. Nice and simple with the ability to expand on. [EDIT] Also, the thing I haven't seen yet is language. The language picked could really start thinning the crowd That's actually the one thing I dislike about LE really. We aren't all on the same page with that but it matters when the rubber meets the road. I vote Lua or C++ myself.

I vote Aggror be the manager! Looks like he has his stuff together.

Don't parent the controller to the model. It can run into issues. After UpdateController(), position the zombie model to the controller position instead.

Use PointEntity() on the zombie model on the Y axis. Then use the zombies Y rotation value via (EntityRotation(zombie).Y) for the rotation value to use for the controller. This will point the model and make moving "forward" with the controller move towards the player.

That's what I was trying to convey with the "Only allowing 1 of a specific script per entity is probably valid enough" statement. Meaning is that really going to be a limitation to not allow 2 of the same exact scripts? I'm trying to think of why you would do this. Then again that could play into a multimap where you can loop through multiple of the same script name if required. I agree, but then again maybe we were looking at the collision incorrectly. Instead of looking at it from the bullets perspective maybe we should be looking at it from other entities perspective. Like in your example we would have a paint can model that we attach a default script to and inside it's OnCollision we can check to see if the entity that hit us is a "Bullet" and then we can do your paint can scenario. The language issue is a problem Unity wanted to create to support more languages. I don't agree with their decision on that, but then again you won't have that issue because it's just Lua. That's much cleaner. I think the main thing to remember is there isn't a whole lot preventing the community from making single pre-made gameplay oriented scripts today and yet it's just not happening. I guess this then comes down to why you think it's not happening. I believe it's not happening today because as a script programmer I don't see much point in making such specific scripts that will hardly ever get used because because they are so specific. I say this simply by looking at how many more "generic" scripts Unity has that were created by the community because of the generic fashion system they have. I keep going back to things like rotation, emitters, & sound. How can I get all 3 pieces of functionality attached to an entity with 1 script? Are we going to have a RotationEmitterSound script? Then an EmitterSound script? Then a RotationSound script? Some things will need sound only, or emitter and sound, and/or any combination of the above and many other pieces of functionality that people would want to mix and match to get their desired functionality. This isn't even just for the script kiddies. It would be way easier for anyone to be able to piece things together. This just seems like the natural evolution at some point.

I would say using the script name as the key to getting a script attached to the current entity would be the way to get a specific scripts function/variables. Only allowing 1 of a specific script per entity is probably valid enough. That would turn it into: -- collision from a bullet point of view function script:Collision(entity,normal,speed) if entity:HasScript("CharacterStats") then entity:GetScript("CharacterStats").AddDamage(self.damage) end if end This however plays into what you said above where you dropped the idea of a Script type. The above isn't complicated. Perhaps the C++ version of it is and that's why you dropped that idea? The above is pretty specific script but I'm guessing most collision scripts will be pretty specific to the game and require coding (unless you went down a big rabbit hole). All I know is I would want something like: bullet model attach an empty default script to handle collision (most likely pretty specific to my game) attach spinning script (I want a realistic bullet so it's spin as it's moving) attach emitter script (I want some smoke trails on the bullet) attach sound script (I want a buzzing noise to play while it's moving so if it flies by your head you hear it) attach a move script (this will get the bullet moving in a certain direction. the weapon that shot it will set the direction & speed.) ??? Profit Ideally the above would be able to be made a prefab so when I fire my gun I can just create an instance of the above with 1 function call, set it's direction and speed, and let it do it's thing. So in the above example I have 4 very generic scripts that I was able to just attach to 1 entity, set some editor settings, and get some bullet gameplay very easily.

Side note, the poll should be radio buttons instead of checkboxes don't ya think?

Fair enough. I think my major concern is using a comment system that actually has functionality. Giving 2 completely different meanings to 1 language feature is something I would think would be nice to avoid if possible.With such a flexible language like Lua I would think it could be avoided. It seems that's not all that different than what you have today. So the results you get from the community won't be all that different than what you have today in Lua ie. pretty sparse. Doing it with one script basically seems like all your really doing in LE3D is removing the targeting system and/or global access to objects as the interaction between scripts and instead having the input/output system. If that's the only "step up" you're after in the Lua system in LE3D then it seems slightly different than originally planned. Not that that's a massive issue, but it might play into my point below. If we can only have 1 script per entity, bolting on additional functionality to an entity would then require the merging of different script files. You once talked about Lua being better for sharing code, but if one has to merge scripts that sort of goes out the window as it's now not that much different than sharing C++ code. I don't think there is any question it's easier to only have 1 script per entity from the aspect of C++ and how you have to handle things, but it's limiting to the majority of the demographic that would be using Lua in the first place. People looking to piece some scripts that you or the community create to give functionality. With 1 script per entity those scripts just became very very specific. No real difference than what we have today, and honestly the community created Lua scripts today are basically zero to none in terms of actual gameplay functionality. They are all pretty much just visual things. That's nice, but it doesn't allow someone to get real gameplay into their game by piecing together scripts. The more specific scripts have to be the less usability for the majority of people they are. Which leads to nobody coding them in the first place for others to use because they know nobody will because they are so specific. I would ask to give us programmers who want to see the Lua community grow, a standard system that has the ability to attach multiple scripts to entities. Once given that, sit back and watch the community take over and grow it into something amazing. Let us sell these scripts if we want to, and with a few key players in the community taking part in the beginning, this thing could be huge and open the door to way more sales from the less strong programming crowd who believe it or not, can make games, but more importantly, have money just like the rest of us.

This really would be the key to it all. I believe to make a successful community game like this the game has to be relatively small, planned out in great detail, and people asked to do very specific, "pieceable", components that someone could do in isolation from the project as a whole and have the project manager able to piece them together. I believe people are more willing to not officially be on a team and instead help out with small chunks of code. For example if you wanted movement based on animation to avoid movement sliding you could ask Roland or Pixel to create a small, isolated class to do so since they are the experts (don't be humble guys you know you are ) of the community in that area. They would be more likely to do that than join a team. So if one could break up the entire game design into small tasks like that and just give requests for the community stating that this is a community game and you won't sell it when complete, or profits went to Leadwerks development, and anyone who helped will be given the correct recognition, then this might work. That being said I don't think all that many people have the skill to do that. You need some amazing foresight, really good design skills, experience completing a game already would be huge benefit, and be very very detail oriented. Building as you go I don't think would work in such a situation as people would probably get frustrated with things as they change all the time. Building as you go by yourself or someone you're paying is fine, but when working for someone else it's just annoying to be doing code that gets thrown away all the time because the design changes as you go. This has been something I've wanted to try for a long time now, but even for the smallest of games it would take someone probably a couple of months to map all this stuff out to enough detail. The last thing you want to do is give tasks like "We need a sound system", "We need a pathfinding system", "We need an animation system", etc. These are far to generic. That's just my thoughts on the topic anyway.

How would you define things like Sound, Material, etc in that method? script.boomSound = Sound? But your last 2 posts do raise the question of private script level variables vs public script level variables. Maybe? script.public.var1 = Vec3(0) script.private.var2 = false Merging your 2 posts above would look something like the below. script.state = false --public bool Using comments I assume you might get into possibly forcing formatting of those comments to be exact. Like what if I put a space between -- and my type or access level. Guessing it could cause parsing issues and possibly fail. Would hate to have the possibility of something like a comment causing failures.

As far as I understand how this is going to be done, those commented variables at the top are the actual input variables that will be used for that script. If you've ever used Unity you can think of these to when you make a variable public and how it now shows up in the editor and you can assign values to each public variable. If Josh is simply using comments to show the general idea and he doesn't have the details of how it'll be worked out then ignore my comments, but if he's really going to be using the comments at the top like that to define the "public" or exposed variables then I would question that style. I thought I remember him though saying the comment style is the way he was thinking of doing it. I would think something like: variables = { var1 = "" var2 = "" }