End Evaluation

Overview

Overall, I view my project as a major success. I managed to achieve the majority of my goals, such as having a real game made by the deadline, lots of interactivity and some in depth and well made sprites that made the graphics of the game highly pleasing and almost industry level in terms of quality. There are, of course, things that I had to miss out despite naming them on my project proposal. These things include but are not limited to having in depth audio, a player death animation and item interactions. I see me missing out these important things as an unfortunate consequence of being too ambitious with my project. Despite their absence, I feel that the content that I have made and will evaluate here is of a high standard and generally proves that I have accomplished the most important parts of my project.  

Planning

Trello

My planning work was very extensive and varied. It icluded using 2 main websites called Trello and Miro. Trello is a timekeeping app that can be used to make Kanban time plans, meanwhile Miro is used to create things like Mood boards and flow charts. 

The Trello board was screenshotted throughout the production 3 times, though it's worth noting that the Trello was updated every time I accomplished something that was on the board. I created the board at the start of the project and added various things that I would need to complete if I wanted to be successful in this project. At multiple times in the project, I decided to alter my Trello board by removing certain aspects as well as making some optional. This was done as a form of time management, if I had more time than I thought I had, I could add things to the Trello board and do more work in the time I had free. Unfortunately this never happened and so I was left pretty much entirely removing things from the board. This happened in around 2 waves with things being made optional and highlighted with a yellow colour, whilst other things were removed completely from the project by highlighting them in purple. Obviously the least important aspects such as extra interactivity were removed from the Trello first, but not removed entirely. This was to allow me to leave time for the things that really mattered like the interactivity needed for the story, meanwhile if I got any extra time I could change the colour of the yellow or purple tabs in Trello to make it clear that I am actually going to do them. By saving time for the important parts of the project, I managed to ensure I completed all the parts that mattered without any sacrifice in their quality. I think that by taking action like I did, the final product I ended up with was better than had I not taken any action at all. This is because the extra time I afforded to major parts of the project by removing unneeded parts, I could instead spend on the more needed bits. This meant that despite having less than intended, what I did have was higher quality and so more likely to be appreciated by the player. 

Not only this, the Trello board in general was vital to my work. I used it to keep track of what I was doing for the project, making sure that every time I did something, I ticket it off on the Trello board by highlighting it green. This meant that anything I had logged on the Trello would be impossible to miss, meaning that I completed every single needed part of the project, leading to a much more refined and fuller project as a whole, meaning an overall better game for the players and my peers. Alongside making sure I did everything I needed, there was also the benefit of being able to see visibly how much was left to do and whether things were being left undone and so piling up. If I saw that things were legitimately getting too much for me, then I could remove things that were sort of extras and not vital to the project to conserve time for my more vital tasks. This sort of thinking allowed me to keep up with the parts that mattered, meaning the main parts of the project were made with plenty of time and so made to a very good quality. This led to an overall better product that lacked in a few areas but had a very stable foundation of interactivity, movement, gameplay, story and much, much more. Without Trello, it's likely much would be missing and plenty more would be rushed to meet time constraints. By making sure I considered low - high priority tasks, this allowed me to streamline my process a lot better, making sure I prioritized the main tasks over others, which fundamentally allowed me to complete my product to the standard it is. The major issue I had with Trello was that I didn't use a day by day system. I have a feeling that if I had put dates onto certain cards, I could have created my work in a more timely manner as well as understanding when I fell behind better. This could have saved me time in the production which I could have used as free time, another thing missing from my Trello board which could have given me prime time to evaluate my work and get more peer feedback.
                                                                         

Miro

Another way I planned for this project was by using a Miro board. Miro boards are very useful as you can use them for many purposes, this could be time planning, flow charting, mood boarding and mind mapping amongst many more. Since I used Trello for a time plan, I decided the need to use Miro for a time planner was pretty much none, meaning I missed out this work as I thought it to be a waste of time when I did the same thing on a different website. I did however, use the Miro to create very valuable and extensive flowcharts as well as mood boards. These flow charts were incredibly helpful to the production side of my game as code is a very linear thing. By making mood boards easily on Miro, I was able to understand how the code should progress, when things should be happening as it executes and what the end goal of the code actually was. This saved me a lot of time figuring out how to code things through trial and error in UE5, as I instead just created a 5 minute flow chart of what I expected would be happening, checked for any flaws while it was simple and just copied the different nodes of the mood board into nodes in the blueprint editor of Unreal Engine 5. This time was very useful as it allowed me to make more flow charts which gave me the same benefits, meanwhile the greater understanding of my code as a whole meant that I could more easily implement changes and iron out bugs, meaning a more robust game less prone to crashing. This is something 100% of players would appreciate it makes the game go more smoothly, maintaining the atmosphere I tried hard to build with my sprites and dialogue.

