Development Blog

Senior Production Part ? - Showtime

The last step in our production cycle would be showcasing our game at the Game Studio Senior Show, and then leaving it, free to play, in our gallery space for the following week. By making it essentially a public release, we’re faced with one more big issue. We can’t let people break it, no matter what. The gallery is open for 6 hours a day. If the first player breaks it, that’s possibly 6 hours that people see a broken game. The stations would be a monitor, speakers, and a controller. No messing around with mouse and keyboard,. Guests see what we want them to see.

It was finally time to make use of the demo mode feature I implemented months ago. And the kiosk mode I implemented weeks ago. There’s one button on the home screen: Login. Register and Quit are grayed out and inaccessible. On the login screen, there’s an account assigned to you, and you can’t change it. We could have skipped over that whole process, but still wanted to demonstrate that we have an online account system. Then there’s the choice between single player and co-op. Both work, but we made the requirements (30 second timer) for co-op more obvious.

Once you’re in the game, there’s a few different ways to exit. “Return to Hub” takes you out of a level/mission, back into the hub. If you’re in co-op. it takes your partner with you. If you hit “Quit”, you go back to the login screen. Once again, taking your partner with you. Lastly, not interacting with the game for 5 minutes does the same. Still, with your partner. Nothing’s breaking, everything’s controlled.

Along polishing up the game, we set up our space in the gallery, and if I may, I think it’s by far the coolest. We have ~40 decals of a selection of the 300+ guns in the game. We have a light-up rocket, which holds custom business card holders, for everyone’s cards. It clean, but flashy at the same time. Admittedly, this wasn’t really my realm, as I don’t have the most deft hands.

With all that set up, we’re ready present, demo, and move onward and upward with our careers as developers.

Senior Production Part ? - The Last Push

Over the past week and a bit, we wrapped up the rocky development of Tales from the Blasterverse, with a bit of a bang. I’m genuinely shocked by how well everything came together, and how much got done, even taking into the account the exuberant time some of us put into the the last few days. I think the hours were somewhere around 35, spread over less than 3 days.

The programmer process was pretty simple, but effective. We threw together a spreadsheet with different categories in our game, including each individual level. We started to ourselves, but soon enlisted help from other team members to play through the game, and taking note of things. Every notes bug was color coded. Red for a critical thing, yellow for something less important, blue for something that might be fixed, but has to be tested in co-op, and green for done. The issues ranged from game breaking, to minor balance tweaks (that we largely ignored, cause there were more pressing issues).

By the end of the first night, the makeshift task board had become almost fully green, yellow or blue. Barely any major things left. A lot of what we fixed, ended being a bit silly, but almost expected as a programmer at this point. “Why isn’t the client getting information about interacting with mission events?” Probably, cause we don’t ever call the function. “Why is this menu breaking for a new player?” Probably didn’t have a null reference check for an object they won’t have yet. “Why do these enemies have no health?” Because they are set to have no health.

So, with a lot of focus and man hours, the game went from a broken mess to a beautiful mess that broke far less often. Final art passes, collision checks, and some UI tweaks also went into effect. As for the balance tweaks, things got a bit odd. Some players thought the game was too easy, other too hard. Ultimately, I leaned towards accessibility, decreasing enemy counts and spawn rates on a lot of levels. which also helped with packet loss, as some enemies were teleporting or disappearing for clients. The game was good, and playable. Now all that was left was making it presentable.

Senior Production Part ? - Going to War with the UI

As we wrap up the penultimate week of real development, the programming team has fully transitioned into a bug bashing role. My focus continued to be on UI, for what I was hoping would be the last week, but things didn’t quite go as planned.

The first thing I got out of the way was making the ‘X’ button work as the ‘A’ button in menus, which requires a shockingly strange function call that I would not have located without the help of the Internet. Along with the, ‘B’ also exits menus now, which above all else, acts as a fail-safe, if anything in the menu breaks. I figured out how to get our scrolling menus to work with a controller as well. The actual math behind it ended up being incredibly simple, but I was trying to over-complicate it, constantly leaving me with an off by one error. As so often in programming, the answer came to me by stripping away most of the function.

I did some more general menu fixes as well, mainly getting the mega-gun station to work fully, including the salvage menu. The one thing I ended up being sucker punched by, was the weapon locker. As I was looking into a small issue, I discovered something far more troubling. This menu works a little bit differently from the others. A few weeks ago, I thought about changing it to be more in line with the other, but chose not to. Bad idea. I couldn’t at all do what I was hoping to, and ultimately made the call I’d start this next sprint by refactoring the whole thing. Really, it shouldn’t be that hard, and certainly a whole lot faster than possible workarounds.

Another problem that arose this week, was things breaking throughout the week, making me step away from my current work to fix it. One of those issues actually came about with from one of my own tasks. Due to our limited schedule, it’s hard to get full test coverage. This bug was, controllers not working for the contract station after the first mission. Major, but not tested, because I saw absolutely no reason that it could be an issue.

