CodingGame – An idea for a real time strategy game for programmers
codinggame.wordpress.com
codinggame.wordpress.com
If you ever find yourself in this position, or if you are the author, please, please, please, knock a bunch of rules together using tools no more technical than pens, paper, whiteboard etc. and play test it to ruddy heck before you so much as create a software project.
Even if I think there's a low probability that the project will be completed as you describe, don't be discouraged. Any progress made in any direction will be valuable experience, and enjoyable. I have started more than one project that I couldn't finish and I've never regretted any of them in hindsight.
Don't be afraid to fail publicly, by which I mean post about absolutely everything you've done, no matter how unfinished it is, it'll help everyone keep enthusiastic and engaged. If you complete the project, you'll have a valuable log, if not you'll be able to see both 1) what went wrong and 2) the sub-victories you had on the way.
Good luck.
Change the title to "An idea for a real time strategy game for programmers"
@mods: could you change the title on hn as well?
(b) It has actually been not at all a long time since our last update. It's a dev project. It's proceeding like dev projects do. :)
(c) Erin's got an update coming soon, but she's also ferociously debugging an emulator that is sucking up a lot of her cycles.
(d) We'd be using the term "game" in a much much looser sense than this story is. :) If you haven't already gotten through Microcorruption.com (our first "game" like this), and you're impatient for Starfighter, well, Microcorruption is good too!
(a) You're welcome. You got many people excited about Starfighter!
(b) Well, I'm impatient :). Though I'll cut you some slack for a while now that Kerbal Space Program is hitting 1.0 next Monday.
(c) Cool. Can't wait! Also, best of luck fixing bugs :).
(d) I know :). I was just trying to find a good excuse to ping you for few days now, and here came something close enough. I started playing Microcorruption recently, and it is very fun. Lots of levels left for me though.
Our other restriction was that we wanted to support hundreds of units per team, and we wanted tens of thousands of computed turns, but be able to compute that within 3-5 minutes.
We did learn from that naive approach though and the next year I believe it was done with a text based API. If performance were an issue, it could be done with protobuffers, since most popular languages have at least some implementation of them. The year we did the java implementation we had replays the size of 250mb+ due to how much data we had, even with deltas, compression, and other pruning. The text API was only feasible due to a massive reduction in the amount of game entities and turns.
The key thing was when you want to offer API commands. We wanted starting freshman to be able to compete, and that required offering things like pathfinding, predefined list filters, etc. This also mattered since it was run like TopCoder where they only knew about the game the day of the competition and had 8 hours to code an AI for it. The least buggy way to support that in multiple languages is to have the API computation happen on the server, then your language specific APIs are just wrappers around the API calls and data and much easier to change as your game changes.
I must admit I just want to experiment with different AI algorithms like deep learning, genetic programming, rule induction and see how they do. I have much of the code already but I am unlikely to get the time to rewrite it, even if could get it to fit within the game environment. Especially as some of the training is best done on a GPU.
Another cool competition is MIT's Battlecode, which actually gives you a bytecode limit. If your code executes past the bytecode limit, your AI is paused and will actually resume on the next turn, without notification. Thus you'll be continuing with possibly old/dirty data. That pretty much prevents you from using any standard libraries and doing bytecode level optimizations, as well as manually yielding if you know it will take too long.
Your robots also can only talk to each other through a radio API that has limited bandwidth and possible corruption if I recall correctly. It's a complete opposite of what I worked on, where we focused more on strategy rather than code optimization.
It was a semester project where we had to hand in a game satisfying a few basic requirements, and since we were done early we were allowed to add as many extra features as we wanted. One of those features is that whenever you clicked on a unit and ordered it to do something, a log message would show you a ruby command which would do the same. You could then open the console and control your units using arbitrary ruby code, and you could also attach AI scripts to your units.
This was before the era of github, so the source may or may not have been lost to history. I'll update this comment if I manage to find it.
One question:
> My implementation uses Scala, so the API will initially be for Scala/Java only, but I want it to be possible to write wrappers for other languages as well.
Why isn't Clojure supported?
Thank you :)
> Why isn't Clojure supported?
I have never used Clojure myself, so I don't know too much about it. Can it easily call into Java libraries? In that case, Clojure should work as well.
Yes, see [0]. If you need help making it available in Clojure, please ping me and I'll be happy to give you a hand.