Unless you’re new around here, you’ll have heard that over the summer I was working on Pollen with Digital Colony. The team of five was composed of three programmers (myself, Ian and Kieran) who had worked together before, along with two artists (Jess, and Abi who also took on the role of team leader). Our previous project, Some Assembly Required, experienced mentors had introduced us to Scrum and given us advice throughout the development process. Moving on to work on Pollen we had a fair idea of what had worked for us and areas we could improve. Continue reading »
We finished the university term with our showcase on Friday, with final year students demonstrating their dissertation projects, and each third year project team showing off their game. So now that everything is over with, I’ve added a page in my portfolio about the game. You can also download the finished executable from there.
The playlist includes a highlight video, the game intro, a progress video from earlier in development, the character animations, and then the complete 10 minute walkthrough. Enjoy!
Apart from that, right now I’m just focussing on XNA and C# in preparation for Dare, and trying to decide upon a topic for my dissertation.
As you may previously have read, this year my team “Screw The Nut” has been working on a 3D platform game through the BBC’s prototype project and the University of Abertay Dundee, “Some Assembly Required”. Our final hand-in to the BBC is tomorrow so I thought I’d take this time to build a little suspense before I share the final game-play videos and let you see a few screenshots.
The game itself sees Warran T. Void, a lost and damaged little robot, wake up alone in a factory. By collecting new parts from vending machines he can rebuild himself with new abilities, allowing him to overcome obstacles and progress through the game. Our prototype level introduces you to a pair of suspicious character who instruct you to climb a giant construction robot and collect pickups for them, and playing as the naive Warran you enthusiastically oblige.
Would you trust these gentlemen?
These are all taken within the last week as we built our level and did some final testing. It’s been really awesome to see our game go from a series of platforms on a plane into a full, playable prototype level as it was only recently that we were able to bring all our art assets and platforming sections together into one application. As you can see, we went a little overboard with bloom, particle effects and shiny things however our actual focus throughout development has been on gameplay mechanics and the physics behind this.
The game was implemented over a period of two and a half months, that’s ten week-long development iterations, following on from general story and game-play designs we worked on late last year. A lot has changed from our original ideas – in particular splitting the BBC’s “interactive narrative” brief into two parts consisting of this game and a separate research project – but we’ve kept the core mechanics and level in tact.
Did we mention our level is also a robot?
The team itself consists of ten third-year students: five programmers including myself, two artists, two producers and a sound engineer. We also had the assistance of programmers from the BBC, and a mentor from Real Time Worlds. This made a huge difference to the project in terms of organisation and development and keeping on track, as well as handling technical problems with our codebase, and (at least as far as I’m concerned) has given us far more experience to carry over to our future projects than we would have gained on our own.
So, fingers crossed for our demo tomorrow and our showcase later in the term (which I believe is open to the public, more details will follow if that’s the case) and hopefully we’ll have a final video prepared for you soon.
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.