The biggest takeaway from this week is that it’s really easy to underestimate how long bugs will take to fix. You think you know your game inside out, and everything that’s not working should be simple to correct. The reality is, that if it were that easy, things probably wouldn’t be broken in the first place. So for next week, I’m aiming a little lower, but ready to pick up more bugs along the way.

Senior Production Part 4 - New Name, Same Game

First things first, as the title implies, we’re undergoing a name change. After a long term debate, it was decided that we should differentiate ourselves from Drinkbox’s Tales From Space: About a Blob and Mutant Blobs Attack (the latter being a personal favorite of mine). While I personally fought my heart out for Gun Gun Galaxy, the new name ultimately came to be Adventure Into the Gun Galaxy. I think mine’s way catchier, but that’s life. I’ve never been the creative type.

agg.jpg

Last week was a bit of rough one for the entire team. Life got the better of people, and tasks didn’t get done in a timely manner, some not at all. My work still came together okay, but it was all a bit messy. The first thing I took care off was implementing the phase system for contracts. Each contract is now part of a certain phase, and won’t show up to the player unless they’ve completed enough from the previous phase. This is now stored in the same manner that gun-part and customization unlocks are stored. Speaking of which, those are now stored on the network, as I learned this week, in a JSON file. Lastly, I implemented a loot drop system. Enemies now have data stored in their prefabs for what they drop. Loot drops happen locally, giving each player their own, picked up on contact.

The most important thing I’ll be doing this week is helping our UI designer implement the interface he’s been planning out for the past few weeks. I know he’s very comfortable in engine, but our back end systems are also a bit confusing to jump into. Besides that, I’ve picked out a few bugs to start fixing. Currently, I’m re-implementing camera shake, which was taken out a while ago, and fixing how burst fire works on guns. There’s plenty more on the list of known bugs, and new ones show up all the time (we already fixed an un-clickable UI issue).

Besides that, I’ve been running more and more support for the non-programmer members of the team. With such a large team, people run into all sorts of problems, especially in regards to the tech and version control, so I’ve been trying to be on call whenever possible, to get them quick answers.

Tanden Engine Part 2 - Laying Out a Plan

As we enter February, it’s time to really get going with Tanden. While we’ve been working away for the past 3 week, we’ve also laid out a more detailed plan. It became clear very fast that everyone working on their own, on whatever they wanted, would lead to a slew of issues. Instead, we put together a somewhat in-depth feature list and schedule for what we’ll be doing over the next few months. In addition, there’s more concrete goals, milestone and stretch-goals, depending on how much we can do in our limited time.

My focus is on the physics system and math library we will be using throughout the engine. Here’s the more exact list of planned features:

  • Vector and Matrix Math: classes for the two common types of mathematical structures, allowing for normal operations and operations specific to those structures (e.g. Matrix multiplication, Dot products, etc.)

  • Primitives: Basic shapes used in both the physics and rendering systems

  • Basic Collision Detection: Detecting collisions in space between our objects

  • Mesh Collision: Creation and use of complex meshes, based on the vertices of models loaded into the engine

  • Rigid Bodies: “Physical Objects” that form the base-level of the world

  • Forces and Laws of Motion: Objects moving based on real world physics and properties, both natural and applied forces

  • Angular Motion: Like the above, but the rotation rather than position of objects being affected

  • Collision Response: Objects reacting appropriately, based on their collisions with each other, based on all their properties

  • Friction: Objects being able to move along others, and having that movement affected based on the friction between them

Going into the semester I had basic collision detection and vector math mostly in place. Everything else is on a timeline for the next few weeks, with hopes of having the core of our goals completed at the beginning of March, heading into Spring Break. Here’s the milestone dates:

01/28: Addition of more advanced vector operations, and baseline setup of Rigid bodies

02/04: More complex Rigidbodies, including the gravity and the likes. Implementation of essentially everything you can do with matrices.

02/11: Manually adding forces to objects, and having them moved based on those inputs. Some small updates to basic collisions, based on known problems and things I’ve read on improving their efficiency.

02/25: Complex mesh collisions, based on the meshes imported into the Engine

03/04: Collision responses for all our collisions objects. Before this point, they’ll just be make it known their colliding, without actually doing anything about it. Also, friction.

My hope is that these goals can be accomplished in a timely manner, based on a 5-10 hour work week, depending on the complexity of that week’s topic. Of course, there are a few unknowns, and according contingency plans. First, is the obvious question of working on a larger scale project with multiple people. Fortunately, the core systems to link everything together are already in place. My systems work independently, even though they might not be visualized. In the event that I’m left on my own, I could bring my systems into an existing engine, with rendering capabilities.

A smaller thing that I foresee is the discovery of things that I’ve forgotten in m,y plan. I’m certain there’ll be one or two things we need in the math library that I overlooked, so I’ll need to take a short while out of my time to add it. Anything larger coming up should be covered by the extra time we’ve left open at the end, though not ideal.

