Transitioning to Native

Transitioning to Native
Robbie Litchfield
Software Engineer
Grinding Gear Games

Motivation
● Engines have their limits.
● C/C++ usage in indie middleware.
● Programmer control over tech.
● Pushing target platform performance.

Agenda
● Jumping into Native Development.
● Development without an Editor.
● Memory Management without GC.

Jumping into Native
Development

Jumping into Native Development
“A Curiously Repeating Story”
By Robbie Litchfield

Day 1:
● Find C++ materials.
● Open StackOverflow.
● Write some code.

Week 1:
● Start on game idea.
● Powering through problems.
● Diligent StackOverflow use.
● Perceived leaps and bounds.

Month 1:
● StackOverflow… :(
● Errors are alien.
● Progress is dwindling.
● C++ love affair is over.

Many moons later:
● Minimal to no progress.
● Project seems ill-defined.
● Longing thoughts of Unity.
● Project failure.

“Going Native” for the wrong reasons.

● Understand your own requirements.
● Make pragmatic risk/benefit analyses.
● Explore novel solutions with existing tools.
● Do the above *before* cutting code.

Attempting too much, too soon, too fast.

● Start out on small and simple pilot projects.
● Take time for learning, analysis and design.
● Extend project time estimates, double them.

Confusing training with skill.

● “Yeah, I’m sure I can pick up C++ quickly.”
● Use introspection, plan around skillsets.
● Push through, skills come from experience.
● Invest in fostering talent in your team.

Your mileage may vary.

Development without an Editor
The bad old days.

● Games were largely hard coded.
● Tools, if any, were primitive.
● Games typically had miniscule content.

Today.

● Games are larger and more complex.
● Demand for high content games.
● The standard for quality keeps on rising.
● Game sizes growing faster than teams.

Programmer time is a large bottleneck.
class Monster : GameObject, MRenderable
{
Monster(Health_t health);
virtual Attack_t GetAttack( ) = 0;
Health_t m_Health;
};

class Dragon : Monster
{
Dragon( ) : Monster( 99 ) {
}
virtual void GetAttack( ) override {
return “The dragon’s fire results in a
swift death.”; }
};

1. Designer asks for trivial change in Dragon.h
2. Modify Dragon.h
3. Recompile and check-in changes.
4. Reply to designer.

Data Driven Development

● Empower those who make the decisions.
● Minimise iteration time with powerful tools.
● Data requirements drive software design.

Data Driven Game Objects
{
“Name” : “DemonDragon”,
“Prototype” : “Dragon”,
“Attacks” : [ “SummonLesserDragons”,
“CharmMinion”, “MightyClaw”, “FireBreath” ]
“MinHealth” : “1500”
}

Game ObjectMRenderableMControllable MAnimatable
Actor
Monster

Monster
Demon
Dragon
“Attacks”
“MinHealth”“Zone”
Monster(Json &json) {
m_Health = json[“MinHealth”];
m_Attacks = json[“Attacks”];
m_Zone = json[“Zone”];
}

Monster
Goblin ElfDragon Human
TrollBlackDragon HighElf Orc
Demon
Dragon

● Works well if types are similar.
● Can’t express complex hierarchies.
● Still requires programmer time.
● We can do better...

Game Object PrototypeMonster
Script
Render

class GameObject
{
public:
GameObject( Id_t id );
Id_t m_Id;
Id_t m_Prototype;
IntrusiveList<Component> m_Components;
};

MonsterDemon
Dragon
“Attacks”
“MinHealth”
“Zone”
Actor
GameObject
GameObject* Create(Json &json) {
for(auto& p : json) {
// Select component for property
// Set component value
}
}

● Added runtime cost.
● Compiler can’t help with type checking.
● Can trivially create new types without code.
● Programmer time for new concepts.

● Materials
● Scripts
● User Displayed Strings
● So much more...

● Tools take time to develop and maintain.
● Not everything needs to be data driven.
● Text files can often be enough.
● Be prepared to refactor toolchain.

GC Memory Management
void CSharp( )
{
var val = new T(“NZGDA”);
/** ... **/
val = null; /* Optional */
}
Memory Management without GC

● Convenient.
● Non-deterministic cleanup.
● Non-deterministic performance.
● C/C++ GC support is a kludge.

Manual Memory Management
Stack Heap

void Func( ) {
int val = 5;
/** ... **/
}

void Func( ) {
auto *ptr = new T(“NZGDC15”);
/** ... **/
delete ptr;
}

T* ptr;
● Lifetime?
● Ownership?
● Cleanup?
● Safety?

“Resource Acquisition Is Initialization”

R.A.I.I.
● Resource is bound to an object’s lifetime.
● Constructor performs resource acquisition.
● Destructor performs resource destruction.

R.A.I.I. Smart Pointers
class scoped_ptr {
scoped_ptr ( int* p ) { m_ptr = p; }
~scoped_ptr ( ) { delete m_ptr; }
int* m_ptr;
/** ... **/
};

void Function( )
{
scoped_ptr ptr( new int );
// Memory at ptr destroyed here
}

● std::unique_ptr<T>
● std::shared_ptr<T>
● std::weak_ptr<T>

● Superior to manual memory management.
● Deterministic cleanup and performance.
● Useful for any system resource.
● Learn this pattern, it’s everywhere.

C/C++ Dynamic Memory
void Func( ) {
auto *ptr = new T(“NZGDC15”);
/** ... **/
delete ptr;
}

● Global State.
● Slow, Heavy Subsystem.
● Virtual Memory Limitations.
● Heap Fragmentation.

Heap Fragmentation

Allocators

Stack Alloc Alloc Alloc Alloc
Stack Heap

● Give up some convenience.
● Faster than the runtime heap.
● Fragmentation can be eliminated.
● Games only need a couple patterns...

Default Allocator
malloc() free()

● Simple adaptor around runtime heap.
● Helps with bootstrapping allocator usage.
● Avoid use in production builds.

Stack Allocator
Alloc Free
Alloc FreeAlloc

● Games already behave like a stack.
● Trivial to implement.
● Fragmentation proof.
● Strong ordering requirements.

Object Pool Allocator
Free Free Free Free Free
Alloc Free Alloc Free Free

● Suitable for game simulation data.
● Subtle implementation issues.
● Fragmentation proof.
● No ordering requirements.

● Games can be made with the runtime heap.
● Allocators are hard to debug.
● Another tool in the toolbox.

Thanks!
robbie.l@missingbox.co.nz
www.github.com/regretbomb

Transitioning to Native

More Related Content

Similar to Transitioning to Native

Recently uploaded

Transitioning to Native