2. + OVERVIEW = KNOWING THE ENEMY (as3 and programming) - ALGORITHMIC THINKING - DATA STRUCTURES - AS3 SPECIFICS . moving stuff around . loop() . event listeners = MAKING A GAME!!!
3. KNOW YOUR ENEMY
4. + THINK == MACHINE = What is Algorithmic Thinking? - Emphasis on PROCESS not facts - How things work not what things are = Therefore... - Very Specific - Quantitative
5. YOU DO IT ALL THE TIME WHETHER YOU KNOW IT OR NOT.
6. + IMPROV JAZZ = What the hell? = To be a good improv jazz performer... - Understanding of Music Theory - Understanding of your instrument - Cooperation with other players
7. + IMPROV JAZZ = Understanding of Music Theory - Rules of the System = Understanding of your instrument - How to express yourself within the given rules and system = Cooperation with other players - Bits of code can talk to each other - Two heads is better than one
9. + WORKING TOGETHER = Object Oriented Programming - Basics - Inheritance = Snippets of Code must work together - Smart Programming - Efficient - Clean
11. + PLAYERS PLAYER moveSpeed: int = 5 throwSkill: int = 5 receiveSkill: int = 5 weight: int = 5 move() throw() receive() tackle()
12. + MORE PLAYERS - QUARTERBACK - OFFENSIVE LINEMAN . CENTER . GUARDS . TACKLES - RUNNING BACK . TAILBACK . FULLBACK - WIDE RECEIVER - TIGHT END
13. + MORE PLAYERS - QUARTERBACK . LEADER . THROWING . CAN RUN THE BALL, USUALLY DOESN'T QUARTERBACK extends Player moveSpeed: int = 6 throwSkill: int = 10 receiveSkill: int = 5 weight: int = 5 leadership: int = 10
14. + MORE PLAYERS - OFFENSIVE LINEMAN . PROTECTS QB . DOESN'T NOT HANDLE THE BALL . DOES NOT RUN THE FIELD OFF.LINEMAN extends Player moveSpeed: int = 4 throwSkill: int = 0 receiveSkill: int = 4 weight: int = 7 leadership: int = 0
15. + MORE PLAYERS - RUNNING BACK . RUN THE BALL DOWN THE FIELD . RARELY PASS . MEDIOCRE BLOCKER AND RECEIVER RUNNING BACK extends Player moveSpeed: int = 9 throwSkill: int = 4 receiveSkill: int = 7 weight: int = 6 leadership: int = 0
16. + MORE PLAYERS - WIDE RECEIVER . CATCH THE BALL . CAN BLOCK IF ANOTHER RECEIVER HAS POSESSION WIDE RECEIVER extends Player moveSpeed: int = 8 throwSkill: int = 3 receiveSkill: int = 10 weight: int = 6 leadership: int = 0
17. + MORE PLAYERS - TIGHT END . EITHER RECEIVE OR PROTECT TIGHT END extends Player moveSpeed: int = 6 throwSkill: int = 4 receiveSkill: int = 6 weight: int = 6 leadership: int = 0
18. + MORE PLAYERS - CHILDREN OF PLAYER (EXTENDS PLAYER) - INHERITS ATTRIBUTES AND FUNCTIONS TIGHT END moveSpeed: int = 6 throwSkill: int = 4 receiveSkill: int = 6 weight: int = 6 leadership: int = 0 WIDE RECEIVER moveSpeed: int = 8 throwSkill: int = 3 receiveSkill: int = 10 weight: int = 6 leadership: int = 0 RUNNING BACK moveSpeed: int = 9 throwSkill: int = 4 receiveSkill: int = 7 weight: int = 6 leadership: int = 0 OFF.LINEMAN moveSpeed: int = 4 throwSkill: int = 0 receiveSkill: int = 4 weight: int = 7 leadership: int = 0 QUARTERBACK moveSpeed: int = 6 throwSkill: int = 10 receiveSkill: int = 5 weight: int = 5 leadership: int = 10 PLAYER moveSpeed: int = 5 throwSkill: int = 5 receiveSkill: int = 5 weight: int = 5 move() throw() receive() tackle()
Hey everyone, I hope you all had a great spring break. It's refreshing to have such good weather with us right now. Makes me want to wake up early in the morning. I just want to take a minute to thank all of you for coming. It means a lot to Joe and I to see so many people interested in making games. We're here for you all, anyone who wants to make games but doesn't really know where to begin. In this workshop, we'll be covering one of the tools you'll most likely be using when making a digital game.
Here's a brief overview of what we'll be doing today. A lot of it will have to do with getting comfortable with programming in general. The more you know about programming, the better equipped you will be to tackle any game project. We'll go over Algorithmic Thinking, which is how to think like a computer. Then some very common data structures that are useful for games. Then finally going over some AS3 specific things you'll need to use. This section will be quite quick and dense... but not to fear. We'll be going an exercise together and building an actual game from the ground up for the majority of the time.
First, you must learn about programming. It may seem scary, but there is one way to think about programming in a way that the numbers and semi-colons won't matter anymore.
So how do we think like the machine? What is Algorithmic Thinking? Algorithmic Thinking is essential to becoming an efficient programmer. It's even more important for a game designer. As a game designer, you're not worrying about what things are but HOW they work. We're interested in the process of how at one point I'm at this side of the room, and then suddenly I'm over here. I don't care about that fact that I moved. It's about how that movement is happening. Basically, you constantly want to deconstruct things and understand them from the inside out. In a nutshell, Algorithmic Thinking is extremely specific and quantitative. In the design process, you can be lofty and say "Yes, this character will be able to jump." But for a game designer and programmer you'll need to know how high, how far, how long, and etc... Everything is defined.
Thankfully, we're all doing some sort of Algorithmic Thinking whether we know or like it. It's a naturally occurring thought process, but understanding why and how we do it is important to really harness it's power. Who has played chess? When playing chess, who has thought out a couple of moves and possibilities before your actually move your piece? That's Algorithmic Thinking! Your mind is following a set of RULES within a defined SYSTEM. You don't just move a piece however you like, you have options and specific ways in which you can move. To get good at the game, you have to calculate these moves in rapid succession.
Another way I like to look at it is with Improvisational Jazz. You're probably wondering what in the world that has to do with computers. Well, let me put it this way. In order to become a good improve jazz performer you need to know the following things: You'll need to know a bunch of Music Theory so you can bust out an awesome solo when your time comes. You'll need to know how to execute that theory with your chosen instrument. Finally, you'll need to cooperate with other players in your band. You need to set them up for solos and you need to look out for their signals too. So... really... what does this have to do with computers?
So firstly music theory... That is the rules you need to abide by when improving jazz. you can't just do whatever the hell you like. One, it'll sound terrible. Two, the other players will have no idea how to respond. It's a game. There are rules, there is a system. Code is similar, and you'll need to learn what its rules are. I like the jazz example because jazz is creative, right? Sometimes people think of programming and they think the opposite of creativity. Even though you're in a heavily defined system, there are ways to express yourself and do clever things. Again, it's just about using your instrument in the confines of music theory rules. Finally, cooperating with other players basically boils down to interaction. There are certain ways you will interact with your fellow bandmates as there are specific ways bits of code will communicate with other bits of code. In most cases, more interaction between players or bits of code means more efficiency. As they say, two heads is better than one.
Before we go into the nit picky details of a programming language like how to declare variables or set up a function, there are some bigger ideas that are crucial to Object Oriented Programming languages like AS3.
As I was saying with jazz, jazz musicians need to work together in order to produce good music. Different snippets of code must do the same thing to produce good games. When you have a good understanding of the underlying system of how Objects, these snippets of code, work together then it will not only make your program more efficient and make your own workflow more efficient too. Efficiency on the program end means it runs faster and uses less memory. Efficiency on the human side means you don't need to copy and paste a whole bunch of stuff or make really huge files that are thousands of lines long. That's a lot of code to look through no matter how well you comment!
But in order to figure out what the hell I was just talking about, let's talk about American Football. Specifically the offensive line. So when you're playing or watching football... what's on the field? Or game board as game designers would call it. <Anyone?> Well, we have players of course! <Yes! That's it!> We have players on the field!
Since players are on the field, we have our most basic kind of player right here. The format that this is in is called a Class diagram in the Unified Modeling Language. So this is our most basic Player object, a class. At the top we have the Class name, below that we have its global variables and finally the functions or methods. Basically we have its name, it's properties, and what it can do. So what I've done here is that I've thought what about what all football players do in a game. This is the most basic outline you can get. They move, throw, receive throws, they tackle, and they lead other players. Some players are better or worse at the things I described so how do we address those kinds of players?
This is a generic diagram of how players are set up in American Football. We'll be concentrating on the offensive team, the blue guys.
So in football, we all know that there's the quarterback. This guy is the leader. He's the one who calls the plays, or strategy, and he also gets the ball places usually by throwing it to someone else. Now we have our Quarterback class. There's one extra detail though, next to quarterback you can see &quot;extends Player&quot;. This means that everything that I had in player, Quarterback will have too! You can think of it as Quarterback being a child of Player. Since it's a child of player, it'll inherit its traits. Some things are different like throwSkill, which is 10. So things can be different in child classes, but the overall structure like moving and passing is exactly the same.
So in football, we all know that there's the quarterback. This guy is the leader. He's the one who calls the plays, or strategy, and he also gets the ball places usually by throwing it to someone else. Now we have our Quarterback class. There's one extra detail though, next to quarterback you can see &quot;extends Player&quot;. This means that everything that I had in player, Quarterback will have too! You can think of it as Quarterback being a child of Player. Since it's a child of player, it'll inherit its traits. Some things are different like throwSkill, which is 10. So things can be different in child classes, but the overall structure like moving and passing is exactly the same.
So here we have the running back. As their name entails, they run down the field, with the ball of course. What happens is that the QB makes a short pass to an open running back and they'll try to run past the defensive line. If they need to, the running back can block defensive players but rarely pass the ball once they have it. They're just thinking about running. So we've adjusted the stats as appropriate. Remember, running back is a child of Player so it still retains it's move(), pass() and all the other functions too! That means I don't need to copy and paste. This is good because if I change a small thing in the move() function, that means I have to dig through several files and make that same change. That's really annoying!
The wide receivers catch long passes from the QB. This means that they have impeccable receiving skills. In order to catch long passes, they should also be able to run far and quick so they have a pretty high move speed as well.
Finally are Tight Ends. This position basically fills in the gap wherever necessary in order to adapt to the defensive team's strategy. They'll catch if they need to, they'll tackle or block if they need to, they'll even run with the ball if they must. Their skills points are relatively balanced.
That's pretty much all I really need to do to make all these different kinds of players. I don't need to rewrite my move() or throw() function, not even copy and paste it because all these specific players I've created are CHILDREN of Player. Syntactically, we'd say that Running Back EXTENDS Player. Because these are children, they inherit their parent's genes--their public attributes and functions. This is efficient because if you suddenly need to change your tackle() function, you just need to do it once in Player. This also means the computer doesn't waste as much time reanalyzing duplicate lines of code. Takes up less memory, less time to parse etc...
The moral of the story is that inheritance and Object Oriented Programming is very powerful. You can see how this can make a game very simple to create. Let's say you want to make a simple Space Invaders like shooter. Basically you'll have two main classes: SpaceShip and Bullet. A SpaceShip could be your space ship or it could be the enemy space ship. They're basically the same, both shoot, both move around on the screen, both die when they get shot at. And you know what bullets are. We'll move onto our exercise now in actually making a simple game.
