Roadmap for Learning Unreal Engine

As part of learning how to make an engine, I want to immerse myself in another engine.

I'm really good at Unity 3D, so I have a really good perspective about how it works. For contrast, I'm going to learn the next most popular engine, Unreal Engine. Learning Unreal has the added benefit of allowing me to sell some of my work on the Marketplace. Since I am most definitely working toward making an ocean renderer and a terrain generator, I can take them both a step further and turn them into full-on toolkits for Unreal Engine.

Below is the roadmap I'm planning to take in order to learn it:

1. Blueprints
1. Quick Start
1. Required Setup
2. Construct Launch Pad
3. Convert Actor to Class Blueprint
4. Create Starting Point
5. Test Overlapping Actor
6. Launch Character
7. Assignments
2. Basics
1. Navigating the Graph
2. Placing Nodes
3. Connecting Nodes
4. Creating Functions
5. Setting and Getting Actor References
6. Working with Arrays
7. Collapsing Graphs
8. Making Macros
9. Debugging
10. Blueprint Communication Project
1. Sample Project Setup
2. Event Dispatchers/Casting to Blueprints
3. Binding Events on Spawn
4. Communicating with HUDs
5. Communicating with Multiple Blueprints
6. Assignments
3. More Advanced
1. How to Set Up Input on an Actor in Blueprints
1. How to Add Components in Blueprints
2. How to Set Up Character Movement in Blueprints
1. Character Setup
2. Input and Game Mode
3. Finishing Character Setup
4. Creating Blend Spaces
5. Animation Blueprint - Idle and Walk States
6. Animation Blueprint - Crouch States
7. Animation Blueprint - Jog State
8. Animation Blueprint - Jump State
9. Animation Blueprint - Prone State
3. How to Find Actors in Blueprints
4. How to Possess Pawns in Blueprints
5. How to Reference Actors in Blueprints
6. How to Set Up a Game Mode in Blueprints
7. How to Set Up Inputs in Blueprints
8. How to Spawn/Destroy an Actor in Blueprints
9. How to use the OnHit Event in Blueprints
10. How to use Raycasts in Blueprints
11. How to use Timers in Blueprints
12. How to use Cameras in Blueprints
13. Class Creation
2. C++
1. Basics
1. Quick Start
1. Create a new Project
2. Create a C++ Class
3. Write and compile C++ Code
4. Test
2. Player Input and Pawns
1. Customize a Pawn
2. Configure Game Input
3. Program and Bind Game Actions
4. Assignments
3. Game-Controlled Cameras
1. Place Cameras In The World
2. Control Camera View in C++
3. Place A Camera Director In The World
4. Assignments
4. Variables, Timers and Events
1. Creating an Actor that Uses a Timer
2. Expose Variables and Functions to the Editor
3. Extend and Override C++ with Blueprints
4. Assignments
5. Player-Controlled Cameras
1. Attach a Camera to a Pawn
2. Configure Input to Control the Camera
3. Write Cod to React to Input
4. Assignments
6. Components and Collision
1. Creating and Attaching Components
2. Configuring Input and Creating a Pawn Movement Component
3. Coding our Pawn Movement Component's Behavior
4. Using our Pawn and Components Together
5. Playing In Editor
6. Assignments
2. More Advanced
1. Survival Game Tutorial Series
1. Section 1
1. Movement
2. Animation
3. Object Interaction
4. Hunger System
5. Networking Support
2. Section 2
1. Flashlight
2. Inventory
3. Switching Weapons
4. Deal Damage
5. Death
6. Respawn
3. Section 3
1. AI Zombie
2. PawnSensing
3. Behavior Tree
4. Section 4
1. Dynamic Time of Day
2. Advanced Player Spawning
3. Game Loop
5. Section 5
1. Game Networking
2. Carrying Around Barriers and Bombs
2. Shader Development in Unreal
1. Flat Shading
2. Basic Diffuse
3. Per Pixel Diffuse
4. Basic Specular
5. Per Pixel Specular
6. Normal Maps
7. Transparency Maps
8. Transparency Masks
9. Geometry Shaders
3. Procedural Generation
1. Procedural Mesh Generation
2. Marching Cubes
1. Marching Squares
2. Basic Terrain Deformation
3. Metaballs
1. SPH Fluids
3. Perlin Noise
3. Projects
1. Procedural Terrain Generation with Marching Cubes
2. Ocean Toolkit
1. Ocean Wave Simulation
2. Wave Particles
3. Object Interaction and Buoyancy
4. Hybrid Simulation
3. Fluid Toolkit
1. SPH Simulation
2. Eulerian Simulation
3. Hybrid Simulation

