Java starterkit
We now support Java, and have done some backend work to help us move towards supporting more languages as well! Check it out in the java-algo folder in the restructured starterkit.
Docs for Java algo are inside the java-algo folder.
Frontend General
Fixed an issue that would occasionally cause UI elements to overlap the gameboard on smaller screens
Centered the UI elements on the my-algos page to prevent large spaces between them on large screens
Added an option to ‘opt in’ to share a resume with potential employers.
Playground
Updated play-by-hand so transition between placing units and viewing the action phase.
Updated the frame timeline so that there is a more clear delineation between rounds.
Rules and docs
Added further troubleshooting for issues with the CLI and Java 11
Added information about other languages
Misc
‘waitTimeStartGame’ and ‘waitTimeEndGame’ are new config variables that can be used to remove the 3 second delay at the start/end of game. This should dramatically speed up testing for some users.
With the new UI, it says I must expand the screen to see replays, however my screen is maximized, the screen on my computer is just small. Now I can’t do any testing or anything. Can you make the certain size not a requirement, just highly recommended.
@chickenpotpie0
Sorry about this. For now can use the zoom out hotkey on your browser, usually command minus. We are going to add a ‘continue anyway’ button.
What is your screen size? It may be helpful for us to know.
I just wrote a test algo in Scala and configured Gradle with the Scala plugin. It builds and runs fine on my computer, but for some reason when I upload it, it says “compiling” forever. Any idea why this might be happening? Is the Scala compiler and standard library too much to include in my Gradle dependencies?
As far as I’m aware, building a program in Scala (most JVM languages, really) in Gradle not only requires Gradle to be installed on the system, but also that language’s SDK. So, as of now, we don’t support Scala algos, and Scala is unable to compile on our servers.
We have more algo languages in the works (I would be the one to ask questions about that), and I am interested in supporting Scala in the future. If we do so, I will involve me coding a starter algo that conforms more closely to Scala’s functional idioms.
So if anyone else is interested in other JVM languages, I found it works fine if you compile the Scala (or whatever else) code beforehand, to another JAR file (one not touched by Gradle), and then have run.sh run that instead of algo.jar. You will need to remove the *.jar line from .zipignore to get the JAR included in your zip, though. I plan on eventually keeping the Gradle build system for java and using algo.jar as a library for my algo, which will be written in Frege. JVM languages should be significantly faster than Python, and be able to do more computation per turn.
@C1Phoenix What languages do you plan on supporting in the future? Ideally, I would write this in Haskell, but I doubt many others would use a Haskell version. Have you considered something like Halite does, and use a more general framework or community-created starter kits? I’m sure many people on this forum would be willing to write a starter kit in their language of choice.
On the topic of things which are significantly faster than Python, we have support for Rust algos in the works. We decided to release Java first, to help us find any problems in the multiple-languages pipeline. We haven’t reached any final decision on which further languages we’ll support. I’m hoping for something old, something new, something fast, something functional.
The idea of community-based language support is something we’ve discussed before, internally. We like how it sounds, but we still have some decisions to make about it.
@C1Phoenix Could you provide a way to submit a compiled .jar? @Thorn0906’s “solution” is really hackish (same as hacking together any other unnecessary Gradle task). Regularly uploading a compiled .jar works at the moment, but only when playing on the Playground. All ranked matches crash on initialization.
Running a jar crashes during a ranked match? That’s strange. When your algo compiles, it just compiles to a jar file, and the ranked matches and the playground are essentially doing the same thing as each other. Are you sure it’s not something else? Maybe you’re depending on a system library, like, perhaps you’ve plugged in some internet-based system which depends on TLS?
I’m gonna have to get back to you on this one. I’ve had problems in the past where Scala would fail to run due to different JVM versions. On the other hand, it could be something similar, or just different.
As a policy, we do not support the uploading of pre-compiled code. We cannot guarantee that it will work, that will we provide support for it, or that if it does work, that it will continue to work into the future.
However, we are currently working on a process for users to write their own starter algos in languages of their choice, and for us to work with those users to integrate the algos onto our platform. This is a high-priority item for us, and we will make a forum post when we’ve worked out a process.
We released Java algo, in part, to find issues in our multi-language pipelines. That fact that it is hard to debug compilation is valuable information. We’re speccing out a way to make it easier to debug algos at the build stage.
I took a look at your algos, and it looks like, in your build.gradle, you are using the absolute path /algo, instead of the relative path ./algo. If you change that I think they’ll compile and run.
I’ve been experimenting with Java algos for performance, and it seems like when I run a Java starteralgo on C1’s servers, it’s ~10x slower than the Python version; but when I run the same algos locally on my machine, the Java version is ~2x faster than Python. Any idea what could be causing this discrepancy? I’m running OpenJDK, which might be part of it. Has anyone else noticed anything similar?
The starter algo, regardless of language, isn’t necessarily indicative of that language’s performance. Since the starter algo doesn’t really do any heavy computation, most of the time is probably spent serializing and piping data, and making basic state changes. For a comparative performance test, you’d probably want to create some algorithm which involves heavy computation (perhaps by using pathfinding many times), implement that in several languages, and compare the CPU-time for that one.
I just did that - I reimplemented an old algo I had written in Python that did a decent amount of computation, and where I hadn’t done any optimization on the gamelib, in Java, and the difference was even more drastic. On my machine ~6ms for the Java algo after it warmed up, and ~11ms for the Python one; on the Playground, ~60ms for the Java version, and ~6ms for the Python version.
That’s interesting. I’m not going to be able to look into this over the weekend, but it might be worth considering the possibility that the Java runtime has a higher runtime overhead, relating to it’s multi-stage JIT compilation of the bytecode.
