> 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.
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.
This game is at the "not even mocked up" stage. There's no ideas in the article, except for vacuous phrases that amount to "good for everyone, simple, and fun".
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.
You raise a really good point about thinking through the game mechanics before diving into the coding.
As it happens, I have actually spent a lot of time on this and even implemented something similar some years ago.
I probably could made that clearer in the blogpost, but I mainly wanted to give a concise overview my goals and plans for this project.
My next updates should have a bit more substance :)
I will enthusiastically read and consider any progress you post.
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.
It would be great to be able to remotely connect to the world, so plays can use the language of their choice. Personally I like web sockets and JSON, as they are well supported by most programming languages. In any case it would set it apart from some the other online AI arena's I've seen so far.
When I was at Michigan Tech I was part of the group that would create an annual version of this, and we were actually running all AI in the same Java process (somewhat sandboxed) which of course led to scalability problems and limited you to JVM languages. For us it didn't matter so much since our target audience was new comp sci students at a school where the starting and most used language was Java.
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.
It is a fair point, if you want to keep the playing field level and you want to compete on the basis of coding skill then you need to manage the code on the server. Otherwise simple network latency to the server could skew the playing field, assuming it is real-time.
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.
You bring up the real-time component, which is something we didn't do and from what I can tell the OP does not plan to do either. Real time is an entirely different beast and something I haven't seen in these types of competitions yet. I'd love to see one that does do it though.
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.
CodeCombat is aimed at people with no, or very little, programming experience.
My game will be targeted towards people who already have at least basic programming knowledge, and are looking for a less restrictive environment.
In that respect, it will resemble CodeCombat's zero sum mode[1].
I am hoping that the focus on slightly more experienced programmers will allow me to create a game with more strategic depth.
I implemented version of this several years ago, except against human players instead of against an AI, and with randomly-generated levels instead of a succession of harder and harder levels.
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.
I had a great time doing the "Planet Wars" version of the "AI Challenge" a few years ago. I kind of wish there were more of them going on. http://aichallenge.org/
BWAPI, the StarCraft: Brood Wars API has been used as the foundation for several AI programming tournaments, which may be if interest here. https://github.com/bwapi/bwapi
Since we're talking about coding and games - hey 'elptacek, 'tptacek and 'patio11, how's Starfighter going? ;). It's been a long time since any kind of update and I just can't wait to start playing!
(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.
We have not. We had planned the first email to be a sort of short study guide for the concepts we're playing with in Chapter 1 of Starfighter, but then I had the traditional Rev 1 Weeks From Shipping freak-out and relitigated every concept from Chapter 1 and Patrick had to fly all the way to Chicago from Japan to help Erin talk me down and so now we've settled back into a solid plan for what the first ~20 levels look like and long story short update coming soon.
33 comments
[ 3.1 ms ] story [ 91.0 ms ] threadOne 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.
[0] http://clojure.org/java_interop
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.
@mods: could you change the title on hn as well?
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.
Change the title to "An idea for a real time strategy game for programmers"
[1] http://codecombat.com/play/ladder/zero-sum
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.
(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.