The document discusses transitioning from managed languages like Unity to native C++ development. It covers jumping into native development without proper planning, which often leads to failure. It also discusses the challenges of developing without editors or robust tools and the importance of data-driven development to maximize productivity. Finally, it discusses memory management challenges without a garbage collector and how approaches like smart pointers and custom allocators can help address those challenges.
6. Jumping into Native Development
“A Curiously Repeating Story”
By Robbie Litchfield
7. Jumping into Native Development
Day 1:
● Find C++ materials.
● Open StackOverflow.
● Write some code.
8. Jumping into Native Development
Week 1:
● Start on game idea.
● Powering through problems.
● Diligent StackOverflow use.
● Perceived leaps and bounds.
9. Jumping into Native Development
Month 1:
● StackOverflow… :(
● Errors are alien.
● Progress is dwindling.
● C++ love affair is over.
10. Jumping into Native Development
Many moons later:
● Minimal to no progress.
● Project seems ill-defined.
● Longing thoughts of Unity.
● Project failure.
12. Jumping into Native Development
● Understand your own requirements.
● Make pragmatic risk/benefit analyses.
● Explore novel solutions with existing tools.
● Do the above *before* cutting code.
14. Jumping into Native Development
● Start out on small and simple pilot projects.
● Take time for learning, analysis and design.
● Extend project time estimates, double them.
16. Jumping into Native Development
● “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.
22. Development without an Editor
● Games are larger and more complex.
● Demand for high content games.
● The standard for quality keeps on rising.
● Game sizes growing faster than teams.
26. Development without an Editor
Programmer time is a large bottleneck.
class Monster : GameObject, MRenderable
{
Monster(Health_t health);
virtual Attack_t GetAttack( ) = 0;
Health_t m_Health;
};
27. Development without an Editor
class Dragon : Monster
{
Dragon( ) : Monster( 99 ) {
}
virtual void GetAttack( ) override {
return “The dragon’s fire results in a
swift death.”; }
};
28. Development without an Editor
1. Designer asks for trivial change in Dragon.h
2. Modify Dragon.h
3. Recompile and check-in changes.
4. Reply to designer.
31. Development without an Editor
● Empower those who make the decisions.
● Minimise iteration time with powerful tools.
● Data requirements drive software design.
32. Development without an Editor
Data Driven Game Objects
{
“Name” : “DemonDragon”,
“Prototype” : “Dragon”,
“Attacks” : [ “SummonLesserDragons”,
“CharmMinion”, “MightyClaw”, “FireBreath” ]
“MinHealth” : “1500”
}
33. Development without an Editor
Game ObjectMRenderableMControllable MAnimatable
Actor
Monster
34. Development without an Editor
Monster
Demon
Dragon
“Attacks”
“MinHealth”“Zone”
Monster(Json &json) {
m_Health = json[“MinHealth”];
m_Attacks = json[“Attacks”];
m_Zone = json[“Zone”];
}
35. Development without an Editor
Monster
Goblin ElfDragon Human
TrollBlackDragon HighElf Orc
Demon
Dragon
36. Development without an Editor
● Works well if types are similar.
● Can’t express complex hierarchies.
● Still requires programmer time.
● We can do better...
38. Development without an Editor
class GameObject
{
public:
GameObject( Id_t id );
Id_t m_Id;
Id_t m_Prototype;
IntrusiveList<Component> m_Components;
};
39. Development without an Editor
MonsterDemon
Dragon
“Attacks”
“MinHealth”
“Zone”
Actor
GameObject
GameObject* Create(Json &json) {
for(auto& p : json) {
// Select component for property
// Set component value
}
}
40. Development without an Editor
● Added runtime cost.
● Compiler can’t help with type checking.
● Can trivially create new types without code.
● Programmer time for new concepts.
41. Development without an Editor
● Materials
● Scripts
● User Displayed Strings
● So much more...
42. Development without an Editor
● 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.
55. Memory Management without GC
● Superior to manual memory management.
● Deterministic cleanup and performance.
● Useful for any system resource.
● Learn this pattern, it’s everywhere.
56. C/C++ Dynamic Memory
void Func( ) {
auto *ptr = new T(“NZGDC15”);
/** ... **/
delete ptr;
}
Memory Management without GC
57. Memory Management without GC
● Global State.
● Slow, Heavy Subsystem.
● Virtual Memory Limitations.
● Heap Fragmentation.
61. Memory Management without GC
● Give up some convenience.
● Faster than the runtime heap.
● Fragmentation can be eliminated.
● Games only need a couple patterns...