A Year Of Technical Games Development

Development Diaries are simply what the name suggests, a write up of the development of something in a diary structure, I had written one myself throughout the development for Blocky road to document my process. Initially, however, I found that it had been difficult to keep up with this on a day-to-day basis, as I had a lot to write about in little time. I thought about how I can write development logs differently, so I don’t have to write them each day.
One reason I like writing Development Diaries is because it gives me something to look back, and reflect on when I grow my skills, and it can look really good on my portfolio! Another reason is, on a blog post I read, Sokolovski (2020) stated that “Transparency and engagement with fans can positively contribute to the player-base's impression of the studio and, in turn, make them want to play the game even more, therefore attracting even more potential players.” This really motivated me to keep up with my own diaries.
To make sure I’m able to write good development diaries without forgetting important details, I figured the best way to approach this for this game in particular was to build up a list of tasks which I’ve done on Trello, and at the end of development, update my development diary, for other projects with a longer production time, I would update my development diary every-other-day.
It’s useful to be able to use Trello to note down what I was able to do, as otherwise I may have forgotten about them!
When I was doing this, I was relying on my memory to remember what I have done on each task, as I only noted down what the task was and not what I done to complete it! I think to improve, I could’ve left comments or a short sentence explaining what I did for the task with some images to support that.

For my game, I needed some way of telling the player how much they can charge up their movement before they move, so I came up with a circle charge UI design, Quintans (2013) gave an example of Good UI by mentioning “the role of a good UI is to provide relevant information clearly and quickly, and to get out of the way once it has done its job.” – So, I took that into consideration when implementing the charge movement which follows the players mouse.
The reason why I had to implement this way of movement is because I couldn’t use the WASD keys to move the player character, instead, I had to think of how to move the player with a single key, so the entire game can be played with one key. This makes the game easy-to-play for anyone.
For the visual side of the charge movement, I made 2 transparent rings in Photoshop, and applied the code of the charging to the fill of one of the rings inside of Unity.
I got this working pretty quickly, as I already had all the code I needed in place, but there was a bug which I had, which I couldn’t fix in the time I had.
For me, this was one of the most significant bugs in the game, and in more detail, the bug was that the bar would fill up, and go up to being full, but then I would want it to go back to 1, instead, the bar never got to 4, and then skipped right to 1, so in the end, I made the bar so it stayed full once you’ve already charged it to 4.
At the time I felt this was fine, but looking back onto this broken UI now, it doesn’t make any sense to a new player, and may confuse them when they’re playing.
This understanding will be essential to me going forward, if I ever want to further develop this game, I know what to work on and fix first.

One thing I have always wanted to do was be a group lead for a game jam, and this is because I wanted to know what the workflow was like, and if I would be a good lead.
At first, I thought that being a group lead meant that I deal with some project management and have plenty of time to work on other things for the game, in my case, the programming, but I quickly learnt that this wasn’t the case.

As I was new to leading, I had to learn a bit more about it. Kantilaftis (2014) wrote an excellent blog post called ‘How To Form A Solid Indie Game Development Team’ – This blog post gave me an insight on the many different roles that could be taken on in Games Development excluding the handful which I already knew about. Kantilaftis’s description of a Project Manager helped me realise what my role was, as quoted by her; “(their) responsibility is to make sure the team works fast and efficiently.” She followed this by answering our burning question of why it should be done; “(they) will be the one that sets milestones for the team and sees to it that they are achieved in a reasonable time frame” and how to do so; “This involves motivating team members that fall behind and making sure everyone is performing their tasks.”
To make sure members are performing their tasks, staying motivated and not falling behind, I made a working schedule for the group, as it was only a weeklong game jam, we each put in around 7 to 9 hours into this game.
For me, the most useful way I knew to stay on track was to not cram work in at once, but to instead work in chunks of 3 hours, this ensures we can stay focused, we aren’t putting in too many hours and we are working to the best of our abilities. At the time, I didn’t think about how everyone may have different schedules, alternatively, keeping the team on a work schedule can be good, as it’s not long term, and it ensures everyone is working at the same time.

