Arachnotron Post-Mortem Part 5: General Retrospective

This project could have benefited from much more (and better) planning, and management throughout. I don’t think we realized how much of a cool, unique thing we were making until toward the end of the project, and needless to say that led to a lot of unexpected complications throughout the project. Most of the first half of this second semester ended up as wasted work, but we pulled through toward the end.

All in all, I couldn’t have asked for a better final student project. It may not have been as successful as we’d wanted in terms of content quality and quantity, but it was an incredible learning experience, and damn fun to work on on top of that. We had to cut down a lot of the ideas we had, so I’d love to get the chance to try making Arachnotron again from the ground up with everything we’ve learned. I’m impressed by the quantity, diversity, and quality of work the team and I got to do on this project, and I know I’ll remember this project fondly for the rest of my life. Here’s to a long and successful career in game development for everyone involved!



Arachnotron Post-Mortem Part 4: Bosses

I love making boss-battles. That’s one thing I’ve really learned, working on this project. The way it brings together art, design, and programming really makes it fun to work with all parts of the team to create an awesome finale to a part of the game. Our lead artist seemed to enjoy it quite a bit, too. He and I both put a ton of work into getting all three bosses working. I still think the first boss is the best one, though.

Because we wanted the boss battles to be grand Shadow of the Colossus style battles, with the player climbing all over them and dismantling them piece by piece, the shape of the boss had to be a close collaboration between my design work and the art. The first boss’s shape came from the design of the fight first, and was later made to look more like a robotic bug, and then the design adapted to fit that more. The second boss, however, was more designed based on the art. We knew we wanted a millipede monorail to end up as the boss, so I was more constrained in the design of that one. Because of the limited time we had to plan, and how it was animated and pieced together because of that, I wasn’t able to make use of the wall-climbing mechanics nearly as much as I wanted to for that fight. As with many aspects of this project, I would’ve wanted a much longer planning phase to make sure the design used the game’s mechanics well and also made good use of the art.

The final boss was created mostly by the lead programmer, after an intense planning session between me, him, and the lead artist. It was meant to use abilities more similar to the player’s own, and be more of a environment and evasion focused fight than the other big robots that were the earlier bosses. It was surprisingly successful, considering it needed a lot more time in the oven. We barely got it working on time, let alone tested and improved. It was pretty fun to adapt the leg-animation system I built to an NPC though, I’d love to learn more technical animation at some point.

Arachnotron Post-Mortem Part 3: Weapons and Focus

The extensive weapons system I wrote up a design for early this semester was a mistake. As lead designer, it was my job to keep the project focused on a unified vision, but I lost sight of that a bit when we had all these new people who’d just joined. I wanted to make sure everyone’s ideas were involved, but I lost track of keeping a tight focus on what made the game special around that time. As a team, we came up with ideas for different weapons and set-pieces that would be really cool, so I wrote many of them into the design documentation. We were still amazed we’d gotten so much done in the later half o the first semester, so it was very easy to over-scope now that our team was three times the size.

A good chunk of time was spent on creating a modular weapon system in the code for the spider-tank, but in the end we only went with the four different weapon types. During a visit from Karthik Bala, he gave us feedback that really helped us get back on course with the project. He told us that the wall-climbing mechanic was what really made the game unique, and that we should try to focus on that, make it the best we could make it. After that, I realized all these new weapons we wanted to add were tangential to the coolness of the wall-climbing, if not actively diluting it. I felt bad about cutting a part of the game that one teammate seemed so excited about working on, but I think in the end it was for the best. At this point if I could do it over again, I would have tried to come up with a more focused weapons system, that would’ve emphasized the wall-climbing rather than distracting from it.

Arachnotron Post-Mortem Part 2: Art Pipeline

The technical constrains that came from the wall-climbing may have hit the environment art the hardest. To begin with, having never done much real environment art myself, and with Sean busy on the character work in the first semester, I just designed the level geometry in the first level as I went, figuring out what worked and what didn’t without much regard for what the art would take.

As it turned out, this was the opposite of what would work well.

The first real push to get environment art into the game was the rush to get the game ready for the MassDigi competition. It was a bit of a disaster. With only a week left, I finished up the final changes to the refinery level and handed it off to the artists. I didn’t really think about what their process would look like, and that cost us all a great many hours of extra work.

Because of how much the wall-climbing mechanic relies on the world geometry, there was an important list of constraints the artists would have to adhere to to make sure their art didn’t break the game. I neglected to communicate this well enough, so the art-pass they did was borderline unusable. The wall-climbing demands that there are no acute angles, small bumpy details, skinny outcroppings, or any objects set to an uneven scale in the scene. The art that was added had all of these.

Thanks to Pro-Builder’s mesh conversion tools (the add-on we used for level block-outs), I was able to go through each individual piece and make it work with the wall-climbing collisions without changing how it looked. Under the hood they’d be unrecognizable to the artists who’d placed them, but on such a tight schedule that wasn’t important at the time.

