How do you plan your project?

Doing a bit of this and that is not a good practice. What is your plane through out your project?

I think I need to make a game core first with player, enemy and type of game and apply it to cube then later make a maps/levels then add feature to it. I feel like the game complete when implement the game core first but when I try to make animation or level first, I just turn off and move to other project.

So what is your plan during the project? Please describe it or make a list as you want.

 

Start making something. See where it takes me. As an indie with no obligation to create or finish and no deadline it works better to just develop, and by doing so see where the game should go to get better

 

Talking about real project. How would you plan that?
I'm just making something and then move on new project because my computer can't handle a lot of asset at all. Some people say that start making a core game first and it will become an actual game with or without extra features.

I sometime start making controller and import model first because it look cool.

 

To organize myself I have several of TODO lists.

First there's a roadmap, major things that I plan to implement. Levels, or new enemies, or game features.

Then a more detailed short term to-do list, once I start unraveling the things I need to do to achieve items from previous list. I add items to the list as I go... sometimes I accumulate things to do for several days.

And also list of tons of things that I might do or not, later on... if I have time.

 

Have you actually made anything at all yet? Ever? If not i dont think youre exactly in a position to define what constitutes as real or not

 

What if you fail your road map? yesterday, I start up a new project and I want to make a 2D endless runner type of game. I finish the game core than don't know what to do next and dump that project then go to sleep. I forgot to set a road map and plans.

Addionally, Can you plan a 3rd person shooting game? I made 2 or 3 uncomplete third person game. One of them finish the core (Running, Jumping, Shooting, Camera) and another one finish the level (Maps, Animation, Particle effects) and then I lose interest because have no idea what to do next.

 

I mean a project that has goal. Not doing a bit of this and that and will never finish and has no dead line. It's just testing.

 

I'd say the first thing you need is either a prototype or a vertical slice. Which one you need depends on the type of game your making. If your game is systems based (like DOTA) I think mechanical prototype is the way to go. If your game is more content based (like Half-Life 2) then I think vertical slice is the way to go.

I needed a vertical slice for my game. Once I decided that was my goal I made a list of major tasks. Each major task can be broken down into minor tasks. Then I give each task an estimate of how long it will take. I use a spreadsheet with percentage completion, and every day I mark what I've done in percentages. I pick a desired completion date and try to make sure my "work remaining" number stays aligned with when I want to finish. I find that every once in a while I like to make a new list from scratch, perhaps with a new task break-down that makes sense for the rest of the project, or how I tend to be working.

I've completed my vertical slice, almost all of my systems, and now I mostly have content left and here is what my list looks like:


And here is what one of those categories looks like broken down:

 

Are you sure you did know what you wanted to do? Once you have a clear idea of what your game should be, you just have to list (on paper or in your mind) what must be done. Once you know what must be done, it's "One step at a time."

 

Same thing.

You make a basic prototype, test it, then outline list of stuff you need, sort it by priorities, then implement it all, meanwhile dealing with all the problems and bugs on ever-growing todo list.

And that's it. It takes a lot of time.

Keep in mind that it is not architecture, meaning that your plan is never set in stone and can always change.

However sorting tasks by priorities is important, you do what makes bigger impact first and leave the rest for latter.

----

1. If you're doing it for yourself in spare time: Nothing happens.
2. If you intent to make a living from it: well, you're losing money. When you lose all money, you'll have to give up on your project and find a job or starve to death. Your choice.
3. Freelance work for a client: It is contract renegotiation time! Depending on contract conditions (and depending on whose fault that is) you may have to either give a big discount to the client, or ask for deadline extension. The goal would be to ensure that the client is still happy with the outcome. Because when you lose all the income and run out of cash in bank account, you'll have to give up on your freelancing gig and find a different source of income. Or starve to death.

 

Nice!
Is alpha another larger vertical slice?
Rephrase - how are you determining what is alpha for your specific game?

 

