Rick

http://www.leadwerks.com/werkspace/topic/14318-my-monsters-can-run-through-walls/ I think this is a good example of some of the challenges faced with game devs who don't have a ton of experience (towards the end). He's using the crawler and now he introduces a concept of them chasing the player through doors even. He hasn't thought about how that would work. He just wanted the crawler to keep running into the door while it opened. Clearly that's not acceptable in today's games. He simply hasn't gotten that far to see that issue yet and lacks the game dev experience to think forward enough to see it. So this rolls into AI. LE has no AI system. It's brute force homegrown at this point. I still have the feeling that your time is better off making systems that make things easier for us to make games. You are going into a part that a couple years ago you hated and said you'd never do. You are trying to write games for us. I disagree with that approach personally and would prefer you write systems. I think you are better at that and it's a better use of your time. Saying this I have Behavior Trees in mind or even a basic state machine system. Without making actual systems that empower us, people are going to run into issues with their game and the things you've written not working in their game design, which we see a lot of these days.

You have to show people your management and design skills. If you had a detailed plan all documented and ready to go and it made sense and was good, then people would be more willing to trust you in that area. However, this can take months or work and organization to do and it better look good at the end. It can't be a 2 page google doc with some vague description of the game. You have to get more detailed in the requirements. Yes, some of them can change during dev but you have to have a fairly detailed plan for the entire game. It's tough to do because you get into some boring parts but it has to be done.

Probably the most underrated service if game designer and producer. By that I don't mean you have game ideas, I mean you can take game ideas and turn them into organized documents and can task out jobs effectively. This is a hard skill to find because it's kind of paper pushing and not many people find that fun, but if it's a skill you have or would like to develop and you show people your organization skills then you will be more likely to land a team as a non-technical/art person. Most games are really complicated and it takes a lot of project management to get them completed. Most people just don't find project management all that fun, but most every successful game has had some form of project management.

I agree, the bug needs to be addressed. Wanted to just make the OP think differently about the greater problem of AI opening a door and how that could work. In his current situation, or maybe even most with dealing with AI, you'd probably never want them walking into a collidable thing and continue walking (from a game standpoint) not able to get by it, but clearly if they do they should collide because that's how physics works So, it's a workaround to how physics should work, but in my eyes not to how a game, or at least his specific case, should work.

What was your plan around the monster going through the door? Would the physics shape cause it to stop but if the code is telling it to find the path then it'll be running in place against the door while it opens and look kind of bad. A different approach might be to have a trigger on either side of the doors that when a monster enters the trigger you both stop it from moving and open the door. Then once the door is open you continue the monsters movement to it's target. Now you wouldn't have to worry about the physics and you maybe solve a problem of the monster running in place against the door if the physics was on there and it looks a little more scripted and natural? Just an alternative thought.

Until networking comes about you won't get around having to do this yourself (and maybe then depending on how Josh does it). If tree's can be chopped it makes them more than static entities which means the server needs to control them (create them and distribute them to the clients). Servers won't have the gfx capabilities to even run a leadwerks game so your server app can't be a leadwerks app. It has to be a plain C++ application. So you have to do this yourself in that app anyway. That's an interesting way of doing it. I've never thought of that way. It seems a little inefficient when compared to just looping over the entities from C++ once the map is loaded as you are going back and forth from lua to C++ a lot based on all the entities you have in your scene. If you wanted to continue doing this I would think you for sure can pass the actual self.entity since there are LE functions where you can do this and it works fine. Probably just need a post on how that's done. Someone has probably done it besides Josh but maybe Josh could share what he's doing to get that to work. Maybe he has a function in the Interpreter class that helps get the entity passed in.

