The project experience
For this assignment, we were tasked in formulating our own teams and from within those teams, conceptualizing and creating a game based around the keyword ‘resist.’ To begin with, after we had formed our group consisting of four people, we began the process of delegating roles to each person – based off those persons considered strengths and weaknesses. We split the roles into groups as follows: art and environment design, coding, functionality and sound design. Since our group was small, members like me or Rebecca would take on extra roles when and if required.
Now we had a team, we would brainstorm ideas surrounding the keyword and from those ideas, we would begin to brainstorm game genres and mechanics that might fit into this web of concepts. We would also consider how we were a small group and the more complex we make this the more work, organisation and learning would be required. We settled on three ideas and ranked them (as we saw them) from easiest to make, to the most difficult.
We then set to work creating game pitches for the upcoming presentation, so we delegated one game per week to be partially made for the presentation, starting with the easiest. Rebecca and I would make the concept art, design the environments, and build the aesthetics, Ollie would add the code and functionality to the test projects, while Kyle would create the sounds. By the last week we had settled already on taking forward the third prototype as our final, as we had discovered during its conception and design phase that this idea made us laugh the most; it brought us the most satisfaction and we knew from building it that we would have a fun and enthusiastic time in its creation.
Because we now knew which game we would be creating early on, we began creating a list of assets, sounds, levels, mechanics and functionality we would require for this game to go forward to a realistically finished state. We also considered how this game was the most demanding, design wise, and would require lots of work and research to complete, however the enthusiasm for it out-weighed the worry of over-estimating our ability.
The presentation was created over the weeks while we created the prototypes, we found this way we could fill in each portion as we went, while leaving a space at the end for the chosen design. As we were now ahead of our planned schedule, we took this extra time to begin creating extra assets and begin planning a schedule for creating the final game.
We split down into weeks and within our chosen fields, each additionally added to the project as time progressed, building level by level, laying down the core mechanics as and when they were needed. We also remained in constant communication over Discord and routinely fed back to one another and guided one another when needed.
Despite our planning and meticulous scheduling, certain members of the team quickly dropped behind and eventually disappeared altogether, leaving only myself and one other member to create the game. It was additionally challenging that the fact that neither Rebecca and I had much coding experience and had to study and work incredibly hard to maintain the schedule and keep the game on track.
Despite these facts, one other member would re-appear at the end of the project to help finalise the project. However by this point, Rebecca and I had created and implemented much of the game and due to setbacks, the game had to be scaled down and a lot of its functionality cut away. The game was not significantly different, however we understood it diverted from the original pitch.
I had taken away a lot from the project by the end and had a clearer understanding of concepting and scheduling of workloads. I have also learned a lot more about unreal blueprinting and the work required to bring a game to full scale. I had created levels, blueprints, textures, game modes, concepted artwork, sculpted a character and had it added to the game. Overall, I explored a wide range of mediums and came away with a lot more understanding of game design.
Project Reflection
On reflection, I took away a lot of knowledge and in many ways, altered my perspective to how group work can be approached. I quickly learnt that even with strict planning and the careful selection of team members, still cannot offset unforeseen circumstances and the need to adapt and take on more work than you initially believed you would be given. It can be frustrating but, in a way, these circumstances can pressure you to be more hands on and enthusiastic about acquiring further knowledge to complete the project. At the beginning of the project, I believed my strengths to be only artistic in nature, however, I was quickly forced to learn more about unreal blueprinting, adapt to the new workload and meet the deadlines.
I especically found myself after having no choice but to learn more about blueprinting that the process can be fun and rewarding, while also giving fundamental game design knowledge in the meantime, as knowing how a game ‘ticks’ is valuable in other areas of the industry.
I also found being confident in your presentation and the concept you are presenting, is a huge asset to delivering an exciting and engaging pitch. By having faith in the project and really enjoying the concept you are pitching it helps make the spoken portion of pitching easier, while making the presentation fun for the presenter and the audience. It was apparent during the presentation that the members who felt strongly about the project where less anxious and enjoyed giving the pitch more.
I would also state that I learned to keep focused on achievability, rather than what sounds like the most fun to create. Knowing your teams’ strengths and the skill level of each person can really help to decide which project is more realistically achievable. The funniest game is not always the easiest to create. We found that although our final game was fun to create, it was more than a challenge and we did state we wished we had chosen the second, more straightforward concept. I also still believe that team creation by strengths is, in my opinion, still the best method of furthering a smooth project through participation and enthusiasm.
Moving forward
In future collaborative projects, I believe I will take more due care in the selection process of concepts and the teams’ workload and commitments. I believe for such a small team we inundated ourselves early with high workloads and some, where not up to the pressure. I believe that in future it would be prudent to select individuals in their strengths and space out the workloads more to ease the burden if the group is small, altering the approach according to the project’s parameters and constraints.
Even though the team communicated incredibly well, more video conferences are necessary in any future collaborations as they communicate problems, bugs, and feedback more effectively than text can. During a certain stage, our group discovered a very confusing bug and could not discover its source. However, once we were sharing screens and communicating vocally, we quickly diagnosed the problem, iterating how effective a video call can be.
Our team also discovered that even though we enjoyed creating our concept, it was incredibly difficult and ended up being different to how we initially had designed it. This was due to encountering skill-based problems and not having the tutorials relevant to exactly what we needed. In future projects, I would plan accordingly, thinking about skill level and achievability rather than what inspires the most fun, thinking about the required mechanics and how easy they are to create and implement.
Still speaking on behalf of achievability, I would consider splitting tasks more effectively, mainly coding and/or blueprinting to ease the burden on team members. I would believe that in future collaborations I would instead take on some blueprinting role early in the project now that I am confident at learning more about the process if necessary. I would also encourage others to consider this as we found you cannot really have enough team members undertaking this job.
I would also consider in future the purchase of more tutorials and assets packs relevant to the project, If, like our group was, the group is small and there is not a lot of labour, asset packs and paid tutorials can be a great resource in speeding up the progress of the game. We found that just one paid pack sped up the creation of our game massively while also providing knowledge, as the blueprints within these packs can be dissected and studied to find out exactly how that asset works.
Effectively, I have taken away that although a project can be planned well and executed well, it can still go wrong, and one must adapt and work through the obstacles and that can be rewarding even if it is still, an inconvenience.