I am a new programmer with novice to intermediate experience with C++. I am currently working with SFML 2.0 and feel I have a good grasp of the system. My first project is a space shooter game, and I currently have the following items coded and functional:
1) Player movement, collision, firing mechanism
2) Enemies (2 types, one that chases the player and fires; one that moves to the center of the screen and fires a laser in a 360 degree motion until the player kills it)
3) A tile map system that reads text files and loads images from a local resources folder
4) Scrolling backgrounds
My question is this:
If I plan on implementing many more enemy types and player features (i.e. power-ups, skill trees, etc.), how much of this should I design (code-wise) before building my first level? I definitely don't want to make a level and have to go back and change it all when I'm further into development. Likewise, I don't enjoy programming endlessly without "seeing" any sort of payoff. When should I move on to the next step? Thanks for your advice.
Game Design: When to stop brainstorming and start programming
I'm new to this too, and this may be more of a bump, but with that said: I've found that designing as much as you can, then when you inevitably can't do that any longer: code.
USUALLY the code reignites the passion to design.
USUALLY the code reignites the passion to design.
Start coding asap and then go back to refactor once you've got some naive implementation. It might be disheartening knowing much of your first implementation might get scrapped but when actually coding you'll stumble into all sorts of problems you probably could never have dreamt of while designing, and even if you spent days on a solid design the first implementation is hardly water-proof no matter how much you prepare.
Refactor and iterate is king, especially in hobby projects when you can go back how many times you want and find and correct your past mistakes, you'll quickly progress into a better programmer overall
Brainstorming should take no more than 30mins. Then implement this idea. Sometimes it is hard to predict what makes the game fun until you have seen and interact with it.
If you already have the ideas of the power ups, implement the first one and see how useful that power up in game. If it is good, move on to the next power up. By time you have tested enough power ups, you might have seen a pattern about what makes a good quality power up and whats makes a bad quality power up. Same idea applies to the monsters. Understand why you are adding power ups in the first place.
Then build one simple level. Keep refining the level and see what is missing, what fits and what does not fit.
Design always change. This applies to your personal project and in the industry. My first game project went through many changes to get the look I wanted. My enemies, ship and projectiles design changed. And that is the key thing: getting the look you want. Change in design is not a bad thing: you learn more about game design and art design thus eventually getting a better understanding of your vision for the game.
The prefer approach is getting something you spend time coding and immediately putting in game for testing the fun factor of that feature.
Draw a mock up design and improve on it. It is important to keep making stuff and improvising on that.
If you think you need a break, give yourself a break to relax and recharge. While you might not be coding or designing during that time, you will be thinking about it in your head or sleep and that will be all you need to get you back to work the next day or next few minutes.
If you hate having to re-work things, programming and game design probably aren't for you. No one designs up front and gets it right the first time -- these things are all about making your best first-guess, and refining over and over until its great. Experience will help you get that first guess closer to the final form, but rarely if ever will you hit the bullseye.
I suggest that you move not from brainstorm to production, but from brainstorm to prototyping. Build little playgrounds that let you test out individual mechanics, and mechanics in combination. Early prototypes might be one-off, throwaway programs, while later prototypes might be special branches of your game. In either case, don't be afraid to throw out what doesn't work, and what does work, well, you'll probably be thankful in the end that your "production" version of the feature isn't the hacked-in, first attempt you took at implementing the feature. When you're confident that the feature is a positive, implement it "for real" in the main body of code.
I know this sounds intuitive, but prototypes actually save you work in the end, because you won't have to rewrite shoddy, first-attempt code that you implemented directly in your main codebase later, and you won't waste time implementing features to production standard just to find out that they aren't fun after all.
Developing a game or application efficiently is not an exercise of doing only the right things, one after the other, but is an exercise in spending time wisely by finding out what's worthwhile before making the big investments. I'd much rather throw 10s of individual days away proving an idea unsound, than to face 10s or 100s of days ripping out the same ideas and going back to the drawing board months later.
Prototypes also give you plenty to show and play with, even if its not the final form. They can scratch the "but I'm not getting anything done!" itch if you let them.
Regardless, get *something* playable as soon as possible -- you can't refine the fun factor until you can actually play the features out. Your first programming goal should be to implement the bare minimum of functionality necessary to play out your primary mechanic(s).
Author
These responses are exactly what I was looking for, and they've helped me develop my understanding of the design process. Presently, I've been designing features in a sandbox-type environment, and I just wanted to make sure that was the proper approach. It looks like it is. Thanks for the help!
As you gain experience you will begin to make better decision about what to implement first because you know it won't change or will change very little.
Regard programming an unknown like war. You have to corner it, demoralize it, and kill it. You don't accomplish that by thinking about how much you hate it. You use your military to force the enemy to make mistakes and reveal itself. In the programming analogy, you use the code you write to establish boundaries of how things could possible work and keep honing on how it must work.
For how far along you are I think you should create a level with what you have.
You may scrap this level, but it will be your test-bed to see what is working well and what isn't with what you already have coded and drawn.
Isn't that usually why people suggest tackling smaller projects first?
That is how you see progress fast, don't invest too much in something that you learn doesn't work and you get a better feel for what works.
Creating the software architecture is as much a skill as programming. Tackling something as complex as you describe might be a little early.
If you have already finished smaller projects consider rewriting them with a focus on proper architecture design.
I think I'd try to write very sophisticated Tetris, Breakout and Snake clones that use the same toolkit / framework / engine.
And I'd make it general enough that I'm pretty confident it will work for the space shooter as well.
I know I had the same feeling ... and I had to recreate projects and start from scratch a lot.
You will get to a point where you don't worry that what you do might not work ... if you consciously improve your design skills first.
<edit>
Btw. ... I meant write your own toolkit, framework or engine ... but it might make sense to do it all.
Create a toolkit, write a framework based on those tools and then an engine using the framework.
That sounds like a good learning project. Do it incrementally (don't finish the engine before you use it for the games) to see progress at all times.
</edit>
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
