Blog Post 10: Post Mortem

A few weeks have passed since my last post and quite a bit has changed. Visualizer has gone through major quality of life updates and polish passes and managed to survive the cut process here at Champlain and will be moving forward next semester into full production. 

Throughout the past 15 or so weeks of development, I have grown quite a lot almost as much as my team and our game Visualizer. The most notable thing about this project has been the lack of a dedicated producer or programmer on our two designer and two artist team. Right from the gate this team composition was a limiting factor in the kind of game we wanted to make and we would have to choose a prototype that we felt was manageable for our given skill sets and would be something that would play to our strengths. However given this, we still had to each wear quite a few hats during the course of development. My role on the team as lead designer and “half” programmer was not only to implement and program new features, but be hyper keyed into the development process and our vision of the game and help guide the team in a way where we were able to most effectively bring this vision to life. The latter was my main area of focus, I helped program and implement where I was needed and while I could have done more hands on work I needed to take a step back and keep an eye on the overall vision of the game. 

Last semester in Production 2 my team did not have a programmer and instead was comprised of 2 producers, and 7 designers. Needless to say, things got a little out of hand and the project was a bit of an unorganized mess. A big area of learning for me in that project came from how enveloped I was in the hands on coding side of things. Because my role was the main “programmer” of the team as well as the lead designer my roles were conflicting a bit, on one hand I needed to program in order for features to get implemented in the game but I also needed to look at the game from a more objective standpoint which was hard to do with my face so buried in the code. Learning from that experience I took a step back and really dug down to my roots as a designer as much as I could while still helping with the code where I was needed. This way my team always had someone on lookout as the game developed and as we brought it to QA. This proved extremely helpful with development as I was always keyed into what needed to be worked on and what issues needed to be addressed and I worked with my team to develop the best solution and when needed I helped make this a reality as well. This was the biggest take away for me this semester, learning what it means to be in a lead position. 

In terms of team dynamics we all got along swimmingly. We were all very respectful and very professional when it came to others ideas or thoughts and we never really had any issues with communication (aside from occasionally needing to be a bit more clear). The main area of learning here for me was communicating as a lead why we needed to prioritize one feature over the other or why we needed to keep pushing a certain feature forward as opposed to implementing new ones. This issue comes hand in hand with figuring out these decisions through a design lens in the first place which was another challenge I faced throughout the semester. During the first half of the semester or so before I had really figured out how to be a lead I was still struggling with juggling programming work with design work with leading the team which put the development of Visualizer in a weird track. We initially just began developing a bunch of features we thought we wanted in the final vertical slice and to our credit most of them made it in. However we did not have the best prioritization with what was getting worked on and when, for example it took us about 10 weeks to remove a game breaking debug feature that was really easy to figure out and we took about the same amount of time to implement our second level. Had I came to this realization a bit sooner Visualizer likely would be in a much better state than it is now. However that being said the team did a fantastic job working together as a cohesive unit, we were all very hardworking, determined, and passionate about making Visualizer the best we could make it. I do wish however that I was able to spend more time with my face in the code helping pull the game up even more. This would have meant that I would have to take less personal time for myself each week which I feel ultimately helped us. In the past I fell prey to working nonstop for better or for worse and it began to get very draining on my mental health so I decided I needed to dedicate some time to myself every week to breathe and I feel that in doing this I was able to basically hit a reset button and I could come back to the game each week feeling refreshed and in a much more clear head space. 

In the end I am extremely happy with the progress my team has made on Visualizer the past 15 weeks and I feel more confident in ever in myself to help lead a team and guide a game’s development through a design lens and through a lead position.

Blog Post 9

With the midmortem presentations drawing close my team has been hastily continuing work on Visualizer, our FPS rhythm game.The past week has been primarily focused on getting in and iterating on player feedback and implementing the last of our planned systems. Since last sprint we have implemented the combo system along with the two player movement abilities the combo system works with. We have also implemented a new round of sound effects and particle effects to help communicate to the player better what exactly going on in the game. On top of this, we have implemented our third and final enemy for this semester, our tanky character, the Brutilizer. 

In terms of art, this week we have implemented the shotgun model into the game and we have weapon reload and recoil animation for both of our weapons. We also completely overhauled our UI and completely changed the layout and functionality with the hopes of communicating better the player what the game systems are. 

Going forward from here we have almost all of the functionality in the game and now it is just a matter of polishing the weapons and enemies, implementing feedback, creating a second level, implementing our new song, and teasing progression in the game. 

