• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
neomaycry

Game Design: When to stop brainstorming and start programming

7 posts in this topic

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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites

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.

Edited by warnexus
1

Share this post


Link to post
Share on other sites

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).

Edited by Ravyne
1

Share this post


Link to post
Share on other sites
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!
0

Share this post


Link to post
Share on other sites

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.

Edited by Shannon Barber
0

Share this post


Link to post
Share on other sites

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>

Edited by DareDeveloper
0

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  
Followers 0