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.
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.
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.