Of the current plan, the big question mark to me is mesh collision, from the ground up. I’ve got some basic ideas of how I imagine it to work, but I’m sure they’re not effective. There is, luckily, a fair amount of research and papers out there about the topic, so I should be starting to read and decipher a few PhD papers. If the conclusion turns out to be: there’s no way I can do this in a few weeks, there’s a variety of other physics topics worth tackling. Things like spring, breaking and soft bodies are ripe for the taking on the project.

Senior Production Part 3 - Cross Pollination

Week 2 was a big one, as we worked together to finalize design plans. As a result, I should have far more direction for my future work. However, this week was still a bit tricky to navigate. I started out by making a series of video for our designers. It shows the basic process of creating maps and missions. There’s already presentations going over the process, but when testing it myself, I found that the presentations didn’t quite cover everything. The main problem was that there’s a few small kinks and issues that need to be manually fixed. These small actions are better demonstrated in action than through text. In addition to the videos, I also added tooltips to many of the fields in the mission designer, to clarify the language in those.

The second major thing I was working on this week was advancement of the player progression and gun unlock system. There’s different factors that can change about how guns operate, and different parts that can be swapped out. The details of the systems weren’t really fleshed out enough yet, and some of what was being planned seemed to conflict with the systems currently in place. Luckily, the team was able to bypass these issues. I brought up the problem to the lead programmer. The next day, he brought it up at the lead meeting, and we walked into that weeks class with the issue sorted out. Lastly, I implemented a simple system for converting unlock data to and from a string, so we can send and store it on our network (using Gamesparks).

For this week’s sprint, I have a few more things planned than for the previous ones. That said, with the systems more clearly defined, getting things done should be lot simpler. First, I’ll be making more videos for our designers. Last week, I laid out the foundation of creating missions, known as contracts in Tales from Space. This week, I’ll go a bit more in-depth on individual objectives, and everything you can do to make unique content. After last week, I’ve got the actual process down, so the only hang-up would me YouTube not playing nice.

Otherwise, I’ve got lots of tasks relating to the progression system, which should have it’s base level implemented by the end of the week. I’ll give a brief summary of what the plan is. At the start of the player’s game, they’ll have a few basic gun featured unlocked. Basic single fire, one or two elements, and the like. As they complete missions, more and more options are unlocked. Our selection of guns is predefined, so weapons will become available once every part of it has been unlocked. I’ll be making this system more fleshed out and visible to the design team, for when they start making more guns. I’ll also be connecting the unlock data to our networking system. It’s not a hard task, but should help me get more familiar with how we handle data.

There’s a few more scattered features for me to handle. First, is the idea of phases. The current plan, is to have three phases of contracts. Contracts will essentially come in bunches, and once a certain amount from the previous phase have been unlocked, the next phase will open up. First, I’ll be adding the phases to the actual design tool, so they actually exist. And then, I’ll mess with the contract station, so that only unlocked contracts show up. Lastly, I’ll start to implement basic loot drops from killing enemies. What exactly is dropping (guns/health/money) isn’t sorted out, but the basic system of “when enemy dies, x% chance of dropping whatever” still needs to put in place. So, that’s scattered week, which I’ll be bashing away at for the next few days.

Senior Production Part 2 - Getting Back in the Groove

My first week back in the developer lifestyle went about as I expected. While there wasn’t a ton of work to be done, I still hit a few road bumps, both from getting back in the right mindset, and simply familiarizing myself with the code base. To start my week, I did a bit of work on the cel-shader Tales from Space will be using. It’s not very advanced, and will probably get some more love later in development, but it was a good experience in getting familiarized with shaders in Unity. I talked with my artists about whether or not to use bump maps with our models, and we’re leaning towards a no for the time being.

Later in the week, I started thinking more and more about player progression, and how the various parts of it will interact. Ultimately, that’s up to my designers. I attended my first of many design meetings, to get started on those plans. Lastly, I spent some time messing around with our tools for making maps and missions, to get an idea of what’s wrong with them, and could be improved.

As I get started on this week, I’ve started to get a better idea on what role I will be taking this semester. In short, I’ll be working very closely with our team of designers to turn their ideas into reality. I spent a good chunk of this week’s class time chatting with the designer in charge of player progression and weapons. We had a few different ideas, centered around simplifying the progression and unlock systems, to be more in line with the pick-up and play nature of the game. I don’t want to go in-depth on it, as we’ll be meeting tomorrow and finalizing things. But in line with that meeting, I’ll get some work done on player progression. I’ll also be exploring the best ways to serialize some of the data. It’s not too important, but it’ll get me in the right mindset for optimizing our networking.

My other role this week was to make the design tools more accessible to the mission designers. Last week, I realized that the associated documentation seems good, but doesn’t really translate to the actual experience. Especially in terms to few small bugs and kinks that have simple workarounds. Along with clarifying some of the documentation, I’m in the process of putting together a few videos, to walk through the process of making a level from start to finish. I’m actually pretty excited for where I’m going here. It’s a completely different direction from the other work. In addition, I hope it helps me get better at working as a team with designers, rather than as individuals.

