These four videos show a complete playthough of the level.

Don’t forget you can check out our other videos on our youtube channel.

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.

It’s Kinda Like Scrum …ish

Before we began developing Some Assembly Required, our first group project, we all did some reading on agile development and in particular on Scrum. As I’m sure most people can guess – actually following a development methodology in practice is nothing like learning about it in theory. Although we continuously refined the way we worked and organised the project, having a framework on which to base our development made a huge difference.

Using A Wiki

Partway through our first project we started using a wiki to track development, and we haven’t looked back since. Of course there are benefits to storing a spreadsheet or text document in source control, using a physical board or using specific management software, but wikis have several important features for us:

1. We can access it from anywhere with an internet connection.
2. It’s easy to share with anyone looking over the project, unlike a file stored in source control.
3. There’s little overhead in terms of setting it up and creating sortable tables.
4. Wikis support mixed media and internal links – you can easily connect pages about the areas you are working on.
5. Unlike fully fledged project planning software, all formatting is self imposed – you can easily change what information you store and how you use it.
6. We can keep all the information for bug tracking, priority lists and game design in one location.

Priority Is King

Although each programmer on the team had ideas about how they would like to specialise, let’s face it we’re all pretty inexperienced. We all have strengths and weaknesses, but in terms of areas of the codebase, no-one had a huge advantage in terms of experience. In most respects we were interchangeable.

Because of this, we were able to assign work based purely on priority. By that I mean we could split the work we had committed to into tasks, each with an individual time estimate, then sort them by importance. Each time we completed an objective, we could simply pick up the next most important – regardless of what area it related to.

This helped ensure no-ones work was blocked – for example we wouldn’t be stuck waiting for a piece of physics code in order to continue. It also meant we could all work on the game framework initially, build up gameplay throughout the project and the focus on polish and graphics towards the end.

A more mixed blessing was the way that we all had to get experience with every area of the codebase. As far as I see, this was fantastic in terms of experience. We all had to get used to writing code that we knew other programmers would read and alter, and with modifying and expanding the work of others. It ensured no-one “owned” an area of the codebase or became precious about their work being changed, and made sure we got used to writing maintainable code.

At the same time though, specialising would have allowed each of us to focus on one area and possibly get a fuller understanding of it. Also, as students, it would have given us separate pieces of code to declare as our own and a simpler answer to the question “So, what part did you work on?” than “All of it!”.

Keep Aligned With The Entire Team

Working on Some Assembly Required, one of the biggest problems on the project was the extent to which various team members were separate. Before work began on Pollen, we talked about using Scrum for the entire team. As soon as work began though, it became apparent that it wasn’t going to work out.

Having two artists, one 2D and one 3D, made it difficult to simply sort work by priority. Each task had to be carried out by one particular person, often in a particular order or going back and forward between artists (such as when texturing). Instead, we simply agreed which stories were going to be a priority in a given week, and decided which art assets and programming tasks would come of this.

At the beginning of the project, our 3D artists Jess made some placeholder assets: a sphere, a box and a billboard, as well as assets to test animation and texturing approaches. This made it easy to simply apply textures stating what an object was until it could be replaced with a final asset – we were never waiting on an object being produced or exported.

Part of the way through the project, we started assigning time each week towards ensuring any new assets produced were working in the game correctly.

Stay Flexible

One of the best aspects of working on a small team with complete control, and also of short iterations, is the extent to which you can adapt the development process. We tried things that didn’t work, for example for a while we tried to keep graphs of our progress. At the end of the day we just didn’t find them useful …so we just stopped. Nothing lost. At the same time though we also tried, for example, creating tasks that averaged at most 3 hours rather than 5 or 6, and that made development easier for everyone. There was plenty of room to experiment.

The same goes for design. No member of the team, on either project I’ve been part of, was an experienced game designer so needless to say we learned a whole lot as time went on. Although both projects were only ten weeks long, we still had time to make large changes to our original designs – for example trying and scrapping touch screen support, or adding puzzles based on throwing rocks once we had a feel for the mechanic.

Nothing Is Perfect

Of course, even though the last project went fairly smoothly from a development perspective, there is still a lot about our methods we could improve and a number of things we’d do differently if we were to begin another game. I hope to cover more about what didn’t work for us, and what we intend to rethink in a specific Pollen postmortem, but until then I’d love to hear from you. What problems or benefits can you see about the way we work? How does it compare to yourself or your team?

Although we didn’t win the competition, we got some great feedback about Pollen and the entire team is really pleased with our completed prototype. All the games produced this year were awesome, and it was nice to finally get a chace to play a lot of them.

It was also brilliant to see kids enjoying the game – especially to see them working their way through puzzles and helping each other choose which kind of bee to use. Even though the prototype took 15-25 minutes for most visitors to play through, almost all of the kids who started playing kept going until the completed the level.

