Years ago I was enticed to buy RPGMaker for the PSX. It included a comprehensive game creation guide not only detailing the ins and out of the game interface, but also giving many helpful suggestions on how to structure RPG development. Within the first few pages, there stood the following list suggesting development flow:
1. Develop a rough idea of the game story, characters, and settings.
2. Create the title screen
3. Create the main character and the other members of the party.
4. Create monsters to populate the different areas of the game.
5. Create game items, including equipment.
6. Create game's magic or skills.
7. Create the game maps and environments.
8. Finally, write the scenario data for the game.
(9. Beta testing)
Might someone recommend an equivalent procedural list for developing a shmup?
Shmup development procedure
-
null1024
- Posts: 3810
- Joined: Sat Dec 15, 2007 8:52 pm
- Location: ʍoquıɐɹ ǝɥʇ ɹǝʌo 'ǝɹǝɥʍǝɯos
- Contact:
Well, here's what I do:
1. Think up main game premise. Will it be a textbook shooter [3 lives, possibly bombs, main gun, and possibly secondary gun], or will you make it different [ala Ikaruga or Mars Matrix, which implement some kind of system to make them stand out]?
2. Implement main player movement and firing system.
3. Create enemy and player graphics.
4. Design levels.
5. Implement enemies.
6. If you'd like, send betas out to forums [like this one], release either early and often [like me], or only when you feel it's polished enough.
7. Go back to step 4 until you've implemented all of your levels. Possibly go back to step 3 if you need more enemy graphics.
8. Do the title screen. No one cares about this part too much, but a nice arcade style title screen [with included intro animation and attract mode] is a really neat touch. This step can be done at any time, therefore it's not very high on the list.
9. Set up a small webpage with your game, upload it, and post the finished game around the net [if it's good, the beta test step will decide this].
All of these steps [except for the first one] can be done in almost any order. But this is my preferred order.
1. Think up main game premise. Will it be a textbook shooter [3 lives, possibly bombs, main gun, and possibly secondary gun], or will you make it different [ala Ikaruga or Mars Matrix, which implement some kind of system to make them stand out]?
2. Implement main player movement and firing system.
3. Create enemy and player graphics.
4. Design levels.
5. Implement enemies.
6. If you'd like, send betas out to forums [like this one], release either early and often [like me], or only when you feel it's polished enough.
7. Go back to step 4 until you've implemented all of your levels. Possibly go back to step 3 if you need more enemy graphics.
8. Do the title screen. No one cares about this part too much, but a nice arcade style title screen [with included intro animation and attract mode] is a really neat touch. This step can be done at any time, therefore it's not very high on the list.
9. Set up a small webpage with your game, upload it, and post the finished game around the net [if it's good, the beta test step will decide this].
All of these steps [except for the first one] can be done in almost any order. But this is my preferred order.
Come check out my website, I guess. Random stuff I've worked on over the last two decades.
-
Shatterhand
- Posts: 4044
- Joined: Wed Jan 26, 2005 3:01 am
- Location: Rio de Janeiro - Brazil
- Contact:
speaking from experience, you should only care about graphics when you have the game nearly completed, or at least its mechanics and the level design at place.
You should care about game mechanics and level design WAAAY before. Use placeholder graphics for testing, just being careful to use placeholders that fit the size you'll need for the real sprites. (You could even just use hitboxes for the placeholder graphics, as this is what trully matters for the gameplay).
You should care about game mechanics and level design WAAAY before. Use placeholder graphics for testing, just being careful to use placeholders that fit the size you'll need for the real sprites. (You could even just use hitboxes for the placeholder graphics, as this is what trully matters for the gameplay).
-
null1024
- Posts: 3810
- Joined: Sat Dec 15, 2007 8:52 pm
- Location: ʍoquıɐɹ ǝɥʇ ɹǝʌo 'ǝɹǝɥʍǝɯos
- Contact:
Design levels entails:
If it's a boss level/rush, make the boss bullet patterns
If it's a normal level, design level graphics, backgrounds, possibly add obstacles, and place enemies. Mostly place enemies and obstacles.
If it's a boss level/rush, make the boss bullet patterns
If it's a normal level, design level graphics, backgrounds, possibly add obstacles, and place enemies. Mostly place enemies and obstacles.
Come check out my website, I guess. Random stuff I've worked on over the last two decades.
1. Create placeholder graphics. Most of the time, these consist of circles.
2. Develop player momement. This is always the fun part of developing a shmup (according to Studio Pixel)
3. Create and program a basic enemy.
4. Create scoring mechanism. This aspect is always tweaked throughout development.
5. Create bullet patterns for the enemies.
6. Adjust aspects and create more enemies with different bullet patterns.
7. Release beta.
8. Apply feedback from players.
9. Repeat steps 7 and 8 as many times possible.
10. Create or get someone to do graphics for the game.
11. Complete (or is it?)
2. Develop player momement. This is always the fun part of developing a shmup (according to Studio Pixel)
3. Create and program a basic enemy.
4. Create scoring mechanism. This aspect is always tweaked throughout development.
5. Create bullet patterns for the enemies.
6. Adjust aspects and create more enemies with different bullet patterns.
7. Release beta.
8. Apply feedback from players.
9. Repeat steps 7 and 8 as many times possible.
10. Create or get someone to do graphics for the game.
11. Complete (or is it?)
[ Wonder Force IV -sorry Frenetic :c- ]
-
SandtouchLC
- Posts: 50
- Joined: Tue Feb 24, 2009 12:08 am
- Contact:
Right on. However, if you want to test your game with a limited audience before releasing it on the Internet (as to avoid getting roasted on beta release), you may want to make some of your graphics beforehand so as to make the game presentable to them. But yes, you can always worry about spit and shine later once you have the core gameplay down.Shatterhand wrote:speaking from experience, you should only care about graphics when you have the game nearly completed, or at least its mechanics and the level design at place.
....
(You could even just use hitboxes for the placeholder graphics, as this is what trully matters for the gameplay).
This is basically what I do when I work on any game. I just wish some people would understand it (especially those who like to nitpick the graphics I'm using as placeholders). There are already people offering their efforts to make custom graphics for my fangame, the remake of Xeno Fighters EX. I'll address the graphics when the game is pretty much complete.Aru-san wrote:1. Create placeholder graphics. Most of the time, these consist of circles.
2. Develop player momement. This is always the fun part of developing a shmup (according to Studio Pixel)
3. Create and program a basic enemy.
4. Create scoring mechanism. This aspect is always tweaked throughout development.
5. Create bullet patterns for the enemies.
6. Adjust aspects and create more enemies with different bullet patterns.
7. Release beta.
8. Apply feedback from players.
9. Repeat steps 7 and 8 as many times possible.
10. Create or get someone to do graphics for the game.
11. Complete (or is it?)
The age of Alluro and JudgeSpear is over.
-
Pixel_Outlaw
- Posts: 2636
- Joined: Sun Mar 26, 2006 3:27 am
*FIRST YOU NEED TO DECIDE HOW MUCH TIME YOU HAVE TO CREATE THE GAME BEFORE YOUR ATTENTION SPAN RUNS DRY*
Make the game simple if you don't have too much time. If you have a job or a short interest you may go the Kenta Cho route or a Boss Rush.
1. Develop how the game will play, try to think about any possible chances the player has to cheat the game and stop them.
2. Start with a rough idea of how levels will play out. Begin working on a base enemy class for polymorphism.
3. Begin working on a base bullet class. You can make this work for both the player and enemies if you again use polymorphism.
4. If you enjoy making sprites, start making them as you need them, this can keep you focused on your game because you will have something visual now. NEVER create the sprites before you have the basic game designed, You may feel obligated to force in enemy units based on premade sprites that simply ruin the gameplay.
5. Start making levels and enemy emitters. an "enemy emitter" is an object that puts out x many enemies at a given time in the level time frame. Or if you have more time, you can start working with tiles and level obstacles now in a less scripted level system.
6. Now start making bosses. How do they move? Are ALL bullet patterns fair? Can the player bomb the boss 2 times and kill it before it really starts shooting out some patterns? Does the boss need simple AI? Does it move using Bezier curves or splines? Is the bullet pattern seamless when it must restart? Are the bullet patterns pretty or are you pulling a Euro and just making them shoot strait down in random patterns?
7. Start working on game states that will go from boss to next level to game ending to title screen. Some people will want to do this first I like to do it last. I usually set a global variable called game_state
it can be "title", "paused", "level", "boss" and "game over". You might have a seperate game loop for each part that updates elements and redraws the screen. Ofcourse the game state "paused" does not update anything, it simply refreshes and draws the screen.
8. Make sure you play test the game before releasing it. Try to cheat the game in every possible way and also try to do things that you had no intended like trying to slide between the tile elements of walls and getting behind the boss where it may be safe. Look for safe spots that the player can just sit in and rack up points. To counter safe spots the best idea is a mix of shots in their general direction mixed with aimed shots.
9. Give your game to Shoe_sama in the IRC chat channel, he will probably destroy it for you while typing in all caps. As you weep with the bloody pieces of your broken game try to fix the broken elements.
10. Try to release the game on a normal game forum where they will say it is too hard and that nobody will purchase it because it does not appeal to casual players and youngsters. Then say you did not intend to sell it and watch the thread die almost instantly.
11. Try to chase down the2bears and see if you can get the game on his blog so the rest of the general shmup community can find it.
12. Put the game in a folder on your computer, never to be touched again as you have already play tested it hundreds of times.
13. Drag it out to show the occasional friend who simply cannot handle an arcade game and then give in and go to their house to play the next cookie cutter FPS.
That's how I do it.
[/i]
Make the game simple if you don't have too much time. If you have a job or a short interest you may go the Kenta Cho route or a Boss Rush.
1. Develop how the game will play, try to think about any possible chances the player has to cheat the game and stop them.
2. Start with a rough idea of how levels will play out. Begin working on a base enemy class for polymorphism.
3. Begin working on a base bullet class. You can make this work for both the player and enemies if you again use polymorphism.
4. If you enjoy making sprites, start making them as you need them, this can keep you focused on your game because you will have something visual now. NEVER create the sprites before you have the basic game designed, You may feel obligated to force in enemy units based on premade sprites that simply ruin the gameplay.
5. Start making levels and enemy emitters. an "enemy emitter" is an object that puts out x many enemies at a given time in the level time frame. Or if you have more time, you can start working with tiles and level obstacles now in a less scripted level system.
6. Now start making bosses. How do they move? Are ALL bullet patterns fair? Can the player bomb the boss 2 times and kill it before it really starts shooting out some patterns? Does the boss need simple AI? Does it move using Bezier curves or splines? Is the bullet pattern seamless when it must restart? Are the bullet patterns pretty or are you pulling a Euro and just making them shoot strait down in random patterns?
7. Start working on game states that will go from boss to next level to game ending to title screen. Some people will want to do this first I like to do it last. I usually set a global variable called game_state
it can be "title", "paused", "level", "boss" and "game over". You might have a seperate game loop for each part that updates elements and redraws the screen. Ofcourse the game state "paused" does not update anything, it simply refreshes and draws the screen.
8. Make sure you play test the game before releasing it. Try to cheat the game in every possible way and also try to do things that you had no intended like trying to slide between the tile elements of walls and getting behind the boss where it may be safe. Look for safe spots that the player can just sit in and rack up points. To counter safe spots the best idea is a mix of shots in their general direction mixed with aimed shots.
9. Give your game to Shoe_sama in the IRC chat channel, he will probably destroy it for you while typing in all caps. As you weep with the bloody pieces of your broken game try to fix the broken elements.
10. Try to release the game on a normal game forum where they will say it is too hard and that nobody will purchase it because it does not appeal to casual players and youngsters. Then say you did not intend to sell it and watch the thread die almost instantly.
11. Try to chase down the2bears and see if you can get the game on his blog so the rest of the general shmup community can find it.
12. Put the game in a folder on your computer, never to be touched again as you have already play tested it hundreds of times.
13. Drag it out to show the occasional friend who simply cannot handle an arcade game and then give in and go to their house to play the next cookie cutter FPS.
That's how I do it.
[/i]
Some of the best shmups don't actually end in a vowel.
No, this game is not Space Invaders.
No, this game is not Space Invaders.
That got a little depressing near the end Pixel Outlaw. Maybe this thread should be stickied so as to reveal the bitter truth about the game design process!
Maybe not... would anyone make a game at that point!?
Maybe the journey is the really fun part. When I was working on my graphic novel, I started to notice that I did not want to be deprived of the work. When the story finally ended, I did feel depressed.
Maybe not... would anyone make a game at that point!?
Maybe the journey is the really fun part. When I was working on my graphic novel, I started to notice that I did not want to be deprived of the work. When the story finally ended, I did feel depressed.
-
Pixel_Outlaw
- Posts: 2636
- Joined: Sun Mar 26, 2006 3:27 am
Well, like Kenta Cho said "I make games that I want to play". Each game is a learning experience really. Make games you like to play and if people like them, it is a bonus.ZacharyB wrote:That got a little depressing near the end Pixel Outlaw. Maybe this thread should be stickied so as to reveal the bitter truth about the game design process!
Maybe not... would anyone make a game at that point!?
Maybe the journey is the really fun part. When I was working on my graphic novel, I started to notice that I did not want to be deprived of the work. When the story finally ended, I did feel depressed.
Some of the best shmups don't actually end in a vowel.
No, this game is not Space Invaders.
No, this game is not Space Invaders.
That's what id Software pretty much said when they made the first DOOM way back in 1993.Pixel_Outlaw wrote:Well, like Kenta Cho said "I make games that I want to play". Each game is a learning experience really. Make games you like to play and if people like them, it is a bonus.
If there's one thing I've learned, it's that it is impossible to please everyone. One person may like abstract SHMUPs like Warning Forever, while others hate those kinds of SHMUPs. I decided now to just make games that I want to play. If you end up pleasing a lot of people with your game, then that's a bonus as well.
The age of Alluro and JudgeSpear is over.
-
angrycoder
- Posts: 232
- Joined: Mon Jan 31, 2005 1:34 pm
- Location: Pennsylvania, USA
Regarding what others are saying about making the graphics last, here are a couple of vids that back that idea up. Its a mini documentary about a tank style arena shooter. His graphics are all basic primatives and the game still looks fun to play.
http://diamondtearz.org/blog/2009/03/18 ... cumentary/
http://diamondtearz.org/blog/2009/03/18 ... cumentary/
-
SandtouchLC
- Posts: 50
- Joined: Tue Feb 24, 2009 12:08 am
- Contact:
A few observations to add to that:Alluro wrote: If there's one thing I've learned, it's that it is impossible to please everyone. One person may like abstract SHMUPs like Warning Forever, while others hate those kinds of SHMUPs. I decided now to just make games that I want to play. If you end up pleasing a lot of people with your game, then that's a bonus as well.
- Of the people who play your game, only the ones who feel strongly one way or the other will ever provide feedback. Most of them will be like the quarter-less kids in the arcade that Ed mentioned: they'll run up to it, enjoy it, and maybe tell their friends, but you will never know about it.
- To learn more about those players, you need to collect statistics. We know the above is so by looking at the Google Analytics stats for Chacker. Only people who really LOVE or HATE the game have provided feedback here or elsewhere, yet, 3-5 new players play it daily. But we press on, not only for those who tell us they like the game, but because of the silent majority who play the game, like it, and tell their friends.
- Alluro's comments, if taken to their logical conclusion, tend to suggest that a developer should adopt a zerg approach to release: Make as many games that are fun for you as possible, but also different from one another, and then release them. But compare developers like Cave that have found success by specializing in one sub-genre.