Some thoughts on Guiding Sprites, important notes about planning a gamedev project

Hi there, as you know earlier this year as my last project for my game art course at De Montfort University I created a puzzle adventure game with Amber Jamieson and Hazrat Bilal called Guiding Sprites. For those who don't know, there is a week by week post on this blog on the development, but for a quick taste of what we created here is a little youtube teaser:

As I head into my masters degree focusing more on general game development it was advised to me by my tutor that it might be a good idea to cast my mind back and see what I can learn from the experience, seeing as it was our first complex game development project. Guiding Sprites was massively ambitious for the time that we had during the FMP, and was actually planned as a whole game with just a vertical slice created just for the FMP time frame. We would then use the vertical slice as a way to pitch the game to possible investors in order to fund the rest of the development. As I said that was the plan, and sometimes the plans don't always work out.

Because of the timeframe we had a lot of issues during the development of the vertical slice. The main problem is that gameplay and art constantly got in the way of each other and we had to sacrifice a lot of features, this also led to slowdowns throughout the project which in turn led to the shifting of plans. Usually in game development a game design or prototype is made before art assets are ready to go, but because of the time we had on the project we just had to push ahead regardless and work. A lot of this could be down to our relative inexperience aswell, at the time we weren't really knowledgeable on how the game development project management actually works, if we had some sort of source control or project management system in place it would have gone a lot better.

We saw the game as being almost like a short novel, with quite a short playtime but despite that the environments and interactions on the way would be quite complex, in the 20 week time frame we had for the FMP that definitely wasn't possible, but creating a demo-like section of that we thought could have been. An estimate that we come up with is that if we continued the game through to completion it would take around 2-3 years. If we were to continue that during our masters now, my feeling is that the same problems will carry on, because we jumped into the deep end and need some other experience and skills first before we would be able to do a large project like that justice.

I am still proud of what we managed to do during the project, we were the first students to design and create a playable game of this kind, but moving on we need to build on what worked and what didn't. This mainly involves learning new planning techniques or adopting some kind of pipeline to make the game development process 100x as efficient as what it was during FMP.

Moving on

What do we do next to avoid the same issues? The source of the problems we had can be put down to conflicting gameplay and art, but that is also something that results from the planning of the project. The scope, the included features, even the art style have a certain budget on time depending on their complexity. Gameplay needs to be done before art as opposed to starting both at the same time otherwise there will be a wait on the gameplay to have a playable section before assets can go in. Juggling assets between people using hard drives also slows down development; as only one person can work in engine at a time (mainly myself) work would have to be split between importing in assets and actually fleshing out the game. To counter this issue proper naming conventions and source control must be managed, which is the industry practise.

Also a more defined approach to the roles within the team, this is usually helped when source control is used as then it takes the burden away from the 'engine person' to setup their imported assets correctly like animations and materials. This just makes everything a bit easier and means that there is no confusion about each person's role in the team. Having someone who jumps between working in UE4, then going to concepting, then back to modelling isn't very efficient unless it's more planned out. It is better to have someone on the team who has those dedicated skills for each area, depending on scope. This isn't necessarily the perfect way to do it, but for me and Amber it works a lot better.

Another thing to make it more efficient and take away some of the potential issues is using a proper naming convention and file structure. This became a major problem later in the project where the asset list was building up and things needed to go in, but I was unsure what was what because I could see different naming conventions in use. I found this fantastic guide for making UE4 projects more consistent created by Michael Allar https://github.com/Allar/ue4-style-guide, it basically covers every single asset type within unreal and provides a prefix for them, aswell as correct suffixes for textures and the correct folder structures within unreal. Having a massive document like this is hugely beneficial and takes time away from making trivial decisions about naming things, removing most issues that we got before due to not being able to find certain files. (Allar, 2016)

Seriously, if you are working in UE4 consider using this document as a base to plan with, it makes everything 10x easier, also if you are working on a marketplace item they will expect this kind of naming convention to be used.

Mainly then, to improve in our next projects we need better planning. Better project structure. To be wary of scope and a bit of foresight to the effects of what adding or changing something in the project can do for time. Below are the main points and some things I will be looking at using properly over my next few projects:

• Practise project management methodologies - Things like Agile, Scrum or waterfall can really help a project move forward, and makes it easier to plan new things and work around possible hurdles.
• Source Control - Git or Perforce, something to make sure that all the people in the team can contribute to the project at the same time without having to wait on someone all the time for a certain piece of work to be done in engine. Perforce is preferred as files can be 'Checked Out' so they can't be edited by anybody else currently using the engine file.
• Naming conventions - A lifesaver, saves so much hassle and grief when a lot of files are being moved around or added. If everything is where it's supposed to be it makes the level design job a lot easier.
• Keeping an eye on scope - this is more something which can be avoided with proper project management, as well as being generally critical of how long things would take - you get more of an idea of this as you do more projects.

Generally though a lot of this can be improved through working on a lot of smaller projects and getting better at game dev. It's not easy, but maybe taking a step back and making some smaller games can help focus efforts on the process, which could be scaled up later when they are ready for larger projects. That is essentially my next goal: To create a load of really small, experimental projects in which all these skills could be practised and honed, before moving on to bigger things again. 

Then maybe further down the line we could come back to Guiding Sprites and make the rest as a completely planned and polished effort... as a possibility. 

Sources:

1. ALLAR, M. (2016) Github - UE4 Style Guide [Webpage] Github. Available from: https://github.com/Allar/ue4-style-guide [Accessed 21/10/16]

2. JAMES BRODERICK DESIGN (2016) Guiding Sprites - FMP Trailer [Online video] Available from: https://www.youtube.com/watch?v=Cy_ud2AIDUw [Accessed 21/10/16]