https://www.trevortorresdesigns.com/programming daily 0.75 2025-09-22 https://www.trevortorresdesigns.com/programming/protectthecitadel monthly 0.5 2021-05-18 https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621377870238-U0NX399YODY5IOU1020J/PTCShotgunEnemy.gif Programming - Protect The Citadel - Once adding the new functions and bugs, I moved on to the next task which was another enemy type. The type I worked on next was the Shotgun enemy, where the enemy would need to get closer to the player than the basic enemy and would shoot a blast of spread out bullets. This enemy ended up working very well, as the only major change from the basic enemy was shooting more bullets and at random angles. To make sure these bullets were not too random, experimented with the angles at which would be reasonable for the distance between the player and the enemy, to avoid bullets flying straight up or down. Afterwards, I moved right along to the next and final enemy type, the rail gun enemy. This enemy ended up being a more powerful version of the basic enemy, by increasing their shooting distance, speed of bullets, and power of bullets, these enemies became the strongest enemies to fight. I rebalanced them to not be as strong, as the randomized enemy spawning cause some instances of a large amount of enemy rail guns to appear and kill the player very quickly. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621377930248-C1VM0J4RO29E0UWY9TDJ/PTCPlayerMachineGun.gif Programming - Protect The Citadel https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621377753626-GQ4RV9FWHR7M6BTVD2LP/PTCEnemyServerAttack.gif Programming - Protect The Citadel - At this point, we had our first playtest and got lots of good feedback about some issues and bugs that would need to be fixed for the next playtest. The bugs involved enemies shooting through walls and enemies shooting from above or below the player. The fixes for these were simple, by making it so that bullets would be destroyed on contact with any other object and I made a function where the enemy compares their Y position to the player's Y position and if they are not within a certain range, they cannot fire at the player; this was to prevent the unfair feeling of enemies being able to shoot vertically but not the player being able to. Once fixed, I moved on to adding a function where the enemy has a random chance to drop an item, a health box or a weapon, when defeated, which went smoothly. The next big step was adding a function that made some enemies move towards servers instead of the player. The biggest hurdle I had to go over to accomplish this task was making sure that if one enemy is already in a server, then another enemy cannot go towards that server and instead chase the player. This was more challenging than the other due to me needing to access, read, and understand the other programmers code, as they were the ones who worked on the server code and mechanics. However, after communicating with them and clarifying certain parts of their code, implementing checks between the two went smoothly and accomplished the goal very well. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621377711591-UZS89ECNJNGBLRX86B1J/PTCMachineGunAI.gif Programming - Protect The Citadel - After fixing the NavMesh and AI issues, we now had access to a system where, hypothetically, any object could be used to chase the player and attack them. With this, I moved on to adding more enemy types to give more variety and challenge to the player when going through the levels or capturing servers. The first enemy type was a machine gun enemy, where the enemy would "rev-up" their turret and then shoot a certain amount of bullets, before needing to reload and repeat the process until the player was out of reach. Using the basic enemy as a base for the new one, I used most of the tracking and NavMesh code while changing the enemy shooting mechanic to have something similar to the intended design. I coded the mechanic to also be ready for future use for the player, so when the play does use the machine gun enemy, it will behave similarly to the enemy's gun, although at the time the task was for the other programmer, so I did not end up polishing up as much as I would have for the player in the end. Allergy Season Gameplay https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621377474177-DS0N3GSW8S40ILJISPTS/protectthecitadelbanner.png Programming - Protect The Citadel https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621377636171-ML6YLFZ9IVALQKPQLCFX/PTCEnemyAiRampFix.gif Programming - Protect The Citadel - The next step I took was to refine the enemy behavior once they were in shooting distance. I was tasked to make it so the enemy would stop in place, but the turret on top would rotate around tracking the player and shooting if in range. I knew that once the player was out of range that the enemy would need to readjust their position to chase the player properly, so I added some code that rotated the turret back to its original position and then rotate the whole enemy towards the player to continue chasing them. After refining the enemy AI, it was time to implement the NavMesh into the first iteration of our level and tune up any areas or AI in the level. Snippet of the gravity power up code https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621377584729-E54ZYJXR7PKTJ33GBJPO/PTCEnemyAINavMesh.gif Programming - Protect The Citadel - For this project, I worked as one of the two programmers, coding mainly with enemy AI and working with the other programmer when the enemy interacted with the player or servers. We started out by making paper prototypes and getting the basics for the mechanics of the enemy AI done. Once finished, I moved on to testing out the best way for the enemies to chase and attack the player, as the levels would have buildings and obstacles that could potentially break AI logic. I decided to experiment with the Unity NavMesh feature, where enemy pathing would be calculated to find the most optimal path towards a certain point, while avoiding any walls or buildings that would interfere with the AI. Snippet of touch code for mobile https://www.trevortorresdesigns.com/programming/allergyseason monthly 0.5 2021-05-18 https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1620952805303-686C84TSHYJB9Z7TGSWN/AllergySeasonGP2.png Programming - Allergy Season - Once we got our core gameplay made and tested with positive feedback, we decided to work on adding more features, such as power ups that would give more choices and variety in the game. I created all of the power ups and made their own spawner to separate their spawn rate with the good and bad allergens. We decided to make a slow time power up, where the allergens would fall slower for a few seconds and then go back to going fast. This was a hurdle for me, as the speed of the allergens were based off of gravity, and making the allergens slow down required the gravity to be reversed multiple times its original speed. By keeping the data of the gravity before the power up is activated, I was able to make the power up slow down the allergens by reversing the gravity fast enough to have them stall in place for a moment and switch back to the original gravity making the allergens speed back to normal once the duration ended. Allergy Season Gameplay https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1620951412561-00DPFOL195WWQJEJHY27/AllergySeasonScript1.png Programming - Allergy Season - I programmed the spawning of the allergens, the effects the good and bad allergens had when interacting with the nose, fail safes incase the spawners or allergens glitched out of place, a score and lives counter and manipulated the gravity to increase as the score increased. Originally, we used a timer with our score, however, we play tested with people and noticed that would aim for higher time than higher score and would push all of the allergens away, good and bad, so we decided to remove the timer to encourage getting more points over surviving for a long time. Snippet of the gravity power up code https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1620949819507-507TND9TWYMORVLQY1EF/AllergySeasonScript2.jpg Programming - Allergy Season - I coded the touching mechanic to create a ball that expands relatively quick and pushes the allergens away, to the sides, or towards the nose allowing players to interact with the allergens. Originally, there was only one ball and it would change position to where the player touched, but I fixed and adjusted the code to make a ball spawn where the player touched, allowing players to touch multiple areas without removing the effects of other inputs. Snippet of touch code for mobile https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1620953250697-AV78YTMY7HRXA9KIR9VD/AllergySeasonGP3.png Programming - Allergy Season - Make it stand out Whatever it is, the way you tell your story online can make all the difference. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1620952946187-8891HT2JB9HDYGG4PJBB/AllergySeasonSnot.png Programming - Allergy Season I also implemented many assets to emphasis visual feedback, such as: the nose changing colors when hit by a bad allergen and particle effects when the player touches the screen. We planned on adding more features, as well as more power ups, once our core game was polished, and we wanted to have a local leaderboard to encourage re-playability through competition. Many play testers appreciated the leaderboard I created and would show off to other players their scores. I created more power ups such as snot allergen that would create a giant "booger" and push away all of the allergens to give the players a small break in the game without ruining the flow. There was a power up that ended up being cut as it had a problem of interrupting the flow of the game severely. This power up would stop all of the allergens in place immediately, but players would be able to push them left or right to reposition them once the power up ended. This power up, unfortunately, caused the allergens to keep spawning, thus piling on top of each other, making it more of a punishment than a reward. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1620937033512-SN1ZGGIR7FMT8429021S/AllergySeasonIcon.png Programming - Allergy Season https://www.trevortorresdesigns.com/programming/spacejunk monthly 0.5 2021-05-18 https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621378202563-HXP0KYUAGFXA2226Y4HP/Title+space+junk.png Programming - Space Junk https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621378248978-BJKBXJ74CD8US9CW4TQK/combat+2.png Programming - Space Junk - I coded the ship’s movement system in Unity to act as if there was no gravity. This movement also influenced how movement and mechanics worked in the paper prototype to test if it would be enjoyable. I was able to make the player able to shoot bullets and attack enemies and obstacles. Also implemented a player upgrade system, by increasing their damage when they receive an upgrade. Implemented an inventory for these upgrades. Snippet of touch code for mobile https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621378303982-A7N9G8CNIPW842CPEZDN/space+junk+shield+upgrade.png Programming - Space Junk - I created a mini map to show where the player’s position in relation to the map and implemented visual health bars on enemies. Coded so that player gets hurt from walls when crashed into and from enemy fire. Finally implemented a shield power up, where it protects the player from a shot from an enemy ship and regenerates after a while. The more shield power ups that player gets, the faster the shield regenerates. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621378273738-RTWDPPEUWRL690EHQERZ/space+junk+enemy+ai+script.png Programming - Space Junk - I coded enemy AI, scene transitions, a boost/dash movement mechanic for the player. The AI tracks the player only when they are in a close enough range or if the player shoots them, as well as making the AI shoot at the player. If the player gets away from the AI, it will stop following them. The distance can be changed for both tracking and shooting, as well as their speed and turning speed. I programmed the enemies to be able to drop upgrades when defeated. I also implemented a death loop, where players keep the upgrades that they had when they enter the next level, and if they die and restart that level, they keep the upgrades they had when they entered the level. Snippet of the gravity power up code https://www.trevortorresdesigns.com/level-design daily 0.75 2025-09-22 https://www.trevortorresdesigns.com/level-design/thelastember monthly 0.5 2025-09-22 https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621553375872-8AC07QYL4GPZ9R44FE13/title.JPG Level Design - The Last Ember https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621559379604-DIV8S2D0XK7GXU7AGZ7Q/gameplayLevelTrick.JPG Level Design - The Last Ember - The development of the project started with a brainstorming exercise with all of our developers, thinking of a game that would fit well with the theme of “Lost and Found” and could be in the scope of a 48 hour development cycle. We eventually came across an idea of light being a core mechanic of our game, where players would need to be careful, as danger could lurk anywhere in the darkness, and by using their light to plan accordingly. We all really liked this idea and believed that it would fit our scope, thus, we submitted it for the Global Game Jam and where I took up the role as Game Lead and Level Designer. Snippet of touch code for mobile https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621557723717-P4IULFDOCYTOJO013CAC/FinalLevel1.JPG Level Design - The Last Ember - The final area (left) of the first level was a more natural area, where it is not an obvious “pick-a-path” layout and allows players to interweave through the different pathways. This is the “final test” of the players skills from the maze area to navigate and find out where the last torch and the exit are. This area allows the player to interact with the enemy AI behavior to see if they are able to outrun, outsmart or outmaneuver them, which our players after submission found quite enjoyable. We decided as a group to make the end very visible and obvious so that players would not reach the end and be fearful that there are more enemies ahead. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621556963569-OLZNW5UOSV8P0UGVG4ES/blockoutLevel1.JPG Level Design - The Last Ember - The next area (right) is for testing the player’s new found ability by presenting multiple paths, where one has an enemy and the other does not. While this may seem unfair and the player must guess which path is right, it will allow players to interact with the water droplet enemies, whether they run into the enemies themselves or discover them with their friend embers. After navigating to the end of the maze, they receive another ember friend and are able to open the last area of the level, however, this area also acts as a test to the players memory. If the player remembers the paths they went through, they can avoid being attacked by the enemy droplets and reach the next area. One thing I noticed was when the player returns from the maze area and they do not touch the first torch, they will respawn back at the maze torch. I wish that it was explained in the game that the torches can be “re-activated” to change respawns. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621559710461-XSB0T18ONVR2Y9KQGZYZ/level3Hearth.JPG Level Design - The Last Ember https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621555616312-JLUJD90RSFS91C3T7U1H/TheLastEmber_Level1.png Level Design - The Last Ember - Since I was also one of the Level Designers, I created an annotated map for the first level that would act as a sort of tutorial level to introduce the player to this game. The first area (center) is to make sure the player would start in a safe environment to get used to the darkness around them and the controls of the character. Once they reach the first torch checkpoint, they will be able to accomplish two things: They can open the door to the next area once comfortable and they can send out a friend ember to scout ahead of them. One of the benefits of our focus on darkness and limited visibility was that I was able to focus mainly on just the layout and pacing of the player. Although, I did not want to accidently have our level look repetitive, so I spent a lot of time making sure that our rock assets were placed and adjusted distinctly enough so that players would not be confused by seeing two very similar rock structure placements. Allergy Season Gameplay https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621557750878-A5PVU6U33UK7LZI64GXM/TheLastEmber_Level3.png Level Design - The Last Ember - After finishing up the first level, I moved on to working on the third and final level, where I wanted to take the design differently than the first one. I wanted to give the players a “trial-esque” level, where the player is given three choices and is able to complete in any order the want to. This allows for players to try out one and can move on to another if they are tired of failing the same challenge. This is different than the other levels, as those had a more linear approaches to finding the exits, where as in this level, the player can already see their goals, they just need to reach them by going through the different challenges. The challenge to the left is another maze area, however it has tighter corridors, enemies right around the corner, and a more complex design, making the player use their embers more often to make sure an enemy will not attack them right away. The challenge below is another maze-like area, however, instead of walls, their are pits with enemies inside them to destroy the player, however, due to the strength of the player’s light they are able to see these holes easily; I would have changed this to have “illusion” blocks where the player would fall in the pits but would look like the ground was normal, making it so that the players must use their friend embers to see where they fall or delete the illusion block when an ember touches it. The right challenge can be considered a sneaking maze or a speed maze where the player must get through a lot of enemies without “waking” the droplets up or run towards the torch before they get attacked. For this area, I specifically increased to the speed of the enemies to prevent players from simply waltzing through the area without any fear of the enemies actually reaching them. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621553485782-RAG0Q0U3VE41S1S2WXAO/gameplayLight.gif Level Design - The Last Ember - Make it stand out Whatever it is, the way you tell your story online can make all the difference. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621557778564-HXEAW0D7CNC7P6Q9AKMG/FinalLevel3.JPG Level Design - The Last Ember - When the player activates all three torches, they are able to open the main door where they started and reach “the hearth”, where all of the player’s missing friend embers are. This place was meant to be a mysterious and almost sacred area that the player has finally reached. When first entering, the player can only see so much, but once the hearth is activated, then they see how big it actually is. As a reward for the player getting to the very end of the game, I made it so that the hearth would give the player over 100 embers to throw around and see the level with a lot of lighting. However, there was a bug where the players’ max embers were tied to how many torches they have touched, so if the player threw too many embers around before opening the final door, they would not be able to open it and would be unable to complete the game. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621555290920-1T5V765RPOVCWU7N0JFP/gameplayEnemy.gif Level Design - The Last Ember - As Game Lead, I really wanted to make sure that the light and dark ambiance was the focus of our project and to have that part made first, so that we could iterate and adjust it as soon as possible. When iterating on the lighting, I wanted to make sure that the player would be able to see their general surroundings clearly, but only see the rest in a dim light, making it hard to see what is ahead of the player. The reason why I wanted the player not to be able to see far ahead was to incentivize the player to send out their “friend embers” to scout ahead and light the path for them, giving the players a feeling of unease or uncertainty, but with the tools to help alleviate it for a moment. These friends would appear after interacting with a torch checkpoint, which respawns them there if they are attacked by an enemy, and stacks more embers the more torches they interact with. Snippet of the gravity power up code https://www.trevortorresdesigns.com/level-design/trapped monthly 0.5 2021-06-21 https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380920576-A5BI0P0MC2Q8P9I8GGQZ/L1P1NewWallDeco.jpg Level Design - Trapped - After fixing the colliders, I was tasked with designing my last level, the large level. After seeing the feedback about the levels being too easy, I decided to make the large level more difficult than I was originally planning. Once I observed how the enemy AI acts, I decided to make the pattern have less free room and make them single lines with multiple paths to allow players to out maunever the enemies, but would still have the fear of being sandwiched. I also wanted the player to defeat enemies more rather than just avoid them, which was one of the reason the levels were easy. In response, I placed far more turrets that would be place in areas that would cause the player to either find a different path to the button or something to be cautious when slipping through the bullets. With the large amount of paths, the difficulty of the enemy and turret enemies, and the large size of the level, the game designer and producer were extremely pleased and really liked how it looked. Once approved, I moved on to blocking out the way I did to fix the colliders and then added my assets in the same way I did for the previous levels. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380701468-7J0V4K4B5H09SUS4D6I6/Trapped15x15Level1BlockOut_1_Torres_Trevor.jpeg Level Design - Trapped - My plan was to start from the smallest and finish with the largest, as I thought it would be a good way to get an idea of what would and wouldn't work without having to make a lot of changes if I were to start on a larger level. Knowing that every side would be the same on the cube, I knew that symmetrical design would be the most effective way for implementing the levels later on and would look the most maze like. With the symmetrical design in mind, I designed only 1/4th of a side and then duplicated three times to fill in the rest of the side to get a perfectly symmetrical pattern. I also made sure that the player had some room for movement, as the small levels would be the first levels and I wanted them to provide challenge but be lenient with the amount of room the player could maneuver around. This design would change for the medium and large levels, as they are suppose to be the harder levels. After approval from the game designer and the producer, I moved on to add in the varying enemies and power-ups on each side. For the first level, I focused on enemies approaching the player once they enter the room, to give the player time to react and plan accordingly. However, this became problematic in practice when I realized that the players, hypothetically, could enter from behind, giving them no time to react or plan if they entered on the "wrong" side. This idea was scratched and instead, I put the enemies closer towards the middle or closer to the edges of the map, to evenly place the enemies if they were to enter from any side. After approval of the finished annotated map, the next step was blocking out the level in Maya. Snippet of the gravity power up code https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380876245-KAJ5AC0SOOS2LVKGZD9W/Trapped25x25Level3Small_Torres_Trevor.jpg Level Design - Trapped - At this point, we were getting feedback on our most recent build and there were issues with some levels being far to easy and player clipping out of the level. The level designers were tasked to play test our first levels, as they were the only ones functioning at the time, and discover the reason for the clipping issue and to fix it. This took a good chunk of the sprint, as we also were consulting the programmers who also worked on the levels to try and see if the issue had something to do with the scripts. After multiple tries of testing, I discovered that the player was clipping through due to how the colliders on the walls were being implemented. The programmers used a mesh collider, which is not as reliable as a box collider. Another reason I found was that the "speed" upgrade made the player so fast that they would easily clip through the mesh collider for the same reason stated before. Knowing what the issue was, I went back into Maya and reorganized how the walls were grouped together and combined. To make implementing the box colliders as simple as possible, I combined and separated the wall pieces to be only squares and rectangles instead of just combining every wall together as one object. This reorganization was able to add the box colliders in Unity easily and would also automatically overlap each other, preventing wall clipping, due to how they were combined, which worked out great. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380588930-1ISQPSU8NO7H1V4K7KPN/trappedBanner.png Level Design - Trapped https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380648822-0Q479DKVWDFY4PTJC6QQ/Trapped15x15Level1v2_Torres_Trevor.jpg Level Design - Trapped - During this project, I was one out of the three Level Designers and was in charge of designing three levels with varying sizes. These levels were divided into three sections: small, medium and large. Our game designer emphasized on the idea that each cube will have the same maze pattern on each side made by each of the programmers, meaning that we were tasked to make a total of three maze patterns and repeat them six times. The catch was, different enemies, power-ups, pick-ups and switch placements would be different on each side giving the player variety on each side, while keeping the patterns the same. The player would advance to the next level if they push every switch on each side, besides the top side, and must navigate each side. With our tasks laid ahead of us, each level designer was given one level from each size, and tasked to design, annotate, block out, and implement them into the game. The player would go through the three sizes and the game will randomly select one of the three iterations of the levels we made, meaning the player can either get all three levels of one level designer, get one level from each of the designers, or any other mixture of levels. Snippet of touch code for mobile https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380736662-9LA090XIK82R6WRZ0B9V/Trevor_Level2_19x19_Trapped_v2.png Level Design - Trapped - For blocking out in Maya, we used modular wall pieces created by the 3D art team members and would place these pieces on an already sized cube. This way, each level was exactly the same size and us not having to worry about other level designers making slight differences in terms of size. Similar to how I annotated the level, I blocked out only 1/4th of a side and would then duplicate and fill the rest in, then duplicating the sides and adjusting them accordingly to match on each side. The process went smoothly by having the pieces fit perfectly in almost any variation I put them in. Once complete, I exported the object out and was ready to implement them into Unity. Allergy Season Gameplay https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380777596-Z6A0JLEC7AUF6FQX0HRG/L2P2Assets.jpg Level Design - Trapped - While waiting for the programmers to make the level functional, as they were tasked with, I moved on to the next sized level, medium sized. For this level, I wanted to design not as free-flowing as the previous level to make it more difficult. I made the flow of the level to be like a figure-8, making the player having to make turns left to right and vice versa, and the pattern turned out almost like an hourglass. This level is not as symmetrical as the previous one, but it still has the symmetrical exits being in the center on on each edge of the pattern. Enemy placement was more lenient than the previous level, as the level was not perfectly symmetrical, it allowed enemies to be placed in many more different spots that would not cause frustration or a feeling of unfairness. The medium levels also receive another enemy, a guard who follows and attacks the player if spotted, which allowed a great amount of through into the enemy placement with the bigger space to work with in the medium level. With these extra obstacles and unique enemy and power-up placements, the game designer and producer were pleased and approved of blocking out and implementation. These next steps were very similar to the previous level of duplicating the sides to be as effective as possible and then adding assets with unique patterns to help differentiate each side. Once finished, it would be sent to the programmers for functionality. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380952247-P81E9DE8752W7W1OMDGZ/L3P3NewWallDeco.jpg Level Design - Trapped https://www.trevortorresdesigns.com/level-design/elementalist monthly 0.5 2021-05-18 https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380065433-WYSG10YZK0TU7OYT3Z6G/LostSandsHubAnnotated.jpg Level Design - Elementalist - Designing the hub room took a couple of days to get right, as it is the first room the player sees in this level, and I wanted to make sure that it set the mood right and immediately show the new mechanic that makes it unique to the other levels. Our game designer requested that the door to the next level be set in the "hub" room of our levels, and that they would need four key parts to move on, where each key part would be in each room, except the "hub" room. So, once the players spawn in, they would notice the door right away and that they only way down is through this new platform that looks like it is moving. Once the players experiment and go down, they will notice that they start sinking, right here is when the player will either try to get out of the sand or sink through to see what happens. Either way, the player will learn the new mechanic by their own decisions and actions, which is something our game designer greatly appreciated. The "hub" room leads to two paths, however, most players will be directed to the right, as the previous level somewhat conditioned them to go only left and right, and the players will need to break this conditioning once they go through the right side path and come back with only two key parts. Once the players experiment and go down through the second set of sand platforms, that is when they understand that there is more of the level. Snippet of the gravity power up code https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380039036-Q0SGGOEMKAZ137CIU8P9/LostSandsLayout2.jpg Level Design - Elementalist - I was the Level Designer and I was in charge of designing levels for the second world, which was the Lost Sands world. The game designer really wanted to have the levels have multiple paths and ways to try out the players individual abilities, and so my task was to create something that would guide the player to the next room, but also let them explore and try different ways to get there. I was also tasked to introduce, teach, and test the players with a new mechanic, the sinking sand, that would slow them down and make them sink down through the platform. Our levels were to be broken down into five rooms, the hub (where the players start), two platforming focused rooms, and two combat focused rooms. This breakdown would allow players to not be overwhelmed with having to attack and maneuver around platforms at the same time. The first level in Elementalist was somewhat linear, only have the rooms in a single row, so I wanted to add in some vertical structure and organized it so that the players would need to go through rooms that went up, down, left, and right, in order to progress. Snippet of touch code for mobile https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621379970216-6W1G2ZRPLX32WEZWWZFX/Elementalist_Poster_lite2.jpg Level Design - Elementalist https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380186036-681THDCQY8QXWHWGPJIL/LostSandsBottomCombatFinal.jpg Level Design - Elementalist - Both of the combat rooms at the very bottom and very top of the level were the most difficult rooms to design, as they focused on the enemies of the game, but the mechanics of the enemies changed in the the design as development went on. It made it difficult to test the rooms in terms of challenge versus ease, as the enemies were still being developed or fixed due to a bug or two. When initially designing the levels, however, I knew that I wanted the player to have the "upper hand" in one room and the "lower hand" in the other, making them parallel between each other, but separated far enough to not feel like the same level just reversed. Different strategies are implemented when having the upper or lower hand, as the upper hand room gives the player the freedom to choose where they want to attack at any time, whereas the lower hand must wait for the right moment to strike in order to not get hit and lose. Both rooms are mostly symmetrical, having a small adjustment to the other to keep variety and not confuse the player as to where they are. As I said earlier, however, enemy development took a while, and I was not able to test out and refine these rooms as much as I had hoped to and many last second changes to avoid cheap feeling enemy placements, platforms that would get too much in the way of the player, and adding sand platforms to help the player defeat the enemies effectively. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380225076-QFSYIMB7VARH5KVOWH2C/LostSandsTopCombatFinal.jpg Level Design - Elementalist https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380111754-L8A7VSVVJIWVPIIKWW2S/LostSandsPlatformingRightV2.jpg Level Design - Elementalist - The room to the right of the hub room was a platforming room, allowing players to try out different ways to jump, wall kick, and dash around to try to get to the next room, which lead upwards. While designing this level, I was in the mindset that every character had some sort of dash ability, meaning that vertical jumps were possible for each character. However, when getting close to finishing the annotated map, I talked to some programmers, who informed me that one character would not have the ability to dash, but instead the ability to dig underground and to make sure that the levels were designed to allow all characters to advance through the rooms. So I went back to the design and made some adjustments and, essentially, split the room in two, one part being the other players would could dash well, and the other being specifically for the character that could not dash. To compensate the character would could not dash, I made a route that only they could get through, by digging under a crack. This path would get to the key faster than the other characters and was less dangerous. Allergy Season Gameplay https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621380137476-RKVMEMQK47ROSKGG0QWX/LostSandsMazePlatformFinal.jpg Level Design - Elementalist - For the room below the hub room, I wanted it to be unique in that it was not just a generic jump from platform to platform and do not fall room. I thought that having a maze like room would work well with the sand platforms, as their textures would be moving, causing a bit of misdirection from sand moving one way, but the exit being the other way. When first designing this room, it started with having the player start on one side of the room depending on which sand they fell through in the hub room, left or right. One problem that I could not fix at the time was having a way to incentivize the players to try going the other route rather than just the route where the key was. However, during development, the programmers made a mechanic where the player would need to activate a switch that looked like a torch to open a door that led to the next room. After seeing this, I went back to redesigning the room to incorporate it so that the room was split in two, however, the exit was blocked but connected to the other side of the room, making it so that the players would need to go to both sides of the room to progress, one to hit the switch, and the other to get the key part. https://www.trevortorresdesigns.com/contact daily 0.75 2025-09-22 https://www.trevortorresdesigns.com/home daily 1.0 2025-09-23 https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/1621553375872-8AC07QYL4GPZ9R44FE13/title.JPG Home You are a lost, tiny, flickering flame in a pitch-black cave surrounded by watery enemies that wish to extinguish you. You are The Last Ember. In this stealth exploration game, you will be tasked with finding all your ember friends and reigniting the hearth. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/e8091cba-c513-45b3-a139-165a90501f0d/trappedBanner.png Home Trapped is an isometric rogue-like game where the player has been captured and must break out of an inter-dimensional prison. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/48c630fc-4e81-4744-a3bf-ae06dc233f9a/Elementalist_Poster_lite2.jpg Home A 2.5D CO-OP vs AI rogue-like platformer that rewards cooperative play and mechanic expertise. https://images.squarespace-cdn.com/content/v1/60999fae41e79b4f40f6fc4b/9a1d95a7-c907-476f-84bf-e9fee46ddad5/AllergySeasonIcon.png Home A fast-paced, one button, physics-based nose defense game in which you must blow away bad allergens to protect your nose from clogging that promotes improvement and beating high scores!