So are you saying you are naming things like "tree1", "tree2", "tree3", etc? You mentioned before you are using C++. I assume you're using C++ for everything code related and not using Lua code at all? You mentioned using the user data when picked to get the C++ class instance you attached to the entity after the map is loaded and you cycled through the entities I assume? If I was using C++ code only and I needed tree's here is what I'd do (have done). 1) create map with trees in them and name them all "tree" 2) load map 3) loop through entities and when the entity name is "tree" create an instance of my Tree class (which is derived from my own GameObject class which has virtual functions for the LE callback functions like Update, Draw, etc) 4) assign that instance of the Tree class to my userdata of the tree entity 5) set the engine functions for this entity (Update, Draw, etc just like lua is doing) 6) inside these C functions get the entities userdata and cast it to GameObject and call the virtual functions (now you have behavior just like lua entity scripts do but in C++) 5) when picking a tree, get the picked entities user data, cast to GameObject, and call it's Pick function (another virtual function of GameObject). 6) What whatever you want inside the Tree's Pick function. So the reason I'm asking all these question is because nowhere in there do I need to have a unique name for any of the trees. So I'm confused as to why you say you do. Take multiplayer out of this because LE isn't setup for that now so you have to do all of that yourself anyway. In that case it makes sense to have unique ID's because when the user picks a tree, you have to tell the server that somehow and the ID would be how you do that. If you are mixing C++ and Lua you can pass LE entities between them in function calls. Josh does this with callbacks like ForEachEntityInAABBDo(), and other calls. So this is why I'm confused. What above won't work in your situation?

A unique ID isn't what you're using then with that system. You're attaching a key/value of say "type" = "tree". That's fine and this isn't a unique ID right? Shouldn't every NPC have a unique name anyway though? I mean you'll have Bill Cloudsmith, and Emily Smith, etc?

Yep, you can gather berries from them and eat them. 10 berries per bush with a few min regen on them. You were so close This will be something we'll play around with. Thanks for the feedback! Yeah, it's still up in the air how long day/night will be. We will try a different value next release and see what people think. This is something we've talked about. We have to think about what that means though. I rains often and if you get stuck with rain at night and your fire goes out you're basically dead . Not much fun I would imagine, but we're trying to think of ways to maybe look at this. Any ideas you have we're all ears. Thanks! We would love to have some dedicated followers who help shape the game with thoughts/comments/concerns/ideas! We will be having monthly releases around the 1st of each month. That's our goal and with 3 people working on it each release should come with it a wide array of changes to test out. Thank you for taking the time to play around with our game!

OK, so what I can gather is that your issue is after the map loads you loop through all entities to figure out what C++ code to attach to. But where does a unique name really come into this and what is an ID going to solve with this? You're only giving me pieces of your logic here so it's hard to really show an alternative method to what you are doing. Tree names obviously just need the name "tree" in them for you to know to attach your tree code to a tree entity. Once it's in a list then you don't need an ID for it because you mentioned that when a player does a pick that's how you get the entity and the code for it. So no ID required there right? What am I missing with that flow? Can you give me an example of needing an ID for a tree so I can help further because right now there is little need for an ID in a singleplayer game that I can see.

I'm just curious as to why you need the name of a tree. What I said should stand in C++ too (minus a script). If you are attaching functionality to trees then having the name "tree" should be enough I would think. You're stick doing a pick in C++ to get what tree the player is trying to chop down right? I'm just trying to help to show how we get by without needing the name that much.It's hard without a use case and specifics though. I was in your same boat but I found that I don't need the name much and only for a few things even when I have a ton of things in my scene that the player can interact with. There are maybe other ways to handle it. I can see if you are doing a multiplayer game and the player picks on teh client and you need to tell the server what tree id it is.

Every tree in our game can be cut down too but it doesn't need a unique ID for that. You pick the tree and that gives you the entity and you can access it's script if you need to. Can you give an example as to why you are wanting a UUID for a tree to chop down? The key really is everything you interact with is pretty much done through some kind of pick to get that entity. There is little need, for the most part, to loop over entities so you don't really need to find them to do that. If you do then attach a script and use that, but picking is generally, in most games, the way to get an entity to do something with.

I didn't even notice this. I just opened the editor and sure enough there is a little box there. First time I even saw it. Honestly, what you think may be obvious just might not be to some people. You have to be a little annoying to put things in people's faces or they just won't see it. In today's world if they have to click a button to open something, they are less likely to do so. There is a reason why Steam opens that window on startup. You have to punch people in the face with this stuff.

I'm assuming he means an instance ID where each instance has a unique ID. Usually an int/long value or a GUID type of ID I guess too. Memory addresses aren't generally given a dual purpose. However, I'm not sure this is really needed. I think I've asked for this a long time ago as well but honestly anything that I need to do something in code with should have (in my view) a unique name anyway. I then just get it by it's unique name.

Are you sure the code is hitting the parts you think it's hitting? Honestly you need to be placing System:Prints() in your code to make sure code is getting executed that you are expecting. If it's not then it helps lead you down fixing the problem. This could go back and forth forever so instead just put those prints in places all over your code and see what gets hit when.

