1. Prototype and complete original games for multiple platforms following the full game production pipeline.
Game of Ketchup -
This complete game runs on your web browser using Construct 3. For pre-production, I had to decide how the cars should control, what kinds of obstacles the player will face (biggest one being their acceleration off the starting line), how many assets I'd need, and if I could include everything before the limitations of the engine's free version become a problem. I started by preparing all the art assets so I'd have a car to drive and a track to test the car on, and the first thing I wanted to solidify were the drift controls so peeling around a corner felt satisfying, easy to control, and carried a lot of speed through. At first I wanted to make the races more open and simply cause the player's speed to reduce over grass, but the capabilities of the AI in Construct aren't the greatest, so I had to stick obstacles close to the track to make the AI stay on the track. I iterated on track length and AI variables many times to make sure, as difficult as it is, that the AI could be beaten by driving good lines. But I figured in the event the player makes a mistake, they can use a boost to help gain the lead. In good arcade fashion, I designed the third track to be a real test of endurance, good lines, and making the most of your limited boosts. Some of the finishing touches were music, sound effects for UI, a car rumble, using boost, the red/green lights that start the race, and colliding with obstacles. After tying the levels together with menus, the game was ready for class.
This complete game runs on your web browser using Construct 3. For pre-production, I had to decide how the cars should control, what kinds of obstacles the player will face (biggest one being their acceleration off the starting line), how many assets I'd need, and if I could include everything before the limitations of the engine's free version become a problem. I started by preparing all the art assets so I'd have a car to drive and a track to test the car on, and the first thing I wanted to solidify were the drift controls so peeling around a corner felt satisfying, easy to control, and carried a lot of speed through. At first I wanted to make the races more open and simply cause the player's speed to reduce over grass, but the capabilities of the AI in Construct aren't the greatest, so I had to stick obstacles close to the track to make the AI stay on the track. I iterated on track length and AI variables many times to make sure, as difficult as it is, that the AI could be beaten by driving good lines. But I figured in the event the player makes a mistake, they can use a boost to help gain the lead. In good arcade fashion, I designed the third track to be a real test of endurance, good lines, and making the most of your limited boosts. Some of the finishing touches were music, sound effects for UI, a car rumble, using boost, the red/green lights that start the race, and colliding with obstacles. After tying the levels together with menus, the game was ready for class.
Mini Treads -
This complete game runs on Windows systems with a build made in Unity. For pre-production, I had to decide not only how I was going to create features like the tanks, the AI, the point tracker, but also how I could make the project stand out from everyone else in the class. That came down to extra features like making the top and bottom of the tank rotate separately, spawning in waves of enemies with difficulty options, or replacing Unity's default skybox. Production continued with modeling the tank, getting it to move, camera zoom controls, getting it to shoot with a cooldown, take and deal damage, many many tweaks for different AI behaviors, creating land tiles and random map generation, tracking score, player lives, a save system, UI, splitscreen multiplayer, audio for shooting, reloading, getting hit, dying, spawning, etc. and music, and ended with bug fixes for systems like the audio manager and hopping back and forth between scenes.
This complete game runs on Windows systems with a build made in Unity. For pre-production, I had to decide not only how I was going to create features like the tanks, the AI, the point tracker, but also how I could make the project stand out from everyone else in the class. That came down to extra features like making the top and bottom of the tank rotate separately, spawning in waves of enemies with difficulty options, or replacing Unity's default skybox. Production continued with modeling the tank, getting it to move, camera zoom controls, getting it to shoot with a cooldown, take and deal damage, many many tweaks for different AI behaviors, creating land tiles and random map generation, tracking score, player lives, a save system, UI, splitscreen multiplayer, audio for shooting, reloading, getting hit, dying, spawning, etc. and music, and ended with bug fixes for systems like the audio manager and hopping back and forth between scenes.
Destined For War -
This complete board game is playable with the printed board, cards, and player pieces. Pre-production started with a document for brainstorming ideas and it quickly turned into how well can we make an RTS work as a board game. That document became our rule sheet, eventually turned into the final version of all the game's mechanics, tracking everything the player could do on their turn, how to collect resources, build structures, what it costs to perform actions, what the abilities and stats of each class and race are, and most importantly, how to win the game. Up to four people can play, but only person can win. The rules are restrictive of many things, like the number of resources you can hold or how much damage and defense a hero or unit has, but there is also a lot of freedom, like allowing players to move wherever they want or leaving the door open to outside strategies, like players agreeing to team against the person with the largest army. While I handled the rules and balancing, the rest of the team took care of designing and printing the board and cards. The final game includes tons of pieces and helpful reminders for the player's options so they don't have to always keep the rule book on hand.
This complete board game is playable with the printed board, cards, and player pieces. Pre-production started with a document for brainstorming ideas and it quickly turned into how well can we make an RTS work as a board game. That document became our rule sheet, eventually turned into the final version of all the game's mechanics, tracking everything the player could do on their turn, how to collect resources, build structures, what it costs to perform actions, what the abilities and stats of each class and race are, and most importantly, how to win the game. Up to four people can play, but only person can win. The rules are restrictive of many things, like the number of resources you can hold or how much damage and defense a hero or unit has, but there is also a lot of freedom, like allowing players to move wherever they want or leaving the door open to outside strategies, like players agreeing to team against the person with the largest army. While I handled the rules and balancing, the rest of the team took care of designing and printing the board and cards. The final game includes tons of pieces and helpful reminders for the player's options so they don't have to always keep the rule book on hand.
2. Create and implement game elements, systems, and play mechanics using industry standard tools,
techniques, and production methods including both art or scripting/programming methods.
techniques, and production methods including both art or scripting/programming methods.
Shammage -
In early design classes, we had to follow the pipeline every step of the way for one project. Of all the papers and design choices, the two relevant to this objective is the pixel art and the papermap crafted for the purposes of what the game might contain or how it may appear, given it is developed when we have the skills to do so in future semesters. In this case, Shammage focused on design and art. The pixel art was made using Piskel and the papermap was made via a slightly unusual method, Miro.
In early design classes, we had to follow the pipeline every step of the way for one project. Of all the papers and design choices, the two relevant to this objective is the pixel art and the papermap crafted for the purposes of what the game might contain or how it may appear, given it is developed when we have the skills to do so in future semesters. In this case, Shammage focused on design and art. The pixel art was made using Piskel and the papermap was made via a slightly unusual method, Miro.
Temple Roam -
I'm quite happy with how this project turned out, both in the design of the run down temple and the blueprints that make it function. This project focused on design and programming. It all started with the temple theme that I wanted to go with, and it made it easy to add more because all I needed to think about was the things you should expect to find inside a temple. But with those additions also came additional programming implementation. The staircase that rises from the ground, the spike traps that activate when stepped on, the poison vases that harm the player over time, swapping to control a second character, the AI that protects the grounds, the runaway boulder, the doors, the button that had to be weighed down by something else to keep the door open, and the torches that all had to be lit at the end to reveal the relic, are all things that had to be figured out in Unreal's blueprint system after committing to the idea.
I'm quite happy with how this project turned out, both in the design of the run down temple and the blueprints that make it function. This project focused on design and programming. It all started with the temple theme that I wanted to go with, and it made it easy to add more because all I needed to think about was the things you should expect to find inside a temple. But with those additions also came additional programming implementation. The staircase that rises from the ground, the spike traps that activate when stepped on, the poison vases that harm the player over time, swapping to control a second character, the AI that protects the grounds, the runaway boulder, the doors, the button that had to be weighed down by something else to keep the door open, and the torches that all had to be lit at the end to reveal the relic, are all things that had to be figured out in Unreal's blueprint system after committing to the idea.
Dungeon Xpress -
This project had me do a ton of design work, mostly documentation, but it also reaches into the art of set designing levels. It took some experimentation and time to learn Unity's Probuilder, but before I got to set dress anything, I had to start white boxing. Because of the way the game is meant to randomly generate a new dungeon layout using a bunch of different rooms, we had to make a bunch of different rooms! I white boxed rooms using existing papermaps and got to set design others using free Unity art assets. I also got to craft many sound effects for the game's characters and their abilities using Ableton and real world objects.
This project had me do a ton of design work, mostly documentation, but it also reaches into the art of set designing levels. It took some experimentation and time to learn Unity's Probuilder, but before I got to set dress anything, I had to start white boxing. Because of the way the game is meant to randomly generate a new dungeon layout using a bunch of different rooms, we had to make a bunch of different rooms! I white boxed rooms using existing papermaps and got to set design others using free Unity art assets. I also got to craft many sound effects for the game's characters and their abilities using Ableton and real world objects.
Game of Ketchup -
In this project, I got to do it all: Design, pixel art, audio, and visual scripting. Using Construct 3, I wanted to go with a racing game, so I had to make the art for the cars, concrete and dirt track, the grass, barriers, cones, the lights you see at the beginning of the race that indicate when it begins, and the particles. After preparing the art using Piskel, I had to program laps, program the cars to move in a manner that was loose enough to let the player drift, program the AI to pathfind towards invisible checkpoints placed throughout the track to keep them in the right direction, and I gave the player three boosts per race to increase their max speed before the free version of Construct 3 cut me off. To top it all off, I created a soundtrack using Ableton and some sound effects for boosting, crashing, etc. using SFXR.
In this project, I got to do it all: Design, pixel art, audio, and visual scripting. Using Construct 3, I wanted to go with a racing game, so I had to make the art for the cars, concrete and dirt track, the grass, barriers, cones, the lights you see at the beginning of the race that indicate when it begins, and the particles. After preparing the art using Piskel, I had to program laps, program the cars to move in a manner that was loose enough to let the player drift, program the AI to pathfind towards invisible checkpoints placed throughout the track to keep them in the right direction, and I gave the player three boosts per race to increase their max speed before the free version of Construct 3 cut me off. To top it all off, I created a soundtrack using Ableton and some sound effects for boosting, crashing, etc. using SFXR.
3. Demonstrate effective game design practices and techniques within the project scope and context such as genre, style, platform, and audience.
Digital Sun -
In the process of making Digital Sun, many design choices had to be made before implementing anything, like determining how realistic this "simulation" should be before determining what kinds of animals the player will encounter, or how the roguelike timer would work best effecting the stats of newly spawned enemies. Actually, it all began with researching a particular genre to prepare for our prototype, and I ended up researching the survival genre because I wanted to make a survival game. The GDD was made as part of preproduction to determine if the prototype is original and fun to play. The second stage of preproduction was testing that fun level and how certain mechanics might work or not before implementing them digitally. Throughout development we received feedback from builds, completed stand ups to report our work, and completed a postmortem after each build. We preferred doing our stand ups and postmortems on video, so this link will take you to one (https://uatedu.sharepoint.com/teams/Section_SP23137/Shared%20Documents/General/Recordings/Digital%20Sun%20Week%203-20230225_201300-Meeting%20Recording.mp4?web=1) but an image has also been provided in case the Teams link eventually breaks.
To match the survival genre, many systems like thirst, temperature, and stamina would thought of and implemented. To match the simulation, almost Hunger Games style of the world, we planned on adding walls around the map that would only be recognized as walls on close inspection and have parts of textures on the map begin glitching the longer the player is alive due to the simulation they are inside failing. While working on this Unity game, the team used an agile methodology, tracking tasks in HacknPlan week by week and always ready to change plans when needed. We also used GitHub as our version control, and communicated often over Discord.
In the process of making Digital Sun, many design choices had to be made before implementing anything, like determining how realistic this "simulation" should be before determining what kinds of animals the player will encounter, or how the roguelike timer would work best effecting the stats of newly spawned enemies. Actually, it all began with researching a particular genre to prepare for our prototype, and I ended up researching the survival genre because I wanted to make a survival game. The GDD was made as part of preproduction to determine if the prototype is original and fun to play. The second stage of preproduction was testing that fun level and how certain mechanics might work or not before implementing them digitally. Throughout development we received feedback from builds, completed stand ups to report our work, and completed a postmortem after each build. We preferred doing our stand ups and postmortems on video, so this link will take you to one (https://uatedu.sharepoint.com/teams/Section_SP23137/Shared%20Documents/General/Recordings/Digital%20Sun%20Week%203-20230225_201300-Meeting%20Recording.mp4?web=1) but an image has also been provided in case the Teams link eventually breaks.
To match the survival genre, many systems like thirst, temperature, and stamina would thought of and implemented. To match the simulation, almost Hunger Games style of the world, we planned on adding walls around the map that would only be recognized as walls on close inspection and have parts of textures on the map begin glitching the longer the player is alive due to the simulation they are inside failing. While working on this Unity game, the team used an agile methodology, tracking tasks in HacknPlan week by week and always ready to change plans when needed. We also used GitHub as our version control, and communicated often over Discord.
Destined For War -
The team of this project consisted of one handling the map, one handling the cards and printing, and myself handling the rulebook. Our preproduction consisted of a document where we started compiling the ideas for our board game, including a concept for the game board, and it eventually turned into our rulebook. At the start of production, we quickly realized some things from playtesting, like how our board was too large. We kept a change log to track things that needed to change or had been changed. And we ended the project with a postmortem.
We kept constant communication on Discord and the team often discussed what needed to be improved or removed. Once we drove home the turn-based real time strategy theme, we crafted many cards for quick reference and helping players remember their options, and tried for the best balance between luck and strategy. For instance, dice have to be used for movement, but we can give the players multiple points of interest. Combat can all come down to resource management, spending to manufacture, spending to move, and spending to attack. We also liked a medieval, fantasy style with focus on basic structures and resources like stone and wood. This helped narrow down the heroes to D&D like classes and the units to D&D like races. From there we decided the mechanics and art that would best fit each class and race.
The team of this project consisted of one handling the map, one handling the cards and printing, and myself handling the rulebook. Our preproduction consisted of a document where we started compiling the ideas for our board game, including a concept for the game board, and it eventually turned into our rulebook. At the start of production, we quickly realized some things from playtesting, like how our board was too large. We kept a change log to track things that needed to change or had been changed. And we ended the project with a postmortem.
We kept constant communication on Discord and the team often discussed what needed to be improved or removed. Once we drove home the turn-based real time strategy theme, we crafted many cards for quick reference and helping players remember their options, and tried for the best balance between luck and strategy. For instance, dice have to be used for movement, but we can give the players multiple points of interest. Combat can all come down to resource management, spending to manufacture, spending to move, and spending to attack. We also liked a medieval, fantasy style with focus on basic structures and resources like stone and wood. This helped narrow down the heroes to D&D like classes and the units to D&D like races. From there we decided the mechanics and art that would best fit each class and race.
Deceptive Turtle -
This team started as a disaster when people flooded in and distracted themselves, but once they split off, the remaining members cracked down on something to submit for the game jam. We talked closely over Discord, mostly in a call, and brainstormed our idea off the semblance of ideas that had spawned before the group split. A lot of decisions were made for the necessity of keeping the project simple and having something ready to submit before the deadline. Preproduction was short, consisting of a single doc for remembering ideas before rushing to create everything in time. There isn't a whole lot in written records, but our progress can be seen in GitHub. In the end, we compiled everything on an itch.io page for others to playtest and rate the game (https://vexurayr.itch.io/deceptive-turtle). No postmortem was required, but from my experience participating in this game jam, you really want to have your team resolved ahead of time, and baseline code from other projects, like health and movement components, significantly aid in focusing on the novelty of the game.
The rough goal was shooting at enemies arcade style and deceiving the player through the enemies they'd need to fight. The arcade genre led to creating a spawning and point system, as well as another method of deceiving the player through the points system. The underwater style sparked the idea for the fast moving turtle enemy, and the more we considered it, the more it seemed like we were describing a horror game. That's when we dove deeper into Unity's 2D lighting to make the scene become darker and give the player a flashlight. This ended up tying well into the deception of the points system, making the "win" much easier to miss.
This team started as a disaster when people flooded in and distracted themselves, but once they split off, the remaining members cracked down on something to submit for the game jam. We talked closely over Discord, mostly in a call, and brainstormed our idea off the semblance of ideas that had spawned before the group split. A lot of decisions were made for the necessity of keeping the project simple and having something ready to submit before the deadline. Preproduction was short, consisting of a single doc for remembering ideas before rushing to create everything in time. There isn't a whole lot in written records, but our progress can be seen in GitHub. In the end, we compiled everything on an itch.io page for others to playtest and rate the game (https://vexurayr.itch.io/deceptive-turtle). No postmortem was required, but from my experience participating in this game jam, you really want to have your team resolved ahead of time, and baseline code from other projects, like health and movement components, significantly aid in focusing on the novelty of the game.
The rough goal was shooting at enemies arcade style and deceiving the player through the enemies they'd need to fight. The arcade genre led to creating a spawning and point system, as well as another method of deceiving the player through the points system. The underwater style sparked the idea for the fast moving turtle enemy, and the more we considered it, the more it seemed like we were describing a horror game. That's when we dove deeper into Unity's 2D lighting to make the scene become darker and give the player a flashlight. This ended up tying well into the deception of the points system, making the "win" much easier to miss.
4. Demonstrate the ability to evaluate game designs for a variety of game play mechanics, game
applications, and game genres.
applications, and game genres.
UX/UI -
My paper on user experience and user interface is a critical analysis breakdown of what components build up a user experience, how the UI is involved in that, and how UI can be done well. I leave out how a user experience can be done well because it is completely up to player preference, just like players who love or hate a game simply for its genre. But the best UI often includes motion, integrates with the world for immersion, bears elegant visuals, sticks with common tropes and patterns, has unique ways of navigating menus, and keeps as much information hidden as possible until called upon.
My paper on user experience and user interface is a critical analysis breakdown of what components build up a user experience, how the UI is involved in that, and how UI can be done well. I leave out how a user experience can be done well because it is completely up to player preference, just like players who love or hate a game simply for its genre. But the best UI often includes motion, integrates with the world for immersion, bears elegant visuals, sticks with common tropes and patterns, has unique ways of navigating menus, and keeps as much information hidden as possible until called upon.
Guiding & Rewarding Players -
My papers on guiding and rewarding players are design/mechanic discussions about successful and unsuccessful methods for leading the player towards the intended objective and keeping the player's attention. For both, I include personal experience, such as the way I became lost traveling through the similar looking rooms of Phantom Abyss or how much enjoyment I get out of skill trees. For guidance, I cover topics like more engaging interactions than an invisible wall and all the ways Dying Light subtly nudges the player to make certain decisions while maintaining immersion. For rewards, I cover the topic of motivation, the issue with games that lack depth or meaningful choices, how different games implement rewards, and how effective those rewards are.
My papers on guiding and rewarding players are design/mechanic discussions about successful and unsuccessful methods for leading the player towards the intended objective and keeping the player's attention. For both, I include personal experience, such as the way I became lost traveling through the similar looking rooms of Phantom Abyss or how much enjoyment I get out of skill trees. For guidance, I cover topics like more engaging interactions than an invisible wall and all the ways Dying Light subtly nudges the player to make certain decisions while maintaining immersion. For rewards, I cover the topic of motivation, the issue with games that lack depth or meaningful choices, how different games implement rewards, and how effective those rewards are.
Game Narratives -
My paper on the existence of narratives in video games, a design often overlooked by me, discusses multiple ways a narrative could be applied. The paper covers how narrative is relevant to the game, how it changes player motive, how important the narrative is overall, what the narrative of certain video games were, like Subnautica, including how the narrative worked to drive the player's next objective without restricting the player or forcing them to focus on the objective, what makes a story interesting, the difference between linear and open-ended, how much the player could influence the story, how the story was revealed, such as in cutscenes, item descriptions, or scripted events, and how gameplay integrated into the story.
My paper on the existence of narratives in video games, a design often overlooked by me, discusses multiple ways a narrative could be applied. The paper covers how narrative is relevant to the game, how it changes player motive, how important the narrative is overall, what the narrative of certain video games were, like Subnautica, including how the narrative worked to drive the player's next objective without restricting the player or forcing them to focus on the objective, what makes a story interesting, the difference between linear and open-ended, how much the player could influence the story, how the story was revealed, such as in cutscenes, item descriptions, or scripted events, and how gameplay integrated into the story.
5. Effectively articulate game design elements and mechanics across disciplines utilizing written and verbal communication skills.
Dungeon Xpress -
For Dungeon Xpress, I created many documents and diagrams that articulate an element of the game, such as how the Fog of War could appear as the player approaches a room. In total, I wireframed multiple UI layouts for menus and ability activation, created storyboards for cutscenes, created complete documentation on enemies and bosses with phases, attacks, stances, animations, sounds, and art references, and other documents that heavily cover game mechanics, like all of the game's consumables or all the interactions that could happen in a room given the choices involved with combat, brews, environmental destruction, and distribution of loot. For every document and diagram, there was always a step of feedback for improvements, clarification, and staying closer to the vision of the game. Not a single thing was made that an artist or programmer wouldn't eventually have to read over and create an asset or implement new functionality. The feedback made sure there wouldn't be any confusion if an artist or programmer needed information from one of my documents or diagrams.
For Dungeon Xpress, I created many documents and diagrams that articulate an element of the game, such as how the Fog of War could appear as the player approaches a room. In total, I wireframed multiple UI layouts for menus and ability activation, created storyboards for cutscenes, created complete documentation on enemies and bosses with phases, attacks, stances, animations, sounds, and art references, and other documents that heavily cover game mechanics, like all of the game's consumables or all the interactions that could happen in a room given the choices involved with combat, brews, environmental destruction, and distribution of loot. For every document and diagram, there was always a step of feedback for improvements, clarification, and staying closer to the vision of the game. Not a single thing was made that an artist or programmer wouldn't eventually have to read over and create an asset or implement new functionality. The feedback made sure there wouldn't be any confusion if an artist or programmer needed information from one of my documents or diagrams.
Art is Alive -
For this GDD, I had to break down a lot of mechanics to best explain everything I want to be in the game once production starts. If a team were to begin working on this game, both artists and programmers would need to reference the document. Art has not been thoroughly explored as the style is still up for debate, but it has at least secured the top down angle and a general description of the characters. Vast majority of the information is grouped into a category, but some parts of the document get more specific, such as camera movement in boss rooms, despawn rates, boss tendencies, and what happens when the players paint over other colors.
For this GDD, I had to break down a lot of mechanics to best explain everything I want to be in the game once production starts. If a team were to begin working on this game, both artists and programmers would need to reference the document. Art has not been thoroughly explored as the style is still up for debate, but it has at least secured the top down angle and a general description of the characters. Vast majority of the information is grouped into a category, but some parts of the document get more specific, such as camera movement in boss rooms, despawn rates, boss tendencies, and what happens when the players paint over other colors.
Digital Sun -
For this GDD, my team helped break it down into more specific categories, making it easier to find the information you seek. Again, both artists and programmers will be looking at this document, and it gives a little more for artists to work with than Art is Alive because the appearance of the game has already been considered. You can see the desire for a more realistic simulation in many places, such as explaining how we want the core UI to appear on the player's watch or the inclusion of dynamic weather. For programming, the document thoroughly explains how the player's goal emerges from survival and roguelike mechanics, plus a mix of many other systems, cooking, crafting, taking a few items with you into the next stage, and making the environment itself a threat as more parts of the simulation crash.
For this GDD, my team helped break it down into more specific categories, making it easier to find the information you seek. Again, both artists and programmers will be looking at this document, and it gives a little more for artists to work with than Art is Alive because the appearance of the game has already been considered. You can see the desire for a more realistic simulation in many places, such as explaining how we want the core UI to appear on the player's watch or the inclusion of dynamic weather. For programming, the document thoroughly explains how the player's goal emerges from survival and roguelike mechanics, plus a mix of many other systems, cooking, crafting, taking a few items with you into the next stage, and making the environment itself a threat as more parts of the simulation crash.
6. Establish collaboration, mentorship, and professional leadership skills by working with other disciplines to deliver highly polished and completed projects.
Deceptive Turtle -
In this game jam project, I got to design, program, and collaborate in an effort to submit a game in time while keeping the group on track, keeping scope in mind, and assisting whenever help was needed. After the split, everyone who stuck around got along great. I might have spent more time assisting than completing new design or programming work in order to mentor our two first time jammers, find solutions when others were encountering problems, and making sure the team wouldn't have to worry about GitHub, changing the entire project over to URP so we could integrate 2D lighting, or any other things that might slow them down. Together I worked on systems like the player's movement and shooting, camera movement and post processing, infinite background, scene lighting, the player's flashlight, and our audio manager, our other programmers handled the AI, spawning, and points system, and our designers were in charge of finding art assets, audio, and adding the UI. I made a pass over everything to make sure the project was as polished and presentable as possible, such as fixing stretched images, centering UI, and balancing audio.
In this game jam project, I got to design, program, and collaborate in an effort to submit a game in time while keeping the group on track, keeping scope in mind, and assisting whenever help was needed. After the split, everyone who stuck around got along great. I might have spent more time assisting than completing new design or programming work in order to mentor our two first time jammers, find solutions when others were encountering problems, and making sure the team wouldn't have to worry about GitHub, changing the entire project over to URP so we could integrate 2D lighting, or any other things that might slow them down. Together I worked on systems like the player's movement and shooting, camera movement and post processing, infinite background, scene lighting, the player's flashlight, and our audio manager, our other programmers handled the AI, spawning, and points system, and our designers were in charge of finding art assets, audio, and adding the UI. I made a pass over everything to make sure the project was as polished and presentable as possible, such as fixing stretched images, centering UI, and balancing audio.
Dungeon Xpress -
In this production studio project, I got to complete a lot of design work that would be used by the artists and programmers in the group, as well as work that would aid the project's future designers. The team always got a laugh out of each other, seemed like we were constantly forming new inside jokes. As designers, our primary contact was with the leads, who would inform us of everything we needed to concept and what needed to be fixed if it didn't quite fit the vision of the game. But every bit of work we designed would at one point or another be looked at by an artist, such as the art references for everything related to the skeleton dragon or what the animation for the Rogue's abilities would look like, or by a programmer, such as the document covering what every consumable in the game does, how line of sight is used for players to be stealthy, or how every enemy in the room becomes alert when combat begins. Feedback from the leads also made sure our concepts were as understandable to the other disciplines as possible. On top of the documents, diagrams, and white boxing and set designing levels so the dungeons could have more variation, I reached out about working on audio, which is something that wasn't intended to be done this semester. With the lead's approval, I created sound effects for each character's ability and action, footsteps, grunts, basic voice lines, ability select/deselect, UI interactions, and music for the main menu.
In this production studio project, I got to complete a lot of design work that would be used by the artists and programmers in the group, as well as work that would aid the project's future designers. The team always got a laugh out of each other, seemed like we were constantly forming new inside jokes. As designers, our primary contact was with the leads, who would inform us of everything we needed to concept and what needed to be fixed if it didn't quite fit the vision of the game. But every bit of work we designed would at one point or another be looked at by an artist, such as the art references for everything related to the skeleton dragon or what the animation for the Rogue's abilities would look like, or by a programmer, such as the document covering what every consumable in the game does, how line of sight is used for players to be stealthy, or how every enemy in the room becomes alert when combat begins. Feedback from the leads also made sure our concepts were as understandable to the other disciplines as possible. On top of the documents, diagrams, and white boxing and set designing levels so the dungeons could have more variation, I reached out about working on audio, which is something that wasn't intended to be done this semester. With the lead's approval, I created sound effects for each character's ability and action, footsteps, grunts, basic voice lines, ability select/deselect, UI interactions, and music for the main menu.
Carrier -
In this production studio project, I completed many programming tasks and maintained communication with the artists and designers to make sure features were implemented as described and all art made could be properly shown off and work with the features of the thing the art is for. For example, we needed a turret that could rotate horizontally and vertically, so we had to explain how the model needed to be broken up for this to be possible. As programming lead, I also got to shadow lots of my team's work, the other programmer would come to me if there was an issue, and I could always point him in the right direction or propose a solution I've considered. Frequent meetings with the programmers helped make sure we'd reach milestone goals and meetings with the other leads informed us of the state of the entire project, what was done or needed to be done, and if there were any active issues, considering solutions for the other discipline. For instance, I've worked some with the design lead to try and find a solution for Unreal's refusal to import umaps. Us programmers had a similar problem, often meeting to get our work working in the other's project. Another thing I planned on doing was recording videos for the team to learn how to use Perforce, until the server went down and we were relying on Google Drive again. Tight communication between every member in the team helped keep us aware of everybody's work and made sure nothing was missing from the milestone builds. I haven't been in a group yet where people didn't get along, but it felt like this group bonded better than in any other group project I've gotten to work on so far.
In this production studio project, I completed many programming tasks and maintained communication with the artists and designers to make sure features were implemented as described and all art made could be properly shown off and work with the features of the thing the art is for. For example, we needed a turret that could rotate horizontally and vertically, so we had to explain how the model needed to be broken up for this to be possible. As programming lead, I also got to shadow lots of my team's work, the other programmer would come to me if there was an issue, and I could always point him in the right direction or propose a solution I've considered. Frequent meetings with the programmers helped make sure we'd reach milestone goals and meetings with the other leads informed us of the state of the entire project, what was done or needed to be done, and if there were any active issues, considering solutions for the other discipline. For instance, I've worked some with the design lead to try and find a solution for Unreal's refusal to import umaps. Us programmers had a similar problem, often meeting to get our work working in the other's project. Another thing I planned on doing was recording videos for the team to learn how to use Perforce, until the server went down and we were relying on Google Drive again. Tight communication between every member in the team helped keep us aware of everybody's work and made sure nothing was missing from the milestone builds. I haven't been in a group yet where people didn't get along, but it felt like this group bonded better than in any other group project I've gotten to work on so far.