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.
So, it’s been 2 weeks since Dare to be Digital started and I’ve failed to write anything about it so far, so here’s an update.
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.
I’ve been talking over a game idea with some friends recently. We’ve had a lot of thoughts on what our game should involve, but naturally before we can proceed much further we need to look at making some prototypes.
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?