Creative Engineering 101
Tom Mejias
Who am I?
● Tom Mejias
● Creative Engineer @ Space Ape
● 10 years industry experience across console & mobile
● Specialisation in Gameplay / UX / Creative
● Blizzard fanboy / whale
Who are Space Ape?
● 6 years old
● Mobile Focus: 4 Games Released
○ Samurai Siege
○ Rival Kingdoms
○ Transformers
○ Fastlane
● Lots of new games & genres in the pipeline
● Recently part acquired by Supercell, creator of Clash of Clans
What will you learn today?
● Engineering & Industry Overview
● What is Creative Engineering
● How to do it
● What to keep in mind
● What to make
● What to learn
Engineering & Industry
Overview
Engineering Roles
Specialist (Depth)
● Gameplay
● UI
● Audio
● Engine
● Graphics/Rendering
● Tools
● Networking
● AI
Generalist (Breadth)
● Broader, but shallower
understanding of a number of the
disciplines above
● Can work on many areas at once
Engineering Roles
Generalist (Breadth)
● Broader, but shallower
understanding of multiple
disciplines
● Can work on many areas at once
Specialist (Depth)
● Gameplay
● UI
● Audio
● Engine
● Graphics/Rendering
● Tools
● Networking
● AI
Console / AAA
● Specialists more desirable
● Large teams -> Less agile
● More crunch
● Smaller cog in a big machine
● Established companies more
secure
The Industry
Mobile / Startup / Indie
● Generalists more desirable
● Smaller teams -> More agile
● Less crunch
● More personal impact
● Startups & Indie can be less secure
Console / AAA
● Specialists more desirable
● Large teams -> Less agile
● More crunch
● Smaller cog in a big machine
● Established companies more
secure
The Industry
Mobile / Startup / Indie
● Generalists more desirable
● Smaller teams -> More agile
● Less crunch
● More personal impact
● Startups & Indie can be less secure
What is creative
engineering?
My Engineering Focus
Labels / Responsibilities
● Gameplay Engineering
● Creative Engineering
● Rapid Development
● Concept Validation
● Prototyping
Scary mind map on the next slide, be warned!
High Level Overview
Internalise the mantra
“Write good, extendible code fast and for the express purpose of validating
a hypothesis”
High Level Overview
Internalise the mantra
“Write good, extendible code fast and for the express purpose of validating
a hypothesis”
● Being efficient with time
● Not duplicating code
● Not getting stuck in a code spaghetti loop
● Always thinking ahead
High Level Overview
Internalise the mantra
“Write good, extendible code fast and for the express purpose of validating
a hypothesis”
● Focusing on the user experience
● Focusing on feedback mechanisms
● Focusing on quality of play
● Focusing on answering your questions
How to do it?
Write Good Code
● Prototyping doesn't mean write bad code
● Refactor often & obsessively
● Scavenge code and refactor it, don't write it again
● Requirements will change, make your code extendible where you can
● Don’t get caught over optimizing
● Still be a means to an end programmer
Make Yourself a Toolkit
Most games have very similar common systems.
● Health System
● Damage System
● Buff System
● Ability System
● Stats Tracking System
● Profile / Persistence Systems
● UI / Dialog Systems
● Animation / Transition Systems
● Common architectural patterns
Make them generic and slot them in to every prototype you make.
Scavenge What You Can
Code
● Open source projects
● Your toolkit & past projects
Art
● Unity Asset Store
● Images.google.com
● poly.google.com
UX
● Find strong references to replicate and for inspiration
Plan your features
1. What - What is the feature you're about to make?
2. Why - Why are you making this feature, how does it tie in to your vision?
3. How - How could you go about building this feature?
4. Where - Where could you put this feature in order the maximise it's
extendibility
5. How - Now you know where, how could you build this feature to
maximise it's extendibility
6. When - Now you know the full picture, when should you do it?
Design for your players
● Have a good idea what you want your players to feel from every
mechanic
● Have a plan on how to elicit that feeling from them
● Q: Is this system here because it’s fun for me to write or because it’s fun
for the player?
● Show, don’t tell, the player wherever possible
● Keep it simple, stupid!
Summary
1. Get yourself into the habit of refactoring early. The longer you leave it,
the harder it will be to do
2. Make yourself a set of standalone systems that perform tasks, you will
move much faster by doing this
3. Be a scavenger
4. Always have a plan
5. Design for your players
What should I keep in mind?
Think about your scope
● Collate a wishlist of mechanics / abilities / interactions first
● Slice through them to find common systems / patterns
● Evaluate and prioritise what systems to make by how much value they
unlock
● This process will help you make more extendible code by forcing
yourself to think ahead and create flexible systems
Think about where you are
● Game Jam - Focus is on the interaction, forget about content, fake as
much stuff as humanly possible
● Prototyping - Focus is on the interaction and its interaction with
content, make things as multi-purpose as possible
● Production - Focus is on performance and maintainability, make things
as safe, understandable and single-purpose as possible
The Space Ape “Funnel”
Proof of
Concept
Spark
Prototyping
What is the game?
Can and should we
make it?
Make it and test it, and
then make it again!
Agile
Production
Think about your audience
● Internal prototype to a team? - Focus on the mechanic, loosen up on the
usability
● Internal prototype to a company? - Focus on the mechanic and the
usability equally
● External prototype to a user group? - Focus on the usability above all
Think of when/what/who to show
● First impressions will last through a prototype
● People are always most engaged the first time they try something new
● Show to a rotating subset of people
● Only show if you have a question you need answering, or to test
usability
● If you run surveys/playtests, have a consistent set of questions so you
can see change over time
Summary
1. Think ahead to be flexible
2. Form good habits while planning
3. Think holistically about your place in the project lifecycle
4. Think about your target audience, have empathy
5. Consider when, what, why and who to show work to
What should I make?
Have a strong vision
● The most important thing while making a game is having a clear,
consistent, and objective understanding of what you are making
● This is often called ‘the vision’
● There is often a ‘vision holder’ on a team who is in control of the vision
● The vision needs to be communicated clearly to everyone on the team
● There are many ways of finding and maintaining the vision
The Promise
1. Describe your vision for the game in a single statement
2. When adding a feature; does it “fit” with the statement?
3. Yes? Great! Continue on with implementation
4. No? Either the feature doesn't “fit” or the vision has changed, work that
out before continuing
5. If you updated the vision, reflect on previous features and their place
with the new vision
6. Repeat
The Promise
“A strategic mobile game where I play a commander of
an elite squad, outsmarting a real opponent to win in
quick, FPS-themed scenarios.”
“A racing themed game which gives me the fun,
competition, control and longevity I get from playing
Mario Kart.”
The Promise
“A strategic mobile game where I play a commander of
an elite squad, outsmarting a real opponent to win in
quick, FPS-themed scenarios.”
“A racing themed game which gives me the fun,
competition, control and longevity I get from playing
Mario Kart.”
Pillars / Ideation Gates
1. Describe your vision as a set of pillars to keep you honest
2. Ensure that for any new features, these pillars still remain strong
● This is especially useful when trying to filter out what NOT to make.
● If you develop a set of pillars; when you are brainstorming for new ideas
you can self validate by rating them out of 5 in each of your pillars and
culling ideas with low scores across the board
Pillars / Ideation Gates
Mobile
First
Evergreen
Gameplay
Scalable
Opportunity
for Mastery
Player Driven
Content
Know Your Complexity
1. Know where the complexity will exist in your game
○ Visual Complexity (visual noise, effects, reduced clarity, chaos, movement, camera shakes)
○ Cognitive Complexity (strategy of abilities, game state awareness, game rule combinations)
○ Interaction Complexity (input timing, frequency, accuracy, intuitiveness)
2. Make sure neither of the 3 complexities are too high and offset high
complexity in one with low in the others
3. Keep your complexities balanced! If you rate each complexity category
out of 5, aim for a grand total of 7 combined
Chart Your Complexity
(Complexity)
~ 7 = About Right?
<< 7 = Too Shallow?
>> 7 = Too Core?
Summary
1. Employ methods to find and maintain a strong vision
2. Think about how to best describe your vision
3. Think about ways to validate the levels of complexity
4. Think about “the opportunity”
What should I learn?
Learn User Experience
● Easy to understand - If you can't explain it in a sentence, either it
shouldn't be user facing or it doesn't belong in the game
● Does what is expected - Spend the lion's share of your time and effort
on making sure your UI/UX makes sense, feels good and guides the
player
● Good feedback on actions - If the user does a thing, always do a thing,
then tell them how great it is they just did a thing
Learn 3D Maths
Seriously guys, just learn the following by heart, they are on every interview
● Vectors - Used for everything, from positions to rotations to velocities.
● Dot Product - Used in almost everything, think of it as “how similar are
these two vectors”
● Cross Product - Used a lot, think of it as “find the perpendicular vector”
● Quaternions - Just understanding their benefits/drawbacks is a start,
look up gimbal lock and slerping
● Matrices - Mostly useful in rendering and mesh generation, really good
to be comfortable with them
Learn Common Design Patterns
Communication Strategies
● Event Bus
● Signals
General Game Architectures
● Entity Component System (Data Oriented Design) (See: Entitas)
● Model/View Separation
Inversion of Control
● Dependency Injection Frameworks (See: Zenject)
● Constructor/Interface Injection
Learn Data Structures
● Understand the pros and cons between all the major data structures
● Try and always think of your data structures first before making
anything else
● Write your own versions of the popular containers to understand how
they work, this will always be asked in interviews
● For better or worse, interviewers ALWAYS ask you to write a linked list
implementation on a whiteboard. Just learn it.
● Maybe even take a look at unit testing, for bonus points
Be Experienced
● It’s so easy to make games nowadays, go make one (now that you have
the time to do it!)
● Learn Unity & C# if you want to get into mobile
● Learn Unreal & C++ if you want to get into console
● If you don’t want to make a whole game, try implementing individual
mechanics you like from existing games - you can use them for a
portfolio!
● Let yourself be inspired and don’t let yourself get jaded
Summary
1. Value your end user; focus on their experience
2. Learn to manipulate 3D maths concepts effortlessly
3. Learn common design patterns
4. Be comfortable with all the popular data structures
5. Get experience everywhere you can
6. Be inspired and be inspiring
More Info
VARSITY@SPACEAPEGAMES.COM
QUESTIONS?

