Rick

I'll throw those in and check, but they would be correlated since something that takes longer would cause less fps, but I agree it would show more solid numbers to work from. [EDIT] Am I going about this right: local s = Time:Millisecs() self.arms:SetPosition(pos) -- 100 fps local e = Time:Millisecs() local diff = e - s System:Print("Arms SetPosition time = "..diff) This is showing me a value of 0 or 1 for SetPosition()/SetRotation() and a value of 1 for Move(). I'm assuming Millisecs() isn't small enough to get a real meaningful value. I guess I don't get why we can't measure something in fps. If without feature A I get 100 fps and then I add feature A in and get 75 fps, then feature A is costing my game 25 fps. So them I can look at feature A and see if I can make it faster so it costs less fps. That seems like valid logic. Sure that's specific to my machine/gfx card but it's all relative and that's fine. If I can make feature A cost less fps on my machine then it'll cost less fps on a different machine as well. So if a feature cuts my fps in half it catches my attention because it'll drop a good amount on all machines.

Here is my event script that I use: if EventManager ~= nil then return end EventManager = {} function EventManager:Create(owner) local obj = {} obj.handlers = {} obj.owner = owner for k, v in pairs(EventManager) do obj[k] = v end return obj end function EventManager:Subscribe(owner, method) table.insert(self.handlers, { owner = owner, method = method }) end function EventManager:Raise(args) for i = 1, #self.handlers do self.handlers[i].method(self.handlers[i].owner, self.owner, args) end end You would create an event like (Inside InventoryScript for example): self.onDrinkHealingPotion = EventManager:Create(self) You would subscribe to it like: InventoryScript.onDrinkHealingPotion:Subscribe(HealthScript, HealthScript.Heal) So you can kind of see how we are communicating between scripts. Inside the Inventory script we have the onDrinkHealingPotion event and when it's raised it'll call the HealthScript's Heal function so the health information can be updated. I've been changing our player code for our game to more of a component design. It's similar to what you're doing except I don't use pivots/entities. I have the 1 entity which is the player, and then inside that script I bring in all the other scripts/components that make up the player and hook all the functions together so they can interact. This is nice because it makes it so each component is not coupled with other components. You can think of each component like a library in itself doing it's specific thing. All it needs is functions that act on the state of its own variables and events to tell the outside world things it may need to know. The basic structure of a component script is: if PlayerSound ~= nil then return end PlayerSound = {} function PlayerSound:Init(entity) self.entity = entity end function PlayerSound:Update() end Then inside my player entity script I'd bring it in and hook it up: import "Scripts/Objects/Components/PlayerSound.lua" import "Scripts/Objects/Components/PlayerInput.lua" function Script:Start() PlayerInput:Init(self.entity) PlayerSound:Init(self.entity) PlayerInput.onmoveForward:Subscribe(PlayerSound, PlayerSound.MoveForward) end So the main player script just ends up being a place where each different component comes together and hooks up events to give the functionality that makes up the player. I've had to switch to this component design because sooner or later the player script just gets too big and unmanageable so splitting up the functionality by domain helps keep things organized better and in their own little scripts doing their 1 specific thing and communicating via events. Everything a script needs to know about some other script is done via events and events can have args so it gets it's information from the other script that way. If you need you can create an onGetRotation event which you would fire off in that scripts Update. I do this between the PlayerCamera and PlayerController as the controller needs the Y rotation of the camera so I have the PlayerCamera onGetRotation event pass that as a param: function PlayerCamera:Update() -- do camera rotation stuff here self.onGetRotation:Raise({ camRot = self.camRotation }) end I'll subscribe to that to my PlayerController and now each frame my PlayerController knows the cameras rotation that it can pass to the SetInput() function. Sorry for the long post.

This is with the FPS template pistol arms.

