base lua file proposal for Josh

[Rick]

My proposal to Josh is to change the base lua files that he has for the editor. I guess I would like a yes, good idea, I will implement that or no that's not going to happen. This will help me decide on the direction to take for lua.

 

I'm thinking the base lua file should be bare bones. Currently there are 3 of them and they are very specific in that they are fps, vehicle, etc. They create a weapon and have weapon code in them. I understand the reason behind this is to get something running asap in the editor, but I don't think this supports the idea of object programming that is the driving force behind using lua in the editor.

 

If there were just one base lua file and it was simple and generic, all that functionality that is currently in the 3 existing lua files can be done in objects that the play drags into the scene. Then to show examples you could create example .sbx files to show how to do something.

 

If you want these base lua files to be something we handle then that's the way I will approach it, even though I think it might be slightly more cumbersome. I just don't see a reason for these base lua files to be so specific. I think it might take away from the approach people "should" be taking with the lua implementation. That is creating objects for reuse and distribution.

 

For example let's say I want to sell an object. It would hold more value if it would just be plug and play with the current editor with no other changes, but currently it would require a more generic base lua file. As a specific example I'm creating a 3rd person camera object. Since the 3 base lua files seem to handle camera controls in them this poses a problem for me as my object controls the camera. Now I can provide my own base lua file, but what happens when another guy has a first person camera object? He would need to provide his own base lua file which could be the exact same basic functionality as mine, but not exactly done the same. He then would need to provide his base lua file and the user now has to know what base lua file needs to be used with that.

 

I think a base/generic lua file can be created that gives everyone the base functionality needed to allow the objects to do the work. I also think this needs to be created by Josh and not the community (the community should give some input though) for the reasons I listed above with selling objects. Once we start getting into any objects that control/handle something the base lua script is doing things start colliding.

 

So to summarize the base lua file should be generic and simple and allow the objects to do the work. This could help prevent "base lua file hell" if you will. It could give confidence to buyers of objects knowing that they won't have to screw around with many base lua files. Their object purchase will just work when they add it to their scene.

 

Thoughts?

[Niosop]

Are you talking about base.lua? Or the game play scripts like fpscontroller.lua, driver.lua, etc?

[Rick]

The game scripts file fpscontroller.lua. I just didn't know what to call them. The scripts with the main game loop maybe?

[Niosop]

They are game scripts. You really can't strip them down or when you hit the play in game button it won't do anything. They have to create a camera and position it and handle keyboard input. If you're pre-packaging an object w/ a Lua script, then you should package that *object* that is self contained and does what it does regardless of the game type. If you're packaging a game type (fps, third person, rts, etc) then you make a game script. Those are just example ones, everyone should either make their own, or not use one and handle that logic in compiled code.

 

If you have multiple scripts that control the camera you're going to need one game script that knows how to switch between them anyways. So essentially there is no "base lua file" that you are meant to use. There's just examples of a couple possible ones and one that is set as default so when you hit the "Play" button it actually does something.

[Rick]

If you're packaging a game type (fps, third person, rts, etc) then you make a game script.

 

The idea is taking objects to a logical level and not just a physical model. You are thinking in terms of say the windmill. That's fine for the windmill, but all the functionality of those game scripts can, and should in my view, be done by objects that you drag into the scene.

 

 

If you have multiple scripts that control the camera you're going to need one game script that knows how to switch between them anyways. So essentially there is no "base lua file" that you are meant to use. There's just examples of a couple possible ones and one that is set as default so when you hit the "Play" button it actually does something.

Not really. It would be left up to the user to realize that they can't have a 3rd person camera and a first person camera in the same scene. Or, these camera objects need ways to allow detaching and attaching themselves.

 

I'm asking for people to stop thinking in terms of physical models and start thinking more abstract. What's the point of hardcoded game scripts when they can be more dynamic via objects.

 

 

They are game scripts. You really can't strip them down or when you hit the play in game button it won't do anything

 

That's not entirely correct. I stripped them down and created a 3rd person camera object that I drag into my scene and assign it a target. Now when I start the game I have 3rd person camera controls around an object that I made the target and that's all handled in the objects Update() and not in the game scripts. Sure if you didn't have these objects nothing would happen, but that's why you would need these objects as objects that come with LE. I'm convinced more and more that an entire complex game can be created via lua objects and would require little to no scripting.

 

There is however some base functionality that this generic game script would need. The big one I can think of is if you are in game mode or edit mode.

[Niosop]

So you want a stripped down game type that does:

 

dofile('Scripts/constants/keycodes.lua')
fw=GetGlobalObject("framewerk")

