Build your own first-person shooter! Classic single-player FPS project template for Unreal Engine 4 in the style of the original Doom, Unreal, Quake, and so on. Make game creation fun again!
![](https://i0.wp.com/www.deplorablemountaineer.com/wp-content/uploads/2019/05/Thumbnail.png?fit=284%2C284&ssl=1)
Have you tried to create a large game project and got lost in the weeds? It is very easy to do. If you were working for a AAA game development company (like Epic Games), that probably would not be a problem, because the company would have a YUGE staff for all phases of game development, and you would have maybe a 100- or 1000- page Game Design Document. This would detail everything that needs to be done in the game, and it will have been reviewed multiple times by perhaps 100s of employees (developers, designers, testers, artists, management, and so on) (though even with all that, it may be changed as more is learned!) so you always know what needs to be done and how it fits with the rest of the game.
Now, at the other extreme, suppose you are a one-person game studio. You are it! You are the designer, developer, artist, manager, and janitor. You might not relish the idea of writing a 1000-page Game Design Document (GDD) all by yourself, and not only that, reviewing it, editing it, making sure it is all consistent (with itself and with available technology), and so on. The good news is, you don’t have to in order to reap benefits when you find your self headed for the rough.
At the smallest extreme, you can write a one-page GDD that hits the highlights. This is far better than nothing at all, even if it isn’t as detailed and well-reviewed as the AAA Game Development Company’s 1000-page GDD.
If you want more, a 10- or 20-page GDD gives additional benefits. 20 pages easily helps you focus enough that even if you find yourself in the weeds, you can see the way out.
If you are a 10-person game studio, 10 or 20 pages would be the minimum, and you could probably produce larger, with more editing and review. My point is smallness of company is no excuse for not planning at all. Just plan less!
A Game Design Document (GDD) will likely contain at least the following information: title of game (or working title if not finalized yet), genre of game (first-person shooter, puzzle, classic arcade, etc.), technology used (Unreal Engine 4? Unity?), platform (PC/Mac/Linux, Android, etc.) and a brief description of the game.
I recommend more than one description, of varying lengths (for varying purposes).
The tag line is a one-sentence description of the game. This gives more of a taste than a picture. An example tagline (from a movie rather than a game) is, “In space, nobody can hear you scream”, which was used on movie posters for Alien when it first came out. This drew the crowds by giving a flavor of what the movie was like: terror in space.
The elevator pitch is a one- or two-paragraph description of the game. The name comes from this: you work for a company and you happen to find yourself in an elevator car with the CEO, and the CEO asks, “what are you working on?” In the time it takes to get to your floor, you need to explain what you are doing, and of course, make it sound like it’s worth the salary you are being paid.
Finally, a longer Summary of the game gives a good picture of what is happening when somebody plays it. If it is a multi-page GDD, go ahead and use one or two pages for the summary. If it is a one-page GDD, you might skip it (or just consider the rest of the document to be the summary).
If the game has an unusual key mechanic, it should go in the summary, or perhaps in a section of its own. What I mean by “mechanic” is how the game is played: jiggle the joystick back and forth to make the character run, and jiggling faster makes the character run faster. Pressing a button makes the character jump. (I vaguely recall an Atari console game like that). It’s not always necessary to explain the mechanic. For example, most First Person Shooters work the same way. Still, you might want to explain unusual moves (dodging, double-jumping, wall-walking, turn into a spirit like in Prey, etc.)
Assets needed for the game should be specified. For a one-page GDD, it would be a summary of assets and style for them, but for a more detailed GDD, you can get really detailed if you want.
Rules of the game should be specified. Think of a boxed board game: often on the inside cover of the box, the rules of the game were printed. This would include things like win or lose conditions, mid-game achievements (like how the player would end one level and start another), if and how it is scored, how powerups and pickups affect the game, and so on.
Depending on the game, a section for research might be appropriate. For example, if you are making a bowling game, you might have a section giving all the specifications of bowling determined through online research: lane dimensions, markings on lanes, pin sizes and weights, ball size and weights, and so on.
In addition to data from research done, this section can mention research that still needs to be done. As the research is completed, the section can be edited to show that.
Here is a (incomplete, but a good start) GDD for a 3D bowling game.
Precision Bowl
Sports Game
Adult
Set up ball speed and spin, choose your target, and try to bowl a perfect game!
Choose a bowler character to select strength and speed as well as appearance. Choose a bowling alley, as well as normal or outer space lighting. Choose a ball to select weight, outer coating, and optional asymmetric weight block, as well as appearance. Choose an alternate spare ball if you want. Choose a lane and oil pattern. Then start bowling!
Select a spot. Select a target. Adjust speed up or down. Adjust spin. Choose to use strike ball or spare ball. Hit “Go” and watch the bowler follow your commands. Score!
Physics, Physics, Physics! Player takes all the time they want setting it up, then hit Go and it’s all physics!
Ball, Pin, Lane , Bowler character(s), Sweeper, Pin Setter, Ball Return, Gutter, Monitor
Alley features: tables, other lanes, back wall, ceiling, other walls and floors, snack bar, juke box, entrance, restrooms, ball washer, front desk and shoe rental, people?
Various ball patterns, normal and space light (cosmic or galactic bowling type of situation, with UV lights)
Standard pin and special pins (e.g. red pin), normal and space light
Wood or composite lane, with oil patterns, normal and space light
Bowling alley features materials, normal and space light
Character skins, normal and space light
Sweeper material, normal and space light
Pin Setter materials, normal and space light
Ball Return materials, normal and space light
Gutter materials, normal and space light
Monitor UI material
Bowling animations for character, including right-hand, left-hand, and for backup ball, straight ball, and spin ball.
Camera animations, Sweeper animation, Pin setter animations, Ball return animations
bowler talk, ball rolling, Pin hits, Ball return sounds, Music, Announcer voice, Ambient bowling alley sounds
Attach to character, Roll, Drop, Destroy, Initialize
Destroy, Initialize
Take Ball, Drop Ball, Roll Ball
Spawn ball
Deploy
Reset Ball, Reset Frame
Update
Follow Character, Follow Ball, Overview Lane
How to Write a Game Design Document on Gamasutra
Sample FPS Game Design Document, 23 pages, team of two
Searching online, I see many (like me) have wanted to work on characters in Blender by exporting the Mannequin skeleton provided by Epic, but there are problems with doing this. The older versions of Unreal Engine 4 it just doesn’t work, apparently, but the later versions, I got it to mostly work by searching online, through the Udemy Blender Character Creator course, and through lots of trial-and-error.
I am using Unreal Engine version 4.18, but it should be similar in recent engine versions. I’m also using Blender 2.79, again should work in recent Blender versions (2.8 and above is supposed to be a major change in Blender so it might fail there).
The first job is to export the mannequin so it can be used in Blender. Yeah, that’s 18 steps, but then the other jobs take lots of steps too…. This is not really a quick-and-easy job despite the humor in the next heading.
Now, you can work on your character. You probably want to replace the mesh with your own. I recommend not moving the bones around in Edit mode or Pose mode or it might confuse Unreal (Edit mode it definitely will, Pose mode might impact retargeting). Make your mesh, and parent it to the root armature. Unreal uses vertex groups for rigging, so either select create empty vertex groups and manually put vertices in the right groups, or select one of the options to convert bone weights to vertex groups or something like that. Test your rig in pose mode to make sure it still works right! Also unparent the original mannequin from the root armature (keep transformation if you want to keep the mannequin, or just delete the mannequin otherwise—I keep it around during modelling, making it semi-transparent, so you can have a reference for the right humanoid proportions compatible with the rig).
Now that you have your new character with Unreal’s Mannequin rig, you want to get it back into UE4.
But if you are only testing, ignore those last two paragraphs and just re-import the mannequin to see that this works right.
These steps are needed for Option 2, but not for Option 1.
This post is not about game programming, but about setting up a Linux virtual box loaded with data science tools. The repository can be found here on Github. Below is from the README on Github for this box.
and you should see something like:
$ ls -AF
.git/ bootstrap.sh* howtos/ LICENSE README.md Vagrantfile
It is important that bootstrap.sh and Vagrantfile be there, as well as the howtos directory (or at least the README.md)
in the terminal. This will take some time, a lot gets installed.
In your guest OS that you just ssh’d into using “vagrant ssh”, you can find the howtos in the directory:
/vagrant/howtos
These give you quick instructions for setting up the Kaggle app and accessing the guest OS’s web, RStudio, and Jupyter notebook in your Host OS’s web browser.
The howtos are reproduced here for convenience:
chmod 600 ~/.kaggle/kaggle.json
kaggle -h
jupyter notebook --generate-config
jupyter notebook password
jupyter notebook --ip 0.0.0.0
Github is a good place to keep your remote Git repositories, especially if you want to share them. However, if you want to keep it private, it costs extra. Also, Github has a limit on the sizes of files it can store. You can partly get around this with Git LFS, though that has some convenience costs and the free version has limits. An alternative would be to have an external hard drive, perhaps one connected to your network, and keep your “remote” Git repo local.
Personally, I have an external drive connected through the network to my Windows 10 PC, mapped as my Z: drive, and I use it as a backup drive. It is also a good place to store remote Git repos.
I also use Atlassian’s Sourcetree for my Git repo management. This is a GUI front-end to Git that makes working with Git convenient. It also allows you to use an internal Git system so you do not need to install Git separately. This system comes with Git Bash, a convenient BASH shell that is useful as a command shell separately from using Git.
Let us suppose I have a project called MyProject that already has some files in it, and I want to maintain a separate Git repo. It is located in the directory D:\Documents\Reps\MyProject. You can follow along with your own project if you change the paths and names appropriately.
Your project has now been committed, but only locally, that is within the newly-created .git directory in your project directory.
Now, we get to the real point of this post: creating the remote repository on your disk drive. My setup is that the external networked hard drive is the Z drive, and I want to put the remote in a file called Z:\Repos\MyProject. As before, change this according to your actual situation.
git init --bare /z/repos/MyProject
Note, git bash uses /z/ instead of Z:\ for the root of the Z drive, and the directory slashes go forward instead of backward. This can be fast or slow depending on how fast your drive is. If all goes well, you will see a response like “Initialized empty Git repository in Z:/repos/MyProject/”.
git clone --bare /z/repos/MyProject
If all goes well, you will see a message like “Cloning into bare repository ‘MyProject.git’…”. It is ok if you get a message like “warning: You appear to have cloned an empty repository.”, because we still need to “push” the last commit to this remote repo.
/z/repos/MyProject
(or the one that you used above)
You now know how to keep a git repo local. I considered showing how to set up a Gitlab instance in a virtual machine, but that was quite involved, and there are some difficult issues with using networked drives and Gitlab.
A first-person shooter (like Robot Dynamite) needs a first-person character. In contrast to a full third-person humanoid character, all the player can see is the gun and the first-person arms mesh. However, if it is a multiplayer game, or even a single player game in which one can look in a mirror or a closed-circuit video, the full third-person mesh is visible.
A first-person shooter (like Robot Dynamite) needs a first-person character. In contrast to a full third-person humanoid character, all the player can see is the gun and possibly part of hands and arms of the character. However, if it is a multiplayer game, or even a single player game in which one can look in a mirror or a closed-circuit video, the full third-person humanoid character is visible.
A first-person shooter (like Robot Dynamite) needs a first-person character. In contrast to a full third-person humanoid character, all the player can see is the gun and possibly part of hands and arms of the character. However, if it is a multiplayer game, or even a single player game in which one can look in a mirror or a closed-circuit video, the full third-person humanoid character is visible.
You must be logged in to post a comment.