Looking for debugging tips to find out what's going on. I have some first person shooting arms in an empty scene. I'm using the old AnimationManager.lua for animating. When I comment it's Update() I get about 700-900 fps. When I uncomment it (animate the arms in an idle animation) I get about 350 fps. I noticed if I comment out the self.entity:UnlockMatrix() that's inside AnimationManager:Update() I get about 500 so that function for sure has a pretty big impact on fps. self.arms:SetShadowMode(0) I have this set for the arms model but it doesn't seem to do anything. I would assume that turns off shadows which is what I would want. Any other ideas? [EDIT] I'm noticing that SetPosition()/SetRotation()/Move() are big fps killers too. Move() easily took about 300 fps. SetPosition() about 100, and SetRotation() about 50. Why would that be?

My suggestions: Look into making "classes" in Lua vs using all Le entity scripts for your code. It sounds like you're attaching pivots to the player and adding LE entity scripts to them. That's a pretty hacky way to go about it. You can simulate classes in Lua and then include those into your main player script. I suggest each systemyour play has would have its own class and just include that into the player script. This would easier as the flow of your code is all in one spot. I would also suggest breaking that huge long formula up into multiple lines and label each step. It'll make it easier to change 3 months from now. When I played around with org stuff I would make a stat class. Then make 2 instances of that in my actor class. One is base stats the other modified stats. Maybe lean more towards event programming vs polling with the formulas. If you have a lot and they get complex not having to run them each frame could help. You really only need to calculate when something changes. Knowing when things change between systems means you need to know when things change. That's where an event system would come in handy. I use one that allows you to subscribe any number of function to be called when you fire the event. That can come in handy as it helps move logic to generaaller functions vs polling which tends to lead to giant functions that are complicated to follow. It also helps keep systems less dependent on each other. You asked for comments so thought I'd share. I know I hate it when nobody replies.

Looks good. I would expect the buy button on bottom right and qty to be textbox with + - buttons vs drop down. I guess that's all I could think of.

A crappy work around would be to have the visual CSG not be considered an obstacle which is a setting for each entity in the physics tab I think and then have a second CSG that you paint with the invisible mat be the one that is an obstacle and make that smaller in size.

It depends on the library. If it's pure Lua and doesn't use require() or load library then you can use it in sandbox. Since the goal of this post is to write to disk then it pretty much means you can't use sandbox anyway. Technically this library could be used in sandbox but it's fairly worthless to do so since you want to use it to save data to disk which means using it in non sandbox, Not true. Some very useful Lua libraries are pure Lua and don't load dls. The tween library I use and the behavior tree library I use can be used in sandbox. They often need to be edited first as josh has removed the ability to use require() in sandbox which almost all Lua libraries use to get loaded. So in change them so they can use import instead.

I've used this for loading Json, but this would be the easier way I would think (less code for you). Export table to Json text and save to file. Read in Json text from file and convert back to Lua table. No messing around with the inner details that you don't care about. http://regex.info/blog/lua/json

@Josh so that's a response that helps us understand more. So that mission statement you have does have the conditions around it to be achieved in a generic game engine. i.e. Leadwerks engine as its core is today. That helps clarify that.

+1. If it's a quick workaround Josh could just attach a dummy script himself to linked CSG brushes when the map is loaded from the game. Seems like a cheap and easy way to do it.

That doesn't matter in business terms. There are always younger people wanting to make these games and these makers are the entry point for them and that's perfectly fine. People will outgrow them the more they dig into game development but some people are simply fine not growing and simply working within the bounds of the game maker. However, if they did want to grow then BAM, this game maker is built from Leadwerks engine which is more flexible at a cost of complexity, but now they have graduated to want that challenge. Just throwing out different thoughts here. Not many people start their game making journey by just buying a generic engine. I'm willing to bet a lot start from modding or game makers as they are less intimidating. Breaking the intimidation factor is harder than providing another option at the start of the game dev chain. Saying the comment you said above is like saying a honda civic isn't worth making because it can't grow and scale with your life. Well the honda civic meets a need and so does an huge SUV. There are markets for both. Maybe it works the same with engines. One size just doesn't fit all.

This is a good mission statement. My question would be are you adding constraints to do this statement in that it should be done within the bounds of what Leadwerks Engine is today? Adding game templates to LE I think is trying to achieve that mission statement in the bounds of what LE is. Can a generic game engine ever really achieve that mission statement? That's the debate I guess.

