Rick

This is the goal of having multiple scripts which is why some of us asked for it. I think the implementation is a little strange but we'll see how it works out.

I've waited a few years for this. Hooray! Why the change of heart? The implementation seems a little strange to me. I get you're trying to keep it simple and avoid having to prefix variables and methods with the script name but sometimes you may just really want to call one scripts function and not have all the ones with the same name called. I would rewrite your HurtEnemy() method like the below and then it's not that bad. This assumes GetScript() on an entity gets the instance of said script on that entity and that system is in place. This allows us to not have to type self.enemy as much and also reduces the indentation so it's easier to follow. function Script:HurtEnemy(amount) if self.enemy == nil then return end local healthMgr = self.enemy:GetScript("HealthManager") if healthMgr == nil then return end if healthMgr.TakeDamage == nil then return end healthMgr:TakeDamage(amount); end I don't see anything wrong with the above. It's short and to the point. It really only does 1 extra check that a script with that name is attached. To call multiple functions have some sort of self:CallMethods("TakeDamage", args)? This might not be bad anyway as it can do the check internally if it exists so we don't have to continually do that check each time we want to call a function that we think might exist.

Populating big islands is tough and if it's not populated then it'll be a walking simulator. For dev reasons it might be best to have smaller islands so multiple people can work on some maps since only 1 person can work on an LE map at a time.

I like that idea. I like being able to see that it's floating by having those peninsula's sticking out. Once the feature detail is a better scale that will look really good.

Sounds good. I'll work on this today.

Yeah, I say we give it to the end of the weekend to have, even if it's buggy, a 3rd party camera on a wizard (even if stand-in) walking around a blank terrain (even if not ideal terrain) with an intro screen. It's something to build on.

That size looks decent. Please be sure to delete the other bigger ones as the repo size is a premium for this and we need to be as tight as possible and remove any unneeded stuff.

It's hard to get an idea of how big that is without seeing the LE controller on it but that looks really big.

https://sketchfab.com/models/5507823093b4488999e236254a0018b0 This looks like something that could be used for the world hub as a place that when clicked loads a map that is kind of a tower like this?

I like this one https://sketchfab.com/models/96f7931b188c44deb28319419fa608a2 Are you sure we can use these though? This one might make more sense with the style though: https://sketchfab.com/models/2bee14d9fbf649d28ba20aad3e0c6790

All that being said about how the process works for saving at an entity level vs a global level, if each map is kind of in isolation and shouldn't take long to do then are we really needing to save any map data like in your example of a bat or acid trap? I would think each map is just a fresh load everytime.

I don't think that process uses SetKeyValue. It uses variables that are in the entity scripts. I think you mentioned that you were more on the C++ side than lua. In lua you can attach a script to an entity, and in that script you can define variables that are specific to that instance of that entity. Imagine if you created an instance of a C++ class and attached it to an LE entity. That class instance has variables and values for that specific entity. Then imagine that class had 2 virtual functions called SaveData() and LoadData(data). When you decide to save your game, every entity in the world at that time gets iterated over and it's SaveData() function called and inside there you return from it a structure of the data you want to save for that entity. When you load a saved file it loops through everything that you saved and if it was a dynamic object it'll create it from a prefab or if it already exists in the loaded map (via unqiue name) it'll call that entity scripts LoadData(data) passing in the exact same structure that was saved. That way that script knows exactly what it saves and so it knows exactly what to load. So think of entity scripts just like C++ classes that you can attach to LE entities. Same idea. The main difference is the structure you'd return in the SaveData() function because in C++ it has to either be string related or a common structure but you couldn't really have a common structure because each class could have different properties that you want to save. However in lua because it's a scripting language you can just return a table that is a different structure for each entity because it doesn't matter. It's just a table and that exact same table will be passed to that entity's LoadData(data) function. The entity already knows the table structure because it's the one that created it via SaveData() so it knows how to read it and what variables in it to set to it's entity variables. The reason this is nice is that the creator of the scripts themselves determine what values should be saved off instead of deciding that at some global level for every entity that exists. Example: So to use your example above. Let's say we have a bat in one of our levels. That bat model/entity is put in at design time in that map and a script is attached to it that gives it it's functionality. We give the entity a name like Bat1 in the map. We set a script variable that indicates it should have data saved and loaded in it's Start() function. So when we loop over all the entities on a save it'll check all their scripts for this value to decide if it should call it's SaveData() function. Let's say the bat has a health variable. So we hit the bat once and reduce it's value by 10. Let's say the health variable is now 90. Then we instantly press the save button. What happens when we do that? 1. Loop over every entity in the world 2. Check if it has a script attached to it and if it does check if it has a shouldSave variable and if it does and it's value is true... 3. Call it's SaveData() function and take it's return value (which will be a table with whatever structure, we don't care at this point but it would have something like a health variable in it that we set from the scripts self.health variable) and save that to a bigger overall table where it's key is the entities unique name. 4. Once all entities are finished that bigger overall table is saved to disk because it now has all the entities data that needed to be saved. Then we want to reload the map. 1. The map is loaded. 2. We read in the saved overall table from disk that has all entities saved information in it and loop over every entity in it 3. For each entity name we find that entity that is loaded (because we loaded the map in step 1) and we call it's LoadData(data) passing in the same table it gave us via it's SaveData() 4. Inside LoadData(data) we take data.health and set it to self.health (this bats health variable) 5. Now all the entities have their script variables set to what they were when they were saved off.

