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.

The game we’re are going to build is a 3d shooter that is very much inspired by classic games such as After Burner, Space Harrier and Star Fox. The goal is to achieve a minimal viable product at the end of the development cycle with a working prototype that anyone can expand upon. Also by building the game with JavaScript and WebGL, we will be able to create a game that is accessible across a number of different platforms such as Windows, OSX and Linux.

Selected Frameworks and Tools

The game we are going to build will utilize several components:

  • JavaScript: Our language of choice and no, it has nothing to do with Java!
  • 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.

Shooter Concept sketches 01

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.

Concept Boss Battle 01

Eye Shots 03

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.

So lets get down to brass tacks. Borrowed from Mike McShaffry’s book Game Code Complete, the application architecture we are going to use for our game development is MFC, a document/view model. Although it is generally geared toward C++ development, we can use it’s rigid structure to break up our JavaScript code into chunks that are easily manageable. Our game code will be broken up into three different sets:  Application Layer, Logic and View. Starting with the top level and working down, the application layer will control the hardware and OS. In this case, this part will be done with three.js and jQuery. Thanks to Mr.Doob and AlteredQualia, most of the heavy lifting of creating a graphics engine is taken care of, leaving us to deal with gameplay and design. The logic layer will manage the game state and how it changes over time(“delta“). Finally there is the view layer which presents the game state with graphics and sound. Do keep in mind these patterns were tempered with time and countless real-wold game development scenarios. With that being stated, remember these guide lines are not set in stone and in the end you have to go with what works for you.

Game Layers

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.

application layer

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.

logic layer

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.

views layer palyer

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.

views layer ai

Class Structure

The final piece of the puzzle is the way we are going to set up our classes. Most JavaScript you come across on a day to day basis is done with a functional structure where the code is in a C like manner–usually done by creating functions and moving from top to bottom. Being that we are developing a large scale application and not small scripts, we are going to leverage the object-oriented(“OOP“) nature of JavaScript. We will be developing an API where we can create inherited objects, being that most of the elements in our game are going to share a lot of the same attributes. Having a modular design is going to end up saving us from repeating code and setting it up so we can expand on the objects we have already built. Below is a hierarchy view of how our classes are going to be setup, detailing how each object is going to communicate to each other and how the inheritance will work. The connections and draw lines are the flow of how the game is going to function.

connections

Conclusion

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.

Next

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.