I’d really like to hear some feedback from the site’s rockstars on this one.
Basically I’d like to know exactly what you guy’s do before starting the project.
Do you lay out all of your structures, or do you get an idea for them and fill it in later? Like, deciding that all GUI texts will contain the scripts that change their values rather than the object it represents.
Do you layout your folders in the project tab, or do you make them as you need them?
What do you design with outside tools, and what is better to design while working within Unity? Like, do you draw out stages on paper, or do you do it in Unity so that you can see it in action as you craft it?
How do you assign work to different members of the team?
How do you determine marks and deadlines?
How would you suggest someone improves their planning phase?
Team… I hire people. deadlines see difficult. Just think about the work involved and multiply it by two. I usually begin with an idea and a gdd. Then plan a core map out area. Then begin programming.
When I read this post I just had to laugh. It seems like you a have a vision of a game, a story and or new game mechanics, and you are seeing a strait line from the beginning of the project to the end. In the process you want to define now, with no intimate knowledge of what it takes, how long you should define deadlines for goals that you will also define now.
Im sorry to tell you making games, especially if your and indie, just isn’t like that. The end result is rarely ends up exactly as envisioned, and the route you take to get their is not a strait line. The software you use will make updates which will force you to make changes. You will get better ideas as you construct your game and get better at using your tools. You have to get your game play tested early and often, and you better be ready to make lots of changes based on what they say.
Also important to know now is that programming is only a third of making a good game. Concept art, modeling, drawing textures, making music and sound effects, Animation, etc… All of this has an art/design and technical component and it all takes a varied amount of time. If you want to be the head game designer you really ought to learn how to do all of this, so you have that intimate knowledge of what it takes, and you can then define how long every thing should take. Not to mention it will give you the skills to do more which will make the project move faster.
So how do you get started? You start by thinking out or planning out your game mechanics. If you have a story in mind, think about it, and plan around it. But in the beginning it’s all about mechanics. Once you have an idea, doesn’t have to be everything, you need to jump right in and build it. You start usually with cubes and planes to have simple representations of objects as you build up your mechanics. Then you start replacing these place holders with art assets and you start doing all the work to make them look good and operate correctly. Then you start building up your levels or expanding out your game depending on what your doing. I say this because if you make a bunch of levels early, then have the game play tested and you decide to change your mechanics, it takes a lot of work to rework all your levels. It’s better to work up your mechanics to the point where its been tested thoroughly and you know your mostly happy with it before you start building up levels. In terms of how to set up structures, I would just recommend that you set up your scripts so they act on just one or as few objects as possible. As you build up your game it will make it difficult to iterate if you have scripts that act on several different aspects of your game.
In the end this advice is just the beginning and getting to the end takes a lot lot more questions and answers, which is why your post made me laugh. I hope some of this helps and I wish you luck.
Step 1 is handled by nature, I have a really lengthy dream that I remember clearly.
Step 2 is to make a clear set of universe rules (game mechanics)
Step 3 is to make a series of steps / stages for a prototype
Step 4 is to implement a prototype
Step 5 is to go over steps 3 and 4 to plan and implement new features
Step 6 is to make things look and sound nice
The first step(s) can be substituted with:
“Take inspiration from one or a combination of two+ existing games”
“Take the universe mechanics of an anime or other big franchise and translate those directly into game mechanics for a universe of your own”
You do need some degree of structure, just so you don’t face fundamental problems later on. And by that I mean be sure your gameplay makes sense. Maybe think about something you’d sincerely want to do, or enjoy playing… but you can’t because it doesn’t exist (yet).
Whatever you do will come with a lot of obstacles and problem solving. If you’re working for a client, you would have to overcome and power through those obstacles, more so if you have a tight deadline. This involves a lot of stress.
But why go through that if you’re making your own game? No one will know how your game evolved, they’ll just see the final product.
Be sure to start with a solid base, then do whatever suits you best, you might find that it’s best to take a different route later on, or maybe cut a problem loose. Or maybe you think something is really worth doing, and spend a lot of time on it and see it happen. All goes as long as you’re doing something you’re proud of.
For KSP, we knew from the start we had more ideas than manpower to implement them, so we had those ideas planned out vaguely, just enough to remember them, but left a lot of room for change in the actual design spec for the game. In fact, that spec became obsolete within about 4 months or so, it didn’t even survive to the first public release.
That wasn’t a bad thing. We expected that to happen, and to a degree, relied on it. Several important design decisions were left deliberately open awaiting feedback from players. After going public, we had to be real careful though, to not let the community drive the project entirely. You have to have a firm vision of what you want to end up with. Feedback is valid when it aligns with your existing ideas, but it’s very easy to let your plans be carried away by the torrent of input that the community provides. You have to strike a balance there, and remember that the community doesn’t know of your ultimate vision. Their ideas and feedback are based on the project as it is, not as you see it. Sometimes you have to stick with your plan even if it goes against a majority opinion.
Remember the words of Henry Ford: If I had asked my customers what they wanted, they would have said ‘a faster horse’.
@Marcellus_Wilson : I agree completely about the game mechanics (in fact I’ve said more than a few times “If I wanted a story I’d read a book.” in regards to that). And of course I have multiple visions of games I would like to make, but this thread was really started after I realized that the small game I had became pile of spaghetti code. I’m acknowledging that I failed to plan properly and would like to know how successful people plan their games.
This is something that I definately need to work on. I’ve always had a mild art aptitude, but I have never really done so for a project and developed a sense of timeframe so I often just dismiss it. Not wise to do, I know.
deadlines see difficult. Just think about the work involved and multiply it by two. I usually begin with an idea and a gdd. Then plan a core map out area. Then begin programming.
