Rick

How did you create that map? I thought LE5 didn't have an editor yet?

@gamecreator What would you say in your and Jorn's experience during that project was the issue (you mentioned it worked OK not great). Just curious on others viewpoints on that topic.

@gamecreator It's a tough balance because being the only coder on a team like that can be overwhelming too. Perhaps 2 coders is ideal but with very clear separate ideas on what they work on. One being player oriented and another world event oriented (this would be the single scripts like buttons to open doors, puzzle things, etc). That would probably work better as they won't step on each others toes. In such a situation the player coder always has the hardest job though. Correct movement (some games can be elaborate in this), inventories (this is a whole thing of it's own), weapons, etc are no easy task to get all done by 1 person. In bigger AAA games each of those things I just listed would be done by a handful of people because they can all get complex and be elaborate over time. I really think an interface for proper communication between these systems is the most challenging but most beneficial thing that could happen to a community project. The fact that still today LE doesn't have any sort of generally accepted inventory system that people are using and tweaking is not good. After all this time we have nothing that is shared by anyone and works well? Go to Unity asset store and type Inventory Systems. There are 54 and a reasonable amount are free. LE has nothing. Aggro tried making a generic one but he found out the LE editor and no universal way of communication between things just makes it difficult to create a good system in LE. It's a shame really.

Just my notes. I initially signed up, but honestly after seeing how the design of the game was taking off I could tell it was just too big of a design to really get completed. This tends to be the biggest issue with community projects, and all projects in general honestly. The scope really started to creep and it became too much to realistically get done by a bunch of random people over the internet. The good thing about these community projects is different techniques get used on each one and little by little we learn.One big issue is working styles. Everyone has such a different way of working and that can make things difficult for a game where consistency across everyone is really needed to make things fit together. When a person is paid well they are happy to conform to a standard, but when they aren't paid at all they tend to just want to do their own thing. The Leadwerks game engine is so open ended and doesn't try to funnel people into a certain way of creating a game and that makes it challenging in a setting like a community project. The one common theme between all of this generally seems to the scope of the project though. When you try to keep the scope down it means you don't need that many people and usually these things get 5-10 people who jump on right away. Then if the scope is small there is nothing to do for most so they fade away. However, if the scope is large then things get out of hand real quick. The larger the scope the more communication needed between people and since this is a hobby and time varies what could take an hour in person if it was a job turns into days and them motivation gets lost and a downward spiral happens. When I tried leading a community project I wanted to try a very different approach to see how that would work. I had a framework for coding that I tried to get people to work within. The idea was each person could work on isolated code from anyone else and as long as the inputs/outputs matched up (I was the one to communicate this between the programmers) things would connect perfectly. The idea was much like lego blocks. As the architect I would determine all the blocks needed and assign the work to programmers. Then I'd connect the blocks of code they wrote. This had various degrees of success but often it came down to people had the idea of the final project and everyone wanted to add their take on it and had an opinion of what should be done instead of what was asked of them. That's the hard part with a community project. Everyone wants to also be the designer as well (very justifiable) but when everyone on the project becomes a designer bad things happen. In the real world people do their role and things work out much better that way. This is true for anything in life big enough to warrant multiple people working on it. If every construction crew member thought they should put their architect skills at work while making the building, the thing would never get done and even if it did, it would look way different than the original design by the actual architect. While the construction crew might think things don't make sense while building, it's their job to build the thing, not question or redesign it. This idea is very difficult with a community game project but I feel is really the best way to do one as it is a best way to build a building. Same concepts. I still think a fairly tight game framework to which everyone on the project works within is the best way to get it done. LE is too open for that at the moment. Yes, it's nice to have a lua script per object, but games require interaction which means scripts need to often communicate. There is no defined way that works across many people working on scripts at the same time. Accessing script variables or methods directly from other scripts leads to issues when those things change by another programmer or aren't defined when you need it. It's best if scripts can be done in isolation and tested in isolation and the communication between then can be hooked up later with minimal effort. It's all about the communication. In both people and code.

The sequences you are describing would be actions in the behavior tree. They can be coroutine enabled methods. The benefit of the behavior tree is in structuring those conditions and actions together via configuration. It's the branching part that you mentioned of when to do what sequence. While it's fine Update() isn't used it's all being done in a loop somewhere either way (running the corourtines until they are dead) so either way. A behavior tree call in Update() would be behaviorTree:Update() anyway. You'd read the image attached left to right top to bottom. The tree is iterated over every tick for each bot. Each tree instance gets a "blackboard" which in lua would be a table that all child nodes can share. This is how nodes can store data and other nodes read it. You can do all sorts of tricks with the blackboard like add timestamps to each piece of data and some bots can remember only so long ago where others can remember longer, etc, to add cool effects. A neat feature of a tree is that sub nodes are just a tree in themselves, so you can add sub-trees to existing trees at run-time. That can create sort of a learning ability in bots, which for this game probably wouldn't be used much, but it's a cool concept.

You know me I'm a systems guy lol! In the Dino game we did we used behavior trees. I found a lua library that supported that then used this site https://github.com/behavior3/behavior3editor/blob/master/README.md to visually design the behavior tree. I export to json I think it was then read that in and made some code to create the correct lua behavior library data structures. Since behavior trees are pretty standard AI mechanism these days I'm sure there are even more resources/libraries around this now compared to 5 years ago or so. This would really help extend AI behavior well beyond manually coding them. You code the specific behaviors and conditions then assemble them via the tree so decision making becomes easier to "see". Makes it easier to understand what is going on in an otherwise sea full of if statements that ends up happening in this kind of stuff. Make it more flexible to change too.

I feel like what we found from the first person player script, was that a very linear way of designing this functionality leads to "messy" code that was hard for people to understand and extend. It's not necessarily about the number of lines of code that you write that makes something easy to understand and extend. It's about the end users experience while using your code. Often to make the end users experience easier and more extendable you have to write a good amount of code making systems. I feel like aiming for any amount of lines of code would be miss this goal. Looking at it from the standpoint of extendable/flexible systems and then just doing as much code as is needed to make it work would be ideal. Coming at the problem from the standpoint of a potential modder in something like this might yield better results. This would mean having a weapon system where it's very easy to make their own weapons with very little code, not copy/paste type code. This means movement systems to adjust things like speed, gravity, etc would help a developer extend or configure different classes. Thinking in terms of lines of code that you have to write to create such an example would really put you in a box. Let the users easily play around with stuff first. Then as they get more interested in learning more about tweaking your systems then they'll have the patience and attention to dig deeper. Also, it helps compartmentalize the design ideas. If someone wants to tweak something in the core system for weapons they know exactly where to do that. In the weapon systems. With something like the first person player script everything is intertwined together and it's very difficult to follow a script like that as different ideas bleed into each other in 1 script. These are probably not ideal situations with something like this. Just my thoughts on it and the past design ideas around creating things for users to learn and tweak in which this seems to be going down a similar path. It will get similar results.

Do we have Enter, Collide, Exit collision functions in LE5?

Just a different take on this perhaps use GetEntityInAABB would be a better approach so you don't have to store pointers of other entities within other entities or have access to global lists or anything like that.

Changing font is a state kind of action. When you change it, it's then set for all drawing of text. So you have to change it, draw your text, then change it back to what it was. What timer are you talking about? You have some timer code somewhere? We'd have to see it.

There is a documentary on Netflix about this. Watch until the end and you'll understand what this flat earth movement is all about. The earth isn't disc shaped.

What I would do is create a new map called StartGame.map or something like that. You won't have any 3D stuff in it (maybe you would later if you decide to have the start menu 3D background?). In the map add a pivot and attach a script to it. In this script would be where you draw all this stuff in the PostRender() function of the script if you're using images for the buttons or in the Start() function if you want to use LE's UI. Then when buttons are clicked you load the new map that is your actual game. You can see how to load a new map in Main.lua file but I think you just set a certain variable to the map name and then it'll load it.

So you're using the veg system for positions/rotation only? If you are replacing every tree in the veg system with an instance of a model, that's what you said right? I would think you would lose performance of the veg system then if you did that right as that has billboards and such where your model instances wouldn't or are you doing your own LOD type thing and that's what the distance check is for? I was thinking you were replacing the veg trees to instance models JUST around the player since if possible that would really be all you need to do, but the problem is being able to tab into the veg system to do something like that.

This looks cool but it seems it may not be that efficient? If I'm reading it correctly you're loading the tree model for every vegetation model that exists on startup. Then inside each of those models you're checking the distance to the player to determine if you should do something. Just thinking that's a lot of checks happening per game loop. Could you not go the opposite direction and do AABB check in a range around the player, then loop only through those to make them real models vs veg? Keep that list so the next iteration when you loop again you can tell which ones are no longer in the list and change those back to veg vs model? Seems like you'd loop through a lot less veg overall each iteration. Where are you able to manipulate the veg system to hide specific trees? I didn't think they were accessible that way?