I watched some episodes of the Lone Ranger today on TV, and not surprisingly, I thought about how this relates to video games.
What really struck me was how play-like the episodes were. When TV was brand new, nobody knew how to take advantage of that technology. People spoke obvious feeder lines to the audience, cameras shot from one angle, people came in and out of a set room, delivered lines, then left. All of these things were directly related to how people used previous media methods. The Lone Ranger had the exact kind of staging that plays did, and the pandering feeder lines came from the radio show style plot.
Now, its hard not to laugh at how not-mature these TV programs were in terms of utilizing their media form. The problem with the Lone Ranger wasn't that the plot was bad, it was that they were using the tricks of previous media to tell their stories. The obvious feeder dialog from stageplays and the non-stop dialog from radio programs are simply methods used because writers and producers didnt know any better at the time. They didn't understand the value of multiple camera angles or closeups on facial expressions during extended dialog because they only knew how to present a story in terms of what they had already seen. You can't close-up on someone or change views in a play, so why would they think to do this for TV?
When we talk about employing story in video games, we rely heavily on things like cutscenes or linear story plot. This is because like early TV producers, we don't know what to do with this new media form because we've only been exposed to the media that's around. There is a way to present plot in video games that is optimal for the new, distinct media form. We have yet to really distinguish that from existing media forms.
I'm sure we
can all think of what form of media would be best for any specific
story, and although we can certainly tell any story in any medium, James
Bond is definitely best told in movies, the Walking Dead is best told
through TV shows, and the Lord of the Rings was best captured in written
narrative. What story is it that video
games can tell better than other media?
It's a question that's worth considering, and--like other polished media forms--won't be answered overnight. With more experience in creating video games with narrative we will be able to iterate on the process and provide something that will allow us to express ourselves in ways that we could not do before. As soon as this happens, digital games will fulfill a need that will bring them the respect of all the media forms that we know and love.
Sunday, December 9, 2012
Wednesday, November 21, 2012
Mid-Track Crisis
Today I spoke to Roger, Corrinne, and Bob about the feasibility of me changing tracks from an engineer to a producer. This post will kind of be a brain dump of all the things I'm worried about and considering for this transition.
First, I'll talk about why I wanted to (and am almost certainly going to) switch tracks in the first place. The original appeal of the EAE program was the promise of crafting any idea into an actual playable game that I could modify and re-craft to be even more fun. I've been doing stuff like this my entire life, and after being in the program for a semester it appears that although everyone has a say in what the game is, its the producers job to make sure that the vision is concise and clear, and I love that.
I just really love public speaking. The thought of giving game pitches to people about a game that I made and I've put all kinds of work into is so exciting. Looking back on my life, I've really put myself in positions where I can public speak as much as I possibly could, and I've never had any feelings but excitement before, during, and after any major presentations I've given. Producers give presentations, I love to give presentations. Great.
I love to see other peoples strengths and build teams around those. This is probably my favorite leadership skill that I have--the ability to recognize the utility of any person and play to those strengths. I definitely have weaknesses, too, but I feel that this is one of my strongest abilities. The ability to see the value in any and every team member. I've been a team leader of plenty of things that people were only half-heartedly interested in, and being in charge of something that everyone actively wants to be a part of is face-meltingly enticing.
Face-meltingly. You heard me.
Of course, changing to a producer has brought up concerns, as well. I talked with my wife Janice quite a bit about the change and discussed the pros and cons of changing tracks. The biggest concern was losing the degree that had originally attracted me to the program: the coveted CS master degree. I can't think of a more employable person than a mechanical engineer who also is a masters student in computer science. Switching tracks would lessen this ungodly employability, but as Zac Truscot pointed out, I could always get back into the engineering scene by using this experience as leadership training. If I wanted to switch back. Game development is pretty insanely awesome.
With the biggest concern out of the way, the only thing left are minor issues. For instance, would I always be shuffled in to this role of "not-really-a-producer"? Would my peers think of me as a wannabe producer or would they actually see me differently? Would seeing me differently be a good thing or a bad thing? I don't want anybody to be weirded out by the transition, and it only slightly feels like I just asked to be everybody's boss and Roger said "sure". I could understand resentment at having me be your next team leader.
There's a lot of things to think about, but one thing that I know for sure is that there's definitely more pluses than minuses, and the minuses are worth dealing with to get involved in something that I'm absolutely going to love.
First, I'll talk about why I wanted to (and am almost certainly going to) switch tracks in the first place. The original appeal of the EAE program was the promise of crafting any idea into an actual playable game that I could modify and re-craft to be even more fun. I've been doing stuff like this my entire life, and after being in the program for a semester it appears that although everyone has a say in what the game is, its the producers job to make sure that the vision is concise and clear, and I love that.
I just really love public speaking. The thought of giving game pitches to people about a game that I made and I've put all kinds of work into is so exciting. Looking back on my life, I've really put myself in positions where I can public speak as much as I possibly could, and I've never had any feelings but excitement before, during, and after any major presentations I've given. Producers give presentations, I love to give presentations. Great.
I love to see other peoples strengths and build teams around those. This is probably my favorite leadership skill that I have--the ability to recognize the utility of any person and play to those strengths. I definitely have weaknesses, too, but I feel that this is one of my strongest abilities. The ability to see the value in any and every team member. I've been a team leader of plenty of things that people were only half-heartedly interested in, and being in charge of something that everyone actively wants to be a part of is face-meltingly enticing.
Face-meltingly. You heard me.
Of course, changing to a producer has brought up concerns, as well. I talked with my wife Janice quite a bit about the change and discussed the pros and cons of changing tracks. The biggest concern was losing the degree that had originally attracted me to the program: the coveted CS master degree. I can't think of a more employable person than a mechanical engineer who also is a masters student in computer science. Switching tracks would lessen this ungodly employability, but as Zac Truscot pointed out, I could always get back into the engineering scene by using this experience as leadership training. If I wanted to switch back. Game development is pretty insanely awesome.
With the biggest concern out of the way, the only thing left are minor issues. For instance, would I always be shuffled in to this role of "not-really-a-producer"? Would my peers think of me as a wannabe producer or would they actually see me differently? Would seeing me differently be a good thing or a bad thing? I don't want anybody to be weirded out by the transition, and it only slightly feels like I just asked to be everybody's boss and Roger said "sure". I could understand resentment at having me be your next team leader.
There's a lot of things to think about, but one thing that I know for sure is that there's definitely more pluses than minuses, and the minuses are worth dealing with to get involved in something that I'm absolutely going to love.
Tuesday, November 20, 2012
Unbridled Fun
Our new project is beginning, and its a large-group Indie-themed project where we're not allowed to use any AAA memes or themes from games. The purpose of the game we're supposed to make is entertainment.
Wow, you might think, Jake really lucked out! A large team making a game whose only purpose is fun?
Yes and no.
Yes, I did luck out because my team is totally awesome. Andrew, Zeph, Cody, Imaginary Jason, Broken Jason, Nick, Damian, and Yang. I don't think I could ask for a more baller team if I paid somebody. Everyone on the team is confident and hardworking, and I look forward to being a part of this.
No, I did not luck out because despite what you might think, large teams and barely any restrictions do not make the game design easier. They make it much, much harder. Every team yesterday came out of their brainstorming session with a hazy look and not much to show for it. Having a large team with no restrictions means that you have to slog through all the ideas that every member of your large team wants to and doesn't want to do before reaching even a beginning idea for what you want your game to be.
Don't get me wrong, I definitely added my share of unused ideas to the pot that we collectively discarded. It's just a hard situation. After about three hours we came up with a physics based Dynasty Warrior based game where you can explode enemies or push/pull them to do damage to them. It should be fun, and Unity looks really easy to code with.
...almost too easy.
I'm concerned about memory management with Unity after watching Triston make a ball jump around by simply dragging a ball into the game world and pressing 'go'. We'll see how things work out.
More on creating a custom path for myself through the EAE course later.
Wow, you might think, Jake really lucked out! A large team making a game whose only purpose is fun?
Yes and no.
Yes, I did luck out because my team is totally awesome. Andrew, Zeph, Cody, Imaginary Jason, Broken Jason, Nick, Damian, and Yang. I don't think I could ask for a more baller team if I paid somebody. Everyone on the team is confident and hardworking, and I look forward to being a part of this.
No, I did not luck out because despite what you might think, large teams and barely any restrictions do not make the game design easier. They make it much, much harder. Every team yesterday came out of their brainstorming session with a hazy look and not much to show for it. Having a large team with no restrictions means that you have to slog through all the ideas that every member of your large team wants to and doesn't want to do before reaching even a beginning idea for what you want your game to be.
Don't get me wrong, I definitely added my share of unused ideas to the pot that we collectively discarded. It's just a hard situation. After about three hours we came up with a physics based Dynasty Warrior based game where you can explode enemies or push/pull them to do damage to them. It should be fun, and Unity looks really easy to code with.
...almost too easy.
I'm concerned about memory management with Unity after watching Triston make a ball jump around by simply dragging a ball into the game world and pressing 'go'. We'll see how things work out.
More on creating a custom path for myself through the EAE course later.
Converse...Video blog?
Even though I haven't written in a while, it feels kind of like I've been keeping up with this blog because I've had a camera in my face for the last month.
Week 1:
http://www.youtube.com/watch?v=2DRN8p6Nksc&feature=relmfu
Week 2:
http://www.youtube.com/watch?v=vhYbDOWAF8E&feature=youtu.be
Week 3:
http://www.youtube.com/watch?v=LN7e6ijJtfc&feature=relmfu
Week 4:
http://www.youtube.com/watch?v=-TQejNMgm9U&feature=youtu.be
Week 1:
http://www.youtube.com/watch?v=2DRN8p6Nksc&feature=relmfu
Week 2:
http://www.youtube.com/watch?v=vhYbDOWAF8E&feature=youtu.be
Week 3:
http://www.youtube.com/watch?v=LN7e6ijJtfc&feature=relmfu
Week 4:
http://www.youtube.com/watch?v=-TQejNMgm9U&feature=youtu.be
Monday, September 17, 2012
Educational Games
We got our new clients for the next four weeks today.
As promised, Bob Roemer came in and wanted a game about Thermodynamics. This is a hard problem, and there are a lot more issues with creating a game that requires calculations than I had thought before I came into the EAE program.
First, mandating that a game requires calculation presents problems. The biggest problem is that requiring calculations is essentially game-ified story problems that are presented slightly more fun than just beating your head against a calculator. This problem leads to the second problem, which is that no matter how you present them, story problems about thermodynamics aren't fun. At all.
Now we're stuck holding the bill of a game that is doomed to be marginally fun at best, but this seems to be the fate of almost every one of the mechanical engineering presenters that we had today. This isn't surprising. Coming from a mechanical engineering background, I'm sure that they gave us as many constraints as possible to help guide us to the kind of thing that they wanted. This was intended to help, I'm positive, but the result is several already finished products that basically need some better art slapped on top of them. Despite their best intentions, the practically finished game concepts that we've been told we can't work out of are already not fun.
On the positive side, these games don't require being as inherently fun as the Beehive Cheese game, say. People won't be playing any of these educational games for fun, they'll be playing the games because it's part of their homework. This additional incentive means that we don't have to make the games fun enough to want to keep playing for the sake of playing, but requiring calculations is still a remarkably limiting factor.
There are positive approaches to requiring calculation. I feel that games that would be optimized with calculation should start off in a ballpark estimate that tends to work. As difficulty increases, the allowable tolerances for acceptable answers would decrease so that the player could either spend several dozen tries trying to get the exact answer or simply try to calculate the exact answer by hand. This concept of "if I were clever enough to eyeball this I could do it" makes the player feel like they're *choosing* to calculate, which in reality is the only feasible solution to the problem. I think this would be a great way to ease students into a calculation-intense game.
As promised, Bob Roemer came in and wanted a game about Thermodynamics. This is a hard problem, and there are a lot more issues with creating a game that requires calculations than I had thought before I came into the EAE program.
First, mandating that a game requires calculation presents problems. The biggest problem is that requiring calculations is essentially game-ified story problems that are presented slightly more fun than just beating your head against a calculator. This problem leads to the second problem, which is that no matter how you present them, story problems about thermodynamics aren't fun. At all.
Now we're stuck holding the bill of a game that is doomed to be marginally fun at best, but this seems to be the fate of almost every one of the mechanical engineering presenters that we had today. This isn't surprising. Coming from a mechanical engineering background, I'm sure that they gave us as many constraints as possible to help guide us to the kind of thing that they wanted. This was intended to help, I'm positive, but the result is several already finished products that basically need some better art slapped on top of them. Despite their best intentions, the practically finished game concepts that we've been told we can't work out of are already not fun.
On the positive side, these games don't require being as inherently fun as the Beehive Cheese game, say. People won't be playing any of these educational games for fun, they'll be playing the games because it's part of their homework. This additional incentive means that we don't have to make the games fun enough to want to keep playing for the sake of playing, but requiring calculations is still a remarkably limiting factor.
There are positive approaches to requiring calculation. I feel that games that would be optimized with calculation should start off in a ballpark estimate that tends to work. As difficulty increases, the allowable tolerances for acceptable answers would decrease so that the player could either spend several dozen tries trying to get the exact answer or simply try to calculate the exact answer by hand. This concept of "if I were clever enough to eyeball this I could do it" makes the player feel like they're *choosing* to calculate, which in reality is the only feasible solution to the problem. I think this would be a great way to ease students into a calculation-intense game.
Monday, September 10, 2012
Dry Runs
We just got finished with dry run presentations today.
This past week we've been working to get our game working, and its surprising how accelerated game development becomes when youre familiar with the language. I'm not terribly excited to move on to another language because I finally feel like I'm understanding MOAI, but having a language with *any* documentation should be a lot better. Starting over from square one with a new language won't be exciting.
AJ presented and everyone ripped his presentation style apart, which I didn't totally agree with. It's true, he could have more eye contact, but I really think that his enthusiasm outshines every other producer that presented. Its the kind of presentation I would have given--with less eye contact.
I'm excited to see what Katie says when she gets here. I think that our game has nailed the demographic game style more than any other game--fun instantly, infinite replayability, and almost mindless control (the kind that you can play in a grocery store line). This should be pretty good.
I don't know if I'm allowed to go onto tangents on this blog, but recently story in games has approached the forefront of my musings. With Laurie's fascination with minecraft and the player-generated stories that crop up and Dad's fabrication of several religions on the private server, I really think that deep, interesting story is the key to making a complex game enjoyable and satisfying. I'll keep thinking about this.
This past week we've been working to get our game working, and its surprising how accelerated game development becomes when youre familiar with the language. I'm not terribly excited to move on to another language because I finally feel like I'm understanding MOAI, but having a language with *any* documentation should be a lot better. Starting over from square one with a new language won't be exciting.
AJ presented and everyone ripped his presentation style apart, which I didn't totally agree with. It's true, he could have more eye contact, but I really think that his enthusiasm outshines every other producer that presented. Its the kind of presentation I would have given--with less eye contact.
I'm excited to see what Katie says when she gets here. I think that our game has nailed the demographic game style more than any other game--fun instantly, infinite replayability, and almost mindless control (the kind that you can play in a grocery store line). This should be pretty good.
I don't know if I'm allowed to go onto tangents on this blog, but recently story in games has approached the forefront of my musings. With Laurie's fascination with minecraft and the player-generated stories that crop up and Dad's fabrication of several religions on the private server, I really think that deep, interesting story is the key to making a complex game enjoyable and satisfying. I'll keep thinking about this.
Tuesday, September 4, 2012
PAX and MOAI pounding
I think I may have forgotten to post last week.
Whether or not this blog is supposed to be exclusively about game development, I can't sit idly and not mention my incredible trip to PAX this past weekend. Seeing game development through the eyes of a future programmer makes things that much more exciting. I'm definitely in the right place.
Earlier today we met to combine code for the different things that we've been working on. Chris pointed out a boolean condition to the mouseUp/mouseDown detection problem (namely, swap the boolean upon lifting or pressing the mouse only) and things are going really smoothly. Jason's collision code merged with my flight and background code without any trouble at all.
Sherly is doing a whole lot with the menus and is currently writing code to save a high score to a file and retrieve it. It seems like every time we get together, we always make progress. It's slow, and the lack of documentation on MOAI makes it difficult, but there are examples to work from. I've completely stopped trying to find documentation in lieu of just mucking through already working examples, and even half of those are obsolete due to how new MOAI is. Its very frustrating, but we're making it work.
The intro to C++ programming relies heavily on tortoise SVN. It seems extremely useful, but I never seem to know if I'm using it the way that its supposed to be used. Almost every time I try to complete an assignment by uploading it to the repository I end by saying "Um.... I think that's what I was supposed to do...". Joe's teaching style is a little bit of a brain-dump, but I can't think of a concise way to criticize it. Once I figure out exactly what is difficult about his teaching style, I'll fill out a suggestion card. He's a really great guy, and I'm confident any suggestions I think up will benefit us both and he won't take it the wrong way.
Whether or not this blog is supposed to be exclusively about game development, I can't sit idly and not mention my incredible trip to PAX this past weekend. Seeing game development through the eyes of a future programmer makes things that much more exciting. I'm definitely in the right place.
Earlier today we met to combine code for the different things that we've been working on. Chris pointed out a boolean condition to the mouseUp/mouseDown detection problem (namely, swap the boolean upon lifting or pressing the mouse only) and things are going really smoothly. Jason's collision code merged with my flight and background code without any trouble at all.
Sherly is doing a whole lot with the menus and is currently writing code to save a high score to a file and retrieve it. It seems like every time we get together, we always make progress. It's slow, and the lack of documentation on MOAI makes it difficult, but there are examples to work from. I've completely stopped trying to find documentation in lieu of just mucking through already working examples, and even half of those are obsolete due to how new MOAI is. Its very frustrating, but we're making it work.
The intro to C++ programming relies heavily on tortoise SVN. It seems extremely useful, but I never seem to know if I'm using it the way that its supposed to be used. Almost every time I try to complete an assignment by uploading it to the repository I end by saying "Um.... I think that's what I was supposed to do...". Joe's teaching style is a little bit of a brain-dump, but I can't think of a concise way to criticize it. Once I figure out exactly what is difficult about his teaching style, I'll fill out a suggestion card. He's a really great guy, and I'm confident any suggestions I think up will benefit us both and he won't take it the wrong way.
Monday, August 20, 2012
First Game
First day of classes today.
We had a guest visit from the Beehive Cheese Company with a request to make a casual iPhone game that would appeal to their core demographic: 24-45 year old fancy-cheese buying women. Games for this demographic can't really be overly strategy based or excessively complicated, and have to be fun enough for people to want to keep playing while simultaneously branding different products from BCC.
We discussed extremely different styles of game mechanics, settling finally on a launch-style game, similar to Angry Birds but with more flight control and a longer path. A bee would be launched out of a beehive with a huge wheel of cheese and the player would attempt to intersect floating BCC ingredients in the air. Tapping the screen would deplete the on-screen "boost" power to make the bee fly higher. The level would start with a specific cheese requirement (eg: you're making Barely Buzzed cheese, collect 10 coffee and 5 lavender) and the player would progress to the next level if he had "collected" the minimum threshold of the specific items he was looking for. Unrelated items would count towards points for boost powers, and landing on the ground would end the level. Initially, landing on a cow instead of the ground would launch you back into the air instead of ending the level, and the frequency of cows would diminish as the level progressed.
Apparently we're also required to use the MOAI SDK, which is not inherently intuitive and has a lot of the other engineers up in arms about how to use it. It seems initially that you have to deploy every program you create to the cloud, which implies that any graphics would have to be loaded there as well. Disk space would disappear rapidly if this was actually the case, and it would become a freemium model really quickly as only 50 MB are allotted to free-level programmers.
We had a guest visit from the Beehive Cheese Company with a request to make a casual iPhone game that would appeal to their core demographic: 24-45 year old fancy-cheese buying women. Games for this demographic can't really be overly strategy based or excessively complicated, and have to be fun enough for people to want to keep playing while simultaneously branding different products from BCC.
We discussed extremely different styles of game mechanics, settling finally on a launch-style game, similar to Angry Birds but with more flight control and a longer path. A bee would be launched out of a beehive with a huge wheel of cheese and the player would attempt to intersect floating BCC ingredients in the air. Tapping the screen would deplete the on-screen "boost" power to make the bee fly higher. The level would start with a specific cheese requirement (eg: you're making Barely Buzzed cheese, collect 10 coffee and 5 lavender) and the player would progress to the next level if he had "collected" the minimum threshold of the specific items he was looking for. Unrelated items would count towards points for boost powers, and landing on the ground would end the level. Initially, landing on a cow instead of the ground would launch you back into the air instead of ending the level, and the frequency of cows would diminish as the level progressed.
Apparently we're also required to use the MOAI SDK, which is not inherently intuitive and has a lot of the other engineers up in arms about how to use it. It seems initially that you have to deploy every program you create to the cloud, which implies that any graphics would have to be loaded there as well. Disk space would disappear rapidly if this was actually the case, and it would become a freemium model really quickly as only 50 MB are allotted to free-level programmers.
Subscribe to:
Posts (Atom)