This is the home stretch!

Today we picked up our caps and gowns for graduation. I’ve officially signed a lease for an apartment near my new full-time position. The days are simply ticking down until not just Senior Production, but college as a whole is over. What a crazy journey it’s been. If, during my first year orientation in August of 2014, you had asked me where I thought I would be at the end of April my senior year, there are so many things I would never have guessed. My time at Champlain has been a wild, incredible ride. It’s hard to believe it’s really almost over. Last night was my final performance at The Grind Open Mic, a venue I’ve attended almost every Wednesday night since starting school. Soon, I’ll give my last tour of campus, push my last commit to the re[Mod] repo, and submit my last ever final project. Crazy.

In some ways, I almost wish Capstone/Senior Production wasn’t ending.

This final sprint is nothing but fixing minor bugs that we haven’t gotten around to, and doing final visual polish. We are totally feature complete at this point. It’s a weird place to be, this close to the end. This project has been my primary focus since the end of August, a total of eight months of my life. In the grand scheme of game production, that’s not very long. But in my college career, re[Mod] has taken more of my time than anything else–a total of 427 hours at the time of writing. That’s only about 3 months worth of full time work, but that’s plenty for a college student with other classes and 3 part-time jobs.

There’s been a lot happening over the last few weeks, and I’ve been too busy to update this blog like I’m supposed to. A lot of really awesome stuff has happened in my personal life (I just got a job offer, I’ve been spending time apartment hunting and setting up finances for post-graduation), and it’s taken away from some of my class work. In terms of actual tasks, it’s been full-steam-ahead for re[Mod], but things like my blog have fallen by the wayside.

A lot has changed over the last few weeks!

Unfortunately, due to a technology limitation, there won’t be many screenshots or videos again this week. But I’ll briefly discuss some things that have changed since the last blog post and some challenges along the way!

Hard to believe we’re just about halfway there! It’s easy to see that the game is starting to shapeup. Here’s what I did this past sprint:

I’m writing this week’s blog post in a bit of a hurry, so unfortunately we won’t have as many visuals as usual. Here’s what I accomplished last week:

• Implementing two new weapon parts: the “X-ray/tag” sight, and the “laser” mechanism

The “tag” sight was implemented as a special Aim-Down-Sights effect; essentially, after aiming at a player for a certain amount of time, they are drawn with a yellow outline around them that is visible through walls. This required the use of CommandBuffers in Unity and a lot of time spent in shaders. Overall, the effect came out nice.

Could it really be blog post time again already?

HUD Overhaul

First, let’s take a look at the new HUD:

Another week, another re[Mod] technical update!

WeaponView Refactor

One of the issues we were running into as re[Mod] has expanded more and more is that the BaseWeapon class had grown a little out of control. BaseWeapon handled combining all of the stats from its component WeaponParts, handling the logic for things like shooting, reloading, aiming down sights, serializing all of the necessary data across the network, and presenting the player with a visual response to their actions (such as switching the model pieces when changing weapon parts, activating particle effects while shooting, etc). The result was a file that was over 1,000 lines long. It was split up into #regions, but I still always dreaded it a bit when going into that file. 

This week on re[Mod], we saw a lot of improved player feedback, some new features, and more refactoring of the network code!

Improved Feedback

This was something primarily handled by our other programmer, Justin. We’ve included screenshake when the player is injured, improved reticle response when dealing damage, and an improved hitmarker when being hit. I also worked with Charlie, our Lead Designer, on implementing better audio feedback for all of these events as well. This tied well into the “bullet refactor” performed last week.

This week saw some new progression in re[Mod], but it also saw me come down with the flu, so my contributions this past week haven’t been quite as large as I would have hoped.

Redoing the Sniper Scope

There were some important improvements made, the first of which being that the sniper scope “aim-down-sights” effect was rewritten to use a screen overlay instead of the mediocre “move the gun to the center of the screen” that we were doing before. Initially, my plan was to essentially use a switch inside the WeaponPartScope script which would cover the different effect types, but I quickly found that that was not flexible enough, as different effect types would require different types of data and exposed variables.

I wasn’t totally sure how to title this post. It’s Week 1 of the second semester of re[Mod], and we’re gearing up to take this project from its current pre-production state to something final and complete by the end of April.

Over the break, we made a lot of plans for how we want to improve and finish this game. Some of them are a little loftier than others. Our ideas include up to 20 new weapon parts, three potential game modes, different maps for 2, 3, 4, 5, and 6 player games, and a suite of environment and narrative changes. There are also several backend changes that I would like to make, including a total overhaul of how players find and connect to games. I am very excited to work on a “lobby” feature later in the semester that will allow players without any familiarity with the game to pick it up and play.

My portfolio post about re[Mod] is available to look over now, and discusses my primary roles for the project. Thanks again to Max Sanel, Charlie Carucci, and Tyler Bolster–the other members of the team–for making all of this possible.

The fall semester is coming to a close, and we’re all completing our closing kits, tying up loose ends, and prepping to move forward into next semester. The good news is that re[Mod] was one of the projects selected by the faculty to move forward into full production in the spring semester. That was an incredible bit of validation for the entire team, and we’re all excited to get started with our new team members. First, though, we all need to reflect on the successes and failures of the project, and the things we learned.

Weekly State of the Repo

The mid-year show and final presentations are coming up quick! It’s hard to believe, but we’re just under two weeks away from finding out if re[Mod] gets to go on to next semester!

