Process of creating games

1. Process of creating games Game Design Vishnu Kotrajaras, PhD

2. The process, in short • Brainstorming • Come up with as many ideas as you can. • Narrow down to 3. • Write 1 page describing each idea. • Choose one out of three. • Physical prototype • Use pen & paper. • Playtests • Within here, if problems arise, you may have to brainstorm and playtest to solve such problems. • You need to play and adjust your game several times. • Once finished, write up 3-6 pages about the game and how to play them.

3. The process, in short(2) • Presentation(optional) • Used to secure fund. • This is another chance to get feedback. • Present demo artwork and detailed gameplay. • Modify game to fit the sponsor’s need, or cancel the project if things aren’t going well. • This may not be applicable to today’s market since big publishers won’t accept your work unless you are famous enough. • You are more likely to finish the game and sell it through an indie channel.

4. The process, in short(3) • Software prototype • Do not do graphics, just find ones that can be used easily. • Iteratively testing the prototype. • Design document(draft) • Production • Work with everyone, making sure each design idea is correctly presented in the document. • Do real art and programming. • Still, test and evaluating a work in each step along the way. • Do not add additional concepts, unless absolutely necessary.

5. The process, in short(4) • Quality control • Playtest again and again before launching.

6. Physical Prototype • Do it, if you can. • It is better to tune things this way before coding. • You can get feedback right away. • If flaws come out, it is much easier to fix things at this stage.

8. Notes on prototyping • Human can track 7+-2 concepts at once. (1956, George Miller) • Phone numbers are 7 digits long. • Tetris includes 7 shapes. • Thus real concepts of the game must be simple enough for human to grasp. • Prototyping help enforces that. • Vague rules become more concrete. • Try modifying the prototype to get a better play.

9. From board to computer • Diablo 2, baldur’s gate, EverQuest, Asheron’s Call, Dark Age of Camelot. • Based on D&D. • Civilization.

10. Civilization Shockforce Wooden Ships & Iron Men BattleTech

11. FPS as a board game: an example • You may use a hexagonal graph paper. • Then construct walls and spawning points. • Make them repositionable. • Matchsticks are perfect for this. • Then place units. A unit must show which direction it is facing.

12. Each player gets the following 9 cards • Move 1 space x1 • Move 2 spaces x1 • Move 3 spaces x1 • Move 4 spaces x1 • Turn any direction x2 • Shoot x3

13. Each player chooses 3 cards and place them face down on the table in a stack. • Each player turns over his top card. • Resolve shoot: • Players with a shoot card fire in the direction their unit is facing. • If the shooting line intersects with a cell containing another unit, then it is a hit. • Shots happen simultaneously for all players • Resolve turn cards: • Players with turn cards turn their unit to any direction they want. • Resolve move cards: • Players move their unit according to move cards they have in hand. • Repeat all steps for the 2nd card and the 3rd card. • If a unit is shot, remove it from the game and regenerate it at a spawning point at the beginning of the next round.

14. Possible additions • Scoring system. Headcount maybe. • Hit and miss percentage based on how far on the grid. • Use 10-sided die. • 100% at adjacent grid, and reducing by 10% for each grid distance. • Hit points • Try 5 hit points, one removed when hit. • First aid point on the map. • Ammo and ammo point. • Other weapons.

15. But isn’t there limitations? • Not 3D experience, not real time? • Do not worry, the structure of the game is more important at this stage. • Physical prototyping forces you to think through the design elements and define them. • Programmer can grasp you vision from it.

16. Mage knight

17. Tips on physical prototype • Start with a core mechanic. • In FPS example, we allow simultaneous movement right away to capture the real time core gameplay. • Add things that are important first. • If you add some features, the overall rules will need to be added or changed to support it. • Rules come before features. • You can try removing a rule to see if the game still works. • After the gameplay is good, you can add details. • Add detail only one feature at a time. Test feature one by one. • If the gameplay is bad, try removing a feature and test again. • Use flowchart for visualisation.

18. If you are stuck • Try changing unlimited resource to limited, or vice versa. • Add ability for player to stop or change actions of other players. • Thus creating new play strategies, such as counter attack or cooperation. • Allow players to change the order of events in the game. • Such as speeding up his own turn or forcing his opponent to skip turn. • Remove a rule from the game, especially a rule that does not really have anything to do with the core mechanic. • Double of half a variable’s value.

19. Software prototype • Software prototype is the additional of small parts, itself still not a complete game. • Demo • A level • These must show the gameplay. • Includes what we said in the game’s focus. • By getting a small piece of the game working, we can get a sense whether the final game will be fun or not. • Can adjust or even cancel the project.

20. Non-intuitive , need fixing

21. If you still have no fun prototype, Do not • Do detailed design document. • Script the game’s dialog. • Make a detailed map. • Make a full level. • Draw real art.

22. Bad thing about detailed levels, art, or documents • These things make assumption about the gameplay, which maybe incorrect. • Wasted effort because the game is likely to be changed. • People who work hard on them will cling to them (keeping the non-working things). • Making the game bad if it includes such work. • Remember, the more people you have, the harder it is to change your game.

