CONCEPT: Squid Showdown was meant to be a high-octane, fast-paced, party game for kids and adults alike, obviously inspired by the series Squid Game. It was developed in Unity using Photon Pun 2 for multiplayer. It supports 1-8 players. 

TIME ON PROJECT: 2-3 WEEKS

WHAT I LEARNED:  I learned how to set up lobbies as well as randomize matchmaking. I learned how to connect and authorize master clients as well as how to transfer ownership for photonviews. I learned what objects were best to be instantiated at runtime or built in the scene editor beforehand. I also learned that the funnier the better, so I incorporated silly things like pressing F to fart and being able to record your own scream which would play if you died rather than the default scream. 

WHAT I WOULD IMPROVE UPON: Squid Showdown was my second foray into the world of multiplayer game development and unfortunately as the location I was developing in had very high latency the connection would frequently drop, meaning I couldn't test a lot of features because most of the features I wanted to build utilized Photon's network for many of the callbacks and functionality. 

If I were to redo this project I would probably redo it using Photon Fusion or Quantum, as they seem to have better support and also be better for multiplayer party games of this style. I would also take my time to improve the UI and incorporate many features such as character customization and level choosing to optimize the experience for players. 

CONCEPT: A 2D-retro themed game where the goal is to pop planets and collect stars!!

TIME ON PROJECT: 1 WEEK

WHAT I LEARNED: I rarely work in 2D so for me my biggest takeaways was learning how 2D colliders work, how to use and manipulate canvases, how for the sake of efficiency of the game developers should build multiple canvases for specific purposes rather than layer a whole bunch of panels on one main canvas. SpacePop also had a more complex in-game currency: players could collect stars, moons, and points, and trying to make an efficient point-awarding formula was pretty fun (and funny). Balancing these currencies so as to not make any one useless was also a good learning curve for me.

WHAT I WOULD IMPROVE UPON: A lot of my friends said the UI could be improved, and I agree, it does look a bit shabby. I had so many ideas for powerups and different planet behaviour that I never had the time to incorporate, but most importantly I think a lot of players complained that the basket and garden in space seemed weird and off-putting. I personally thought it was stupidly cute, but a game developer has to listen to their audience after all!

CONCEPT: A 3D Endless Runner mobile game where the main runner is a beetle and the main currency is cherries!!

TIME ON PROJECT: 8 DAYS

WHAT I LEARNED: This was the first mobile game I actually planned to run ads on and make microtransactions for, so learning how to authenticate users, use AdMob & the Google Developer Console to integrate in-app purchases as well as successfully run rewarded and banner ads was a huge learning curve and a massive step out of my comfort zone. 

WHAT I WOULD IMPROVE UPON: This is a project I would like to come back to in the future but while I love the appeal of a non-human runner, finding animations rigged to a beetle skeleton was a pain beyond belief. I would probably use a human rig in the future even though it would make it less unique, and I would also probably use root motion for the animations now that I have learned how rather than directly calling the run or walk animations to play. Obviously I would also improve the gameplay and UI, but that wasn't my main focus for this short project as it was mostly to learn how to incorporate monetization methods.

CONCEPT: A fast-paced time-management co-op game for 1-3 players like Overcooked where you have a shopping list and you need to scan and checkout your orders before the time runs out. There will be NPCs that queue up and get in your way. 

TIME ON PROJECT: 11 DAYS

WHAT I LEARNED: This was my first multiplayer project so I didn't focus as hard on lobby making or matchmaking. Players could simply join the same room by typing the same string, and it was a simple 1 level game where the list of items were randomized and a check would run every time an item was scanned to make sure the correct item was bought and the global initial money the players had would be deducted from. I learned a lot however about NavMeshAgents and simple AI that would make the NPCs wander around, and random pathing, as well as how to incorporate root motion into that pathing. 

WHAT I WOULD IMPROVE UPON: My initial idea was to have the player models be ugly customizable kids, like how a kid's biggest fear is being abandoned at the store. But these kids are supposed to be naughty, so the idea was to have fun and stupid mechanics like being able to knock over bins, steal items if your wallet didn't have enough money, pickpocket from NPCs, graffitize the walls, etc. As well as a police officer penguin that would waddle around and arrest the kids if they were spotted doing anything naughty. I definitely want to come back to this concept in the future!!

CONCEPT: CATASTROSUSHI is a 2D, mobile, Diner-Dash style time management game about serving orders and pleasing customers before they run out of patience.

TIME ON PROJECT: 13 DAYS