On the topic of sprites, I used the Miro board to make mood boards. These mood boards contained images of things that relate to different topics in my game, such as the player or the UI. Whenever I was considering things like the character design or how to display something like the ingame text, I was able to look at the mood boards I had created and use them as a sort of guideline for what the things I wanted to make actually looked like for other people and within the industry. The moodboards also gave me inspiration as to how to do certain things like what height to make my character and the style I could use for my Aseprite creations. In total honesty, I think they were more than necessary to create my project to such success. They were very useful in stopping me getting creators block, as whenever I was stuck with something, I would just look at the images on the mood boards and would instantly have ideas on how to do the things I was struggling with such as the design of the main character. This without a doubt saved me lots of time as I was able to crack on with my work instead of having to spend time coming up with completely original and chances are worse ideas as without the moodboards, I wouldn't have understood how it was that other people made things and what worked. Being able to see what worked for others helped me to create assets that looked industry standard and appealing to players and my peers, making my game look more professional as I used work from successful creations to help with my own project. My only issue is that I didn't make enough mood boards. The monster was relatively uninspired as a clone of the main character, and I think that by making a mood board for the monster itself, I could have avoided this simplicity. I also could have avoided making my weather so simple with more mood boards, as I could have learned how to properly display weather as sprites, possibly building the atmosphere more than I did without such mood boards. In the future I would probably make better use of mood boards by having some for things like the weather and possible settings. This could have really improved my work since I would have been able to rate the idea of setting the game in a radio station against other ideas such as a shopping market or a theme park. Obviously I'm happy that the radio station fit the story so well, but in reality I probably could have made the game seem a lot better in the eyes of more people if I took more time and was more serious when decided upon it.

The final use for my Miro board was to mind map some of the ideas I came up with during the idea creating part of the project (around the first 2 weeks). I made spider diagrams with at least one idea for each category I included. This allowed me to see all of my ideas layed out in a very simple and obvious way, allowing me to internally weigh up the pros and cons of each idea whilst figuring out which one I actually liked the most. This was a great thing to do with my planning time, as it let me understand what game idea actually interested me the most, meaning that when I eventually started to make the game, I would start and maintain a good enough level of motivation to get the project completed, as I myself would want the game to exist so I could play it just like any other player. It also meant that I could gain a deeper understanding of what I could do with my limited time, as I was able to rule out large projects like a visual novel or having to chase down a terrorist leader. This couples with me being able to narrow down what I was actually capable of, as without a mind map to rule out large projects and judge my capabilities, there's a chance I would have started a project that I didn't like, didn't have time for and didn't know how to make. This would have without a doubt meant me failing this project and not having a game to show off or any meaningful assets for such a game, I thankfully avoided this sort of fate through using my mind maps and learning what each idea truly meant. I also had my peers put a few ideas down that I could use to help inspire my own work, ensuring that I wouldn't watch my peers would develop and get frustrated when I see something I could and would like to have included in my own project. This helped to keep my enthusiasm up and my stress levels down, helping to create the game in a timely manner and with a good level of quality.      

GDD

The final planning that I think is worth mentioning, is my GDD. GDD stands for "Game development document", it included things like the intended visual style, the plot of the game, the map layout and a description of what the game was actually meant to be as well as many other details related to the project like what engine to use. The unfortunate part of making this GDD was that I worked on this project alone, when most of the time a GDD should be used in a team to make sure that everyone understands what is actually be created, the end goal and how it will all be done. This sort of made it a waste of time to create, but in other ways it definitely wasn't. The time I spent making the GDD could have been spent making the actual production part of my project, this would have helped more as the GDD mostly included things I never forgot at any part of the project, meaning there was no real reason to look back at it. The extra time on production could also have allowed me to do important tasks like sound design, something I missed out on due to the deadline coming up. This would have meant me getting sound or another task done, improving the atmosphere, the animations or more generally the game as a whole, which means a better product for any players as there is more content or it is higher quality.

