Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

A friend of mine and I are planning a game together to work on in our free time. It's not an extensive game, but it's not a simple one either.

He's working on the story behind the game while I'm working on the graphics and code.

I don't really know where to start with the game. We know what the basic type of game it's going to be and how it would be played, but I'm having a hard time of actually knowing where to begin.

I have Xcode open but I don't really even know what I should be designing first.

What is some advice for this writer's block? Where is a good place to start with a game? Should I design all the graphics and layout before even touching Xcode? Should I program the things I know I'll have difficulty with first before getting to the easy stuff?

share|improve this question

closed as off topic by Noctrine Oct 27 '12 at 3:32

Questions on Game Development Stack Exchange are expected to relate to game development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

6 Answers 6

up vote 28 down vote accepted

Start by getting something up and playable. Don't spend more than an hour on graphics, just render the game with rubbish placeholders. Games don't have objective requirements to build to: the key requirement is that it be fun, and evaluating whether a game is fun or not requires playing it; as a result, game design should follow an iterative approach. (I recommend Tom Wujec on the marshmallow challenge as an orientation on iterative design.

share|improve this answer
    
I don't understand why there should be so little emphasis on the graphics. –  OghmaOsiris Oct 5 '11 at 23:26
15  
@OghmaOsiris: Most games don't have graphics as an intrinsic element of gameplay. Usually, the graphics is just a layer on top of the actual game, that makes it pretty and makes it sell, but isn't fun. Graphics are also really expensive to make. If you've put one hour into the art for your twitch-shooter spaceship game, and then a week later you realize it'll work better as a turn-based fantasy citybuilding game, you haven't lost a lot. If you've spent weeks on that art, you'll either need to throw away work or release an inferior game. –  ZorbaTHut Oct 5 '11 at 23:33
1  
@OghmaOsiris (continued): Sometimes you're making a game where the art is crucial, and then you'd probably want to do enough art to get a feel for it. Usually you'll know when you're in that situation. –  ZorbaTHut Oct 5 '11 at 23:34
    
@OghmaOsiris, go play Minecraft, or even better, Dwarf Fortress. :) –  Cyclops Oct 6 '11 at 22:41
1  
Making something appealing takes far longer than implementing the basic functionality and always ends up adding the dreaded "scope creep". In the worst case you project may never get done, causing you to just give up. Don't loose scope of your objectives: Make a game that works! Plugging in graphics after will show a whole lot more accomplished in far less time, especially if you're still trying to figure out where to start. –  Mohgeroth Oct 9 '11 at 4:42
add comment

Create something on paper, and by that I mean make a mock-up board and cut-out pieces. Make rules and play your game on the paper mock-up. Use that to break out your code design into feature sets and modules that you can work on. This process will help your friend design the story and how the game works, too.

You may be tempted to write extra features into your code, avoid that. You are prototyping to see what will work.

Once you have a small piece up and running you should work iteratively and at each iteration get just one more feature running. When something isn't playing well go back and changes features. Keep iterating and changing.

The basic idea is to have the long term vision based on your paper mock-up, and from that a series of short term goals to work on that get you to where you want to go a piece at a time and without the stress of "omg what do I do next?"

share|improve this answer
    
+1: Firm believer in diagrams and drawing! Ideas go from dripping in to a sudden cascade of ideas once you SEE what your mind is trying to show you! –  Mohgeroth Oct 9 '11 at 4:43
add comment

Evaluate your requirements first. Coding without a plan creates a lot of waste later.

What does the game functionally need to do? What frameworks do you need to make that work? What are the elements that can be borrowed from existing frameworks, and what do you need to write yourself?

Before opening Xcode, it might help to just make paper cutouts, and run through all of the game interfaces and dialogs first. This will give you some idea of what you need to create in Interface Builder.

Next, how do things interact? What are the distinct styles of interaction required? That should give you some idea how the controllers need to be divvied up, started and stopped.

Don't plan it to death, but clearly define your requirements, and as soon as you can break the project into bite sized (30min-1hour) pieces, you're ready to start coding.

Looking at 2 days, 2 weeks, or worse, 2 months worth of tasks engages a fight or flight reaction. Break it into small enough pieces that you can bite each one off sequentially without choking, and my guess is you'll know exactly which bite to start with, and which one to go after next.

share|improve this answer
add comment

Do the things that give you a playable prototype as soon as possible.

The first 1-2 weeks you propably can not make good estimates, because you are new to the engine. So in the first week(s) its probably a waste of time to do estimates. But do note the time you spent for stuff, so you have some experience you can base your first estimates on. After that time start to plan, estimate and set priorities!

Three things I've learnt from the last 6 months where I was part of a not successful game project (I was paid to be the dev implementing game logic):

  1. Do not change your plan every day! It's obviously a good thing to go an agile path, but if you end up changing your goals every day, clearly something is wrong.
  2. Keep track of the time you spend on your work. Compare estimated and effective times. At first you will probably note a big difference, but over time you should be able to make better estimates.
  3. Take estimates into account when setting priorities.

Important: From time to time take a look back on the project and see what went well and what did go wrong. I guess you can identify parts where you spent too much time on something not needed. Try to leave such things out the next time. (For example: If you work on a gadget that your player can use 1 or 2 times in the game for 2 seconds, don't spend a whole month on the implementation.)

share|improve this answer
add comment

If the game is supposed to fit into an existing genre, or it is somehow similar to another game, simply try to make a crude, simple imitation of that game, or make a "typical" example of the genre. If you are not a good coder, follow a tutorial which will walk you through making a game similar to yours.

After a while, you should naturally feel the urge to "diverge" from your model, and start taking the game in your own direction. From there it's a downhill road of adding a feature there, fixing a bug here, and generally improving in small steps.

If there is a certain concept that is somehow unique to your game, you might also start by building the simplest demonstration of that concept. There's also the option of simply building your game around that concept.

share|improve this answer
add comment

If you don't know how to properly design a project, i suggest reading chapter 1 of Bruce Eckel's Thinking in C++ (the book is free), there's a section named "Analysis and design". It's a good introduction.

Be sure to checkout Bruce Eckel's Thinking in C++ Volume 2.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.