Designing a Shmup from the ground up

[kevin koss]

Hello fellow shmuppers and shmuppetts. I have a question and a problem and it is my hopes that you can help with both.

Introductions are in order. My name is Kevin and I've been playing shmups since 1942 was on the Nes. I've played quite a few over the years and still find more that I've yet to experience. Always a pleasure to chat with like minded fans and aficionadod.

Now for the question and the problem.

I am an amateur game designer looking to design a shmup from the ground up. As i said, I've played quite a few and i have a general idea of what i want to create. More than a general idea really.

I plan to use Unity for the engine.

The problem: what are the things needed to design a shmup? I'm not talking about artist or programmers, but the games design itself. To date I've never seen a game design doc that outlines everything needed for even the most basic shmup.
Once you know what you want to build, you have to know how to build it. Can anyone point me in the right direction?

Any help would be greatly appreciated.

[n0rtygames]

Hey,

1. Create a method of spawning enemies on screen via code (or whatever method you want)
2. the most important part - game flow.
3.. um... more stuff

In fact, I'm going to make this post entirely about point 2 I think - since I see so many people not bothering to do this and it leads to projects not getting finished. If you put your game flow in place first, then the rest is just polishing and fleshing it out. Retrospectively fitting it just gets put off longer and longer, then it becomes a real PITA.

So, what's game flow?

1. Level starts
2. Some gameplay occurs
3. Player dies - game over - continue? return to main menu?
4. Player kills level boss or reaches level end - proceed to score screen
5. Player is done looking at score screen - transition to next level
6. Player has completed all levels - handle game ending

Obviously, you want to get a few basics down like a player ship moving around. Shooting projectiles, hitting enemies etc - but I cannot stress enough how much of this is actually irrelevant if you ever want to complete and finish your project.

It may be tempting to go nuts, spawn ten million enemies on screen. It might be tempting to fill the screen with bullets, get distracted with bullet patterns etc etc. But seriously, if you have just one enemy on screen, a single bullet at a time - the ability to kill that enemy - you have a game. Make sure you can repeat this loop for however many levels you want your game to go on for and then come back and start fleshing out the game loop.

Seriously, do this. It's boring as hell. It's the least fun part.. but that's why you should do it now

- Steve

[n0rtygames]

Also if you need help with Unity specifically, just ask. I'm quite well versed in it.

However, I do think there are better environments for making 2D shooters - if I'm perfectly honest.

[trap15]

Interesting idea for a thread. Maybe I should take notes on how I develop stuff, since it might be helpful to others, even if the tech details don't really apply to anything from the past 20 years

[gamingjustin]

I'm in the middle of my first project myself with no real experience, so maybe I can lend a hand. Definitely start designing as broadly as possible like n0rty suggests. I write down "fake" code a lot. For example, I'll share my take-off "code" for when the game starts (like in the old Raiden games).

For take-off sequence:
1. If the take-off sequence is playing, player loses control of ship. (I use a variable to switch control on and off)
2. Open hatch and start ship animation at same time.
3. Raise platform. IF power is level 3, create bit objects (little side ships that fire), IF shield timer > 0, create shield object.
4. Create jet animation.
5. Begin scrolling the screen; starts out slow then faster.
6. After a while, change jet animation to default and make ship controllable.

No functions or syntax were used at all, but the reason I do this is because it helps me think logically and see what the consequences might be at each step ahead of time. I then proceed to research the actual functions I need to use if I don't know them, and use proper syntax according to the programming language. In my case I use GML in Game Maker. Imagine very specifically what you want to do, then research how to express it mathematically according to whatever code or engine you use. Always imagine the consequences, and always design SYSTEMS, not like a linear series of unrelated events.

By that I mean: Make a system for spawning enemies that will work anywhere. Make it so that you can die anywhere without any problems arising. Make it so, if an enemy is off-screen, you can't shoot at it and it can't shoot at you. Try to design systems that are as universal and flexible as possible. It would be possible, for example, to design the entire game on a linear timeline-- a terrible thing to do: At time 0 spawn player ship, at time 5120 spawn this enemy, at time 67555 make the boss appear, at time 123679 make this specific thing happen. It could technically work, but would be grossly inefficient and if one little thing changed you'd have to redo everything. That was an extreme example, but hopefully you get the idea. A "thing" or a system should ideally work on its own without problems before you add it to the actual level.

