FMP reflection and deconstruction
To first start of my research for my MA I am going to reflect on and deconstruct my FMP from last year to find out what went wrong and how we can fix it for this year.
Last year Me, James and Hazrat (also doing the masters) made this game (more a vertical slice or demo of a game) for our FMP: [1]
This year me and James want to work together again and produce another game but better; so firstly I need to figure out where this one failed.
List of things that went wrong:
- Naming conventions
We had a naming convention set up but not everyone understood it.
The preferred naming convention is as follows:
Used for folders [2]
Used for assets ect. [2]
When importing skeletal meshes. [2]
When importing static meshes [2]
When importing textures. [2]
- Having set roles
At first we thought we knew who was working on what but it ended up being better for just one person to work on one thing and in some cases two to work on another.
Our initial approach:
The way the roles should have been split up:
This is due to some things taking longer than others and somethings only being able to be worked on by one person.
- Time for game prototyping
The beginning of the project is arguably the most important and because we were trying to make a game for our FMP at uni we came across the problem of start dates. This was a problem due to prototyping needing to be the first thing we do, concepting also needs to be done at this time but we had already started that by using pinterest before the project and already had a solid idea of what we wanted to do. In short the prototyping needed to be started before everything else or people end up waiting on things and this inevitably slows things down and eats up more time. This diagram below is a simplified version of a game dev pipeline.
Pipe line example [3]
- Asset transfer and materials (source control)
Something that would have changed the pace of our project immensely is the use of source control. Source control allows more than one person to work in engine at the same time; If I wanted to import textures and assets I could do so without having to stop James and get him to import what I needed.
- Planning
Our planning as a group not efficient and we tended not to stick to it. We were too ambitious and thought that 20 weeks was a large amount of time and thus allocated time to have things done faster than we actually could; this then ate into our buffer and polishing time. We also didn't plan for things to go wrong, so when engine crashed and when lighting needed building we were using up time we had planned for something else. Using something like a waterfall production line might have helped more and we could adjust this as we went so we knew how much time we had left for everything else.
Example of a waterfall pipeline [4]
- 3D work flow
We had a lot of problems with meshes not being polished enough or having little things missed. We would end up having to evaluate the work and sending it back for corrections; which in process wastes time. By following something like this simple 3D workflow you can stop this from happening. Obviously this would need to be tried and tested and its naive in the sense of what needs to be done first or what needs to be done at all but these things listed we the main problems we faced in our FMP.
- Balancing art and game play
We had a few issues with how this project would be marked so we needed to make sure that their was more art in it than game play or technical things as we are a game art course not a game design course. Luckily this year we will not have this problem as we set our own projects and marking criteria.
- Lack of communication
When you are working in a group/team you need to be able to talk to each other without worrying about offending them because its about the work and it shouldn't be personal. We also had the problem of people not listening or forgetting to tell someone they had finished something. The best way to fix lack of communication is to speak to each other openly and take notes so that you know what you are doing and what someone else is doing what they have done.
Overall the project went well considering how experimental it was; by doing this project it has made it easier to plan for the next game. I will be able to take these problems we went through and fix them by applying everything I have written about above. By doing the FMP it really set in stone that I want to be in game development and not just one set job. My next step is to analyse how indie companies work and how I could fit into a job role at one.
Bibliography:
[1] JAMES BRODERCK DESIGN (2016) Guiding sprites – Teaser 1. [Online Film] Available from: www.youtube.com/watch?v=t9tn11fdnSA&feature=youtu.be [Accessed 08/11/16]
[2] ALLAR, M. (2016) Asset Naming Conventions. [Online] Gamemakin LLC. Available from: https://github.com/Allar/ue4-style-guide?utm_source=launcher&utm_medium=chromium&utm_term=spotlight&utm_content=styleGuide&utm_campaign=communitytab&p=593212&viewfull=1#post593212 [Accessed 08/11/16]
[3] KGIS COMPANY (2015) Production pipe line. [Online image] Available from: http://xn----itbkqkfiq.xn--p1ai/11-bari/production-pipe-line.php [Accessed 08/11/16]
[4] THE OMNI GROUP (n.d.) Step 9: Connect Tasks with Dependency Lines. [Online image] Available from: https://support.omnigroup.com/documentation/omniplan/mac/2.4.1/en/working-in-omniplan-a-tutorial/ [Accessed 08/11/16]