Tanden Engine Part 1 - Go Hard or Go Home

For my Console Programming class, aka “make something of value” class, I’m engaging in a sizeable project with 2 friends of mine. While everyone else is making innovate games, or exploring new tools/systems, we’re teaming up to contribute to something far bigger. After getting a head start at the end of last semester, we’ll be spending this semester working on Tanden Engine, a basic rendering/physics engine. It’s a huge undertaking for 3 students, working only part-time on it, but when we succeed, we’ll have done something truly impressive.

We’re splitting our work apart into distinct sections, with some cross-over. My main focus will be on the physics system, while contributing a bit to the rendering and editor components. I’ve spent far too long being unsure in what direction I want to go as a game programmer, but hopefully this will help me decide. I know I want to be working further on the back-end, so hopefully I enjoy this experience as much as I hope I will. I’m both worried and excited about doing high level work, as well as the challenge of tackling a huge code base with a team, where I don’t know what exactly every line is.

We’ve got a ton of resources to aid us, and have already been getting our research in. We’ll be using Vulkan as the core of our rendering, some libraries to assist with model loading, and imgui to form the basis of our editor.

There are a lot of risks going into this project. The biggest thing is simply the scope of what we’re tackling. In addition, there’s the various things that come from working with a team. Besides needing everyone’s success for the project to come together, much of the work we’re doing relies on what others are doing. We’ve put together a tentative schedule of what we plan to do on a weekly basis over the semester, and hopefully we can closely stick to it.

The reality is, that this is our first time working on a project of this size, and none of us really know how much time we’ll have, with everything else going on at this juncture in our lives. We’re shooting for the stars, but we’ve got various levels of complete that we can use as a fallback. The base goals for my physics system is to simply have a few spheres bouncing around in our scene. The intermediate goal, and a large jump, is to have basic destruction of rigidbodies/meshes. Have a cube fall and shatter, or something of the like. Lastly, is the possibility of basic softbody physics, to add life to objects. For another class, I’ll also be tackling particle physics.

All in all, I’m nervous but cautiously excited for what will hopefully be a huge project and personal success!

My Teammates’ insights: Thomas McGillicuddy

 
 

Senior Production Part 1 - New Year, New Hopes

With a new year, a new team, a new game and new goals, there’s a lot to be excited for. As the semester rolls along, I’ll once again document my journey, in my final few months of college. The newly expanded Tales from Space team only came together two days ago, and work on this week’s tasks has barely begun. Still, I’ll take a look at what’s going on this week, in addition to how I see my role on the team, and where I see this semester going in general.

The one thing that clearly stands out from a programming perspective on Tales from Space is that it’s far less of a patchwork than other games made in Capstone. Systems need to be tweaked, and expanded upon, but there are functioning gameplay and production loops. On one hand, that makes my life a lot easier, but it also means I can’t just come in an fill a specific role from day one. Instead, I’m spending my first week with bit of mix of tasks, as the team figures out the specific areas of need.

I started my week by a reading over design pipeline documents, which should expedite content production, using a few tools made by our lead programmer. While it’s also good for me to understand them, my job was mostly to ensure they make sense for other people new to the system. On the topic of the design pipelines, one of the things I’ll be doing this week is testing those tools. It might just be cause there’s not much else for me, but I’ll choose to believe it’s because I’m the only team member who’s actually taken a software testing class. Later in the week I’ll be pushing the map and building creation tools to their limits, finding every minuscule edge case, and doing everything I can to break them. Honestly, writing it like this makes software testing sound incredibly fun.

The most important thing I’m tasked with this week is starting to build out the player progression system, and adding to the gun customization system. I think I’m doing the testing because I’m the “Testing Guy”. I know I’m working on this because I’m the “Math Guy”, and I’m damn proud of it. A lot of the exact specifications are still up in the air, and throughout the semester, I’ll be working closely with the design team to turn their visions into reality. I assume this process will continue throughout the year, as we adjust to feedback from weekly testing.

My last major piece of work for the week is getting started on the game’s cel-shader. Shaders aren’t really my preferred area of work, but there are some things to be excited for. I won’t be going anywhere in-depth this week, but ultimately, there should be a ton of values that designers and artists can tweak. As I’ve seen in previous projects, the same shader doesn’t work for every object. Different shadowing, different line thicknesses, etc. I’m sure this will leave me feeling dumb often enough, but hopefully it’ll also be rewarding to see how far I can push myself.

So, that’s what I’ll be doing this week. Well, and all the work I’m putting into my engine project, which I’ll be writing about in due time. Oh, and I should probably give a quick introduction to what Tales from Space actually is. I’ll finish by leaving the small trailer the original team put together back in November.

Capstone Part 10 - Final Thoughts and Moving Forward

As established prior, my team chose not to move forward with our game, and today is officially our last day together, before I join my new team next week. I’ll talk about them later on, but first I’d like to finish up reflecting on this semester, after having gotten more time to both think and discuss it with my team.