To me, the most important thing when designing a game is having a strong imagination and the ability to foresee possible consequences and imagine solutions ahead of time. Just have a good imagination-- learning code and all the technical things are merely a means to express what you imagine. Also do not be afraid to jump in and make mistakes. No matter how much you plan ahead there will be unexpected consequences. The best you can do is maintain an efficient mindset. For example, you could draw an awesome boss that has all these sweet bullet patterns... only to discover the boss is too small for the screen and looks silly. It is more efficient to just whip up some crummy-looking thing that represents it and test it in the game first-- give it its properties-- to make sure the size is correct, that is moves the right way, that it shoots the right way THEN spend hours drawing it.

So to sum up some of the things I do that help me make a game:
1. Write fake code to guide my thinking in a specific way-- helps to see the consequences and provides a starting point for researching real code.
2. (Aim to) design universally applicable systems. Make sure all the "parts" can work (enemy spawning, what happens on death, etc.) on their own before putting them together in a level. Of course not every little thing can be a system, but I try to imagine where I can design systems for the sake of efficiency.
3. And maintain an efficient mindset. I won't be able to predict everything, but at the very least I try to make the job as easy on myself as possible. I don't go too far with an idea if I haven't actually tested it yet (anymore! I made this mistake too many times already), as it could turn into wasted hours later on.

The best design docs you can learn from are your favorite STGs. Reverse engineer them in your head and copy ideas from them. If there's a game that has a laser you really like, plan and code it into the game-- I outright copied the blue laser from Tatsujin. If you like how those asteroids scroll by in a certain level, copy it. If there's a game where the ship moves just right, copy it. It is like any other art; learn by copying the fundamentals. It saves time and you learn from the best. STGs are the oldest and longest-lasting videogame genre in existence, and has evolved more than any other, so there's no need to reinvent the wheel-- I say this for the sake of learning.

And remember the old adage: Google is your friend. If you run into an issue it is very likely someone else has already had your problem and received some help. There are plenty of people who share this passion who are willing to help.

And please take all this with a grain of salt, as I am a complete amateur with no real experience-- I have a half-finished game and am learning to code along the way. My advice is based on my own experience, not some expert authority.

[BPzeBanshee]

I agree with everyone's statements here, but one thing I'd like to add is having a bit of a plan for what you're developing and how goes a long way, in the game flow and also in your design choice.

What code base/engine are you using? Is your game going to be single-player? What are you going to HAVE in your stages? What kind of input will you support? Who's your target audience? Asking yourself questions like these are important too.

In my case, I decided to go with 2 players late down the track and while it could've been a lot worse for me, it's still a PITA whereas if I'd just designed it with 2P support from the ground up I would've been better off. I did however benefit from starting simple: get enemies on screen, get bullet patterns working, get player working, gradually building up to what I have now. On the flipside, I was able to replace my old encryption system for high score saving with another one in about five minutes since I designed GMOSSE to have each component more or less removable and organised. Things can come up during the development process that you may not be able to plan for too: how you plan your game can make the difference between such matters being little speed bumps in the road, and tiptoeing around a minefield.

[tibone]

I think that planning is the most important part.
To know what you want the final product to be, and how to get there.

Write down milestones and a general vision of what you want.
ie.

- A vertical shmup with manageable powerups, multiples ships, 6 stages, boss rush at end.

