Suggestions for the next Windward Intercollegiate Programming Championship?

Once the Windward International Collegiate Programming Finals are over, please take the time to give us your feedback here. What went right, what went wrong, how could we have done this better?

And the big question – should we do this again next year?

If we should, do you think it should be an A.I. challenge again? Is 8 hours the right amount of time? Is the last Saturday in January a good date?

And any suggestions for what the challenge should be next year? Please, any idea for a good programming challenge are very much appreciated.

7 Responses to Suggestions for the next Windward Intercollegiate Programming Championship?

  1. Pingback: The Windward International Collegiate Programming Finals are in process! | Windward Wrocks

  2. As for more detailed feedback:
    * 8 hours is definitely not enough, especially when it takes over 5 hours just to get the framework working. As far as I know, noone at my school even managed to consistently beat the random bot in the time allotted. Meaning that we literally would have done just as well by not even coding anything.
    * By comparison, the Barracuda programming competition is 24 hours using a much simpler game and framework.
    * The game specification in general was lacking, as evidenced by the length of the FAQ. And what little information there is was often hard to find. To make matters worse, there was a lot of incorrect or contradictory information out. For example, you didn’t even bother to change the code comments referring to the old version of the game. You know somethings wrong when a team serious considers packet sniffing to reverse engineer the protocol.
    * The framework is ridiculous. Sure it was posted ahead of time, but the messages didn’t really convey how hard it would be to set up, or that the demo game would be near identical to the actual one. The note about C++ confuses the issue further by implying that only compiled languages would have problems.
    * As an example of some of the problems, the provided Python bot is unkillable! We had to hack at it, just to get it to the point where it could be terminated. Another example is the fact that you have to have a unique password for each client, a bit of info that was difficult to discover.
    * The cumbersome framework makes testing and debugging a huge pain. The cycle for testing is: start up server, start up client, click lock on server, click Yes on the popup, click start game, wait a while, exit the server, kill the client, and then dig through the copious output and stack traces to find the part that you actually printed. This makes even simple debugging an arduous and time consuming process, which makes the tight time limit especially problematic.
    * The game seems to be pointlessly complex. You want games that are simple to understand and hard to master, not the other way around. This is exacerbated by the poorly explained rules and short time limit.

    I’m sure there are other problems, but the post is already long enough.

  3. The Code War event was a lot of fun coding and meeting new friends through welcoming teams and healthy competition.

    However, there were many problems with the implementation of the event.
    Chief among these problems were massive inconsistencies between provided code and stated rules as well as repeated rule clarifications conflicting previous information. Many students were very disappointed to have their efforts frustrated by shifting rules and confusing provided code so poor that merely fixing the default bot was an extremely strong contender in the field.

    In our particular locale it could have been more exciting to have matches projected on a large screen continuously to encourage agile development and continuous testing. Redemption came through good food and a great company participating in the competition, which did not suffer for it being a weekend in January and whose many voices wished for more time to compete.

  4. Hello,

    I always enjoy AI competitions, the environment is always fun. I really do hope you do this again next year. I think a better time frame is 12-24 hours, it gives you more time to refine and implement the specific aspects that really make the difference in these games. I have two recommendations:

    1) Make the game much simpler, and make it rely less on chance. For example a simple card game. One competition I competed in in the past involved a card game racko:

    It made for an interesting AI challenge. Something slightly more complex than racko would be fine too.

    2) The main reason I say to make it simple and rely less on chance is because we submitted the provided java client (with 2 lines modified I believe) and made it pretty far in the competition – which I feel says something about the game itself (we are GaTech Catalan). So my second suggestion is to provide more documentation and fewer code examples. Make us do something. Instead of writing something reasonably intelligent for us, you could have done had the provided bot always pick the first card and use it. Just to show us how things work.

    Hope this helps, look forward to competing next year.
    – Kyle

  5. I think this event is a great idea and has amazing potential, but I was not impressed by the choice of programming challenge today. My team spent the whole time trying interesting approaches to the problem, but due to its difficulty and overall reliance on chance, our final submission was only a slight modification to the sample ai provided. Since we scored 5th out of 8 in the national semifinal, surely a better game can be found for next year. Perhaps reducing the number of competitors in a given round would help make such programming challenges manageable.

  6. Thank you for organizing this event! Even though my team was not able to complete the AI due to a lurking bug, we definitely had a lot of fun. However, I noticed one thing: nearly all teams were spending more than half of time digging in the server code to find out how exactly the game works. I think you should consider preparing better documentation for your game rules and examples so that all of us can make use of all 8 hours.

  7. It was hard for the programmers to figure out what they were supposed to do. It took my group around 3 hours to get set up, read and understand the game, then make a plan for what we would do, so we didn’t start coding until 1:00. It probably wasn’t as bad for other groups, but I still feel like it took too much time to do all of that. Perhaps encapsulating the code more and providing a javadoc site of the classes would help.

    The game’s animations made it hard to figure out what was happening.

    The stream’s video was sporadic, but the audio was fine.

Comments are closed.