I'm drawn to this statement. Do game templates really address the above statement is the first question I asked? What I hear with the above statement is how can you take all that game dev related stuff and encapsulate it away so the dev doesn't have to know about it? All the dev really cares about is defining the gameplay logic in an easy way. They expect a list of common camera controls to just pick from vs defining their own. It's hard to blame them on this as basically every camera style has been done already. I'm sure they look at that and wonder why they have to care about the camera code. I wonder if templates don't go far enough. You have the core engine, but what if you made separate game engines for each type build from Leadwerks and sold them separately on Steam? I mean RPG maker is basically that. You could make your own 3D RPG maker using Leadwerks but sell it as it's own app as it would be highly specific to RPG's with dialogs and a lot of UI specific things. Then do the same with RTS, FPS, etc. All using Leadwerks under the hood but each being their own application really. It takes the templates idea further providing new revenue streams while all still using Leadwerks under the hood. RPG makers, FPS makers sell and I think they would be valid separate apps as they would all have very specific beginner friendly dialogs to build that type of game. There is no doubt that you making those would also help with ideas on what the core engine needs in it as well so the core engine wouldn't suffer from not being updated. The question is, does that spread you too thin? Perhaps you can employ people for each game maker type? Just ideas on how Leadwerks can reach those beginners. Getting more specific in the application has been a trend these days. It would sort of be like that one Leadwerks user who made that RTS engine using Leadwerks at the core.

@Josh what you are saying has nothing to do with ppl not using filters. We use filters, but dragging and dropping entities between filters being the only way to move something isn't efficient. Having what filter an entity is in on the properties would be another way and more direct. Filters may not be linear but that doesn't mean you can't find all filters for this dropdown and make it linear for our viewing and moving. I think the problem you have with doing this is allowing sub filter names to be duplicated. If that wasn't there then it wouldn't be an issue. Not sure if it's too late to change that, or have a different control than drop down that shows the filter hierarchy.

It doesn't look like it. For the sake of ease PlayAnimation() has it's limitations. If you want you can use the old AnimationManager.lua script and that has ways to get the frame that's being played. However, the question is why would you need this to save to disk? No game I've ever seen saves while something is in the middle of an animation and then when you load the game it starts right in the middle of that animation. That seems like an odd request.

For our purposes, we are syncing the "frame" one a zombie struggle animation with fps arms struggle animation so they are playing the same "frame" so it looks right as the animations between the 2 were created to match. Tum is talking about saving that data, which I'm not sure why you'd ever want to do that.

I added a GetFrame() function to the old AnimationManager.lua (one was there but I tweaked it). However, that has a way to expose the current "frame". Not sure about the new way.

When talking about enemies you need to really think them through. Should you really place them at design time or run-time. If placed at design time do they really need to have data saved? Think mario. Those enemies are placed at run-time but they aren't saved between saves. A level starts fresh every time. What example do you have where this would be needed at design time and you can't just have them reset where they were when placed at design time each time?

Not of the actual saving side but I had before code that loops over all loaded entities and would call a LoadData() script function if existed after the map load passing in the table that was saved. Then each entity has the chance to get the data it needs to read and set. You still have to code the logic in LoadData() for each entity but to read and set the variable in that script. Then they had a SaveData() as well that allowed the script to save any data it needed to. Now each script controls what it writes and reads. Passed into these functions is the table that you read from or write to. Then how you do the actual loading to a table or reading from a file to a table can change without affecting your scripts.

I really want to use left alt key for turning the camera to look behind while keep moving in a different direction but it would seem the alt key doesn't work.

Does this work on terrain yet?

What's the benefit of dynamically populating a list for design time options? With those properties needing to be filled out at design time it implies you know the values already to populate that property.

I think you'll find other issues with it but give it s go. Do a search on the forums about multiple cameras as others have gone down the 2 camera path and learn from them.

2 cameras have caused issues for ppl in the past. It's probably best to avoid doing that but you can try if you like. I think in that case you have to hide and show both be dude I believe you can only have one active camera at a time.