How to Make a FPS in 3 Easy Steps....
by Jerane Alleyne · in General Discussion · 08/06/2001 (11:40 am) · 3 replies
A friend of mine asked me an interesting question...is there a guide on the creation of a game, a first person shooter in particular. I don't mean a postmortem, more like a general technical guide as to the production process, covering areas like programming game logic(physics for what models, player characteristics in games, etc), type sof models needed for levels/maps, what kind of sound and visual fx are needed...stuff like that.
I know that the use of game engines can make differences in creation of games, but I figure there are more things that are universal than there are differences.
Anyone know anything!
Thanks!
I know that the use of game engines can make differences in creation of games, but I figure there are more things that are universal than there are differences.
Anyone know anything!
Thanks!
#2
Elements Of A Game Engine
By Luke Hodorowicz
Game Design: The Essence of Computer Games
By Geoff Howland
Targeting Your Genre Audience
By Geoff Howland
The Key to Completing Your Game: Motivation
By Geoff Howland
You can also find more resources at flipcode.com or GameDev.net. I hope that some or all of this is useful.
08/06/2001 (1:01 pm)
I am not sure if there is a resource like you are asking for, but here are a few options. One is to go to the Garage Games search engine on the right and check for help on this web site. You can look under the "Resources" section, or whatever other categories you might think helpful. You can also just look under the What's New section (again here to the right) and look at the entire resources list there. If neither of those help, I recommend looking at these:Elements Of A Game Engine
By Luke Hodorowicz
Game Design: The Essence of Computer Games
By Geoff Howland
Targeting Your Genre Audience
By Geoff Howland
The Key to Completing Your Game: Motivation
By Geoff Howland
You can also find more resources at flipcode.com or GameDev.net. I hope that some or all of this is useful.
#3
In teams I've found that basically upto actual implementation everyone is raring to go and people start to lose interest quickly, especially artists and level designers who may not have anything to do initially other than playing with ideas. Quite often a team project is saved by one guy who is prepared to run around and keep everyone focused. Team projects fail as soon as everyone starts thinking this isn't too interesting. You (especially if you're dealing face-to-face) only need 1 properly motivated guy to hold a team together because he can seem to inject new life into the team.
I think other advice on development with new teams is DON'T go hyper-technical to start with. The game a small group of us are planning is essentially a Tribes clone (It is pretty different but the generic premise is the same [squad warefare]), why! because we know the engine can handle it easily. Once that is done we have a far more ambitious project, but we want to get to know what the engine can and cannot do first. If you dive in the deep end you could find yourself way out of your league, or even worse having to 'make do' because the tools you have aren't upto the job. Now I'm not suggesting every V12 makes a squad warfare game. But if people aren't sure of what can be done with the tool (as that is essentially what the engine is) then falling back already well established genres and ideas may be worthwhile whilst you increase your experience. Make that uber game number 2, when you know your limits, the limits of the engine, the limits of your patience. And if you create 1 game you can probably create more. If you can't even create your simpler game initally your more complex uber-game that will make you and your group renowned will probably never get made. Afterall I would love to see 50 games that are all FPS shooters out initially than hearing that 45 amazing games have been canned and 5 good games have been released. Why? Because I know that 50 teams out there can go the distance (plus the experience in making that first game will put you far more at ease when developing later projects) and their 2nd game should be something really interesting. That's why I love indie games they are usually far more ambitious once the team gets established, it's just getting established and getting used to the development cycle that kills a lot of teams.
Hehe. After reading it I wouldn't urge anyone with great ideas to ditch them and go and make Quake. OTOH if you're worried about your technical ability or the possibility that come crunch time you will hit a wall and sack it in see if you can create Quake. If you can then let your imagination loose. Why am I doing something that has already been done if I know I can go the distance? Well my team want to do it, and I'm grateful because they are approaching games development for the first time and I want to see how they handle it.
As for creating a FPS in 3 easy steps, no. There is a lot to consider even when you're just looking at the surface. Who is the enemy? What are the weapons? Player story and motivation. Setting. Then when you get below that there are physics, damage, player speed, how high he/she/it can jump, and so on. Every FPS is unique, even Quake/Quake2 are significantly different experiences. Even games produced on the same engine have highly different experiences. They may all be blast 'em ups but all have different physics, different motivations, different settings, different enemies. There is no 1,2,3 to creating a game, even bad games need to be thought out (although sometimes it appears that they weren't). The best way to make an FPS if you don't want to sit down and figure it all out is to find a couple similar, play them, see what you like about them and steal it. If you like the idea the main character's melee weapon is a dirty great big sword, steal it. Obviously your own imagination has to bring these threads together in unique manner and creating a Quake meets Duke Nukem meets Tribes meets Counterstrike meets NOLF is simply dumb, but taking elements you enjoy from each and then blending together by the designer to produce a new experience may help take some of the weight out of designing. Personally I try to design my stuff from scratch (it tends to work better logically), but I find elements from games I have played creeping in. Look out into games market for inspiration. What you want has probably already been done before in a game out there right now, and whilst it may differ slightly it can offer and idea on how to implement that particular element into your game. However plagerism is not a good idea, if you can look at your game at the end and it doesn't feel like another game you have suceeded, even if a number of the elements were taken from other games. If people can turn round and say "hey this is exactly Quake, but in a fantasy setting" you may have failed (please note the may, if you want to create Quake in a fantasy setting you have obviously succeded :D). Keep things original, but don't be afraid to look at other games, afterall if someone has done the work already you might as well use that as a springboard and improve on it.
Did I miss anything? Am I spouting rubbish? ;D
Owen
08/08/2001 (6:37 pm)
That motivation factor is very true. As a fairly experienced modder of the Quake Engines I often found (as a solo player) that once I had achieved the technical goals of the project it quickly lost interest. Why?! Because all the interesting stuff was done. It took a lot of effort to pull myself through to the project conclusion, and releasing a playable bit of code. My opinion on keeping projects interesting is don't do all the interesting stuff at the beginning. If you code your cool bits first you have the boring routine stuff left, followed by bug fix after bug fix. If you start with some routine stuff, then do some cool stuff, then code the routine stuff for that, then more cool stuff e.t.c and after that cycle the prospect of bug fixing is not such a chore. Just pace yourself, with a fair bit of determination you can pull it off.In teams I've found that basically upto actual implementation everyone is raring to go and people start to lose interest quickly, especially artists and level designers who may not have anything to do initially other than playing with ideas. Quite often a team project is saved by one guy who is prepared to run around and keep everyone focused. Team projects fail as soon as everyone starts thinking this isn't too interesting. You (especially if you're dealing face-to-face) only need 1 properly motivated guy to hold a team together because he can seem to inject new life into the team.
I think other advice on development with new teams is DON'T go hyper-technical to start with. The game a small group of us are planning is essentially a Tribes clone (It is pretty different but the generic premise is the same [squad warefare]), why! because we know the engine can handle it easily. Once that is done we have a far more ambitious project, but we want to get to know what the engine can and cannot do first. If you dive in the deep end you could find yourself way out of your league, or even worse having to 'make do' because the tools you have aren't upto the job. Now I'm not suggesting every V12 makes a squad warfare game. But if people aren't sure of what can be done with the tool (as that is essentially what the engine is) then falling back already well established genres and ideas may be worthwhile whilst you increase your experience. Make that uber game number 2, when you know your limits, the limits of the engine, the limits of your patience. And if you create 1 game you can probably create more. If you can't even create your simpler game initally your more complex uber-game that will make you and your group renowned will probably never get made. Afterall I would love to see 50 games that are all FPS shooters out initially than hearing that 45 amazing games have been canned and 5 good games have been released. Why? Because I know that 50 teams out there can go the distance (plus the experience in making that first game will put you far more at ease when developing later projects) and their 2nd game should be something really interesting. That's why I love indie games they are usually far more ambitious once the team gets established, it's just getting established and getting used to the development cycle that kills a lot of teams.
Hehe. After reading it I wouldn't urge anyone with great ideas to ditch them and go and make Quake. OTOH if you're worried about your technical ability or the possibility that come crunch time you will hit a wall and sack it in see if you can create Quake. If you can then let your imagination loose. Why am I doing something that has already been done if I know I can go the distance? Well my team want to do it, and I'm grateful because they are approaching games development for the first time and I want to see how they handle it.
As for creating a FPS in 3 easy steps, no. There is a lot to consider even when you're just looking at the surface. Who is the enemy? What are the weapons? Player story and motivation. Setting. Then when you get below that there are physics, damage, player speed, how high he/she/it can jump, and so on. Every FPS is unique, even Quake/Quake2 are significantly different experiences. Even games produced on the same engine have highly different experiences. They may all be blast 'em ups but all have different physics, different motivations, different settings, different enemies. There is no 1,2,3 to creating a game, even bad games need to be thought out (although sometimes it appears that they weren't). The best way to make an FPS if you don't want to sit down and figure it all out is to find a couple similar, play them, see what you like about them and steal it. If you like the idea the main character's melee weapon is a dirty great big sword, steal it. Obviously your own imagination has to bring these threads together in unique manner and creating a Quake meets Duke Nukem meets Tribes meets Counterstrike meets NOLF is simply dumb, but taking elements you enjoy from each and then blending together by the designer to produce a new experience may help take some of the weight out of designing. Personally I try to design my stuff from scratch (it tends to work better logically), but I find elements from games I have played creeping in. Look out into games market for inspiration. What you want has probably already been done before in a game out there right now, and whilst it may differ slightly it can offer and idea on how to implement that particular element into your game. However plagerism is not a good idea, if you can look at your game at the end and it doesn't feel like another game you have suceeded, even if a number of the elements were taken from other games. If people can turn round and say "hey this is exactly Quake, but in a fantasy setting" you may have failed (please note the may, if you want to create Quake in a fantasy setting you have obviously succeded :D). Keep things original, but don't be afraid to look at other games, afterall if someone has done the work already you might as well use that as a springboard and improve on it.
Did I miss anything? Am I spouting rubbish? ;D
Owen
Rene Kersten
but there isn't really anything you wont learn when you just try it...
oh and i would start off with little stuff, learn to program in general (try everything, it will come in really handy when making a game).
since game programming is one of the toughest forms of programming, dont expect to make anything good when you start.
if you dont learn by making little stuff in the start, then you will get stuck with bigger projects with planning etc.
really really learn programming/making art good before making something as big as an fps, it can take you up to 3 years before you are ready (okok, this might be a bit too long)
but when you are that far, then there is nothing that good logical thinking and practice cant learn you (when it comes to game logic/planning/design)