My primary concern with the game right now is our lack of direction and lack of communication to the player and to each team member. Lately team members have not been as informed about what the others are working on as I would have liked which has led to work flow stumbles, nothing serious enough to be a problem per se, rather slight bumps in our teams ability to work efficiently. In terms of the game itself our primary issue is that players are often very confused as to what is going on and what they need to do in the game as well as how their actions affect the world they are in. It also feels like the team is aware that this is an issue, but it does not seem like we really have a cohesive idea of what we need to do in order to fix it. I plan to player the game for a long while and write a comprehensive list of bug and feedback as well as features we need to implement or redesign. I also plan to bring this up at our next meeting and sit everyone down and talk about how we can go about fixing both team and player communication issues.

Blog Post 8

Following the Columbus day break, development on Visualizer was left in a weird spot with a lot of features left unimplemented and up in the air. The next spring cycle after this break left us in a position where everyone was available and ready to get back onto our normal work schedule. This allowed us to spend the vast majority of the week implementing the features we had been working on for some time but had not gotten the chance to implement. 

The two most notable changes in development this past week were the implementation of our new weapon system which allows us designers complete control over when the player gets a new weapons, how they get it, what weapons are available and in what order, what weapon has what firing mechanism, and complete control over the particles and feedback effects generated when the player shoots. Along with implementing a big system like this it was bound to come with a number of bugs, which was certainly the case here. I spent the majority of this week bug fixing the system and making the guns feel as good as possible. I tweaked the vfx of the bullets, I changed the position of the gun on screen, I implemented the first draft of the pistol model, and I led QA testing. 

In addition to the weapons system we implemented our first pass at UI, the two of these systems then began to work together to give the player a full picture of how their actions affect the world around them in terms of any combos they gain, remaining ammo, health, shields, enemy positions through a radar, etc...With the beginning stages of these two systems implemented the game feels much more put together and establishes a decent proof of concept. 

In terms of the art side of things we have been working closely along side our artists to tweak the UI to both increase play ability and visual interest. We have also been working to implement power ups like shields and health. As of last week level design and environment art took a bit of a back seat as we relied our priorities were in the wrong place; putting more emphasis on the play space than the systems and mechanics needed to prove the concept. While it would be nice to have a dedicated producer to help manage our team we have been able to plan and make cuts very well according to our game needs and player feedback.

Going forward our main goal is to really buckle down on making the game feel as fun as possible. We plan to constantly iterate on the beat detection system and the weapon feel as these are the cornerstones of our design and what will make the game the most fun. Secondarily we plan to flesh out the AI a bit more and add more complexity to the combat through new player abilities and movements.

Blog Post 7

As our development of Visualizer (our rhythm shooter game) continues we find ourselves in a bit of an awkward state. We realized in our prior week of development that our feature planning was chalked up to mostly guess work, often including the kinds of general things we needed to get into the game and not enough specific information. We spent the beginning part of our weekly sprint discussing as a team what our development road map would be for the semester and we planned out in detail the features we needed to add and what the deadlines were for those features. On top of this, we gave ourselves a week long buffer before the mid-mortem presentations where we could dedicate ourselves to polish and bug fixing as we plan to feature freeze any new additions the week prior. 

Upon creating a more structured roadmap we all had a good understanding of what we would all be working on and we spent the majority of the week completing as many of our tasks as we could. In terms of what I was in charge of this week was furthering the work on our weapon system and continuing work on level design. With the weapon system I worked on incorporating weapon switching and picking up new weapons as well as creating the functionality for the pistol and the shotgun weapons. My main challenge here was condensing the code and making it as modular as possible; writing it all in one neat script and creating enough variables that tweaking would be very efficient and streamlined. In terms of level design the blockout for level 1 was for the most part finished. We discovered that the scale was enormous and needed to be adjusted so a series of meeting with my environment artist and trouble shooting were necessary to figure out why nothing was lining up. With this sorted out and with my remaining work time this week I shifted my focus to creating a rough blockout for our level transitions. As it stands right now the player will spawn in a side room in the night club’s bar/lounge and then will proceed into the bar/lounge area and fight off the “data leeches” inhabiting this first level. Upon completing this level the player will proceed into an elevator, be awarded a new weapon and then will have the ability to use any points scored to purchase weapon upgrades. After this the player, being a creature of data themselves, will travel into the wiring of the elevator and will find themselves inside the cables of the club. These cable levels will be simple hallways with randomly moving targets the player can shoot to practice with their new weapon/upgrades and upon reaching the end of the hallway the player will enter the second level. It is these cable levels I am currently working on. Once I finish production and blockouts of these levels I will move on to coding the actual level transitions and the weapon upgrades.

