Honored is the game made by team Dis Is Honored for a 4-month long capstone project for the end of the degree program at Full Sail University. It is done in collaboration with 4 other designers, and 4 artists. The game is based off Dishonored from Arkane Studios, and set in a premodern Egyptian empire. The player must navigate through levels with numerous paths forward and complete missions such as defiling monuments, stealing artifacts, or taking out targets. The project is available now on Steam. Play time is roughly an hour and a half.

I worked on creating the inventory system for the game and many of the items that went into it. I also contributed to the level design, enemy AI, and Player Character functionality. 

Dev Blogs

Post Mortem December 15th, 2022

Honored was a fun game to work on and I learned a huge amount about the game dev process by taking a project from start to "finish". One of the key takeaways being something that our Course Director told me even beforehand: "Games are never done, we just stop working on them." Now that it's time for us to stop working on this, it's also time to reflect on what went right, and what went wrong, and how I can improve for future projects and team. 

What went Right

One of the best parts of the project was that we were able to get moving very fast very early on and build the project. We made a really strong start on the project putting a very large amount of features in, especially compared to some of the other teams that seemed to spend much more time trying to figure out a cohesive vision. We gained a lot of momentum and motivation with our strong early start.

The other part that helped is that we did not have a lot of clashing heads which let us get more work done faster. As a team, we managed to head in one direction most of the time without having to dedicate much time to drive the project in one direction. 

Another bit less close to design, but at least as important was that we got along very well. We made time to do team-building activities and just hang out together. By the end we were all really good friends and able to ask for help, or give critique because we all trusted that each of us was doing our best to make a great project. 

What went Wrong

    Each of thoes previously mentioned advantages ended up with some serious down sides. For one, our early lead meant we had a lot of features many of which were not made to work with anything, much less everything in our project, so getting some of the systems to communicate was an uphill battle. I spent a significant amount of time learning how the code for my teammates features worked so that I could implement mine cleanly, and a lack of documentation made this a lot worse.

Another problem was that our lack of clashing seemed to also come from or with a lack of communication. Like with our code not communicating many times I opened to project and saw something I hadn't even heard was happening, and given the size of the project was a little disappointing. But I learned the value of strong communication and how when everyone is on the same page and working together, even if it's slower the project turns out a lot better.

There were more smaller problems, but almost all stemmed from these broad issues so that's where I will leave this off.

This project was a blast to work on and I am proud of what we created. Knowing what I do now, I can say with certainty that doing it again would make a much better product but I learned a massive amount and I came out as a strong designer in the end.

Bellow you can find the sprint reviews that were created with each of the 7 sprints of the project. These show a more in depth view of what I worked on with each section and what I learned each time. There were six 2-week sprints and final month of class was consolidated into one 3-week sprint. 

Sprint 1 Review September 14th, 2021

This was the first sprint. I worked on two different things for this sprint:

Going into this  I had no idea how to make an inventory and so I followed a tutorial by Ryan Laley the entire way.  Because of this there are some things that behave in ways that don't work perfectly for our system, and I anticipate issues with connecting this to something like a weapon wheel.  

The enemy awareness functioned off existing code from my teammate Trevor Babcock. A big takeaway from this was reinforcing the importance of commenting because I spent a lot of time trying to figure out what was what. Going forward I am going to be making an effort to be as detailed as I can with comments. 





Sprint 2 Review September 25th, 2021

This sprint was the second sprint. Once again we were focused on getting more features and filling out the toolset for the player. I personally worked on:

The iventory was fixed through a simple error from the searching for a slot behaving different in build versus in editor. I retooled the same functionality into a different chunk of code and it now works as intended.

The Throwable was built using a physics object that the player connects to them to hold, then deletes and spawns a clone of to throw., adding an impulse in the players facing direction. I still have issues with communication to enemies so that part of functionality is still missing.

Sprint 3 Review October 14th, 2021

This was our third sprint. While we still had some focus on getting new features into our game, we also started working on levels. I personally worked on:

The throwable had some frustration but I had already ran down most of my dead ends, and at the start of this sprint I got it working fully. The throwable now attracts enemies, and also stuns ones that it hits directly (stuns built by Trevor Babcock)

The level came out well for what was finished, but I spent too much time on small details so the level ended up being very small. I think I need to focus more on rapid prototyping and getting something done fast, then make it done well.

  

Sprint 4 Review October 22nd, 2021

For our fourth sprint I focused a lot more of level design and fixing some existing bugs. Specifically:

The falling damage was what I started with. This was  done using a lot of testing in the reference game, Dishonored. Then I had to reteach myself some Algebra and Calculus to make a good formula to convert player velocity into damage. When the player lands it checks their velocity and outputs it into a damage number scaled to their health bar. The code was very few nodes, but it still took several hours of math and testing to get right. It was an interesting change of pace from the usual. 

The level was difficult for me because of my goal to use verticality and tie in falling damage. The biggest issue of this level is enemies swarming the player. It's very easy to attract enemies from floors above and bellow who will then pathfind up to the player, which takes long enough the player doesn't even remember attracting them. I believe the enemy needs tuning anyways, so I want to hold off on changing the level in case that issue is fixed through other work, but I do need to comeback to it.

