WOC Update Log
-
@011830-0a42ef84 Yeah, I can give it a shot. Been busy lately with school and troubleshooting various bot targeting methods.
@sirbots I believe I have fixed the second bot, although you can look through my code to see if anything is wrong or buggy.
-
@sirbots I believe I have fixed the second bot, although you can look through my code to see if anything is wrong or buggy.
@011830-0a42ef84 I’m going to mention something, the clone system I had should work but I think I know a way to fix it and not make broadcasts conflict, though there’s a chance it could be a bit hard to understand, tell me if you want to try to implement it and make it in a readable way
-
@011830-0a42ef84 I’m going to mention something, the clone system I had should work but I think I know a way to fix it and not make broadcasts conflict, though there’s a chance it could be a bit hard to understand, tell me if you want to try to implement it and make it in a readable way
@tyller_ That sounds good, after I stabilize everything in my test room I will let you implement it. Is that okay with you?
-
@tyller_ That sounds good, after I stabilize everything in my test room I will let you implement it. Is that okay with you?
@011830-0a42ef84 yeah, my idea is to use a list queue for broadcasts, the issue with my method is that the broadcasts call a bunch, so those variable parameters get called within the same frame and out of order, thus leading to the arbitrary order of what clone takes priority (this is called a race condition). I am actively very much debating how it would work, but I think the general idea I have is listed below:
- A list named “action queue” that is added to each time a sprite wants to broadcast something
- it adds formatted text to the list, in the format of “{clone id}|{broadcast}” (This works because my method only broadcasts what clone/ai the sensors are for, if other broadcast parameters were added it would need to slightly change)
- it then broadcasts the actual broadcast (no parameter cus that stuff is now in queue since parameters cause race conditions)
- the actual ai clone would now start handling stuff (before it was the sensor doing stuff), when it receives a broadcast it checks the queue list to determine if it was queued for that broadcast
- if it finds its id for that broadcast, so “{clone id}|{broadcast}”, it will run the code for that broadcast
Here’s an example for the 5th clone (so clone id is 5 or “ai&5” but their interchangeable so it doesnt matter which way I decide to handle the clones) handling the broadcast “behind player”:
- the sensor detects the player and needs to broadcast “behind player”
- It adds “5|behind player” to the “action queue” list
- It broadcasts “behind player”
- All the clones of the bot receive “behind player”
- They check if the broadcast is for them or if they have a broadcast queued since it could be trying to handle multiple broadcasts in the same frame, they do this by checking if “action queue” contains the result of joining their clone id and “|behind player” (so join(clone id)(|behind player) in the editor)
- If that broadcast is for them (or they have one queued) then they do what they do for the “behind player” broadcast
- They delete that line from “action queue” with teh delete value of list block
If this doesnt make sense I can try an example, I jsut wanted to list out my thought process
-
@011830-0a42ef84 yeah, my idea is to use a list queue for broadcasts, the issue with my method is that the broadcasts call a bunch, so those variable parameters get called within the same frame and out of order, thus leading to the arbitrary order of what clone takes priority (this is called a race condition). I am actively very much debating how it would work, but I think the general idea I have is listed below:
- A list named “action queue” that is added to each time a sprite wants to broadcast something
- it adds formatted text to the list, in the format of “{clone id}|{broadcast}” (This works because my method only broadcasts what clone/ai the sensors are for, if other broadcast parameters were added it would need to slightly change)
- it then broadcasts the actual broadcast (no parameter cus that stuff is now in queue since parameters cause race conditions)
- the actual ai clone would now start handling stuff (before it was the sensor doing stuff), when it receives a broadcast it checks the queue list to determine if it was queued for that broadcast
- if it finds its id for that broadcast, so “{clone id}|{broadcast}”, it will run the code for that broadcast
Here’s an example for the 5th clone (so clone id is 5 or “ai&5” but their interchangeable so it doesnt matter which way I decide to handle the clones) handling the broadcast “behind player”:
- the sensor detects the player and needs to broadcast “behind player”
- It adds “5|behind player” to the “action queue” list
- It broadcasts “behind player”
- All the clones of the bot receive “behind player”
- They check if the broadcast is for them or if they have a broadcast queued since it could be trying to handle multiple broadcasts in the same frame, they do this by checking if “action queue” contains the result of joining their clone id and “|behind player” (so join(clone id)(|behind player) in the editor)
- If that broadcast is for them (or they have one queued) then they do what they do for the “behind player” broadcast
- They delete that line from “action queue” with teh delete value of list block
If this doesnt make sense I can try an example, I jsut wanted to list out my thought process
@tyller_ Here is the testing room link:
https://play.creaticode.com/projects/67b60b7a40002631c45cd8ab
Everything should work smoothly. There still might be occasional bugs, mostly consisting of the second bot (the second bot is annoying, I might nerf his attacks stats from 1 dmg 0.5 dmg. -
@tyller_ Here is the testing room link:
https://play.creaticode.com/projects/67b60b7a40002631c45cd8ab
Everything should work smoothly. There still might be occasional bugs, mostly consisting of the second bot (the second bot is annoying, I might nerf his attacks stats from 1 dmg 0.5 dmg.Update 2.18 - Balance Patch/Adjustment Update
Release Date: February 26st, 2025
What’s New:
AI
The AI has received adjustments to the following actions:- The AI will now occasionally shoot in very small bursts while are moving
- The amount of bullets fired is less than when standing still
- Adjusted the range of rounds fired for the Anchor by 23% (24 to 30 to 26 to 40)
- The forward movement speed of Interceptors while they are not getting into position to shoot has been roughly doubled.
Voicelines
- Changed the first voiceline played at 250 points earned or there are 5/6 of the total players on one team.
- Increased the general interval between voicelines by 100%
Gamemodes
- Capture Points can no longer be contested in non-realistic battle matches.
- Reduced the time to capture an uncontested enemy point directly by approximately 50% (3 seconds to 1.5 seconds)
UI
- The screen for when the match is being prepared will now show up as one of 4 backgrounds instead of one. The text indicating that the match is being prepared has been moved and received some polishing.
- Added Tips.
Bug Fixes
- Fixed a bug causing the point counter to stay on screen when a match ends.
*Fixed a bug causing the player to “kill” an enemy with a grenade or poison gas while the aforementioned bot was still dead. - Fixed a bug causing the AI to shoot at other teammates constantly.
- The AI will now occasionally shoot in very small bursts while are moving
-
Update 2.18 - Balance Patch/Adjustment Update
Release Date: February 26st, 2025
What’s New:
AI
The AI has received adjustments to the following actions:- The AI will now occasionally shoot in very small bursts while are moving
- The amount of bullets fired is less than when standing still
- Adjusted the range of rounds fired for the Anchor by 23% (24 to 30 to 26 to 40)
- The forward movement speed of Interceptors while they are not getting into position to shoot has been roughly doubled.
Voicelines
- Changed the first voiceline played at 250 points earned or there are 5/6 of the total players on one team.
- Increased the general interval between voicelines by 100%
Gamemodes
- Capture Points can no longer be contested in non-realistic battle matches.
- Reduced the time to capture an uncontested enemy point directly by approximately 50% (3 seconds to 1.5 seconds)
UI
- The screen for when the match is being prepared will now show up as one of 4 backgrounds instead of one. The text indicating that the match is being prepared has been moved and received some polishing.
- Added Tips.
Bug Fixes
- Fixed a bug causing the point counter to stay on screen when a match ends.
*Fixed a bug causing the player to “kill” an enemy with a grenade or poison gas while the aforementioned bot was still dead. - Fixed a bug causing the AI to shoot at other teammates constantly.
Made some last minute changes to the final draft of 2.18:
- Reduced the volume of the Anchor firing sound by approx 33%
- Player speed increased when playing as the Interceptor
- Changed the firing sound of the Assault and the Marksman
- Changed the menu music for the final time.
- The AI will now occasionally shoot in very small bursts while are moving
-
2.18 is now out!
Ever feel as if your teammates are just plain useless, or just loves rushing on top of Enemies only to have both of them die? Well, they can now shoot while they are moving! Yes, they don’t have to stand still to shoot! To make things better, the Interceptors can actually do what their name implies including you, intercept and annoy the other team. With a new speed buff, they can get there and attack the enemy team, or at least, damage them enough, to have better chances of being successful in your first attack, or your teams first assault on the frontlines. BUT…
The enemy also has Interceptors of their own, and before you know it, you could have an enemy interceptor slowly cutting your team down in your spawn, or even have a whole army of them at your doorstep.
The next major change is a new strategy in the logbook to more effectively take back important objectives. In regular battles, points can no longer become contested, and faster capturing times in general. Also added in the logbook is some advice that you can read over before entering a match.
Lastly, some fine adjustments to some of our weapons has gave them better firing sounds, to make it feel as if you are really bringing the enemy down to their knees.
Now, for community feedback:
From some of my buddies, and one certain user here, have said that the firing sound for the Anchor was very loud, so its been reduced in volume.
The next update will focus on a widened game screen, a player count display that shows how many players are using a specific class in realistic Battles, and major UI changes. This next update might be the final update before I focus on other projects.
-
2.18 is now out!
Ever feel as if your teammates are just plain useless, or just loves rushing on top of Enemies only to have both of them die? Well, they can now shoot while they are moving! Yes, they don’t have to stand still to shoot! To make things better, the Interceptors can actually do what their name implies including you, intercept and annoy the other team. With a new speed buff, they can get there and attack the enemy team, or at least, damage them enough, to have better chances of being successful in your first attack, or your teams first assault on the frontlines. BUT…
The enemy also has Interceptors of their own, and before you know it, you could have an enemy interceptor slowly cutting your team down in your spawn, or even have a whole army of them at your doorstep.
The next major change is a new strategy in the logbook to more effectively take back important objectives. In regular battles, points can no longer become contested, and faster capturing times in general. Also added in the logbook is some advice that you can read over before entering a match.
Lastly, some fine adjustments to some of our weapons has gave them better firing sounds, to make it feel as if you are really bringing the enemy down to their knees.
Now, for community feedback:
From some of my buddies, and one certain user here, have said that the firing sound for the Anchor was very loud, so its been reduced in volume.
The next update will focus on a widened game screen, a player count display that shows how many players are using a specific class in realistic Battles, and major UI changes. This next update might be the final update before I focus on other projects.
@sirbots Would you mind if I copy your update log idea for my game?
-
@sirbots Would you mind if I copy your update log idea for my game?
@011830-0a42ef84 unless you’re just copying it without actually changing it to be for your game, there’s no need to ask to use the idea’ on pet of an update log
-
@sirbots Would you mind if I copy your update log idea for my game?
-
Since widening the canvas and the screen is creating a TON of bugs that might take a few weeks to fix, I unfortunately have to cancel the addition of the screen widening until I can fix the bugs on a testing copy of the game.
As compensation, I will add one feature of someones choice. Post what you want added here, and I will pick at random Thursday.
-
Since widening the canvas and the screen is creating a TON of bugs that might take a few weeks to fix, I unfortunately have to cancel the addition of the screen widening until I can fix the bugs on a testing copy of the game.
As compensation, I will add one feature of someones choice. Post what you want added here, and I will pick at random Thursday.
-
@sirbots why do you need a 1000x360 screen? that’s a very bad aspect ratio, like 25:9, a normal montior is 16:9 and the normal viewport is 4:3
-
@sirbots wdym doesn’t fit your screen? it will only fit your screen if you full screen it (like to the edges), the default si 4:3 which only fits on stuff like ipads (typically), almost all monitors universally are 16:9 which is ~ 640:360, 1000:360 is a completely arbitrary veiwport size, do you mean fit like across the entire screen (not vertically) in the project page? 1000:360 should not fit on a screen evenly in any way
-
@sirbots wdym doesn’t fit your screen? it will only fit your screen if you full screen it (like to the edges), the default si 4:3 which only fits on stuff like ipads (typically), almost all monitors universally are 16:9 which is ~ 640:360, 1000:360 is a completely arbitrary veiwport size, do you mean fit like across the entire screen (not vertically) in the project page? 1000:360 should not fit on a screen evenly in any way
-
@sirbots you said 1000 by 360, whats the issue? just try othe default viewport size 480:360 if the game works with that and remove fencing by just upping the canvas size, like if you just want no fencing at first you can do legit just 1000 by 1000 canvas size, 2000 by 2000 should be more than enough, I don’t recommend actually moving the viewport because at sizes at I think 5000 to 10000+ it stops showing stuff some way from the edge of the canvas
-
@sirbots you said 1000 by 360, whats the issue? just try othe default viewport size 480:360 if the game works with that and remove fencing by just upping the canvas size, like if you just want no fencing at first you can do legit just 1000 by 1000 canvas size, 2000 by 2000 should be more than enough, I don’t recommend actually moving the viewport because at sizes at I think 5000 to 10000+ it stops showing stuff some way from the edge of the canvas
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login