Overall, things are a little all over the place with our team at the moment. We have a bunch of features and assets each team member has been working on but only some of it has been implemented into the main gameplay loop and as such we are still using and testing out dated assets and mechanics which is starting to hurt our development. Going forward, the plan for this week is to meet and do a huge pass over the game, implement all of our feature and assets, clean our any unnecessary project files and reorganize ourselves to hopefully make further developments run a lot more smoothly. 

Blog Post 6

In terms of development, this week was a bit tough. Given that we had no classes for Columbus day, team member availability was a bit limited with members such as myself being away or with family. We resorted to limited in person meetings in favor of online meetings on discord where all members could attend. On top of this we had to hold meetings at different times than we would normally to accommodate for the change in schedule. 

When it came to feature creation I felt like we were a bit all over the place. In the prior week we had spent many a meeting determining what the scope of our game was and really defining what our game would look like in terms of progression, systems, mechanics, etc.. With that planned we then needed to being the development of these features. This is what our main focus was this week. Each team member was assigned their respective tasks, broken up by discipline and specialty and we all got to working. However I felt like this sprint was a bit of a mess in terms of what we were working on, though this may have been an issue unique to me. I was tasked with designing and white boxing our first level and getting our weapons functional. The issues i ran into with this sprint was that I needed to finish our weapon system so my other designer could implement them and I needed to finish our level blockout so our environment artist could start asset production based on the scale I used. I needed to fulfill two distinct roles simultaneously, both level designer and systems designer. This was very challenging for me because no matter what I worked on I would feel like I was holding one of my teammates back. Ultimately I needed to make a call and I decided to put most of my focus on level design as the design blockout process and the environment art creation process would take the longest so we needed to allocate more time for that. This means that I will need to spend next sprint working on developing our weapons so that my other designer can implement them with the beat/combo system. 

This issue will likely be fixed next sprint/as soon as i can finish the weapon system however. Last sprint, prior to me starting work on the weapons, I met with my designer to split up our roles in the team so we would be able to develop a better workflow and so the team would have one person to go to with specific questions of concerns regarding a specific feature. I will be in charge of level design and FX (including music and visual FX) and my other designer is in charge of Systems design and UI, and we are both splitting the AI development role.

This sprint was a bit of a mess but we addressed out development pipeline issues mid sprint which ideally will make future sprints go a lot smoother. Going from here our main focus will be on implementing and tying together the level, art, and systems we started working on this sprint. On one hand I am glad we have managed to accomplish so many features this sprint however I am worried in regards to implementation as we have so many working parts that need to implemented all at once which will inevitably lead to quite a few bugs that need to be hashed out which will take up a chunk of development time. Going forward this will be our main focus. We will be implementing all the collective features we worked on as a team this sprint and polishing them until they feel good together. From there we will then work on iterating them and adding more features. 

It is at this point in development where having a dedicated producer would help us, namely in avoiding what happened this sprint with the jumbled roles among us two designers, however with the issues likely resolved I imagine we will be fine going forward without having a dedicated team manager.

Blog Post 5

This week it was finally time for us to narrow down our pool of three games to one, the one we will be working on for the next year. After deliberating long and hard over our three prototypes we have chosen to move forward with our rhythm shooter game. Our decision process was fairly simple and largely a unanimous decision. We sat down as a team and agreed not to leave the room until we had chosen our game. With us all there we wrote an extensive list of the “values” and the “risks” associated with each of the three games. In addition to this we also fleshed out the designs of each game if we were to go forward so as a team we would have a better understanding of what we were getting into. We ultimately decided that our leg tank game was a huge technical and design risk as we would need near perfect game play that felt solid and was extremely unique from other fighting games, additionally the concept left little work to be done in terms of environment art and level design so half of our team would not be working to their strong suits. Given all of this, we cut leg tank from our list. When it came to our mine cart shooter game we decided that once again we would run into rather large technical issues with the roller coaster system and we would be in a constant battle with fighting off motion sickness with turning minecarts. We realized that the motion sickness issue severely limits level design options as we would likely be unable to pull off fantastical levels, which for us was the main draw to the game. On top of this the type of gameplay we were targeting left little to do in terms of 3D animation so our animator would be left without a lot of work. In terms of our rhythm shooter our primary concern was the fact that another team was also making a game based on the same exact concept. However we realized that in making our game single player we would be able to differentiate the two ideas enough that this ideally will not be an issue and that we may even be able to use the other team as a resource. On top of this the whole team seemed most excited about this idea as it is our most unique and more flexible concept which we will be able to get extremely creative with and which will make iteration rather easy. 