I wouldn't call my project aimless, goal-less and lacking the intent to be finished but thats the approach i took

 

Another one of these threads? Perhaps I should get some popcorn? There is no magic secret anyone can give you to get games made.

Forget planning your first projects. Simply build something until it's done and release it. That will give you a far better idea of what's needed then anyone on the forum can.

Seriously. Grow up and learn to solve your own problems.

 

I know it seems harsh but i cant agree more with @BoredMormon
You need to just, make something
You're acting like one of those 12 year olds who say they make 100 page design documents for MMOs, just make a game, it doesnt matter if its terrible or if it fails. You just need to make something

 

I know full well how to manage a project and plan it, everyone does. But that's no fun so you get threads like this.

 

I'm calling it alpha when all the content in the game is at least first pass. So I want every location in the world to have a rough art pass, all the quests to be playable and beatable. It can be super ugly and buggy, but the skeleton should be there.

I do agree that there is no magic piece of advice that will suddenly enable someone to create a game, and in this case I don't think planning is the thing bottle necking our OP at the moment. Nonetheless, I think a discussion about how developers go about planning their production is fruitful. Its something I'm very interested to hear from other developers about anyway.

 

Valid point. The thread in general could be useful. My post was more lack of patience with the OP, rather then saying this thread is a bad idea. There are only so many times you can ask the same question without doing anything about it.

 

I think this is a great answer, and exactly how I believe most successful people work. You have an idea, you start playing around with it, and - as it develops - you start putting together your todo lists, your timelines, figuring out your dependencies and order of approach.

There's probably a hundred ways to approach things, but at the end of the day, the approach that works for you is the correct approach.

 

I didn't know what vertical slice is but thank for telling me that. Here's my side scrolling 2D road map:

1.Core Game

1.1. setup basic scene
1.2. setup camera and camera script
1.3. make character {move, jump and attack}
1.4. setup enemy and allow them to die in 2 option {stomping, attacking}​

2. Setup scene

2.1. Gather Sprite that fit the type of game
2.2. Make 10 basic levels
2.3. import sprite & setup animation sprite
2.4. import levels​

3. Setup UI & sounds

3.1. Make Menu, Start, Setting & Level chooser
3.2. Add score, health bar...etc
3.3. Setup audio for the objects​

4. Final state

4.1. script to UI, Core game & scene
4.2. Add extra feature {trail, effects, bonus, Credit, ....}​

I'm doing the basic 10 levels right now. It's time consuming.

That make sense. Doing the core first is always important.

 

Again I couldn't agree with @BoredMormon anymore. The thread itself is fine and could honestly bring about some great discussion, it's just that the OP is creating so many threads of this nature to avoid just starting
@GTHell, have you started anything yet?

 

@QFSW Great question. I've done mostly 2D project side scroller and endless runner. I don't have time to make impression to let fully grown man know what I'm doing something. The General Discussion is not helpful anymore to me when people come up and saying "Do something" when you ask a question that related to specific problem & need answers. I could say that you don't know how to code or a troller because I don't even know you. Why judge person base on the how many thread they've made? Seriously, Someone should make less assumption about others.
I want to make another thread call "What software you use to design 2D level?" but I'm sickening of fully grown man who is a thread derailler. No one is happy when they asking A and got a non-sense answer that tell them to do something. The only thing I can do is to ignore it.
I don't want to be a type of person who is a thread bug and not helpful to any newbie at all.I don't want to sound hearse but isn't it sound stupid to just build thing and release it? Making a junk of uncompleted scene and release it maybe. Sound stupid.
Define yourself as a fully grown man is a self proclaim.

Here's what I find and what make me want to ask this question.

 

What I do is the following, I come up with an idea and write everything down that needs to be in it together with a rough estimation of how long it's going to take to make. Then I check if I have the resources to make everything and if my scope is not too ambitious.

