I came to you all about this because my loud, proud ego finally said, âOkay, you canât do this on your own, SOR-REEEE,â and went off. I think it also muttered something about me being a doofus.
My main issues:
Using player IDs to relay to other players
Tracking everyoneâs position and returning whoâs closest to you for everyone
Donât know how big the FOV is, need the in-between measurement of the extended and regular (Minor Issue)
How it will work:
The system will check for anyone whoâs in the FOV.
If that returns completely false, it will check for whoâs last been in the FOV.
If that returns true, the system will check how long theyâve been out of the FOV.
The system will track everyoneâs coordinates the whole time, and estimate where the player shot if anyoneâs been in the FOV
The system will calculate how wide the estimating range is based on how long a playerâs been out of the FOV (If for 5 seconds, it expands to 180 degrees, the limit)
The system will pick a random trajectory
The system will simulate the projectile so as not to be âinstantâ
If a player is in the way of that âprojectileâ, the system relays to that player and takes away regular health (Hard) and/or pseudo-health (Easy)
a. If using both (Medium), the system prioritizes pseudo-health. If the player dies before it reaches zero, it is a âfalse deathâ, meaning it âdid not happenâ.
b. If using regular health (Hard), the system relays to that player and heals them fully. The damage is added to how much the player healed, and then that becomes the damage. i.e. Player is at 76/100 HP. Healed fully, so the system calculates how much they healed, 24, and adds that to a Common Pickaxeâs damage, 1. The player is now shown that they are at 75 health.
c. If using pseudo-health (Easy), the system decreases by the gadgetâs known damage. The player is not reported dead unless they reach 0.
Now, that may be a lot, but once we break this down, we might be able to figure it out and possibly make it as memory-efficient as possible.
Constants:
All players are tracked
The game MUST know that they have a certain gadget and uses its database to see the speed, range, and damage of the projectile
Measures the FOV
Ask me any questions and Iâll try to clear it up for you.
Happy Gimkitting!
I still think you shouldâve done this by yourself.
First, we are tracking everybodyâs coords, that way we can see if they are in the FOV.
To check if they are in the FOV is simple enough.
Why are you using player IDs?
This sounds like FFA (correct me if Iâm wrong), in which case triggering playerâs team number would work much better.
We only need 9 properties (not including the basic coord variables). Weâll start with the first 4: xmin, xmax, ymin, ymax. These hold the playerâs FOV in coordinates. Weâll have to make them global, which is fine. The 5th property is playerID (confusing, I know, itâs just saving which player weâre talking about).
The way this works is it cycles through each player, seeing if Player Aâs adjusted FOV correctly fits the coords of B. To do this, weâll save the correct values of A to the first 4 properties, then use a relay to call on B, use checkers to compare with Bâs coords, and if ALL true, then theyâre in the FOV, and we call back on A (using the playerID property), and add them to the list or remove them. Simple block code using text strings, like: â1,2,13,â. Just have our 6th property hold whoâs in our FOV. Our 8th and 9th variables were used to hold Bâs location (if in FOV), and those are stored in the 9th variable, FOVcoords. These hold the coords corresponding to the 6th property. These will have to be updated each time, and make sure theyâre in the same slot as in the 6th property. Again, text string manipulation, not the hardest code in the world bid it doesnât take over 75 blocks.
Well hopefully that helped, but I have to go to school now (first day) so I canât talk about other stuff, but I tried my best
So like, the sender, AKA the player trying to see the closest player to them. Maybe use tracking devices and some comparing? Iâll try and find your solution!
Iâve found out 2 more ways to make hit detection.
1- Prediction. This is generally less âdetectionâ and more ârandomizedâ, but simpler and uses less memory than directional tracking.
2- Directional Tracking. This uses pseudo-projectiles. There will be 8 (or more) directions- North, East, South West, and all those in between.
It uses the changing coordinates to decide which direction itâs going. The more directions it chooses from, the more memory it uses, but it gets more accurate.
More complexâŚ
Directional Tracking, because prediction is not reliable in a sense that the error possibility is higher. The cons outweighs the pros. However, as complex and memory-wasting as directional tracking may seem, it is the more direct approach as you are literally calculating which way youâre going, unlike prediction which is very indirect and does not calculate at runtime, instead it calculates the chances you would go that way .
Not sure if this would help, but I made directional tracking on a small scale in this guide:
Thereâs only 2 problems:
The ball & goal limits
I didnât actually damage people. I guess we could use a zone system to match the capture zones and deal damages to them, but weâd have to put some thought into it.
Also, the system isnât very accurate because of the ball & goal limits. Feel free to discus.
That was a nice system for the TD, Bird! Though itâs not what I was looking for.
That ball is kind of a nuisance when trying to move it across the map, if we were to try to solve the ball problem.
Zones are also inefficient, which means it adds much more memory than is needed. We need something else entirely, and that means⌠THE COORDINATE DEVICE! (add popcorn crunch here, editor)[1]
I kinda have it set up in my mind, but as I said in other topics (with a little bit of ego boost), I need to model it to actually make a guide about it.
You actually have been a great help, Bird. [2]
Of course you could use the coord device, I was just worried about it not lining up.
⌠until I remembered grid snap lol Iâve never used that thing.
Care to elaborate? Exactly what is this model you have in your head?
Let me rephrase. I need to make it to make a guide.
Iâd say to have an equal balance between accuracy and memory, thereâd be 12 directions.
The coordinate device will track the nearest player and deduce which "direction theyâre going.
Then the game heals the target to full, and damages them so that the regular health wonât interfere with the pseudo-health.
I donât understand why youâre healing them to full again. Canât you just have a damaged with the correct damage for every gadget type and then just deal the damage?
Also are we talking about directional tracking or random hitting? If the former, how to we know what direction theyâre firing in? Or if they fire at all?
Weâre using directional tracking, and Iâm healing them to full because if they were âhitâ by the systemâs standards, but not hit by the actual gameâs terms, then the regular health will interfere with the pseudo, by having too much health. Whereas the game will say that the player is hit and the system does not, which means they will have too little health, interfering with the pseudo and their location, if it was crucial. Finally, if both systems detect the player is hit, they will have too little health again because there was no healing taking place after that damage.
Healing to full, then damaging them so that itâs accurate, is crucial to gameplay.
Arenât you holding back to farm likes from Bird?
No, Iâm not holding back to farm likes. I havenât started the model and theyâre asking questions.
Get out, ego.
