Twang! is a multiplayer platform racing game, developed for Xbox 360 supporting up to four local players. You race by shooting your grappling hook onto nearby objects, swinging to gain speed and then release, flying through the air. You eliminate other players by being faster and getting ahead of them. If you are the last player on the screen, you win!
The Dare competition has offered lots of opportunities for our team. Being from Sweden (4 out of 5 members), we get firsthand experience with another culture and to practice our second language, English (since people from Scotland know very little Swedish for some reason). Apart from that we’re able to meet people from the business, which is invaluable. Meeting people from Sega, Sony and Rockstar North (just to name a few) is just mind blowing for a recently graduated games development student such as myself. Especially when they come to our office to meet us and talk about our game. Oh, and it’s also very educating to hear what experienced developers have to say.
Being the 4th week of the development, almost halfway, we’ve learnt a lot so far. Both personal, such as getting experience with XNA, Xen and JigLibX, but also team-based stuff such as team dynamics. As a designer, putting your pride and your ego aside, and focusing only on what is better for the game, is a great skill to have. Totally worth spending a couple of skill points to get that skill if you haven’t already. Also, being able to leave an area of the game to someone else is worth a lot.
Personally, I want to do everything by myself, but there’s no way that would ever work. Being able to leave things like level design to another team member (since I totally skipped the level design branch of the skill tree) is better for me, since I can spend my time doing stuff that I’m better suited for, and also, it’s a lot better for the game. The best thing we’ve learned so far though, is when to cut a feature and when to keep it. Holding on to a feature just because you like it is not the way to go. Taking some time to try it out and then cutting it completely is better than having to spend weeks on adjusting the game to fit with the new feature and lose precious time.
One of our biggest strengths in the competition is the fact that we got a working game by the end of the second or third day. Even if the player could only move a white circle across a blue screen (CornflowerBlue of course), we’ve still been able to see what works and what doesn’t, testing new stuff rather than theorize about it. During the whole project so far we’ve been able to test new things in the game and decide to keep it or remove it completely, instead of gluing it all together the last few days and hope for the best.
Lastly, I want to give some advice to people who dream about making their own games and maybe try to participate in Dare some day. Do it. Find a couple of friends and just get to know the different roles in a development team. Make a couple of small games, rather than spending a lot of time with only one. Getting to know different kinds of games and problems will make you more flexible. Get used to the time frame. The competition runs for about 10 weeks – 9.5 to be exact. That’s nothing, believe me. If you can get used to making a complete game in this short time frame, you’ll have an advantage in the Dare competition.
Make use of deadlines, they’re your best friend. In our team, we have weekly deadlines, where a functional and fun game has to be presented each week. Even though this deadline is only for ourselves, it helps us immensely. We’ve seen that we work harder, and get more eager to produce high quality content, since we want to beat last week’s game.
If you want to see our weekly progress videos, check out twitter.com/ThatGameStudio or our team blog page on the Dare to be Digital website.