Capstone Blog #4

Week 4: Making a Maze

As I wrote about last week, most of the team’s been leaning pretty hard toward doing the spider-tank game, but Nick O. still really wanted to give the co-op maze game ‘Daedalus Trials’ a solid chance, and so did I. By the start of this week of work we had all decided we didn’t like the strategy game compared to the other two concepts, so we’ve decided to make our three prototypes be these:

  • Daedalus Trials, to try to prove the communication-based asymmetric co-op experience
  • Arachnotron A, to try to prove the concept of fighting waves/rooms full of smaller computer-controlled bug-bots to get upgrades
  • Arachnotron B, to try to prove the large-scale Shadow of the Colossus meets 3D bullet-hell boss battle style of experience

Because we already have a solid base for Arachnotron, we spent this week on the Daedalus Trials prototype. Despite my leanings toward Arachnotron, I still really like the idea of the co-op experience I intend for Daedalus Trials, but my concerns that the game would have to be relatively systems-dense to really prove the concept were realized. We put in a lot of work on it, but it was still lacking when we took it in for testing on Monday.

Nick R. and I once again divided the work pretty well, with me improving the runner’s movement & building the maze, and him making the overseer/guide and the traps for me to place as obstacles. I was pretty happy with how the runner’s controls turned out, I was able to create movement that felt like Half Life–mostly because of how I incorporated that game’s signature crouch-jump mechanic–with more speed & momentum.

I think the runner player controls provided the level of depth I was going for, with the ability to get going surprisingly fast with enough skill. However, it turned out designing a maze-like level that worked well with these mechanics, that was both big enough and obstacle-filled enough to be interesting, was a lot of work. With only part of a day left to work once I’d set up the maze, it was too late to adjust the maze to work well with the speed and momentum the runner could reach, and it ended up feeling imprecise and floaty instead of satisfyingly fast because the maze was on the small side.

The Overseer/Guide/Builder/whatever-we’re-calling-it-now role ended up kind of bare-bones, able to see a simplified map of the maze, so they could guide the runner to the objectives and disable traps to help them out. I’d been afraid the overseer would have too little to do compared to the runner, but from how QA went, it seems I over-corrected in that area, and the runner actually felt like they had less to do. I was unable to be present, but from what I’ve heard from both Nicks, it was mostly the overseer doing the talking and the runner waiting for instructions. From what they saw during testing it sounded like the prototype proved the concept better than I expected it to, but of course needed more feedback to help the players communicate.

Team Dynamics

Still nothing really to complain about so far, but my minor concerns from last week remain present. Nick O. has still been a little less organized than I’d like to see, neglecting to tell us the Monday meeting was cancelled because of having QA that day instead of Saturday, leaving Sean and me to wait for both Nicks for a while before checking in on the chat to find out.

I’m still feeling like I’m able to get things done a little bit more organized, quickly, and efficiently than Nick R. when working in-engine. I’d hoped I could learn more about keeping my code clean and organized from him, but unless he’s waiting until after the prototyping phase to get things cleaned up, his work leaves some things to be desired. I’ll make no secret of this once we decide to focus our work on one concept, ’cause if it turns out I can actually help him organize his work better, I’m more than happy to oblige. Maybe I learned more during my internship at HitPoint over the summer than I realized.

I’ve still seen relatively little from Sean, but he sounds quite aware of this. He’s made it clear he’s not the best at 2D concept art, and he’s excited to start really getting into it once we decide which game we’re doing, so I don’t fault him for it. I expect he’ll come up with some cool stuff in the coming weeks assuming we reach consensus on doing Arachnotron like I expect we will.

I don’t usually gravitate toward the leadership role, but I think I have enough strong ideas about the direction of the game that I could see myself being a bit of a leader in our work on the game.

Going Forward

