What is the correct way to control de timeout in java?

Programming languages Java
#1

At the compete games, based on turns, what is the correct way, or the most efficient to control the timeout in java?

I started inserting the reference time for the timeout (Using Calendar.getInstance().getTimeoutInMilissecons()), after send my command and before start to read the next turn data. But somethimes, the time to read the first input is much more than 100ms…

So I started to set the reference data, after the first read of the input data… But, somethimes, with a max of 50ms of timeout, I lost the game…

Is there any guide? I’m playing Smash the code.

Mean Max (CC01) - Feedback & Strategies
#2

Don’t have expensive loops. If you’re looping through a queue of options to consider, purge duplicate candidates. If you need to read input quickly, use the local maximum operation instead of calling next() for each value. (e.g. reading the entire line to split by space, instead of calling nextInt() several times) If you wrote a depth first search, implement depth limits and experiment with the right number that keeps your code from running out of time. If there are values you’re setting that you don’t need, don’t set them.

#3

You could try System.currentTimeMillis(); or System.nanoTime()

But do so after reading the first line of input. Otherwise you also stop the time your opponent needs for his turn.

while (true)
    read input
    start timer
    read more input
    while time left
        do computation
    print move
1 Like
#4

In most cases it’s also a good safety measure to have a margin, maybe between 2 and 5 ms. To be tuned until you don’t have timeouts anymore.
Personally I switched from System.currentTimeMillis() to System.nanoTime() since it has better precision and is more adapted to measure elapsed time, even if the measure itself could take a bit more time using nanoTime…

#5

I implemented thread with timeouts to be sure that i dont have any bug or infinity loop. Using the time reference after or before the inputs, I get the timeout in the same way. Im sure that this game have some kind of bug… At other games, the timeouts works correct.

#6

System.currentTimeMillis() gives you the wall clock time. On a virtual machine running multiple processes, the returned value is neaningless for your purpose. That matters is the CPU time spent by your program which, in your case, is the JVM. Bad news, there is no one simple way to measure it accurately from your Java code. The best you can do is to use something like ThreadMXBean.html#getCurrentThreadCpuTime(). It’s still not the JVM CPU time consumption but, provided you don’t waste time in some system calls and don’t stress the GC too much, the method should provide a usable value.

#7

Using getCurrentThreadCpuTime, I time out while it tell me that I still have 10 ms available, so I think nanoTime, while not perfect either give a better value.

#8

How about using setTimer()? I haven’t tried it but just asking

#9

Hey,

First off, big shoutout to BrunoFelthes for bringing up this topic – timeouts in Java can be a real head-scratcher…

I totally get the frustration when dealing with timeouts during competitive games. It’s like time has a mind of its own, right? Here’s a suggestion that might help you out: Instead of relying solely on ‘Calendar.getInstance().getTimeInMillis()’, consider using ‘System.nanoTime()’.

I have experience with similar systems when I worked for a Germanmobile app entwicklung agentur, there were a lot of similar cases there and I think it can help you. (it worked for me 50% of the time, so it’s worth a try). This can offer better precision and accuracy for measuring time intervals.

Your approach of setting the reference time after the first input read is a step in the right direction. To address the issue of reading the first input taking more time, try to optimize your input reading process. Buffers and asynchronous input reading might help shave off those extra milliseconds.

Also, keep in mind that game loops and performance vary across systems. What works perfectly on one machine might not on another. Experimentation and fine-tuning are your best buddies here.