On my development diary, I wrote about how some members weren’t available during the sessions, so I trusted them to work on their own accord to reach the same amount of work hours as everyone else in the group, I had no way of checking the working hours, so it was entirely possible that group members who aren’t available during the scheduled hours may overwork or underwork themselves, in the future, if I were to lead another project, this is something which I could do further research into, and improve on. To check our members were performing their tasks, for each working session, we joined a group call, and during this group call, I checked where everyone is and their plan of action for the session, I would also work on assigning tasks by sharing my screen and going through our groups Trello task list. We would remain on the call whilst we worked just to simulate a work environment.

Teaching and explaining source control is very important, especially for a group project like this, since we are all working on the same Unity Project, but I thought to make things easier and to get less conflicts, I would only set up, and teach git to the programmers of the group, so that means Layla and Fabio, it would be extra unneeded work to set up git for the artists for a game which we are only going to work on shortly.
I explained source control and how it worked to everyone on a discord call, and then guided Layla and Fabio through how to install Github Desktop and use it with the games repository, which I had set up with an empty Unity Project.
I explained why it is important to have useful, descriptive comments on each commit and how they should try not to work on the same stuff at the same time to avoid coming across conflicts (We never even got one!) We avoided working on multiple branches and just pushed all of our commits to the master branch, since the game is only a small game. They both picked up how it worked very quickly, so in the end working on this game with source control made it so much easier then working on separate unity projects!

I decided to take the Group Lead role on again and this was to improve on anything I may have not done as well last time; and although my peer feedback on my leadership was all positive, I knew there had to be other areas which I could improve in.
Previously, I stated that for Pet Pal I didn’t have time to do much programming for the game, as all of my time was mostly spent on project management, this time I wanted to make sure I can contribute to programming as well.
For me, I would've initially thought the most significant difference between leading this project and leading the previous is the team size, for this project we had a team of 8; and because of the team size difference, you would think there was more which I had to manage as the group leader, but having experienced this, I now realise that leading a team of 8 is not much different from leading a team of 5! Furthermore, I have learnt that this is most likely because of having team members which are happy to pull their own weight in the team, so there wasn’t any conflicts which I had to deal with in either of these games.
Another relevant and useful experience this time leading the project has to be reflecting on what I’ve learnt previously.
For this game, I decided to get more input, in multiple areas from every member of the team, as previously I felt like I didn’t do that. At the time I thought this would be a bad idea, and the team wouldn’t contribute, but I was pleasantly surprised at how much input this team gave me!
An example of one of the inputs I asked for at the beginning of the game jam, was I asked every team member what role they wanted to take on for the development of the game, they could pick whatever they liked, if they wanted to try something new, or if they wanted to stick to something they were more comfortable with, I really enjoyed this as I felt like for the other gamejams which I’ve participated in, most people stick to a role which they know they can do well, or a role they were assigned, but I personally feel like experimenting in different areas is one of the most valuable experiences you can get out of these gamejams, and this is certainly something which I will be doing for any future gamejams which I lead.
In addition to that, another input which I have taken from the team is about opinions on the game’s development thus far, one question in particular was about a main aspect of the game which we didn’t have time to implement.
I think the ability to give creative input, even in an area which you don’t specialise in is important, a lack of creative input is commonly found in triple-a studios, and it’s called ‘Triple-a Fatigue’, many opinions on this article state that with a lack of creative input, they don’t feel part of the games development, so I wanted to know the opinion of other game developers’ on this subject, and to do this I made a survey, and some of the answers I got were very interesting and informative! The results which I have gotten from this indicate that there are many pros and cons to creative freedom, and it will certainly be something which I will be looking further into in the future.