We’ll be planning next week later today, but I’m already fairly certain we’ll decide that Arachnotron is the way to go and start separating the prototypes for that game. Ideally if both different styles of gameplay for that game pan out well, we can combine them into one experience down the line. It seems like I have a much better idea of how to improve the spider-tank’s movement than Nick does, from a technical standpoint, so I’ll probably volunteer to focus more on that while he puts together some basic enemy AI. I always love putting a lot of work into the finer points of the player feedback and game-feel, so me programming most of the player control logic is ideal for me.

Everyone we’ve shown the spider-tank prototype seems to have thought it was pretty cool, which is of course pretty motivating for me to keep working hard on it. I think it’ll have a solid core mechanic of climbing over any surface and using the two firing modes, and there’s a lot we’ll be able to do with it. It provides some interesting opportunities for both combat/gameplay design and level design, which are some of the areas I’m most interested in. Plus there’s room for Nick R. and Sean to stretch too, with AI, working together on some technical animation, and enemy design. The way the game’s design will make us all work together closely will give Nick O. a chance to really help us keep it organized and focused, too. I’m excited to see how the next few weeks go.

Capstone Blog #3

Week 3: Building a Spider

This week the team went all in on our Spider Tank game idea to start prototyping. At the beginning of the week, we explained the 3 ideas we had settled on to the class, with a small presentation to aid it, and the response we got changed some of my thinking about our concepts.

The Daedalus Trials, the 2v2 maze-runner game, wasn’t so well received. I don’t think we explained it very well, because the design I’ve written up is fairly complex. I still believe it’s an interesting, cohesive idea, but I’ve realized now that the density of systems required to get it close to the idea I have in my head is a little daunting.

Love & War, the strategy game, has lost my interest more and more as the week has gone on. After we presented it in class, many people thought it sounded a bit out of scope, and I think they might be right. Creating an interesting strategy game on top of the dating-app army building mechanics would not be an easy thing to do. Plus I think it’s just outshines by the other two ideas, it feels like the dating-app army-building is the only gimmick it has.

And lastly the spider tank game, which I’ve given the rather silly title of Arachnotron, for the time being, has become my favorite of the bunch. I managed to find a couple examples of how something like that has been done as a brief segment in other games, and that gave me enough inspiration to figure out a design that I liked for this one. It’ll be a great opportunity to attempt some really good combat flow design and level design, which if done well will be very good to show to potential employers in the future. I was afraid the wall-climbing would be a frightening technical challenge, and while it still was, it was a challenge we were able to overcome this week, with startling success!


Nick R. and I spent two days working on the prototype for Arachnotron. He was working on the wall-climbing movement and I was working on setting up the basic controls for the combat mechanics. We got off to a good start the first day, with Nick creating some pretty smooth movement over a 90 degree corner, from floor to ceiling, and some movement and aiming controls that felt pretty good on the ground. However, when we continued work the next day, we found his wall-climbing code didn’t work when going over the outside of a corner, like from a wall to the roof of a building, for example. We spent a bunch of time each working this problem independently, sharing ideas and discussing our approaches. I’m proud to say in the end the system that works well was my work! I won’t go into the technical details much here, but it’s fun to know our simple cube of a spider-tank essentially has 8 “legs” going out to check for changes in the floor around it as it moves.

Team Dynamics

Our team has continued to work well together, but I have some very minor concerns which I hope to smooth out soon. Nick O., our producer, has been less on top of things than I’d hoped for, with no meeting schedule posted until I asked, and relatively little planning in regards to our in-class presentations. I plan to ask him about taking notes on our meetings, QA sessions, and class feedback, because I think those will be very valuable, but I don’t think it should fall to me to do. I have plenty of other things to do on the project.

I’m curious how dividing up the programming work will be for Nick R. and myself, because I’m eager to enact my ideas in-engine, and I have a lot of ideas for how to do it. In the end, though, he should be doing more work on the game’s code than I should, since he’s the programmer. Because the prototype for Arachnotron was almost entirely my work, despite our initial plans to divide it up, I’m a bit worried I’ll end up doing a lot of programming just because I’m able to come up with good solutions to certain things before he does. Once we pick a game to go forward with I don’t expect that’ll be a problem, but since I already feel a bit like I’m needing to suggest ways for Nick O. to do his job better, I want to avoid stretching myself too thin across the various roles of the project unless I can improve my time management.

