CS199 Reflection – Rat King

Introduction

This quarter marks the second quarter of independent study I completed for my solo game dev project, Rat King. For those unfamiliar, Rat King is my spin on the big robot vs. big monster trope, except the big monster is a swarm of rat revolutionaries and the big robots are piloted by their bird, cat, and reptile overlords trying to eat them. The vision is that each section of the game plays differently, with the bird sections playing like a side-scrolling space shooter.

Last quarter, I had built out a respectable boss fight for the falcon boss, and I wanted to spend this quarter building the stage for it. I ended last quarter with the goal of working faster; going lower-fidelity on the art for the time being in favor of getting the core gameplay across so I could test more and iterate more. I would say I had mild success with this goal.

On one hand, building a full stage instead of just a single boss room unearthed plenty of issues in the core gameplay that required me to take a step back. On the other hand, the stage building process also taught me how to work faster by designing assets and enemies to be versatile, allowing me to reuse the same asset to create different challenges.

 

Core Gameplay Changes

The stage’s design started out with a stage map, a strategy I learned from the stage design lecture in 247G. This was especially useful in helping me design the learning curve of the stage.

For example, I wanted to make these electric barrier enemies progressively more difficult to overcome by complimenting them with other enemies, and having a stage map helped me keep track of what enemies players knew about at each point of the level.

 

However, creating the stage map also helped me see a bigger issue. Though the game was supposed to be a space shooter, I built the stage more like a platformer, with elevation changes and such. 

Space shooters typically occur on a single screen where everything is visible. Since the player can move around the screen freely, the level design is almost 100% enemy placement. But for Rat King, having the entire level take place in essentially a single hallway didn’t create the feeling of exploring and traversing a place.

There were a few ways I managed to address this. The first was with camera movement.

In a platformer, the camera follows the player, but it doesn’t in a space shooter. At first, I just tried having the camera follow the player. But after observing playtesters, I noticed that they typically did numerous micro-movements rather than big swooping ones to avoid attacks. The camera aggressively shifting to follow the player even for tiny movements was distracting. The solution was to add a delay and ease in for the camera’s movement, so small movements created appropriately smaller camera movement, whereas for larger movements, the camera would pan quicker.

The second way was making elevation changes obstacle courses in and of themselves. If you can move freely, elevation changes or bottomless pits and such aren’t really challenges anymore, so it’s hard to justify them in this game. A really fun challenge was finding ways to turn elevation changes into challenging obstacles even with free-form movement. Some examples include this narrow section lined with hazard tiles where you have to time your upwards movement to the openings, or this section where the scroll shifts to vertical and you have to avoid enemies without being able to shoot at them.

 

These are just a couple of roadblocks I dealt with that really slowed down my progress. However, overcoming them both led to insights that would help all future stages I design for this game. It also showed me that thinking about game mechanics can only take you so far. You’ll have to actually build it out to some degree and play it to see if it’ll actually work out, likely many times for many iterations. Knowing that core mechanics are very likely to change after being transferred from mind to screen is an especially valuable insight for planning/scoping future projects.

This experience also made me far more comfortable in diverting from my game’s genre and its conventions. Even though space shooters don’t typically have panning screens, it doesn’t mean my game can’t. It’s definitely harder and requires more playtesting, since we’re playing around with ideas that haven’t been validated by past games. But at the same time, navigating that uncertainty almost always leads to a more innovative and interesting result.

 

Enemy Design

When I started working on this stage, I told myself that I would include no more than 5 unique enemy types as a scoping decision. In order to still have varied and interesting challenges, I focused on designing enemies to work in conjunction with one another; each enemy could be mixed and matched with another to create a different kind of challenge.

For example, these egg enemies that have temporary invulnerability when in their shells work really well with these electric barriers, since I can place them to block the weak points. The eggs also work really well with these archer enemies, since their straight shots fit right between the archer’s spread shots. Designing enemies in this way made it much easier in the teaching department. I only had a few enemies I had to explicitly teach players about, and from there I could focus more of the stage’s real estate on fun and challenging combinations of those enemies. It goes to show that designing enemies to be versatile isn’t only good for reducing developer workload, but can make a better player experience as well.

 

Lesson Learned: Building a Game from the Middle

As I was working on this stage, I realized that a lot of the principles of stage design apply to the design of a multiple-stage arc as well. Each stage should be built upon the lessons learned in the previous. This first level I’m currently building is actually the middle stage in the bird section of this game. It’s like designing the middle of a stage, and trying to build the beginning and end around it. It’s hard to design that middle section to be as fun and fair as possible if you don’t know for certain what info your player has at that time yet.

Therefore, I have some concerns that I should have built these stages in the order they appear in game. In each playtest, it’s hard to tell whether my game is too difficult or if they’re just not familiar with the gameplay yet because they’re playing the middle stage as their first exposure. I don’t think it’s the biggest deal, and I’ll proceed with finishing this stage first as planned even though it might need some hefty revisions after the other stages are made. Even so, this was a valuable lesson in learning how to design the arc of a whole game, especially important since it’s much harder to rapidly playtest a whole game versus just a single level.

 

Conclusion

Though I didn’t get as far in building this stage as I wanted, I’m at least confident that all the pieces are now there: the enemies, basic movement, and core mechanics are working well together and now it’s just a matter of assembling the pieces and testing the result. I’ve also developed some strong strategies for reducing my workload without compromising the quality of the game. Before this quarter, I had a lot of hope that being able to work and iterate quicker would come from gaining more experience, and I think this quarter was a strong testament to that. Though progress was still slow, the skills I developed will help the remainder of the level move a lot quicker.  

I’m very excited to use this summer to get this level and boss fight to higher fidelity (I miss making things look pretty) and start developing additional bosses and stages going into fall.