Sunday, August 28, 2016

C++ Object Construction Working

C++ Object Construction: It Works!

I can now create static meshes via code!

This was a lot more annoying that it should have been. Every example on the web was wrong because Unreal has altered the API.

My function to build an object is simply this:
SpawnBlock(FString MeshLocation, FVector Location, FRotator Rotation, FVector Scale)

That is how it should be. I will default the rotation and scale so you only have to provide a mesh location and X/Y/Z coordinates for it.

I fine tuned my performance analysis:
you can have 11x11 non shadow casting actors in your vision without stutter (at least on my machine). I built an 11x11 matrix of cubes in front and behind me and neither produced stutter. 12x12 objects in front of my started causing slight jumps. My prior test was 19x19 with me at the center of the cubes. That is likely similar numbers, just a different way of thinking about it...

Getting object construction in place is all the wiggle room I needed to get started producing environments.

I played with the functionality to randomly pick between a blue and texture material:

This is all with one AActor class.

They make it REALLY hard to do this because:
1. The actor is created from a factory
2. You can only find meshs and materials in the constructor
3. You can't pass anything custom into the constructor.

It is a real suck fest.

My only way around this is to either:
1. create an object name that is unique and communicates mesh and material to pick
2. communicate via static variables

static variables will be my current approach but that is fragile. If the construction of these actors ever becomes multi-threaded, it will break.

Saturday, August 27, 2016

Unreal Performance Testing with the Vive

Unreal Vive Performance Testing

I've been doing some performance testing to see how to increase the number of objects on the screen.

Here is what I found:
1. Turning off casting shadows has a huge impact on performance.
2. Objects with 2 textures and few triangles (12) hurt performance more than objects with 1 texture and more triangles (156). I'm glad I learned that now. Multi-texture objects are out!
3. Distance without LOD has no effect on performance. To be expected but good to know.
4. Scale has no impact on performance
5. Static vs moveable has no impact
6. Turning on the tick for an object has no impact
7. scaling/rotating/moving an object has a HUGE impact on performance. Very very bad.
8. A material with color versus an image has no impact on performance. This was surprising to me.
9. Executing code each tick without affecting the object had no impact on performance.
10. The sky box had no impact on performance.

With no shadow casting, 1 texture UV mapped on the object and no movement, I was able to put 19x19x19 (6859) objects on the screen without a stutter.

This was a huge increase from before.

Now... I can't just be adding objects without shadow casting but I will try to avoid it when at all possible.

I also did testing of what felt visibly acceptable for the number of generated landscape regions/squares. I found that 10x10 felt very reasonable. I will allow players to customize that area so we'll see what works as things progress.

This scene was produced from my automatic object generation blueprint. I just tweaked the scale and only allowed one vertical row of objects to be created.

Next steps:
1. convert the code to pure c++
2. start adding shadow casting objects
3. look into using landscape mesh grouping to allow more of the same object on the screen at one time.

Since everything in my game will be built on the fly, I needed to figure out where exactly that should happen. I had a false start by creating a blueprint function and hooked it into my level start. That works but it isn't the correct spot for it. The correct place appears to be "Game Mode". I create a custom game mode, tell the world to use it and this acts as the "overseer" to landscape, item and player spawning/destruction.

Here is the documentation for how the Unreal Engine works. I hate spending all my time reading but this is pretty important stuff:

Friday, August 26, 2016

A little blueprint demo

I put together a little demo using blueprint and c++.

I created an actor that hovered and spun in c++


#pragma once

#include "GameFramework/Actor.h"
#include "FloatingActor.generated.h"


class SIDE_STEP_API AFloatingActor : public AActor

// Sets default values for this actor's properties

// Called when the game starts or when spawned
virtual void BeginPlay() override;

// Called every frame
virtual void Tick( float DeltaSeconds ) override;

float RunningTime;



#include "side_step.h"
#include "FloatingActor.h"


