Ambiera ForumDiscussions, Help and Support. |
|
| [ 1 2 ] Page 1 of 2 |
|
|||||
|
In my game, I want a certain event to only be possible after a certain amount of area is covered (walked over). I'm not sure how this would be done, but (for example) if a person's foot was about 12 inches long and single step is about 1.5 ft. in distance, Each step is about 2.5 feet of total distance covered (if my math is correct). Thus 10 paces would be about 25 ft. Well, in my game, it's a wolf's paw, so that would be about maybe 6 inches, since he's walking more or less on his toes (as wolves do), but the distance between steps would be about the same. How would you go about keeping track of how far you'd traveled in a given direction? Would you calculate the total walkable area, then subtract every step from that, or...? |
||||
|
My dearest friend, you finally back. All this months I'm waiting to continue the furry fairytale. I think you should use another approach. Just set up dummy objects around your map. They all are "not visited" in the beginning. If player gets close to one, it becomes "visited". Now you know total amount of objects, and know how many of them are "visited", so you just divide visited/total, and get your percentage. You can even set up this objects programmatically as your scene strats not to waste time doing this by hand. If you want to measure the walked distance, you can get your player position every frame and store it. Next frame you get the position again, and calculate distance between them. Now you just need to accumulate the distance to a variable. If total value seems not realistic to you, since coppercube uses units, which are not meters or wolf feets or whatever, you can just multiply total distance to some magic number, which you can adjust based on your preferences before showing it to the player. I can kindly implement these for you tonight, if you promise me to release a new version in the near feature. |
||||
|
wrote: My dearest friend, you finally back. All this months I'm waiting to continue the furry fairytale. I think you should use another approach. Just set up dummy objects around your map. They all are "not visited" in the beginning. If player gets close to one, it becomes "visited". Now you know total amount of objects, and know how many of them are "visited", so you just divide visited/total, and get your percentage. You can even set up this objects programmatically as your scene strats not to waste time doing this by hand. If you want to measure the walked distance, you can get your player position every frame and store it. Next frame you get the position again, and calculate distance between them. Now you just need to accumulate the distance to a variable. If total value seems not realistic to you, since coppercube uses units, which are not meters or wolf feets or whatever, you can just multiply total distance to some magic number, which you can adjust based on your preferences before showing it to the player. I can kindly implement these for you tonight, if you promise me to release a new version in the near feature. Thank you for the warm greeting!  However, I want the most accurate "tracking" possible, for area covered (walked distance). Since Luposian has a looped "walk cycle", which consists of two steps (which repeat), then we need to know the covered distance of one "cycle". If we assume the aforementioned 1.5 feet (18 inches) between steps and 6 inches for each paw print, that's 2 feet per step, so a total distance of 4 feet per "cycle". If we assume his body is about 2 feet wide at the shoulders/hips, that's a total of 8 sq feet of covered space per cycle. |
||||
|
I believe, you should not think in terms of real life sizes - what important is relation between model size and world size. Tbh, I think you should do it the way I described, since it's much easier to implement, and you will have pretty much the same result. With your approach you still need to track which parts of area are covered, so you need to keep that data somehow - so you will still use a 2d array to store x,z coordinate of "zones" which are already visited - which is pretty much the same I'm suggesting. I also don't think your approach will work, since players can, for example, run into an obstacle, which will change character speed. Or release move forward key before the whole step is completed. And you need to handle this for both running and walking scenarios. Also just think about what benefits will you get? It will be more precise probably, but players will never know that. It even might be more frustrating, since it's much easier to hit a bigger zone, than try to find an exact little area that they didn't visited yet. Overall, you will create an over complicated system, which has potential for a big number of bugs (related to variable speed like hit into obstacles or spamming move button instead of pressing it), could be frustrating for your players, since they have to find a very specific area which they haven't visited yet. You also will have to store a bigger amount of data, and do heavier calculations. And what are your benefits? A higher precision. Do you really need it? So, think about it. I still offer you to implement systems I described completely for free. |
||||
|
There is a behaviour known as calculating distances, it is exactly what you need |
||||
|
Trying to calculate every detail like that is not the way of game programming. Making game is about faking things for player to feel real, not trying to make everything work like in real life. |
||||
|
C'mon, listen to Guest - he never gives bad advices. It's a fair deal - you complete your game faster, I play it. I'll put all code in separate behaviors, so if you don't like it - you can just remove it with a single click and replace with any implementation you want. CC0 license - completely free to use and no attribution required. I will also publish it here, so you could be 100% it's safe. |
||||
|
Here it ishttps://drive.google.com/file/d/... My initial idea with nodes didnt' really work, since you need quite a lot of them even for a small level. I won't get into details, but basically, I divide the whole map into small zones. Each zone is a part of a bigger cluster. First, check if player is inside the cluster, then check which exactly zone. By default there are 256 zones for a default coppercube map size. I hope it has a decent performance, at least my 8 years old i7 is able to run it with no issues with 83k zones total. After that coppercube fails with out of memory. If you have an ok PC you can actually set clusterSideLength parameter to something like 16 which will give you total 65536 zones. Also set polling parameter to something like 15 ms. That way you can check how annoying it will be for a player if you meassure the covered area more precisely. |
||||
|
wrote: I believe, you should not think in terms of real life sizes - what important is relation between model size and world size. Tbh, I think you should do it the way I described, since it's much easier to implement, and you will have pretty much the same result. With your approach you still need to track which parts of area are covered, so you need to keep that data somehow - so you will still use a 2d array to store x,z coordinate of "zones" which are already visited - which is pretty much the same I'm suggesting. I also don't think your approach will work, since players can, for example, run into an obstacle, which will change character speed. Or release move forward key before the whole step is completed. And you need to handle this for both running and walking scenarios. Also just think about what benefits will you get? It will be more precise probably, but players will never know that. It even might be more frustrating, since it's much easier to hit a bigger zone, than try to find an exact little area that they didn't visited yet. Overall, you will create an over complicated system, which has potential for a big number of bugs (related to variable speed like hit into obstacles or spamming move button instead of pressing it), could be frustrating for your players, since they have to find a very specific area which they haven't visited yet. You also will have to store a bigger amount of data, and do heavier calculations. And what are your benefits? A higher precision. Do you really need it? So, think about it. I still offer you to implement systems I described completely for free. There is another version of the game I don't think I uploaded, as the change was too trivial... the inclusion of pawprints. Very faint pawprints. So, you do have a way of visually knowing where you've been. So, your scenario of "spamming the move button" is not quite so likely. As well, since the storyline is unfolding as you play, you don't know what you don't know. You just wander around, exploring, until something else happens or changes. But spoken/subtitled dialog helps lead you in the right direction, after awhile. But that part hasn't been added. And some stuff needs to be removed, to make Stage 1 complete and ready to release. 
|
||||
|
wrote: Here it ishttps://drive.google.com/file/d/... My initial idea with nodes didnt' really work, since you need quite a lot of them even for a small level. I won't get into details, but basically, I divide the whole map into small zones. Each zone is a part of a bigger cluster. First, check if player is inside the cluster, then check which exactly zone. By default there are 256 zones for a default coppercube map size. I hope it has a decent performance, at least my 8 years old i7 is able to run it with no issues with 83k zones total. After that coppercube fails with out of memory. If you have an ok PC you can actually set clusterSideLength parameter to something like 16 which will give you total 65536 zones. Also set polling parameter to something like 15 ms. That way you can check how annoying it will be for a player if you meassure the covered area more precisely. Alrighty then! I just tried "playing" your example code and I like it! It marks percentages and meters. In the short time I walked around (avoiding the hills... as you won't be able to climb them initially - that's one part that needs to be changed for Stage 1), I covered 25% and just over 330 meters or almost a quarter mile. That's some good exercise right there! You know how to prevent my character from climbing the hills? I know decreasing gravity made him able to walk around without getting stuck on the terrain, but could you turn max gravity on when you touch the base of the hills and change it back to the previous gravity as soon as you step away from it, or would you get permanantly stuck in place? That way, you're covering only the flat terrain between the hills, Otherwise, I'm assuming something similiar to the barrier around the edge perimeter would be what you'd use. But I'm not a programmer, so I haven't a clue how to implement it. |
||||
|
Nice, I'm glad you like it. Regarding the hills - if you're using built in terrain just use invisible walls. It's a simplest, fastest and most reliable way. 1. Think about the wall shape which works for the particular obstacle. Basically you have your plane, box and cylinder. For a hill, probably cylinder shape works the best. 2. Add a cylinder to the scene, move and scale it to fit the hill: 3. Add a small completely black texture and apply it to the cylinder, uncheck Occludes light, change material to transparent (add) I think this is something that you're already doing with the map boarders. There are other ways also: you can try to mess up with gravity, or pick up an extension which aligns a model to the ground, attach it to some dummy model and use it as a leveler, so if angle is higher than a threshold, you set player move speed to 0 or something like that. But I'd say go with invisible walls, it's much more reliable. Currently, area coverage just divides the whole area to zones, so it considers the whole area walkable. Probably, it's a good idea to be able to exclude certain zones, so they are not used in the calculation. I will look into it. |
||||
|
wrote: Nice, I'm glad you like it. Regarding the hills - if you're using built in terrain just use invisible walls. It's a simplest, fastest and most reliable way. 1. Think about the wall shape which works for the particular obstacle. Basically you have your plane, box and cylinder. For a hill, probably cylinder shape works the best. 2. Add a cylinder to the scene, move and scale it to fit the hill: 3. Add a small completely black texture and apply it to the cylinder, uncheck Occludes light, change material to transparent (add) I think this is something that you're already doing with the map boarders. There are other ways also: you can try to mess up with gravity, or pick up an extension which aligns a model to the ground, attach it to some dummy model and use it as a leveler, so if angle is higher than a threshold, you set player move speed to 0 or something like that. But I'd say go with invisible walls, it's much more reliable. Currently, area coverage just divides the whole area to zones, so it considers the whole area walkable. Probably, it's a good idea to be able to exclude certain zones, so they are not used in the calculation. I will look into it. Is the ground (where my character starts) considered 0, vertically? Therefore aren't hills and mountains considered higher than 0, visually as well as mathematically? If so, when you start to climb a hill/mountain, if you go beyond a certain elevation (beyond 0), you just stop moving forward. That would look most natural, because you wouldn't be hitting an invisible, perfectly round barrier, where, maybe there was a spot you COULD move forward, but can't. Your limitation to climbing would be completely elevation based. The base of the hills/mountains are not perfectly round, so running into an invisible barrier that WAS, would look kinda fake and contrived. The perimeter of the game field makes more sense, because it's a flat edge barrier, preventing you from falling off. But we don't want the inability of climbing the hills/mountains to seem like a direct barrier, but more like he has a better idea or a curious thought provokes him to explore the flat lands a bit more, instead (hence the area tracking routine). I'm likely going to add in dialog/audio for this. I need to re-read my storyline to make sure I lay this all out correctly. I want the game to play out like the storyline. |
||||
|
Here's the first part of the storyline: In One’s Beginning (Game Storyline) Consciousness slowly swam up from the depths of non-existance, to a hazy awareness. The sound of a breeze blowing and the mild warmth of it, blowing upon him, encouraged him to open his eyes. Yet, oddly enough, there was little for him to see, staring straight up. He had no idea what he was looking at. Had no idea where he was. Or who he was… or even what he was. His consciousness was simply that he was. In the moment. The now. And every moment that passed thereafter. Just an unwinding eternal “now” was all he knew. No memories of a past. Nothing to give him any bearings of how he got here or where here was… or why he was here. Just that he was... where he was. He slowly rose to his feet and looked around. He could see hazy outlines of mounds nearby. But this haze persisted all around him, in every direction. He could see fairly clearly maybe 25 feet in any direction, but the haze increasingly obscured everything beyond. Unless he moved. The circle of visibility followed him everywhere. He found this somewhat strange, but with no reference as to why, he simply accepted it. He wandered around, aimlessly, going off in one direction for awhile, then heading in a different one. He was looking for something. But he didn’t know what. But he felt lead. Even pulled, to discover something ‘out there’. After wandering around for awhile, though he had no reference of time, so no need to hurry, he looked down and noticed imprints in the ground. He lifted his foot. Yup, same pattern on the bottom. “I must’ve been here before.” he says to himself. “But is this where I started or somewhere else I’ve already been? No sense in doing that again. I need to find a new direction or area I haven’t explored.” And, as he went in directions and areas he hadn’t been, more awareness made itself known to him. Like bits and pieces of memories… or a puzzle... or something. And, after awhile, though he had no idea how long, he suddenly looked at one of the mounds he was closest to and had a thought… “These mounds are higher than the ground I’m walking on, maybe they’ll give me a vantage point.” And so he endeavored to climb the mound closest to his current position. And the closer to the peak he climbed, the more the haze lifted. And, upon reaching the plateau, he rested for a moment before looking around at the scenery. “Whoa! This is amazing! Like I can see for miles!” and then, out of the corner of his eye, he catches a glimpse of something. “Hey, wait a second… did I just see what I thought I saw?” [… TO BE CONTINUED…] |
||||
|
Is the ground (where my character starts) considered 0, vertically? Therefore aren't hills and mountains considered higher than 0, visually as well as mathematically? If so, when you start to climb a hill/mountain, if you go beyond a certain elevation (beyond 0), you just stop moving forward. That would look most natural, because you wouldn't be hitting an invisible, perfectly round barrier, where, maybe there was a spot you COULD move forward, but can't. Your limitation to climbing would be completely elevation based. The base of the hills/mountains are not perfectly round, so running into an invisible barrier that WAS, would look kinda fake and contrived. Yes you can also do that, but also remember, that the player can not only move forward but backwards. You can set a height threshold, and set movement speed to 0 if this is reached. It has its own limitations, like you will not be able to use vertical levels, so no second floors, tree houses and etc. You also need to add a sliding mechanics as the speed is set to 0, since other way the player will stuck on top of the hill no being able to move. Actually even with sliding mechanics added there is a possibility that the player will stuck - it means this should be tested properly. Good thing is that it's quite easy to implement. If you want to do it like that - I can make another extension for you tonight. Also Luposian, my man, keep focused. No one will care if they run into an invisible wall or slide from the hill, if they are not playing a platformer game and jumping is a main gameplay feature. And as far as I understand, you're making something like a narrative adventure, not a platformer, or real life walking simulator. You need to focus on major things: story (which is the main reason people play narrative adventures) and your game mechanics (which will keep players busy, while they discover your story). And you haven't introduced any of gameplay mechanics yet. It might be puzzles, enemy fights, dialog system, stealth, whatever. You need to start focusing on that, since this things really have an impact. I would say, think about things to keep player from getting bored. Decide how this things should be implemented and how they are integrated into your story. Focus on this things and your story. Implement everything else with a fastest, cheapest, and most reliable way you can think of. That way you will complete your game. Otherwise you will stuck. I will tell you exactly what will happen: you will have a ton of complex useless features which do not work with each other. You start spending more time on very important stuff like changing fonts, updating green color of your menu to be less green, calculating the exact foot length based on knowledge you got from all wolf related books you found in your local library. Once again, keep focused on the important things- write down gameplay mechanics you want to use. I'll get back to you with hills sliding implementation tonight, guess you'll see it tomorrow morning your time. And so he endeavored to climb the mound closest to his current position. And the closer to the peak he climbed, the more the haze lifted. I also suppose this is not possible in-game with the approach you suggested. You will have to use a cutscene for that or disable the height threshold feature. |
||||
|
"And so he endeavored to climb the mound closest to his current position. And the closer to the peak he climbed, the more the haze lifted." I also suppose this is not possible in-game with the approach you suggested. You will have to use a cutscene for that or disable the height threshold feature. I don't imagine EVERYTHING will happen in the game EXACTLY as the story tells it, but it will be generally the same, as close as possible. Yes you can also do that, but also remember, that the player can not only move forward but backwards. You can set a height threshold, and set movement speed to 0 if this is reached. It has its own limitations, like you will not be able to use vertical levels, so no second floors, tree houses and etc. You also need to add a sliding mechanics as the speed is set to 0, since other way the player will stuck on top of the hill no being able to move. Actually even with sliding mechanics added there is a possibility that the player will stuck - it means this should be tested properly. Good thing is that it's quite easy to implement. If you want to do it like that - I can make another extension for you tonight. The area tracking and elevation limiter are only temporary. Once you've covered 25% of the level ground, both functions are no longer used. Tracking is no longer needed and elevation limit is no longer needed. Stage 1 is a little bit of a puzzle you need to figure out. But I want those puzzle pieces in place.
|
||||
| [ 1 2 ] Page 1 of 2 |
|
|
){kind=link}