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.

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.

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.