In terms of development, this week we focused on really defining what our concept was. We realized our primary issue we needed to address was the beat mechanic. We want to tie in as much of the game to the beat as possible and we have a number of ideas with how we might approach this, like making the enemies only shootable on the beat, create a combo system for consecutive hits that we can use as currency to upgrade weapons, etc... 

The things we worked on this week were designing and blocking out our base level, implementing a mechanic where enemies can only be shot on beat, and both character and environment conception. In terms of a production standpoint my biggest concern as of right now is figuring out what exactly we want our game to look like at the end of the semester and how we need to plan our sprints to accomplish this. 

Going forward I plan to hold a number of design meetings where we discuss enemy variations, how our weapon upgrade system will function, and what our overall narrative will be and how we need to structure our gameplay to reflect this.

Blog Post 4

In our fourth week of development we focused on creating our third and final prototype, our leg tank fighting game. This is a game that spawned originally as a joke as it was based around a character known as leg tank, which is exactly as it sounds, a tank with large muscular legs. It was at this point where we faced our first design hurdle; figuring out what exactly a leg tank game entailed. Through some discussion we deduced that our best be was a 2.5D brawler.

In terms of setting up a prototype I was not particularly worried about the technical aspects of programming and more so about splitting the work load. Because all players will have the same abilities, movement, and so on we only needed to make one version of player. Initially this was a bit challenging for us two designers because we had to divide the work in such a way where one person worked on movement and the other worked on setting up attacks and since we were setting up the basic character from the ground up we needed to make extremely modular code that could be easily combined after we both finished working. Code-wise this was not too hard. The hardest part came when we had set up the basic character and worked on further development like setting up health, rounds, and power-ups. It was difficult communicating how we would navigate changing common player values as we both worked. For example if I was to change the player’s base speed as the other designer worked this would cause issues with version control and it was difficult to know exactly what we each needed to tweak within the player character until we got deep into the code and started working.

In terms of how development went with this prototype things went very smoothly as we followed our general production cycle from the past three weeks to help structure our development. Because of this, we were able to scope our prototype accordingly and get in all key features and even add in elements of polish that make it feel QA ready.

My main concern with this prototype however, deals less with the technical constraints we faced in development but rather the design and polish issues we will run into in the future. Fighting games are notoriously difficult to program and design because the controls and mechanics have to be razor sharp. We will need to have extremely well defined mechanics and game play elements that set our game apart from any other generic fighting game and we have to make sure these mechanics feel perfect. Not only is this a design challenge in terms of fun but also in fairness and balance. As if to make things even harder we will also need to program the game to be completely bug free, extremely smooth, almost frame perfect, and be modular enough that we can go in an tweak values and abilities on the fly. I worry that if we are to go forward with this idea we will run into mountains of unforeseen issues and design challenges that might make choosing this game a bad idea.

Going forward my team and I plan to take some time, sit down with each of our three prototypes, vigorously play them and heavily discuss the scope and overall potential and strength of our concepts. From this play session/discussion we will walk out of the meeting with either one or two game ideas we plan to move forward with. If we choose to go forward with two ideas we will do another round of sprints for each game, furthering development and QA testing our concepts again to better gauge which of these two is a stronger and more feasible idea. If we move forward with only one idea then we will simply go into full fledged production on this idea.

Blog Post 3

This weeks focus was on making our second shooter game. The premise of this game is that two players continually ride mine carts around roller coasters and shoot each other and the last one standing is victorious. We chose to prototype this game as our second prototype because we predicted that this was our second most risky game idea and as such we wanted to figure out early if it would be a feasible idea to pursue. 

As it turned out, with the help of a spline system plug in we were able to severely mitigated the risks associated with both building roller coaster tracks and getting objects or players to move along them. As such most of what I worked on this week was less on the programming side and more on learning the new tool and building out a basic environment that the players could fight in as well as experimenting with coding in the ability to dynamically switch tracks. On top of this, I worked on setting up basic game play functions like determining the winner and restarting the game. Because we are unsure of the logistics of using an outside tool in the development of this game if we were to move forward with this idea I also conducted a great deal of research about creating our own custom tool in Unity to use to build out our tracks and what not. 

