The Rand() posts of a growing software engineer. Mostly about game programming, old college stuff, and some fun side projects. Comments, discussions, and games are greatly encouraged!
Showing posts with label Unreal Engine 4. Show all posts
Showing posts with label Unreal Engine 4. Show all posts
It is that time now. The time to begin the Quest, to a Quest Plugin that will meet all your Questing needs and desires in Unreal Engine 4. This first post of Part 2 of an Unreal Engine Quest Framework will go over the high level design of such a system. I will go over two prototypes that have lead me to my current design. I will also discuss the requirements for such a Plugin. Finally, I will discuss the final high level design of the Quest Framework in Unreal Engine 4.
So, without further ado, let us move on-wards in our Quest (I promise, I will not stop).
Old Prototypes
First, I am making this framework with previous experience. As we all know, there is a Part 1 to the Quest Framework. This was the initial prototype. There were obvious issues with it I will discuss at a later time. I also made a second prototype. It turned into a mess. I will discuss everything that went wrong when implementing it.
Prototype the First
The original prototype consisted had two clases: AQuest and AInfo. AInfo classes where AObjective nested in an AQuest. This framework supported Binary Quests - pass or fail type scenarios. AObjective object tracked it's own completion state. AObjective tracked state by using two int32 parameters: CurrentProgress and TotalProgressNeeded. There was no replication, no RPC, just dumb state tracking and some FText for the UI.
This was a flawed design lacking robustness.
These flaws were many. It was too simple, required a lot of work to integrate, and did not have any management included. Using two AInfo classes as a base resulted in serialization, binary, and network overhead. Combined with having to spawn Actors to run quests, a lot of resources became wasted. Finally, there was no management of Quests and Objectives outside of their scope.
There was no easy way to edit Quests and Objectives in the Unreal Engine 4 Editor. It required needless Blueprint Subclasses of AObjective and AQuest to build quest paths.
Prototype the Second
The second prototype was somewhat more advanced.
It used UObject as the base class and Instanced everything. There were objects named UQuest, UObjective, and UReward. Each of these classes had a specific purpose.
The core of the system was the UQuest object. It contained a list of UObjectives. Then the UObjectives had URewards for applying a rewards system for completing objectives. UQuest had three objects of UQuestState that drove the logic of a UQuest.
An example of these states were a UQuestState_Active, UQuestState_Passed, and a UQuestState_Failed. Then there were child classes of these states such as UQuestState_Transition. These managed how transitions worked when changing state. They also ran the actual logic behind a UQuest object. Essentially, UQuest was a StateMachine.
It became a mess. Worse yet, adding in Replication, UI features, and ActorComponents, made it worse. There was too much complexity and overlapping class responsibilities. Binding to new events added a lot of complexity. It also made management of quests and objectives harder. It was a lot and it was doing too much.
With the old prototypes explained there were several lessons that I learned. A Quest Framework should be simple. A framework for end developers to create customized Questing experiences for their players. It should not force Quests into the world. It should not force metadata parameters such as a Title, Pictures, Sounds, etc. It should be event based and have the ability to adapt to many states and results. It should allow any interested party to observe state without coupling to the quest framework.
Requirements of a Robust and Flexible Quest Plugin
So, what is it that we desire in a Quest Plugin for Unreal Engine 4?
Well, it needs to be generic and support many use cases. Such use cases would be single or multi player and dedicated servers. It needs to support saving status and/or state and progress. It needs to not force implementation, such as what parameters to use in the UI. It needs to support replication on demand as well as server managed RPC methods. It needs to be lightweight.
Being generic and the support for many use cases allows for a core foundation of a Quest Framework / Plugin. This will allow use of it in many game projects. It must not dictate quest types, quest metadata, and how quests progress.
A good Plugin should have network support built in. This is 2017 after all, if your game isn't networked in some way, well, it is a fun single player game. Plus, lots of people like to make MMOs, which (probably) requires some networking and (may) have lots of fun quests. This means a Quest Framework needs to support Unreal Engine's Replication and RPC frameworks.
Quests are a way to track player achievements within a game and to guide the player to some end goal. These games are not short and allow for the player to leave for extended periods of time. This is usually why games have a Save system. Unreal Engine 4 allows for a SaveGame framework. A good Quest Plugin / Framework will support this as well.
Finally, a good Quest Framework will not force implementation. It will only allow for adaptation and let the developer decide presentation.
With this in mind, I have concocted a design for a general Quest Framework in the Unreal Engine 4.
Quest Framework Overview
So, with this in mind I will explain the core concepts for the new Quest Framework in Unreal Engine 4.
The concepts involve the mixed use of several class types. These types are UDataAssets, custom Interfaces, an Event/Message hub, as well as a Graph Editor for quests. Finally - for good measure - we will use UActorComponents as a way to let the Gameplay code interact with the quests. And yes, this will be a lot of work - but a good system or framework is always worth the workload, especially if it is reusable.
The various objects inherited from UDataAsset will be quest, objective, and rewards descriptors. The actual data defined in the class will be by the developer. (EDIT: After writing this article, I may leverage the new feature of TMap in Blueprints). Think of this as the Blackboard object in Unreal Engine 4 Behavior Trees.
Interface UObjects will be logic drivers for the Quest Framework. Such drivers will detect the state of an objective and a quest. It will also moderate rewards received, how to give out rewards, and various other tasks. Think of these as a similar role to Tasks, Services, and Decorators in Behavior Trees in Unreal Engine 4.
We have defined the roles an structure of quests and objectives. Now I can go into how to decouple questing logic from the rest of the application. From current experience, event or message based systems are great at this. This is because we just need to create a proxy event object or a message object that transmits information we care about. This reduces overhead of knowing exactly what a quest or objective object is.
Finally, a nice feature to have would be a Graph Editor. The Graph Editor will also have functions that allow us to create new quests, objectives, logic, and quest flow. The Graph Editor will also allow us to layout the paths and tracks of a quest.
That is it for Unreal Engine Quest Framework Part 2: Design - check back later where we start defining some code!
I have been using Unreal Engine 4 by Epic Games for almost 3 years now and have really enjoyed developing games in this game engine. I have spent hours looking for good content on applying my C++ skills in Unreal Engine 4.
What I want to share with you right now are some good resources that I have constantly gone back to for references. There are about three categories I would split my findings into for Unreal Engine 4 C++ tutorials and examples. These categories would be the obvious, the popular, and the obscure.
Unreal Engine 4 C++ Resources: The List
The Obvious
Whether it be from the horses mouth or an expert in the field. These are solid choices for learning anything about Unreal Engine 4 C++ coding.
C++ Tutorial on Unreal Engine's YouTube Playlist
This tutorial is great for beginners with Unreal Engine 4's C++ API. It will teach you how to create gameplay code, interact with objects, some simple HUD work, as well as some effects. I watched a few of the videos when I was starting out just to get a jumpstart into C++ with UE4.
The Wiki is always a good place to stop by when looking to implement some common game components. My very own Quest Framework is posted there as well. There are so many tutorials involving AI, C++, Blueprints, and Building with UE4 that it is an invaluable resource.
This is a decent place to go to get some information about C++ in Unreal Engine 4. You may not always get an answer, but when it comes to the more clear questions and descriptions of what you want, there are some good people that will help you out. Sometimes a staffer will comment as well and really steer you into the right direction.
The Source Code
The source code. (You MUST be logged in and a part of Epic Games to view this private repository)
If there is anywhere to go as the definite source (pun intended, I'd be lying if I said it wasn't) to C++ code in UE4, it is the source code. If ever you have any questions in regards to how certian modules work or how something is implemented, this is the place to go to. I use it extensively when writing plugins and editor extensions. It is exceptionally helpful to look at the MessageBus, OnlineSubsystem, and Actor replication portions of the code when writing networked games.
When it came to writing network code and code for interactive objects in Unreal Engine 4, this was my go to place. Tom Looman has most of his tutorials in C++ and Blueprints. What this does is allow for a smooth transition if you are used to Blueprints and wish to move to C++.
Reddit seems to have a large crowd and there is relatively good activity in the subreddit. Most of the time I see a lot of beginners go there to ask questions. It is usually pretty helpful.
This person does a lot of stuff with UE4 and has a Plugin library for Blueprints. There are also a few other Plugins on the marketplace by this person. From forum posts to tutorials, transition guides, and wiki posts - Rama has a lot of content and most of it is in C++. Also, Rama seems to enjoy lots of color and hearts.
The Obscure
This is just a small collection of links to random things about Unreal Engine 4 and it's C++ components that nobody really talks about. Most of these links are one off a very specific. They are as follows:
Things start to look nicer the more you apply yourself
Well, that is about all I use when going in to take a look at C++ demos and examples in Unreal Engine 4. Obviously, this is not the extent of all the resources available for Unreal Engine 4 C++. If there is anything that you may know of that I missed and is usable by a wide range of people, feel free to comment. I hope for anyone who was looking for some help in C++ for Unreal Engine 4 that this offered as a good guidance of where to go.
After spending some time on vacation and on an epic honeymoon, I have finally had time to get back to continue my original Quest Framework series. But, first, let me interrupt and thank everyone out there for their support. This is by far the most popular content I have ever written and it brings me great joy that you support it and find it useful.
With all the time off, and the time back at my day job, I have not been able to fully complete the second part of my Quest Framework series. However, I do have an addition I would like to share that may be useful. This addition is a new class that generates random Objectives from a predefined list of objectives inside of a Quest.
Quest Framework Part 1.5: Random Objectives
Want your players to look this excited for your quests? Don't use this framework for evil, no randomly generated fetch quests allowed!
Following the format of the last post, I will layout the header file for you, then explain some of the variables. From there I will layout the definitions and explain all of the logic.
The Head
class QUESTGAME_API AQuestRandom : public AQuest
{
GENERATED_BODY()
public:
AQuestRandom();
virtual void BeginPlay() override;
protected:
UPROPERTY(EditDefaultsOnly, Category = "Quest")
TArray<TSubclassOf<AObjective>> PossibleObjectives;
UPROPERTY(EditDefaultsOnly, Category = "Quest", meta=(UIMin=1))
int32 MinObjectivesGenerated;
UPROPERTY(EditDefaultsOnly, Category = "Quest", meta=(UIMin=1))
int32 MaxObjectivesGenerated;
private:
/** Helper methods for validation and generation.
* ::GenerateRandomObjectives() could be made public
* and wrapped with UFUNCTION(BlueprintCallable, Category="Quest") to make it exposed to the rest of your game.
*/
void GenerateRandomObjectives();
bool IsValidConfiguration() const;
};
Pretty nifty huh? We just inherit from AQuest (defined in the original Part 1 post) and add a few configuration parameters that can be set in either an inherited class or Blueprint.
PossibleObjectives is the meat of this class. Just add AObjective subclasses to it in the derived Blueprint or subclass and whenever the AQuestRandom is spawned in game, the class will do all the work of adding some random Objectives.
MinObjectivesGenerated and MaxObjectivesGenerated are there to help add some constraints to the amount of randomly generated quests. In proper fashion, these numbers are just constraints on the random determination of the amount of random Objectives created. I heard people like randomness on top of their randomness so I threw it in just for fun.
Next, I will show you the source for this nifty class and explain the true meat of the randomization algorithm (which isn't too difficult at all).
The Source
#include "QuestRandom.h"
AQuestRandom::AQuestRandom() :
AQuest(),
MinObjectivesGenerated(AbsoluteMin),
MaxObjectivesGenerated(AbsoluteMin)
{
}
void AQuestRandom::BeginPlay()
{
if (IsValidConfiguration())
{
GenerateRandomObjectives();
}
//Must be called last as we need to fill the Objective subclass array first
Super::BeginPlay();
}
void AQuestRandom::GenerateRandomObjectives()
{
const bool bMakeOnlyOne = MinObjectivesGenerated == MaxObjectivesGenerated;
if (bMakeOnlyOne)
{
int32 RandomIndex = FMath::RandRange(0, PossibleObjectives.Num() - 1);
Objectives.Add(PossibleObjectives[RandomIndex]);
}
else
{
int32 RandomCount = FMath::RandRange(MinObjectivesGenerated, MaxObjectivesGenerated);
for (int32 i = (AbsoluteMin - 1); i < RandomCount; ++i)
{
int32 RandomIndex = FMath::RandRange(0, PossibleObjectives.Num() - 1);
/* Note: if you want only one type of quest to be active at a time,
* i.e. treat Objective types array as a set, use AddUnique
*/
Objectives.Add(PossibleObjectives[RandomIndex]);
}
}
}
bool AQuestRandom::IsValidConfiguration() const
{
return MinObjectivesGenerated <= MaxObjectivesGenerated && PossibleObjectives.Num() > 0;
}
Awesome right? We really only need one function to add randomly generated Objectives to our Quests! Huzzah! So, let us look immediately into the GenerateRandomObjectives function as it is the crux of our class.
First, if we have the same MinObjectivesGenerated and MaxObjectivesGenerated, we are going to short circuit and say the designer only wants to pick one random Objective for this Quest. It is also the default behavior due to the values set in the Constructor of the class.
If the designer does not go with this default behavior we will actually do some work.
So, if we really look at it, the algorithm is not that hard to implement. All we need is to grab a random number clamped to the values provided to us from MinObjectivesGenerated and MaxObjectivesGenerated. From there we just iterate as many times as the RandomCount has defined to create that many Objectives.
In both configurations we just grab a random number starting at 0 (the starting index of an array) and PossibleObjectives.Num() - 1 (we subtract one to ensure we are within the bounds of the array as index access is 0 based but the Num() starts at 1 - this is a general rule).
From there, the base class takes care of everything else for us.
The End
And there you have it. Random objective generation. So, hopefully you can add some more content and unique playthroughs of your games via random Objectives in your Quests.
Until next time!
Note - I will have an official part 2 for this series that will have subsections. I am currently prototyping with the idea of implementing quests as state machines and message publishers to decouple a lot of the quest implementation from your actual game-play code. On top of that I am going to implement it as a plugin with components so that you can port it over multiple games. Why? Because 'Quests', 'Objectives', and 'Missions' are really all the same thing and can be written generic enough that the core foundation of them work across all game types.
Lately, I have been working on a simple horror game in UE4 that has a very simple Objective system that drives the gameplay. After looking at the code, I realized it could serve as the basis of a framework for a generic questing system. Today I will share all of that code and explain each class as it pertains to the framework.
The following classes to get started on a simple quest framework would are AQuest and AObjective, using the UE4 naming conventions for classes. AObjective is metadata about the quest as well the actual worker when it comes to completing parts of a quest. AQuest is a container of objectives and does group management of objectives. Both classes are derived from AInfo as they are purely classes of information and do not need to have a transform or collision within the world.
Objectives
Since it is the foundation for a quest, I will first layout and explain AObjective. The header of AObjective goes as follows:
// Fill out your copyright notice in the Description page of Project Settings.
#pragma once
#include "GameFramework/Info.h"
#include "Objective.generated.h"
UCLASS()
class QUESTGAME_API AObjective : public AInfo
{
GENERATED_BODY()
public:
// Sets default values for this actor's properties
AObjective();
// Called when the game starts or when spawned
virtual void BeginPlay() override;
// Called every frame
virtual void Tick( float DeltaSeconds ) override;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "O" )
FText Description;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "O" )
FName ObjectiveName;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "O" )
bool MustBeCompletedToAdvance;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "O" )
int32 TotalProgressNeeded;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "O" )
int32 CurrentProgress;
UFUNCTION( BlueprintCallable, Category = "O" )
void Update( int32 Progress );
UFUNCTION( BlueprintCallable, Category = "O" )
virtual bool IsComplete( ) const;
UFUNCTION( BlueprintCallable, Category = "O" )
virtual float GetProgress( ) const;
};
Not that bad of a deal. The only responsibilities of an AObjective is to track the completion of the sub-portion of an AQuest and offer some idea of what the player must do.
The objective is tracked by the CurrentProgress and TotalProgressNeeded properties. Added by the supplied helper functions, Update, IsComplete, and GetProgress, we can get a reasonable amount of data about just this tiny portion of a quest. These functions give you all the functionality needed to start a questing framework for your UE4 game.
There is one boolean property that has not been mentioned: MustBeCompletedToAdvance. Depending on the use case, this could be used to ensure a sequential order in objectives or having required and optional objectives. I will implement it as the first in this tutorial. Only minor changes later on would be needed to use it as an indicator or optional or required quests. Or, you could just add a new property to support both.
There are two more properties that help us out with AObjective management: ObjectiveName and Description. ObjectiveName can be thought of as a unique identifier for the implemented AObjective. The ObjectiveName's purpose is for player feedback. For instance, the FText value could be (in simple string terms) "Get a rock". It is nothing specific to the game, it is only something to be used as a hint in either a UI or other visual element to let the player know that they need to do something in order to complete the objective.
Next, we can look at the small amount of code that is used to define AObjective.
// Fill out your copyright notice in the Description page of Project Settings.
#include "QuestGame.h"
#include "Objective.h"
// Sets default values
AObjective::AObjective( ) :
Description( ),
ObjectiveName( NAME_None ),
TotalProgressNeeded( 1 ),
CurrentProgress( 0 ),
MustBeCompletedToAdvance( true )
{
// 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;
}
// Called when the game starts or when spawned
void AObjective::BeginPlay()
{
Super::BeginPlay();
}
// Called every frame
void AObjective::Tick( float DeltaTime )
{
Super::Tick( DeltaTime );
}
void AObjective::Update( int32 Progress )
{
CurrentProgress += Progress;
}
bool AObjective::IsComplete( ) const
{
return CurrentProgress >= TotalProgressNeeded;
}
float AObjective::GetProgress( ) const
{
check( TotalProgressNeeded != 0 )
return (float)CurrentProgress / (float)TotalProgressNeeded;
}
Again, you will be hard pressed to say "that is a lot of code". Indeed, the most complex code is the division in the GetProgress function.
Wait, why do we call / override BeginPlay or Tick? Well, that is an extreme implementation detail. For instance, what if, while an AObjective is active, you want to tick a countdown for a time trialed AObjective.
For BeingPlay we could implement various other details such as activating certain items in the world, spawning enemies, and so on and so forth. You are only limited by your code skills and imagination.
Right, so how do we manage all of these objectives and make sure only relevant AObjectives are available? Well, we implement an AQuest class in which it acts as an AObjective manager.
Quests
Here is the declaration of an AQuest to get you started:
// Fill out your copyright notice in the Description page of Project Settings.
#pragma once
#include "GameFramework/Info.h"
#include "Quest.generated.h"
UCLASS()
class QUESTGAME_API AQuest : public AInfo
{
GENERATED_BODY()
public:
// Sets default values for this actor's properties
AQuest();
// Called when the game starts or when spawned
virtual void BeginPlay() override;
// Called every frame
virtual void Tick( float DeltaSeconds ) override;
public:
UPROPERTY( EditDefaultsOnly, BlueprintReadWrite, Category = "Q" )
TArray<class AObjective*> CurrentObjectives;
UPROPERTY( EditDefaultsOnly, BlueprintReadWrite, Category = "Q" )
TArray<TSubclassOf<AObjective>> Objectives;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "Q" )
USoundCue* QuestStartSoundCue;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "Q" )
FName QuestName;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "Q" )
FText QuestStartDescription;
UPROPERTY( EditDefaultsOnly, BlueprintReadOnly, Category = "Q" )
FText QuestEndDescription;
UFUNCTION( BlueprintCallable, Category = "Q" )
bool IsQuestComplete( ) const;
UFUNCTION( BlueprintCallable, Category = "Q" )
bool CanUpdate( FName Objective );
UFUNCTION( BlueprintCallable, Category = "Q" )
void Update( FName Objective, int32 Progress );
UFUNCTION( BlueprintCallable, Category = "Q" )
bool TryUpdate( FName Objective, int32 Progress );
UFUNCTION( BlueprintCallable, Category = "Q" )
float QuestCompletion( ) const;
};
Not much bigger that the AObjective class is it? This is because all AQuest does is wrap around a collection of AObjective's and provides some utility functions to help manage them.
The Objectives property is a simple way to configure an AQuest's objectives via the Blueprints Editor. And the CurrentObjectives is a collection of all live AObjective's that are configured for the given AQuest.
There are several user friendly properties such as a USoundCue, FName, and FText types that help give audio visual feedback to the player. For instance, when a player starts a quest, a nice sound plays - like a chime - and the QuestStartDescription text is written to the player's HUD and a journal implementation. Then, when a player completes a quest, a get is called for the QuestEndDescription property and writes it to a journal implementation. But those are all specific implementation details related to your game and is limited only by coding skills and imagination.
All of the functions for AQuest are wrappers to operate on collections of AObjectives to update and query for completion. All AObjectives in the AQuest are referenced and found by FName property types. This allows for updating different instances of AObjectives that are essentially the same, but differ at the data level. It also allows the removal of managing pointers. As another argument, it decouples knowledge of what an AObjective object is from other classes, so completing quests via other class implementations only requires the knowledge of an AQuest - or the container for the AQuest - object and default types supplied by the engine such as int32 and FName.
How does this all work, well, just like before, here is the definition of AQuest:
// Fill out your copyright notice in the Description page of Project Settings.
#include "QuestGame.h"
#include "Objective.h"
#include "Quest.h"
AQuest::AQuest() :
QuestName( NAME_None ),
CurrentObjectives( ),
QuestStartDescription( ),
QuestEndDescription( )
{
}
void AQuest::BeginPlay()
{
Super::BeginPlay();
UWorld* World = GetWorld();
if ( World )
{
for ( auto Objective : Objectives )
{
CurrentObjectives.Add(World->SpawnActor(Objective));
}
}
}
// Called every frame
void AQuest::Tick( float DeltaTime )
{
Super::Tick( DeltaTime );
}
bool AQuest::IsQuestComplete() const
{
bool result = true;
for ( auto Objective : CurrentObjectives )
{
result &= Objective->IsComplete();
}
return result;
}
bool AQuest::CanUpdate( FName Objective )
{
bool PreviousIsComplete = true;
for ( auto Obj : CurrentObjectives )
{
if ( PreviousIsComplete )
{
if ( Objective == Obj->ObjectiveName )
return true;
else
PreviousIsComplete = Obj->IsComplete() |
!Obj->MustBeCompletedToAdvance;
}
else
{
return false;
}
}
return true;
}
void AQuest::Update( FName Objective, int32 Progress )
{
for ( auto Obj : CurrentObjectives )
{
if ( Obj->ObjectiveName == Objective )
{
Obj->Update( Progress );
return;
}
}
}
bool AQuest::TryUpdate( FName Objective, int32 Progress )
{
bool result = CanUpdate( Objective );
if ( result )
{
Update( Objective, Progress );
}
return result;
}
float AQuest::QuestCompletion( ) const
{
int32 NumObjectives = CurrentObjectives.Num( );
if( NumObjectives == 0 ) return 1.0f;
float AggregateCompletion = 0.0f;
for( auto Objective : CurrentObjectives )
{
AggregateCompletion += Objective->GetProgress( );
}
return AggregateCompletion / (float)NumObjectives;
}
Probably the most complex code out of all of this is the CanUpdate method. It checks to see, sequentially (so order of AObjective configuration matters), if an AObjective is completed and if it is required to complete any other AObjectives after it. This is where the bitwise OR comes in. So basicly, we cannot advance to the requested AObjective if any of the previous AObjectives are not complete and are set to MustBeCompletedToAdvance (or as the listeral code says you CAN advance if the previous AObjective IS complete OR it does not required to be completed in order to advance).
The IsComplete function is just and aggregate check to see if all AObjectives are complete - defining a completed AQuest. The QuestCompletion method is a simple averaging of all AObjective completion percentages.
Also, the AQuest class has a simple function to wrap up the CanUpdate and Update calls into one neat little function called TryUpdate. This allows a check for the ability to update before applying the requested progress update and returns an indicator of success or failure. This is useful when code outside of AQuest wants to attempt AObjective updates without caring about much else.
Finally, for the same reason of AObjective's BeginPlay and Tick functions, AQuest also overrides these to allow your coding skills and imagination to fly.
Hopefully, this was a good introduction into the groundwork of designing a questing framework for your Unreal Engine 4 game. If you did enjoy it, comment or like it. If there is enough interest I will continue on-wards with Part II: Nesting Quests and Objectives. That part will be a tutorial just like this, with full code samples, explaining how to structure the framework to nest multiple AObjectives into an AObjective to create a structure of sub-objectives as well as the same pattern applied to AQuest to supply sub-quests.
This may seem like a strange post. But it is a reflection on the past five years that I feel sharing with anyone can help them think about what they are doing in regards to their profession, as well as where they plan on going. Be warned though: Get settled, get some hot cocoa, and enjoy the read. Perhaps it pertains to you in more ways than one, and it does not necessarily have to be about video games or your career.
So, let me continue on and start with the strange, seemingly unrelated topic first: StarCraft 2, a video game.
With StarCraft 2: Legacy of the Void being released this past month, I have spent a lot of time reflecting on the past five years in regards to my past pursuits in relation to video games. These reflections are on how I handle something that I enjoy, how I handle failure, and ultimately, what I have learned from the past five years in regards to my pursuit in the video game industry.
Let us start at the beginning. That is, the release of StarCraft 2: Wings of Liberty. That was about five years ago. A lot was going on for me at that time: I had graduated high school, started my education at DeVry University, and maintaining a wonderful relationship with my now fiancé. StarCraft 2 had a major impact on my life and may have made me who I am today. I say this for three reasons: it happened at a critical time in my life, it helped define my work ethics, and it allowed me have some introspection.
I remember the day I first bought StarCraft 2. I was at a local Target with my fiancé. After some debate I bought it. I then proceeded to spend the first three nights playing through the campaign. I then logged in to online multiplayer (the real reason the game is so popular) for the first time. I began to become assimilated into the SC2 ecosystem within the course of a week.
After a few losses and one win I was placed in Bronze League – one of the lowest leagues to be put in. I played a few more games which led to me being obsessed with winning. This was odd for my personality as I played sports my whole life and didn't care about winning or losing as much as the other players. This obsession led me to spend hours watching SC2 shout-casts by HD and Husky (don't know who those guys are? Me either - anymore) and improving my SC2 skills with tips from Day9 (quite the fellow). The hours spent doing this usually crept into the wee hours of the morning. Sometimes, it would be dawn before I decided to go to bed.
With all that dedication, I started to improve.
With my improvements I began winning. I was consumed with this rush of excitement, the feeling of glory, the joy in crushing my opponents. I was winning games using my god-like macro abilities and my sick Protoss builds. I was rolling over the enemies. Within weeks I climbed the ladder from Bronze league, to Silver, to Gold, then to Platinum league. I was an SC2 super star in my head. (As a note, the Master and Grand Master leagues did not exist at that time).
A few months in I started to pay attention to the pros - NaniWa, HuK, and MC. I would download a few of the replays they would post and study them. I would watch the tournament VoDs – Videos on Demand. I would also do practice runs in game to perfect my build timings. Indeed, I was going all in.
After some time I progressed to Diamond League. The excitement! The joy! I WAS A GOD! ... I may get a little carried away with my statements but it is hard to share the complete, full body experience that came with joining the upper echelon of SC2 players. Worse still, I became a Rank One Diamond in my division for a good period of time. My ego began to tear down the walls of my bedroom around me. This is where the decline began.
The game started to consume my life, it occupied my every thought. I had transitioned to three jobs at the time and all I talked to my co-workers about was StarCraft 2. My lovely fiancé (then girlfriend) listened to me talk her ear off about every aspect of the game - even watched a few tournaments with me (bless her heart). I was a Protoss... that is how I defined myself. I was 19 at the time.
My mind started to become the barrier. I would get cocky trying out for SC2 clubs, I was disheartened by the lack of SC2 community in the Midwest region near me, and I felt alone - nobody I knew played SC2 as well as I did to practice with. It was a void that could not be filled. I began to feel lonely. For some reason, I just lost interest. I started to feel like a failure, there was no rhyme or reason to it, it just sort of happened.
I quit StarCraft 2 before Heart of the Swarm (the second part of the three part game) was even launched.
I moved onto League of Legends, another competitive based game, this time with teams of 5.
Talk about a vicious cycle. If you reread the entire section about StarCraft 2 and replace "SC2" with "LoL" you get the picture. I fell into that trap as well.
Looking back, playing video games consumed me when it came to competition. I enjoy playing the ‘regular’ games like the entire Witcher series by CD Projekt Red and the Total War series by Creative Assembly. But the competitive games affected me differently than those. They started to feel like a job, a climb to the top. I would get frustrated and feel inadequate and I would blame everything around me for that feeling – all from a silly little games.
With that being said, we will move onto my projects I worked on in parallel with this SC2 craze.
I went to DeVry University for a degree in Game and Simulation Programming. It was all fun and games for the first two years as with any College / University. That is why I had all that time to play SC2. However, junior year began to challenge me – which I enjoyed. I was learning project development cycles, advanced C++, networking, game design, and game engine architecture. I had also joined a few people on some professional projects during my time at DeVry. And this is where I would like to lead into. (If you really want details on my projects at DeVry, read all of my 2014 posts.)
a simple FPS cam (above) and a trailer for my senior project (below)
I had worked on several projects with outside entities while at DeVry. These projects - in no particular order - were named as follows: Super Ubie Land, Undead Fred: A Grave Tale, Invisible Battles: The Quest for Hope, War for Orion, Soccer Legend Online, and Bring out Your Dead Trading Card Game.
I was prototyping Super Ubie Land for Notion Games, LLC on the Game Maker engine. Just like when I was obsessed with SC2, I threw myself into it. I had a working prototype up and running for the developer in Game Maker. I even started to prototype another game for him. Turns out that prototypes and proofs of concept are not permanent nor guarantee a job. I spent a summer on that project and the company decided to go with a different engine that they did not need my skills for. Which I am okay with – these things happen. Was I heartbroken? Yes. To be 19 and have a name on a legitimate game would have been awesome. However, I could not help myself from blaming them and feeling like a failure for some time.
Herald in my 20s. I was looking for a project to work on. So I posted on the Game Maker community forums as a programmer looking for work. I was picked up immediately by a wide-eyed hobby developer. The project sounded fun; I was up for anything, optimistic, just getting off the high of a really fun school project learning DirectX 9 (now ancient). I accepted.
I must say, it was a team filled with talent. If I met that same team today, I would still have the same optimistic feeling. We had a talented artist, a practical game designer, talented programmers (yes, some self-flattery there), an excellent sound artist, and a game demo ready in three months. There were talks of interviewing with some small time indie game magazines. We were sailing along nicely.
test screenshot for Undead Fred: A Grave Tale
One day – it just stopped. It was strange. We went from daily emails to weekly. Skype never rang for me anymore. Eventually – I was working solo on a project. I was disheartened, frustrated. I must admit I was quite angry. I uploaded it to the Steam Community and said “ah ‘phooie with it.”
From that point on I promised to focus on school for I had, once again, completely devoted myself to something just to be tossed aside like used underwear at the end of the day. Worse yet, nobody else noticed nor cared. I felt cheated of opportunity, untalented in my skills, and completely distraught.
Fast forward a few months. I broke that oath. It was mostly out of desperation for an internship before graduation, because internships are of the utmost importance. You are doomed without one no matter the industry.
I cannot remember how I got there, but I came into contact with the owner of an indie game studio in downtown Milwaukee, WI. After some research I started to believe in the project and I worked on Bring out Your Dead TCG for Ever Fire Studios. It was a green project comprised of hobby developers and students alike. All resources were paid for by the owner. For all intents and purposes – it was an unpaid internship, which is not that uncommon.
The project was approached using the Agile Project Management methodology. This was a breath of fresh air because any project prior there was no project management. Which was fine for prototypes, but not for a complete project. We were getting along fine and having fun. The internship required seven hours of work a week and the attendance to a meeting once a week. This helped me regulate my time spent on it unlike the previous projects for Super Ubie Land and Undead Fred: A Grave Tale. Even more so, it was a far cry from my StarCraft 2 days – where I managed my time horrendously.
However, it was not meant to be. Owning two companies cost money and the priorities were on the other company – Forever Interactive – and their exciting project Visions of Zosimos. I do not blame them, this project was just getting started and VoZ had been in development for years – and a great project at that from playing it a few times. But, I was – again – heartbroken.
(above) visions of zosimos trailer
That brings my total time dedicated to projects to about two years. My total number of projects I worked on to three. The total number of completely heart-wrenching, motivation killing, talent squelching failures to three as well. I was on a roll and a nice trip down failure lane.
It was starting to feel like StarCraft 2 all over again. I would start, get excited, be optimistic, make great progress, only to see things halt and die on me. Sometimes, I don’t even know why it went south other than that it did.
To complete the overarching theme, I graduated school and worked on three more projects after that. These ones were shorter term and not as important to me but I will write details just to cover all my bases.
Soccer Legend Online wanted to hire me on a contract basis. They wanted some AI programmed in with networking within three weeks for a small payout. I was arrogant and thought I could do anything, a motto I seem to have going for me as that is how I felt with StarCraft 2, the reality did not match my internal expectations. Needless to say there was fallout in communication and I did not deliver the expected product. Now, they are Greenlit, so kudos to them.
Then the game Invisible Battles: The Quest for Hope. If ever there was a time that I could relate myself to being a wormhole of confusion, it was then. I had no idea what was going on with this project. All I knew was that I was programming a game and I was getting paid some decent money for it. I had no idea where the artists were at, but I never had assets to use from them. Sound designers were non-existent. The game designer, well, I wasn’t sure who was the game designer or just a person voicing their opinion.
(above) Invisible Battles: The Quest for Hope combat, morphing, and item pickup prototype
I made great progress on that project. I was excited to work on it as it was with the recently released Unreal Engine 4. Again, I threw everything I had into it, all my free time, all my thoughts, and all my efforts.
Then the developer ran out of money. Again, I had the overwhelming feeling of failure and complete loss of worth.
This brings me to my last endeavor with an external team: War for Orion. I have no one to blame but myself on this one. I was excited for a brief moment and I was working with that team in exchange for a trade of skills. I program for them, they make art for me. We both meet halfway. I received half of the excellent art assets (and I didn’t even deserve that much) and I worked on the game halfheartedly. This has nothing to do with the project in itself – it is a great concept and I try to follow the team.
(above) War for Orion prototype video
What happened was that I was beginning to become bitter. I started on this project expecting the same thing to happen as had happened before – I start, get excited, move fast, devote my time, and then find out it was all a huge waste. My own pessimism got to me and it gave off an aura to the team.
I was asked to leave – on friendly terms – after a few months.
Again – heart broken. But this time, it happened because I expected it to happen. I conjured the event with my own mind. This is a direct relation to what I did with StarCraft 2 and League of Legends. I brought myself down in the end.
This is the point of the story where everything ties in. You see, I followed the same path when it came to StarCraft 2 and Game Development. I let failure get to me and control me at this point. It didn’t lead me anywhere useful… or so I thought.
Reflection is a great thing. It allows you to look into yourself and learn something new. What have I learned? That commitment to something does not mean going full throttle all in to get where you want to be. Commitment means taking the time to plan for the long haul and balance the work that needs to be done with the rest of your life.
Constantly, I hear about these developers and pro gamers that spend 70 or 80 plus hours a week on their goals. That doesn’t help anybody but your manager or yourself getting the illusion that you are doing something worthwhile. Damaging your health, even if it is for something you love, is not worth it – ever.
I have learned a lot in the past five years, and these are just the things I have learned reflecting on something as simple as my enjoyment of a video game and my pursuits of working in the game industry. Better yet, all of these perceived failures were anything but.
I have learned that there is no such thing as failure – only the opportunity to learn and grow. So, the next time something doesn’t work out, or you lose focus and stop a great project. Sit back, write it down if you have to, and take a look at the why. If you are writing a lot of whys about something other than yourself, stop, you are not ready for this.
Reflection takes self-awareness and introspection. You need to know your strengths and weaknesses – what makes you tick. Better yet, you need to find out your flaws and work with them, or improve them. My flaws were obvious in the above stories: I did not balance my life well, I allowed failure to overwhelm me, I used to blame outside entities for these failures, and I allowed myself to be negatively affected by these events.
I have learned over the past five years. I have learned from StarCraft 2 that I can easily become obsessed and unbalanced when it comes to achieving my dreams. I have learned from my past projects that management is a key factor in success. I have also learned from both that there are things more important than making video games, which is just a career after all.
Finally, to prove that there is no such word as failure, I sit every day at my day job, programming – a job that I love. I would not be there if I had not gone on wild adventures in regards to video games and game development. From each of my endeavors I learned a little more about myself. I have tweaked my bugs, and produced a better self. I am happy and I will continue to do what I love outside of work – like play video games and make them, and – most importantly – spend time with those I love. The only difference now than five years ago is that I will no longer consider anything a failure; I will have a healthy balance in my life; and I will only work on what I enjoy in life because life is too short to be miserable.
Now, I challenge you: sit down, reflect on all perceived failures in the past five years. Find reasons why you failed due to yourself. Then reflect and learn that they were not failures, but opportunities to grow.
For those of you interested in the projects (some now dead):
Today I am going to talk about using Components for your game objects.
Wow, that one came out of nowhere, wasn't I just talking about my new alpha version game and the design contest I have going for it at adventuregamequest.azurewebsites.net/#/contest? Yes, but let us take a break from Text-RPG games and focus on some exciting 3D Games.
As I have mentioned before, I am currently working on two projects. Both of these projects are a 3rd person adventure/action game of sorts. From various phases of the design process, before implementing any code, I have come to the conclusion that components are great. In fact, I would venture to say its the next best thing to inheritance.
To keep this in scope, I am not talking about the Component-Entity design pattern per say, rather, the component systems implemented in both Unreal Engine 4 and Unity 4. Not coincidentally, these are two of the largest game engines I can think of that are still of relevance and readily available to the public. Both of these engines incorporate a component model, where you have a base object within the world that has objects attached to them.
In Unity these are the MonoBehaviour scripts. They can be attached to any GameObject within the engine and readily used. In Unreal Engine 4, these are ActorComponents that can be attached to Actors.
Why is this such a good system?
I have several answers to that question. These answers are as follows: modularity, prototyping, less limitations.
The first point is the best: modular components make life awesome. I would venture to say that, for games, components are the next best thing after object oriented programming languages/design. By allowing a designer/programmer to take an unspecified object with no real value other than existing as an entity - GameObject in Unity and Actor in Unreal - on can put together pieces to design a complex system or entity within the game. The best part is that traits of the entity can be replicated and attached to other entities that are not necessarily an instance of that entity. For example, one of the problems I had with a game I was making in UE4 was as follows:
An Actor has several different methods to attack. They can have a weapon, or use an unarmed attack. This means the Actor (we will refer it to creature from now on) will need to have some way to cause damage without a weapon. Simple enough, sounds like a simple property named damage. And, again, simply, the weapon now needs a property called damage. Nice, simple, easy to the point, use some logic to see if the creature has a weapon, if not, use it's damage. But wait, now we want ranged weapons. Well, a ranged weapon is a weapon, so we will just inherit from weapon, also inheriting the damage property. But a ranged weapon doesn't do damage, it shoots things that cause damage. Well, we could give that projectile a damage property too, sounds good, and ignore the ranged weapon's damage property when the projectile hit an enemy. Another route would be to have a pointer to the firing weapon, and if the projectile hits anything, use the ranged weapons damage to cause damage. Nice, that is all wired up now. So for each actor that has this damage property, add a callback event to apply damage on the other Actor hit by the creature, the creature's weapon, or the creature's ranged weapon's projectile. Awesome done. But wait, now we want spells, okay, just copy all logic from the other four classes...
Clearly, you can see where this is going. And it is a long an miserable road to travel. This is what your (prototyped) files would begin to look like:
class Creature : AActor { public: float Damage; Weapon* MyWeapon; float GetDamage() { if(MyWeapon == NULL) return this->Damage; else return MyWeapon->Damage; } } class Weapon : AActor { public: float Damage; } //Notice the circular dependencies in this awful design not using components class RangedWeapon : Weapon { public: Projectile* WhatIShoot; } class Projectile : Actor //You could even have projectile inherit from weapon if you would like... but is that really any better? { public: float GetDamage() { return WhatShotMe->Damage; } RangedWeapon* WhatShotMe; }
Sure, you could argue, "Well, why not have a DamageActor that has all these stats?" As an exercise to the reader, I will let you argue that point.
So here is the alternative:
Make an ActorComponent called DamageComponent, add a damage property (and any other awesome damage like properties like critical hit, critical chance, critical multiplier, etc.) and have a get method that calculates damage. Slap that component onto any actor you want and implement whatever event that causes damage (overlap, hit, fall, etc.) Done, Need spells? Awesome, create a spell actor and slap that puppy on there.
Seems pretty obvious why the whole modularity thing comes in handy now, doesn't it? This also helps create a nice, distinct, seperation of concerns when it comes to your software. Rendering components render, collision components collide, gameplay components do game stuff, and so on and so forth.
Next is how easy this modularity makes prototyping. Let us go back to the first example of making attack power/damage where we created a file for each entity that could possibly cause damage. Better, yet, let us take that a step further and say we used some good OOP and have a DamageActor inherited from Actor that all of these classes inherit from. Now, we just add all the extra properties we need for this. Seems like a good solution.
Well, the Game Designer came in and changed something. The player can now transform into any one of the enemy AI you see before you. You already created all of these awesome combat mechanics using inheritance, and you created the player with a controller, as well as some stats of his own (since this is a stealth game all of a sudden, the player is not a DamageActor because, unlike every other protagonist in the world of games, he does not kill people). So, do we turn this docile, sneaky player into a Damage Actor? Do we just create and inherited class for each possible AI in the game into a PlayerXXXActor and have a bunch of unneeded data implemented?
No. That is bad.
This is a tough one, but my approach would be to find a reference to the base class and copy over the components into the component array, exclude the ones that are type or super type of DamageComponent. One line of code, done. Call it a day, and no crunch time.
Who loves components, modularity, and prototyping? We do.
Finally, this brings to the point of less limitations. In the world of programming, refactoring is a way of life. It can be fun, it can be tedious, but it is also the result of lots of prototyping. With components we can swap in and out common and uncommon responsibilities between common and uncommon entities within the game. Let us, for instance look at a Unity example.
You have a multi player game and there is a single player mode. Do you want to write a script called AIScript where you have if statements for every single action? For instance:
public class AIScript : MonoBehaviour { private bool multiplayer; private ClientRunner client; OnUpdate() { if(multiplayer && client != null) { client.Send("Position", new object[]{position.x, position.y, position.z}); } else { //Do nothing, so we have a stupid if/else statement here (or we could hide it with out putting the else, but does that really make you feel good inside?) } if(multiplayer && client != null) { //Receive a whole slew of data to update } else { //Um.... do nothing, perhaps go out into the local game world and get that //same data } //A plague of if/else blocks if(multiplayer && client != null) { } else { } if(multiplayer && client != null) { } else { } if(multiplayer && client != null) { } else { } if(multiplayer && client != null) { } else { } } }
Looks okay. I mean, if the AI is on the network it replicates, if not it uses the game world. Well, that is a lot of conditional branching in an update loop - kind of sucks for performance. And now the AI is responsible for its own Client/Server or Local Gameplay management. Might as well as throw ALL information that requires that knowledge into those blocks of data, or do a lot more copying and pasting.
I have your solution from this awful life: Have a CommonAI, NetworkAI, and LocalAI, have an AI manager detect gamemode and when creating AI, attach the appropiate script. No need to go in and out of if/else blocks to change little things, you can still use inheritance by having common AI routines go in Common AI and have the Network* or Local* inherit from that. Not bad, components win the day again.
In the end I would like to say that I love the component systems used in modern game engines. I know this may seem obvious, but some schools teach the importance of OOP in schools to the point where one can focus on only using OOP in game engines and gameplay classes. When there is a better solution out there, it should be taught, and I hope this helped you to see the light or help solve a difficult case of multi-inheritance messes.
For the past few months I have been hidden under a rock, not posting anything. Why? Well, life moves fast and I was keeping up with it. I have taken on one independent project (near completion), two after hours projects, and a full time job. I found myself wanting for time but also enjoying what I am doing.
First is my current independent project. I have recently finished the core features of a web based text adventure game. Why? As any programmer/engineer/mad-scientist will inform you: "Because I can." And I certainly can, did, and will continue with. Quite frankly, the project just needs some added game-play features and a hosting platform. The technologies used in this project were:
.NET 4.x Framework
ASP.NET
Entity Framework
AngularJS
Identity Framework
Twitter Bootstrap
What was the biggest motivation behind this project? I could say it was a yearning for the classic games, or a drive to make a deep story driven adventure. Quite frankly though, it was to learn various web technologies. It has always been my weakest skill in the world of programming. However, in this world, that would leave me without a job (games or not, the web is growing and so are the demands for positions to create it).
The other two projects that I am working on are all done in Unreal Engine 4, the engine I raved about so few months ago. I have pretty much stopped all production in Unity as I just didn't want to use it. I prefer C++ when I want to, and uber-fast prototyping in Blueprints when I need to. Plus I find the tool sets in UE4 significantly more robust and user-friendly. It feels wrong saying user-friendly, but it is true and it makes the projects move along smoother and at a more rapid pace than I have ever seen.
I am not sure as to whether I can talk in detail about these final two projects, but I will definitely give many updates if they turn out to go farther and allow me to share screenshots/videos with everyone.
Until next time! Keep an eye out on this blog as I will be posting a link to my web based game very soon once I get a hosting platform up and running.
Today I started a new project. The project is a simple Pinball game made in Unreal Engine 4 using C++. As it stands right now, I have a framework already up and running for the project and will soon go to implementing special features. After that, I will have need for my own sounds, meshes, and textures. When that is done I will then make a simple UI for the main menu of the game, again using C++. Here is a short video on what I finished today:
Last night I had the time to work in the Unreal Engine 4, as I have finished a lot of my Senior Project. I do have a few comments about it in regards to the C++ Programming. They can all be summed up in one word though - Smooth.
Indeed, the C++ programming is a smooth process once you understand the patterns and design of the system itself. Knowing C++ definitely helps too. For instance, yesterday I began implemented my own Inventory system derived from the one found on the Unreal Wiki. It when all as planned with only a minor hick-up in having no support for Unions as a UPROPERTY (So it can be seen and edited in the Visual Scripting Engine - Blueprints).
The ability to program in features with the ease of Unity and its managed scripting engine and the performance of C++ makes me very attracted to using this new engine. Having access to the source code also helps with understanding the core components. I also find that the unity website, wiki, and forums have a wealth of knowledge to start with. Finally, the free games and demos I can download from Epic aid in understanding the system even more.
I am sure I have mentioned before I was never a fan of UDK, so I was a little hesitant to begin with UE4; however, I am glad to be spending the measily $20.00 for this awesome engine and I plan to keep on using it. There are also some nice community works in progress underway such as an Adventure Kit.
Oh, and don't even get me started on how EASY it is to do multiplayer games in UE4.
Decided to share my thoughts and tell you that getting Unreal Engine 4 is worth it!
Yesterday I purchased a subscription license for Unreal Engine 4. I have to say, it is great that they offer the full source code as well as the ability to build the entire engine. On top of that, after only two hours of playing around in it (including checking out, downloading, and compiling) I am in love.
I have used Unity 4 for the better part of two years now. Mostly was because of the ease of use of the scripting languages in C# and (not-really)JavaScript. This simplicity beat out the UE3 scripting language. But now, it is a whole new game.
UE4 allows for building new game objects directly in the C++ source code. This is amazing! Especially when considering that it links it to their Blueprint Visual Scripting engine. I think I will find myself working mostly in UE4 from now on - while I still get the hang of it.
With that being said, I will still be posting about Starbound Aces starting next week as it will be my last 8 weeks of class before I get my B.S. in Game and Simulation Programming.
Here is a link to Epic Game's Unreal Engine 4 - its worth it! Check it out!
https://www.unrealengine.com/
It has been a while since I have posted. This is mostly due to the fact that I am on break before my last class starts. This class is the second half to my Senior Project and is the second sprint towards a Beta for Starbound Aces.
I have decided not to work on Starbound Aces during the break. This is unusual compared to my past patterns in which I would religiously throw myself at my code to fix all bugs that manifested themselves in the Alpha development. I have decided against this because burnout is a huge mood killer.
On another note I plan on purchasing a license for Unreal Engine 4 and taking the C++ for a spin since that is the language of my choice. I also have been working on some Unity prototypes that I though were neat. Within the week I will be able to show some prototypes here as well as explain them. In regards to UE4, we will see if I have anything to post.
In the meantime, enjoy your game programming and check back soon!