Specific tasks were shared out amongst the programmers of the team, and the majority of those tasks were to do with mechanics involving the player, so I decided to take on level mechanics myself, this involves things like visual cues to fade the screen between levels, to checking if the player has the key to complete the level by the time they reach the door.
Doing this as early as possible was essential, as I needed to build a level template which can be worked with when it comes to designing and implementing levels, and levels isn’t something we want to work on last minute! - This is because, like Weesner, (2011) states “Level design is incredibly time consuming. It’s one of the few aspects of design that spans the entire development process from early prototyping to closing out final bugs!” and in my own experience with making levels in gamejams starting the level design as soon as possible is always good, as if you were to start level design closer to the deadline like I did for ‘In Too Deep’, ‘Welcome To Yelapa’ and ‘Airport – Lost & Found Division’ the levels tend to be lower quality, and less entertaining to play, in comparison, the gamejams where levels were focused on sooner like ‘Team Swap Heroes’, ‘Driven Round The Loop’ and ‘Only One Recruit’ have much more entertaining and fun to play levels, which in turn makes the player want to play for longer, I noticed this pattern during the development which is why I tried to get the team to work on the level design as soon as possible.
One of the mechanics I worked on for the levels was checking to see if they key to open the door has been collected.
To make this work, I made a levelProperties script, which would be on every level and contain a boolean which indicates whether the player has collected the key for the level or not, and if they have, it runs the win function.
At the time, I thought this was the best way of approaching this, as it worked, but having learnt many new practices since then, I now realise that I should’ve used ScriptableObjects to contain level data, and keep things tidy, as “they are great for organizing assets” BlueBubbleBee, (2020). As a next step, if I were to work on this game again, I would be doing a lot of tidying to make sure the game is as optimized as possible, so adding levels to it would be easy for anyone to do!
To go a step further, I could integrate level creation with a program like Tiled to build out levels from JSON text files, so artists would be able to use the easy to learn Tiled program to paint out levels!

Being a solo-programmer on this game meant that I had to handle a lot of work - And I was prepared for this! Some things which I had to work on during this project involve source control, and implementing all my teams' models, and game mechanics inside of Unity (Our game engine).
As I mentioned, I asked the team if I can take on the entirety of the programming myself as a personal challenge, and I'm very happy they let me do that, as it allowed me to challenge myself, and although I got stressed near the end of the game jam, it helped me learn what I can accomplish and what my limits are when working by myself on programming.
A blog post titled 'Can Stress Help Students?' I read by Jain, (2015) talks about the benefits of stress, we usually see stress as a negative thing, but "Thinking about stress as 'good' or performance-enhancing can work to your advantage" as studies showed "[people] primed with the mindset that stress was good for them - felt more productive and energetic."
I didn't do this research during the game jam, but I know for the future that I should try and see stress as a positive, to help me with productivity, I would do this by thinking about the end product as I'm working toward it.

As a group, and as divided specialisms, we all began doing research into things we may need to know, and we shared these things.
We also had our own group Zotero. Zotero is a "reference management software to manage bibliographic data and related research materials" (‘Zotero’, 2021) We used the Zotero to put useful videos and guides to help everyone out on.
We also put together group discussions calls, where we proposed new ideas to grow our understanding of what we will end up making by the end of this.
As of January, when we were doing these calls and collecting research, we had researched into all areas of things.
For our general research, we done a lot of research into How Submarines Work (How Submarines Work, 2000), into How Submarines Dive and Surface (Science Channel, 2016), and into what it’s like on a submarine. (Navy Lookout, 2020; Royal Navy Personnel in the Control Room on HMS Vigilant, Submarine..., n.d.; Ship Control Station, n.d.)
For our art research, the modellers looked into substance designer , the documentation tells us that "Substance Designer is an application intended for creating 2D textures, materials and effects in a node-based interface, with a heavy focus on procedural generation, parametrisation and non-destructive workflows", the modellers used a guide to learning substance (The DiNusty Empire, 2016) and research into how to unwrap (ChamferZone, 2017).
For the programming research, we had a look into a few things regarding VR and Networking , (Latency Compensating Methods in Client/Server In-Game Protocol Design and Optimization - Valve Developer Community, n.d.; Locomotion Vault, n.d.) I didn’t personally do this research as this was something Aurora and George were looking into.
The research I helped out with was a lot of the general stuff in the early stages, as I wasn’t thinking much about the programming side of things yet, as we haven’t delved into even a prototype at this point yet.