while KeyHit(KEY_ESCAPE)==0 do	
fw:Update()
fw:Render()
Flip(0)
end

 

Then you handle all keyboard input, camera control, etc in separate objects that you drop in? That's fine but it doesn't fix any of the problems you mentioned. In your example, what if you drop in both a first person camera object and a third person camera object? They're going to fight with each other and you're in "camera controller hell", or "keyboard input hell" or whatever. Your method is totally usable, and I'm all for breaking stuff down into self contained components, and I'll possibly use this paradigm in my own code. But it's hard to tell where the divide should occur. In order to avoid conflicts you have to break your script own into ridiculously small pieces. "This script rotates the camera around the X axis in the negative direction by the value you set in the 'mouse sensitivity' box when you move the mouse down", then another one to rotate the camera up, then another to handle the left mouse button, another one to parent the camera to some object you define, etc, etc. It might be kind of cool to have a totally visual system like that where you never have to write a single line of code to make it do something (ala kismet), but performance would tank due to function call overhead and you'd be in the same position of "This script handles mouse movement, but I want to use this horizontal mouse movement script with it....is there a vertical only version I can download?"

 

Anyways, it's not my intent to disparage your idea, I think compartmentalization is great, I'm just not sure if it's Josh's job to decide how far things should be broken down when we can easily just include a README file saying to save the above code to a file and set it be the default game file in the editor.

[Rick]

I think Josh can define that level. He's already defined a level and I think it needs to go slightly farther is all. In your example of cameras colliding, that would be what makes a good object vs a bad object. The first question a user would ask is do I really need multiple camera types in my scene? If they do then they would need a camera object that allows itself to be disabled via a property OR a camera type that handles all types in one by setting a property.

 

My base bones game script is kind of like what you posted, but I make a string global variable to determine if I'm in editor mode or game mode. Since I'm making a 3rd person camera object, I can't have it run it's logic when in editor mode as that would take control of the editor camera and mess up designing the scene.

 

In order to avoid conflicts you have to break your script own into ridiculously small pieces.

 

It wouldn't need to be broken down to the level you described. I think an acceptable level is enabled/disabled of an entire object. You wouldn't be able to use some pieces from one object and some from another. I think an all object or non is perfectly fine.

 

 

I think this would really promote coders to making individual objects that they could give or sell to the community and have a user base who would be willing to use/buy because it's easy and requires no changes to how the editor works out of the box. It would require the coders to really put some controls/error checking around their objects and make more friendly objects that work well with other objects. I just picture an artist making a cool scene and wanting to add a character and have 3rd person camera movement being able to just drag this 3rd person object into the scene. Make the target their character object and have it just work. No need to mess around with a new whole game script lua file.

[Josh]

That's not a bad idea.

[Rick]

If you like some proof of concept before you do any action, I (or anyone else interested) could take your fpscontroller.lua file and show how it can be done via objects and a generic game lua script? Since the code is already there it would basically be breaking it out into objects so it shouldn't take all that long.

 

 

The best thing about this is that by default this is how the editor would work, BUT if someone didn't want to use this they could provide their own custom game script. I think that this way would be a huge success for both programmers and artists.

[TylerH]

I am in 100% agreement.

 

Though I think the way the community can spearhead this, if not done by Josh (whom seems interested ), is to go ahead and start making some of these objects.

 

You made a 3rd Person Camera; if someone makes a First Person Camera, then someone else can make a First <-> Third person camera that you can switch between and change elevation angle via mouse wheel, and the list just goes on from there...

[Niosop]

We'll also need the barebones game container class. As Rick said it should set a global string or similar that lets the objects know if they're running in the editor or in game so they don't mess w/ editing functions. Rick, mind sharing what you have?

 

There should also be a way for scripts to register that they control certain singleton type objects. So a script that controls the camera could set a global string/int indicating that it controls the camera, and all camera control scripts should check to make sure that nothing else has claimed control of the camera in their CreateObject function. If something else has already claimed control it could throw up a Notify so the user gets immediate feedback about a conflict. Then it can release it in it's Free function so another script could take it for say switching between first person and third person. Then we wouldn't need a First<->Third person camera, just one that knows how to swap between the other two.

[Josh]

Since it's all one state, you can just use a global lua variable.

[Niosop]

Ahh, yes, could even store a reference to self in there so other objects know which object has control of the resource, and communicate directly with it. So they could request to take over, or an object could interact with ANY compliant camera control script by looking up which object has control of the camera and sending it a message or calling a standardized function.

[Rick]

