For a more in-depth look into my own contributions to this prototype, here is a link to my portfolio where I go over in more technical depth how I created this prototype from beginning to end. LINK

Unlike what i’ve done for the previous game and broken down the development through prototypes each week, for this games version due to a time constraint of only 2.5 weeks i didn’t have time to break it down everytime i completed a feature and instead in this post i will break the game through the scripts that i’ve wrote with a final section explaining the video prototypes of the game. This is going to be a simplified breakdown of the games scripts.

The main focus of this prototype was to develop upon our previous game with improved game features. After our 2nd playtest we had alot of feedback and in our group discussion we highlighted a couple core game features we would like to see in the game to make it more interesting and fun:

• Continual Gameplay
• Being able to interact with camps
• Creating a utility for resource
• Be able to build camps
• Continual resource generation
• A complete checklist
• For each task there should be a corresponding storyline with each character

How the scripts are set up:

• Due to the more complicated game system than the previous version I had to begin planning for the future scripts. As such, i set my main scripts up like the gamemanager, campmanager, narrativemanager and task manager in a way that they behave independently but they share their data through two key handlers:
  • Save manager: Pretty much as it sounds, its in charge of saving the players session-levels through using Unity’s built in PlayerPrefs and in memory dictionaries
  • SceneTransitionData: This was to run alongside the save manager and attempt to keep transient data loaded across scenes. 
• An example of how this is used within the gameplay is that it keeps state-sensitive data like the resource totals, week progressions, task completions routed through this system to ensure consistency between the camp scene and narrative scene.

Elaborating on the utility of save & scene data handling:

• SaveManager: This handles two layers of save logic:
  • Permanent storage – Uses PlayerPrefs to remember the values for player resources
  • Temporary Data – To track in game session transfers between camp scene and narrative scene
• SceneTransitionData: Pretty much this script is a bridge for the runtime scene swaps, what’s included in this is:
  • Resource Values
  • Day and week counters
  • Camp upgrades 
  • This intalises a DontDestroyOnLoad() and is prioritized during a scene load
• The reason these are so important to have set up is that it creates a seamless transition for each time the narrative scene is called on, especially important when having to constantly playtest the game. 

CampManger Script: Handles the camp management, resource generation, and UI handling:

• The camp manager is in charge of how the camps are constructed, upgraded and how the resources are then generated. This means it creates the structure for the camp progression through an upgrade system which decreases production times. In addition, it also tracked the visuals of the camps from scene to scene ensuring the remain “built”.
• As i’ve mentioned there are 4 key features. Here is a brief explanation of each features utility:
  • Camp Construction & Upgrades – Simply this added a build cost, resource generation type and base generation time with the upgrade system decreasing the base generation time. This was implemented to offer a strategic choice of resource usage to maximise the resource output. 
  • Resource Generation Timers – I decided on using timers to control the rate in which camps produce their given resource whilst allowing this timer to be affected by the camps level.
  • UI Handling for Camp States – For each camp there are a couple of UI components connected to them, the build and upgrade button. The player can either see these options, or it will be locked due to the player not unlocking the previous required camp. Additionally to the buttons, the camps each have their required resource amount to both build and upgrade. Lastly, they each have the timer and slider to show how quick the camp is producing the resource in real time. 
  • Resource Management – There are 5 camps with 5 unique resources, scraps, food, bio, tech and security. The camps each have their own upgrade level which the game checks to determine how long the generation time will take. After each countdown the resource total gets updated by the resource management system

TaskManager Script – simplifying the task manager script, it is in charge of game objects and ensures that they have a clear task and reward for the player. The reason this is the longest and most in depth script was for numerous reasons but one of them being that the tasks were designed to be complex, interdependent and encourages the player to complete all tasks within the game.

