Rick

Is there a reason why you are loading new maps for each room? It just seems a little unnecessary. You can still do the transitions like that and such without loading a map for each room. I love the old school door opening transition but back in those days there was a need to actually load new maps for each room.

Yeah, if I recall diagonal would be straight also. If it's returning the correct straight lines (even diagonal) then I'd say it's working? If you look at the documentation there is a callback function that gets called. If it returns true the node is passable if false it's not. I think what you would have to do is check your marked field in that node table to see if it's taken. So nodes can be a table that has at least an x an y member but you can add any other members in that. So for example you would add an .open field that is boolean. In this callback function you make check if node.open == false then return false end to signify that node isn't valid. I think that's how it works. [edit] You probably check the neighbor for open not the node itself when inside that callback function. If you don't define this callback function there is a default one in the library that just returns true which makes all nodes valid to move. You should be able to find a path that would return some straight lines and some diagonal even without unpassable nodes right? That can tell you if it's working too.

The thing I found with that algo is that if there are straight lines in the path it skips the nodes in the middle and returns the start and end point. So you will have to find those middle nodes to move to from the information it gives you.

I've noticed that too. Generally the 2 that come in from the left around the same time. We'll look at that. When we were testing we had the grenade drop change at 75% so we could go grenade crazy and it seemed too powerful to have a big splash area but with them being much more limited now I think a bigger splash area is warranted. Thanks for finding that bug. I'll log it and work on getting that fixed!

I know the leaderboard is messed up. I'll work on a paging system for it.

First off unless you are curious in learning how A* works I wouldn't worry about it. You can use that lib I posted and just get it working without knowing the details. If you want to learn how it actually works and try to implement it yourself then google it and learn, but pending your skills it could take time and you could have bugs to work through. Generally you have a 2D grid array/table of either just booleans or other objects/tables if you need more information per grid. If you just want to know if that "tile" (we'll call it) can be walked on or not then boolean works (true/false). At some level you'll need walkable/not walkable anyway for the A* to know how to find the path for you. The "tiles" in the 2D array/table have a center point to them, which is determined on how big you want the tiles to be. You will get back the tiles from the A* and then you move from center point to center point (generally) along those tiles. That 2nd screenshot you have above gives you an idea of that as you can clearly see the tiles with those grassy areas. Those tiles exist in a 2D array of booleans/objects in the code. All but the roads are marked as not open. Now in that game they could have not done the A* and just did pivots connecting because it's less dynamic of a path, but they could have used A* to find the path. You just have to think of the 2D array/table separately from your actual gfx but try to somewhat line them up so they match. They just don't have to be exact and often games want to hide that. In your 2nd screenshot they aren't really trying to hide that and in that Tower Wars they aren't hiding it. A* can work on hex tiles as well as square tiles and clearly Tower Wars uses the hex tiles.

Ah, if that's the case I wouldn't use LE's navmesh. If I did a TD game I'd lean towards A*. I've used this before where I think I had to modify it slightly: https://github.com/lattejed/a-star-lua

Oh. None of those games above do that. I've never seen a tower defense game do that actually. My first thought would be are you sure that's what you want to do? I would be shocked to find out the navmesh information is available to lua. If anything that sounds like something you'd have to do in C++ and even then it may not be exposed?

I think you mean x and z since we are in 3D not 2D. So you only really need to be worry about the navmesh on the area they can walk. Since you don't place towers on the area you walk this should be fine. So how to place towers depends on what time of game you want it to be. You could make a 100% free placement game where you have a "ghost" image of the tower and you check that it's AABB isn't intersecting with anything else before placing. I'm not following what this means? You want the navmesh visible? Why would you want that? I must be misunderstanding that. So the top pic and bottom pic are fairly easy because the path is dug into the terrain so the navmesh would only be able to walk on that path and not get up. The middle one is different because the navmesh would be able to move anywhere. To get around that you can place invisible csg around the path so the path generated is only the visible graphics path. Note that using the LE navmesh process you might not get nice and neat enemy movement if they are layered. If they are sent 1 at a time it's fine but if you want 2-3 side by side that look like they are taking separate paths then it might not give you that. To get that you could play around with invisible CSG and make lanes on your visible path though.

Yeah, you have to figure out how to make it look good. If the rock is just separate from the terrain in a big way there is no way around it. The navmesh system doesn't allow for jumping up or falling down from what I've seen.

Make csg and paint it with invisible material?

To build on josk's answer if you do go global variables (I would maybe look at file i/o for this unless you want it to work on the game player) make a global table and store the values in there inside Main.lua. It'll just be easier to organize things that way vs loose variables.

