Final Major Project Evaluation
My main aim with this project was to fully test my capabilities and understanding of game-making that I have developed and learned throughout the two years I've been on this course. I wanted to make a single fully complete and playable level with at least 5 collectibles locked behind silly and dumb obstacles.
As for the project itself, my aim was to make a game that functionally works. As long as I had the core gameplay in a functional state, I didn't mind how the game visually looked in the end.
The skill/knowledge I felt I had to develop most was coding in C#, as it is mandatory to understand for making a game in Unity. There was no way around it, learning a bit of coding and understanding it was absolutely required. Other than that, I surprisingly felt confident enough in my knowledge of Unity itself and my ability to research any problems I could potentially run into.
Unlike last year, I didn't need to develop any art skills and ended up embracing my lack of skill in the game's tutorials. They were made in MS Paint and they are absolutely fantastic.
Looking over my reflective journal for each week, I think my use of the project time was very effective. I was on schedule for the whole project, and I nigh-perfectly followed the priority list I made that put in order what I thought was the most important element of my game to implement first.
If I were to do anything differently, it would be to work on it during off-days and the weekend as that extra time could've allowed me to polish the game more and add a proper ending to the game.
Conceptually, the game has changed/evolved somewhat moderately.
The protagonist, Sir Box, used to be described as a Kleptomaniac. This was changed to a Marauder after I realized it didn't line with what I imagined the character's personality to be like. Sir Box is not above stealing hats, but it is not an uncontrollable urge he has.
The game's first level was also planned to take place in a volcano. As a lot of platforming games' final stretches are lava-themed, having it be the first level would've perfectly displayed just how unstoppable Sir Box really is.
However, I also wanted to poke some fun at the grass-themed first levels/worlds too, so I ended up changing it to be an easy tutorial-esque grass-themed level instead.
Grass-themed levels are simple, unintimidating, and calm by design, which is why they generally come first in a lot of games and I'm not going to drift away from that formula. That being said, if I were to develop the game further, the volcano would be the second level as that would surprise unsuspecting players even more.
Inconveniently, the most difficult part of Unity was also the part that was absolutely mandatory: C#.
There is a reason only two of us in this class this year decided to make a game for their FMP: Coding when you've only just learned it is incredibly difficult. The project lives and dies by it. I've really never tried making/coding a game before, so this project made me realize just how much coding is required.
While I think I have greatly improved my practical skills, especially when it comes to coding--I'm not sure if I've improved my organizational skills that much. I felt I've improved a good number of my soft skills, like Time management, Problem-solving, and Resourcefulness.
Unlike last year, I did actually have a schedule--albeit an incredibly simple one. I'm still technically winging things, just in a more controlled manner. Problem-solving was essentially required, as coding is just problem-solving with extra steps. As for resourcefulness, I felt like I've used the skills in question throughout the whole year very effectively, to the point where it felt incredibly lazy.
The main character of my FMP game project, Sir Box, was modeled and animated all the way back in Unit 9 when we learned to actually model and animate in Blender. I was essentially preparing for the FMP the whole year just to give myself a massive head-start in production.
As for the final outcome, I'm unsure how to feel about it. The game is mechanically developed and actually playable so in relation to my goal of having a short and playable level, I am quite happy. I was even successful in implementing controller support.
However, the gameplay itself is unbelievably short--maybe only around 3-5 minutes max. The player and enemies don't have actual means of attacking as they run on Mario logic. There is also one corner of the map that has literally nothing, which just sucks.
The final outcome also has no options menu. This stings a lot, as a robust options menu is vital for accessibility--one of the major factors I tried to consider during production. At the very least, the game can be paused.
As for the themes and ideas I initially set out to convey, the game doesn't really convey them at all as I never got to implement NPCs or cutscenes to show just how much of an unstoppable antagonistic hat-lover Sir Box really is. The final outcome, presentation-wise, pales in comparison to my previous year's FMP as it lacks any cutscenes. It does show hints of the ideas I had though, like how his house is literally just himself.
Honestly, I think the game sucks. That being said, I'm unsure of the validity of my own opinion as I am unsatisfied with basically everything I create--especially when I compare it to another solo-made game like Cave Story (which is incredibly good).
The response from those who have played my game has been generally positive. Even during development, I got quite a lot of informal positive feedback from people who've playtested it.
However, the game does have multiple faults. First, the UI is underdeveloped, as the player's health is directly represented by a number. While this does allow for more strategic use of Hat-Tastic Mode, there should've been a visual to go along it.
Next, the game just abruptly ends with "You Win" text, along with extra text stating I ran out of time to make an ending. Some found the extra text to be an amusing self-aware jab, while others found it to be too honest as it makes the game feel more unfinished.
While I do agree with all the feedback from those that are actually constructive/useful, I still feel like I'm the only one who has a different opinion on the overall game. I don't know if people are hiding their constructive hats from me, or if I'm being a little too pessimistic for a first-time college game project.
I've seen game jam games and funny side-project games be made by only a single person, in less time, with significantly more content--even from people who initially had little to zero experience in game-making or Unity.
Based on everything I've done during my project, I think the most valuable thing I learned was C#. Even if Unity ends up being the only useful application of the programming language for me, I now know that I can actually learn a bit of coding when given enough time. I went from zero confidence in coding to only very slightly, which is not much--but it is an improvement nonetheless.
If I were to do a 3D Unity project like this again, the practical and soft skills I'd need to improve further are C# coding and Creativity. C# is obviously outright required, so any improvements in my understanding of it are always a plus. I experienced multiple creative blocks during level building, which resulted in 1/4th of the map being unused so improving my creativity would ensure I have fewer creative-blocks
Ok, so I might've lied in my reflective journal when I said I was done with the project itself.
However, a game like a 3D Platformer is best played on a controller, and not having support for it is absolutely criminal. A keyboard/mouse wouldn't be practical for an exhibition regardless.
Unity has both an old and new input system, and I've been using the old system until now. Controller bindings were working in play mode, but not when the game was actually built. I tried researching as to what causes this, but there are actually no forum posts or anything that both ran into the same problem and had a solution for it.
This meant I was forced to switch to the new input system, which is annoying as I now had to go back into every script and replace every line of code that looked for button presses as it uses a different function.
- Artificial Grass / Terraforming.
The table will be covered with fake grass to replicate the Grassy Grassfields of Grass level.
Shouldn't be hard to find and buy. - Miniature Trees.
It would compliment the grass perfectly. That being said, where would I even get these? Maybe I can buy some in bulk or something. - 3D Cardboard Figure of Sir Box wearing a real Top Hat.
Sir Box is literally just a box and four rectangles, so making a 3D cardboard figure of him should be relatively easy. As for his hat, I plan to have him wear an actual top hat. This does mean I need to keep his scale into consideration, however, so he isn't too big or small.
The art department should have more than enough materials to make him. - Actual Hats. A lot of them.
Why not, right? Bring in a number of random hats and place them around the area. Players can even wear one while they try the game out if they feel like it. - Balls painted to look like the (:D) enemies.
I have no clue how I'll do this, but I want to include small balls painted to look like the smiling enemies. I don't know what the material will be, and where I can find them. I consider this to be low-priority, and will only do it if I have nothing else to do. - Wanted Poster
As my space is in the corner, I have some wall space and I want some way to convey the fact that Sir Box is effectively the antagonist. A wanted poster of him should show that quite nicely. - Top Hat Cake
Yes, an actual, edible cake. My father (supposedly) has some experience in cake-making, so I thought it would be neat to bring in a cake for the exhibition. The shape of a top hat is fundamentally quite simple too, so it should be well within the realm of possibility. My family has a tradition of making a farewell gift for teachers anyway, so why not?
No comments:
Post a Comment