• Some of the key features include handling the task structure, task UI, resource management integration and task dependencies. Here is a quick look into each feature:
  • Task Structure – Each Task is set up in a way that requires the previous task to have been either completed or at least close to being completed to progress. This sets up a structured progression that requires resource gathering, talking to characters and even potentially upgrading camps before they can complete all tasks. 
  • Task UI – Simply the task UI is set up so that you can click to examine the requirements for each character’s task and then also two buttons, one to speak to the character and one to complete the task. Once spoken to and completed the character profile grayed out indicating the task has been completed. 
  • Resource Management Integration – another core component of the tasks system is directly connected to the resource system. Each task requires the player to collect a specific amount of resources with each new camp unlocking the next camp’s options to be unlocked. This form of resource management integration keeps the player hooked and conscious about managing their resources.
  • Task Dependencies – Although not fully utilised the task dependencies sometimes require previous tasks / objectives to be completed to continue the game. This was implemented in the unlocking of the camp systems to create a logical flow to collect resources.

GameManager script – The gamemanger was in charge of the global game state and time progression.

• Although towards completion the gamemanger started to become outdated it still was in charge of controlling important features such as tracking the overall game progression from days to weeks to resources whilst also being in control of the narrative scene transitions. In the end I utilised it to create a logical flow to each system. Although long the most impactful system it controlled where:
  • Scene Transitions and State Persistence – Simplifying this it is responsible for saving and loading the numerous game states, specifically when transitioning between the narrative and camp scene. It made sure to save all game states including the current time, day, week and resources. All this data then got saved to the SceneTransitionData script which made sure that when the player transitioned back to the camp scene their game progress remained the same.

TimeController – Arguably the most important script, this controlled the day & week cycle, speed control, and visual feedback

• The timer controller was essential in managing the in-game timing controls and time based progressions while allowing the player to fast forward time to increase the resource generation timers. This was essential to keep players occupied later on in the game.
  • Day and Night cycle – each day equates to 300 seconds and this day progression can be seen with a continually updating digital clock and slider. For future development I implemented a day and night system that would flicker between day and night when the clock hit the evening and morning.
  • Speed Controls – This allowed the player to switch between normal mode and fast forward mode where it allowed the player to increase the days clock by 3x the speed. This allowed the player to reduce the wait for resource generation and tasks to be completed. This could be visually seen in all clocks and sliders significantly increasing in speed.

SeneTransistionData – was required for scene data persistence and state management

• Slightly more complicated the SceneTransitionData script serves as a persistent runtime container for all game data that needs to stay persistent between the two game scenes whilst also erasing this saved data at the end of a game session. It manages the temporary states like resource counts, camp states, task progression across scenes to create a smooth gameplay with easily transferable data. As this gets technical very quickly, a more in depth explanation of this script can be found in my portfolio HERE.

This was a challenging task in many ways from time constraints, miss-communications, technical challenges and many more. However, as a group we overcame these challenges and ended up producing a game, although not perfect, we were much more pleased to submit. With the help of my group we were able to come together and fix the major bugs littering the game. For a look into how the UI came together and all the call visual features check out Anna’s portfolio HERE and for my breakdown of how I developed the backend features and set up the foundation here is a link to my portfolio HERE. 

If you would like to look into a more in depth analysis of this prototype, here is a link to my breakdown in my portfolio: Joe

Whats going on in this prototype:

• Since the last prototype we had a playtest. Simply though as a group we decided the game needed a revamp, what was included in this revamp was removing the current drag & drop mechanic and replacing it with a smoother and more user friendly drag and drop mechanic. In addition to further make the game user friendly it was noted that the camps placeholders were confusing the players and it would make sense for the characters to all just be placed into one camp similar to the first prototype, the issue in doing this was keeping the characters benefits as the whole reason i added the placeholders was to determine if a character should receive a bonus or not. Lastly, the final thing noted was too many things happening on the screen and the actual camp area was too small.

Implementing the character drag and drop feature:

• What should have been a simple implementation turned out to be the second biggest issue I’ve faced in this project so far. From one bug to another this implementation challenged me in so many ways. Some of the reoccurring issues were that the character gameobject couldn’t detect if the mouse had clicked it or continued to click it, another issue was that each time the character gameobject was clicked to be dragged it got sent to the back of the hierarchy and therefore disappeared. But after re-writing the script, and changing the scenes hierarchy and multiple google searches of different error codes i got the drag and drop feature working. So as you can see in the video, the player drags each character and drops them into the camp and similar to before just clicks them to reset their position. 

