Rick

Honestly it would be better to have a separate table for all the different ammo type counts. Ammo and weapons are different things so it makes sense to store them differently. I'd then fill out this ammo table with each ammo type and just set their counts to 0 to start with.

No, you are not forced to use Lua. Using pure C++ is just fine.

When you create a new project, there should be an option for a blank project.

"Ideal" is sort of misleading. Easy would be more the word. Leaving it up to the client creates lots of cheating possibilities. This again depends on the game as well. If it's a slower paced game you can run the movement on the server and have it send position information to the clients and just smoothly move the clients based on the server positions. A turn based or RTS could do something like this. There is latency from the command from client to server then getting information back but often these kinds of games can mask that in various ways. In some games the character will do a little animation acknowledging the command like "Yes, sir" with a little solute, then start moving. That time is meant to mask the delay of this communication. If you're doing an RPG of sorts you can get away with having the client do all the movement and just send the positions to the server and have the server validate certain things like are they moving to fast (speed hack), did they move through walls, etc. If you're doing a fast paced shooter than that's the hardest networked movement to get right and there are many topics online about that.

To me it sounds like you're talking about 2 issues really. The first one being GoToPoint() with high speeds isn't doing what you think it should be doing. It clearly has some kind of smoothing curve movement which means it can overshoot the points by a lot causing some issues. Then you're worried the client will do the same. Network movement code can be a pain to work with honestly and it all depends on your game style.

The above code doesn't seem to be networked and that seems to be the issue you're having right? So you have other code for that? In that code do you keep calling GoToPoint() in a loop? I seem to recall, and this is a long time ago so if I'm wrong I'm sorry, you shouldn't be calling GoToPoint() in a loop. Instead call it once, then check if you're at the next point and once you hit it, call GoToPoint() again, then same thing.

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.

@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.

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.

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?

lol

Tessellation should really help to add detail to our games! It seems like I don't see a lot of tessellation in games that I play these days. I wonder why that is because if I recall the tech has been around for 3-5 years already?

The bots are having conversations with each other! After the human race is all dead bots will still be replying to each other on forums and the aliens that find earth will be very confused.

So in the scene graph you have a camera object as a child of your player pivot? If that's the case then from your script that is attached to your player pivot you'd do something like this in the Start() function: self.camera = self.entity:GetChild(0) This assumes you only have 1 child to your player pivot and it's the camera. If you have more than one child I think you can use self.entity:FindChild("camera_name_here") Scripts don't automatically get variables like you're thinking because they are children or parents of things, but there are ways to get them with GetChild(), FindChild(), GetParent() calls. This isn't 100% ideal though. Ideally you'd create a script parameter and drag and drop the camera in the scene graph to that parameter. To do this at the top of this script add: Script.camera = nil --entity Then when you select your player entity in the scene graph you'll see the camera parameter show up. Drag and drop the camera to this slot and now you've made a link between the camera entity and this script camera variable. Now you can use self.camera in your script. You can do this with any entity btw.

If this is your entire script then you can't just do self.camera like that. As the error is saying self.camera is nil. Just curious as to your thinking on why you think it would work as it can help explain why it doesn't better.