I’m not too proud of what I accomplished in terms of the product this semester, I’ve made that relatively clear. At the same time, I am proud of what I learned, and hopefully, I can be proud of how I’ve adjusted as a result, in the future. That said, I do hope that my teammates feel pride in what they’ve accomplished this semester. Everyone tried new things, and what we put together was great, even if not fully complete.

I’m confident we made the right choice by not moving on, even if we had looked forward to showing off our game. Nobody likes to present something they’re not proud of, which we were able to avoid doing. Since presentations happened, I’ve had a few conversations in the vein of “Oh yeah, you guys didn’t present. Why? Your game looked really cool!”, to which I truthfully responded that we weren’t happy with how everything had come together. Having these exchanges has been very rejuvenating, and encouraging. People cared about what we made, and recognized how unique and interesting it was. We weren’t just another game that failed, we were a game that failed, while shooting for the stars. I’d be remiss to not also mention the other team in our section, filled with more friends of mine. They ended up in a more complete state than us, but are also not going through. From what I could tell, they faced a similar problem of directionlessness as us, albeit in a different way. I know everyone from my team is very happy with where they’re moving on to, and I hope all of them are too.

On that note, I too am very happy with where I’m moving on to. I’ll be joining Bullet Mullet to work on Tales from Space, probably the game I’ve actually spent the most time with this year (outside of my own, obviously). I didn’t actually expect to find myself heading there, because their lead programmer is my roomate. We’re already working on a different project together as well, and are now essentially intertwined in everything we’re doing, which has the potential for disaster, but also the potential for huge success. That said, there’s a few reasons I’m very excited to be joining my new team.

From a specific team standpoint, I’ve landed on a team with people I know, many of whom I know as friends, others as classmates. The biggest thing is, that I’ve been reunited with three of my four original team members from Production II, where we had huge success together. It’s hard to strike gold twice in a row, but I’m really happy and excited to be working with people I know I work well with. The way their (and now, my) producer runs things works very well for me, and is conducive to getting the best work out of me. With the people I’ll be joining, I’ve got high hopes for next semester.

As for the more general reasons, I’m simply excited to experience new things. First, is that this is by far the biggest team I’ve ever been on. Last semester, it was ultimately eight people. This time, we’ll be going into the semester with fifteen. I can’t even begin to imagine how work will get divided up, and what roles everyone settles into. The other thing that excites me, in a bit of cynical way, is stepping into somebody else’s code. It might just be because I lack confidence, but I’m absolutely terrified of other people going into my code, and ripping it apart. Now, I get to be on the other side for the first time. Hopefully, I won’t be ripping apart any code though. Rather, it’s about learning the codebase, and adjusting my work to fit the standards. It could be a very humbling and professional learning experience, or it could just be incredibly frustrating. There’s a good chance it’ll be the latter, but I’m trying to take things on with a positive, learning attitude.

So, that’s a wrap for the semester. It had its ups and downs, but more importantly, I learned a lot, which is ultimately why I’m going to school. Now, I get to not go to school for a bit, and get some much needed rest. Not that I’ll actually take a break, as I lay out the projects and work I’m hoping to do over the winter…

Capstone Part 9 - Reflections of the Team

This is the second part of my reflections on my time working on Capstone, and the last before I have a larger discussion with everyone in the class. This is going to be a lot tougher to write than part 1, because instead of critiquing myself, I have to critique the team. Not as individuals, but how we worked together. I think everyone’s been open about their failures and successes as an individual, but realistically, the burden lies on the collective, not the individual.

The most base level thing I want to look at is the actual composition for the team, and the relationships between people. Our producer and artist are long time friends. Our artist and I have been good friends since freshman year. The producer and I tangentially knew each other. The designer had worked with the other two before, but they didn’t have a personal connection. I had never spoken to her, before she reached out to me, asking to form the team. In short, there were varying levels of knowing each other going into the project, which I think was a small issue. There’s risks to working with friends, and risks to working with strangers, but working with a weird mix, can lead to uncertain power-dynamics and uneven levels of communication, as we experienced this semester.

Going into the two aforementioned points, I’d like to touch on power and leadership. Nobody on the team was a clear-cut leader who could confidently speak on behalf of everyone. Some of us weren’t outspoken at all, some only about their individual position and work, but nobody who would take charge. I noticed early on in the semester, that my opinion was valued and respected when I suggested to kill one of our prototype, and wasn’t questioned. But instead of building on that, and continuing to voice my opinions, I spent the rest of the semester silent. In that same vein, I want to point out a major positive experience I had with the team. People respected my knowledge and authority on programming. I’ve often had problems with people who don’t know my work, continuously pushing for features that were out of scope or simply impossible. Here, the few times I made a call, people listened and understood. I only hope that I made them feel the same way, in regards to their field.