Prototype 6 ext shows my idea of creating a tutorial section:

• During the playtest it was also noted that players couldn’t seem to understand the purpose of the game. This meant during the playtests i had to physically write a tutorial. To fix this i created a simple tutorial script that made the players click through a sequence of instructions circling and describing the different gameobejects. This will mean players can hopefully understand how to play the game.

Changing current placeholder system:

• As I said in my last paragraph, the drag and drop feature was the second biggest issue I faced – this feature was the biggest issue I’ve had to face so far. What looks simple and almost seamless took days of  focus on this one component. I had to go back to page one when thinking of how to achieve a one camp system that still determines whether to give a certain character a benefit. To simplify how I developed this system I gave each character an assigned value 0-3, I then gave each character a preferred camp ID from 0-4. Then each camp was given an ID from 0-4. After I had set this up in the inspector of the characters and camps I then had to worry about characters actually being able to be dropped into these camps. I did this mainly through the drag and drop mechanic by detecting if they are over a camp and if so then the camp determines if there is a free slot in the camp and allows the character to be placed and if not once the character is dropped its position is reset to its original position. 

Revamping entire project:

• In addition to adding these features, I revamped all the scripts by reducing the reliance on game manager script, camp manager script and click and drop script. I created multiple scripts to do specific purposes in an effort to erase bugs and issues caused by conflicting lines of code in these scripts. By doing this it has also reduced the lines of code and made every script a lot more readable and easier to change and adjust their functions without breaking the game. This is a small change but was time consuming and should hopefully allow me to make changes to my project in the future significantly easier

After this prototype was created I showed the group the development however, we came to the conclusion that even more significant changes needed to be made. So, after playtesting this prototype and taking on the feedback from the playtest 2 we decided to come up with a plan as to where we are going to take this project. All this information can be found on our WEEKLY MEETINGS and my personal portfolio where i go into the technical side of the change HERE. 

What’s happening in the video:

• This is the final version of the game before playtest 2. Within this version I made no charges to any scripts or even any UI. This prototype was created by Anna as she took on the role of UI designer. Within this prototype you can see a couple of changes. Firstly, the UI was entirely rearranged to make the game look more futuristic / rustic at the same time, with an entirely new colour scheme to match the GDDs vibe. In addition, she also added a tasks button in order to reduce the clutter on screen that could potentially be overwhelming the player, this also allows for more tasks / requirements to be added without worrying about fitting it on the already cramped scene. Lastly, the main difference, all of the artists drawings / visuals got implemented, from the character icons to the backgrounds and different character artists. As you can tell all of this combined really gave life to the game and makes it look more like a completed game. As a group we all feel happy and confident going into playtest 2 with this prototype.

If you would like to look into a more in depth analysis of this prototype, here is a link to my breakdown in my portfolio: Joe

What you are seeing in this prototype:

• In this prototype you can see that it now looks playtest worthy, this is because my main focus for this prototype was getting a version of the game that would be able to be playtested by not just me but by others. The main differences in this version was implementing some of the art that had been designed by the artists and arranging the UI in a way that best suited the GDD. This was accomplished by researching other games’ UI. In addition to these visual changes i implemented a core feature which is required in most games which is a fail state, i did this through making it so that food is ‘consumed’ when end day button is pressed and once the player runs out of food, the fail state kicks in and makes the player press a button to restart the game. Lastly, I had to fix some bugs and error codes before the playtest to ensure the game ran without any issues such as the size scaling and issues with task requirements.

Sorting UI screen out:

• As I briefly mentioned, I sorted the UI screen out by researching similar game UI which if you want to read more in depth, here is a link to my portfolio page where I explain it a bit more HERE . The more notable changes in this prototype in terms of the UI were removing any individual panels and making it a long panel where all gameobjects fit inside in an effort to make the game look more ‘futuristic’. In addition I moved all gameobjects to the side of the screen for the same reason. I like the way it has turned out but it still doesn’t look right, so we will have to revise this design. It was also mentioned in our weekly group discussion that the progress button felt too ‘cramped’ and felt out of place, so to fix this issue I moved it up with the End Day button where there was more room and to keep the ‘progression’ buttons together.

Fail state and restart method:

• One of the more important things that was added in this prototype was the fail state and restart method. The reason for this being so important is that it creates the overall game requirements for this module which is a core gameplay loop. With this system in place it meant that a player could start and finish the game with a fail state for losing and a restart method to try again. The way I implemented this was simple. In my gamemanager script i was pretty much detecting if the player had < 0 of food resource or if the player had < x amount of the required resource if this was statement was true it would activate a panel which would freeze the current gameplay and then the player would have no choice but to press a button to reset the game from the beginning of that scene.

Sounds and Music:

• Our narrative designer whilst working on the scripts also decided to create not only a soundtrack for the game but also UI clicky sounds. So to make use of these I decided to implement them into the game. This isn’t very complicated and I just wrote three short scripts, two that manages the music and allows me to in the inspector click loop to continue the music past the duration of the soundtrack. And one that I added which was the MouseSound script which really was just managing the sounds for the UI like the button clicks and the mouse clicks. To put it simply, what these scripts do is the mouse soundhandler uses Unitys built in audio components and I just call on them before the game starts and use an update function to check when the button is clicked and determine whether to play the button sound or general sound. The Background Music script just adds a audiosource component where i added the mp3 file to and allows me to play the music at the start of the game, and then the musicmanager script sets the audio component as a singleton to ensure only one instance throughout the game whilst also being set a not to be destroyed so that it plays in both scenes continuously. 

Improving on issues and errors:

• As with all the prototypes I had to constantly work on issues and errors that occurred both during the development of the new features and errors that have developed due to existing scripts conflicting with the newer scripts. My main issues I was still trying to solve were relating to getting the weekly tasks to update during the gameplay. I managed to find a solution to this by getting the script to both check and update the text after each ‘Day’. This meant that the player could see where their progress is in relation to the week’s task.

This prototype was crucial in the direction of the game. As such I asked for opinions and recommendations on where we should take this game now we have a functional frame. I sent it through the group chat so that when we met in person for our group meeting we were all on the same page as to where the project was and we all had an opinion on how we should develop the game. 

If you would like to look into a more in depth analysis of this prototype, here is a link to my breakdown in my portfolio: Joe

What you are seeing:

• Although it doesn’t seem like much this prototype was important as it was showcasing what the game would currently look like with visuals included whilst also highlighting the potential bugs and issues with the current version. In this prototype video you can see the overall core gameplay loop, with the player having to read the characters dialogue and then making decisions based on that dialogue to then being transported to the camp scene where you have to then manage the characters into different camps and after 7 days of this progress to what will be the next narrative scene.

Bug fix summary:

• Layering issues were really the only bugs I have encountered so far. What may be obvious is the layer hierarchy change in the narrative scene where the buttons panel now when triggered is called to be in front of all other game objects to ensure that there are no conflicting layer issues. 

Progress bar development:

• Developing upon my progress button we decided it would be best to include a requirements text / list that needs to be accomplished by day 7 so that they could progress. It was very simple to add as i had already manually inputted into the script the weekly requirements so all i had to do was make this public and then create an function to update the text the script is attached to everytime the resources change. As that was abit complicated to explain here is the code i wrote for this specific task:
  

If you would like to look into a more in depth analysis of this prototype, here is a link to my breakdown in my portfolio: Joe

Narrative Scene:

• Developing upon my last prototype and my plan I decided to tackle the narrative scene. First, I grey boxed the general area in which I wanted my gameobjects to be placed and started filling these in with either the art given to me by the artists or generic images I found online that fit the theme. To keep things as simple as possible I only created two scripts that controlled this entire scene, the DialogueManager and the PopUpManager. I’ll explain a bit more in detail about each script further down but first I want to explain the core game loop that is going on in the first scene. Each time the player left clicks anywhere on the screen they continue the dialogue until a certain point where they are faced with a choice of options. Once they’ve clicked through all of the dialogue and choices they are then met with a last button which will take them to the camp scene, this will be the same loop for all future narrative scenes.

Narrative Dialogue:

• I started brainstorming the best way to not only code but to set up the dialogue system. My first thoughts were to look at visual novels to see how their game loop flows. From watching both gameplay and tutorials on games such as Fallout New Vegas and King of Dragon Pass and watching Stellar Studios tutorial on making a visual novel in unity i decided the best way to go forward was base it off of the tutorial whilst taking inspiration from UI design from Fallout New Vegas.
• How it works, as seen in the video of the prototype, is that there is a set script that was written into the code so that each “button press” (clicking anywhere on the screen) moves the script onward. This includes everything including option choices, and decision choices by players. 

Option Choices:

• Going off of the same research as the narrative dialogue, the option choices were set up to “popup” in a predetermined way. Each choice button was scripted to trigger a chain of events. However, due to limitations of the narrative script not being written yet the options in this prototype, but i have already noted this as something that needed to be implemented and as such I already set-up a function in the code that handles this.

Placeholders and character benefits:

• During the earlier discussions and from the feedback on the first prototype it was mentioned that camps should not only produce their own resource i.e. scrap camp only produces scrap, but certain characters should also gain bonuses of a specific resource if they are placed in a specific camp. For example in the video you see me place the colours in the corresponding colours. Ie, character 1 red needed to be in camp 1 red placeholder to obtain + 5 resource. This was all coded within the GameManger and CharacterHolder scripts where it was, to put it simply, just determining if the ‘preferred’ character had been placed into the ‘correct’ character slot. If they were and then the End Day button was pressed they would gain +5 resources in comparison to the +1 resources if they were not in the preferred and correct placeholder. 

Progress button:

• A simple but important addition, I added a progress button which literally is there to progress to the next scene. I set it up so that it is greyed out and can’t be interacted with until the right conditions are met. In this prototype the conditions are that the day is 7, but in the future there will be more requirements to be able to interact with the button. 

To get some feedback and update my team on my current progress I sent this youtube video through to our group chat so I could get some general feedback. Additionally I presented my prototype in person during our meetings. If you want to read what discussions took place here is a link to the WEEKLY MEETINGS. After every prototype I try my best to develop the game in the direction the group wants whilst staying realistic as to what my developing skills can create. 

If you would like to look into a more in depth analysis of this prototype, here is a link to my breakdown in my portfolio: Joe

Breaking down what you’re seeing:

Drag & Drop Mechanic:

• One of the first mechanics / features that I needed to develop was the drag and drop mechanic. Using the already planned UI grey box I created a simple layout in unity and began work on developing the drag and drop mechanic between the characters and the camps that they will be assigned to. Whilst creating this script I noticed that having to drag characters around to reset their location was tedious. As such, I implemented an automatic location reset if the character is not dropped within a camp. Also, the characters that are already in the camps are able to be reset by just the click of a mouse, instead of dragging it all the way back. 

Resource Tracker:

• As the game is a resource management game I felt it necessary to tackle this mechanic early on so that I could get as much feedback and bug testing done in the remaining weeks. Simply, each character can be placed in each camp, once a character is placed in a camp and the end day button is pressed the resources section is updated and tracks how much resources should have been collected. It’s a very simple script that will need to be updated as I develop character specific benefits / skills that change how much resources are received each day. 

Progression Buttons:

• There’s not much to say with the progression buttons. The ‘End Day’ button was simple to implement as unity has built in buttons that do all the work for you. It was similar for the ‘Progress’ button, same implementation. I wrote a simple script that just greys out either of the buttons when they cannot be in use and added a gamemanager to detect when they have been pressed to then update the game scene accordingly. 

Scene Changer:

• This was the one implementation that stumped me for a while. I have never in my previous games or experiments had to change scenes through a button or change to a different scene all together. Such a simple switch should’ve been very easy. However, what I failed to realise is that I was using an up to date version of unity, what this means is that some of the websites and threads I was using to find any help were outdated. Luckily after playing around with build profiles I finally worked out how to set two scenes that can be switched between if called correctly in a gamemanager script.

To get some feedback and update my team on my current progress I sent this youtube video through to our group chat so I could get some general feedback. Additionally I presented my prototype in person during our meetings. If you want to read what discussions took place here is a link to the WEEKLY MEETINGS. After every prototype I try my best to develop the game in the direction the group wants whilst staying realistic as to what my developing skills can create.