What you need to do is put it in everyone's face who uses the engine. Have a splash screen pop up like Steam does when we start the engine that shows off the models and has a few pages when you click 'next' just like Steam. You need to advertise to your audience and the editor is the best way to do that. People aren't always looking for stuff, but when you put it in their face they will be more likely to buy something. They are doing this because you aren't shoving the workshop interface that's built into LE in their face. I have to click workshop menu to get there. Hell, I forget it's even there and when I remember I'm hesitant to click it because I don't want to page through so many models and waste 15 mins of my time.. You have to pop that stuff into our faces and in a better interface that shows just 10 or so that I can page through. There is so much stuff in there that it can be annoying to keep paging over and over, but if you randomly show some on start up eventually you'll hit something that catches someones eye and they'll buy it because it's easy. You aren't invasive enough with the workshop and your editor. All your customers open the editor. You have to take advantage of that. Every time I open Steam I page through their splash screen to see what's there because I know it'll only take 1 min and there might be something I'm interested in. I also page through their main page because there are only a handful of things on there. Paging through ALL the games on steam is a giant pain and takes a lot of time so I rarely do that.

I thin it's all "official" stuff vs "user" stuff. User stuff would take longer to take hold I think. Most people want "official" stuff.

Complex games take time to make and I think most people lose interest in their game before that time can come, so right off the bat the number of people who can make a better and complex game is low. Not many people can stay interested in a game like Hayden has with Hunt for Food. Add on top that most people aren't great at every aspect so making a quality game is tough for 1 person. So you either wait for that 1 special person or wait for that team to get something out OR you fill in the gaps that people aren't good at. Of course this is a lot of work for you since you're basically writing 20 different game elements and hoping someone can fill the gaps and piece things together but how good can a pieced together game really be? 1. Maybe try describing some of the qualities you are looking for in this quality game. A checklist people can work towards. 2. I'd be interested to hear why you think you haven't gotten that quality and complex game yet? Off the top of my head: Lack of saving data (can do it but kind of hacky right now with gameplayer and most probably don't even know you can in this hacky fashion) limits complexity as most people think their game has to be pretty simple without being able to save progress. Lack of a nice GUI means people spend time on their own. If we've already determined most people lose interest in their games over time then all things that take time need to be reduced. Not having a person create their own GUI helps with that.

Notice how 'context' is being passed as a parameter to the PostRender() function. Leadwerks engine is calling this PostRender function and it's giving you the object you use to draw 2D stuff (the context). So like jsk said just use 'context'

Nothing ever gets pinned around here. You'd be better off writing a program that logs into this forum as yourself and bumps this thread every week Actually that's not a bad idea lol

You can't draw text in the collision function. It has to be drawn in the PostRender() function in the scripts.

If you are doing this in an entity script then it has to be in the Script:PostRender() function. Generally you check if they reached their goal in the Script:UpdateWorld() function. What this means is you should probably set a flag in the UpdateWorld() function that you then read in your PostRender() function to tell you to draw. By "flag" I mean a boolean value. Below is a very basic example to get the point. function Script:Start() self.reachedGoal = false end function Script:UpdateWorld() if reached_goal then self.reachedGoal = true end end function Script:PostRender(context) if self.reachedGoal == true then context:DrawText("Congrats!", 0, 0) end end

I didn't look at that code you posted because it's pretty long but you would generate the dungeons in either Main.lua or if done in an entity script in Script:Start(). You could do it in UpdateWorld() if your goal was to generate it on the fly as you're moving around though. That's possible but you probably for now want to stick with doing it once on start up. I agree with nick that using a 2D array would probably be the way to go. Make each room the same size and the 2D array breaks things into a grid system and you place a new room at each grid or connector tunnels between rooms but they still are the same size.

Josh has said before that he doesn't (at this time) consider the flowgraph to be a full fledged programming tool.

I make a utility function for this when I need to. Note that every entity you use this for should be a unique name or else this will just get the first one. You could modify it if you want to get all entities with the same name to have it add to a table and return the table. function FindEntity(entityName) local x local world = World:GetCurrent() for x = 0, world:CountEntities() - 1 do local entity = world:GetEntity(x) --System:Print("name = "..entity:GetKeyValue("name")) if entity:GetKeyValue("name") == entityName then return entity end end return nil end