Game development facts and tips

Posted on November 19, 2009 by Daniel Rodríguez

Last month I had the pleasure of finding a new friend in the gamedev community: Ian Masters, a senior game programmer at Sidhe Interactive, creators of the Speed Racer game for Nintendo Wii and Sony PlayStation 2.

While he was in town I managed to compile a list of game development facts and tips. Here they are:

Programming:
Everybody creates their own internal technology to build games. They modify engines and create frameworks for internal use.
The technical director is the responsable of selecting technology like the game engine.
Developing a game engine from scratch could take years and it’s not recommended.
The most used languages in game development are : C++, Lua and Python.
It’s common to have a prototyping team.
Use source control (SVN, mercurial, etc.)
Have all your projects into a solution, prefer that to link against static libraries (including third party code).
Have your engine’s source code in your source control system so you can modify it and the changes will propagate.
QA:
Unit testing is very important (specially for math libraries and core functions).
Regression testing is important too.
QA team is different from playtesting. QA test QA, playtesters test fun.
No QA guys in multidisciplinary teams.
Art:
Conceptual art should be delivered as soon as possible before programming start (at least a month ahead).
Work on iterations.
Artists hate naming conventions.
It’s not easy to convince the artists to follow naming conventions (normally you need a producer to talk to them).
Having a lead artist who follows naming conventions is crucial.
Try to integrate audio as soon as possible. Audio is not a luxury.
Post effects are often decided between the post effects coder and the art director.
Camera effects are often decided between the camera scripters and the designers.
Have metrics with the export tools (poly counts, texture sizes, bone count, etc)
Should present a visual target.
Design:
They can’t account for everything.
Design document should be as detailed as possible.
Design document should be a live document.
They define tunable properties.
Normally use XML files for tunable properties (exported from spreadsheets for extra awesomeness).
There are co-designers (scripters).
Production:
Producer’s work is to assure work is being done and cycles are running smoothly.
Wikis are awesome.
You can manage a whole project documentation using exclusively a wiki.
Procedures, knowledge and project management all fit into a wiki.
Multidisciplinary teams are a great way to work.
Have a list of features that need to be tested on the prototype.
Recommendations:
Scrum is the way to go.
Use Scrum properly.
Scrum meetings in the mornings.
Put scrum plans on the wiki.
Create tickets on Trac or a similar tool.
Keep things visible and transparent.
Read a lot. Be proactive and an active learner and problem solver.
Try to work as close as possible with artists, programmers and designers.
You need a published title to get into the industry. To get that title you need to be in the industry. Indie titles are a good way to break into it.
Prototype as soon as possible.

Programming:

  • Everybody creates their own internal technology to build games. They modify engines and create frameworks for internal use.
  • The technical director is the responsable of selecting technology like the game engine.
  • Developing a game engine from scratch could take years and it’s not recommended.
  • The most used languages in game development are : C++, Lua and Python.
  • It’s common to have a prototyping team.
  • Use source control (SVN, mercurial, etc.)
  • Have all your projects into a solution, prefer that to link against static libraries (including third party code).
  • Have your engine’s source code in your source control system so you can modify it and the changes will propagate.

QA:

  • Unit testing is very important (specially for math libraries and core functions).
  • Regression testing is important too.
  • QA team is different from playtesting. QA test QA, playtesters test fun.
  • No QA guys in multidisciplinary teams.

Art:

  • Conceptual art should be delivered as soon as possible before programming start (at least a month ahead).
  • Work on iterations.
  • Artists hate naming conventions.
  • It’s not easy to convince the artists to follow naming conventions (normally you need a producer to talk to them).
  • Having a lead artist who follows naming conventions is crucial.
  • Try to integrate audio as soon as possible. Audio is not a luxury.
  • Post effects are often decided between the post effects coder and the art director.
  • Camera effects are often decided between the camera scripters and the designers.
  • Have metrics with the export tools (poly counts, texture sizes, bone count, etc)
  • Should present a visual target.

Design:

  • They can’t account for everything.
  • Design document should be as detailed as possible.
  • Design document should be a live document.
  • They define tunable properties.
  • Normally use XML files for tunable properties (exported from spreadsheets for extra awesomeness).
  • There are co-designers (scripters).

