2nd Project: "Astral Pirates”
Introduction
I entered this project with excitement. It was to be what I considered my first complex game. My team was (including myself) a team of six, and our brief was to develop a fighting game within 4 weeks. Much like our previous project, we were told that we could use whatever software we wanted to develop this game, but no specific engine was recommended this time.
The Concept
The first week had our group discus what type of fighting game we would like to develop. Although the genre fighting game brings to mind very clear images of traditional 2d fighting games, usually with two players fighting one another (such as Mortal Combat), although sometimes as arena battles with multiple players or bots(such as Super Smash Bros). I initially wanted to bring a concept to the team that was more of an arena battle, in which player character utilized musical instruments to for their attacks. Certain types of instrument could then fill the roles of certain character archetypes found in fighting games. I.e characters with Percussion, Wind, String and Electric instruments would fill the roles of Grappler, Rushdown Zoner or Shoto (all rounder) characters. It would be simple to implement the core ideas found present in these types of fighting game: 3 or 4 move sets, combo attacks and most importantly an ultimate move, which in this case would be used through playing their chosen instrument. Unfortunately this concept was not picked up by the team, but I am very happy with the concept that we settled on.
During my discussions with the team we settled on a more campaign based game, Ala Streets of Rage, where the player works their way through levels to reach the Boss, fighting against enemy bots of varying ability along the way. We sited Binding of Issac and, more importantly, the original Street Fighter and Monkey Island games as inspiration for our art style. We decided that we wanted to place our character sprites into a cartoon 3d space, to allow for forwards and backwards movement, as well as more interesting map traversal. It was for this reason, and the fact that we are learning Unreal Engine 5’s blueprints for programming, that we decided to make our game in Unreal Engine (after a vote).
Finally for the setting we settled on Pirates in Space. We obviously drew inspiration from Disney’s Treasure Planet, a childhood favorite of some of our team (including myself). I had suggested that if we need to pull assets from the Unreal Engine Market Place, having two stylistic themes (Space and Pirate) could afford us more options to look at.
The Journey
Unfortunately, much like the first project, a major snag in the production was being able to communicate with my team, to get them face to face, to map out what needs to be done for our project to come to fruition and to set deadlines that were actually met. Our concepting phase took almost a full week (a quarter of our development time) mainly because I couldn’t get the whole team together at once to settle on an idea. Ultimately myself and two others of my team (who I was able to consistently meet with) developed the Space Pirates idea and most of the other core concepts for the game on the Thursday of the first week. We brought our ideas to the rest of the team via Discord and the team decided that since we had almost burned a whole week of our time already that this is what we should develop.
At that Thursday meeting we settled on:
The Space Pirate theme.
The Streets of Rage inspired side scroller, in which we would be fighting the AI not each other.
A simple story board to introduce our game.
A simple story board for level progression, as well as boss and enemy placement and weapon placement and implementation.
The pixelated art style for our characters/sprites.
Our Health and combat system, and what would have been our fun “drunk system”.
The Space Pirate theme, inspired by Disney’s treasure planet was a very fun setting idea that the entire team could visualize very easily. I presented the idea to the discord chat as “a space ship which would look similar in design to old maritime naval ships, but with spacey things on them like jets and those kind of golden solar panel things that satellites have for sails.” One of my team suggested designing the cross section of our ship with the Mary Rose in mind, and even visited the local historic ship to get take some reference pictures as inspiration. We also obviously looked at our initial inspiration, Treasure Planet, and what made the ship designs in that film iconic. Lastly I also suggested looking at the Ulysses 2 from Disney’s Atlantis, which had steampunk themes that I though would fit in with the style that we were trying to settle on (particularly the windows).
Although we were initially inspired by these Disney films, I felt it was really important to distance ourselves from them in design, to design something that stands apart and most importantly to design a setting in which there would be no copyright issues. I suggested that “we also need to distance ourselves a little from the Disney Treasure planet model. Just to be careful.” and had some suggestions with how we could do that. I suggested that “the ship deck could have some sort of greenhouse type dome to it. A bit like the Eden Project.” But with a more rustic/steampunky aesthetic, like the submarines from Disney's Atlantis. With thick metal beams holding the glass panels in place in a long dome shape.”. I came up with a very rough concept (pictured below) minus the glass dome. And one of my Designers said he would be happy to work of a design for the ship. He understood the brief and set out to “basically do something like HMS Warrior or HMS Victory with golden sails, large engines, maybe wings/winglets and other scifi”.
We had all of us yet to meet up together as a full group, so I hadn’t been able to discuss what tasks where needed, or work out my teams skill sets to assign said tasks. I had spoken to one of my coders, who was looking into how to implement a side scrolling camera to to the 3rd Person build Unreal Engine 5. I also knew that my Artist was working on character concepts, and my designer was working on the exterior ship design.
With the ship design underway I quickly had a look at interior level design and some simple story boarding to present to the group (pictured bellow), my designer also made a basic layout for the ship levels (pictured right).
The original Story concept had our player character as the Captain of the ship, fighting down into the belly of the ship against invading pirates, who had crashed a small pod into the bottom of the ship. we changed this idea early on to have our player character be a Pirate themselves, invading another pirate ship to claim it for their own. This decision was made for a few reasons. The use of a small invading pod didn’t align with the number of enemies the player would encounter. Also the idea was to have the enemies get harder as they got closer to the pod, with the Boss pirate being right outside of or inside the pod. This just didn’t thematically work for us, as we imagined the boss as a character who would most likely lead the charge. (Also, where the hell was the rest of our crew?). When we flipped the idea so that we were the invading force the level design made more sense. By working up the ship through the grunts to the more important characters on the ship, like the 1st Mate or Captain, it would make sense that these enemies were getting harder, as they were better trained.
I split the ship into 3 distinct levels:
The 1st level would be simple game play, introducing simple combat mechanics, and the idea that although the player is traversing from right to left (or left to right) they would also need to travel forwards and backwards or even up and down levels to bypass obstacles, for more interesting map traversal. The player would end this level simply by going up some stairs.
For the 2nd level I had the idea of introducing simple tools for the player to interact with the map, such as a wrench to break blockages in the map. The idea was that the player would possibly miss the tool initially, meet a blockage further along the level, and have to backtrack to find the tool. The player would end this level in a more interesting way, by leaving through a porthole and climbing up some rope or chain to the bowsprit, which would be the start of level 3.
For the 3rd level we would have the player utilize all of the lessons they had learned in the previous levels. They would have to leave the Bowsprit via climbing a rope to get to the to deck-proper. They would have to travel to the middle of the map only to notice another barricade, and travel backwards to find the tool needed to get past (in this case it would have been a spacesuit). They would have had to climb over the barricade in the spacesuit by going up the mast (and possibly have a fight on one of the beams of the mast). The next stages would have had a fair amount of map traversal and tool use to finally reach the final Boss. This last section, with the map traversal and tool use ultimately felt like more of a puzzle game than a fighter, so we decided against its complexity.
I finally got to meet all but one of my team on the Monday of the second week and we managed to discuss many more topics of the game, such as player and enemy move sets, enemy types, health systems and our fun idea for a “drunk system” which would tie into our health system. I also used this meeting as an opportunity to try a definitively hand out set tasks to our team members.
My current coder would carry on looking at how our player character moves and interacts with the world space and 1 axis fixed camera.
My 1st Developer would continue working on the world space and environment art/assets. He also suggested he could have a look at Menus and UI, which ultimately I assigned to the team member who hadn’t made it to the meeting and I still hadn’t met yet, although they had been partially active on discord.
My 2nd, I struggled to assign a task to at this point, mainly as I wasn’t familiar enough with the game development pipeline myself, also I wasn’t yet entirely sure what other tasks needed to be done yet and I had not yet been able to work out what his strength were, despite directly asking.
Finally my artist and I settled on working on the Sprite Sheets.
For us I sourced multiple sprite sheets and reference pictures to work from, and came up with many sheets myself. Our initial concept was to have two enemy types per level, and one mini boss per level, with a final boss at the end. Unfortunately I hadn’t realized how time consuming sprite sheets were to produce (although not technically difficult to produce). As a producer I should have paid closer attention to my Artist, as he had suggested that the number and variety of enemies we were suggesting would be difficult to implement in the time we had been given.
We entered consolidation week and I began work on the sprite sheets, which consumed my entire week. In our early concepts we had played with the idea of having a 2-player option, so while my artist worked on the player 1 sprite sheet I worked on a concept for player 2. Initially I tried to make a featureless sprite sheet, which I planned on using as an guide to draw over for later sprites (pictured above right). The further into doing this I got the more I realized it was a waste of our allocated time, and moved over to simply making the sprite sheets we would ultimately be using. I based my design on a previous character I had made in the past, using a programme called Hero Forge (pictured left).
Our initial plan included our character picking up different weapon types, such as shattered rum bottles, a gun and a sword, which meant that all of these “combat states” needed their own set of idle, walking, dodging, dashing, blocking and combat animations. It was a mountainous task, so much so that we cut the gun animations, and the 2nd level of the game, which involved gun game play.
I drew the sprite sheet with several mechanical ideas in mind. We had planned on our character being able to dodge and dash, as well as having combo attacks. None of this was implemented by the release of the game as we didn’t work out how to implement the mechanics in time. We did, however get our block function to work. The sprite sheet for the sword game play was also not implemented by the deadline either.
From a developmental point of view I would also like to stress my disappointment in my characters design. Whilst trying not to deviate from the Hero Forge design I gave the character a cream crop-top underneath her mustard jacket. Unfortunately the colour and tone of the crop-top were too similar to the skin tone, which gave the sprite the unfortunate appearance of being topless. This was absolutely not my intent, and I noticed this too far into development to implement a change. In the future, and given more time, I will spend a little more time checking the art assets to avoid issues like this.
Halfway through consolidation week I discovered that my artist had several issues happening at home, which meant they had been unable to do much work towards the art or sprites. At this point I was already realizing that sprite sheets are very time consuming, and with just myself currently working on them I felt the pressure to do more work to fill in where my artist was unable. In the rest of that week I finished off what would become the main/only player character, as well as three different enemy types.
The first two enemy types were drawn with two different attack types in mind, much like the player character, a main and an alt. This was due to the fact that they were bosses and I wanted their game play to be more interesting than the common grunts. The grunts had two different types of attacks as well, but they were meant to have the same effect, and just show variation in animation.
We reached our final week, the week after consolidation week, and I discovered that besides myself working on the sprite sheets, my coder working on the player character code, and my designer working on the ship, no one else on the team had used the week to work on the project. Another quarter of our allotted time had been unused. After wrangling my team on the Monday (and finally meeting the last member for the first time) I divvied out the left over tasks that still needed to be completed.
My 1st Developer would continue working on the world space and environment art/assets. He made a lovely exterior of the ship, but didn’t send over the assets, so we could only use a .png image file for our cover photo on our submission. He also made the 3d assets for level 1. We imported the files and swiftly discovered that the entire level (the room, the barrels and table and benches etc.) were one large 3d file that we couldn’t separate out into its components. We also had a clipping issue. The file was essentially a large cuboid with a cavity/corridor for the player to walk down. However Unreal interpreted the file as a single cuboid. When we placed the character in the corridor and pressed play they’d clip out of the cuboid either above or bellow. To fix this I turned the collision off on the asset and placed invisible boxes with collision in all of the necessary places, which worked well. Another issue with the corridor is that we had to apply textures to it, however as the corridor and all of the items inside it were one large asset, we could only apply one texture to it. We went with wood.
My 2nd Developer, I assigned converting our sprite sheets into animations. This is something I had already done with one of my sprite sheets. Unfortunately when my 2nd developer ported their animation files over to our master file they didn’t work, so I ultimately whizzed through and made the animations myself.
My 3rd Developer, whom I was meeting for the first time I asked to look at Menus and UI, as well as how to implement health and our Drunk system. He was unable to develop a drunk system in time but the menus were well made. Unfortunately he was unable to get the assets and files to us in time for us to implement them by the deadline.
My artist I asked to finish their main character sprite sheet, which we changed to be an enemy as their wasn’t enough drawn to fully animate all of the actions that we had our character doing.
Finally, my coder and I collectively worked on our enemy and player character AI.
Submission
We got a lot of work of this work done the day/evening before the submission date (Thursday) as I would not be available on the submission day (Friday) due to plans arranged before I started the University Course. I made a mistake that evening that I have definitely learned from.
So far throughout this course our games are to be submitted to “Game Jams” on Itch.io. It was encouraged at the beginning of this assignment to make a project page on itch.io, with a simple cover photo or description, and submit it to the Jam with no content, so that we don’t miss the close off date for submissions. I hadn’t done that yet so I set out to make a page, set the rest of my team up as admins so that they could add new files if they did further work on the game on Friday, and lastly submit the game page to the Jam. Late on Thursday night, feeling more than a little fatigued, we had to learn how to package our game, which I did after a little sleuthing. I submitted the correct zip files to the game page (and also uploaded what we had been working on to our google drive) and we wrapped up work that night.
The next day my team discord chat was exploding at midday. The game file was not working when my team went to try it out, the files added to the google drive didn’t work either… my uni account was the only one which had the master files. From Disneyland Paris I had to give my log in details to a couple of my team members, and they had to find the exact computer I was working on the night before to find the file to re-upload.
The second panic came in the evening, when they noticed that our game was not on the Jam page. They noticed this after the submission deadline. It seems that in my tired state I had made the game page but hadn’t submitted it to the Jam. From my spotty hotel wi-fi in Paris I reached out to our course lecturer and highlighted my mistake, and stated that I didn’t want my teammates punished for my mistake. My hope was that since the submission had only just closed that evening, he would be able to help. It seems that other teams similar issues as our lecturer extended the deadline to the end of the weekend, and we were able to submit.
This mistake taught me a few Lessons:
On day one, I should submit a game page to the Game Jam, whether it has files in it or not.
If I am not going to be available at important stages of the games development or submission then I need to make sure that the files are up to date, work for everyone else and are readily available to the rest of the team.
Reviews and Feedback
The following week saw us reviewing one another’s games. It also outlined to me that my team isn’t the only one that had it’s struggles. I was initially very worried about the state of our game, however in the process of developing the game I forgot to realise that this was really the first proper game that most of us had ever made. It was bound to be rough around the edges. Other games were in similar states to ours, some were not playable, and others had elements that I really admired and could learn from. I discovered that other producers also had a hard time of getting their teams together in on place or getting them to do and submit work. What I learned from that revelation is that it may be helpful for my sanity to check in with other producers during development time. It will be helpful to know that other producers are facing similar issues, or helpful to learn how they tackled similar issues.
There were several consistent issues within our game that were highlighted throughout its reviews:
1. The most frequent complaint was that our ship interior was entirely textured in 1 wooden texture. This was a very fair complaint and it is something that I think could have been avoided by our submission date with enough forethought and planning. Had I asked early on in the development for the custom made 3d assets to be kept in separate components then we could have built a more interesting and varied environment for the player.
2. Our enemy NPC was still having issues with it’s animation hierarchy, and would often play two animations on top of one another.
3. One complaint was “Exaggerated actions”, where the player characters kick animation was somehow pushing our enemy far away after being kicked. This was part of a larger problem in the code where we were trying to implement a damage system, based on collision spheres, which we were not able to implement. Which leads on to the next issue.
4. No Health. Neither the player character or the enemies had a health system in place. We had set up health variables but had not yet worked out a way for our blueprints to communicate and register that when a character hits another, that variable should decrease by a set amount.
5. The other smaller problems were that there was no music or sound, so it didn’t feel very atmospheric whilst playing, there was no control screen so players didn’t know what buttons did what, and there were no objectives. For the last point I feel like the game, as a side scroller with enemies in your path, didn’t necessarily need to highlight the objective of getting from one side to another. However, I would have loved to have implemented the story line that we had outlined at the beginning of the project.
Attempt #2
After our submission we had a lot still to work on:
The enemy AI logic was flawed, with breaks in the animation, no combat capabilities and only 1 enemy type actually in the game. (although the other enemy types were animated and set up, we just needed to copy the enemy logic across all of the characters and add some variance for more interesting gameplay). We needed to make our animations more seamless and include actual combat with animated hurt states for when the enemy takes a hit, and a destruction state for when the enemy runs out of health.
We needed to have actual combat that has an impact across characters. The animations worked, but we needed kicks and punches to affect health bars. We needed health pickups. We wanted to include a ‘block’ ability that stops the player from taking damage if they’re blocking.
The Level design was simple, with one texture across all of the shapes and objects which had been merged into one. We needed to separate the objects into their own individual 3d models and reconstruct the level, and finally retexture the scene.
Although my 3rd developer had made some menus for the game, we were unable to get them into the game on time for submission. We needed to actually add these into the game.
We also needed some sort of sound design to make the setting more engaging and interesting.
My coder and I spent a large portion of the next two weeks working together on both the Enemy AI code and the Player Character code, looking at a multitude of things.
At this point in our coding studies we finally discovered how to ‘Cast To’ in blueprints. This was a eureka moment for us, as we could finally implement a combat system that worked. We had many hiccups along the way, for example our enemies could damage us from far away, so we had to implement a way to check overlapping spheres in the character. We initially could only cast damage to one enemy, so we learned to set up an array of enemies that we could cast damage to. I used the basic framework that we made for our enemy AI and then made some variations, such as an enemy that could leap attack, one that would spin or push the player backwards etc. I made basic code for these mechanics and my coder fixed it when it broke or was sloppy.
I implemented the health system for our player character, and had assigned my Artist to make some health ‘Hearts’ and pickup ‘health bottles’ for visual representation. I even set up a rudimentary inventory system for the bottles, which stopped the player from picking up bottles once they had hit max capacity. Our Player Character health bar was 3 hearts which depleted in half-hearts. My coder eventually helped me set up a system that didn’t allow the health bottle to be consumed if the PC was on full health, and stopped the consumable from healing us past full health if the Player character had only lost half a health (as the consumable would heal a full heart of health).
My developer who had initially made the 3d assets for the game was able to go away and separate the large 3d model into its core components. We were then able to put them into the game and my developer played around with the textures and made the level look far more interesting than it was before.
After this was done I played around with the lighting in the engine. I turned down the spotlight that was lighting the scene to virtually 0, and added more dynamic lights the scene. From there, unreal engines Lumen system and ray tracing did the rest of the work, making the scene look pretty. A specific example of this is the lights on the engine; my developer gave it a light blue texture on the inside and a more metallic/grey texture on the outside, when I placed lights right next to the blue insides the ray tracing gave off an amazing soft diffuse blue light.
I finally got a look at my 3rd developers menus, which he had made as widgets. We had a Start menu and a game over menu. I then had to learn how to implement the widgets in game. From doing that I also learned how to make my own widgets and apply them to levels, I used this knowledge to make a ‘Controls Menu’ and a functioning pause menu. I then programmed the code for the menus to function correctly.
The last week of our fixes was upon us, and we were mostly happy with the gameplay, level design and all around design of the game. I had tasked my 2nd Developer to find some sound and music assets, and implement them into the game. Unfortunately the sounds and music he was finding were either not on theme with our game or had licensing issues which meant we couldn’t use them. The night before our actual final submission I had a crack at sound design.
I found several open source websites, which only required us to simply credit the website and/or creators if we were to use them. I implement music into the levels and menus, I also applied sounds to the pickups, attacks, hurt states etc. This required me to learn how to use ‘Sound Cues’ in unreal engine. Finally I added a dynamic ‘hum’ sound in game for the engine, meaning that if you’re wearing headphones and pass the engine, it’s hum will move from right to left headphone accordingly.
The only thing I could fix was some sort of repeating sound effect that was happening when enemies got hurt or died. It was as if the sound was being played several times over itself and was loud and immersion breaking.
Reflection
All in all I learned a lot from this Game Jam task, from the game development pipeline and discovering realistic timelines/deadlines, to technical and artistic knowledge, to managing a team in a production role especially.
One obstacle that I discovered I wasn’t alone in by speaking with my Production Peers is that team members not turning up or engaging was a real problem across the course, and one which I also struggled with. The way I dealt with that for this project is probably not the most sustainable, as I chose to pull up the slack myself. This ultimately lead to me burning out and falling behind on my studies and modules. I think for the future I will explore other means of communicating my (and the teams) needs to team members who aren’t necessarily contributing enough, in the hopes that this motivates them. I will try to communicate with the whole team a lot better in regards to scheduling; if I can set up a more defined schedule framework then hopefully I can minimise the risk of team members not showing, as well as prevent myself from overworking.
Alongside scheduling, I now have a better understanding of the game development pipeline, of how long certain tasks might take and of what tasks should take priority. With this knowledge, and access to Project Management software, such as Jira, I should hopefully be able to provide more clearly defined objectives and deadlines.