Since we’re getting so close to the end, we’ve been settling into a slow code-freeze, and the number of new features we’ve selected for the past few sprints has gotten smaller and smaller as the deadline approaches. There is still plenty in our backlog should we go on to the next semester, but that hasn’t stopped us from adding a few cool new things. This week, we’ll be challenging Vertical Slice to get into Final Iteration, which means we’re guaranteed to present at the mid-year show; we’ve also already started that presentation as well. But let’s look at what’s new in the game this week!

Weekly State of the Repo

We’re in Vertical Slice! We’re not totally sure, but we think we may have been the first team in all the Capstone sections to reach this stage, although a few others have done so since Monday. It is, of course, not a competition–but it’s still nice to feel a little ahead.

We’ve also settled on a new name for the game, since Modulate wasn’t working for everyone. The new name is…

Weekly State of the Repo

This past week, we successfully passed into Proof of Concept, and are planning to challenge yet again to get into the Vertical Slice stage. At this point, we can all feel the pressure fully on–there are less than 4 weeks until the mid-year show presentation, which leaves about 3 weeks to actually work on the project if we want as much time as possible to prepare for the presentation itself.

Weekly State of the Repo

General Approach

The AI keeps track of cards discarded, discarded cards drawn, and how many cards are left in the deck, among other things. This allows it to make educated decisions about what to do next based on a utility scoring system. This approach has been very successful against the “test Dummy” DLL we were given to start, often receiving 2-3 times the total end score when playing one-on-one, with a smaller margin but still consistent win rate against larger pools of opponents.

Weekly State of the Repo

It’s hard to believe, but we’re currently about halfway between the start of the semester and Thanksgiving, which means the mid-year show is coming up quick. Modulate is still on route to be a strong candidate to go forward next semester. Visible progress this past week was slower than usual due to a couple factors. Firstly, next sprint I need to refactor all of our code that touches networking–something that made the entire team weary of adding new features this sprint; secondly, this past weekend was Fall break, giving us a four-day weekend that the team has definitely earned.

Weekly State of the Repo

During our last class, we successfully challenged Initial Concepts and are thus now in the Deep Dive stage! Of our three prototypes, we decided to move forward with the Arena game, with one important change: QA feedback was nearly unanimous that the splitscreen controller-based version was not cutting it for players. Thus, the first thing we did this sprint was one of the biggest challenges we’ve faced as a team yet: networking the game.

We’ve also finally decided on a placeholder project/code name: Modulate.

Weekly State of the Repo

Work on Capstone has continued at a steady pace. This week was mostly spent putting “polishy” touches on our prototypes to make sure that we could take them to QA and get feedback on the items we actually wanted more information on, which sometimes requires a more complete experience than you really want to build this early on.

All tasks last sprint were completed successfully, rounding out to a whopping 28 hours logged including team meetings. At this point, most of our major mechanics are implemented in the prototype in some form or another, although most have a lot of room for iteration. This week was spent on the items that follow, as well as writing our technical risk document. A summary of all our mechanics listed in the doc can be found at the bottom.

Our competition for the Minesweeper AIs has concluded, and the results are in!

Weekly State of the Repo - v0.02.02

Last week’s sprint was successful, and essentially all of the core mechanics shared between the different concepts have been implemented. We were finally able to complete some informal and formal QA testing and received good feedback about the direction we should be heading.

None of the tasks last week were so challenging that they stand out in retrospect as being too difficult. One important thing that we tried was a pre-sprint planning session on Wednesdays. Because our class is 8:00am on Thursday and all of us have full schedules for the rest of the day, we struggled the previous weeks to ensure we had a properly planned sprint by the end of the day when our task list was due. This week, we learned that it is significantly easier if we meet on Wednesday afternoons and plan out our tasks for the coming sprint with some room for flexibility based on feedback in-class.

Weekly State of the Repo

The past week was spent implementing a couple different prototypes in Unity, each of which focused on a single mechanic with the plans to later build them out to full gameplay.

Weekly State of the Repo

This first week was spent importing systems that I built over the summer, plus writing a build system.

My plan for Minesweeper is to follow the general approach outlined by Bai Li (luckytoilet) in the blog post “How to Write your own Minesweeper AI” which is also linked to in the references section.

Before I begin, I want to give credit to whoever wrote the blog post that used to be located at the following link: http://www.nikumangames.com/dev-blog/unity-and-sourcetree-and-unityyamlmerge-exe-oh-my/

The only reason I’m writing this post is that it looks like their website is down and isn’t available in the Wayback Machine. So thank you, mysterious vanishing developer(s)! Major credit also goes to Tim Pettersen (@kannonboy) for his GDC 2017 talk on incorporating Unity with git which is what got me started down this path.

This is a blog post I’ve been meaning to write for quite some time. My summer engine project is winding down and, due to a lack of time, never quite reached the level I wanted it to. Still, one of the best aspects of what I was able to complete was the Coroutine system. This doesn’t use proper concurrency to run (although I will talk a bit more about that in a future post), but somewhat emulates the way a lot of really common coroutines work.

The semester is wrapping up, and so I’ve been writing postmortems for pretty much every project I’ve been working on. I’m getting ready to update my portfolio with some of the projects I’ve worked on this past year; I’m a little tired of my website making it look like all I’ve worked in is Flash. One of my favorite pieces I worked on during the last piece of this semester was my UI system for my Game Architecture final, which is written in C++ using SFML.