Welcome to part 00 of Let’s Make a 3D Game with HTML5, a new tutoiral about building an HTML5 game with three.js. This series will walk you through building a game from the ground up with three.js, covering all the major areas you’ll need to face when building your own 3D game.
Selected Frameworks and Tools
The game we are going to build will utilize several components:
- Sublime Text 2: Amazing text editor for writing code.
- Chrome: To run our code and take advantage of its rocking development tools.
- Three.js: Abstracted graphics framework for WebGl.
- jQuery: Helper framework to initialize and capture events.
- Photoshop: Photo manipulation tool to help develop concepts and textures.
- Cinema 4d: 3d application to create and animate our art assets.
- RoadKill UV: Tool for unwrapping 3d objects for texturing.
- Collada or JSON 3D Objects: Output files for the graphics pipeline.
- github: God bless version control!
- JsUnit: Undecided sure if unit testing this is overkill…
The choices are all down to context. These technologies are the ones I am most familiar with. I know most people might not have access to tool such as Cinema 4d and Photoshop, but you are more than welcome to follow along with open source alternatives such as blender and gimp.
Concepts and Game Play
We can’t have a game with out a slick game concept. This one involves aliens, lasers, spaceships, and the kitchen sink. Well maybe not the kitchen sink, but you never know. Last year, I started creating some concept art for a game idea that I had brewing in my head. The first step was the create some basic sketches with pen and paper, in turn settling on a basic visual style for the game. There are many ways to go about creating a game, but being that I am a very visual person, creating concept art is what drives my ideas forward. One pitfall to be wary of is to have a game driven by content, but we will pivot as needed if the game play is not fun. It is generally a good idea to have a basic understanding of what kind of game you want to make before starting and this is even more true when dealing with 3d.
Now that we got some ideas for our game, I could have gone ahead and started working on developing the game in code by using just basic shapes as standins. If you feel you are not confident with your 3d art skills, this is definitely a route you should consider. But, this is not how i work. Being an artist, I tend to have a clear vision of look and feel, so before coding I wanted to get my ideas down. Using 80′s video games and cartoons for inspiration, I went about creating style boards of a visual mark that I wanted to hit. This is a common practice when working in the motion graphics and animation industry. You generally start with a basic concept, work through a set of different visual styles, and end up settling with the best one.
For the last step in the initial design process, I utilized my 3d application to create a basic animation of how the ship would function. This let me experiment with camera placement and prototype game play mechanics all inside of a pre-rendered animation. From what I understand, this is a common technique used in the AAA game industry. By creating animations of how the gameplay might look like, the team has a mental mark of how the final product will play out.
Game Engineering and Architecture
What do you mean game engineering and architecture! Can’t we just start coding and figure out the details later? If this was a 2d game, I might have to agree with you here. The reason being a bit of planning will go a long way in 3D game design. We want to approach game development as an engineer and not as a n00b hobbyist. Also, you dont want to end up with unwieldy spaghetti code as your project grows in scope.
Consider the beating heart of the systems: the application layer. This is where the devices are handled, memory is managed, internal time is set, and most of all the core of the game lives. The core consists of the system libraries, the main loop, or, in our case, the animate and render methods. Another addition to the application layer are the low level implementations, such as threads and networking. By keeping the application layer separate, it will give us flexibility to port our code to another platform with minimal effort.
The logic layers are the second component that combine to make up our game. These involve subsystems for managing your game’s world state, communicating state changes and other systems, and taking in input commands. Also included in the logic are systems that dictate the games universe. A good example of this would be the physics engine–controlling how objects move and respond to each other.
The last system is the game view. This system is in charge of showing the game state and taking in inputs to be converted into commands that are transmitted to the game logic. The view layer itself can be split up into three separate entities. The first and most important would be the view of the player. This draws the game on the screen, plays audio queues, and takes in commands from the UI.
The second could be the AI agent and the final view will be for remote players over a network. All get the same state changes from the logic and do different actions accordingly.
If you made it this far congratulations, now you know a little more about how to develop a video game and you are well on your way to become a 1337 coder. For those that might feel a little overwhelmed at this point, don’t fear what you dont know. The first step in becoming an expert is to learn about the things you don’t know, then the next step is to embrace your ignorance and work toward enlightenment. If you have any questions please feel free to contact me or leave a comment.
Now here are links that might come in handy down the line.
- The Github repo for code and assets for the project.
- Shooter game’s design document.
- Boilerplate template for starting a three.js project.
- Three.js API.
- C4D Cafe, a nice place to learn more about 3D.
In the next part, I’ll go through the process of setting up a pipeline to export models from our 3d application into our game.
The areas the next tutorial will cover will be:
- Review boilerplate code of three.js.
- Baking textures and lights into 3d objects.
- Exporting models from our 3d application.
- Converting models into a pipeline friendly format.
- Importing 3d models and displaying it in our game.
- Understanding the limitations of our environment.
Some parts might take several weeks to cover depending on how involved they are.