Last Saturday, the programmers from Screw The Nut (Andrew, Deji, Ian, Phil and I) took part in the first Realtime Worlds student programming competition. It was the first time any of us had attempted something like this, so although we had some vague plans before the day began, we didn’t really know what to expect.
The basic format of the competition was that around seven teams from various universities were each given one computer between the five members. After a basic practice question to check we could correctly read the output and would be able to submit our answers, we were given three hours to solve three further problems. Finally, at the end of the day we were tasked with writing AI for a spaceship to complete an Asteroids-like game, which the competed against the other teams.
For each of the three questions our team managed to agree upon a solution and write out the psuedocode required to implement it. What really took time was actually writing out and testing our solutions. Being so pressed for time really emphasises the amount of overhead involved in writing in C++. Creating functions involves either writing prototypes for them or ensuring they’re all written in order, and finding one again means using Ctrl-F or searching through the file. The obvious way to make things neater would normally be to create multiple files, but that becomes almost unthinkable when you consider the overhead involved in writing headers. Then you come to testing the project – the compile time really adds up. Don’t get me wrong, all the teams were working in the same conditions (we were also given the option of using C# – I’m not sure if this would have improved the situation or not), but at any rate, at the end of the three hours we only had one solution to submit.
The second section of the competition (creating the game AI) went better. Knowing we would be short of time we focused on creating the most simple working solution we could – staying in one position, rating asteroids based on several criteria and shooting the highest rated one. As it turns out, most of the criteria we calculated were almost useless, or even hindered the spaceship – far more important than anything else was shooting the closest asteroid to the player. Our ship did very well in round one, but unfortunately we hadn’t considered what would happen at the end of the level when no asteroids remained, and we crashed out of the competition leaving two ships to continue through the next rounds.
At the end of the day things were looking a little bleak – we had had fun but given all the teams had successfully submitted more solutions than us and we knew ours wasn’t perfect, so we were hugely surprised to find we came in 3rd place, winning Amazon vouchers. Hopefully the competition will take place again next year as we now have a far better understanding of how we’d take part.
Things we learned:
- Don’t enforce time limits for each problem unless things aren’t working – one working solution is better than several non-working solutions.
- A quick solution which works in most cases is better than a perfect lengthy solution which will take a long time to implement.
- Don’t try to solve problems at the computer – just type up pseudocode.
- There are tasks one person can do while the rest of the team is working on the first solution, for example reading in the input into data structures.
- Global data works just fine.
- Working with people you know well is far easier than getting a group together – no matter how brilliant they are.