Sign in to follow this  
getinthedamnbox

Help w/ twin-stick shooter brainstorming

Recommended Posts

I'm an amateur/indie dev planning my next game, and I was hoping I could bounce an idea off of you all. With the project that I just finished, I didn't seek a lot of feedback early in the design process, and I ended up paying for it later. I'm proud of how that one came together in the end, but I feel like it would've been well-served by some more brainstorming and prototyping early on.

 

So, now that I'm between projects, I'm forcing myself to slow down and think things through. Here's the current idea I'm considering:

 

It's a top-down twin-stick shooter that controls like Geometry Wars. The player's avatar (let's say it's a ship) has a variety of systems: movement, shields, weapons, etc. When a new game starts, most of the ship's systems are offline, the hull is critical, and the area is swarming with enemies. Warning messages are flashing; alarms are ringing; everything is red. The player has been dropped into a battle that they are on the verge of losing, and their task is to turn it around.

 

If the player survives for the first few seconds, systems will slowly start coming back online, and the difficulty level will recede. Eventually, they can go on the offensive, and the difficulty level will rise again---this time in the usual bullet-hell way of enemies becoming more numerous and powerful.

 

In this way, the difficulty curve would be a "U" shape. The first few seconds might feel like Super Hexagon, with quick deaths and restarts. The player would hopefully feel compelled to keep trying by the promise of getting their systems back online, stabilizing, and enjoying a respite before going on the attack.

 

A few more thoughts:

  1. I'd probably subdivide the ship's systems: shield quadrants instead of shield on/off, movement along each axis instead of movement on/off, etc.
  2. In a pre-game interface, I could give the player control over which systems are offline at the start and which order they are repaired in.
  3. Whenever the player's ship takes damage, a system could go offline. (Maybe there wouldn't even be a hull/health bar, and death would happen when the final system broke.) In this way, the U-curve of difficulty could repeat throughout a run, with the player periodically having to slow a freefall toward death, stabilize, recover, and then continue advancing.

What do you think? Should I consider anything else before I start prototyping? Scrap this idea altogether? Thanks for any thoughts you may have.

Share this post


Link to post
Share on other sites

I personally ditched twin stick shooting mechanic in my own project because I wanted mobility focused combat and twin stick shines with cover or other slow and methodical combat.  Without focus on cover or highly detailed management aspect the game becomes this weird 2 solved problem where with movement you just want to avoid things and with aiming you just want to hit things.

 

So I guess this is a way to just challenge the base of your project.  I mean if you really enjoy twin stick shooters go for it but do keep your options open and check out other methods (during prototyping).

Share this post


Link to post
Share on other sites

Cool, thank you. That's good advice, especially because, tbh, my rationale for doing twin-stick is a little shallow. Basically, I'm trying to get a lot better at game feel. The movement/aiming system of my last game was pretty unique (to my knowledge), but it didn't have much visceral appeal. The positive reactions I got were something along the lines of "it's cool that by the end of the game I could move/aim pretty well despite how challenging it was at first," which is what I was going for, but I think I lost a lot of people in the first few minutes of play.

 

When I think of control schemes that feel best to me right from the get-go, twin-stick shooter comes out on top for whatever reason. So, that's more or less the whole reason for starting with that idea. I'll definitely keep my options open as I work on it, as you said.

Share this post


Link to post
Share on other sites

I like a lot of the concepts you have in mind here. Managing the system order before you start, and the general mechanics sound fun. I don't think you need to feel that the U difficulty curve is required. I would just plan to adjust once you have something functional. My main worry with your U difficulty concept is that there might be a dull period once you got past that first hump... but maybe it will be a deserved break, I'm not sure. 

Share this post


Link to post
Share on other sites

Awesome, thanks. That's true, and I'd be worried about the other side of it as well: that the chaos of the first few seconds will be too likely to discourage players from continuing. I'll keep those concerns in mind as I iterate. I'm hoping that play sessions will be quick enough that I'll be able to find people willing to help test it. This was a challenge with my last game, which was slow and dialogue-heavy... tough to ask friends to make that kind of time investment.

Share this post


Link to post
Share on other sites

Getting someone hooked on 1-3 seconds of gameplay has to be tough. Somehow Super Hexagon does it. It's an interesting phenomenon, and probably a huge exit point for a lot of people. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this