In this blog post, I will be talking about how we, as a code team, planned for the R&D phase, communicated with the art and design teams, the mistakes we’ve made and how we could have better managed this phase if we did it again.
Start of R&D – Goals
We started off the module given a task: to build a framework for our game in PhyreEngine, and to prove gameplay mechanics (i.e. built a whitebox level). Since PhyreEngine was completely new to us, we didn’t really know where to start, so we’ve had a couple of meetings to try and figure out how we’re going to achieve what’s required from us.
At this point, we didn’t have a game design at all – we knew we’re building a racing game but that just about covers it. So we didn’t really know all of the features we need to test in PhyreEngine. Therefore, we started thinking about features that pretty much any racing game needs:
Menu-ing systems to support things like main menu, car select, track select, etc.
Object pooling for things like bullets, etc.
AI Navigation
Vehicle controls
Physics, collision detection, etc.
Sound
Particles
PS4 Controller features
Technical limitations of PS4/PhyreEngine
Exporting from Maya to PhyreEngine
Camera
However, one looming question that no one really had the answer for was simply “Where do we put our gameplay code?”. So, for the first week or two, we spend time reading the user guide for Phyre, looking at samples and doing tutorials for PhyreEngine.
We found out that Phyre supports an entity-component based system, so we figured we’d try to take advantage of that. After the whole “poking Phyre to see what happens” phase finished, we figured we need to start becoming more productive than that, and had a couple more meetings to decide on a plan of action and how to manage our work.
At this point, we knew something about our game design as well: it would be something akin to F-Zero and Mario Kart. This gave us information in terms of pickups, vehicle controller, the types of tracks we would have and so on. So we outlined some of the tasks we have and created a Trello board to keep track of them:
On a big-picture basis, this is pretty much how we divided work:
James focused on researching the Camera, making it follow the player vehicle and all sorts of camera effects.
Sunny focused on finding out the technical limitations of Phyre in terms of poly counts, texture resolutions and so on. He also went on to research sound and the various PS4 controller inputs.
Joe focused on creating menu-ing systems
Alvaro researched the physics engine, and then went on to research AI features
Radu went into implementing guns for our game, starting off with the laser. In the process, he also implemented a system for loading multiple levels and transitioning between them
I opted to construct our template solution and our framework structure as an entity-component based system – find a place to put our gameplay code in. Afterwards, I worked on the vehicle controller.
So we roughly divided up work between ourselves, but that was that. The trello board was soon abandoned, mainly because all of the tasks were progressing really slowly, and that the game design changed 180 degrees every other week. However, it seemed that at least most of the team members had a better understanding of what the end-goal for the module is.
I can’t clearly remember who specifically did this, but we also went to investigate any potential issues with the art pipeline – we had Freddy provide us with some assets, investigated how exactly they should be imported to Phyre, and what issues we’d encounter. At first, we had trouble importing collision boxes from Maya to Phyre, but we managed to resolve those issues.
For the other part of the interdisciplinary work pipeline between art and code, we ended up not having to build much in terms of tools, since the focus of our project is using the level editor as much as possible, and artists readily have access to it. This meant that the artists could in fact test all of their models/textures/normal and so on themselves, and the code team would not need to get involved in making any of this work.
Mistakes made, and how I’d do everything again
Reflecting upon how this module went, I think the biggest mistake made my all of the team is lack of communication. Starting off with the code team themselves. Instead of closely reporting progress between team members and having daily stand-up meetings, we mostly worked individually – everyone roughly new what everyone’s working on, but no one really knew each other’s progress. To mitigate that somewhat, we decided to switch our desks around, so that we can easily glance at each other’s screens. However, the biggest issue that came out of all this was that one team member would potentially get stuck with some errors for days, whereas another member might have had the same issue and found a solution to it already. I know for sure that this happened to James, but I’m pretty sure that other members experienced problems down the line as well, but they never discussed them with the rest of the team (solving the issues themselves instead).
Once I noticed this was happening, I started compiling a list of issues I’ve encountered when working with Phyre and managed to solve/work around, hoping that this might help some of the team members: http://gamercamp2015.pbworks.com/w/page/105189303/How%20to%20update%20your%20game%20build%20for%20the%20PhyreLevelEditor . However, the fact that the team encountered issues and no one knew about that means that time was inevitably wasted, so we really really should have daily stand-up meetings to discuss any blockers, as that would have helped to solve some of the issues a lot faster.
That was pretty much the main mistake we made within the code team, so I’ll discuss the mistakes we made within the whole of the dev team. And really, there was only one issue – lack of communication. Since the game design was incredibly fragile and changed so much so often, the changes would go on unreported and we felt that by the end of the module, no one really knew what our game is about exactly. We should have spoken more to the design team, and the design team should have done a better job reporting design changes to the rest of the team as well. If we did this effectively, I would have not had to throw away the code I wrote for ground vehicles when it all changed to having drones flying in all axes.
Furthermore and in general, I felt that the whole design process this module was miscommunicated a lot. For the iOS game, we had lots of meetings with all of the team to discuss the design of our game and what gameplay we’re going to have. In this module, we were actually felt barred from chipping in to the design by our lecturers, and as a result the design team ended up having all of these discussions alone. This resulted in the fact that the design was poorly understood by the team, the team (especially the art team) weren’t clear on what their immediate goals are as we were stuck waiting for a design to be made, and all design decisions were foggy, miscommunicated, done late, and unclear in their motivation.
So for the most part, both the code and art teams were supposed to work on a game without knowing what the game is, making it a real challenge to set out goals and make meaningful progress. This meant that the art team had to re-make the theme several times, and the code team was blocked from implementing any core mechanics for our white box – it wasn’t clear what weapons we’d have in our game, it wasn’t clear how the AI is going to perform, it wasn’t clear how the vehicles are going to control, it wasn’t clear what the tracks would look like and what features would be in them, it wasn’t clear how the pickups would work or what menus we’d have in our game. This could have all been remedied by having more communication between the disciplines for the most part. For the other part, when the design decisions were lagging behind, it might have been a lot faster to brainstorm design with more members of the team – we’d all understand the design better, and we’d more quickly come up with ideas for weapons etc.
Up to this point, I really don’t know why the design team worked in such isolation as they did, but if we were to do this again, I think we’d get better results from all of us working together. At different points through the module, it felt like some sort of a power struggle between various members in terms of everyone wanting their ideas to make it to the game. This isn’t really how a team should behave, and the module didn’t seem that much like a collaborative effort. We’re all working towards the same product, and we should be doing this together, and not individually. Not to mention the fact that the design changed so much every time some visitor came in and gave us their thoughts of what the game should be.
So we finished off this module without really knowing what our game design is, or rather, what gameplay mechanics our game will have and how it’s going to control. We know that it’s drone racing, and that it’s supposed to be arcade, but that doesn’t tell us much in terms of what the actual game is going to be. The best we currently have is some youtube videos of drone racing done by professionals with realistic controls, which is far from our goal of an easy to control, arcade-y drone action game.
If anything, the key point going forwards is that we need to work a lot more together to define what we’re setting out to make and making sure we understand each other properly.
XDR R&D #1: Teamwork and management
Introduction
In this blog post, I will be talking about how we, as a code team, planned for the R&D phase, communicated with the art and design teams, the mistakes we’ve made and how we could have better managed this phase if we did it again.
Start of R&D – Goals
We started off the module given a task: to build a framework for our game in PhyreEngine, and to prove gameplay mechanics (i.e. built a whitebox level). Since PhyreEngine was completely new to us, we didn’t really know where to start, so we’ve had a couple of meetings to try and figure out how we’re going to achieve what’s required from us.
At this point, we didn’t have a game design at all – we knew we’re building a racing game but that just about covers it. So we didn’t really know all of the features we need to test in PhyreEngine. Therefore, we started thinking about features that pretty much any racing game needs:
However, one looming question that no one really had the answer for was simply “Where do we put our gameplay code?”. So, for the first week or two, we spend time reading the user guide for Phyre, looking at samples and doing tutorials for PhyreEngine.
We found out that Phyre supports an entity-component based system, so we figured we’d try to take advantage of that. After the whole “poking Phyre to see what happens” phase finished, we figured we need to start becoming more productive than that, and had a couple more meetings to decide on a plan of action and how to manage our work.
At this point, we knew something about our game design as well: it would be something akin to F-Zero and Mario Kart. This gave us information in terms of pickups, vehicle controller, the types of tracks we would have and so on. So we outlined some of the tasks we have and created a Trello board to keep track of them:
On a big-picture basis, this is pretty much how we divided work:
So we roughly divided up work between ourselves, but that was that. The trello board was soon abandoned, mainly because all of the tasks were progressing really slowly, and that the game design changed 180 degrees every other week. However, it seemed that at least most of the team members had a better understanding of what the end-goal for the module is.
I can’t clearly remember who specifically did this, but we also went to investigate any potential issues with the art pipeline – we had Freddy provide us with some assets, investigated how exactly they should be imported to Phyre, and what issues we’d encounter. At first, we had trouble importing collision boxes from Maya to Phyre, but we managed to resolve those issues.
For the other part of the interdisciplinary work pipeline between art and code, we ended up not having to build much in terms of tools, since the focus of our project is using the level editor as much as possible, and artists readily have access to it. This meant that the artists could in fact test all of their models/textures/normal and so on themselves, and the code team would not need to get involved in making any of this work.
Mistakes made, and how I’d do everything again
Reflecting upon how this module went, I think the biggest mistake made my all of the team is lack of communication. Starting off with the code team themselves. Instead of closely reporting progress between team members and having daily stand-up meetings, we mostly worked individually – everyone roughly new what everyone’s working on, but no one really knew each other’s progress. To mitigate that somewhat, we decided to switch our desks around, so that we can easily glance at each other’s screens. However, the biggest issue that came out of all this was that one team member would potentially get stuck with some errors for days, whereas another member might have had the same issue and found a solution to it already. I know for sure that this happened to James, but I’m pretty sure that other members experienced problems down the line as well, but they never discussed them with the rest of the team (solving the issues themselves instead).
Once I noticed this was happening, I started compiling a list of issues I’ve encountered when working with Phyre and managed to solve/work around, hoping that this might help some of the team members: http://gamercamp2015.pbworks.com/w/page/105189303/How%20to%20update%20your%20game%20build%20for%20the%20PhyreLevelEditor . However, the fact that the team encountered issues and no one knew about that means that time was inevitably wasted, so we really really should have daily stand-up meetings to discuss any blockers, as that would have helped to solve some of the issues a lot faster.
That was pretty much the main mistake we made within the code team, so I’ll discuss the mistakes we made within the whole of the dev team. And really, there was only one issue – lack of communication. Since the game design was incredibly fragile and changed so much so often, the changes would go on unreported and we felt that by the end of the module, no one really knew what our game is about exactly. We should have spoken more to the design team, and the design team should have done a better job reporting design changes to the rest of the team as well. If we did this effectively, I would have not had to throw away the code I wrote for ground vehicles when it all changed to having drones flying in all axes.
Furthermore and in general, I felt that the whole design process this module was miscommunicated a lot. For the iOS game, we had lots of meetings with all of the team to discuss the design of our game and what gameplay we’re going to have. In this module, we were actually felt barred from chipping in to the design by our lecturers, and as a result the design team ended up having all of these discussions alone. This resulted in the fact that the design was poorly understood by the team, the team (especially the art team) weren’t clear on what their immediate goals are as we were stuck waiting for a design to be made, and all design decisions were foggy, miscommunicated, done late, and unclear in their motivation.
So for the most part, both the code and art teams were supposed to work on a game without knowing what the game is, making it a real challenge to set out goals and make meaningful progress. This meant that the art team had to re-make the theme several times, and the code team was blocked from implementing any core mechanics for our white box – it wasn’t clear what weapons we’d have in our game, it wasn’t clear how the AI is going to perform, it wasn’t clear how the vehicles are going to control, it wasn’t clear what the tracks would look like and what features would be in them, it wasn’t clear how the pickups would work or what menus we’d have in our game. This could have all been remedied by having more communication between the disciplines for the most part. For the other part, when the design decisions were lagging behind, it might have been a lot faster to brainstorm design with more members of the team – we’d all understand the design better, and we’d more quickly come up with ideas for weapons etc.
Up to this point, I really don’t know why the design team worked in such isolation as they did, but if we were to do this again, I think we’d get better results from all of us working together. At different points through the module, it felt like some sort of a power struggle between various members in terms of everyone wanting their ideas to make it to the game. This isn’t really how a team should behave, and the module didn’t seem that much like a collaborative effort. We’re all working towards the same product, and we should be doing this together, and not individually. Not to mention the fact that the design changed so much every time some visitor came in and gave us their thoughts of what the game should be.
So we finished off this module without really knowing what our game design is, or rather, what gameplay mechanics our game will have and how it’s going to control. We know that it’s drone racing, and that it’s supposed to be arcade, but that doesn’t tell us much in terms of what the actual game is going to be. The best we currently have is some youtube videos of drone racing done by professionals with realistic controls, which is far from our goal of an easy to control, arcade-y drone action game.
If anything, the key point going forwards is that we need to work a lot more together to define what we’re setting out to make and making sure we understand each other properly.