Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (577)
games submitted by our members
Games in WIP (498)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  An AI challenge  (Read 12186 times)
0 Members and 1 Guest are viewing this topic.
Offline timfoden

Junior Member


Projects: 2



« Reply #30 - Posted 2008-07-20 11:03:00 »

Oops! That'll teach me to 'borrow' code! Can you tidy it up for me Tim?

OK, I've made the changes.  As I said, they were fairly minor bugs really.  The code is in http://www.7sun.com/temp/fow/FOW.java -- EDIT: this is the FOW from the previous release... I'll just get the new one now and see if its the same.  UPDATE: OK, I merged my changes into the new version of FOW.java now, and uploaded it to the same address.


While I was looking at making these changes, I found code that I believe can be made a lot more efficient.

For example, the lineOfSight routine calls canMoveTo(x,y) for each point tested along the line, but canMoveTo(x,y) tests for hitting a pillar each time.  This means that it's doing a pillar hit test for each pixel in the map along the line being tested.  I think lineOfSight would be faster if it found the closest pillar once, and then used this info to limit its search in the map.

Would you like me to have a go at fixing this too?

Cheers, Tim.

Try Pipe Extreme -- can you get to the end of the pipe?
Offline SimonH
« Reply #31 - Posted 2008-07-20 15:38:48 »

OK, I've made the changes.
Thanks!

lineOfSight routine calls canMoveTo(x,y) for each point tested along the line.
Would you like me to have a go at fixing this too?
Would you mind? I can't believe I missed that!

People make games and games make people
Offline Jackal von ÖRF

Junior Member





« Reply #32 - Posted 2008-07-20 18:19:00 »

Optimizing the canMoveTo and canSeeBetween methods would improve the performance of my bot, because those are its hotspots. But when I switch to using castRay, it should anyways use much less CPU. Casting some 100 rays each step should be faster than calling canMoveTo 10000-50000 times each step. Roll Eyes

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline SimonH
« Reply #33 - Posted 2008-07-20 19:25:49 »

Optimizing the canMoveTo and canSeeBetween methods would improve the performance of my bot
That's true, but it'll also improve the performance of everyone elses...
The advantage of optimising the ray casting is that it means tests will run faster. castRay() will always have a cost so the fewer (and shorter) rays a bot casts, the better!

People make games and games make people
Offline timfoden

Junior Member


Projects: 2



« Reply #34 - Posted 2008-07-20 19:43:09 »

OK, there's a new version of FOW.java available.  It has some of the changes to make the lineOfSight and canSeeBetween routines faster.  It seems to make my bot about 2 to 3 times quicker.  I've got some more changes planned though, so please bear with me.

Cheers, Tim.

Try Pipe Extreme -- can you get to the end of the pipe?
Offline Jackal von ÖRF

Junior Member





« Reply #35 - Posted 2008-07-20 23:35:07 »

Good changes, Tim. My bot's CPU usage has dropped by 50-75%. Now 75% of my CPU time goes into checking all cells on the map with the forbidden canMoveTo method. I should be able to drop the CPU usage by at least 50% by changing the way that I look for obstacles, unless I manage to make a very CPU intensive way of doing it. I have some ideas on how to recognize those pillars even if they would not be moving... let's see how much CPU it will require. Roll Eyes

But first I'll need to take a pause and concentrate on work. I'll come back in a couple of weeks.

Offline timfoden

Junior Member


Projects: 2



« Reply #36 - Posted 2008-07-21 10:48:18 »

Here's another iteration of FOW.java with some more speed improvements.

In my timings (4 runs, square maze) the previous version has an average of 0.524 ms/turn.
This new version has an average of 0.353 ms/turn for the same maze.

This is not such a large improvement as the previous iteration, but I think it's worthwhile non-the-less.  I don't think I'll be looking at any more speed improvements at this time.  Smiley

Cheers, Tim.

---
A quick note about timings... I had to change to nanoTime() to get the accuracy shown here.  It would seem like a good idea to do this for all bots, and further, to take the timing code out of the bots completely.

Try Pipe Extreme -- can you get to the end of the pipe?
Offline SimonH
« Reply #37 - Posted 2008-07-21 20:04:45 »

Thanks Tim! That's given a it huge performance boost. (what a klutz I am!)

BTW I originally used nanoTime() but found it totally inaccurate (2 identical bot's timings differing by a factor of 10).
Is there some trick to using nanoTime?

People make games and games make people
Offline timfoden

Junior Member


Projects: 2



« Reply #38 - Posted 2008-07-22 09:16:09 »

I've never had any problems with using nanoTime() instead of currentTimeMillis().  I've only tried it on Windows machines, but other posts that I've read that mention it are from people running Linux machines.  I can't remember anything about it's MacOS implementation.

It is necessary to check that the time hasn't gone backwards (which it does when the counter wraps... the documentation is a bit misleading there -- it wraps quicker than the documentation implies).  But your code already does this for the currentTimeMillis() version anyway.  The only other point is that of course the value returned is in nanoseconds not milliseconds.

Oh, one other thing... there seems to be a minor problem with it on multi-core AMD processors.  nanoTime is based off the cpu's high resolution timer, and on the multi-core AMD processor each core has it own timer, and it seems that they can get a little out of sync.  But apparently just rejecting times that go backwards tends to fix the problem fairly well.

UPDATE:

see Game Timer
Quote
As an aside, I wouldn't suggest switching to System.nanotime.  That particularly timer doesn't work reliably on processors with energy saving capabilities (which is common, especially on laptops) and older dual core AMD processors.
-- doesn't sound good does it?  Smiley

also see NanoTime for Dual Core AMD systems
-- this one has some sample code for dealing with the problem.

Cheers, Tim.

Try Pipe Extreme -- can you get to the end of the pipe?
Offline SimonH
« Reply #39 - Posted 2008-07-23 17:25:27 »

Few minor changes. (source here).

Collision detection is now accurate (per-pixel), which has broken my bots Sad (not Tim's or Jackal's though)

I've added a new (nightmare) map which breaks all the bots except NoAI (evil chuckle!) 

Quote
I wouldn't suggest switching to System.nanotime
Doesn't sound so good...

People make games and games make people
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (19 views)
2014-04-15 18:08:23

BurntPizza (15 views)
2014-04-15 03:46:01

UprightPath (28 views)
2014-04-14 17:39:50

UprightPath (13 views)
2014-04-14 17:35:47

Porlus (29 views)
2014-04-14 15:48:38

tom_mai78101 (54 views)
2014-04-10 04:04:31

BurntPizza (111 views)
2014-04-08 23:06:04

tom_mai78101 (212 views)
2014-04-05 13:34:39

trollwarrior1 (181 views)
2014-04-04 12:06:45

CJLetsGame (187 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!