23. Example 1: Odyssey: The Legend of Nemesis • Richard Rouse inherited a game engine and some portion of the game from previous developer. • First, a six page document to the publisher • One page per one map. • By the time he had implemented the 2nd island, he know enough to throw some other islands away. • Didn’t lose much work, because the early design was not too detailed.

24. Odyssey: The Legend of Nemesis

25. Second, develop it using place-holder art (inherited from another project). • No fear of losing an already created art. • Hire an artist to draw replacements later.

26. Example 2: Centipede 3D • Original gameplay idea. • But created 6 levels!! • More levels on paper!! • Then find out that it was not fun. • Adjust the gameplay. • But had to throw away existing levels, and levels on paper. • If the designer kept them, it would be worse.

27. Centipede 3D

28. Prototyping stages • Initial Core Gameplay • Test only the core. • See if it is fun. • You may probably be testing (repeatedly) on your own. • Try for an audience • Add enough structure for your friends (people without full vision of the game) to play. • Test for functionality and fun (repeatedly). • Try the full functionality • Test for the game’s weakness and balance (repeatedly). • Refinement • Test for fun and accessibility (repeatedly).

29. Useful software or programming environments for prototyping • Flash • Macromedia Director • Game Maker • NeverWinter’s Aurora toolset • So good for designing 3D game. • TorchEd • Panda3D • Unity • Unreal 3 • Mod from Half-Life (such as Counter Strike). • Level Editor of Warcraft 3 • You must play with it if you want to design RTS.

30. Game maker Aurora

31. Some games really need software prototype • Tetris. • Space war game. • Whenever paper model becomes too difficult. • Remember to use the tool that allows fastest change. • Do not think of reusing the code here.

32. Problems in a big company • Artists, level designers, system coders start working at an early stage. • Publisher may want to see a complete design document before anything. • No choice, have to do what the sponsor says. • If possible, self-fund until you get the gameplay prototype working. • Good prototype will help getting the funding later.

33. Building the game (Production) • Build core technology • Complete one system or mechanic before moving on to the next system that depends on it. • It’s difficult to have a different team code systems in parallel.

34. Building core technology • Game engine must be built first • Does not have to be completed before we can start making the 1st playable version. • We don’t always know the limitation of technology. • We may first design 10 enemies on screen, but the engine can only support 3. Therefore we must change the design.

35. Incremental steps • Break down the design into tasks, fundamental and dependent tasks. • Sidescroll platform: getting the player’s navigation system working is the first thing to do. • Forward, backward, turning. • Work on it until it feels good. • Then add more movement: crouching, jumping. • Make sure they don’t break previous movements. All must work well together. • Then add attack movement: test until it feels right. • Then add enemy.

37. example steps for adding enemy and items • First, just get an enemy in the world so the player can attack. • Then get it moving around. • Then get it to do its attack. • Then add item into the world. • Next, allow player to pick it up, and throw it, etc. • In each and every stage, the game must be playable and fun. • When you add a thing that break previous elements, fix it immediately .

38. Try to play your game throughout the development • It is very easy to lose sight of your gameplay if you spend a lot of time in an unplayable state. • If team member can pick it up and play, they’ll have clearer idea of what they are working on. • If a thing that someone adds make the game less fun, you’ll see the effect immediately .

39. The first full level in the game • Once all mechanics are working as you like them, start making a level. • When you test the game on a level, you’ll find missing features of your game. • Make this level as close to the intended final state as possible before moving on to other levels. • You’ll learn a lot from a level, saving you a lot of time when creating other levels. • But since you will have modified this first level a lot, it will not be a good level compared to any future levels you make. • It is normal to throw away this first level.

40. Careful about difficulty level • When doing your first level, you’ll have a chance to adjust general difficulty level of the game. • Have some friends play the game. • Observe how easily it is to pick up. • If it is harder to play than you expect, you must change the design immediately. • Beware of getting used to flaws: • Unintuitive controls. • Unfair enemy moves.

41. Going through changes • Throwing away art, code, levels, and even design is something to be expected. • Everyone must be brave enough to throw them away. • Good work may not fit in the game, remember this.

43. But don’t overdo it • Designer may get bored of the kind of level he makes, and decide to redo the level just to get something new. • You must stop him from doing it! For players, this level will always be new when they play the game for the first time. • If the gameplay is already good, don’t change things.

44. Programming and designing • We need constant feedback between designer and programmer. • A designer who can program has advantages: • Can experiment with his ideas. • Can understand technology limitations. • Example: sword change shape when enchanted…(engine cannot do). • Engine can do some particles around the sword though. Designer may in fact be perfectly happy with this solution (but he doesn’t know the limitation of the engine).

45. Different gameplay ideas between designer and programmer • Programmer may pretend that it is hard, when in fact he does not like the idea. • Designer who does not know the technology will be taken advantages of.

46. If the designer don’t program • A lead programmer must have a good sense of gameplay. • Otherwise, the project may fail.

47. Conclusion: Iterative & incremental process No problem Generate ideas problem Make prototype Evaluate results playtest Iterative process diagram [FSH]