3 requests:
1)Can you shrink the .zip a few percent? I have to copy across from 1 pc to another and at 1.47Mb it''s so pesky having to span across two disks. Can you get it down to like 1.35Mb with better compression or saving graphics as .jpg etc? Of course if you add more features it ain''t possible it''s just the fact it''s only jut too big!
2)When our update() is called can''t it be update(float TimeUsed) - telling us how long our last ''turn'' took. We can easily make an fps thing but real time and simulation time aren''t identical. This would have two advantages - for development we can see how long we''re using and for the competition, where we can''t accurately judge how much can be done, a good algorithm could adjust its complexity to take full use of the time allowed.
3)The wall thing is sucky. Am I right thinking it draws a line from the bot to the wall at right angles to the wall, meaning the bot only sees it if facing <40 degrees away from the wall? Firstly does 0 degrees mean I''m looking at the wall or am parallel to it? Secondly why can''t it just project my view direction to where it meets the wall line - this would seem more straightforward and avoid the corners problem.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Requests for GDArena
lo some ideas
why not include "health items" ?
indeed an energy bar would be nice .. could even include some more weapons.. 1 weapon that takes a lot of energy and 1 that doesnt and might shoot "faster" ?
why not include "health items" ?
indeed an energy bar would be nice .. could even include some more weapons.. 1 weapon that takes a lot of energy and 1 that doesnt and might shoot "faster" ?
thought of sth else.. what about the bot being able to draw "stuff" on the screen when in debug mode? might be nice to help imo
To make the bots able to better navigate and fight its really necessary that they have memory!
Say at frame X u get all objects on screen and save them. Then a frame Y u do the same thing. There is no way to find out if the bot has seen the object before so it is just blind.
We use the system for navigating the world: get a marker, move in a direction and compare the new position to the marker.
The simplest way of doing this is provinding the Bot with the world ID of the object he sees. (for object i in sight get its ID in the world).
This way the bot knows if it is not walking into a wall, or a tree and can compute a path through the world.
Death to the gaming industry! Long live games. /*ilici*/
Say at frame X u get all objects on screen and save them. Then a frame Y u do the same thing. There is no way to find out if the bot has seen the object before so it is just blind.
We use the system for navigating the world: get a marker, move in a direction and compare the new position to the marker.
The simplest way of doing this is provinding the Bot with the world ID of the object he sees. (for object i in sight get its ID in the world).
This way the bot knows if it is not walking into a wall, or a tree and can compute a path through the world.
Death to the gaming industry! Long live games. /*ilici*/
quick question khawk:
in an earlier thread you mentioned that you planned on "fixing" the FOV to include objects that were only partially in the FOV, even if their central points were not in the FOV. is this still planned?
-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.
"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)
(author of DustBot)
in an earlier thread you mentioned that you planned on "fixing" the FOV to include objects that were only partially in the FOV, even if their central points were not in the FOV. is this still planned?
-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.
"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)
(author of DustBot)
quote: Original post by drreagan
quick question khawk:
in an earlier thread you mentioned that you planned on "fixing" the FOV to include objects that were only partially in the FOV, even if their central points were not in the FOV. is this still planned?
-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.
"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)
(author of DustBot)
I haven''t decided if it will be implemented for the beta contest. It may be left as part of the redesign.
quote: Original post by Ilici
To make the bots able to better navigate and fight its really necessary that they have memory!
Say at frame X u get all objects on screen and save them. Then a frame Y u do the same thing. There is no way to find out if the bot has seen the object before so it is just blind.
We use the system for navigating the world: get a marker, move in a direction and compare the new position to the marker.
The simplest way of doing this is provinding the Bot with the world ID of the object he sees. (for object i in sight get its ID in the world).
This way the bot knows if it is not walking into a wall, or a tree and can compute a path through the world.
Death to the gaming industry! Long live games. /*ilici*/
You can remember their locations based on your starting position, this is how my current bot is working. It''s not perfect yet, but it''s getting better. He builds a list of objects + locations, so it knows when it sees something a second time (it is at the same location), and it knows when something new is seen. It also stores this information and calculates it''s distance and direction for each object that''s been seen, so even if I''m backing up, I know how close I am to the objects.
quote: Original post by Ready4Dis
It also stores this information and calculates it''s distance and direction for each object that''s been seen, so even if I''m backing up, I know how close I am to the objects.
i guess it depends on how your system works as a whole, but here is a piece of advice: don''t calculate the distance and direction for each object in your internal map every update. instead, to make sure that the movement that the bot has decided on for that update is valid, turn the desired movement into a vector and then, using the movement vector, do a segment/circle intersection test against the obstacles (you could even get fancy and implement something like recursive dimensional clustering to help narrow down the objects you need to test against). I don''t have any hard evidence that this is the case, but i''m assuming that using the trig functions on each object every update to convert the objects from your bots internal cartesian map into polar coordinates is slower than the vector math used to calculate a possible intersection between a segment and a circle (especially if you are just testing for collision, and not trying to find the point(s) of seg/circle intersection).
-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.
"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)
(author of DustBot)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
