Gamebryo

Applied Game Development: Gamebryo Project – Progress Videos

Across this semester in my Applied Game Development Module I’ve been assigned to a group to create an ‘Exciting Racing Game’ using the Gamebryo engine. We’re incredibly lucky to have this oppurtunity to develop with the Academic version of Gamebryo at the University of Derby.

My group is only small, made up of 4 programmers – I was elected to be the groups project leader.

With our group being the smallest in the Module, as project leader I decided my group would create a framework to build a game on top of, to avoid us falling into the feature creep hunny trap. Our first milestone was to better ourselves with the Gamebryo framework by disecting one of the samples provided by Emergent.

The video above shows an adapted tutorial, we’ve added basic user control, a flexible camera and we’ve changed the main character (Programmer art at it’s finest )

As you can see in the Progress Video, our main character can travel through the floor. I believed that solving that issue early on would allow us to further prototype additional collision and features. After a lot of research into the Gamebryo framework, we’ve switched levels and we’ve acquired a tempory vehicle asset (No more brick) all helped in developing our system for collision.

The method we decided on was casting a ray from the vehicles position and testing that ray against the terrain mesh. If a collision was found then the vehicle would be clamped to just above that collision. This next video should demonstate this new system.

With the terrain collision in place, we can now work toward object collision. In Gamebryo, there are two types of colliders, a collider and a collideé, both needed Alternative Bounding Volumes however the collidee needs addition data stored inside the model that was placed when converting from Maya or 3DSMax. Sadly our nice new car model did not have that data, so after searching through many assets from other demos in Emergents AssetViewer we found a model that has the relavent data. This was the best we could find.

Using the MyEmmerse tool in Maya, and a bit of code changes, we were able to get our car asset back in the game with collideé data. Additionally, at this point we’ve began prototyping our user interface – it’s current holding debugging data.

Though we were satisfied with our progress on the framework so far, it’s still far from a game. My groups next milestone was to prototype AI, pick ups, fuel and health mechanics and a loading screen / menu system.

In the video you can see our latest vehicle placeholder asset, which is a little closer to the final product. The AI being demoed here currently reads a list of hard coded positions to head to; at the moment we are working hard to have him turn in the right direction when heading to the next node and should be available to see at our next Progress Video.

Additionally, the demo shows our acceleration system, pick ups (Although the placement is a bit iffy) – I’m personally really enjoying the speed boost pick up! The video quality makes showing the fuel and health system a little difficult as the font size in the UI is quite small, you’ll just have to trust me when I say it’s going down and back up and right times.

Final Demonstration

A few weeks after the previous video our team began pushing towards the Alpha hand-in, which was to be feature complete at this time. However, sadly 2 of our 4 team members were unable to continue working with us, leaving just two of us for the rest of the project. Together we pushed hard toward the Alpha deadline, and submitted a feature complete project – from that point onwards we began fixed bugs and preparing our documentation and presentations for this project.

Additionally and unfortunately, our artists did complete their schedules all to plan and as a concequence no new art assets was recieved, so we had to make do with what we had, which we found to be quite depressing as the games progression looks to quite limited to an outside viewer, when we programmers knew a lot had changed and for the better.

Conclusion

Though the final product may not be as visually amazing as myself and the team would have hoped, I believe as a group of programmers we achieved a lot. Our group was the first in the class to fully implement terrain following, additionally we were one of the only groups to include an AI that wasn’t bound entirely to a rail.

Our subsystems too, like our AI / Input / UI Manager, were well designed and documented – following the examples from Gamma Johnson’s ‘Design Patterns’, to better understand design patterns and industry standards for later work, and the examples of the Unified Modeling Language to better understand object orientation discussion and documentation – this allowed for us to present work easier to colleagues and lecturers if any problems came up.

Finally, as a leader I took on a task far larger than I’d ever lead before, I learnt first hand the difficulties of co-ordinating the schedules of two very individual teams with their own desires and free time.

I learnt so much more from this module than the normal programming teachings, I learnt to lead, to co-ordinate and I like to think I learnt to inspire to, and I’ve very grateful they elected me to lead the group on day 1 of the project.

As a very final note, I’d like to include pictures of our programs Headers and Source files to give the impression of how much work and effort went into the project.

From our Gamebryo Group Project

From our Gamebryo Group Project