Downloading the new single lua state code, but then I'll start playing around with this. I'm going to convert the fpscontroller.lua file into object based and I'll see how the generic main loop lua file is looking after that. Since it's a single state I won't need to use SetGlobalString/Number so it'll change slightly.

[L B]

How about implementing static LUA files or objects. Ones that cannot be dropped or instance. For example, the atmosphere, waterplane and ambient light (and currently the directional light) should not have more than 1 instance. They could be made un-draggable and static.

[Rick]

So like a singleton. I think allowing the to drag would be ok, but having the script itself keep track of the count or return one reference only would be kind of cool. Much like a singleton class does.

 

Maybe it only allows your to drag 1 instance onto the screen. The object could keep track and if you try to drag more than 1 it just doesn't create the object other object? Not sure if that's possible or not.

[L B]

It might be me, but apart from the water height, there is no point in setting either position, scale, or rotation, or anything else for the atmosphere, waterplane, and lights. I don't see why dragging should be enabled, even once.

[Rick]

Because you might not want an atmosphere at all. A scene that is entirely in doors won't need an atmosphere. Some sort of puzzle game might not need an atmosphere. By dragging it into your scene you are saying you want an atmosphere. I suppose you could do the same thing with a setting, but I like the idea of objects acting as settings as well in this case.

[Rick]

Here are a few more ideas I'm thinking of trying out.

 

KeyboardControl Object

Animation Object

 

With these 2 objects targeted at a model that has animations, by just setting properties you can tie together keyboard input to moving the model and playing certain animations with that keyboard movement. This is all in my head atm but I don't see a reason why it couldn't work. In the Animation Object you define your animations with a name to the frame start/end. You link that to your "character" object. You also link the KeyboardControl Object with the Animation Object, and you define Forward = KEY_W & Forward = "WALK" for the animation. Now that would be cool!

 

This exact same setup could work for AI also, expect instead of KeyboardControl Object you would have some predefined behavior AI Object. Coders could create all sorts of different behavior AI's.

[VicToMeyeZR]

You could also create a Master AI controller. Like you have a squad of men. the talk to the Squad Commander(which is a separate object) This object controls the men in that squad's behavior, and through the commnuication, you change the settings of that commander, and all the men under him respond accordingly. But the functions of how to walk, run, shoot are all controled by the actual character object, but where to shoot, how to sneak up and plan an attack is controled by the Commander object(Which could also be one character or not a real game object at all).

 

By doing this you can create the sense of a really smart AI, but really its only one AI, just telling multiple entities how to respond.

[Rick]

Now that's a cool idea!

[VicToMeyeZR]

Its works pretty good for having AI's flank, and sneak up on the player all working together.

[Rick]

This is what I'm using for the main loop lua file. Ideally we would have a better way to exit game mode than having it hardcoded inside here. Could probably make setting in the Configuration Options for how to exit game mode from the editor. Now ideally this script would also be setup so it can run from the engine.exe as well and it would know where it's being ran from. The editor or the engine. I'm open to ideas.

 

require("Scripts/constants/collision_const")
require("Scripts/constants/engine_const")
require("Scripts/LinkedList")
require("Scripts/filesystem")
require("Scripts/math/math")
require("scripts/classes/bullet")


SetGlobalString("mode", "GAME_MODE")

FlushKeys()
FlushMouse()


--main function
while KeyHit(KEY_ESCAPE)==0 do

fw:Update()
fw:Render()
Flip(0)
end

SetGlobalString("mode", "DESIGN_MODE")

[Josh]

If you add require("scripts/loop") at the top, you will import the loop script, which has a few functions declared the engine picks up:

 

require("Scripts/hooks")

function UpdateWorldHook()
RunHooks("UpdateWorld")
end

function UpdatePhysicsHook()
RunHooks("UpdatePhysics")
end

function FlipHook()
RunHooks("Flip")
end

 

I just added the FlipHook() function, so I guess it doesn't make sense to call this file "loop" anymore. Maybe "enginehooks" would be a better file name?

 

Then the user can use AddHook("UpdateWorld",myfunction) to add their own Lua hooks, and your main loop doesn't have to have any code hardly.

[Rick]

I'm confused to why I would want to do that with the design idea we are talking about? The idea is that the users wouldn't need to do any coding at all. Objects would control everything. These hooks would be more for the coders making the objects for non coders, or even coders who don't want to reinvent something, to use.

 

For example if I was to create a 2D HUD object I would hook into the Flip hook when in game mode and unhook it when in editor mode. The user drags the object onto the scene and it just works.