At this point I was only told to study Unreal Engine and C++ over the Christmas break, to get comfortable with using Unreal with a combination of Blueprints and C++. Previously, I had done my own research and study into Unreal and C++, but I hadn’t ever applied it to a final game before.
I began my study of Unreal by going through the Unreal Engine Documentation and taking notes on important things, which I can use as a reference when I’m stuck. In addition to using it as a reference, writing out notes this way helps me remember and study them much better.
I studied lots of basics, like the most important workflows when working in Unreal, Player Movement, Input Checking and Interacting with things, and User Interface. I personally found the Unity to Unreal documentation (Unreal Engine 4 For Unity Developers, n.d.) very helpful to pick up things a lot quicker, as it used terms that I’m familiar with.
Another source that I used to study was the book Understanding the Basics of Blueprints (Ferro, n.d.). I didn’t study the whole book, but I read the entirety of chapter 2. I have also done some research into the Planesman using a web page (Ship Control Station, n.d.) which talked about submarine movement in much more detail, I also looked into some terms, like Yaw and Rudder, and found a picture that showcases the six-degree-of-freedom model of a submarine (Figure 1. The Six Degree-of-Freedom Model of Submarine, n.d.), this helped me understand these terms.

In the first few months of development, nothing much was done to make the game at all, so I decided if nothing was going to be done, I would have to individually get started with some sort of prototype.
We were still using Unreal Engine at this point, and I was not confident with using that at the time, so I decided for the purposes of prototyping and idea generation I would use Unity, and another thing I would avoid is the whole ‘VR’ stuff as I haven’t got my own VR which is compatible, I would aim to make this prototype work with mouse controls, and maybe some keyboard presses. This means our whole team could use and play it.

I didn’t spend too long on this prototype, there isn’t any functionality in it besides camera movement, but even doing something like this sparked ideas!
I used Liam’s basic block out to get an idea of the scale of the place and how I could work with it, at this point, the team was still confused on the brief, we hadn’t been in a submarine, we had no idea what it looked like and we only had a basic idea of what a planesman and periscope operator actually do.
With this barebones blockout-with-camera-controls-prototype I whacked together quickly, I had these ideas for our future development:

• The game doesn’t necessarily need to be built from the ground-up with VR implemented, most of our group, except one person had a VR headset to test on, so it would be easier for testing purposes to have mouse controls so everyone could work on the game if they wanted to.
• We could plan and develop the game in singleplayer first, and then switch over to the multiplayer once we got all the basics down for the game.
• We could switch between the planesman and periscope operator with a UI button.
• It made me realise that we were focusing on stuff we shouldn’t be focusing on first, as we were worrying too much about the multiplayer and VR functionality rather than the actual game, even though they’re important, the actual game needs to work first, and the mechanics can be thrown together in a gamejam

After I completed the prototype and we were in a group voice call, I proposed my ideas, and how we should switch over to Unity because the majority of us knew how to use Unity and we only had limited time, which wouldn't be long enough for all of us to learn Unreal.
I proposed the singleplayer idea and how we should focus on the game instead of the multiplayer and the VR for now, and then from this call, we discussed running a gamejam over the weekend to get as much of the basic game done and implemented, as our team was being a bit slow in general and this was because we all didn’t know exactly what to do.

This is one of the smarter moves for the group, as we all knew we weren’t getting anywhere as of now, we knew we needed to do something, and that is why we arranged the gamejam.
I hoped that everyone in the group would attend, but unfortunately, they didn’t so there was a lot of work to do, which meant that we done what we planned but not to the quality that we wanted.
We made a trello board just for the gamejam which we worked our way though, and at this point, our 3D modellers Rob and Liam had already finished their submarine models.

First Day of Gamejam (12/02: 6pm start)