I can't say the GDD was a complete waste of time though, I occasionally went back to check what each level should include and what things like the age rating were. This allowed me to keep a good understanding of my initial views, making sure nothing I made during production would sway too far from the original idea, and so look out of place. In a way, this helped to keep the game style more cemented, and so meant that nothing stood out in a bad way, something that could have broken the atmosphere of the horror game and ruined the project as a whole.

Research

Primary and secondary

The majority of the research I did for this project was online, though I also made use of things like custom forms to get the information I needed for this project.

My primary research mostly consisted of microsoft forms. These forms were filled with questions on things like the graphical style players would want as well as things like what really scared people. These forms were then given through a link on Microsoft teams to my peers and tutors, who answered them as honestly and as fully as possibly. This was a really good way to conduct research as it allowed me to make questions tailored for my own game and get answers to them in a timely manner from people who both knew things about the games industry as well as who played enough games to understand what the questions actually meant in the context of researching for a game. By doing primary research forms, I managed to gain an understanding into what it was the people around me felt like the game should be like, it also showed me whether my ideas needed changing whilst the project was still relatively early on, meaning I wouldn't be stuck having to fix something that doesn't belong in the game and that people could have pointed out to me through my primary research. This primary research was vital for my project being such a success, such as how it saved me time by letting me avoid making things people didn't want to see, as well as influencing my design choices in a way that made the game more appealing to a normal player or potential employers. Both fortunately and unfortunately, I didn't really have to remove anything from the game as people didn't really disagree with me on much, so I didn't get much benefit from saving any time. Despite this, if there was anything that needed changing, I could have avoided it using my primary research and could have used the time on more important tasks like production, helping to make the game as high quality as possible. Without primary research, it's possible some sort of bad idea could have been left unchanged as I wouldn't have realised it was anything bad, perhaps costing the game a lot in terms of how appealing it was or how fun to play it was.

I also conducted a healthy amount of secondary research. My secondary research was really helpful in this project and was made up of things I researched online. This gave me a wide variety of knowledge from some highly specialised people, allowing me to avoid making some simple mistakes as well as giving me insight into how things like colour theory and choosing between programming methods worked. Some more things I researched were good file management, animation principles, level design and file types. This was all incredibly helpful as it allowed me to gain a deep understanding into how different parts of my production could be completed, allowing me to avoid making mistakes as well as making me more likely to make a quality product as I knew how things worked better. A more concise example would be how because of my research into colour theory, I understood that making the monster a sort of off gray would make the player naturally infer that they were unnatural, diseased and a threat. This makes sense story wise, as well as giving the player the go ahead to shoot the enemy without explicitely telling them to do so. This research was great because it allowed me to not break the atmosphere of the final scene of the game with a pop up telling the player what to do, and instead allowed the player to infer the danger on their own and calculate how to stop it using what they know about the story and what the character picked up in a different level. Without my secondary research, things like this would have been impossible as I wouldn't have understood what colours make people naturally feel, costing me the atmosphere and tension at a pivotal point in my game, ruining the player experience.

Another way I managed to use my secondary research was when I chose what programming language to use based off of what I learned about each on the internet. I learned that blueprints were much more likely to lead to a successful project, and so I used them as the only form of code in the entire game. This lead to the success of the project as I quickly got a hang of how to code using blueprints and how different parts of Unreal Engine 5 worked with them. I could also mould my programming to better fit the limitations of blueprints as well as their natural strengths. Without knowing through my secondary research what coding method would be best, I probably would have had to choose between them based on a guess, possibly meaning I would have used c++. This could have ruined the entire project as c++ is harder to understand and harder to learn than blueprints, possibly leading to me struggling to the point of not being able to complete the production of my project, or leading to me needing time to actually learn the programming language, something that would have meant me sacrificing time spent doing other things like animating and creating the final battle. This would have led to an overall worse product for the player.

In the future I would definitely try to put more emphasis on primary research as I don't think I did an equal amount of that and secondary research despite them being of equal importance. If I did this, then I might have ended up with a better end project as I could have gotten more tailored and more local answers to how to do certain things and how those things should look or play.

Feedback (technically primary?)

