What I learned about game development while making Cauliflower Knight

For as long as I can remember, I have wanted to make video games. Before I even knew how they were made or what a computer was I had an overwhelming desire to pursue it as a medium. My dream was to be able to have the creative freedom to work on a game of my own design, so you can imagine my excitement to hear that my final project at university would be developing a game in its entirety within a small team. Throughout my first two years studying game design at university I had prioritised working on my hard skills that are involved in game development. These include level design, learning how to use game engines, 3D modeling, texturing, rigging, animating and so on. This led to the bombshell of a realisation that I had been completely neglecting to develop the skills that turned out to be the most important to a game designer of my position, the soft skills of working within a small team.

Image 1: Screenshot of Cauliflower Knight gameplay

When working in a team of three to develop our game, Cauliflower Knight, it became clear very quickly that I was in over my head with my responsibilities. As the one who pitched the game concept in the first place, the rest of the team naturally came to me for guidance on every aspect of planning and development. I felt as though I knew what I was doing when working on the game as a prototype solo, but the moment I had to communicate with others on what the game should be I consistently stumbled. Thankfully my team was patient enough to stick by me and give me time to get my act together and we eventually got to the position now where we have a strong vertical slice of our intended outcome.

For those of you who may find yourself in the position of game director or game design lead, here are 3 essential soft skills you NEED to have honed before even considering such a position on a team.

Planning

You can improvise a game, but there are practically no circumstances where the end product would not have benefited from extensive planning ahead. You will make a more cohesive, balanced end experience for your players in an exponentially faster time. Reworking, improvising and scrapping aspects of a game are an inevitable part of game development however strong planning documents will cut these tasks tenfold in the long run and save vital resources.

Image 2: Level layout plan included in content plan
Communication

Without communication there is no plan and there is no team. Crazy thing is, teammates are not mind readers and they are not obligated to fish information out of you themselves. You should be making every effort to communicate the entire picture of every possible aspect of what is needed of them and when it is needed from them. I try my best to give the artist of the team creative freedom but that means that I specify what aspects are up to them, and I provide a suggested outcome if they do not want any creative decisions for that particular aspect of the game. What you DON’T do is tell your team to “make level assets” with no direction or specifications.

Image 3: Specifications for in-game asset with intentions to be passed over to the 3D artist.

Image 4: Feature spec graph detailing physics of character movement in-water, to be passed on to the programmer.
Organisation

So you have a plan and a team on the same page. What now? Set tasks and deadlines for each team member. You must do your best to be aware of where each team member is at with their work, and alter the pace of the plan accordingly. If certain tasks are taking too long you must take the initiative to alter the route of current development in order to meet development goals such as getting a portion of the game ready for public testing or having to cut portions of the game in order to polish the overall experience. Things WILL go wrong, so you must be able to reorganise the team on the fly.

Final notes on how to work well within a team.

It has become abundantly apparent that for someone in my position, it aids the project immensely if the director has a basic grasp of all aspects of development. My strong understanding of 3D modeling and animation has allowed me to both communicate detail and functionality of assets as well as plan what is graphically viable for our project within our time frame. This knowledge also allows me to assist with development with these assets when needed, or tweak animations to meet required gameplay specifications for collision events to trigger at correct times. I however was not able to be on the same wavelength as the programmer of the team as my coding skills are little to none. This both made understanding what was possible in the time frame difficult for me to grasp, but also communicating specific terms almost became a language barrier at some points. Thankfully they powered through my ignorance and understood my crude graphs and feature specifications despite my non-technical language.

Beyond the team, here’s my advice on other development aspects.

Starting your game

Get feedback early on and lots of it. I’ve developed games in full only to realise they aren’t fun. Thankfully with Cauliflower Knight, I had made a low-fidelity prototype before taking it on as a Uni project which allowed me to get feedback from outsiders and fix big issues early on, which there were MANY.

If you can get your game to be fun and engaging, you should then get to work on creating a small slice of the game to the level of polish you intend with a full release (or close to it). I’ve come to learn this is the best approach as the average play-tester will only need to play for 10 minutes in order to provide meaningful feedback. We as a team initially planned on making a “skeleton” of the entire game first, then adding the meat afterwards however the more content your game has, the more you have to fix when you make changes, and the game will be less engaging for play-testers who will obviously not have access to the final vision which is still months down the line in development. Not only that but having a small complete portion of your game makes it presentable for early marketing, and provides a safety net for minimum viable product as cut content will have had no time wasted on it.

Taking feedback

Listen carefully to all feedback, but only act on it if those giving it understand the games INTENDED experience. Acting on feedback for a FPS game that will aid it in being a turn-based strategy will simply morph it into a bad turn-based strategy game.

Conclusion

Not everyone will be as lucky as I to have teammates like mine, but you can ALWAYS improve yourself, especially at skills and practices you may not even be aware of in the first place. Communicate at every turn while in a team and working with play-testers. Trust your gut once it has been critically analysed and articulated. Good luck to us all making games. It will never be easy, but that's what makes it rewarding.