Starting a Project with constraints
Author
Hi, Im Alex and obviously new here.
Im currently studying a game design course and next trimester we begin doing our final project which is to create a game using a group of designers/programmers/animators.
We have roughly 24 weeks to complete the game from concept and all the paper work to a final release copy.
Anyway, what Im look for is any tips on what should be thought about to make sure the project finishes on time.
Because I dont know too much about programming and dont know who will be in my group next year I dont know what sort of pitfalls to stay away from etc.
So far one idea i have come up with is a multiplayer game sort of like commandos where each player controls a squad of units via a RTS styled or Isometric RPG interface.
Another was a 2.5 D (wooooo buzz word) beat 'em up or platformer.
Now Im rambling but, yeah, any tips, tricks or advice would be greatly appreciated.
The key for any smallish project with hard time constraints is focus. Whatever idea you end up going with, you must be ready and able to identify a small set of core ideas -- then develop them fully while defending them from outside encroachment. By focusing on a small core of key design and gameplay elements, you will be able to refine and polish these to a high degree. Bring in too many elements, and you will find yourself to be spread very, very thin. This doesn't mean that you absolutely can not bring in additional elements later, but that any new element should serve a specific purpose and not upset what is already there. Design (or programming) complexity does not increase linearly with the number of elements, but very nearly exponentially.
When I was at Digipen, the game project instructors always emphasized that we were not there to create our magnum-opus -- because there simply wasn't time -- and instead to create what would be a demo of the full game we envisioned. Successful teams were able to hold themselves to it, those that didn't were over-worked, overstressed, and very often their other classwork suffered. I'm also quite certain it contributed to at least a couple folks dropping out. There were some teams that went truly above and beyond, but their entire teams were both very smart, and very disciplined in their studies (and also didn't typically lead much of a social life.)
A smaller, well executed and highly polished game that demonstrates that it could be much more that it is is a whole lot better than a long, disjoint misadventure held together with duct-tape and bubble-gum that makes everyone wish it was shorter than it was.
When I was at Digipen, the game project instructors always emphasized that we were not there to create our magnum-opus -- because there simply wasn't time -- and instead to create what would be a demo of the full game we envisioned. Successful teams were able to hold themselves to it, those that didn't were over-worked, overstressed, and very often their other classwork suffered. I'm also quite certain it contributed to at least a couple folks dropping out. There were some teams that went truly above and beyond, but their entire teams were both very smart, and very disciplined in their studies (and also didn't typically lead much of a social life.)
A smaller, well executed and highly polished game that demonstrates that it could be much more that it is is a whole lot better than a long, disjoint misadventure held together with duct-tape and bubble-gum that makes everyone wish it was shorter than it was.
There are many things to think about, but based on my experience with (both failed and successful) university projects, two aspects that can be really fatal if not done right are communication and project management.
Your team members should be talking to each other, and for a game this would also mean that your programmers need to be talking together with your designers/artists. Regular (weekly or biweekly) face to face meetings are a must to keep people focused and working. This is especially important for university because motivation is low due to other commitments and lack of a paycheck. Other communication channels are important, too, but just email by itself for instance is almost a guaranteed recipe for disaster. IM does not really cut it either. If all else fails, Skype can help, but face-to-face is really best to keep people motivated.
Project management is a continuous process. It starts on day one and is not done until you ship your project. At the beginning you will have some kind of brainstorming session and come up with a project plan. Maybe you will codify some milestones in a Gantt chart or similar tool. What frequently happens next is that this chart is shown to the project advisor from university-side, then put into the long drawer, never to see the light of day again. You have to perform controlling continuously and compare reality with the chart, making adjustments. Otherwise you will not even know that you are in trouble until it's already too late to salvage the project. This is also true for very small teams.
We made this last mistake with the web application we shipped last week for our institute. We had two people and sixteen weeks to build it, but a majority of the project took place over the last six weeks, and we ended up two weeks behind schedule. We did not perform any project controlling and had only a couple of face-to-face meetings. But towards the end of the project, communication drastically increased, as my phone bill will testify :-).
In any case you will also want to consider what is possible with the team you have. I don't have experience working with artists, but programmers at least will underestimate the programming effort required (I do this myself all the time - you'd think I'd learn after so long...). This is a fact of life that you will have to deal with when you plan the project - if your programmer guys tell you something will take six weeks, it will really take anywhere from twelve to sixteen. The less experience the programmers have, the longer it will take compared to their initial estimate. Feature creep also comes into this - software is never done but accumulates features if you don't know where to draw the line.
Tools and middleware are also important, because they can really cut down the time it takes to make something. No matter whether your game is in Python, Java, or C++, there are many great libraries and middleware solutions out there that you can take advantage of. Don't let your programmers come up with a new engine from scratch, as that will almost certainly take too long unless the game is really, really simple.
It almost goes without saying that you need a central version control system. Subversion does wonders for code but can also perform versioning for your other assets such as the project plan or your graphics assets that are part of the project. Nowadays, distributed version control systems are also popular, but I have no experience with those. You can get free hosting for Subversion projects from various providers on the net. Another online tool you could benefit from would be a central task and bug tracker.
Your team members should be talking to each other, and for a game this would also mean that your programmers need to be talking together with your designers/artists. Regular (weekly or biweekly) face to face meetings are a must to keep people focused and working. This is especially important for university because motivation is low due to other commitments and lack of a paycheck. Other communication channels are important, too, but just email by itself for instance is almost a guaranteed recipe for disaster. IM does not really cut it either. If all else fails, Skype can help, but face-to-face is really best to keep people motivated.
Project management is a continuous process. It starts on day one and is not done until you ship your project. At the beginning you will have some kind of brainstorming session and come up with a project plan. Maybe you will codify some milestones in a Gantt chart or similar tool. What frequently happens next is that this chart is shown to the project advisor from university-side, then put into the long drawer, never to see the light of day again. You have to perform controlling continuously and compare reality with the chart, making adjustments. Otherwise you will not even know that you are in trouble until it's already too late to salvage the project. This is also true for very small teams.
We made this last mistake with the web application we shipped last week for our institute. We had two people and sixteen weeks to build it, but a majority of the project took place over the last six weeks, and we ended up two weeks behind schedule. We did not perform any project controlling and had only a couple of face-to-face meetings. But towards the end of the project, communication drastically increased, as my phone bill will testify :-).
In any case you will also want to consider what is possible with the team you have. I don't have experience working with artists, but programmers at least will underestimate the programming effort required (I do this myself all the time - you'd think I'd learn after so long...). This is a fact of life that you will have to deal with when you plan the project - if your programmer guys tell you something will take six weeks, it will really take anywhere from twelve to sixteen. The less experience the programmers have, the longer it will take compared to their initial estimate. Feature creep also comes into this - software is never done but accumulates features if you don't know where to draw the line.
Tools and middleware are also important, because they can really cut down the time it takes to make something. No matter whether your game is in Python, Java, or C++, there are many great libraries and middleware solutions out there that you can take advantage of. Don't let your programmers come up with a new engine from scratch, as that will almost certainly take too long unless the game is really, really simple.
It almost goes without saying that you need a central version control system. Subversion does wonders for code but can also perform versioning for your other assets such as the project plan or your graphics assets that are part of the project. Nowadays, distributed version control systems are also popular, but I have no experience with those. You can get free hosting for Subversion projects from various providers on the net. Another online tool you could benefit from would be a central task and bug tracker.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