Throughout the production phase, I got feedback on what I had done and what could use changing. In total, I got feedback 4 times and smaller amounts of feedback whilst I was working. My feedback generally came from focus groups that play tested my game, as well as getting feedback on what could be done to improve my site and what people felt about it. This feedback was very helpful as it allowed me to make changes to my project and to my google site throughout the entire development process. This was vital in ensuring that by the end of my project I had the best possible results. Without my feedback it's possible that my google sites would have been much messier and harder to digest, possibly leading to people not wanting to look through my work in the future or play my game as they may start to associate my work with being shoddy and lazily put together. It's also possible that I could have missed things like bugs in the game or missing research from my site, both of which could have led to my project being of a lower quality by the deadline as I wouldn't have understood many things due to missing research and would have had a worse game for people to play because of things like crashes and bugs due to people not getting the opportunity to playtest my game and tell me about things that I might have missed. 

This goes to show that having feedback in projects is exceptionally important if you want that project to be a success. It also shows that people can see things that you miss, and that it's helpful to have them tell you about such things as it means that you can stop real players from experiencing issues in the future.

Production

Blueprints

Blueprinting was by far the hardest part of my project, trying to get things to work whilst keeping them efficient, well organised and functional was always going to be difficult, and it proved difficult beyond what I'd expected at the start of the project. In some aspects I managed to exceed my own expectations, such as being able to program the text widgets that appeared letter by letter, as well as things like the monster being able to kill you, the doors actually working to move you to places and the progression system working seamlessly. These blueprints are great showcases that despite struggling to get some things working, I could easily implement even complex blueprints in a realtively timely manner. The inclusion of such complex code definitely made the game more interesting, kept the player more entertained and so made the quality of the game much higher. Despite this, there were areas of my blueprint work that could have been "executed" much better. 

In the future I would definitely avoid not giving myself enough time to program, since again and again I had to code the same feature differently to get exactly what I wanted, this included things like the door having the code to move the player eventually becoming just a place to hold the destination variable for the player to use in it's own code. When I did things like this, I left a lot of obselete code surrounding the working and more optimised code. This not only made it all much more difficult to understand, but also unoptimised the game, making it bigger than it needed to be for the exact same game, since code that served no purpose was just being left in. This caused me to lose a lot of time to just trying to figure out what code was actually needed for the function of the game and what was not. The majority of the time, the code was left due to not having enough time to clean up, with the organisation of the blueprints being exceptionally messy for the same reason. More time would have solved this issue, allowing me to clean the code up and so make it easier to edit in the future as I would be able to tell what did what and that everything there was needed. 

Another thing I really could have done with doing is commenting my code. This would have made it exceptionally easy to find what I was looking for when I was editing and logging it all, as well as making it more obvious to peers who could help me update the game what everything actually does. Alongside this, I would change things like the timelines and custom events to have more proper names, mostly because things like "loopdieloop" don't really tell you what it actually does for the game. Collectively, I probably spent around an hour just looking for things when I got lost in my own work. This is time that through better organisation and commenting could have been spent on making new blueprints or further optimising the ones I had.

Dealing with troublesome code

It's definitely worth mentioning that despite my overall success in the coding of this project, I did have to miss a few things outfor more than just time issues. For example my flare gun animations. Originally, when the player picked up the flare gun, they were meant to carry it around in their hand until using it to kill the final enemy. Unfortunately, when I actually tried to implement this, the code wouldn't work and instead began to corrupt itself. Starting with not being able to move the character at all anymore, and eventually corrupting the entire movement system of the main character blueprint. This was a major issue as it meant the rest of the work I had done since the last backup could have been lost completely, which would have cost me at least a week of my time to recreate. This would have put me behind schedule permanently. Fortunately, I found a way to migrate the entire main character blueprint from a backup save into the more recent one to preserve my work. The main thing I took from the whole situation however, was that I should abandon the idea of implementing the walk and idle animations changing to him with the flaregun completely. My reasoning behind this is that it's not worth risking the stability of the entire project just to add a flare gun to my characters hand, though I never added a second way to see that you were even carrying the flare gun which I regret.

In future projects, I would definitely be sure to add little failsafes incase of things like this, these would be alternatives like having a part of the UI show that you have the flare gun rather than showing nothing at all like I unfortunately had to with this project. I would also try to implement things earlier so that I know what exactly won't work and can make changes to accomodate the issues, this is with the idea in mind that I can iron out the details of the things I implemented quickly once I know everything will at least work. Unfortunately, I really do think that missing the flare gun ruined part of the ambience as the player felt no more protected than before, and I'm sure I will plan for this better in the future.