Production:

  • Producer’s work is to assure work is being done and cycles are running smoothly.
  • Wikis are awesome.
  • You can manage a whole project documentation using exclusively a wiki.
  • Procedures, knowledge and project management all fit into a wiki.
  • Multidisciplinary teams are a great way to work.
  • Have a list of features that need to be tested on the prototype.

Recommendations:

  • Scrum is the way to go.
  • Use Scrum properly.
  • Scrum meetings in the mornings.
  • Put scrum plans on the wiki.
  • Create tickets on Trac or a similar tool.
  • Keep things visible and transparent.
  • Read a lot. Be proactive and an active learner and problem solver.
  • Try to work as close as possible with artists, programmers and designers.
  • You need a published title to get into the industry. To get that title you need to be in the industry. Indie titles are a good way to break into it.
  • Prototype as soon as possible.

Hope that helps, and a big “Thank you” to Ian for his time with us. I learned a lot.

Posted in Game development | Tagged , | 1 Comment

Introduction to Game Development and Unity3d

Posted on November 19, 2009 by Daniel Rodríguez

Today I was invited to the UVM University to give a workshop on game development using Unity3d. For that purpose I created a small presentation that you can find in pdf format here: Introduction to game development and Unity3d.

It is a very basic introduction, but I hope you like it.

Posted in Game development | Tagged , | 2 Comments

Game design with Noah Falstein, part 4: Brainstorming and extra tips

Posted on October 10, 2009 by Daniel Rodríguez

Meta-observation:

  • The best way to learn is by playing many games and learning from other designers
  • Game designers must also learn to observe themselves on many levels as they play
  • Some levels in playing/designing games: Mechanics, strategies, cheat/exploit, game design rules… but there are other ways to see it

Basic brainstorming:

  • Be aware of, but not shackled by constrains
  • Listen to what others say
  • Challenge assumptions – your own and others
  • Vary discussion of theme/story and gameplay mechanics (Important!)
  • Try to cross-fertilize ideas even (specially) when it seems absurd
  • You are finding new neural pathways
  • Mixing wildly different ideas or themes can create useful tension
  • Example: Art deco + bio-tech + Ayn Rand + 1960 + underwater = Bioshock
  • Ideas, not egos: Critique concepts, not people
  • Review constraints and question them too
  • Good, not escential, to have a reason why
  • Nothing is to odd or silly – low hit ratio
  • It’s normal to wander – some!
  • Best size around 5 +- 2
  • Common ground, divergent opinions
  • Avoid including managment directly (fear of firing, danger of deferring to boss)
  • Consider flied trips, resources, toys
  • Time pressure (optional)
  • No judgments (optional, useful for dealing with people that has never done brainstorming)
  • More than art as you gain experience

Great game elements (advanced techniques):

  • Classic convexity structure (Start wth one node, then many, then one again)
  • Appropiate inteface
  • Negative feedback (Handicap)
  • Self-tunning features
  • Emergent complexity (Overlap various game mechanics)
  • Great balance (tradeoffs again!)

Negative feedback examples:

  • Exponential costs (experience, money, etc)
  • Easier to aim after each failure or death
  • Selling items give you less money that what you originally paid for it
  • Stronger units are more restictive (specialized, only good against another specific unit, etc)
Posted in Game development | Tagged | Leave a comment

Game design with Noah Falstein, part 3: Natural funativity theory

Posted on October 4, 2009 by Daniel Rodríguez

Natural Funativity Theory:

Natural funativity theory is Noah’s own work. You can find the original gamasutra article here. What I present here are only my notes on the subject, my personal interpretation of the theory. Hope you find it useful.

What is fun?

  • Dictionary: Enjoyment, a souce of amusement (that does not help)
  • Consider underlying reasons
  • “Funativity”: Thinking about fun in terms of a measurable cause and effect
  • Inevitably this leads to “Why do we commonly share the experience of fun?”

Evolutanary roots:

  • We must look to our distant past
  • Young mamals play to learn basic survival skills
  • Games are organized play
  • Human entrataiment is more complicated

Entretaiment is Learning:

  • Life is either work, rest or entretaiment
  • Perhaps at first it was all work or rest
  • Play (and fun) may be neotenal traits
  • Fun is about practicing or learning new survival skillin a relatively safe setting
  • People who didn’t experience were less likely to survive to become our ancestors