The last thing I’d like to talk about for now, is communication. As already mentioned, none of us were really outspoken, which also lead to major lack of communication. My Production II team last semester, met far more frequently. At the time, I thought it was a bit unnecessary, but I see now the importance of it. It really helped keep everyone on the same page. Frankly, I’m not sure how it ended up as badly as it did, but there were various points throughout the semester, where people had completely different ideas of what the game is. That’s also on a more general level the main thing we discussed after deciding not to present. We spent too long being directionless, which left us needing to do more work than we could in the time remaining. That, being another issue that could have maybe been solved with a more outspoken leader.

As with the individual reflection, I’ll have more to say after our big discussion, but I think I’ve covered the core here. The issues that I identified in retrospect actually align a lot with what I was afraid of, going into the semester. That said, I want to make it clear that I love everyone on my team, had a great time with them, and wish them all the best on their future projects, where hopefully we’ll be able to take this experience as a lesson, and avoid the same mistakes.

Capstone Part 8 - Reflections of Myself

I’d like to break my reflections of my Capstone semester into 3 parts. This first one, focusing on my individual work, experiences, success and failures. The second, looking at my team as a whole, and what went wrong and right. And lastly, more general look at everything that’s gone down, after talking with everyone else.

The first thing I’d say when talking about my Capstone, is that it was incredibly nerve wracking. Stressful and tiring? Yes. Fun and educational? Yes. Disappointing and satisfying? Yes. But more than anything, I was incredibly nervous the whole way through. I think the nerves came from three different places. First, was the simple fact that I didn’t want to let my team down, and as I’ll go into later, I think I did in many ways. Second, was the general nervousness around the scope of project. There were many fears I had about what we were getting into, and unfortunately, a few (but not all) of them were well founded. Lastly, the expectations were getting in my head too much. Not just the expectations of making a good game for capstone, as everyone has. But, the success I had last semester, with Rolling Thunder, being the only juniors to go to PAX, made it feel like I had too much to live up to. Ultimately, there were multiple reasons why the project didn’t quite come together, but I think me being more collected would have been a big difference maker.

One of the biggest things I learned this year was the importance of communication and honesty. Not just with the team, but with yourself. I wasn’t a big fan of our game, and I know for a fact that I wasn’t clear enough when expressing that to the team. Nor was I outspoken enough about the concerns I had with the scope. But more so than that, I should have been more honest with myself. Capstone expects us to put in about a dozen hours or so a weak, but to really meet expectations, artists and programmers especially, have to do around twice that. With all the other classes, projects and jobs we’ve got going on, that’s no small task. But, when you love what you’re working on, it’s very doable. I didn’t love what I was working on. Yet, I told myself, I would still be able to power through, and put in the necessary hours. As the weeks went on, it became more clear, that wasn’t happening, nor was it going to happen. I don’t want to make it an excuse, but I need to be more conscious of the different amounts of effort I’ll put into a project, depending on how I feel about it.

On a more technical note, this experience has definitely helped me get a better grasp on what kind of programmer I want to be, and the kind of work I enjoy. I went into the semester thinking I enjoy gameplay programming. Who wouldn’t? It’s where you get to be directly involved with the player experience, and I love playing games. But as the weeks went on, it just became tedious. I spent too much time tweaking things, and getting instantly visible results isn’t actually that nice when the results suck. I started having fun again when, far too late, I started messing around with tools and background systems. They made me feel powerful and in control, and the whole idea of making the computer do what I want is a big reason I got into programming in the first place. This has only further been backed up by my engines class, where I’ve now committed to a huge, multi-semester project, with some of my friends.

I’ve got a lot more stuff to talk about, like planning, scheduling, more in-depth discussion of scoping and communication, and a whole lot more. But I’ll save that for parts 2 and 3. To conclude about my personal experience and growth, I think what I learned this semester is far more valuable than what I produced. You learn through failure, and I experience a whole lot of that. Being able to mostly answer what kind of programmer I want to be is a huge step, and not at all what I expected.

Capstone Part 4 - The First Casualty

Dramatic title aside, this week’s sprint planning meeting did include the major decision to scrap our third, yet to be started, prototype: the beat-’em-up. Really, it was my idea, but everyone else was onboard with no convincing needed. I appreciate the trust a lot, especially having often found myself pressured into taking on too much work, by people with no idea how long it takes. As a matter of fact, everyone was on board so fast that I don’t think I even had time to state my reasons, so I’ll do that now. First, is the fact that all our prototypes were pretty sizeable efforts, and we only had so much time. It made very little sense to spend so much of our semester on them, especially when we’d be completely scrapping 2/3rds of the work we did. So why this game? Well, there’s the simple fact that we’d started work on the other two, but not this one. Along with that, I thought it just wouldn’t prototype well with time constraints. A beat-’em-up without animations is never gonna appeal to anyone. But we don’t have an animator. Our artist can, and will have to make some animations for any game we do, but they’re most important, urgent and simply the highest amount, for this game. So bye-bye you go, maybe we’ll encounter each other again in the future…

With that deed complete, I did still have two games to work on. I’ll start with my struggle against Project Nugget.