Sprites + animations

In my opinion, the sprites I made were very high quality. They fit the style I was going for perfectly, especially the environments. Most people that tried the game pointed out that the visuals were nice and well implemented, adding to the eerie atmosphere of the game. This feedback just goes to show how much my research into colour theory and level design actually helped me when it came to making the sprites for the environments as I made them with my research in mind, adding places for speech events to happen in order to award the player for looking around by giving them more of the ingame story. I also think that my sprites were well sized, with the player and the environmental sprites matching up perfectly size wise due to me using the player character as scale for creating the actual in-game map. This made the game look like it all fit together well and that it was all well thought out rather than just sloppily thrown together. In the future I would definitely pay more attention to how many pixels I used for the map and character as the pixel count severely limited how creative I could get when making my sprites. If I had more pixels available, I could add things like gore and realistic weather to the map, maybe even creases in the sofa or peeling wall paper. This would add a lot to the atmosphere of the game and could be extra useful in taking the story telling to the next level as I could have writing on the walls and perhaps even proper paintings and posters on the map, both of which I couldn't include this time around because of the low pixel count and so the limitations of how much room I had to work with.

In all honesty, I'm really proud of my animation skills this project. From my peer feedback and my own opinion, I can say without a doubt that my animations are fluid and realistic, as well as fitting perfectly into the ingame world. This is because I had decent frame rates for each animation to ensure fluidity, as well as making sure to keep the animation within the confines of reality. You can see this in how the character walks, with the characters legs maintaining the same legnth and the arms following in the correct swaying motion. If there was one thing I would change the next time I animate for a project, it would probably be how much time I have alloted to each animation. I would give myself more time animating to ensure that each and every animation the project needs gets done. The main reason I'm pointing this out is that I was unfortunately never able to make any monster attack animation, player death animation and things like an idle animation for the character purely because of a lack of time. If I had spent any more time animating, it's likely that I wouldn't have had time to finish the actual game and so it would be a failed project. Even if I did finish the game, the chances of everything being polished and the animations actually being implemented into the game would be low, with the game probably being worse off with them than without. I definitely think I made the right call in stopping with the walk animation for the monster purely because I know now that I couldn't have finished the project if I had spent any more time away from coding.

Without a doubt I will be giving myself more time next time, or will outsource a little to my peers to save myself time whilst maintaining the games great quality.

Backing Work Up

The final thing to really note is that I made sure to back up my work every time I considered there to be enough different from the old backup to warrant it. I do think this was a really good idea, mostly because it meant that if a corruption broke my most recent save, I'd have a fall back save to keep me from failing the project. The main issue is that I made backups without a proper schedule and whilst doing so only made them on my harddrive. These were both very bad ideas, as the backups tended to not be uniform in the amount of work different between them and often were instead massive jumps or nothing different at all. By following a set schedule to back my project up, I'm sure that I could have saved myself a lot more efficiently if something had actually gone wrong like my flare gun animation permanently breaking the project I tried to implement it into. This realisation that a schedule of backups could be useful will no doubt be thought of in my next project, in which I plan to do a backup every 3 days during production, this way not risking losing much more than half a week of progress. 

The fact I only made the backups on my harddrive rather than google drive or drop box as well, meant that if I lost my harddrive (like nearly happened near to the end of the project), I would lose everything I had worked so hard on and so wouldn't be able to use it all as my final project. To avoid making the same mistake in the future, I will definitely be making sure to store backups somewhere online as well as just on my harddrive. This will help to avoid any stress about losing everything, as well as having the bonus effect of making the project really easy to share with people. This will be very useful in the future as it means I can share the project with peers to get their opinions as well as just to have them play the game. If I work with anyone on a project like this in the future, having the ability to upload and download the game folder at any time would be a very useful thing, so I'm sure that the experience I have gained in backing up work in this project will impact my future work to a massive extent.

My use of weekly evaluations + my final feedback

When the project was coming to an end, I decided to get feedback on things like how people found the graphics or the interactivity of the game. This was really enlightening as it opened my eyes to things that I hadn't noticed before such as how short the game really was and how buggy it could be at times. This has really impacted how I see game development, and I'll be sure to make my future projects longer, more replayable and overall just more stable so that people can enjoy my projects without being interrupted by glitches or the abrupt ending of the game. I highly doubt that without this final feedback form, I would have noticed the shortness or instability of my project. This tells me that making a form right at the end of the project is a great way to inform yourself about how well you really did and what you need to do in order to improve. Without a doubt, making the form will impact my future projects as well as my attitude towards game development positively, with me choosing to give more time to bug fixing as well as making the story the right length for a normal player to sit down and enjoy.