All in all this prototype proved to be significantly less of a risk than we had initially anticipated and we were able to get a very functional prototype very quickly. However I worry that if we are unable to use this external tool to develop our game further if we so choose I worry that we will be unable to actualize this game without a dedicated programmer. This particular game involves quite a heavy workload on both the programming and design fronts and with only two designers this may be an issue. The final game will require a large number of different smaller systems that need to come together seamlessly and I worry that us two designers will have to dedicate large numbers of hours to figuring out how to create a system that will allow us to build nice tracks that we can fully manipulate through code. 

In terms of the producer side of things we have yet to have any issues as we have set up a solid work flow for these three prototypes where we spend a week working on art concepts and building the prototype and then spend the next week working on another prototype and creating the documents and conducting QA for the prior week’s game. Like last week, the plan as of right now is to bring this prototype to QA and test the validity of the concept.

Blog Post 2

In our second sprint of development my team and I have decided to move forward with three game concepts, a rhythm shooter, a 1v1 fighting game based around the character “leg tank” which is exactly as it sounds, a tank with big hairy legs, and a 1v1 shooter where both players are in mine carts on a roller coaster. 

For this specific sprint however we chose to prototype the rhythm based shooter as this was our highest risk prototype. The game concept is as follows, you must survive an onslaught of enemies for the duration of a song, but you can only shoot the enemies on the beat of the song. The prototype is surprisingly functional given that we only had a week to work on it and we have enough content to warrant a basic test as QA. We currently have simple AI, a basic beat detection system, a full arena, a mini map, and a lose state.

My biggest concern going into this prototype (and a big part of why we chose to try this one first) was the technical risk associated with a rhythm game and our lack of a programmer. The lack of a programmer on our team resulted in many hours of research about how audio works in the Unity game engine and drafting ideas of how we might want to tackle the issue of dynamically calculating the beat of a song based on an audio clip. Luckily because I had dealt with audio in Unity before in a somewhat similar fashion this issue was mitigated by the fact that I already had ideas of how we could tackle this and knew how to point my research. After a few hours of research and programming we got a very basic system of beat detection set up. From here we spent the rest of the week setting up game functionality. 

The biggest challenge for me however was time management, without a producer to help us budget our time and scope we may have gotten a bit too ambitious with what we wanted to get done within our first sprint of full development. However, because we have two designers on our team we were able to split the programming in such a way where the work load was more manageable as I was unable to dedicate as much time as I wanted to to the prototype this week on account of my other assignments. 

So far however we have not run into too much of an issue without a producer, we are able to keep our sprint planning mostly within scope, while also including a few stretch goals, and we are relatively good about wiki and team management. 

The plan going forward is to bring the prototype to QA to get more formal feedback, potentially iterate on this idea, wrap up any accompanying documents with this prototype, and move on to our next idea.

Blog Post 1

Hi, my name is Ryan. I am a part of a four person capstone team with the aim of creating a video game over the course of the coming school year. I am writing this blog as a means of documenting the development cycle of our game from conception to the final product. My team (currently not named) is comprised of two designers (one of which being me) and two artists. Unlike a number of the other capstone teams in our year we are lacking a dedicated producer and programmer so the challenges we face are largely unique to us. 

As of right now our team is in the conception phase. We are currently drafting and fleshing out potential ideas for our game. As of right now we have 21 ideas in a shared document that the four of us have added to over the course of a week or so. The ideas are extremely bare bones as of right now, mostly consisting of just a core mechanic, character, narrative, etc. Once we had reached the 20 idea mark, we all sat down as a team to discuss our concerns with each idea, as well as what we liked about each one. The idea behind this exercise was to both get everyone on the team on the same page about each idea and clear up any confusion and to start becoming aware of our potential shortcomings are as a cohesive team. This way we will ideally be more aware of what we can and cannot accomplish given the time and our personal skill sets. 

Once this conception phase had concluded we decided that it was a good idea to take a day or two to sit on our ideas for a day or two before revisiting them with a clear, open mind. At this point in time we added another idea and delved even deeper into each idea really ironing out any concerns we had and addressing any other questions about an idea that may not have come up earlier. We then evaluated each idea in a risk assessment and each voted on our 4 favorite ideas. The idea behind this was to gauge team interest in our ideas and see which ideas were weaker and which ones we could potentially pursue. This is roughly the point we are at right now with development, we have a list of now 10 of our favorite ideas with an emphasis on 3 of these 10 which most of us prefer. 

Our biggest challenge so far for me personally has been trying to bridge the gap between the art and the technology side of things.The team, specifically the artists are very imaginative but I find myself needing to reign the team in a little bit, back to the realm of possibility. As of right now our primary concern going forward is choosing our final idea and making the final decision on which game engine we want to use, Unity or Unreal, the engine the designers know or the engine the artists know...