// Sets default values
AFloatingActor::AFloatingActor() {
  // Set this actor to call Tick() every frame.  You can turn this off to improve performance if you don't need it.
PrimaryActorTick.bCanEverTick = true;

UE_LOG(MyLog, Log, TEXT("Floating actor constructed"));


// Called when the game starts or when spawned
void AFloatingActor::BeginPlay() {


// Called every frame
void AFloatingActor::Tick( float DeltaTime ) {
Super::Tick( DeltaTime );

FVector NewLocation = GetActorLocation();
float DeltaHeight = (FMath::Sin(RunningTime + DeltaTime) - FMath::Sin(RunningTime));
NewLocation.Z += DeltaHeight * 50.0f;       //Scale our height by a factor of 20
RunningTime += DeltaTime;

FRotator NewRotation = GetActorRotation();
NewRotation.Pitch = (RunningTime + DeltaTime) * 20.0f;
NewRotation.Roll = (RunningTime + DeltaTime) * 20.0f;
NewRotation.Yaw = (RunningTime + DeltaTime) * 20.0f;

// UE_LOG(MyLog, Log, TEXT("Delta Height for float: %f"), DeltaHeight);

I then used the level blueprint code to spawn this actor a bunch of times.

I created variables to control the number of actors spawned and their distance.
> I see that Unreal blew up and lost the distance variable... sigh...

This is the result:

It didn't take much experimentation to discover the number actors I can put on the screen is pretty pathetic. 6x6x6 (216) on my beastly machine. If I went to 7x7x7 it choked in certain directions.

That is a frighteningly small amount of cubes on the screen at once before stutter sets in.

I really have my work cut out for me...

c++ and Unreal

c++ and Unreal

This has been taking a lot longer than I expected.

First I took a break and played No Mans Sky. I sunk a week and a half into that game. Then I found out what the ending was. There is no ending! That was the last straw. I went back and watched early trailers, footage and interviews with Sean Murray. That guy is a big fat liar. It is crazy. When someone would ask him if something was in the game he would always say yes. He would even say things that were clearly not in the game. I played the PS4 version. I has also preordered the limited edition for PC from 8-bit. I am unable to return it even though they haven't shipped it to me!


I promise you this. I will never misrepresent anything in my game development. I will tell you exactly where I stand. If you can't start from an honest position, you've got nowhere to go. Vaporware is one thing, but telling people something is there when it clearly isn't is disrespectful.

OK, so I digress... why has it been taking so long to get started...

First I needed to install visual studio and brush up on c++.

Then I watched a horrible youtube video series on Unreal and c++ wasting hours of my time. I did learn how to output to the log from with c++ and monitor the unreal log, so I guess that is something...

Now I am watching a series that is much more informative and practical:

This is how it goes with any development. There is an incubation period where you are learning. Once I push through this I can start implementing my vision.

The ironic thing is I have already psuedo coded the classes for my world generation. I just need to implement them in c++, hook it into unreal, see where the performance bottlenecks are and I'll be off an running. So hopefully in the next few weeks I will see some results for all my slogging through retraining in blender, Unreal and c++.

Friday, August 12, 2016

Unreal C++

This weekend's objective:

Create 2 c++ classes and expose them to blueprint. This may turn out to be nastier than I expect since I need to brush off my c++ coding skills and install a c++ editor.

TMap wrapper
It boggles my mind that Unreal doesn't support maps/hashes natively. Any language worth its salt has this.

In case you don't program much, these are the core containers that need supported:
array/list (a list of objects in order. A list is usually a wrapper around an array automatically managing size)
map/hash (using a key you can get an object back)
set (unique container of objects. I can limp along without this but it is handy)

Environment maintenance
I will be procedurally constructing everything. I need a class that will manage this that I can expose to blueprints. Example: As the player moves, this class will update the environment. Environment construction relies on a seed for randomly generating everything. It also relies on a variety of performance settings. This will not only control object/landscape/actor spawn/de-spawn but perimeter effects such as fog. It will have a variety of other tasks I will implement later as things progress

This is pretty close to where I want to begin with environment creation:

I will start with something brain-dead simple like this:

When I have something working I will post a screen shot of it.

Wednesday, August 10, 2016

No Man's Sky

I haven't played the game yet but I've been reading reactions. This is very important because I am also creating a procedural world. I will be posting reactions that provide specific insights.

Here is one:

Been playing this game for a while now, and even though it's too early to give a final opinion on this game, so far it's been underwhelming to say the least. I don't personally care about multiplayer as much as I do about just how empty this game is, and how quickly you end up recognizing the patterns behind the algorithm that generates these terrains, plants and animals. Once you do, all of the interest in exploring new planets quickly fades as you realize that the next animal will simply be a new permutations of parts you've already seen, or that the next planet will be a combination of geologic and plant features you've already seen but just shuffled up differently. If you have a few dozen body designs set for each section of the body, you can get an insane amount of permutations (just how you can shuffle a 52 card deck into an absurd number of variations), but ultimately they're all the same.
The survival mechanics are horribly unfun. I'm not sure many people seem to enjoy mineral collection, especially due to a really small inventory size. It mostly consists of scanning and following icons, and is incredibly repetitive and not very rewarding. Combat is also really unsatisfying, with enemies that don't react to getting hit and no real threat outside of space (where the main weapon is a lock-on laser). The exploration controls with the ship are pretty decent and it's fun to fly around while listening to the excellent atmospheric music, but wears out its welcome fast because there's not much exciting hidden content. The monoliths you find don't give much, alien outposts are not exciting.
There are a few things that this game needs badly:
  1. Implement bases, storage, and furniture. This needs to be done almost immediately. I want to be able to set up base camps on planets, forge for resources, and store extra stuff.
  2. Add unique non-generated content that add some sort of story or quest with specific details about a past civilization, more than the generic monoliths. The bottom line is this: human-made content with some sort of narrative will always, always have more thought put into it than content spit out haphazardly by an algorithm.
  3. Bases need special atmosphere bubbles, so you cant start farms and bring different animals from different planets there. This should include plants, let's grow plants from other planets on new planets, or seed dead worlds.
  4. I want to be able to take animals to them and move them from planet to planet. Add cargo ships at least.
  5. Fix the map so we can see the names of the systems you've already been to.
  6. Fix the inventory so its not a nightmare to manage. You spend most of the time in this game mining and grinding for materials, at least make this part seamless.
  7. Add some variation to the animal behavior. Simply varying the colors and meshes isn't enough, they all do similar pathfinding and don't attack and interact with each other. There should be an entire ecosystem of realistic behaviors, with full life cycles and possibly some mechanics that we can study these and earn some sort of reward. Right now "taming" them essentially means they poop out resources.
Those need to be done like, IMMEDIATELY. I can respect the sheer ambition of this title, but the fact that this was developed by a team of like 15 people also shows throughout. This game is fucking empty.

Sunday, August 7, 2016

Choosing a direction

There is so much to learn it can be overwhelming to know where to go next, The myriad of directions leaves you sometimes going in none. Option overload...

Should I polish my blender skills?
Should I continue to study blueprints?
Should I practice importing meshes and textures?
Should I build a sample scene?
Should I write some C++ and see how it hooks into the engine?
Should I build some materials?

The list goes on and on...

I generally know what I need to do but I am afraid if I try to hit the ground running with too little tool knowledge I will handicap myself by doing something the wrong/hard way.

I'm sure other game developers feel this way too. I could spend a year just learning tools inside and out and that would leave me without any progress on my game.

I think I am going to spend the day brushing up on my blender skills. I've done a ton of blender work in the past but I've noticed my second nature keystrokes have gotten rusty. I need that 3D modelling back in working order. Building meshes quickly and getting them into Unreal is very important for a 1 man shop like myself.