For your 2nd note about the offset generally you'll want your "origin" from your model in the model app you use to have it set to the bottom. If you go with csg then I think you can set that in code if you make it an entity. For your 1st question this has been brought up many times but it's because of the navmesh. In order to calc where something can go the navmesh generation needs to know the size of that something. That generation is done in the editor at design time for 1 size. If you had different sizes you'd need multiple navmesh's for each different size physics body. It's not impossible but Josh has said for now this is what we have. There are various ways you can work around this depending on the situation you have. Clipping is something we generally just have to deal with though. Your other more advanced option is to not use LE's navmesh stuff at all and make your own. Before LE many people used A* for path finding and put their own node system in. Obviously this is more advanced stuff to do though.

The editor doesn't know anything about what you do in C++. If you want your classes to be associated with entities in the editor you will have to loop over all entities after you load the map in C++ and then assign them yourself. You'll most likely want some kind of system to make that link yourself but because this is C++ and not very dynamic it'll be some hard coding going on. For example, you could make a lua script that has a Script property and in it's Start() function you assign whatever value you typed into it to the entity key/value system (self.entity:SetKeyValue("type", self.Type)). Then in C++ after you load your map loop over all entities and get the "type" key and use it's value against some hardcoded string's to C++ classes foreach(auto e in world->entities) { string key = e->GetKeyValue("type") if(key == "Player") player = new Player(e); if(key == "Enemy") enemy = new Enemy(e) } The above is just some pseudo code example on how you could do this.

Thanks Thirsty, Yeah, the high score display was from Josh's example code for it and I changed the font and size. I'll have to go back over it and make sure it works for all resolutions as currently it doesn't. The grenade is for future development (we have grenades about 90% finished right now. will release another version shortly). We plan on having this level just an endless mash of things we want in the entire game in the future. We'll have a number of different levels with end bosses ever so often and levels will get progressively harder. At some point we hope to do a greenlight for this game and get it beyond the LE Game Player.

I noticed when we placed this in the scene (not a prefab but just the emitter) and I tried to call :Instance() on it, the new instance would act the incorrect way too. So something with making new instances. I'm guessing some fields for emitters aren't getting set when a copy is made via Instance().

It worked great shadmar. ty very much!

I've had to restart my PC before because of this.

Model:Box():SetPosition(v.x,v.h,v.y) Oh, I see the h is actually the y. I'll have to pay close attention

OK, to make it not crash you need to set the zombie target to the players script variable. So in ZombieSpawner.lua line 48 instead of: self.zombie.script.target = self.Target do self.zombie.script.target = self.Target.script The zombie script is expecting the target variable to be the entities script variable instead of the entity itself. I saw that because inside MonsterAI.lua there is a ChooseTarget() function which sets the target variable and you can see it sets the entities script as this target value. Doing that fixed the crash but the zombie didn't run to the player. The thing is the MonsterAI has code in it where it searchers for opposite teamid so you don't even have to set the target manually because the monster will find the player. The other thing you are doing incorrectly is in your spawner you are using a script level variable: if self.zombie==nil then self.zombie= Prefab:Load("Prefabs/Characters/crawler1.pfb")end --self.zombie.script:Start() self.zombie:SetPosition(self.entity:GetPosition(true), true) self.zombie.script:Enable() For the first time self.zombie will be nil so it's load it. Then it'll set it's position and enable it. The 2nd time in there self.zombie is NOT nil so it won't load it again, but it'll keep setting it's position to the spawners position over and over again. When you load things dynamically you don't really need to hold onto them from the loader script itself. Just let it be free! In other words use a local zombie variable when loading and setting things up for that zombie. After the function exists that variable will be free'd but the zombie will now exist in your world and do it's thing. In other words change it to this: local zombie= Prefab:Load("Prefabs/Characters/crawler1.pfb") --self.zombie.script:Start() zombie:SetPosition(self.entity:GetPosition(true), true) zombie.script:Enable() You don't need to set the zombie's target and also not the true params in GetPosition() and SetPosition(). It's needed because your spawner is a child of the spawn controller and you want to use the global position of the spawner not the child position.

I get a weird flickering of the trees in the distance. GeForce GTX 650 100+ fps.

Thanks Shadmar! You know I just found that code this morning on github but I asked the guy if he could make it 3D as it was 2D. I assume your 'h' is 'z'? Why the 'h' instead of 'z'? Just curious.

It doesn't need to be a perfect curve, I'm just surprised I couldn't find any function online that given 3 points would just provide the curve points for you.

So you're doing velocities and such. My idea was that I know my start and end points in which I would then calc the mid point and from those 3 points make a parabolic curve and then get the points along that curve and move over them smoothly. vs sending an object in a direction and calculating that curve as it goes.

It would seem I'm an idiot in math and have not idea on how to translate anything on there to code