It’s a playthrough of the opening and tutorial section of the game, intended to introduce the player to the controls as well as each type of bee and their abilities.

Things we’ve learned from creating a tutorial:

• There’s more to having multiple input methods than just implementing support for different hardware.
• If you give players big arrows as hints, you need to remove them gradually or people panic.
• It’s good to give people an area to practice (lots of rocks, a few mushrooms) but unless there’s an incentive (like pollen) they probably won’t bother.
• Nobody reads text.
• Audio cues make a huge difference, even if they are subtle.
• Experienced players need to be able to skip or get through the tutorial quickly, or it’s frustrating.
• There’s always a way to break the tutorial you haven’t thought of yet.

If you have any advice on how we can tighten this area up, make it less confusing, or on creating great tutorials in general we’d love to hear from you!

Progress

The first two weeks of the competition have gone fairly smoothly. We’ve had problems with exporting models and animations and with collision responses, but no major issues that we haven’t worked past. So far we have the abilities for each of our bee types in place and working in our blocked out level. We’ve designed and redesigned the obstacles involved in the game and we’re happy with the basic progression of these so far, but obviously we’ll continue to change and refine them until we have a complete demo.

XNA, C# and Visual Studio

XNA is working very well for us, and we’re making far more progress than we expected. Compared to the OGRE engine which we worked with on our last project XNA has a lot of similarities – it’s very flexible and allows the developer to decide the extent to which they rely on built in functionality. However, XNA does have an advantage in terms of the amount of features available without relying on third party libraries and although content loading hasn’t been entirely painless, the design of XNA’s content pipeline is really nice.

We’re using our own systems for basic physics and collision detection, so the only external functionality we’re making use of is XNAnimation for skeletal animation and EasyConfig for config file loading. Both of these integrated incredibly easily with XNA and are working very well for us. While early on we did consider using IronPython for scripting support, simply loading values from config files is providing more than enough flexibility for us so far, and the format we’re working with has far less overhead than creating XML files.

Although none of the team had much C# experience before the start of Dare, it didn’t take long to get used to it. Obviously we don’t yet have the same level of understanding of the language as we did with C++, but for most functionality the two are similar enough that it isn’t an issue. The fact that Visual Studio 2008 practically writes the code for us is also helpful here…

Websites and all that

We’ve got some concept art and renders up on our page on the Dare website, where you can also check out the games other teams are working on. We also have a twitter feed, though mostly we just share pictures of bees.

• We need to know what’s technically possible, what sort of limits we’re likely face with certain systems and types of gameplay.
• It ensures the group is all on the same page in terms of the core mechanics of the game, that it’s going to work in the way we’re all imagining.
• By fiddling with values and experimenting with different dynamics we might discover gameplay elements we wouldn’t have thought of otherwise.
• Most importantly… We know whether our idea is fun.

“You can’t argue with a prototype… If it’s cool, people shut up.” — Chris Hecker

If something we want to build is going to be fun to play, it has to be enjoyable right from the most basic gameplay elements. Even with all the awesome artwork in the world, heavy theming will not salvage bad design. So no matter how great our idea seemed to be, if we had tried to prototype it and came up with demos that just weren’t fun to play around with, we would have been back at the drawing board all over again.

So, lets looks at the prototyping work from a more technical point of view. I’ve been using Python 2.6 along with Pyglet, and despite never having so much as looked at either of those before I’ve been able to get things working incredibly quickly. Compared to working in C++ and setting up devices and frameworks, this has been a very refreshing way to develop.

In the past I’ve used Actionscript to get together very rough prototypes, but given the (previous) lack of object orientation, the difficulty it takes to set up a new project and the fact that Adobe Flash isn’t free, I’d definitely now say I prefer Python. Although there are obviously still many features of the language I have yet to get experienced with, the syntax was easy to pick up and come to terms with. Pyglet made it very simple to create a window and display graphics within it, and the commands for OpenGL remains the same as in C++.

Hopefully I’ll be able to get some other Python demos up on the site at some point, and eventually the prototypes I’ve been working on now.

So, what do you do about prototyping? Do you have any Python experience and if so how have you found it? Any tips or advice?