Furthermore, I found a massive amount of helpfulness from my weekly evaluations, which let me understand what I was doing right and wrong based on how much I felt I was actually accomplishing each week as I wrote. The weekly evaluations were pivotal for the overall success of my project, with me using what I learned from them to modify how I was working. For example, I used my weekly evaluations alongside my Trello board to understand when I was falling behind or not. This allowed me to do things like removing parts of my Trello to do list as well as making some things optional rather than mandatory. This no doubt led to me getting my project completed and with such a good quality end product that I genuinely don't think I would have ended up making if it were not for the evaluating I was doing from week to week. In the future, I would make sure that I evaluating every week or maybe twice a week for added unserstanding of how the project the evaluations are linked to are going. This could also be coupled with more evaluating as many of my weekly evaluations felt more like a description, limiting how useful they were. I could also make sure to evaluate more during the logging of my work, as I feel that I could have really benefitted from understanding what I was struggling with during each task. For a lot of my production log, I ensured I added a conclusion to the bottom of the page stating what I learned and could do in the future, but by making this more detailed I could definitely improve the speed and quality of my future work through pure understanding.

Did I match my target audience?

I would argue that I overall managed to match my target audience quite well. I say this because the game maintained a spooky, errie and horror themed atmosphere without too much in the way of proper gore and horror that would have made it unsuitable for 12 year olds. I also managed to avoid using any bad language and avoided using a real gun in the game by instead having a flare gun, allowing me to fit eaily into the PEGI 12 age bracket. This is really good as it means that the possible audience for my game is not 18+ but also includes 12 and upwards, making my game more likely to get a community and more likely to succeed on the market. I also think that by keeping to the age rating I set out in my GDD, I managed to show potential employers or investors that I can keep to my original idea without veering off course. This is a great thing to show as it means I might be able to get paid for making future projects or at least partially funded, leading to higher quality games and projects as well as me making a better name for myself in the gaming community. This of course makes people more likely to play my older works including this project, meaning the game could develop a larger playerbase and community later down the line. Perhaps even years after the original release date. If I hadn't kept to this age rating, the chances of a community developing around the game would have been significantly lower as most gamers are around the age of 12-18 as they grew up with playstations and personal computers their entire lives. It would also make it less likely for investors to consider funding my future projects as I would be seen as unreliable and so not worth investing in, stunting my future projects before I even start them.

How my work was presented

In all honesty, I think my work was presented very well on my Itch.io page, youtube video and the screenshots I took of the game whilst playing. This is because the majority of people that see even one of these displays will understand what the game looks like and generally what it would be like to play. The one major gripe I have is that I didn't have anything more official. An X page relating to the development of the game could have been really good for creating an online community around the game through dev logs and weekly updates like my weekly evaluation. Unfortunately, I missed out on this opportunity, but would definitely make one for future projects as it makes the game I make more likely to have an actual playerbase and a real community wanting to support my work as a whole. 

I also wish that I had released the game on a more professional marketplace than Itch.io like Steam or the Unreal Marketplace. This is because Itch.io is associated with low quality releases from people that don't really have much of a passion for game development. The pure quantity of releases means that my game is likely to get hidden amongst these terrible games and so not get the attention it really deserves. This is really bad as it means that the game is unlikely to reach any major player base and is instead likely to just sit there as a portfolio piece. Not what I wanted at the start of this project. A release on Steam would make consumers see the game as a more professional piece due to the quality control Steam is famous for. This would have led to a proper community forming around my project instead of it just being lost in a sea of other releases on Itch.io

End Note

My end note is simple, I really think I did well with this game but I see major areas for improvement. I need to learn to be less ambitious without getting rid of my ambition as a whole, I also need to learn to organise my work more so that I don't have random code that doesn't do anything or execution lines that practically circle the entire blueprint page. On top of that, I could also use making use of primary research more for specific answers of what people want as well as leaving myself more time for bug fixing and just generally relaxing so that I don't get burnt out and slow down my work. 

If I'm able to do all these things, then I'm sure that my next project is going to be even better. Even higher quality, just as ambitious and just as well recieved.