WHAT I LEARNED: This was my first mobile game so my biggest takeaways were working with touch input, scaling for different screen sizes for mobile, as well as testing different layouts. 

WHAT I WOULD IMPROVE UPON: Honestly if I were to repeat the process now I would make a lot of improvements, from the variations of customers to the ingredients available, as well as adding sound and other versions of feedback. I would genuinely like to develop this into a proper working game one day, with my own assets as all the sprites used are very poorly rendered 2D cutouts from random google images which are not licensed in any way, shape, or form for commercial use. I think I might also use a different theme than sushi as it's been done before, as well as add different modes & challenges to spice up the gameplay. 

CONCEPT: A harrowing twist on Who Wants to be a Millionaire where the stakes get bloody. Picking the right option is the difference between LIFE and DEATH.

TIME ON PROJECT: 2 DAYS

WHAT I LEARNED: This is probably one of my least finished games, but my biggest takeaways was about database and design. This project was the first time I learned how to use SQL to design data tables and instantiate a list of questions and answers from said tables as well as save results to the tables so that they would persist across gameplay. I also learned how to design a login function as well as a salting algorithm so that the data saved would not be easily manipulated. Additionally I learned how to encode and parse XML and JSON for storage purposes.

WHAT I WOULD IMPROVE UPON: As I mostly focused on backend for this project, it's not very well-designed from a front-end perspective, so to me it's one of the least complete games I've ever done! On a redo I would definitely make it so that there are end goals and a running thorough narrative. Heheh.

CONCEPT: A top-down pseudo tower defense game about a spider queen defending her brood

TIME ON PROJECT: 3 DAYS

WHAT I LEARNED: This was a really rushed concept as I had changed my game halfway through. My main focus for this project even though I'm not as proud of it as the others, was on static classes and using namespaces as well as virtual & override methods. This was the first time I learned how to make static instances that will persist over the game even when new scenes are loaded using Don'tDestroyOnLoad methods as well as OnAwake and OnEnable methods to initialize certain functions. 

WHAT I WOULD IMPROVE UPON: This project -- even though it's one of the ones I'm least proud of, still taught me a lot especially on backend and how to organize my code and make it more efficient too. Along with Dreadcrest I would not redo it as it simply isn't a fun enough concept for me to care about. But if I did, I would firstly fix the spider's controller and animations as well as make the entire theme consistent. The spider, the eggs, and the slimes all seem to come from different artistic directions and it makes the game confusing. Also, the LIGHTING!!! my god.

CONCEPT: A short 3D horror game where you can shoot monsters. Sort of. 😅

TIME ON PROJECT: 6 DAYS

WHAT I LEARNED: This was only the second game I ever made in my entire life, and also my first 3D-game. I had no idea how to use physics or what a damn Quaternion was, or even how to make and instantiate prefabs, until I started making this. This was also the first time I played around with AudioClips and AudioSources, as well as truly writing my own specialized classes rather than very simple manipulation of gameobjects to be enabled or disabled. This is also when I started learning about rigidbodies and physics simulations as well as colliders and triggers. 

WHAT I WOULD IMPROVE UPON: This is probably the only student project I wouldn't bother to redo - simply because I have no interest in developing this concept further. However, one of the first things I would do if I had to redo this would be to fix the tiling of the texture on the walls so that it doesnt look like the player is around 2 feet tall lol. I would also make the bullet the proper rotation upon being instantiated as well as have a proper mesh. It's so funny to see I made a game where the player is shooting vertical default capsules BAHHAAH.

CONCEPT: An unknown entity has taken over your computer and you don't know why. Play and find out!

TIME ON PROJECT: 3 DAYS

WHAT I LEARNED: This was my first game EVER. I made it like a week into learning Unity and my original concept was based around a blinking cursor and nothing else, no images, no nothing. And you would have to type questions and slowly get to know the person/entity behind the game to uncover the mystery. However, because I was so inexperienced, I didn't know how to add atmospheric music, or camera shakes, or transition animations, or anything really. I still learned a lot, like how to load new scenes, what a game object is, and how to code IEnumerators as well as handle player input. 

But the biggest takeaway I had from this was not to be too attached to your original vision. The only reason why I added visuals and puzzles was because my lecturer told me to, and that ended up being a huge improvement to the gameplay as a whole. I was very salty and very reluctant to take his advice, but I learned early on that games never end up looking like what you originally intend, and new mechanics and ideas will always form along the way. 

WHAT I WOULD IMPROVE UPON: If I were to redo this now, I would make the story more engaging. The puzzles more in-depth, the desktop more personalized, and hmm...