To get there, i like to use "user stories" (http://en.wikipedia.org/wiki/User_story) to help me get to the point that i first envisioned.
Also, i do think writing everything down makes it easier to get it accomplished, because it's very easy to aim high, get frustrated because something is really difficult and abandon the project. Also there's new project honeymoon, which is something that can be defeated by writing down, and i think user story is the easiest way to do that.

ie.
Player: Has to be able to move, shoot, control power-ups through a specific button, drop large bombs of limited amount with another button. Player can also choose a ship.
Boss 1: Looks like something, bullet patterns are x, y and z, moves like jagger, etc, etc.

You get the idea.
I think this applies not only to shmups of course, but can help a ton when working with shmups.

[nasty_wolverine]

Since most people here are talking about the idea-flow of things rather than the technical flow, let me try my hand at it.

**this assumes you already know a language and a rendering api

1 - Before you even start programming anything readup on FSM(Finite State Machines). 99% of games are designed as FSM's.
2 - Develop a framework, that opens a blank window, while initializing all backend devices (window framework, renderer, audio etc...)
3 - Create a state manager that lets you push and pop states
4 - Create states that can be updated and rendered
5 - Add in state transitions, so states can chain load, or remove themselves and load another state
6 - add in resource handlers, audio and video renderers, entities(ingame objects)
***at this point there is no game, but an engine
7 - finally start creating game objects, eg. players, enemies, bosses, huds
8 - throw them all in together and see what happens, dont like it reshuffle till you like it
9 - keep at it, you will have a game at the end of it

tips:
- keep things as modular as possible
- dont go new/malloc'ing away during gameplay, keep those at loading parts
- use object pools whenever you can
- dont couple update and render rates, will give you a headache with vsync off
- dont try to cover all scenarios, only ones which will arise in your game

[Formless God]

At time 0 spawn player ship, at time 5120 spawn this enemy, at time 67555 make the boss appear, at time 123679 make this specific thing happen.

In that case how do you work with enemies that appear at specific positions on the screen (like ground enemies)? You pretty much have to know when to add them so that they sync with the background correctly.

[nasty_wolverine]

At time 0 spawn player ship, at time 5120 spawn this enemy, at time 67555 make the boss appear, at time 123679 make this specific thing happen.

In that case how do you work with enemies that appear at specific positions on the screen (like ground enemies)? You pretty much have to know when to add them so that they sync with the background correctly.

There are two ways to spawn enemies...
dirty way - sync everything to frame updates, so at frame ### of this stage spawn enemies at x, y. ground enemies have to be synced by hand.
clean way - assign enemies a x, y position relative to the background/stage, and when the position is in view, activate enemy. (requires building level editors)

[BPzeBanshee]

Personally, I do both.

On stages with the 'room' height equal to the screen, I do a stage timer. The timer adds up every frame and based on that I spawn enemies. This is how Stage 1 in GMOSSE works.

Then, on stages where the 'room' height is larger than the screen, I do it as nasty_wolverine describes as the 'clean' way. This requires I use GM's level editor function, and do a bit of other trickery to activate/deactivate enemies, and then for objects that don't control position relative to the screen position themselves (ie. you dont want your player ship scrolling down with the background, right?) I do a for loop moving all my objects within a list of specific object parents to move them. Sounds complicated but the end result is neat and I've designed it so it's not really a pain to modify for future stage development. Stage 2 in GMOSSE does it this way: walls and enemies are placed that way and activated when their positions is greater than the y position of the view - half of the object's longest side of its sprite (usually width).

[ciox]

There's a third way I don't see mentioned, which is great if you want to shuffle around enemy formations.
Basically you make a queue of actions like SpawnEnemy(enemy,x,y) and Wait(frames), and you just loop through the whole queue during each frame, breaking out of the loop when you encounter a Wait action that hasn't completely counted down yet. You naturally mark actions as disabled after they've run so they can't run twice.
This allows you to insert an extra enemy formation at the start of the level with zero effort, where previously you'd have to update the frames (or x,y coords) of every single other spawn in the game.

A random sample of what the code looks like when you're initializing the queue with 'insert action in queue' functions, and basically building the level: http://pastebin.com/raw.php?i=h6XdbpGB

[kevin koss]

A lot of ground was covered. I appreciate that. What sort of advice would you give for the non programmer type designer?

[tibone]

Programmer or non-programmer.
Good design is good design.

Think about a game that you want to play.
Think about games that you like to play.
Try to think like a player. And try to design a gameplay experience that you think is fun and engaging.
Try to realize how to get there.

Game design is not easy, but it's not impossible. Think about what work and doesn't work for other games on the style that you're aiming for and think about how could you add/subtract to that and what the consequences would be.
Test a lot, talk with other players/designers, don't be affraid to change something.