This is a post-mortem for the project “The Wisp”. The project was able to be completed as a vertical slice as opposed to the initially intended complete product. Future additions are planned for it, but as the due date has passed, the development time for the project has concluded and this blog will talk about the ups and downs the project had. This blog will offer solutions to anyone who comes across this and has similar problems for their project.
What Went Wrong
Over the course of the past 2 trimesters, most of the time available for us to develop the project was outside of class time. Some of this time should have been used for talking about aspects of the project and updating each other for what the state of the project was at. The amount of time allocated to the project per week, outside of class, was 12 hours, which when added to the time in class, reached the full-time study requirement.
The primary cause of this was the lack of motivation to communicate. Most of the time we all knew what we were doing, only rarely asking others for information. Due to this, everyone assumed that others didn’t need to know the current state of things and were almost completely autonomous.
A way to solve this problem would be to enforce communication for a few weeks at the beginning of the project so that everyone gets into the rhythm of updating each other. Talking at least once a day will allow people to begin repeating it, getting used to talking without any prompt.
Our game was over-scoped from the beginning. We assumed we could have finished the project in the time given, though the change in aspects of the game mid-way through the project wasn’t helpful to this, though the changes weren’t too large. There were too many minor aspects that took too much time to be completed within the allocated time that had us push milestones back. Due to the push back of milestones, polish was not possible which resulted in a less than satisfactory product to be produced.
Due to the amount of time we had for the project, we assumed the project could be completed before the time was over. This was a bad move on our part as the minorities overtook us. Some of the problems were pertaining to some assets being used. These assets hadn’t been tested and therefore we didn’t know the limits of them until they were reached. Miscalculated time requirements were a big issue as well since they helped push tasks back which threw our project planning into the wind.
A solution to this would be to purposefully under scope the project so there is far than enough time for polishing. Having excess time for polishing also allows for additional aspects to be conceived and implemented, allowing for a more well scoped project. Calculated time requirements are also a big issue as the amount of time added may be too small of a number. Multiplying the amount of time thought to take by a large number, such as 3, allows for the minor aspects of the task to be overcome, hopefully not pushing back other tasks and causing a chain reaction that makes the time allocated to the project larger than hoped.
Our team’s management wasn’t the best. Most of the milestones set weren’t reached at the targeted time. This made the project timeline to be crunched towards the end and resulted in an unsatisfactory product that not everyone was happy with.
Poor project planning in terms of the programmers. Time estimates were off which made tasks last longer than they were intended to be. There was also the problem with everyone’s timelines, which were not lined up to each other. The time we allocated per week was to have a day together where we just made the game and other days in which we were to work independently. This fell out of whack due to work with we hadn’t planned for. Not everyone was available to work on the same day which killed that idea and made productivity very low.
Schedule the team’s lives around a plan for the project. Choose a day in which no one is allowed to have anything on and use that as a day in which everyone can work together in the same space, allowing the communication of the group to flourish.
What went right
When development began, the documentation was already mostly done, giving the programmers a lot to work off of. Albeit there were some aspects that weren’t completely thought-out, so there were some hick-ups, but what was done allowed for a base to be built.
The main reason this occurred was due to the methodology we were undergoing, which was to have a rough design to build upon and to get the ball rolling for development. Since design was needed before production, the main aspects of the project needed to be outlined, which made us require this, and once we had a rough document, we developed the game alongside more documentation, which eliminated the production being halted for a while.
How to enforce
When beginning a project, it is usually best to be able to write out all aspects of it. This allows the designer to better understand the project if they can get it all out into words. There is also the problem of the programmers needing to be able to know what exactly to implement before going into implement anything. Having them completely understand what is needed allows for them to make it the way the designer envisioned and reduce any waste of work due to reiteration of the implementation.
At the beginning of the project, we frequently had meetings to allow us to flesh out the roles of the team and the idea of the game. Having everyone’s input of the game allowed us to create a project everyone would have been happy with making. It also allowed us to identify what aspects are too difficult to complete within the time required or if it would be better to do it a different way for performance or gameplay reasons.
Meetings were something we held in high regard, it was something that we knew we needed a lot of at the beginning of the project. To begin the project, we had no idea what was going to be, we needed everyone’s to allow for a basic idea, once we had that we then needed to flesh the idea out, having everyone offer their opinion as to how certain aspects can be better or how different additions would make it better.
How to enforce
Find whether everyone has a complete grasp on the project or if it’s fun, if either of these are anything but a resounding ‘yes’, then have more meetings. This is especially important at the beginning of the project as no one has an idea of what it will be. Having meetings with a purpose is also important; create a list of meeting goals so as not to waste time. You want to use a goal to get the meeting started, have it focused, else you can just have a meaningless talk amongst the team that results in some people walking away more confused than going into the project.
In conclusion, we were able to produce a vertical slice of the project, but there were a lot of problems that arose which we hadn’t planned for. Luckily we had prior experience with games development and overcome the hurdles we faced, though most of the hurdles harmed the project to the point that the end result was something sub-par. Though we had problems, we were able to success at other aspects of the project which allowed for us to get to where we needed to be at the end of the allocated time. We did learn aspects of production which will allow us to create better products in the future which is always important when walking away from a project.