Or… the journey through the x, y, and z axes through the lens of a computer screen.
An overview of the tools that I have used and the thinking I have gone through whilst creating a 3d Game
Thinking of getting into 3d game development?
Wondering how hard it is?
Wondering what sort of tools you will need to know about, or use?
Note: this is part of a series of articles: See 3d Game Programming with Java and libGDX — Overview of Articles
When learning or implementing a new technology, there is only so much new learning that you would be able to do, whilst progressing your project at an adequate speed. The more new things that you have to learn, the more cognitive overload that there is.
In development parlance, these are called ‘innovation tokens’, each new piece of toling, or knowledge that you need, the more tokens you will have to spend. There comes a point at which the new learnings become over-whelming, so that nothing is truly learned well.
So, I evaluated a lot of options, and knew that the OpenGL side of things was where I would want to spend my innovation token, everything else is a distraction, and would slow me down.
Initially, I started looking at Unity3D as a completed environment, this is what I had to learn:
- The integrated development environment (IDE) that came with it was unfamiliar
- The language (c#) was unfamiliar
- Low level OpenGL calls
This was far too much, by choosing libGDX, I had a familiar IDE in eclipse, and a familiar language in Java, so I just had to learn more about OpenGL and 3d graphics.
Here is an un-ordered list of the tools and things that I have needed to use and know, in order to get a 3d game off the ground.
Here is what I ended up using
- Java — as the programming language
- Eclipse — as the Integrated Development Environment
- libGDX — as the baseline game engine
- VisualVM — for keeping track of memory and performance issues
- ‘The OpenGL® Programming Guide’ — unofficially known as the ‘Red Book’ — as the reading material
- Trello — for tracking ideas
- GitHub — for source control of the project
- GitHub Desktop — a nice UI to push changes and saving myself from using the command line
Command Line Tools
- fbx-conv — for converting models into the native libGDX format
- ffmpeg — for converting movies into animated gifs
- AnyConv.com — for converting models from different formats into .stl
Model and Image Editing
- GIMP — for image editing
- Blender — for 3d modelling and textures
Choice of language
Java, Java, Java
- Java is fast… enough… I need 60 fps — the game I am building is not a first person shooter, it is more a builder-type game
- I know Java, really well
- You know what else uses Java — Minecraft, they chose it for the same reason, they knew Java, and used the Light-Weight Java Graphics Library which underpins jMonkeyEngine3, and libGDX
Choice of Integrated Development Environment (IDE)
I have used eclipse since back in the day when it was IBM Visual Age for Java, there are others out there including
I looked at a lot of libraries
- Unity3D — a Superb framework and development environment — however the language is based on C#
- Godot — Once again, a framework and development environment, C# language based (along with other Scripting languages)
- jMonkeyEngine — A well regarded IDE and engine, however based on the NetBeans IDE
- lwjgl — this is a low level API library, with little tooling around it
- libGDX — The library of choice
When evaluating the options, I also looked at a few other
- Needing to know deep levels of OpenGL functions and APIs
- Needing to learn another language
- Whether there was an IDE
‘The OpenGL® Programming Guide’ — unofficially known as the ‘Red Book’ due to the cover being predominantly red, as shown below
Whilst you do not have to read the entire book, it will take you through the concepts that you will need to know when rendering a scene.
A very simple board which I add cards to as I remember things, just to keep track of everything that I am working on. I prioitise
GitHub is a source code control site where you can safely store your code and changes, so that, should you make a mistake, you can roll back the changes.
GitHub Desktop (download)
When on larger projects, I would use the command line tool, however, for a single collaborator, I use the Desktop tool
fbx-conv is a libGDX tool that converts .fbx formatted 3d models into .g3db (binary) or .g3dj (JSON formatted text) which can then be read by libGDX and imported into the project
ffmpeg is a command line tool that will convert a videos through various formats — I use this to convert screen recordings to animated gifs.
ffmpeg -i input.mov -vf "fps=10,scale=640:-1:flags=lanczos,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -loop 0 output.gif
Converting 3d Models from one format to another, a
Model and Image Editing
Blender is the free and open source 3D creation suite. It supports the entirety of the 3D pipeline — modeling, rigging, animation, simulation, rendering, compositing and motion tracking, video editing and 2D animation pipeline.
It is used both for personal and commercial projects and has been used for hollywood style blockbusters and television studios.
Free and open source — the Gnu Image Manipulation Project is a one stop shop for all of your image editing needs.
Memory and speed is paramount in a 3d game, being able to see what is going on is going to be extremely helpful in catching slowdowns early on in the process.
For example, you run your programme, everything is going well, you are still hitting your target of 60 frames per second, then suddenly, you have added additional code, the framerate is dropping, the movements are jaggy and stuttered — this is where VisualVM will save your proverbial bacon.
I run this periodically to ensure that the memory usage and the framerate are still within reasonable limits.
When my framerate dropped, I noticed that I was creating over 2 million Vector3() instances — something which I could then see and fix before it became a larger problem.
There is a lot to learn about 3d game programming, and a lot of tools out there which will require your familiarity with — don’t be put off, each of the tools are relatively easy to use, and as your experience and comfort with each of the tools grow, it will get easier.
Also the amount that you need to kow for each of the tools is relatively small to start off with. As your game grows larger, so the need to dig into the tools a little more, however this is all balanced as the learning is spread out over all of the tools, a little bit at a time. The majority of the time will be spent in the game logic, with sidelines into the tooling