Creative Engineering 101

  • 1.
  • 2.
    Who am I? ●Tom Mejias ● Creative Engineer @ Space Ape ● 10 years industry experience across console & mobile ● Specialisation in Gameplay / UX / Creative ● Blizzard fanboy / whale
  • 3.
    Who are SpaceApe? ● 6 years old ● Mobile Focus: 4 Games Released ○ Samurai Siege ○ Rival Kingdoms ○ Transformers ○ Fastlane ● Lots of new games & genres in the pipeline ● Recently part acquired by Supercell, creator of Clash of Clans
  • 4.
    What will youlearn today? ● Engineering & Industry Overview ● What is Creative Engineering ● How to do it ● What to keep in mind ● What to make ● What to learn
  • 5.
  • 6.
    Engineering Roles Specialist (Depth) ●Gameplay ● UI ● Audio ● Engine ● Graphics/Rendering ● Tools ● Networking ● AI Generalist (Breadth) ● Broader, but shallower understanding of a number of the disciplines above ● Can work on many areas at once
  • 7.
    Engineering Roles Generalist (Breadth) ●Broader, but shallower understanding of multiple disciplines ● Can work on many areas at once Specialist (Depth) ● Gameplay ● UI ● Audio ● Engine ● Graphics/Rendering ● Tools ● Networking ● AI
  • 8.
    Console / AAA ●Specialists more desirable ● Large teams -> Less agile ● More crunch ● Smaller cog in a big machine ● Established companies more secure The Industry Mobile / Startup / Indie ● Generalists more desirable ● Smaller teams -> More agile ● Less crunch ● More personal impact ● Startups & Indie can be less secure
  • 9.
    Console / AAA ●Specialists more desirable ● Large teams -> Less agile ● More crunch ● Smaller cog in a big machine ● Established companies more secure The Industry Mobile / Startup / Indie ● Generalists more desirable ● Smaller teams -> More agile ● Less crunch ● More personal impact ● Startups & Indie can be less secure
  • 10.
  • 11.
    My Engineering Focus Labels/ Responsibilities ● Gameplay Engineering ● Creative Engineering ● Rapid Development ● Concept Validation ● Prototyping Scary mind map on the next slide, be warned!
  • 13.
    High Level Overview Internalisethe mantra “Write good, extendible code fast and for the express purpose of validating a hypothesis”
  • 14.
    High Level Overview Internalisethe mantra “Write good, extendible code fast and for the express purpose of validating a hypothesis” ● Being efficient with time ● Not duplicating code ● Not getting stuck in a code spaghetti loop ● Always thinking ahead
  • 15.
    High Level Overview Internalisethe mantra “Write good, extendible code fast and for the express purpose of validating a hypothesis” ● Focusing on the user experience ● Focusing on feedback mechanisms ● Focusing on quality of play ● Focusing on answering your questions
  • 16.
  • 17.
    Write Good Code ●Prototyping doesn't mean write bad code ● Refactor often & obsessively ● Scavenge code and refactor it, don't write it again ● Requirements will change, make your code extendible where you can ● Don’t get caught over optimizing ● Still be a means to an end programmer
  • 18.
    Make Yourself aToolkit Most games have very similar common systems. ● Health System ● Damage System ● Buff System ● Ability System ● Stats Tracking System ● Profile / Persistence Systems ● UI / Dialog Systems ● Animation / Transition Systems ● Common architectural patterns Make them generic and slot them in to every prototype you make.
  • 19.
    Scavenge What YouCan Code ● Open source projects ● Your toolkit & past projects Art ● Unity Asset Store ● Images.google.com ● poly.google.com UX ● Find strong references to replicate and for inspiration
  • 20.
    Plan your features 1.What - What is the feature you're about to make? 2. Why - Why are you making this feature, how does it tie in to your vision? 3. How - How could you go about building this feature? 4. Where - Where could you put this feature in order the maximise it's extendibility 5. How - Now you know where, how could you build this feature to maximise it's extendibility 6. When - Now you know the full picture, when should you do it?
  • 21.
    Design for yourplayers ● Have a good idea what you want your players to feel from every mechanic ● Have a plan on how to elicit that feeling from them ● Q: Is this system here because it’s fun for me to write or because it’s fun for the player? ● Show, don’t tell, the player wherever possible ● Keep it simple, stupid!
  • 22.
    Summary 1. Get yourselfinto the habit of refactoring early. The longer you leave it, the harder it will be to do 2. Make yourself a set of standalone systems that perform tasks, you will move much faster by doing this 3. Be a scavenger 4. Always have a plan 5. Design for your players
  • 23.
    What should Ikeep in mind?
  • 24.
    Think about yourscope ● Collate a wishlist of mechanics / abilities / interactions first ● Slice through them to find common systems / patterns ● Evaluate and prioritise what systems to make by how much value they unlock ● This process will help you make more extendible code by forcing yourself to think ahead and create flexible systems
  • 25.
    Think about whereyou are ● Game Jam - Focus is on the interaction, forget about content, fake as much stuff as humanly possible ● Prototyping - Focus is on the interaction and its interaction with content, make things as multi-purpose as possible ● Production - Focus is on performance and maintainability, make things as safe, understandable and single-purpose as possible
  • 26.
    The Space Ape“Funnel” Proof of Concept Spark Prototyping What is the game? Can and should we make it? Make it and test it, and then make it again! Agile Production
  • 27.
    Think about youraudience ● Internal prototype to a team? - Focus on the mechanic, loosen up on the usability ● Internal prototype to a company? - Focus on the mechanic and the usability equally ● External prototype to a user group? - Focus on the usability above all
  • 28.
    Think of when/what/whoto show ● First impressions will last through a prototype ● People are always most engaged the first time they try something new ● Show to a rotating subset of people ● Only show if you have a question you need answering, or to test usability ● If you run surveys/playtests, have a consistent set of questions so you can see change over time
  • 29.
    Summary 1. Think aheadto be flexible 2. Form good habits while planning 3. Think holistically about your place in the project lifecycle 4. Think about your target audience, have empathy 5. Consider when, what, why and who to show work to
  • 30.
  • 31.
    Have a strongvision ● The most important thing while making a game is having a clear, consistent, and objective understanding of what you are making ● This is often called ‘the vision’ ● There is often a ‘vision holder’ on a team who is in control of the vision ● The vision needs to be communicated clearly to everyone on the team ● There are many ways of finding and maintaining the vision
  • 32.
    The Promise 1. Describeyour vision for the game in a single statement 2. When adding a feature; does it “fit” with the statement? 3. Yes? Great! Continue on with implementation 4. No? Either the feature doesn't “fit” or the vision has changed, work that out before continuing 5. If you updated the vision, reflect on previous features and their place with the new vision 6. Repeat
  • 33.
    The Promise “A strategicmobile game where I play a commander of an elite squad, outsmarting a real opponent to win in quick, FPS-themed scenarios.” “A racing themed game which gives me the fun, competition, control and longevity I get from playing Mario Kart.”
  • 34.
    The Promise “A strategicmobile game where I play a commander of an elite squad, outsmarting a real opponent to win in quick, FPS-themed scenarios.” “A racing themed game which gives me the fun, competition, control and longevity I get from playing Mario Kart.”
  • 35.
    Pillars / IdeationGates 1. Describe your vision as a set of pillars to keep you honest 2. Ensure that for any new features, these pillars still remain strong ● This is especially useful when trying to filter out what NOT to make. ● If you develop a set of pillars; when you are brainstorming for new ideas you can self validate by rating them out of 5 in each of your pillars and culling ideas with low scores across the board
  • 36.
    Pillars / IdeationGates Mobile First Evergreen Gameplay Scalable Opportunity for Mastery Player Driven Content
  • 37.
    Know Your Complexity 1.Know where the complexity will exist in your game ○ Visual Complexity (visual noise, effects, reduced clarity, chaos, movement, camera shakes) ○ Cognitive Complexity (strategy of abilities, game state awareness, game rule combinations) ○ Interaction Complexity (input timing, frequency, accuracy, intuitiveness) 2. Make sure neither of the 3 complexities are too high and offset high complexity in one with low in the others 3. Keep your complexities balanced! If you rate each complexity category out of 5, aim for a grand total of 7 combined
  • 38.
    Chart Your Complexity (Complexity) ~7 = About Right? << 7 = Too Shallow? >> 7 = Too Core?
  • 39.
    Summary 1. Employ methodsto find and maintain a strong vision 2. Think about how to best describe your vision 3. Think about ways to validate the levels of complexity 4. Think about “the opportunity”
  • 40.
  • 41.
    Learn User Experience ●Easy to understand - If you can't explain it in a sentence, either it shouldn't be user facing or it doesn't belong in the game ● Does what is expected - Spend the lion's share of your time and effort on making sure your UI/UX makes sense, feels good and guides the player ● Good feedback on actions - If the user does a thing, always do a thing, then tell them how great it is they just did a thing
  • 42.
    Learn 3D Maths Seriouslyguys, just learn the following by heart, they are on every interview ● Vectors - Used for everything, from positions to rotations to velocities. ● Dot Product - Used in almost everything, think of it as “how similar are these two vectors” ● Cross Product - Used a lot, think of it as “find the perpendicular vector” ● Quaternions - Just understanding their benefits/drawbacks is a start, look up gimbal lock and slerping ● Matrices - Mostly useful in rendering and mesh generation, really good to be comfortable with them
  • 43.
    Learn Common DesignPatterns Communication Strategies ● Event Bus ● Signals General Game Architectures ● Entity Component System (Data Oriented Design) (See: Entitas) ● Model/View Separation Inversion of Control ● Dependency Injection Frameworks (See: Zenject) ● Constructor/Interface Injection
  • 44.
    Learn Data Structures ●Understand the pros and cons between all the major data structures ● Try and always think of your data structures first before making anything else ● Write your own versions of the popular containers to understand how they work, this will always be asked in interviews ● For better or worse, interviewers ALWAYS ask you to write a linked list implementation on a whiteboard. Just learn it. ● Maybe even take a look at unit testing, for bonus points
  • 45.
    Be Experienced ● It’sso easy to make games nowadays, go make one (now that you have the time to do it!) ● Learn Unity & C# if you want to get into mobile ● Learn Unreal & C++ if you want to get into console ● If you don’t want to make a whole game, try implementing individual mechanics you like from existing games - you can use them for a portfolio! ● Let yourself be inspired and don’t let yourself get jaded
  • 46.
    Summary 1. Value yourend user; focus on their experience 2. Learn to manipulate 3D maths concepts effortlessly 3. Learn common design patterns 4. Be comfortable with all the popular data structures 5. Get experience everywhere you can 6. Be inspired and be inspiring
  • 47.