After that I make a detailed todo list for a small prototype of the core of the game and a more detailed list of everything I am going to need. Once my small prototype is ready which is usually 4-6 weeks in because I use a lot of asset store assets and assets from previous projects so I can prototype quickly. I play the prototype a lot and ask my friends what they think.

If feedback is good and I think its fun, I continue else I kill the project. If I continue I make new list with more detail these are very precise and will include everything that will be in the final game including a description of what it needs to look like or play like. Then I just keep developing seeing what works and what doesn't and updating the lists from there.

 

No one ever said anything about releasing it. You need to make stuff. If you think you're gonna be able to release your first ever project when you're constantly creating threads to procrastinate and stay away from the task of actually making a game, then you really need to just jump in, try stuff and hone your skills
Anyway you really oughta just be making something instead of spending so long planning it out, its such an iterative process that extensive planning is gonna be pointless unless you have the experience to know how development actually pans out.

Um, what are you even trying to say here?

 

Do entertaining threads count?

If you need good examples of how to handle this just look at Unity.

 

I probably did. I'm a firm believer that releasing a game is a key part of being a game developer. Games don't exist in isolation. They have to leave your hard drive and get played by random strangers to count.

Learning to release a game is an important skill. It requires as much deliberate practice as learning to make a game.

Of course, feel free to nuke your failed releases from orbit once you have better games. I'm pretty sure no one can find my Flappy Bird clone any more. And Space Invaders 2 would be an embarassment if it showed up now.

 

Very good point, of course releasing first game has its pros and cons but the main point I was trying to make is that it really doesn't matter how bad his first game is it just needs to exist

 

We follow the typical agile processes.

- Create user stories that, once complete, carry the vision of the final product
- Break down the user stories into features
- Break down the features into major tasks
- Break down the major tasks into smaller tasks
- Put the tasks on the backlog (we use Jira)
- Put tasks on current sprints
- Update everything as necessary on a daily basis

 

I let my friends play one of my core project with one levels and their feed back is ok. They really give a good feed back and the thing I'm lacking of. They just want pixel game kind of old Mario game.

 

It's exist. Just not completed yet because UI and Levels not implement yet. As I said, I don't need to tell anyone who I am or what I'm doing. If appreciate the help and I will ignore the people who is useless.

 

Yeah... those people on these forums post a ton but out of every 100 posts they make about 1 is actually useful. Just put them on ignore, it cleans up the threads quite nicely

 

@rnakrani Your process is like data structure breaking bigger problem into a smaller piece.

 

That's how we did it in the AAA's

 

If you're already in the middle of a project why do you need help planning it out?

 

Are you working for EA? That's awesome!

Learning from people's mistake. It's a best practice for me to learn from other people's mistake so I can avoid it in the future.

 

Close, but no cigar.

Close enough though.

 

In my opinion: you're overthinking it.

The steps you list don't require planning, because you'll be doing them no matter what, and they don't require expensive preparation.

You can't make a game but forget to make a scene, character, camera, and enemies. Therefore those do not need steps for them in the game plan.

Step 1: make a prototype, then test it.

Based on testing the prototype, make a list of features you need to implement.

 

It's not expensive preparation. It's a to-do list to make thing clear.
Isn't prototype walking, running and killing enemies?

 

What you're saying is true, but his list could be interpretated in a different way. a "basic scene" could be a boilerplate that he instantiates every time he creates a new level, for example generating a standard background or instantiating a grid for a tiled game. In that case, you should definitely plan it ahead.

Going back to the main question, I usually write down on paper a basic scheme of the project I'm working on, focusing on status changes and logic. I don't plan how many assets I'm gonna make or how the game is going to look, I first create something that works, and only in a second moment I start thinking about those elements.

PS: I didn't find any section to introduce myself, so... here I am, hello everyone!

 

The middle is probably where you need to plan the most.

Making a prototype is pretty straight forward. Just throw code and primitives at the screen until something sticks. Changes are cheap, so pretty much anything goes.

As you move into actual production things need more planning. Changes get more difficult. Code structure is more important, as it now needs to last the entire project. Artists need specifications.

