A major part of the project involves distributing microcells (fixed areas of the world) between a series of worker nodes both statically and dynamically. In order to test methods of achieving this, I created a small testbed application which simulates the task without networking. It is capable of using various methods to distribute cells, both at the start of the application and as it runs, both controlled by a central server and initiated by worker nodes and gives graphical and numerical feedback.

The images below were taken with a greatly reduced number of cells, and the work involved in processing each cell is artificial: there are no pathfinding characters yet. However hopefully it demonstrates to some extent how division of the world takes place, and allows me to easily test distribution methods before using them in the proper simulation.

Coloured by number of characters per cell.

Initial block distribution.

Random distribution for comparison.

Block distribution with dynamic passing after time.

As the actual application I am working on is written in C#, I used XNA to create the images here. As it is possible to render XNA frames to a windows form application with little difficulty, this is also the approach I will employ for visualising the complete project.

YinYangYou, our game, is a top-down two-player race to collect energy and skew the balance of the playing field. By throwing orbs into their opponents’ “holes”, each player can increase the amount of ground they control on the opposite side of the board, eventually claiming an entire side and winning the game. A range of exotic energy pickups, such as time control and hole switiching, add variety and tactical elements to the gameplay.

Developed using XNA, our prototype includes all the features we originally planned – although that isn’t to say the week went without a hitch. Lengthy code merges, a lack of shared source control and model import problems were exacerbated by the fact that having just met, our communication levels were far from ideal. However, by remaining flexible and getting to know each team members strengths and weaknesses, our workflow improved hugely throughout the week.

Even though this project was really short, I feel I got a lot from it. Spending time in groups with the same people for the past year let us refine development and programming methods which worked very well for us. Suddenly being dropped into an entirely different group challenged some of my beliefs and ideas, and reaffirmed others. The opportunity to talk to industry mentors about this game and about development in general was also hugely beneficial.

Finally, I just want to say thanks to Iain Smith for organising the event, all the mentors and other participants for their help and to the rest of Team Be for making YinYangYou a success.

We pitched our games to the other participants on Friday, having only just managed to meet up the morning beforehand. Luckily we’d managed to agree on a game design through online meetings on Skype, but there were elements that we didn’t fully decide upon until we met face to face.

This morning (early this morning) we got together in Whitespace to actually start work. The team is composed of two programmers, two artists and an audio producer, and while we have roles and some idea of what we each need to achieve it’s hard to know exactly what we will end up with until we get to know each other better.

Waj, the other coder, and I settled into development over the weekend before by developing a particle system manager and a flexible 2D game framework respectively (we, of course, couldn’t start work on the game until today). Luckily, we have XNA at our disposal which should make a big difference to what we can get through in the timespan. Today however, much of each our time was spent simply merging code: lacking an SVN client on the university computers we were attempting to simply use Dropbox. Scary, and time consuming. Hopefully tomorrow we can make use a portable command line SVN client to keep track of changes.

Another issue we’re facing is in terms of work distribution and each having our own coding standards. As you might imagine, most of the problem is with communication – to a small extent because we don’t know each other, but mostly because we barely had time to come up with a game idea, let alone come up with task lists and naming schemes. We’re working things out the best we can as we go along though.

So, hopefully on friday we’ll have a simple top-down 2D game to share! Wish us luck.

Me: “But Abi! Surely I should work on bug fixes rather than implementing Depth of Field.”

Project Manager: “No, Hazel. You must work on awesome graphics effects.”

Me: “Sweeeet.”

Ok, so I’m paraphrasing a little but if there was a film of the actual situation I’m pretty certain this would have been the dialogue. We’d been talking about macro-photography inspired depth-of-field effects for a while but I wasn’t sure we’d actually find time to get it working. In reality, it took less than a day to implement, didn’t kill our framerate and (I think) looks fantastic.

Although I’ve really only been sharing bright and shiny screenshots of our game, it actually progresses from a sunny farm through to a dark and creepy forest. Naturally, this meant it was time to focus on implementing a coherent lighting model for the level. At the moment we’re working with ambient lighting, two directional lights and two spot lights per short section of our game.

In addition, I’ve been looking at methods for shadowing and shading. Each bee is an intricate model, but scaled down it would be easy to lose a lot of the detail. As you can hopefully see in the following images, shading adds some depth and makes the bees appear far more three dimensional.

Shade by distance from ground.

Shade when normals point down.

Combined Shading Techniques.

Combined With Lighting.

 
 Similar techniques applied across the entire scene also improves the overall appearance, with and without lighting:

 
 Finally, here’s an additional happier version of the shot above, just to show the difference a change in lighting can make:

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.

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.