When I last left off with my chickens, they were refusing to move. I decided to abandon the AI system, and get the nuggets to move with basic interpolation. I’ve done it dozens of time before in Unity and from the ground up. It’s second nature to me, and easy. RIght? Wrong. After a bit of reading, I learned how to move things with a lerp (and timeline) in Unreal. Okay, why is only the last member of the chicken array moving? I think this is the first time I’ve gotten upset with Blueprints, because I was genuinely left the dark about what was going on, and no easy way to see what was going on. After more reading, I think the issue appeared to be how timeline inside the built-in for-loops work: they don’t. So I think I’ve figured out the issue, or I’m blaming the completely wrong thing. Either way, this is another thing I take issue with. I don’t want to call it a problem, but more of an inevitability about engines: they want you to do things their way. I originally made this realization when I was abstracting functions for my Game Architecture class, and it’s stuck with me since. When an engine has a specific way of doing something, you generally have to accept it, even if it doesn’t align with how you’d normally do it. Worst case scenario, it simply doesn’t allow something you want to do, and you have to find an over complicated work-around. In my case, I just made the chickens teleport. Whoops.

As for the paint game, I had an easier time this week. First, I spent some time cleaning up the combination of spouting paint and placing decals on the floor. Like, not doing those things when you’re just standing still. Then, I started to mess around with wall riding. That was the first of multiple special movement options I’ll be implementing over the coming weeks. Ultimately, this would largely be visually demonstrated through the character animation. I was just using the basic 3D “Unreal Dude” that comes with the starter content. So to demonstrate him riding on the wall, I just turned him over 90 degrees. It looks ridiculous, and occasionally he’ll start spinning around back and forth. People like it a lot. In addition to riding on the wall, paint should also be placed on the wall. And it did so just fine… until you went into a corner. Corner paint decals got all sorts of stretched and mangled. I don’t think it’s important at the moment, but I hate it. It bothers me on a deep internal level, and I vow to fix it next week.

So, I shall return next week, to tell the tale of my battle against corner decals…

Capstone Part 3 - Testing Base Mechanics

If last week was about establishing and researching core mechanics, this week was about starting to implement them on a base level, to make sure they actually work. As such, I continued to work on Project Nugget, and starting getting to work on the paint game.

For Project Nugget, I was supposed to get chickens to move as a group, to a point you direct them to in the map. The first thing I tackled was being able to click somewhere in the world. The thought of finding a point in the 3D world, from the 2D screen originally seemed daunting. However, doing this in Unreal turned out to be surprisingly easy with the Mouse Location to World Space node, and a line trace (ray cast). The real problem ended up being moving the chickens. I figured I’d have an easy time, thanks to the engine’s built in AI systems. I followed a tutorial to get everything set up, and it seemed like it should work. But it didn’t. After spending a while trying to make it do something, I decided to put it on hold. The other part was spacing the chickens out, which should have also been part of the AI system that wasn’t working. That was an easy (short term) quick-fix with placing individual chickens at a random point within an an area.

For the paint game, my artist spent a while wracking his brain over how we should be placing paint in the world, ultimately deciding on a complicated system with swapping textures. Then, I took him to meet my programming professor with me, to explain what we are trying to do. We received a lot of suggestions, including the use of decals. Decals were actually my artist’s original idea, but he was concerned that they’d eat up processing power fast with how many there’d be. However, along with the ability to dynamically batch them, it’s also the simplest option, by far. Which is where my favorite programming principle: KISS, “Keep it Simple, Stupid”, comes into play. There’s no need to over complicated, especially since we’re really just prototyping for now, and very pressed for time.

My work for the paint game was split in two parts. First, detect where the paint particles shooting out of the character’s feet were colliding with the world. Then, place our paint decals at those points. I think I sort of figured out particle detection, only to totally scrap it. The paint is coming out of the character’s feet, in a trail behind them. KISS. Just place the paint decals where the character is.

The big lessons I took out of this week were about communication. First, the fact that I should make an effort to get help from my professors, who inevitably know more than me, and are more than willing to offer help. Secondly, that keeping in constant communication with my teammates is incredibly important, especially when our work intersects. We both know things the others don’t, both in terms of things we can do well, and our own limitations.

Now, to get those chickens moving…

Capstone Part 2 - Decisions and Research