As soon as I got back from MassDigi, the design and art teams had a big meeting to discuss what we’d failed to communicate ahead of time, so we’d never have to do that again.

Future levels were designed with much more modularity in mind, and the final level in particular was constructed using less than 8 different pieces, if I remember right. It was a great lesson about proactive cross-discipline communication.

Arachnotron Post-Mortem Part 1: Level Design

In the business of working on Arachnotron while also keeping up with other classes, I lost track of the weekly blog posts. In their place, I’m writing an extended post-mortem, broken up into a few different parts to focus on different aspects of the project.

In hindsight, the level design is probably the part of the project that most needed extra time. Though there are plenty of similar games to draw on for the systems design in Arachnotron, the wall-climbing mechanic made it so that the level design had to be different from anything any of us had seen before. Us on the design team still don’t really have a solid understanding of what good level design takes in this game; we’ve learned a lot, and the stuff we made later in the project ended up being a lot more interesting and easy to navigate than the earlier designs, but I don’t feel like I can say we know how to do great level design in this game yet.

Because every surface has to be a viable floor to walk on–both from the design intent and technical limitations–there was already a lot more to consider than in your standard up and down grounded shooter. I struggled planning out the structure of a level ahead of time, and resorted to just white-boxing as the first sketch in the beginning. I considered using a VR drawing program to sketch out the shapes of the levels early on, but decided that would just take too long, since I was a solo designer at that point in the project. I now wish I’d remembered that idea for when we brought on other designers, because if I’d had everyone use the VR drawing tools from the beginning, the level design could have been planned much better.

With more planning, we would have ended up with much better levels. The way it ended up, we pretty much had to go with what we made, whether it worked well or not. Levels in this game are so involved to create in this game that we didn’t have time for major revision and re-do of anything. In most games, you can afford to have the shape of the level be relatively vague, add some art, and still maintain the same gameplay experience.

In Arachnotron, the precise world geometry has a big impact on the gameplay, so we had to make sure every edge, corner, and vertex were in line with the limitations we had to deal with. The three main rules of no acute angles, no outcroppings skinnier than the spider-tank, and no intricate/bumpy surfaces meant we had to be meticulous in creating the white-boxes of the levels, or the gameplay could easily be interrupted by the spider-tank’s wall-climbing glitching out and spiraling off into the sky.

Of course these constraints around world geometry became doubly troublesome when the artists came in to make the levels look good…

Arachnotron Development Blog #3

I think we’re finally getting back into the rhythm of it this week. Production is coming along well on the train heist level, with the other two designers finally getting more comfortable with the level-building tools we have. I’ve been focused on re-designing the first level, so that we can have that polished for any student game competitions we might have the chance to go to. Helping to manage a team this large has been a challenge for us though, since none of us have experience keeping things organized with this big of a group.

The combat system I’d put together last semester was somewhat disorganized, so I’m glad Cory’s been doing so much to re-organize it. However, he’s accidentally broken a lot of it in the process. I’m going to work with him and lead programmer Nick to get that all re-built in a way that works, and hopefully make it more designer-friendly. I want to be able to go in and adjust almost every little thing about the combat system, so I’m going to help make the system more modular and make sure it’s set up with all the adjustments and changes I can foresee wanting to make later on.

It’s still hard to know how well we’ll be able to meet our originally planned scope, but I’m leaning in a quality over quantity direction. I’m ready to cut some of the planned features I don’t think add as much to the game to make room for the stuff we do have to shine, but I still think I may not have to. I think next week will give me a better sense of where the team is at in terms of pace and organization.

Arachnotron Development Blog #2

The last week and a half started with the team suddenly getting stopped in our tracks by the green-light requirements we hadn’t fully understood. Dan, the professor running our section of Senior Production, wanted us to put together a thorough green-light plan before starting any new work on the game. He’d failed to communicate this to us at our first class meeting, since he was away and had to call in remotely, so when he told us about it the following week, our plans were brought to a grinding halt, frustrating everyone. As we met with him a few times throughout the week and put our plan together with a better idea of what he wanted us to do, we came to understand why he was having us do such thorough planning with no new work getting done, and the team warmed up to the process, realizing how much it would help us in the long run. I’m concerned for the scope of the game, since four relatively unique levels is a tall order to complete in just three months, but with careful management, I think our team has the skill and determination to do it.

The past few days post green-light have seen an explosion of productivity! I’d been concerned about having anything worth testing at some QA sessions, since Conor insists on taking the game to every one, but with how quickly our team is putting new features together, it’s been an excellent setup. I’m concerned as well that level design work is going to take a while to really get going, because the other two designers aren’t really familiar with the tools or any of the strange little considerations I’ve discovered last semester. I want to focus on systems, and I’d feel bad for taking over on any of their work, so I’m going to try to work with them as much as possible to get them up to speed on everything I’ve learned about how to make levels for this game.

Overall, I’m cautiously optimistic that we’ll be able to do everything we’ve set out to on this project. And even if it turns out to be untenable, the game will be awesome even if we have to cut a few features.