Here is how my game project process typically goes

1) Develop a prototype. A simple demonstration of the core mechanic. This can be a single scene with hacked together code and no UI. But it must be fun. I have dozens of projects that never get past this stage.

2) Pen and paper. I'll draft screen shots on paper. I'll draw out key moments in play and flow. Is there a menu? How many players are on screen? What else is on screen? What does the UI look like? A key focus of this stage is determining what information the player gets, and what inputs the player provides. I may also sketch out some basic interactions and systems at this stage.

3) I'll then pick a screenshot and start building it. The pictures become my todo list. There is a health bar in the picture? Time to code a health system. There is a pause button? Better make that.

It's also worth noting that this is an iterative process. Often I go back to the pictures stage or even start a new prototype to test a mechanic.

 

Skimming through this thread I get the feeling that OP's issue is a problem of motivation, not planning.

I dabble in writing sometimes, and there's a common phrase regarding getting your novel written: Butt In Chair. Ultimately that is the answer - you must sit down and keep writing code until the the project is done, and no amount of advice is going to change that fact. So put your butt in the chair, open up Unity, and get to coding.

Follow Indie Whipping Bot on Twitter for motivation.

 

Whilst I do now agree with you GTHell that it's beneficial for you to learn from others methods, I honestly think you will learn more trying stuff yourself. Try planning it out, learn from your mistakes and see what works for you. There is no shortcut. After that, it would be a good idea to learn from others but you need to try yourself first

 

That's the vibe all of his threads have given

 

It's not motivation. It's about doing a bit of this and that that drive me crazy.

 

Instead of drawing up complicated project plans rather write down an outline of what you game is about and what functionality it should have. It may sound like the same thing but it's not really. Project planning is very useful when you have a large team working together as it aims to delegate tasks to the various group members. Visualizing a game and defining it on paper is something any aspiring game developer can and should do because if you know what your game is all about you'll know how to create it and whether or not you can finish it by yourself. I'm currently working on a Chess game for example so I would do something like this.

1. What's my game about? - It will be a chess game that is able to use 3rd party chess engines for AI so that I can play against a computer opponent.
2. What 3d models or 2d sprites will I need? - A chessboard and chess pieces which I can get freely on the internet.
3. What functionality do I want in my game? - Game must be able to detect invalid moves. Game must know which square on board is selected as well as which piece. Player must be able to move pieces on board (obviously). Game must detect checks, castling and enpassant situations. Game must have adjustable play level and adjustable time clocks. Camera must be freely movable. Must be able to communicate with UCI chess engines for AI. Must be able to read and save PNG files. Must be able to connect to online chess servers. And so on and so on.
4. What platforms will my game run on? - PC only.
5. What controller support will it have? - Mouse and Keyboard.

The above is just a very short list I came up with while writing this post. In most cases you'll end up with a large list of things you need to look at. So the next step would be to separate the crucial stuff from the nice to have stuff. For example it's crucial that my game can play chess against an AI but online play is a nice to have. So you start with the crucial stuff and leave the nice to have for a later update.

The point is that putting the game idea you have in your head on paper will allow you to break it down into manageable tasks. In my case I would now start by getting and importing the 3D models I need. Since I know I need to determine what square I'm working with on the board it's important that my board model is modeled in such a way that I can do this with ray casting. Next I write the mouse code to do all that, then I write the code to check for invalid moves, then I write the code to check for check and checkmate, then I write the time and clock stuff, then I write the code for communicating with the chess engine and so on.

See? I didn't worry about the details, I just stated what I want my game to be and the steps to do so became much clearer.

 

Yeah minimal viable product + iteration

Lets say Im making max Payne
I need a character system, a camera system, weapon enemy, enemy, slow down mechanic, cinematic system (id throw them in a test arena). Then when you got those systems in place you'd start working on the levels

 

I'm mix thing together if I don't make a to-do list.