After reconvening, sharing and discussing all of our ideas, we were tasked to narrow it down to 3, to pursue and prototype over the next few weeks. Long story short, none of mine were chosen. I wasn’t really upset about it, cause ultimately it just came down to what both my teammates and the other team in our class found more exciting. These are the 3 we did choose:

  1. A combination between a farm simulator and a strategy game, revolving around breeding an army of chickens, and taking them into battle against large-scale monsters. Those monsters would then drop items you could use to breed magical chickens with special properties (fire chicken, zombie chicken, etc.) It sounds a bit ridiculous, but uniquely fun. This was my personal preference out of our choices, because it’s simple to program at a base level, but then gets into a bunch of interesting math. And an army of chickens just makes me smile.

  2. The second game is a blend between the 10 year old (though recently remastered) De Blob and 20 year old Jet Set Radio. You play in a colorless world, and spread paint by riding on your rollerblades. What I like about this idea, is that it’s grounded, unlike a lot of capstone games, which rely on a level of dumb-fun instead of actual great gameplay. But speaking of gameplay, this game also scares me a lot. Mainly the fact that making fluid 3D movement is really hard, especially with an unorthodox way of moving.

  3. The last game was actually a combination of two different ideas, because we liked both, but neither was too expansive. The first part of the game is a side-scrolling co-op beat-’em-up, in the vein of classic arcade games, like Final Fight and plethora of licensed games of the sort. The players would play as Japanese style Sentai or Power Rangers, as we know them in the West. The second part of the game is Shinkansen Joust, where giant mechs ride towards each other on bullet trains and smash each other with lances. I don’t know where this idea came from, and I’m pretty content keeping it that way.

For my actual work this week, I focused on three things:

  1. Getting everything (specifically, our repository) set-up and working, and making sure everyone on the team knew how to properly use it. I actually ran into a bit of trouble with this, because Unreal Engine’s documentation on repo integration is spread out. I originally tried to use an ignore file that was missing some folders I should be ignoring.

  2. Start working on the first prototype, now referred to as Project Nugget. It was really just about seeing how many nuggets (aka, chickens) I could get to spawn in a scene, both from a performance standpoint, and from a visual perspective.

  3. Starting to do some research for the skating game, and how to implement some of the more complicated systems. One of my programming teachers was present and had mentioned that Unreal allows me to detect collisions of GPU particles, so we could use that to “realistically” determine what parts of the world should be covered in paint, as it comes out of our character.

All in all, it was a pretty slow week, without much trouble, besides the repository issues. I’m happy with how the team is starting to mesh, although a bit concerned that our games are a bit too large in scope, especially if we spend too long trying out different prototypes.

Capstone Part 1 - What Game Should we Make?

Starting Senior year brings the biggest challenge I've faced in my education so far. In Sophomore year, I worked with three teams over a semester, making games over a 4 week period. In Junior year, my team worked on a game over the course of an entire semester. Now, the goal is to spend the entirety of my last year at college making, marketing, and possibly publishing, a game. Over the course of the next 9 months, and possibly beyond, I hope to document both my and my team's experiences along this journey.

Our first week in action was relatively calm, as we simply focused on compiling our own ideas, to create a list of possibilities, before narrowing it down to a few we want to prototype. On an individual level, I simply had to come up with 5 different ideas, though these could all change over time, especially after hearing more opinions on them. In no particular order, here they are:

  1. My first idea is in on one of my favorite genres of games: dungeon crawling roguelikes, or "roguelites", as they've been re-dubbed by strongly opinionated individuals. Specifically, I drew inspiration from Edmund McMillen's The Binding of Isaac, a game I spent far too many class hours playing through High School and College. Instead of biblical and bodily themes, I was setting my sights on carnivals, fun-houses, and creepy clowns. It should also give me an opportunity to work with procedural generation, which I've been itching to get back into.

  2. The next idea draws from something I really fell in love with during my years at college: card games. My artist, who also had a similar idea, was actually one of the people who introduced me to Magic the Gathering. Both our ideas however, were deckbuilding dungeon crawlers. Personally, I was recently enamoured with MegaCrit's Slay the Spire, and using cards as your move-set. It's very reminiscent of using dice to play Dungeons & Dragons. Thematically, I was still looking at creepy clowns, but branching out a bit. DIfferent groups of classic monsters (zombies, vampires, werewolves, clown, etc.), would work as the different tribes, offering their own types of cards, and unique combinations.

  3. My third idea was inspired by a combination of things. Playing God of War back in May created a longing for more games with a Norse mythological setting. However, I didn't like that the trolls in that game were of the evil, brutish variety. I prefer my trolls to be a happy village of little creatures, like the Smurfs. In terms of gameplay, I was hoping to go with a 3D platformer / collectathon, in the vein of Hat in Time or Mario Odyssey. Oh, and it takes place during Ragnarok, because death and destruction are exciting!

  4. One of the settings in games that people have most tried to replicate, with little major success, is Rapture, from Bioshock. I don't want to try that, but the idea of subterranean civilization does intrigue me. A game I know little about, except what it looks like, and what I can infer from it, is Sunless Sea. Explore, collect (in my mind, mining), transport, and thrive in a civilized underwater society, while travelling in a submarine. It's all very loose for now, but I think there's a lot we could do with it.

  5. The last idea is probably the least expanded one, and the one for which I have the least clues on what to do with it. The idea of time manipulation as a puzzle mechanic really pulled me in. The first thing I came up with is a broken, dilapidated bridge, which you fix by turning back time. Like I said, not very expanded, and I doubt we follow up on this one, but if we did, I'd be leaving a lot up to my designer.