Going Forward

Tomorrow in class we’re going to focus entirely on showing off our work so far on Arachnotron. I’m still waiting on Nick O. to put together some slides, but I’m looking forward to showing off the prototype; it’s the most complex movement system I’ve ever coded, and it turned out less rough around the edges than I’d expected for the first week of it. After that, we’ll have to decide what we’re doing next week. I’ve suggested working on both the maze runner and strategy game prototypes because I’m so sure Arachnotron is a good idea, and I want to settle on one game as soon as possible, but we’ll see how our discussion goes.

Capstone Blog #2

Week 2: Solidifying the Concepts

This week, we narrowed down our ideas into the three we think will be the most interesting to develop, engaging to play, and feasible to create in the time we have. Here are the three we’ve decided on, some of which may be familiar from last week’s post:

  1. The 2v2 Maze Runner, with one player building traps, and guiding the other, who runs through the maze as best they can.
  2. A strategy game that uses an interface like a dating app to build your army. With funny profiles for each general, you have to try to put together a balanced force based on the limited information provided, and then command them effectively to take your opponent’s base.
  3. A fast-paced action game where you control an insectoid battle-robot that can climb on the walls and ceiling. Try to get to the end and defeat the boss without being destroyed, and get a randomized set of abilities to use each attempt.

Most of the work I’ve done this week is to brainstorm exactly how each of these might work, and write up a design concept document to guide our thinking on each idea going forward. I won’t go in-depth on the exact design of each here, but here are my thoughts on the designs I’ve come up with so far:

The maze runner, which I’ve dubbed “The Daedalus Trials” for the time being, since I thought it needed a cool name, seems like the most well-defined idea we have. I can imagine most of how it would work, and what I imagine seems like a really engaging, cohesive game design. All of the systems involves interact well and it seems simple enough that it will be both doable, and have a lot of room for more complexity once we solidify the basics. This is the one I’m leaning toward most at this point, especially after I spent some time making a prototype for the runner’s movement, and I got it feeling pretty good already.

The strategy game was one I was unsure about, but after spending some time thinking up how it might work, I’m getting more excited about it. The unpredictable nature of building the army combined with the humor we could build into the generals profiles seems like some good, casual fun, and I feel fairly confident I can design a simplified real-time strategy combat system to make it both approachable to inexperienced strategy players, but also deep enough to be engaging beyond the initial set-up phase.

The battle-bug ‘Spider Tank’ robot game is the one I’m least confident in at this point. It’s one Sean, our artist pitched, and I can see it looking very cool, but designing it to be both unique enough in its gameplay and not so technically challenging that we couldn’t make it has been challenging. All I’ve been able to figure out for it so far has seemed too similar to existing games to me, and I’m not sure we could do it well enough for it to be worthwhile.

Team Dynamics

Our team has worked well together so far, there’s not much to talk about in this regard yet. Most of our teamwork has been in our brainstorming meetings, and those have gone well, it feels to me like everyone’s voice is being heard. Sean, our artist, was pushing for us to use the Unreal game engine, which Nick R. (programmer) and I are unfamiliar with, but Sean seems willing to use Unity if that’s what we want, so I’ll be glad to stick to what Nick R. and I know. It’s much easier to make 3D art look good in Unreal though, so I want to do what I can to help set up Unity to do the same, because I’m sure Sean is capable of some excellent stuff.

Nick O. (producer) has been good at keeping things organized so far, but I’ve had a number of suggestions I’ve made to help things run more smoothly. During my internship at HitPoint Studios over the summer, I got a taste of the producer role, so there are some practices from my time there I’ve tried to bring to our team. So far it’s been stuff about the organization of our digital communication through Slack, and how notes are taken during the meetings. I’ll see as we settle into our organization system if there’s more I can do to help Nick O. keep things going well.