Honestly I think we're just trying to actually get something out the door. No community project has really succeeded so the main goal I think should be succeed at all costs! Show that this can be done. If we don't finish anything then all the documentation in the world doens't matter. Nobody will play or look at an unfinished game. Step 1, finish the game, Step 2, release the game to the public. Step 3, worry about highly documentation and all that other stuff for people to learn from.

Do we have anyone who can model a low poly wizard and animate it as well? I don't think it needs to be perfect or even really good honestly. With this style it can be pretty blocky. We just need something instead of trying for perfection. If he's going to have a wand he shoots thing out of I think some kind of wizard is ideal. From there as far as lore goes I'll let others think about that. I'm not a big lore guy myself.

On the workshop I did have a Save/Load script. The idea is that you add 2 script functions for a script attached to an entity you want to save/load data for. SaveData() and LoadData(). In SaveData() you return a table structure that will be saved for that entity (unique names of entities acting as it's identifier). LoadData() has an argument which is that entities table that was returned from SaveData() so the entity itself determines it's own data structure to be saved and loaded. This helps remove any sort of global way of needing to save information. Here is a post I replied to recently about someone using it:

Separate. I'll fade between them. For now we'll disable the options button I think. Just have it as a placeholder. Yes, please find a cool font and I'll use that with the plain text options.

My plan is to have this part of it finished by the end of the weekend. Have some things going on but game if you could get the "Powered By Leadwerks" logo, and some New Game, Exit, Options, etc buttons in the next couple days that would help. Thanks!

Do you mean wand? You wrote ward. Just clarifying. If you think you can do the "heat seeking" of the magic following a moving target then I don't see anything wrong with that. It allows for future expanding by possibly adding different element types to shoot which could come in handy for puzzles. Ice to freeze things, fire to melt things, etc but getting the core mechanic first would be fine with me. Remember that everything we do isn't set in stone and can be changed or scrapped later if things don't fit. I like how we can sort of organically shape this game as we go.

That first picture is a big map relative to what we would be able to do. I know it's not big in the sense of today's AAA type games but that is a big highly detailed map for sure and would take way to long for us. I know you weren't saying do that specifically but I'm just pointing out anything like that I think would take too long and is too detailed. To me that looks like a more world hub map because it has such different zones. I can imagine clicking on each zone to load in just that specific part. That actual map is probably still too detailed for a world hub map but the idea of having very different biomes like that does makes it a good world map I think. The red circles would show entire clickable areas that load that specific map. This world map would be way less detailed and low poly but get the point across of the drastically different areas that you can load. Perhaps we could have fog on the entire map but the first one you can do doesn't have fog. Then after you do it we can decide on 1 or more to remove the fog. If the fog is set in a way then we can expand as much as we want without having to decide right up front how many areas to have.

I think we need to decide on the exploration idea. Are we really wanting vast terrains so exploring is a thing? It's hard to feel like you're exploring within a small terrain. When I think floating islands I think smaller terrains not larger ones which is what I was going from. Larger terrains require populating which will be a roadblock for a small community project. We also don't want it to be a walking simulator. How long are we expecting each map to take a player to complete? Are we thinking many quick short maps or fewer longer maps. I generally go for smaller maps that users don't spend a ton of time in as we can more easily complete a smaller area and it makes it easier/quicker to extend the game in the future by making more maps. Since LE doens't allow 2 people to edit maps at the same time it's also just 1 person making a map. The smaller those maps are the easier that'll be to manage from a development perspective. Smaller maps that can be made in a shorter amount of time and put in front of the gamers vs a longer dev cycle with larger maps due to having to populate them.

Given each map is relatively small and it's a low poly look I wouldn't think vegetation would be any sort of bottleneck for the game. Paths would then be the question. LE built in doesn't do anything like that does it? I think Aggror had a workaround for it but that can't be better than some built in tool for that in a modelling package since LE doesn't really allow much support for that kind of add-on.

Not that I know blender or if anyone on our team is using blender but found this which seems to be pretty easy. I would imagine other modeling software has something similar? https://devforum.roblox.com/t/how-to-make-a-generate-a-low-poly-terrain-in-blender-in-less-than-10-seconds/87161 Seems like it doesn't get much easier than something like this. I suppose paths and roads is where it would get harder but I assume modeling software has that covered as well?

With that kind of low poly style I don't think LE's terrain can duplicate that look well enough. Is there some terrain module in some art software that makes it easy to make random low poly terrains? It's probably better to start with a random kind of terrain and edit vs making 100% from scratch.

I'm going to make this process a MainMenu map in itself. When the game is ready for go live we can just make that the default map that starts, but when testing gameplay keep the default map one of the level maps.

Yeah, add those menu button images too. We can see if that works better than plain LE text