3rd Project: "Beat the Bell”
Introduction
Our 3rd project for the first year saw us grouping into teams of Ten. Our team comprised of two producers (myself and one other), one designer, two artists and five coders. This dynamic lead to several challenges, cons and benefits. We were presented with a selection of game briefs, put together by the second years. Our group settled on a pitch called “Don’t Miss the Bell”.
The Concept
The pitch for Don’t Miss the Bell (which I started referring to as Beat the Bell because the alliteration felt like it rolled off the tongue better) was for a first person parkour street runner. You play as a rebellious teen who has a bad habit of being late to school. Now they are on our last straw and the school Principal is going to expel your character if they are late even once this month.
In the brief we were provided with a framework of movements and controls that the clients wanted to be included, an art style, game features and formats.
Movements and controls:
Basic 3d First Person movement (WASD and mouse).
For quite some time our team worked under the idea of having our game be in third person (for reasons that I will expand on later), it wasn’t until visiting our brief again that I realised we should include a first person mode so that we more accurately represent our brief.
Slide under tight spaces (Hold control).
We went a little further and had our control button place the character in a crouch when pressed, and have our character slide when held.
Vault over high obstacles (space).
This requirement lead to a long discussion as to how this would work. Would this be more like a climbing mechanic, where the space button makes our characters climb up and over obstacles? Is this “vaulting for speedily hurdling over obstacles as we run? To begin with we opted for the latter, where our character would only vault/hurdle so long as they were sprinting, but we noticed that there were certain obstacles that were too high to vault over (thematically) in this way, but were also too short that it wouldn’t make sense that the character couldn’t climb over the obstacle. Due to this window we decided to make our vaulting work a bit more like the slide mechanic, where if we are sprinting use of the vault button has a different effect to if we are moving normally or standing still.
DASH LEFT AND RIGHT TO AVOID ONCOMING TRAFFIC (Q AND E)
Art Style:
Low poly (Low spec requirements).
Quicker development than high detailed models.
Similar to a game called “Hello Neighbour”.
Unfortunately the art side of the project is the side that was most challenging. With two non vocal artists it was constantly hard to pin down exactly where we were at with our art at any given time. I will expand on this later.
Obviously our first port of call for art style was to check out the recommended game as influence for our own art style. After seeing the low poly models we felt that this was a very achievable art style in the time we were given. Simple models meant that we would hopefully be able to churn out more character and assets. We had the possibility of multiple player characters, and numerous npcs. Other sources of inspiration were the games “Jet Set Radio” and “Knockout City”, the kids cartoon show “Codename: Kids Next Door” and the art style of “The Gorillaz” band. With two artists we set one to environment design and one to character. Both artists were happy with this setup as they said it played to their strengths.
Game Features and Format:
Levels
Difficulty starts easy and gradually increases.
31 levels for 31 days of the month.
This was a worry throughout the project. 31 levels seemed like a steep ask in the time that we had to make the game. However, we were imagining complex and intricate AAA type levels. To meet the briefs requirement of 31 levels we could make simple designs and possibly reskin levels with seasonal skins and different obstacles to streamline the level development process.
Each level has a countdown for the bell. You must reach the school before it reaches 0.
This was a very simple element that we wanted to elaborate upon and make more unique or interesting in certain level designs. One of the earlier concepts for this was to have “race levels” where the player races an NPC to the school. Effectively you are still racing a timer, but this one is a visual timer in the form of a competitor on a track.
Items and pickups
Energy drink (brief speed boost).
Boots.
In the brief, this power up was never explained as to what it would do. We interpreted it as a jumping power up, that would allow our character to jump higher.
Crash helmet/body armour (grants a second chance after getting hit by traffic).
Random bikes, skateboards etc. as mountable objects that provide a change in
Near miss mechanics
Dash as close to an obstacle as possible to fill an adrenaline meter.
Once the adrenaline meter is full you may use a temporary boost of speed.
Environmental Obstacles
Parked cars.
Crowds of people.
Traffic (oncoming cars).
Train crossings (player can use by hopping across the tops of passing trains).
My Contribution and The Journey
Unlike the first two projects we didn’t have the problem of deciding what to make within a specific game genre, which should have saved us some development time. However the time we would have saved was instead spent interpreting aspects of the brief and also convincing team members of creative ideas/directions. Our one designer put together a very bare design document from our discussions, and myself and the other producer took on larger designer roles within the project due to our designer unfortunately not having much input.
In my production role I set up much of the framework that allowed our team to work and communicate as well as track what tasks had been completed. I had initially set up a Jira board, however there was a team wide preference towards Trello which my lead coder then, a shared google drive and even a page for the project on itch.io, the website that we posted our game files to for the previous two game-jam projects. I had made a slight error with our itch.io submission on the last game jam project which I did not want to repeat, unfortunately this page did not get used however, as the submission was different for this project. Lastly I set up a discord server with a variety of channels to discuss our ideas and post topic related questions, such as:
Art
Tech
Design Ideas
Music and SFX etc.
One channel that I set up and we did not end up using was and “Availability” channel. Our course was structured in a way that we consistently had a timetabled slot for groupwork every Monday, however I intended to use the “Availability” channel to get my teams availability at other times in an attempt to work out a schedule for meeting up and working together more than once a week, as I felt we may get more work towards the project done this way. Unfortunately this was not received wel by the team as a whole, who wanted to communicate more via discord and work individually on their home PCs.
Early discussions saw one of our five coders asked if we would be having a lead coder, an idea I had thought of. Seeing as he was forward thinking enough to ask this question I felt he nominated himself quite well for the role. This ended up working out quite well in the role as he was very direct in communicating and asking the other coders questions, as well as just being a good coder so he was able to go over the code developed by our other coders and make minor fixes and changes where necessary. He was also good bridge between myself and the rest of the coders, operating as a producer-lite for the coding side of the project. I was able to ask him broadly how specific things work, where they are in development or whether we can change things to get a more desired effect, which gave me a better understanding of specific pieces of code before having to the individual coders. He also set up our source control through GitHub, which he was well versed in, and I did not yet have an understanding of. Several times throughout the project I was able to come to him with questions on how specific parts of source control/GitHub work so that I was prepared for questions from other members of the team.
Pre Production
Early stages of the conceptualisation of the game saw myself and the other producer taking on larger designing roles. On my part, this was partially because I felt like there wasn’t much for me to do yet within my producing role, but was also due to our designer not being very active in his role. On reflection I wonder whether this was the correct move for the project, and whether I should have encouraged our designer to be more active (I will expand more on my interactions with the designer and how I tried to encourage and help him within his role further on within my dev diary). Having the myself and the other producer designing lead to some discourse on a few design ideas that could not be mutually exclusive:
The first was how to tackle the 31 levels. The other producer wanted to develop 31 individual levels. I had the idea that we could approach it as an open world build, with 31 routes within the level, which would crisscross at set intersections and would have portions of the map dynamically closed off depending on what day we are running to school. This would also lend itself to having different starting locations, such as a friends house from a sleepover the night before or having got lost on a field trip and missing the bus back to the school.
As there was only 2 of us approaching this aspect of the game design (myself and the other producer) we were at odds without a 3rd deciding vote, so I decided to put it to a vote with the rest of the group. The vote was 7-1 for the open world and we moved on. Eventually I was better able to explain and describe this idea to the other producer who got behind the idea. This was a design aspect that we later had to go back (I will expand and this more in the “Visit from Rebellion” section).
The second conflict was on level design. I put together a design document outlining story beats and how a tutorial level could introduce players to the movement controls, abilities and pickups (seen to the right). Part of my motivation for setting the tutorial level within the school was that I saw the school as a reusable location with reusable assets. As well as a tutorial level set in a place that we would be developing anyway, it would help to bump up our number of playable levels. I also felt that the gym class setting that I proposed just fit really nicely contextually within the setting of the game.
I developed the proposed levels with the idea of introducing mechanics to the player incrementally. The Tutorial level Part 1would show our player the basics of movement, Part 2 character abilities, and Part 3 would introduce the “Timer”/ the idea that the player has to get somewhere before the time runs out. Level 2 would put the player in the city for the first time and they would learn that things in the city are always moving (i.e. a section that is accessible in this level may be blocked off in the next) and that crowds are an obstacle. Level 3 would introduce the idea that the player has to get A to B via C in the form of a side objective/collectable item that is required to progress. Later levels would then introduce race levels, where the player must race an NPC (functionally this is still a timer, but more immersive), different staring locations, or even mount levels where the player can use a skateboard or bike to traverse specially designed sections. Throughout my design document references to a “Dating Sim?” can be found, as early ideas had the team joking around with including a dating sim as a gimmick to the game. Their inclusion in this document was mostly to maintain the half-joke at the time.
As the other producer was at odds with my ideas I suggested they make their own design document with alternative suggestions, and that as a group we could go through the two and see what we wanted ideally from both concepts. Counter to my design ideas, their concept had no specific tutorial area, more of a starting ally way that simple encourage the player to work the controls out, before opening up onto the rest of the level 1 map. They would then immediately be given a side quest, of chasing down a thug who just robbed the characters parents, to learn how certain movement mechanics could help build up speed or certain abilities (such as the athletes charge or the musicians dash) could be used knock NPCs over. He also proposed the alternative of having a side quest rather than a chase. After this their level designs function similar to mine; introducing different level frameworks such as race or chase (where the player chases an NPC) levels, police chase levels (where the NPC police chases the player and triggers a lose state if they catch the player), a night time level, and a “Collectathon” where the player would have to collect multiple items, which was similar to a level concept I proposed where the player would have to get school supplies.
Once again at odds and with no 3rd voice (ideally the designer) to take us in one direction or the other I put another poll up to see which way the majority of the team wanted to go, particularly with the tutorial level, as later levels could be used or combined without conflicting with one another. At this point the team was a little bored with the conflicting directions and either couldn’t settle on what they wanted or couldn’t be bothered with the slight discourse. The poll did not get much response, and discussions showed a pretty even split between building the game as outlined in my document vs building the game as outlined in my fellow producers document. In this area we were just not progressing, and I also realise the scale of development required for some sections of my design was unrealistic for the timeframe we had to develop the game, so I conceded and suggested we start small, and throw in ideas from my document where we can.
Hello Neighbour
Upon reflection I think I should have pushed my concept for the design more. It had really strong elements, particularly the Tutorial level, and the way I deliberately designed it to incrementally introduce gameplay elements to the character (I believe) would have lead to frustrating and accessible gameplay. However, also upon reflection I can immediately see scope-creep. Level design ideas such as a Train level, and nightmare levels would have required us to develop counter to our open world development idea, by forcing us to also develop these closed off/individual levels.
Knockout City
As stated previously, pre-production also had us settling on art style. We immediately checked out the recommended game “Hello Neighbour” as well as the games “Jet Set Radio” and “Knockout City”, the kids cartoon show “Codename: Kids Next Door” and the art style of “The Gorillaz” band. The majority of these influences were centred around the character art, where we focused in on the low-poly style and also outlined interest in cell shaded characters (the influence of which came directly from Jet Set Radio). Having outlined the visual influences for our character art we set out to develop a selection of playable characters to choose from, as well as a selection of NPCs and some teachers from the school. The 4 characters we settled on, and that I conceptualised, were drawn for school kid stereotypes:
Jet Set Radio
The Jock/Athlete
The Band Kid
The Goth/Emo
And the Stoner.
With our character artist set up with the task of creating concept art for the characters we then had to look at our environmental art and setting. We knew that we would be revisiting the school so we would want need school type assets (chairs desks lockers etc). We would also want to have a bunch of re-usable assets for the city (vehicles, lamp posts, buildings etc. As other teams were working on this parkour game concept, I wanted our setting to stand out from the others, and we settled on the game being set in a Japan/Tokyo inspired environment. This would later help with my own level design when I designed the school based roughly on already existing Japanese schools and schools from anime set in Japan.
Reflection on the pre-production stage
Looking back on the pre-production stage I definitely feel that I should have encouraged the team to do things a different way. I think we spent a little too long in pre production, partly due to conflicting ideas and indecisiveness, partly due to lack of input from some team members but also due to the fact that myself and the other producer hadn’t outlined a deadline for the pre-production stage. Although this didn’t effect the coders, who mostly got straight to work on the most essential (and already outlined) mechanics, the project sorely lacked strong ideological foundations in what directions it needed to go, which I believe had an effect in its production all the way to the end of the project.
Production and Prototyping
Art
Production had already begun for our coders, who were hard at work with many aspects of the game code ranging from player movement to menus and widgets to cell shading. However I will start by discussing the production experience with our artists. Concept art started lukewarm with in general. Our Character artist had provided some really nice concept art for a couple of characters but was relatively unresponsive on discord regarding more work for a long time, and would not be present to many of our scheduled meetings. when they were they would say that they had more art but no means of showing it. Ultimately our character artist did produce more models and art work for us, and had even custom animated each of the four player character models. The models and animation were vary strong and impressive. Unfortunately he provided them without enough time to actually implement them into the game.
The Environmental art was a very similar story where our environmental artist produced some concept art but was also relatively unresponsive on discord and would also not be present to many of our scheduled meetings. and also when they were they would say that they had more art but couldn’t show it.
With the deadline closely approaching and method of getting our artists to submit work I put out a message regarding the project and peer reviews (which would ultimately affect peoples grades) and suggested that team members give an accurate score towards all other team members (i.e. score people low if they’ve not provided any work, likewise please give people who have worked hard a good score). Within the last few weeks of game development we received some assets from our environment artist. Some were in keeping with the low poly art aesthetic however some had suspiciously high poly counts, which my co producer caught and discussed with out artist. it turned out that these items had been downloaded from the internet. By this point the project did have external assets which I had sourced and kept a reference sheet of, as they were placeholders in the hopes that our artist would ultimately provide assets to replace these items. These items stayed in the game, which was submitted with references to where each item came from.
In the end I implemented and textured only a handful of our artists assets within the game. I had already set up many textures within the game using Unreal Engines Quixel content, so texturing was not a problem, however the files provided were only blender files, not the .fxb files requested, so I had to export them myself. I am quite grateful for this as it forced me to learn a little bit about fusing assets and exporting assets within blender, as we had only been learning our 3d modelling within 3ds max in our 3d modelling module. I am also rather grateful that I had to learn how texturing works within Unreal Engine, which is another skill I will take with me from this experience.
Ultimately our art held this project back from being a strong finished game. I am unsure as to what I could have done further to get better interactions from our artists. Quite often we would hear that they were working on other modules, which to be honest I completely understand. My own individual module work at times either took precedent over my group work, or fell by the wayside in comparison to my groupwork. Again, it may be possible that stricter deadlines for specific itemised assets, rather than for example a collection of school assets or a collection of building assets, could have improved the input from our artists. It’s an interesting issue that I find very specific to university/educational institutions, in that you can’t just fire an unproductive team member, and rehire someone who will produce work. Likewise because there is no inherent risk in not producing work (possibly because the work of others has the potential to allow you to pass) this behaviour is understandably quite common.
Visit from Rebellion and how it influenced Design
Design saw a similar issue. Early on in deciding roles our designer approached me unsure of what to do towards the project. as well as maintaining the design document, I requested that he start white boxing out level designs, with coloured boxes to indicate where specific actions should be happening (i.e. blue boxes should be for wall running, red for sliding underneath etc). To help with this I provided links to videos that cover level design concepts. I also suggested that myself and the other producer could make the starting area (Player character home) and finishing area (school) to alleviate the pressure of designing levels for the designer. When I suggested building these levels individually I was under the assumption that we would ultimately find a way to merge the items and assets into one big map for our open world concept.
Luckily the visit from the guys from Rebellion lead to a discussion in which they suggested an open world may not be the best development choice for us. which meant that we didn’t need to find a way to merge the maps, and lead to us having a semi open world concept, where the player character starts in their hub-world (made by the other producer) load into “route maps” and from their load in to the school map that I had been working on. They also spoke a bit about how Inverse Kinematics could help with our wall running and sliding animations, but at this point we definitely had no character models to apply it to, so I simply kept a note of inverse kinematics for when the character models were in the game.
In the end our designer was similar to our two artists in that they consistently did not have work to show, and in the end only produced two white boxed levels.
Design is where I feel I did the majority of my work. Firstly I wanted to be in keeping with the Japan/Tokyo imagery that we had settled on so I quickly found images that I could use as a mode board for the design. I designed and built the school level with some core design principals in mind. Firstly I new this was a location that we would be returning to, and so I wanted to add variety and flavour to the end of each level. I designed the school to be traversed through, the concept being that you would end the level in specific class rooms. I also designed the school to have multiple interesting entrances; through the gym, kitchen, cafeteria, lobby, basement (for a sewer/subway level) or playing field. I then subsequently designed the surrounding area to also have multiple approaches, mostly in the form of alleyways but also from an overhead tramline and other roads, which would all act as loading in locations. I also wanted to ensure that the player would make it to the correct class room by putting necessary blockages within corridors or by having certain doors locked/unlocked which I did by creating an asset with an instance editable locked/unlocked Boolean.
When I initially white boxed the level I did it without the forethought of having to replace the boxes with actual assets. This lead to me having to rebuild the school when it came to texturing and fleshing out the level. From within this level space I learned how to make materials and texture assets, how to make roads and pavements by using splines, and I animated opening and closing doors based on collision boxes and using timelines. I also Implemented some of the code that our coders had developed, such as our wondering NPCs or cars that drive around the map. I also edited the code that had been developed for our car actor to randomise it’s mesh and colour upon construction, using the car assets that our environmental artist had provided. The last thing I did whilst working in this level was to try and implement some sound into the game. I sourced some free audio assets from Zapsplat.com and created some sound cues with them which I hooked up to the collision event of many of the pickups.
Code
Code was by far the strongest part of our project, with four of the five coders being extremely active towards the group project. My experience with the coders was essentially asking for something to be made and then that thing got made. This side of the project is where I felt the most producer-y, most likely because there was communication, discussion and engagement from the coding team. So long as I communicated with the coders what tasks they had been set, and assigned things correctly on the Trello board, it all went relatively smoothly.
Occasionally I would present a YouTube tutorial for specific functions that we wanted or needed, such as a tutorial on chaos destruction for our destructible walls that the athlete could run through, tutorials on parkour sliding, vaulting, wall running and even using the Navigation mesh for NPC movement.
The strangest complication I experienced in managing my coding team was that my lead coder was too good. He would finish his code and then move on to someone else’s assignments, either overhauling them or building an entirely new set of code. This left me conflicted. Overall we were getting a better game from his efforts but it was starting to irritate the rest of the other active coders. In the end this lead me to assigning the tasks that I thought might be the most difficult or longest to our lead coder, at the same time I had a conversation with him asking him to only edit other peoples code after they are done with it and after a discussion has been had with them, also where possible doing it with them as a sort of teaching/learning moment. After this discussion I did not encounter this issue any further.
Reflection
It has been difficult for me to reflect on this project. Ultimately it has been a project that unfortunately I am not proud to have been a part of, however I am proud of my part within it. For any player who can get to the school level of the game, they should hopefully see that a lot of work went into make an immersive and interesting level, which was ready to receive more assets, and would have had many places for scripted events.
It is a shame that our finished product was in a state that had no story beats or meaningful gameplay. Yes, we had a couple of levels in which the player had to beat a timer to get to the school, but it was lacking character models, animations or even levels that made it past the white boxing stage. We released something that clearly looks un developed and un-loved.
The development process often times felt like we were in a waterfall model, waiting for one thing before moving on to the next. If I could have a crack at developing this game again I would have ensured that evidence of white boxing levels had started sooner, as well as developing an in detailed plan for scrum sprints as guidelines to follow whilst being stricter with deadlines.