Going Forward:

Having started on a prototype for the maze-runner game, I’m quite confident we could do that one well. Next week Nick and I will be working on the prototype for the next game, probably doing Spider Tank next. I expect that one to be challenging to prototype, because a lot of the game’s appear would come in the polish that gets added later, so we’ll see how much we’ll be able to do on that. Overall, I’m glad to say I could see any of our three ideas working well. Some of my failed projects in the past were mostly victim to a poor concepting phase, stating production with limited intention regarding the game’s core experience, so I made sure to set a pretty solid statement of intent for each design.

Capstone Blog #1

Week 1: Brainstorming

This marks the beginning of the first semester of the largest game development project I’ve started so far. This week hasn’t been busy yet, with just one meeting to go over the ideas we have so far, and brainstorm a few more. I’m excited to see what we decide on, because this’ll be the project where we’ll most likely have the most creative freedom we’ll have on a team game project for a long time. We had to come up with at least 20 to show in class, and so far ~8 of those I’m confident would make good games based on our ideas so far. We’ll have to settle on 3 to prototype, so I think we’re off to a very good start.

To mention a few of my favorite concepts so far:

One idea we have that I think would be particularly interesting is a 4-player game, split into 2 teams of 2. It would be a first-person maze-runner for one player (think mirror’s edge style running, jumping, climbing gameplay), and a building/strategy game for their teammate. The builder would place traps and scout out the maze, and then advise the runner to warn them of traps and help them find good routes while they try to reach the other player’s start point first. It has elements of the tense communication-based co-op design I’m interested in experimenting with, and would likely be a good challenge in art, programming, and design. I think this is one of our better ideas so far; it’s simple enough to stay in scope, but has plenty of room for us to challenge ourselves.

Another concept I think would be a potentially good choice to prototype is an asymmetric co-op game where one player controls a big, slow, powerful thing, and the other player controls a small & fast flying thing. There would be various types of challenges that would require both players to cooperate and communicate to succeed. It could fit in many different settings, (capital ship & fighter, giant & pixie, high-tech spy car & remote control drone, etc.), and would fit in well with the tense communication-based design I’m interested in. As seen in both of these concepts, I’m really interested in co-op encounter design as seen in games like Keep Talking & Nobody Explodes, Overcooked, and the raids in Destiny. Examples of very different games, to be sure, but they have that certain type of cooperative game-play in common, and I want to try my hand at designing something like that.

Some systems we’ve talked about that would fit within a greater game concept:

A system to view the world in different ways, like having high-tech/magic goggles the player can put on to get different information from what they see, like x-ray vision or a fancy heads-up display. This would work in many different types of games, since it’s just a way to present more information to the player. It would have to be a game that is complex enough to have the need for more information, and the information the alternate views would provide would need to not be so essential that it should be part of their view all the time. Basically this system sounds interesting to use, but I wouldn’t want to use it unless the greater design of the game made it useful and necessary.

A system for switching ability sets by controlling different types of robots, but where switching from one to another has some form of risk involved. Like when you unplug a flash drive without ejecting it properly, you have the potential for corrupted files, the player could jump out of one robot quickly but risk having their control/HUD messed up, or spend the time to eject properly to avoid that risk. This one’s close to being a full game idea, but it still needs more to it to really be an interesting experience. This idea still has some potential problems, because messing with the player feedback/input to show corruption could easily become frustrating.

Going forward:

There are a number of other interesting ideas on our list, but those are the ones that have stood out to me the most so far. I mainly want to make something with more depth than I have before. Rolling Thunder, the downhill office chair obstacle course game I designed last semester was a success in making something very entertaining to a lot of people, but I want to make something that people would want to spend more time with this year. I hope to make something that has room for a lot more depth in its design this time around. The tense communication-based co-op I’ve mentioned is what I’m most interested in trying this semester, but I’ll wait to see the feedback we get on our current concept list before getting too far into any one concept.