Rick

It's always interesting to see conventions used.They must have had the 8 character filename limitation, or someone wanted to hold it over (I've seen this even today by older programmers lol). Interesting that they put Class in every classes name. Not something you see much of these days with modern IDE's. They use inheritance over composition which is different from today's thoughts on game development thanks to the idea of entity programming. Browsing the code I'm shocked they didn't abuse the hell out of macros. That was a pretty common thing back in the day. Pretty much each method fits on 1 screen which is good, but some files are thousands of lines of code which suggest they could refactor things more. Good commenting.

CSG shape as a child in the editor?

Josh you might want to look at these Online Services. A fair amount of companies are doing it and it gives developers a way to have a lot of online features via web api calls that are common for a lot of games. It's basically your own web api on top of Azure/Amazon that helps manage user Id's, inventories, achievements, etc. Might be a good extra income source.

Call of Duty is already 190gig so it would most likely be in the TB's with something like this pushed to the max.

It doesn't use normal maps at all it seems. It just compresses the highly detailed model data (triangles), seemingly in real-time (or every few frames probably) depending on the camera distance. The closer you are the less compressed the model data would be meaning it's more detailed (more triangles). The farther away the model is from the camera the more compression the model data would get so it's less detailed (less triangles) since the eye won't notice? Basically dynamic "real-time" LOD like you noted. Since the idea of a normal map is to fake detail, and the idea here is to change detail, seems there wouldn't be much need for a normal map? Yeah, the biggest thing would be disk space, but since that's cheap and getting cheaper by the day it's probably OK. After watching more, perhaps they are compressing not every model but the final scene of the detailed models. So once you have your entire detailed screen, it then compresses that before sending to the renderer. However, my concern there would be memory of those detailed models loaded. I wonder if this would result in less unique models available on screen. PS5 has 16 gig, but that demo scene might be reusing a lot of the same assets to get around any kind of limit with what you can have loaded at once. Or maybe it's not a big issue.

UE 5 demo dropped. It talks about Nanite technology. Seems the idea is your models can be ultra detailed, no funny business like normal maps or anything just straight up source model with millions of polygons from your modelling package, just very detailed models, and this technology will automatically adjust the level of detail in real-time, sort of like tessellation, by streaming data from the model as needed. They say it's sort of like mipmaps. Just curious on Josh's take on something like this. It would be pretty cool to be able to set an overall frame polycount budget and have a system like this automatically deal with the details of how much data from the highly detailed source models that are visible to be rendered in real-time. From a long term perspective what's interesting is if that frame polycount budget was dynamic based on something from the gfx card in question, then most all computers could run most all games made this way as the models would be highly adjusted based on the power of the gfx card. On the other side, as gfx card technology gets better your game from "10 years ago" would automatically look better without any changes from the devs as the polycount budget number would become higher since the engine detects the gfx card can handle more details! Curious on opinions about this idea of streaming in highly detailed models and applying compression algo's to them in real-time to determine the level of detail to send to the renderer.

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?