I also made it so that throwables will attract multiple enemies. I changed the event to take a boolean input letting the player choose which functionality they want to use when calling that event. Currenlty it is only used by throwables and it is checked as AlertAll. But someone could easily change it back in the future and the values for it are able to be easily changed as well.

Finally I spent some time getting throwables to lerp correctly to the player. What was happening was the item would zoom in from the side when the player picks up a throwable rather than just moving from where it is to where it should be. Essentially what happened was a lot of flipping of relative positions and world positions. Thankfully this fix was only a couple of nodes and didn't involve much refactoring, however it took a very long time to diagnose and I wish I could have used that time to accomplish other things.

Sprint 5 Review November 3rd, 2021

This is the start of a new class, Game Balancing, and with that we are now going to be focusing more on bug fixing and polishing. There are not going to be more new systems unless absolutely necessary. I worked on:

The throwable ended up being more complicated than I thought in that I had to restructure the code, but I came up with a solution that was fun to implement and works really well. It brings the object to the player and then simply reveals a throwable mesh that is always in the players hand, that way it moves as the player does such as running. And then when throwing it, I spawn a new one where that mesh is, and then add an impulse, hiding the mesh again.

After being stunned enemies would previous just declare "must have been the wind" which is not how people usually respond to being smacked with a glass bottle over the head. So now they save the location that the throw came from, and run to that area using the investigate sound code. I want to change it so they run part way, because it's hard to say where the source is precisely, just the direction, but that will have to be a later change.

Sprint 6 Review November 9th, 2021

This sprint was pretty small for me, however I was for the first time diving into UI. Lots of very tedious tasks which was a bit of a nice change:

The UI in Honored is all slanted as part of a stylistic choice, but almost none of it is standardized. Some was slanted left, some right, and different UI elements were slanted between 2 and 10 degrees. I ended up standardizing it all under a 4.5 degree slant that looks pretty nice while still keeping the player able to easily read without tilting their head. The other part of this is that I wired up all of our buttons to have sound when hovering and clicking on them. This  was a shockingly huge labor, because I manually set every buttons OnHovered and OnClicked in every menu in the game. I am sure there is an easier way to do this, and I'm kind of shocked I didn't even look for one, but in the end it worked. Being able to just chill out for a few hours while connecting the same nodes over and over was a nice break from the non stop problem solving.

Our coin system was created with the intent of creating shop keepers for upgrades. But when we realized how complicated that ended up being for what is basically just another version of our existing rune upgrade menu that got scrapped. But we liked that they served as a metric of how much of a level the player has explored so I chose to redesign them to be a collectible, and the form was scarabs. I'm not completely happy with this, but I don't have time to entirely refactor the design, so it'll stay the way it is.  I have some more thoughts on this that I'll share later on in a personal Post Mortem essay for the whole project.

Sprint 7 Review December 19th, 2021

Sprint 7 is the final sprint of our project. Under a normal schedule the class would have called for 2 sprints, but with Thanksgiving cutting off the first week, and Christmas forcing an earlier graduation we had much less working time than a regular schedule would have had. 

My time was spent on:

The art assets were the bulk of the time. Most of it was very easy, just moving in the static meshes, turning the textures they gave into materials, and making sure everything aligned correctly. But I had to do it many times since there would be issues and I had a number of different assets that I had requested.

The throwables tracing was also pretty easy, but I had to go through a few revisions of how I was handling it. I initially was looking into using VFX but the sources I found did those in a way that seemed to require refactoring the way we handled throwables. Our game uses physics and just applies a force to the objects, whereas the sources have the player aim to a location and then calculate the arc for it to fly, which is easy to wire up VFX to as well. Because of this difference I chose to simply create a phantom version of the throwables which removed some of the behavior such as exploding after a time or attracting guards on landing, and changed the material to an earlier draft for glass that was intended for bottles that was too clear for that purpose, but makes a great "ghost" material.

Finally, for this sprint I wasted a lot of time with bugs and tasks that were duplicated between multiple designers. I had several hours of time spent essentially reading through tasks, testing and finding out it was no longer an issue. This stemmed from a broader failure to report bugs as we find them, so at the start of the sprint we all made tasks for what we knew needed to be done, which led to several of us cloning each other. I believe I made a reasonable effort when making tasks in this way to check if there were duplicates, but I'm sure I can't be absolved of all fault here.  My theory as to why this only came up now is that we were doing a good job checking for tasks before reporting, but this last sprint we got too excited to be done with the project and the degree, so we rushed it. 

The other reason for this doubling up, was because several of them were art related issues, and they would simply get fixed as someone integrated the art assets, which isn't something I had the experience to foresee, even though now writing this seems obvious in hindsight.

This game was created in collaboration with Trevor Babcock, Paul Howald, Demetrious Reed, and James Clingan, with art assets provided by Jennifer Anichowski, Gary St.Louis, Deyquan Wilson, and Ryan Angiuoli.