While in general the public and judges told us they liked the idea, visual style and gameplay in Pollen, we found the biggest problem was with controls – gesture recognition using left and right mouse buttons. We’ve recieved a lot of encouragement to try and take the product forward onto Wii, DS, iPhone or through the XNA community which we’d love to do. Finding a control method which is intuitive and fun for every player, especially if we opt to continue using gesture based input, could well be one of our biggest challenges.

Anyway, thanks to everyone who supported us during the 10 weeks – it was a fantastic experience and made a huge difference to me as a developer. We should have final gameplay videos, a copy of the prototype level and a postmortem available soon.

Even though we only recorded it a week ago, it feels like a lot has changed in the game. If you’re in Edinburgh around the 14th to the 16th of August, you can come check out Pollen and all the Dare to be Digital games.

I like how colourful this game is making my blog look! We’ve had the ability to add post-processing effects to our game easily for a couple of weeks now, but have only just considered what to do with that. Inspired by some of the effect from rendering fur over the weekend, I created some examples of a brushstroke shader in effect the game. It’s good having a colourful 3D environment to play with like this.

Although it looks nice in screenshots, the way that assets move and colours change make it look as if the screen is swimming and as such is impractical for use in the game. I think with some consideration it would be possible to create an impressive looking environment in this way however it isn’t really suitable or relevant for what we’re working on now. So it’s something to consider another time.

Brushstrokes shader.

More brushstrokes.

 
 Along the way, we also played with a few different effects (a couple of which are shown below). At the end of the day though we don’t want to do anything which will cause huge changes to the textures Abi is creating, and simply having a coherent lighting model (which we do now!) greatly improves the game’s appearance.

Horrible toon(ish) shading.

Alpha values. Pretty, I guess.

Here’s the second Pollen progress video, recorded towards the end of week 4 (so around a week ago). Although it doesn’t reflect the state the game is in now
(more assets, better controls, better motions and animations for each bee type) it’s a huge jump from the first video we shared. It shows a basic walkthrough of our level, and how the different bees can be used. Since then, the level has been tweaked (ie made less brutal), we’ve added a tutorial, the tunnel section looks less like it “is from the movie Saw” (Ian’s description) and we’ve started work on our scary boss battle.

Obviously the game is still far from finished, so we’ve got a lot of room to change and adjust it. If you have any feedback or suggestions, we’d love to hear them.

There seems to be a commonly held belief that secretly all games programmers long to be artists.

I’ll admit that being able to draw anything even remotely resembling what I’m aiming for can be disappointing, but I certainly would never want to switch from being a programmer. That said, spending hours on a demo only for it to be ruined by horrible coder art is almost as frustrating as try to explain why it really *is* cool even if it doesn’t look like much. I guess that’s why I’ve fallen in love with the idea of procedural content generation.

Anyway, for me one of the best things about taking part in Dare to be Digital is getting to collaborate so closely with talented artists. Not just being given assets and getting them into the game as often ended up the case with my last project, but sitting as a whole team each day and discussing overall appearance and design. Each build looks far more impressive than the last as well as just having more features.

Obviously there are technical benefits as well. I’ve learned a whole lot about the processes 2D and 3D artists actually go through to develop content, what parts are most time consuming and what can be done far quicker than I’d imagined. And in terms of the art pipeline, it’s much easier to solve problems when you can talk through export and import options together.

The biggest thing for me though is really feeling like shaders and particle effects are there to compliment anything the artist produce. In personal and university projects, the aim often seems to end up being cramming in as many effects as possible to match a marker’s checklist, or to cover for the lack of assets. Here, it’s all about getting everything the artists produce looking as good as possible on the hardware we have, and ending up with a demo that looks coherent rather than just sparkly.

It’s now half way through week 3 of Dare to be Digital, and although progress has slowed slightly as we focus on refining our level, things are still coming along nicely.

Although the core gameplay remains the same (swarming, the abilities of various bee classes) we’ve made some huge changes to our level. It’s now far more focussed on platforming and simple obstacles, rather than obscure puzzles, and balanced between the strengths of each type of bee. The gesture controls are working well, allowing all bee actions to be based on circling an object (for example to select some pollen to pick up) or drawing a line (for example to throw a rock in a particular direction), making it fairly easy to interact with objects even when they are moving or quite small, and would have been difficult to click.

Despite a few issues we’ve had with textures, animations and shaders, we’re getting a lot more art assets into the game to replace some horrific coder art which Ian and I added. On the advice of our mentors, we have also made some adjustments to our group plane and camera making the level far more fluid. There are a lot of improvements still to be made but we’re focussing on prioritising each feature correctly, so hopefully we’ll get through all of the most important ones.