Week 1 Evaluation
Week one has overall been quite a success, the project proposal seems to be completed to a standard I deem more than acceptable as well as the timeplan on Trello being fully made. I had no major issues with anything I planned to do this week and having the time to take an in depth look into academic resources as well as do things such as researching into different similar games have been amazing starts to my project. One thing I believe I could have improved on this week was that I just didn't set myself any sort of story making time, to make up for this I decided to have my story creation time on week 3, though I genuinely think that having the story sorted already would have made production quite a bit easier. Comparatively, I think that the project proposal and the project concept didn't really need there to be a cemented story yet, and so I feel that by making the story once I have ironed out all of the technical details in the GDD next week means that I can have what I want the project to be like completely cemented in my mind so that the story doesn't call for anything that could go against my intentions for what the project should look like as well as what it should play like. I would probably look into more similar games for inspiration in future projects as it could help me avoid getting creative block during production, but considering the time limit of this project I think I'll have to move on without doing this for this one.
Conducted Academic Research
I Looked At Professional Portfolios
Researched Similar Games
Created A Project Proposal
Create A Trello Time Plan
Explained The Time Plan
Week 2 Evaluation
I feel like this week has been an overall success, but I definitely think I could have done better in a few areas. When it came to working on my GDD I did amazing work, managing to write about all of the sections that I intended to write about on my Trello time planner as well as managing to do so in an immense amount of detail, even going as far to talk about the uniformity of the size of pixels as well as listing off possible sounds the game could use rather than just writing that the game should just have sound generally. These things were all very nice to log as complete, which I think was another success of this week as I did a good job in keeping track of what I have done and what still needs doing. Unfortunately that leads me onto the negative side of things, I didn't manage to get everything I wanted to do complete by the end of the week as I poorly planned the speed of replies for my primary research, this means that as I wait for answers on my forms, I'll have to come back to talk about them next week as I need this research done as soon as is humanely possible. This could have the horrible effect of eating into the time I had reserved for week 3 activities such as completing my GDD as well as researching into very important things such as what game engine would be best to use and what the best drawing software would be for my pixel art creations.
Hopefully I don't need to spend too much time next week completing work that would have (under the best of circumstances) already been completed by now so that I could work on the project more effectively by following the time planner I created more precisely. In reckon that a good way to improve my use of the time planner would be to include more empty space so that I could catch up on things I for whatever reason missed earlier in the project. This would ensure the planning, production and research of my game are as detailed and complete as possible.
Various GDD Work
Created Two Microsoft Forms As Research
Week 3 Evaluation
Week 3 was quite a difficult week, I had to change the time-plan to have more of the optional yellow segments such as for the animation and the frame-rate research, this was mostly due to bad time management which lead to me not having enough time to complete everything I thought I'd be able to do at the start of the project. Due to this weeks troubles, I'll be taking more and more off of the Trello time-plan to make my workload actually line up with what is possible for me. By not taking things off and instead making them optional, I think that I leave myself plenty of room for both going back to previous weeks to do the optional parts for further learning as well as giving myself opportunity on the week itself to either do the basic amount of work I want or to put even more effort in. Since I'm doing so much already per week I doubt that I will be able to do much if any of this optional work but I should always plan for success and prepare for failure rather than settling for the bare minimum.
Hopefully next week I can complete everything by the time it's time to start week 5, if not then I'll definitely need to look into further changes to my time plan or perhaps changing things in my personal life to better fit the project. This would hopefully allow me to start completing weeks by the time they should be done by, this would also make it much more likely that I finish the project by the deadline. This would be a major success as it would show just how good I am at game creation and so would be great for improving my skills, confidence and building a portfolio for future employment.
Finally, I managed to get my story line ironed out after trying multiple different versions. The version I settled on was the station, mostly because I thought the story was compelling due to the horror and interactivity it would allow for. It also has quite a concise story since I'm running on very limited time and need to make sure I can get my project done. I also had a peer double check my story, with them saying that it was short enough for me to make as well as simple enough to not get confused when making the story progression. I genuinely think they are correct as the game really isn't complicated and I purposely made the story in a way that I wouldn't get too confused when making it.
Thing is, now that I've completed my GDD, I don't know when I'm actually going to use it. Most peers have told me that I don't really need a GDD for a game I'm making on myself, but I made one anyways because I thought it was best to have one and not need one than need one and not have one. In the future I would probably skip the GDD and put the time towards something else instead, something more useful for getting a completed final project such as production time.
Researched Drawing Softwares
Researched File Types
Compared Different Game Engines
Completed GDD - Storyline
Completed GDD - Game Time And Location
Completed GDD - Level Layouts
Completed GDD - Conclusion
Week 4 Evaluation
Even though I once again didn't get any optional extra work done, I managed to get what I wanted to complete done by the end of the week, something which I call a major success. The work I wanted doing was done in a relatively timely manner with very little fuss of rushing near to the end of the week. I got work such as getting peer feedback on my planning, research and time plan alongside shape and colour theory done very easily. I then managed to compare programming methods alongside good file management. I have no doubt that the work I did this week will be plenty for the production to be a success in future weeks. One thing I regret is that I had the researching of blueprint types set as an optional addition for that week rather than something I really needed to get done, this decision had been made with the idea that I won't really need to use anything more than a user widget, an actor and a character when it comes to the types of blueprints in the game.
As I reflect now however, I realise that I really could have used being able to use a greater variety of blueprints as having just 3 that I know well is really limiting. Unfortunately there's no way to fix this now without losing out on thing I need to do in other weeks due to time. I'll just make use of tutorials when I need them and trial and error if tutorials are not available and I need to use a different type of blueprint in Unreal Engine. It shouldn't be the biggest issue ever but I do regret it.
Looked Through Peer Feedback
Researched Shape And Colour Theory
Researched The Meanings Of Colours
Compared Programming Methods
Researched Good File Management
Week 5 Evaluation
This week was great and terrible all at the same time, I managed to get most of what I wanted done and yet fell behind in other areas. I managed to get the character concept completed alongside completing the map concept. I also managed to create moodboards alongside managing to create the environmental concepts and making a concept monster using my main character to save on time. This was a lot of work and it's definitely something to be proud of but I missed two key parts I wanted done. I wanted to add the concept for the character to the GDD and I wanted to concept basic item sprites. The most serious issue here is not concepting the items, of which there would probably only be a candle or torch, maybe a lighter and most importantly by far a gun of some sorts, this would be used to kill the monster so I really need to ensure this item is done by next week. If I want to get this all done then I'll have to do some of the work next week to ensure I can move onto development as quickly as is humanely possible. This sort of failure, even something so minute, can eventually lead to the failure of a project due to time issues and lessened morale, something I don't intend to have happen with this project. I will definitely be making sure that my future projects aren't limited so much in production like this project. Without doing that, I feel that my future projects would risk having things missed like this one did, leading to a worse final result.
Created Main Character Concepts
Created A Complete Map Layout
Created Basic Mood Boards
Created Basic Environmental Concepts
Created Basic Concepts Of Monsters
Week 6 Evaluation
This week I managed to get a bunch of things done in the concept art department. I managed to complete the concepts for pretty much everything I wanted, as well as creating a basic map concept. The main thing that I realised this week was how my game doesn't actually need any items in the conventional sense. Making a lot of items would require a UI and inventory system which I would no doubt struggle to make. This would take way too much time as well as being very stressful for me, I've also realised that I don't need items like what I imagined as I can convey the story and have good gameplay without them. If I get too stressed then I will have to make personal sacrifices to put more time into my work and I'm more likely to make mistakes, meaning it's probably better to drop the idea out of current time restraints and consideration of what the game really needs to be fun and finished by the end of my project.
I've decided that in order to manage changing circumstances in my life to do with my free time, as well as to manage my expectations for this project, I'll be editing my time plan to more closely fit what I can realistically do. Things in my I have decided aren't needed and are just me going overboard will be changed to have a purple cover so that I know that they no longer need to be done. This will save me time and to be honest my own sanity which will allow me to focus on other parts of my programming and animating which should allow for a smaller but overall better product.
I could definitely use having a less ambitious time plan in the future, as although I'm saving time by removing things from the project, I'm also wasting time removing something that I never really had to put there in the first place. This time could have been spent making last weeks concepts that I unfortunately missed out on due to time limits.
Created Basic Concept
Finalised the main character, monster and environmental concepts
Week 7 Evaluation
This week was very successful, I turned the item sprite creation to a purple cover which meant that I didn't have to do it as it was no longer needed for my project. This allowed me to spend more time on creating the finalised character sprite, monster sprite and map layouts. My map layout will be incredibly helpful as I will be able to make the individual rooms of the station and piece them together in the game world. This is helpful as it will let me put the world together whilst knowing what happens in each area, helping me program things to fit the story as I know where things will be moving, when and what else is in the room. Otherwise, when it would have come to making the final map and putting it in UE5, I would have faced issues with piecing everything together and I could have missed including things important to the game and story because I forgot them due to not having a layout. This would have caused unnecessary stress and would have wasted my time, so my extra planning will be well worth it when I implement the map and make the final sprites for each room.
It's really unfortunate that I'm not making item sprites, but the increased quality I can get on the other spites through the extra time I have to spend on them will lead to a better game overall, as the higher quality will lead players into thinking the project was a high quality production rather than student work. In the future I will definitely make sure to give production the time it really needs so that I can ensure everything (including sprites) are complete in my future projects. This will give the games I make more variety as well as making them seem higher quality due to how much is actually in each future game.
Created finalised sprites
Finished the map layout in detail
Week 8 Evaluation
This week I made my walk cycle for my main character as well as its idle animation. I decided this week that rather than having a death animation for my character, I can just have a fade to black. This decision is due to me wanting to save time on the project so that I don't fall behind, this helps me stay motivated without causing too much damage to the game as a whole. It's generally recognised in games that a fade to black is a sort of respawn, this means that most players won't mind a missing death animation as long as the game as a whole is functional. In the future, I would definitely focus more on deaths for a horror game, I think this because most simple horror is body horror where people are killed or ripped apart, something my game is missing.
The walk cycle I made is very adequate for my game. It features arm movement, shadows, the character's face being visible, accurate leg movement and much more. This all adds to the realism of the game world and so increases the immersion of the player as they are able to associate more. I would definitely work on adding things like tripping over and making the animation smoother in the future, in order to boost this realism further, but I just don't have the time to do this without sacrificing other things from my project. If I were to animate again, I would definitely work on adding variety to the animations that doesn't look like it's repeating and isn't over the top, but still noticable and appreciatable by the player. This sort of detail would be very much enjoyed by the player as it makes the game look so high quality that it doesn't need to tell you about every detail, it just gives you them to enjoy whether you notice or not. Without variety, I feel my future games could end up relatively bland like the walk and idle I made for this one, meaning the game is unappealing to players.
Created the character walk cycle
Created the character idle animation
Week 9 Evaluation
This week was a success and a failure at the same time. I managed to get around 66% of what I wanted to do this week done, but the time it took to complete this 66% was unfortunately too much for me, meaning that I didn't have time to make a monster attack animation. Similar to last week, I think that by adding a fade to black when the monster reaches you will negate the need for a monster attack animation as you won't be able to see the monster as it fully reaches you. This is important as you can't see it not doing anything, meaning that the immersion of the game is not broken. It also keeps the game feeling high quality as you can't tell it's unfinished. Next time, I will definitely keep track of my time more efficiently by using more time planners, I could also have someone check my timeplanner and compare it with the work I have done. This would be helpful as the other person would have no bias as to how hard or easy work is, and could point out missing work or work that has issues, pushing me into finishing the work to make the game higher quality. I could have probably just asked for support from a peer when making my animations for the monster, this could have saved me time and I could have gotten the attack animation completed by using this time, this would have been better as I could have made the attack animation and so made the game overall higher quality, attracting potential players.
Created the monster run animation
Created the monster death animation
Week 10 Evaluation
This week I got a lot of Unreal Engine work done. Nothing really went badly this week apart from me not getting the death trigger done for the player. My thinking behind this is that I can probably just make that feature when it comes to it rather than making it now and probably forgetting how it works by the time I need to use it. This is a great idea as by knowing exactly how I made the blueprints for the death means that I am less likely to make mistakes and so will probably save a lot of time when it comes to the bug fixing week. I considered changing the position of the death trigger box on trello to the week after, but I figure that I may get confused and believe I have already done the work when I haven't. Doing the death trigger when the game needs it is just better for the development as a whole, with time potentially being saved and stress avoided.
The better way to make this decision would have been to get the opinion of one of my tutors or peers. This would have given me a much more well researched look into whether delaying certain parts of the production can be bad for the project or whether it would be better to do it that way.
Lots of Unreal Engine work was done
The level was made
Movement and animations were added#
Week 11 Evaluation
Week 11 was always going to be a difficult one, and I think I did really well with it. The text boxes are easily edited without me ever planning on them being so, this is amazing as it means I can save times with the production by just duplicating a speech widget, changing some simple blueprints and variable values and setting the widget to player when a speaking box is activated by the player. These speaking boxes are really versatile as they control the widget the player sees as well as where they can activate it from.
The speech as a whole was heavily dependent on UI, UI that also made a major difference to doors. I used a minecraft font from online to get the blocky letters and then in the case of my speech boxes, I had a face pop up to show the player was who was talking. This is very good as it's simple and easy to understand for the player. The more amazing bit is that I could use the different UI and widgets I made to teach the player how to play the game by adding very simple one letter commands at anything interactive. A peer said that this would be an amazing way to show how the game works without being obstructive and I have to agree, though I disagree with them not wanting to have the controls disclosed at the beginning. The controls being shown at the beginning meant that you had to explore for the position of interactables, this added mystery compared to what my peer said, but I'm fine with the change as long as my player-base enjoys the game.
Unfortunately I don't think I'll be able to implement a control list at the start of the game whether I want one or not. This is mostly due to time limits, something that if I had planned better using Trello might not have been an issue. In future projects I'll definitely have to put more emphasis on managing my time using not just Trello but other apps as time has been the biggest and by far the most limiting factor during this entire project.
Implemented speech boxes
Created basic UI
Set up story events/ triggers
Week 12 + 13 Evaluation
These weeks are very similar, it includes me making the final battle and implementing the monster. As well as this, I added a way to kill the monster and for the player to die, all very confusing work. I started off with making the monster blueprint, this mostly consisted of making the monster be there with a hit-box and walk to a predetermined position. I then made the player be able to die to the monster by making the player capsule overlap the monster to trigger a death event. After this, I made the player be able to kill the monster when it's in range by pressing F. This then kills the monster and sets off a widget about you surviving.
Overall, I'd say this was a very successful couple of weeks. The original idea was to spend these weeks doing these exact things, and I'd say I did a good job. I managed to do everything in a very timely manner and with a great deal of quality. This will allow me to move onto my future weeks work with minimal issue. It should also mitigate my need for any days near to the end of my project to do missing work or fix broken project pieces as the high quality of my node work means that it is relatively hard to break or find issue with. This should hopefully lead to an improved player experience as crashes are going to be less likely, as well as further improving the project and player experience as I shouldn't have to miss anything out on my time plan in the final weeks as I don't need any extra time making things like the final battle or triggers. I also think I did quite well when it came to implementing the things I made, the collision boxes all work perfectly and the code is relatively easy to understand once you trace the execution line. This makes the project really robust and difficult to break as it has very little parts for it to go wrong, the good placement of triggers also ensures that a player can't glitch through a door and avoid a collision box, avoiding softlocks, bugs and crashes. This is major as crashing can ruin the player experience and completely break the atmosphere. It also makes the game more likely to be bought or published by a third party, mostly because the game isn't likely to break and can be edited easily due to the low part count.
On top of this, I have managed to keep up with my Trello board updates. This has allowed me to understand whether I'm falling behind or not as well as whether I've missed something. This has and will continue to ensure that I don't miss any part of production that I actually have time to do, meaning that the project will be more complete by the deadline and is likely to not be missing anything major. This also means that I may have time left at the end of the project to improve work I've already done. This is good as it means that the game will be more polished and high quality as well as having less bugs, improving the overall player experience.
One major thing that I would add if I had the time would be a menu system. When I played the packaged game, I got annoyed at having to open task manager to shut it rather than just having a button. If I had the time, this would be a very simple and much appreciated thing to have in my game, not only by other players but also by myself. Without an exit button, the game just feels relatively unfinished and clunky as you have to force open task manager to even stop playing despite being on a still screen of a widget, something that would no doubt bother any player no matter their patience.
Created end widget
Created way to kill enemy + die as player
Created monster blueprint
Created monster walking trigger
Week 14 Evaluation
This week I evaluated the needed bug fixes for making the game playable to a high grade. This makes the game more enjoyable for players as there are less crashes and game breaking bugs, allowing the players to genuinely enjoy the game. This is important as it means that the players are more likely to recommend the game to others or replay it. This improves the games spread amongst the gaming community and so helps the game reach new players to start the cycle with again.
This week I also had people playtest the game to see if it was all working perfectly or needed fixing in some way. I was also looking forward to seeing what they had to say about the game in general. This playtesting will allow me to update the game to better fit what people want from it as well as allowing me to fix the issues people encounter when playing the game normally. This is a job for next week, but will allow me to make sure my players avoid any issues within the game and so leave the game with a positive outlook on it. This makes them more likely to share the game and so helps me make a name for myself in the gaming industry.
Finally, I made a form about what the game was like as a whole. This form will give me valuable insight for evaluating next week, letting me understand what I did well and what needed improving with my game and project as a whole. This will allow me to change how I manage projects in the future, probably letting me improve my future work and so improve its reception amongst peers and the gaming community. This is very important for people in an industry that changes every day, and so I feel that by doing this form I can make my future chances of success better.
Created end widget
Created way to kill enemy + die as player
Created monster blueprint
Created monster walking trigger
Week 15 Evaluation
Week 15 is nearly entirely taken up by the evaluation work I did. The evaluation is really important for this project as it will tell me exactly what I did right and wrong, allowing me to improve in my future work. Furthermore, the evaluation will give me much needed rest time before my next project. These 2 things are going to be very important in my progression as a games programmer as by keeping burnout low and improving my work as a whole, I can ensure that I make all my future projects to the best of my ability, incredibly improving my future project and code reception amongst both my peers and the intended client base. Other than that I just fixed a few bugs with the game. This is really important as it will prevent crashes and bugs, improving the player experience.
The improvements are also very important as I doubt I'll be making any updates to the game past putting it on itch.io or sending it to friends. This means that making the game as robust and unbreakable as possible before I call it finished is very important as a game breaking bug won't be fixed afterwards. By ensuring that the game is done, I can keep the potential players happy whilst not making a commitment to keeping the game up to date and maintained. Many of the changes I made were due to feedback from last weeks playtesting, meaning the issues I fixed were the ones most encountered by the average player.
Made the final evaluation
Did some bug fixes
Put the game on Itch.io
Released the final gameplay video