This should get me up to speed on how Unreal Does Things. We'll see on Friday how good I feel about this, and we'll update and modify as we go along.

Routines and Current Plans

SAVE, then go to WAR

Alright, sometimes it happens as SAV and go to RAW, but who cares. This is based off of a concept I heard about from Puttylike, a blog I follow about being a multipotentialite (something I'll cover in its own blog entry). She called it the "Multipotentiate Morning," which is, itself based off of the Miracle Morning, The idea is to get up earlier than normal, and spend time doing the following:

• Silence
• Affirmations
• Visualizations
• Exercise
• Reading
• Scribing(Writing)

Called SAVERS, for obvious reasons. These are intended to help you be productive early, and set a precedent for being productive throughout the day. Her application was to make it so that you can work on all of your projects every day.

She modified it to fit her needs, and so have I modified it to fit mine. Coming from the small town that I do, and knowing all of my enemies for getting into the games industry: Procrastination, lack of a tech infrastructure, being overwhelmed, and a lack of knowledge; I have decided to characterize my whole thing as kind of a video game.

The first thing is to SAVE my game at the beginning of every day. This sets me a good foundation I can go to any time I start to feel like I'm losing my way. This remains unchanged. Start the day with about 30 minutes of various kinds of meditation, spend 30 minutes exercising, then I take an hour break to relax, eat breakfast, before spending 3 hours doing the next stage.

The second thing is to go to WAR. Writing(this blog), doing Art exercises, and then Reading. This allows me to do a little bit of work on one of my pet projects, specifically the part I feel like working on, without taking away from portfolio production time.

So mine is

• Silence
• Affirmations
• Visualizations
• Exercise
• Reading
• Writing
• Art
• Reading

This is further supported by a nightly routine, but there's no neat acronym for it. The general idea is to set a rhythm so I can easily get to sleep.

• Plan next day
• Hygiene
• Litter Box
• Clothes for next day

This way I am on the right track for the next day.

Current Plans

I've finally figured out exactly how I want to brand myself to employers, and what I really feel like I want to become the best at. I have a great amount of passion for real-time simulation, especially of water, and I have a great amount of passion for procedural generation. So my portfolio projects are going to focus on that. I'm trying to limit each part of this to one month "phases." I'm going to showcase three parts of my skills:

• Ocean Surface Simulation
• Phase 1: Basic Simulation
• Basic Surface Simulation
• Tiled Ocean
• Perlin Noise displacement for each tile, and LoD tesselation
• Foam and Whitecap generation
• Phase 2: Advanced Effects
• Wave Particles and Buoyancy
• Splash Particles and SPH Interaction
• Buoyancy Displacement of Surface
• Terrain Interaction: Foam and Waves
• Phase 3: Lighting
• Caustics
• God Rays
• Fog
• Diffuse
• Procedural Generation
• Phase 1: Basic Generation
• Marching Cubes
• Chunk Streaming
• Procedural Texture Generation
• Island Generation
• Phase 2: Advanced Effects
• Procedural Grass and Plants
• Procedural Trees
• Underwater Flora
• Phase 3: Coupling Terrain with Water
• Different Generation for Lakes and Rivers
• Shore Waves and Flow displacement
• 3D Rasterizer and Abstraction Layer
• Phase 1: Basic Improvements
• DirectX Rendering Abstraction Layer
• Flat Shading
• Faceted Lighting (per-vertex)
• Diffuse Shading
• Specular Shading
• Various Texture Filtering Methods
• Phase 2: Advanced Effects
• Point Lights
• Spot Lights
• Multiple types of light
• Phase 3: Engine
• Input
• Physics
• Scripting
• Shadows

My Artist Library, and the skills I'm going to need to build

Bruce Timm - DC Animated Universe

• Simplified Anatomy
• Action Lines
• Strong Silhouettes
• Simplified clothing (ideal for animation)
• Angular drawing style

Bryan Konietzko (Avatar: The Last Airbender)

• Extremely expressive faces
• Simplified facial attributes (easier to make expressions)
• Plays a lot with facial proportions
• Strong poses (stronger than Timm's)
• Action Lines
• Good understanding of anatomy, wrinkles, fat
• Still simplified anatomy
• Generally rounded
• Sub Style: Der-shing Helmer

Eiichiro Oda - One Piece

• Always keep in mind that he's bad at drawing women, unless he's doing an extreme body type.
• Switches between simplified chibi-ish style and strong anatomy
• Strong shapes and silhouettes, especially on larger characters like Franky and Kuma
• Plays a lot with body proportions. Keeps everyone a certain number of heads tall, but they may have a giant torso, or really long legs.
• Extreme scale. Things tend to be scaled up to a ridiculous degree, like Water 7 being a giant fountain.
• Heads and hair tends to have strong silhouettes (see Franky, Kuzan, Sengoku, Blackbeard)
• Lots of extreme body types, when he wants to.
• Lots of normal body types, too. Zoro and Sanji are muscled normals.

Hiromu Arakawa - Fullmetal Alchemist

• Well defined noses (weird for anime, and mostly only on older characters)
• Strong anatomy, generally not simplified
• Strong facial anatomy as well on older characters
• Differences in faces are made primarily by varying mouth, nose and eye sizes, and varying face shapes, although they're mostly either round, triangle, or heart shaped, with a few squares on the men.
• Functional, mostly realistic designs

So the final list of skills is:

• Anatomy
• Strong Poses and Action Lines
• Silhouette Design
• Extremely simplified muscles
• Extremely simplified clothing
• Facial Anatomy
• Expressions
• Drawing mundane things at large scales

And of course, the big two that I need to learn before I learn those: Construction and Design. Those will take time, of course, but they're also the most fundamental skills, and will be just as important.

Several things have said that I should also pick a master to study from, and Leonardo DaVinci has always been one of my engineering idols, so he's the natural pick for me now, as I learn to draw.

Here's hoping this all goes fairly well!

So what actually are the basic tools art?

The actual "elements" of art are: Line, Shape, Form, Space, Value, Color and Texture. Most traditional courses start from here, but I think this is actually a mistake. There's a few more basic things you should focus on, before you learn these fundamentals.

List of Tools for this stage:
Literally any pencil - Softer lead is better, but my animator friend just uses a .03mm mechanical pencil.
Literally any eraser
Some paper, although a sketchbook is nicer to work with than printer paper.

If you want to do the Edwards Stuff you'll need:
Plastic Transparency Sheets
Card Stock
Wet Erase Markers

I cannot stress enough that literally any pencil and eraser is fine when you're beginning. Just like having the best software doesn't magically make you a better programmer, having expensive pencils or paints will not make you a better artist. </stress>

How to see:
This is a huge part of learning to draw, and it's often overlooked. Many even think of this as one of those "you have it or you don't" principles of art. The best resource for learning this, other than the above-linked tutorial from Nsio, is Betty Edwards' Drawing on the Right Side of the Brain. This resource focuses on shifting your thinking about drawing from the symbolic left side to the expressive right side.
Primary exercises:

• Self-Portrait to see how bad you are right now
• Pyrolettes/Vases-Faces
• Blind Countour Drawing
• Contour Drawing - Using an image plane
• Negative Space Drawing (still using an image plane)
• Proportion and Perspective (still using that image plane)
• Putting it all together by drawing a profile portrait
• Re-doing your self-portrait by turning your mirror into an image plane

These are a good set of confidence boosters, and a good place to get started. Once you've finished them (should take you around a week, if you do about an hour a day), you can start moving toward actually developing a practice regimen.

How to Practice and Learn:

Linked above is one of the best articles I've read on how to practice. Take some time to look at his other tutorials, especially the "How to Practice" set. Some other really good tips from there, though, that are more universal:

• "Create a library of art that looks like the stuff you want to do."
• "List out the skills you need to learn in order to draw like them." Utilize other artists to help you identify what makes particular artist's style unique
• "Choose one skill to study."
• "If you are starting out, focus on Construction or Design."

I'd add one more thing: Determine why you are learning to draw, and what skills are required to be at that level. If you're just wanting to develop a bunch of prototype assets, you don't need to be nearly the same skill level as, say, someone who wants to become a professional character artist.

A more comprehensive set of warm-up exercises (do at least some of these every day):

• More Pyrolettes - Shifts from verbal to non-verbal modes of thinking
• Gestural Drawing - Use a site like Quick Poses to try to capture the action lines of a pose.
• Upside Down Drawing - Helps you to not think about the symbols of what you're drawing
• Automatic Drawing - Just kind of doodling and letting your hand fly around the page. Helps you get pure lines.
• Negative Spaces - Gets you thinking about space generally, and helps you to forget about the object.
• Non-Dominant Hand - Helps you loosen up
• Primitives - Lines, Triangles, Circles, Squares, Polygons, Cubes, Pyramids, Cones, Cylinders and Spheres Planes
• Line Exercises
• Drawing Primitives in Perspective - start with planes
• Perspective Grids

Next, we need to pick a skill to develop, and study it. This is the time where you'll want to look at art you like, and start breaking it down. My recommendation, look at this list by Brandon Dayton, and look at his suggestions for studying a single image. Focus on things that help you develop the skill of constructing objects by using primitives, or the things that make a piece of art look interesting. How does the artist construct his/her shapes?

Another thing that's really helped me figure out construction is Chris Hildenbrand's excellent tutorials on Programmer Art. He focuses on using inkscape and playing around with nodes and vectors to create robust art for video games.

This wouldn't be a bad time to instead look at tutorials and read books. Draw With Jazza is a fantastic resource, as is the collected works of Andrew Loomis (used to be free, apparently the Loomis Estate is reprinting them). Deviantart has a host of good and bad tutorials, but here is the list that I like. These focus on construction more than anything else, although there are a few that are on things like value and color theory.

Finally, take what you did in your study phase, and try to apply it. Draw something with it. Test your knowledge of how a thing is constructed. Play around with it. Try breaking the rules, and try to understand why they're there, and when you can break them.

This should get you started, but the biggest thing is, you can't just run through a bunch of tutorials and suddenly be able to draw. Work at it every day. Eventually, you'll get to that point where you can "draw from life" and "draw from reference."

Next entry is going to hopefully be some documentation of where I'm at right now, and what I'm trying to accomplish. I'll list out my artists that I really love, and the skills that I need to build.

Art Rant

Learning art is hard, if you're not already an artist.
I just started learning to draw for two reasons:

1. I want to be the programmer version of Dean Dodrill (Maker of Dust: An Elysian Tail), and make a game entirely on my own.
2. I'm a graphics programmer, and I feel like understanding art is just as important as understanding the physics of graphics.

With Programming, there's well-defined basics: Syntax, Variables, using functions, Decision Statements, Loop Statements, Declaring and Defining Functions, Objects, and Pointers. Any tutorial teaching these is, by definition, a basic tutorial. Most tutorials that assume you know these things, state as much. When you look up "basic programming" or "c++ tutorial," you get these same principles. When you look at more advanced tutorials, the better tutorial writers are able to list prerequisite knowledge required, and teach a very specific skill.

This is actually reflected in 3D modeling, which has more of a parametric, programmer-like way of doing things. When you learn the basics, they actually seem to follow this idea of building up a basic set of skills and tools to be used to shape models: Creating Primitives, Selecting and Editing Meshes, Selecting and Editing Vertices, Edges and Faces, Extruding Faces and Box Modeling, Using Modifiers, Setting up Reference Images

I'm probably forgetting a bunch of things, but the idea is that you're able to build a bunch of skills up to a point. That point being that last point: Reference images. If you want to get to the point where you're designing your own characters, environments, and materials, you'll need a foundation in traditional art.

This is where I start to have a lot more trouble. I mean, there's plenty of tutorials for Inkscape, Photoshop, Illustrator, ZBrush and Flash, but those are tools, like a pencil or a set of paints. Most basic tutorials focus on similar ideas to the 3D tutorials, essentially how to use the tools, but not how to actually draw.

Tutorials on deviantart and otherwise tend to have a fairly specific thrust toward how to draw specific things and characters, not the basics. When they do talk about basics, it comes to a few really annoying principles: 

"Draw from life, draw from reference." 

Okay, how do I do that? 

"Draw what you see."

When I draw what I see, it looks like this:

[insert one of my beginner drawings]

"Well, just keep practicing. You'll get better. Maybe choose an artist you like, and copy their work. Practice some gesture drawing."

Translate these into any other medium, and you're no longer talking about the fundamentals. "Look at other people's githubs, and copy what they did. Make programs out of typical processes you do every day. Practice by just randomly making things as fast as possible." Not only are these bad habits for a complete and total beginner, they would often make beginners completely discouraged and make them think that programming is simply a talent, and you either get it or you don't. Sound familiar yet?

So what are the basics? How do we, the art dunces of the world, start to learn how to see like artists? This is the journey I've been on for the past few weeks, and I wanted to document what I've learned so far, and what is needed, as well as my progress. My goal? I need to come up with a number of characters, weapons, items and tile sets for a game I'm working on. This encompasses both environmental design and character design.

In my next post, I'm going to catalog all of the sites and tutorials I've found, and try to organize them into a regimen that can actually be used.

The basis of Firestorm Engine

So here's the first post on actual engine design, rather than tools and libraries.

Game engines are interesting beasts. They range from game-genre specific, like Source for FPSs or the Starcraft 2 engine for RTSs, to genre neutral like the ubiquitous Unreal Engine and Unity 3D. The thing that these have in common are that they have an editor, that they are extremely data-driven, and that they focus on allowing for the game to be made by non-programmers without ever having to touch a compiler.

The core purpose of my independent study is to understand what all goes into a game engine, why certain choices are made, and what the low and high level structures are. At its highest level, a game has to have certain specific things: Scene Management, Graphics, Input, Collision Detection and Physics, Sound, User Interface, and Scripting. Collision and Physics tend to go hand in hand, even when no physics simulation is required, so I lumped them together. My general task is to take the various libraries for these systems, and glue them together.

For Graphics, I've decided to use OpenGL for now, as Ogre3D is too difficult to set up, and too much of Monogame is being deprecated. SDL will be used to generate the context and to handle Input, the User Interface, and sound since it already has that functionality between itself and its plugins. Collision and Physics will use the well liked Bullet Physics library, as there's a wealth of tutorials available for it. Scene Management is something that is very domain-specific, and so I'll be writing my own scene management system. I'll be working on that as I go.

The core goals for this are: A working, demonstrable game and a working, demonstrable editor. These will help me understand the dual role of engines. To help content creators create the game, and to run the game created.

Task the first is to create the basic engine and then the graphics rendering part. On the engine side, once things are in place, I want to be able to just call Update() on a graphics component or Update() on the graphics system, and have them call the necessary functions under the hood. This is the general model for each system. That's the purpose of using components and entities, rather than making a unique game object class for each kind of game object. This also works for systems because all systems require a startup, update, and shutdown function, as well as a reference back to the main engine. Rather than coding all of these functions into the main engine, they're all treated as their own system object. This makes debugging easier, as this also means that systems can be turned on or off without having to comment out entire sections of code.

I think this is a pretty good place to start. Now to codecodecodecodecode...

References:

• Game Engine Architecture by Jason Gregory
• Real Time Collision Detection by Christer Ericson
• Game Physics Engine Development by Ian Millington
• Real Time Rendering by Tomas Akenine-Moller et al.
• Evolve your Hierarchy: Refactoring your game with components--Cowboy Programming

Ogre3D vs. OpenSceneGraph vs. Irrlicht vs. Panda3D vs. Monogame vs.OpenGL Free for all

So, I need to get this figured out and soon. I am trying to decide what the best option for making a game engine for my independent study course would be. The long and short of it is that Ogre3D is working on my wife's desktop, but I cannot build it for my mac, and I need to be able to work on it wherever/whenever. So here's a grand shootout of different libraries, with all their pros and cons laid out, with my own conclusions about what I am going to use after. Disclaimer: These are basically my combined thoughts from when I tried to work with it, or from DevMaster.net. Your mileage may vary, I'm just trying to aggregate my thoughts into one spot. On with the tables and lists!

Engine:	Ogre3D	OpenSceneGraph	Irrlicht	Panda3D	Monogame	OpenGL
Pros:	Platforms: Big 3, iOS, Android, WebGL Comprehensive, has scene management, resource loading, many built in shaders Abstracts most meshing functions Has extensions for input, GUI, physics Well Documented API, many tutorials, books	Platforms: Big 3, Playstation Scene Management, resource loading Many Plugins	Platforms: Big 3, Xbox Decent Tutorials Easy to get up and running(see below)	Platforms: Big 3 Uses Python Extensively Integrated tools for physics, AI, network, Audio, packaging	Platforms: Most of them Comprehensive Uses C#, my favored language Decently supported Can use OpenGL and DirectX	Complete and total control over my engine Don't have to deal with installing except in the case of physics engine
Cons:	Poorly documented for Mac, so far impossible to set up Must use 1.7 for set up, 1.8 for manual, 1.9 for available downloads, and 1.10 for latest features. Many things for ease of use are simply missing.	Poor Community and Documentation Poor support for procedural generation	Difficult to set up on Mac Poor Documentation	Documentation lacking, especially for c++ Not easily set up on IDEs that are not Visual Studio Because it uses integrated tools and is a full-stack engine, Panda3D needs to be disqualified for my purposes.	Have to make my own WebGL support Not helping me learn better C++, which is part of this exercise Unknown how easy it will be to install BulletSharp	The very definition of going to square one Have to implement all resource loading from scratch Might be too big a scope for a 6 week project

What it really seems to be coming down to is Monogame, OpenGL, or Irrlicht. I guess the game is then to figure out which one takes the least amount of time to install and get 10 rotating cubes on the screen. Once I have that down, I should be able to figure out what the best next step is. I'll update with my results once I get it done.
UPDATE: Ditching Monogame because OpenTK's been abandoned. Ditching Ogre3D because of its documentation. Haven't set up Irrlicht yet, but OpenGL/SDL is seeming like the way to go.