Natural Funativity Theory:

  • Basic concept is that all fun derives from practicing survival and social skills
  • Partly learning new skills, partly mastering and mantaining familiar ones
  • Key skills relate to stone-age human life, but often in modern context
  • Three cathegories: Physical, Social, Mental

Physical fun:

  • Sports generally enhance our strength, stamina, coordination skills
  • Exploration is fun, both of local area and knowledge of exotic places
  • Physical aspect to gathering “stuff”
  • Hand/eye coordination and tool use are often parts of fun activities, crafts

Social fun:

  • Storytelling is a social activity, a way to lean important survival and social lessons from others, our first VR
  • Gossip, bonding with friends aids survival
  • Flirting, showing off, finding mates is a key component in social fun
  • Language has become paramount

Mental fun:

  • Pure abstract reasoning practice is fun
  • Pattern matching and generaion
  • Music, art, puzzles, all pattern based, both perception and creation
  • Gathering has also a mental aspect: categorizing and identifyng patterns

Multipurpose fun:

  • Many fun activities have physical, social and mental aspects in combination
  • Games that mix these aspects tend to be very popular (e.g. Blizzard games)
  • Incorporate ways to practice these skills to increase popularity of games

Noah also mentioned that Diablo 2 was a great in combining the 3 types of fun. You have great physical (hack and slash mechanics, click click click), great mental (inventory, item management, etc) and of course, great social fun (multiplayer is great!).

Seth out.

Posted in Game development | Tagged | 1 Comment

Game design with Noah Falstein, part 2: Fundamentals

Posted on October 3, 2009 by Daniel Rodríguez

Ok, continuing with my notes on game design, here you have the fundamentals that Noah Falstein teach us:

Identify your constrains:

  • Creative: expectations and goals
  • Technical (including platform)
  • Bussiness, marketing, sales, distribution
  • People: skills and personalities
  • Internal politics
  • Serious games – add teaching/training and real world content constraints

    Game design fundamentals:

    • Creative plagiarization: Take only what is appropiate, make it your own
    • Sid Meier’s rule: Fun for the player, not for computer or designer
    • Albert Einstein: Make it as simple as possible, and no simpler
    • Make it familiar, yet new
    • Easy to learn, hard to master
    • Easy, clean, deep
    • Emphasize exploration and discovery
    • Have a clear short, medium and long term goals
    • Natural funativity: hunting and gathering

      A great game:

      • A series of interactive choises in the persuit of a series of well stablished and compelling goals
      • Must be a series of choises or it’s too simple to be a game
      • Must have a goal or it’s a software toy
      • With Sim City and The Sims players may bring heir own goals
      • Choises need to be meaningful
      • If choises are dull could be that:
      • Easy to code that way
      • Lazy designer
      • Meaningful choises are perceived by the player as having significant consequences
      • May not have actual consequences

        Goals:

        • Clear goals: it’s not fun to flounder aimlessly
        • Avoid “the protagonist with amnesia” cliché
        • Compelling goals are goals that follow the concepts in natural funativity
        • Surival is always a compellin goal

          Flow:

          • Combine intense learning with practical gameplay
          • Start with a relatively low stress level
          • Combine rapid difficulty increase with slower increase. That maximizes fun.
          • High difficulty increase: Boss battles, climatic battles, quest resolutions
          • Low difficulty increase: Bonus levels, new resource ad tresure-rich areas, series of easy minion enemies
          • Overlap introduction of new skills, areas to explore, tools, enemies
            Posted in Game development | Tagged | 2 Comments

            Mixins in game development

            Posted on October 2, 2009 by Daniel Rodríguez

            Programmers tend to think in the Object Oriented Programming paradigm all the time. We create complex class hiercharies that describe every single entity on the game. Thats what we learn at school, we are programmed (deeply into our firmware) to do that, but there is a whole world of different pradigms and approaches we can use, and the scripting languages are bringing the dynamic style into the game.

            Functional programming can be great for game scripting, Lua has beeen a very popular game scripting language for a very long time, and a bunch of game engines uses it (including CryEngine 2.0 and Gamebryo LightSpeed). The ability to attach properties and functions into an object at runtime, for example, is incredibly useful to create high level game logic and even artificial intelligence.

            We can talk about dynamic languajes and their benefts here, but I want t focus on Mixins as the modern approach to game entity description:

            Mixins are chunks of functionability that can be applied to game objects. You can think of them as little pieces (building blocks) that you use to create a complex game entity. The most basic mixin every game entity is the entity’s transform which defines its position, rotation and scale. Each game engine implements entity’s transform in a different way, but the concept is the same.

            Mixin complexity can vary from a simple mixin that lets you name an object (holds a string identifier), to very complex mixins like the one that provides characters the ability to use pathfinding to navigate the scene.

            Each engine handles mixin agreggation in it’s own way, some engines even let you use multiple inheritance with mixins. Please note the difference between mixin inheritance and mixin agreggation:

            • Inheritance:
            • Mixins can be inherited
            • You can have mixin class hierarchies just the same way you can with normal classes
            • Aggregation:
            • Game objects agreggate a number of mixins to aquire their functionability
            • Mixins are agreggated (added to game objects) to create entity model descriptions

            For example: A mixin called BoomerangTarget provides the ability to be the target of the player’s boomerang. BoomerangTarget is a child of another mixin called Target which provides the generic ability of being a target of a player’s weapon. At the same time, an Enemy agreggates the following  mixins: Actor, BoomerangTarget, SwordTarget. Actor lets the enemy play animations, BoomerangTarget is the mixin desvribed above and SwordTarget provides the ability to be hit by a sword. SwordTarget mixin is also a child of Target, thus, both BoomerangTarget and SwordTarget share the basic functionability defined in the Target mixin.

            A lot of game engines are using Mixins these days. Mixins have become the standard way to represent game object functionability.

            Seth out.

            Posted in Game development | Tagged , | 3 Comments

            Game design with Noah Falstein, part 1: The game designer

            Posted on September 28, 2009 by Daniel Rodríguez

            Last month I took a very interesting course of Game Design with the professional game designer Noah Falstein, fomous for working at LucasArts (formely Lucas Film Games), DreamWorks Interactive, and now his very own game consultant company: The inspiracy

            I asked Noah for permission to share my personal notes about this course, so, here you have them. The stuff presented here may be the basics of game design, but I really learned from them.

            In this first part I collected my notes about what is a game designer, his role, and the types of game designers.

            Game Design with Noah Falstein:

            How to spot a game designer:

            • Obsessive game players, moviegoers and readers. Be in the popular culture!
            • They easily get mistaken for the standard programmer and common nerd
            • Wonders how things work and why: Rules!
            • Smart but quirky
            • In-depth knwoledge of many different areas

              Tips:

              • Know a lot of things: If you only specalize in one thing, all your games will be the same
              • Story & design should support each other: they both will become stronger that way
              • Reuse characters, that will add more to them
              • DON’T make your first level first! Always start designing at the middle of the game
              • Don’t stay in the kwnon landscape, explore!

                Game designer types:

                • Lead designer/Design director:
                • Combination of managment and design
                • Assistant designers/co-designers
                • Take charge of subset, may share vision
                • Level designers
                • Often hybrid of artist, architect, designer
                • Playtesters
                • Separated from QA (PT = fun, QA = bugs)

                  How to become a game designer:

                  • You need experience
                  • The chicken and egg problem (do something else)
                  • Specialize in different areas (if you only know a subject all your games will be the same)
                  • If you only want to be a game designer, probably you shouldn’t become one

                    Game designer fundamentals:

                    • Clear overall vision
                    • Keep the audience in mind
                    • Consider the player’s experience
                    • Concentrate on the decisions made
                    • Chris Crawford says: “Verbs, not nouns”
                    • Do stuff, don’t show it

                      The next part of my notes are about game design in general, I’ll post them soon.

                      Posted in Game development | Tagged | Leave a comment

                      Here comes the kraken!

                      Posted on June 3, 2009 by Daniel Rodríguez

                      Welcome to Silent Kraken, your ultimate resource for game development.

                      We are a small team of game developers including artists, coders and game designers and all we want is to develop fun stuff.

                      In this blog I’ll be talking about what I decided to call “The kraken”: the new generation of games, I’ll be posting my research about Game Design, my experiences building games and how I get in contact with the industry. I’m a newcomer to the blogging universe and my english is really bad sometimes, but I hope you’ll find this blog interesting.

                      Stay tuned for updates.

                      Posted in Blog | Leave a comment