How does the Video game creation process work?
- Thread starter Professor James
- Start date
Recommended Videos
What aspect of game creation do you mean? In very simple terms, it's just a software project:
1. You have an idea
2. You plan it
3. You code it in some programming language
4. You release it.
That is very simplified, of course, so what are do you want to focus on more?
1. You have an idea
2. You plan it
3. You code it in some programming language
4. You release it.
That is very simplified, of course, so what are do you want to focus on more?
The Planning and coding mainly but I also want more information on how #1 and #4 works.DoPo said:
Well, here is more detailed information, then.
1. You get an idea. It can be a game mechanic, a story, a visual style, whatever. Something that you can build a game around. Say, you may decide to make a sports game - that's fairly broad. Or you may want to make a Half-Life mod about shooting underwater aliens. That's more specific. Whatever the case, you now have something to work with.
2. You plan it. So you flesh it out more, think about appropriate other things, say if you wanted to make a sports game, what sport? And how would it play? Basically flesh it out. Also do some research. Lots of research, probably. Is this idea out there already? Can you use it? Can you actually make it, as in, physically able to - you may want a full 3D game that is visually stunning, with super complex mechanics and great narrative, that has all the best voice acting in the world, but it's pretty much impossible to make this. Next, what technology would you use for the game? What would the target audience be? And so on and so forth. You get the gist, I hope. You have to know your project very well after this. Analyse it for break points, try to prevent them.
It probably sounds harder than it is in practice, though. If you have a solid idea, you'll know most of these things, since you'll be constantly thinking about it. Another part of the planning is your team, if you have one. Who will do what and how would you all work together. Again, it sounds a bit harder than in practice. But if you have just assembled a team now, DO NOT SKIMP HERE! I can't stress this enough. If the team is new, even if they know each other from before, as long as this is the first time they work together, more likely than not Things Will Go Wrong. I've seen too many projects just die because of awful team work. And it wasn't anybody's fault...in a sense. It was also everybody's, too. Teamwork is crucial.
So make the best out of it, basically the planning is the time to test your idea before building it, predict the failures and try to prevent them. Not all of them, of course, you aren't going to know everything that might go wrong, but you'll know enough to be able to fix stuff on the fly.
Also important, what project lifecycle would you use....which is basically "how am I going to build this" from a more meta perspective, not talking about the actual idea itself but the process. Just check Wikipedia [http://en.wikipedia.org/wiki/Systems_development_life-cycle] on this for an overview. What would work best here? For example, if you have a very concrete idea in mind, you'd adopt one approach, however if you are not entirely sure, and intend to add features as you go along, then the same approach wouldn't work.
3. Coding...well, it's not that hard. During the planing phase, you would have found what to use. Be that Java or C++ or specific third party libraries. Say, if you want to make a 3D game, you might not write everything from scratch but instead use the Unreal Engine, or the Source SDK or something. Of maybe, you and/or your team simply doesn't have the experience for some technology, so you'll go with what they are most comfortable with. That means, that, say, you could make the game in Java if that's what you know.
But basically, the rest of it is...coding. Get people together and use a keyboard. You would have done some of the work in the planning phase, so most of what you'll be doing is just make these ideas manifest. Say, you want a funky jumping mechanic where you could leap from wall to wall, you'll just have to make the game behave like that.
Well, there is another important part here - project management. You have to oversee the project. If not you, then somebody. There are lots of ways that things can and will go wrong if you just implicitly trust people will do what they need to. Someone has to make sure things stay on track, that everything is going smoothly as planned (or close enough), that the team is getting along, also to prevent feature creep[footnote]"Hey, we have this, but wouldn't it be cool if we have that as well? I know we wouldn't plan it but it wouldn't take much time." No, just no. Write it down, make a To Add list that you'll go through later, if you will but feature creep is a very likely way to kill a project[/footnote].
And finally, try to follow the development lifecycle. Or if it hinders you, try to change it. But very basically, you need to have some goals and milestones to go through. That helps keep things on track.
4. And at the end, release it. That can be very hard or not-as-hard depending on the intentions. You could just put it on a website somewhere to download for free. That's the game released. Or you might have to talk to other people to help you distribute it. Steam Greenlight is actually nice here. You have a product, just chug it on there. Well, you'll also have to put on additional work, though - try to pitch the game to some random strangers on the Net. Showcase it, provide feedback, respond to feedback, if you want a demo, that makes your job easier and harder at the same time. If you want your game published on a console...to be frank, I don't really know how you'd do that but there you go - you'll have to find out. You'll also have to make it comply with whatever specifications they want. From what I've heard, you even need to pay them money, or at least pay Microsoft, not sure about PSN. Releasing it is about lots of information gathering, and also lots of sales pitches. You'll probably want to get the word out there about your game.
1. You get an idea. It can be a game mechanic, a story, a visual style, whatever. Something that you can build a game around. Say, you may decide to make a sports game - that's fairly broad. Or you may want to make a Half-Life mod about shooting underwater aliens. That's more specific. Whatever the case, you now have something to work with.
2. You plan it. So you flesh it out more, think about appropriate other things, say if you wanted to make a sports game, what sport? And how would it play? Basically flesh it out. Also do some research. Lots of research, probably. Is this idea out there already? Can you use it? Can you actually make it, as in, physically able to - you may want a full 3D game that is visually stunning, with super complex mechanics and great narrative, that has all the best voice acting in the world, but it's pretty much impossible to make this. Next, what technology would you use for the game? What would the target audience be? And so on and so forth. You get the gist, I hope. You have to know your project very well after this. Analyse it for break points, try to prevent them.
It probably sounds harder than it is in practice, though. If you have a solid idea, you'll know most of these things, since you'll be constantly thinking about it. Another part of the planning is your team, if you have one. Who will do what and how would you all work together. Again, it sounds a bit harder than in practice. But if you have just assembled a team now, DO NOT SKIMP HERE! I can't stress this enough. If the team is new, even if they know each other from before, as long as this is the first time they work together, more likely than not Things Will Go Wrong. I've seen too many projects just die because of awful team work. And it wasn't anybody's fault...in a sense. It was also everybody's, too. Teamwork is crucial.
So make the best out of it, basically the planning is the time to test your idea before building it, predict the failures and try to prevent them. Not all of them, of course, you aren't going to know everything that might go wrong, but you'll know enough to be able to fix stuff on the fly.
Also important, what project lifecycle would you use....which is basically "how am I going to build this" from a more meta perspective, not talking about the actual idea itself but the process. Just check Wikipedia [http://en.wikipedia.org/wiki/Systems_development_life-cycle] on this for an overview. What would work best here? For example, if you have a very concrete idea in mind, you'd adopt one approach, however if you are not entirely sure, and intend to add features as you go along, then the same approach wouldn't work.
3. Coding...well, it's not that hard. During the planing phase, you would have found what to use. Be that Java or C++ or specific third party libraries. Say, if you want to make a 3D game, you might not write everything from scratch but instead use the Unreal Engine, or the Source SDK or something. Of maybe, you and/or your team simply doesn't have the experience for some technology, so you'll go with what they are most comfortable with. That means, that, say, you could make the game in Java if that's what you know.
But basically, the rest of it is...coding. Get people together and use a keyboard. You would have done some of the work in the planning phase, so most of what you'll be doing is just make these ideas manifest. Say, you want a funky jumping mechanic where you could leap from wall to wall, you'll just have to make the game behave like that.
Well, there is another important part here - project management. You have to oversee the project. If not you, then somebody. There are lots of ways that things can and will go wrong if you just implicitly trust people will do what they need to. Someone has to make sure things stay on track, that everything is going smoothly as planned (or close enough), that the team is getting along, also to prevent feature creep[footnote]"Hey, we have this, but wouldn't it be cool if we have that as well? I know we wouldn't plan it but it wouldn't take much time." No, just no. Write it down, make a To Add list that you'll go through later, if you will but feature creep is a very likely way to kill a project[/footnote].
And finally, try to follow the development lifecycle. Or if it hinders you, try to change it. But very basically, you need to have some goals and milestones to go through. That helps keep things on track.
4. And at the end, release it. That can be very hard or not-as-hard depending on the intentions. You could just put it on a website somewhere to download for free. That's the game released. Or you might have to talk to other people to help you distribute it. Steam Greenlight is actually nice here. You have a product, just chug it on there. Well, you'll also have to put on additional work, though - try to pitch the game to some random strangers on the Net. Showcase it, provide feedback, respond to feedback, if you want a demo, that makes your job easier and harder at the same time. If you want your game published on a console...to be frank, I don't really know how you'd do that but there you go - you'll have to find out. You'll also have to make it comply with whatever specifications they want. From what I've heard, you even need to pay them money, or at least pay Microsoft, not sure about PSN. Releasing it is about lots of information gathering, and also lots of sales pitches. You'll probably want to get the word out there about your game.