Our plan looked into the gameplay loop, the time frame, and the different controls, and any challenges we can add in to add difficulty to the game.
We planned the Periscope and Planesman mode out separately, but starting with the Periscope mode, we split it into 2, an ‘IN the periscope’ mode and a ‘Human Mode’ and from here we began going into detail about what each of those jobs done, and as we were describing this we decided to reference our brief which we had previously put together. Having it in a graph like this makes it seem like much less work is needed to be done.
With the Human Mode, we just had to take notes on how they would input their findings.
For the Planesman notes, we wrote about what they would do, and that wasn’t very much.
The rest of the Miro board had the gameplay description, which was a written summary on how we imagine it would flow, which had some ideas around it.
When we moved onto Unity, Aurora was adding the planesman room and the periscope room with their textures, and I was working on adding packages and working on the camera splines for the Periscope room.
For the periscope room, I decided to use splines for the cinematic transitions between using the periscope and going over to the input panel, at this point they were just simple cameras moving along splines, there was no transitions between the two.

Second Day of Gamejam (12/02)

On this day I worked on a whole bunch of things, our planning on the Miro board was done, but we kept using the Trello.
I began working on the script to switch between the periscope and using the control panel for the periscope room.
After that I worked on the package management, importing Aura 2 and DOTween.
I imported Aura 2 for Rob to play around with the lighting, and to make the scenes look nicer.
From here I worked on the Planesman camera controls, and much like my individual prototype, I used Cinemachine to make a ‘first person’ feeling camera which you can move around with your mouse, it also has restrictions so you can’t go past certain angles looking up and down, and the camera slowly recentres to the control panel if you have it in one place for too long.
From here I worked more on the periscope room and the planesman room, getting them to crossfade between each other, as snapping to the next camera feels unnatural.
I made the crossfade with an image UI component, and I simply got it to fade in or out depending on the bool parameter which I enabled and disabled within the code when you press on the interactive buttons in the rooms. I also made the Fade UI a prefab so it can be used in any scene.
From here I then worked on outputting stuff to the screen as the planesman operator, this wasn’t too hard to do, and it also looked really cool! This was the basics of it though, so the clearing functions and minus functions on the keypad were not working at this point.
Another thing I worked on during this day was the friend which will be sitting next to you when you’re in the planesman room.
Usually there would be 2 planesman in a submarine sitting side by side, and for this, we voted on a character in a poll which we have taken from Mixamo, for now this character is a placeholder, and I picked to use Mixamo as it’s all free and has many many realistic animations which you can apply to models which either you have made or they’re pre made on the website.
We ended up picking the gas mask character, as it means we wouldn’t have to worry about lip syncing when they give the instructions on how to play the game.
He was also inserted into the game, and it made the planesman area feel so much more alive!

Last Day of Gamejam (13/02)

On the last day of the gamejam it was hard to get the rest of the programming stuff done, but that was just down to me arranging the gamejam date to be on a day where most people in our team were busy! I didn’t think I could get the rest of the programming stuff done on time.

On things non-programming related, I worked on reinserting the lighting for the periscope room, as something happened in Rob’s lighting on the room which made things error, putting the lighting in was fun as I was able to work with fog and different colours, and it really gave more personality to the room. I also worked on optimizing the camera controls for the periscope room as I was working on the lighting another thing I worked on was putting some more props into all of the scenes to make them look more alive! These props came from Liam and Rob, and I really like how they clutter up the place more.

I then began working on making the input screen more detailed, to display what we need it to and getting the minus button and clear button working, now you can switch between putting the yaw and pitch inputs in, but I doubt this format would be used for the final game as we need to plan a bit more about how this would all work in general.

After this I began working on the actual periscope, as of now there is no ‘sea’ in the game, but I’ve made targets which are any object tagged with target, and the periscope operator turns their camera according to some buttons, but this is all prototyping! this WILL be changed in the future!

This was also added in as a button within the periscope room, so you can go in and out from using the periscope and being in the periscope room!

Gabe also found some cool sound FX which we used on the buttons in the game to make using the control panel more fun to use!

And that was pretty much what I had done for the gamejam, it was a lot of hard work, and it paid off! 
And because this one went so well, we decided to do another one at some point which we are going to try and get the whole team to attend!