It's been more than a year since the last one. Time for a new Active Sketch.
I made this to test out an idea my coworker suggested for indirect control through gravity wells.
In this little physics prototype, you can click to add planets and drag them around, and your little face person will zoom around, orbiting them according to Newton's laws of gravity.
Can you imagine playing with this on a touch screen?
Nothing fancy. Just a little experiment. Turns out that gravity among all these planets is a chaotic system, where it's almost impossible to predict where the orbiting face will go next. That might make this a little too confusing for a game, though who knows - maybe if you slow it down and draw motion trails showing the future paths of all the objects, it might be pretty interesting.
Still, I think springs might make a better physics-based mechanic than gravity, at least for a real-time action game.
So this Active Sketch was pretty quick to make - maybe an hour to get the basic mechanic working, and another hour to polish it up for release. This is encouraging, because it means I might be able to make more of these, even in the limited time I have now that I have a job as a game programmer.
I don't want to make any promises, but with any luck hopefully you'll be seeing a lot more of these little prototypes from me in the near future. I'm looking forward to it. :)
2011/04/17
2011/03/06
Interview with a Game Programmer
One of my cousins asked to interview me for a school project, since I'm a real game programmer now! I went all-out on these questions and thought I'd share them here, so if you know anyone who's considering a career in games or programming, feel free to send them over for a bit of behind-the-scenes with a recent college grad who has just broken into the game industry.
Needless to say, the views expressed here are my own and do not necessarily reflect the views of Fugazo, Inc.
What is your name and job title?
My name is Alex Cho Snyder and I work as a Game Programmer at the casual game development studio Fugazo, Inc.
How long have you had this job?
I started this job on August 9th, 2010, so I've been working at Fugazo for about six months.
Please explain what a typical day of work is like for you.
I have breakfast at home, pack a lunch, and take the bus downtown to the office. I usually get there around 9:30am, but time is pretty flexible there, so it's no problem if you get there a bit late. I go to my desk - all our desks are together in the same big open-studio-style room - turn on my computer and wait for it to start up so I can check my work email, download the latest images and files that my teammates have added to the project from the SVN repository, and start up Visual Studio, which is kind of like Microsoft Word for programming code. I also look through my work notebook to refresh my memory about what exactly I've been working on and what I was thinking about the day before.
I work on a team of about three or four other people, making Fugazo's next hidden-object adventure game. There are about two other such teams at Fugazo, each working on a different game. Each team has one designer, one programmer, and two or three artists. I'm a programmer. I like to think of it in comparison to building houses. The designer is the architect, who draws the plans for the house and manages the overall process. The artists are the ones who prepare the pieces of the house - boards, doors, roofs, siding, etc. And the programmer - me - is the contractor putting the pieces together and actually building a functional house. I like building things, so it works out. But I really don't like remodels, where I'm taking an old building that someone else made and have to tear out old parts of the building and fix it up and add new rooms and features. You never know if one wall or pillar is okay to take out or if the whole building will collapse when you do. That's the annoying part.
In more specific terms, my designer will come to me with a feature or puzzle or something that he wants me to add to the game, and describe exactly what he wants while I ask questions until I feel like I understand completely. I usually like to write out the details of the task in my notebook by hand, because it helps me wrap my brain around the problem. Then I'll either start writing ideas for possible solutions, or look through the existing code of the game to get a better understanding of how the solution will have to fit in. Then I start actually writing code, and testing it out. Most of my time is spent going back and forth between thinking about the problem, reading code, and writing code. If I get stuck I'll ask the designer for clarification, or talk to our lead programmer to ask how he would recommend solving the problem. Once I've got something actually working on screen, I'll show the designer and ask him for feedback. Either he'll suggest more things to change, or he'll give me the next feature he wants me to build.
At noon we have an hour for lunch, and I often walk down to a nearby alternative school to volunteer-teach game programming to some middle-school kids. After that I'm back to work, until around 5:30pm when everyone leaves and I take the bus home or to martial arts practice for exercise.
What have you enjoyed most about your occupation?
That is a hard question for me to answer. I love thinking of ideas for games, and hashing out designs with teammates, but as a programmer that is something I am rarely involved in directly. In my role as a programmer, my enjoyment comes from exercising my near-magical ability to create imaginary worlds that live inside a computer screen. When I have gained enough understanding and familiarity with my tools that this process is no longer a confusing struggle but a mildly stimulating problem to solve, I find this very enjoyable. This usually happens when I am asked to create a smaller puzzle within a larger adventure game, where I can visualize the end result I want and then figure out how to actually build it with computer code. When things are going smoothly, I can go from start to finish in this process within a day or two.
I like seeing the fruits of my labor up on the computer screen - the quicker and more immediate, the better. I like to take something that works, that I can see and play around with, and tweak it and adjust it until it's just right. It is very rewarding to me to see and appreciate and savor this thing I have created, and when I am deprived of that gratification for too long I can easily become frustrated. I'm quite stubborn, so I don't give up when things take a long time to sort out. That doesn't mean I have to like it, though! :p
Do you believe most of your fellow colleagues or workers enjoy their work? Why?
I think they do. But not necessarily in the way you might assume. Many people mistakenly conflate the fun of playing games with the hard work of making them. I like to compare the process of game development to cooking or baking. Most people love to eat pastries and cookies and donuts, just like most people enjoy playing games. But not everyone likes to bake those cookies, and not everyone likes to make games. If you want to become a baker, it certainly helps to like eating pastries. But it's not enough.
Some game companies are more like donut factories. They are not fun places to work. Fugazo, where I work, is more like a successful neighborhood bakery. The work isn't amazingly fun, but it's usually interesting, and the people are nice, and it's not a bad place to be all day. And at the end of a project, after a few months, you have a finished game that's pretty cool and you can feel proud of it and show your friends and family and all that. And you get to think about games all the time.
If you could change anything about your occupation what would it be?
If I could make games without ever having to sit at a desk and stare at a computer screen, I would. If I could run around in a virtual forest, climb inheritance trees and swing from conditional branches, build towers with blocks of code, and just use my physical body and my stereoscopic vision and my musical ears and my agile primate fingers, I would be so much happier. I love plants; I love being outside. I also love the ability to create virtual worlds that other people can experience, through computers. But every minute that I spend in front of a computer screen is a sacrifice that I make in exchange for this power to shape (virtual) reality.
More realistically, if I never had to renovate another programmer's poorly encapsulated user interface code, that would be awesome. Most frustrating part of my job right there. Also, if I had more teamwork throughout the day, I think I would enjoy that. I love collaboration, and I get just enough of it to avoid feeling unbearably lonely throughout the day, but I really get very little. There's something called pair programming where two people share a computer and take turns writing code and observing, and I've done that a few times in school and I think I'd very much like to do that again. However, it's obviously not as feasible in a small company like Fugazo where each game has only a single programmer to work on it.
Have you gone back for more educational training since you began the job?
Nope. For me, working at this job is all the educational training I need! It has been at least as educational as an equivalent time at school was, in the six months I've been at Fugazo. In computer programming, school can be essential to getting started, but once you're actually working, you should be learning a lot as you gain experience and your company starts branching out to new technologies and platforms. At the least, you can learn a lot from your own side projects as well.
What educational background do you have?
I graduated from the University of Washington with a Bachelor's degree in Computer Science. It took me a little less than five years at the UW to decide on my major, take all my required classes, and graduate. Throughout college, however, I had a summer internship or two working as a programmer and also made quite a few of my own games on the side, which is crucial if you're trying to get a job after graduating. Just a Computer Science degree doesn't cut it. You need to have experience working at a programming job, at least as an intern, and show that you have the passion, skill, and discipline to make your own games in your free time.
If you won the lottery and did not have to work, would you? Explain.
For a while, at least. ;) I decided to look for a job last summer so I could earn money, spend my days working on a team instead of by myself, and get experience learning from people who know what they're doing instead of fumbling around on my own. The lottery would only take care of one of those things. My life's work is to change the world through games. The most important thing I can do right now is to hone my skill at designing and programming games, and become fluent in all other aspects of the process as well. I will work at a company for as long as I need to until I'm ready to strike out on my own and form my own team, and I can't imagine finding a better place for that than Fugazo right now. A lot of game companies are not fun places to work. Fugazo is a notable exception.
What kind of strategies do you use when your job gets stressful?
Programming is often frustrating and can easily get stressful if you are not careful. I find it important to take breaks whenever I am really stuck or not thinking clearly, and I find that taking a walk right before lunch is very helpful in clearing my head. I also have started giving myself permission - with my boss's encouragement - to take short naps when I feel sleepy, especially in the afternoon. When it comes to jobs like programming that consist almost entirely of difficult problem-solving, it is often much more efficient to take a twenty-minute nap and come back refreshed than to fight back sleep deprivation for three hours without getting anything done. As with any sort of activity that involves sitting at a computer and staring at a screen all day, I've also found it very helpful to take a few minutes every so often to get up and move around, do some handstands, stretch, get my blood flowing, and help loosen whatever mental rut I might have gotten into while hunched over at my desk.
In your career field, is it difficult to balance work with home/family or personal life?
The game industry is one of the most notorious when it comes to poor work-life balance. This is a problem that is slowly improving, but it is definitely a real concern. Many companies, because of poor scheduling, can have months of forced "crunch time" at the end of a project, where people are working evenings, even weekends, continuously until the game is finished. Obviously, this is a very bad thing and it is arguably counter-productive in the long run, but many companies still do it. Even at Fugazo, where I work now, there may be a week or two of crunch at the end of a project, where I stay late in the evenings, but I've never worked weekends. Even then, no one is forcing me to stay late - I choose to keep working because I have a long list of things I want to get done, and I tend to be a perfectionist about these things. And I'll usually be the only one working late on most occasions, since no one is forced to crunch.
Outside of extreme circumstances like crunch time, I do often struggle to balance work and personal life. I wouldn't necessarily attribute this to the game industry itself. I think this has more to do with my inexperience (I've been working full-time for less than a year) and my tendency to cram way more things into my life than I could reasonably have time for. Though maybe the game industry tends to attract people like me anyway, so who knows!
What was it like when you went to high school? What kind of career planning did you have in high school?
I started high school about eight years ago. Back then, I wasn't thinking about jobs at all, but I knew that I wanted to do something with games. At the time I was doing a lot of programming on the graphing calculators we used in math class, making little games and releasing them online. I was also starting to read about using games for education and social change and became inspired to make that my life's work. As it turns out, those were the perfect things to be doing if I later wanted to start a career in game development!
What do you feel is most important when choosing a career?
There are a lot of ways to think about this question. One approach that I like is to think of something that you could see yourself getting really good at, if you spent the next ten or twenty years doing it for a living. That doesn't mean something you are already good at, necessarily, but something that you could see yourself learning to get really good at. I started learning to make games about ten years ago. The reason I choose to make games for a living now is not that I'm particularly good at it now, but I could see myself becoming really good at designing and making games over the next ten years. And that has less to do than the skills I currently have, and more to do with my passion and what I'm excited about and what I enjoy doing and learning and thinking about in my free time.
If you really love to do something, chances are that you could get really good at it - that if you kept doing it for a living over the next ten years, you wouldn't get bored and drop out - you'd keep learning and exploring and getting better and better as time goes on. I wouldn't suggest that you think about money right away. The jobs that tend to make a good amount of money are the jobs where you can keep getting better and better, where someone who is really good, with a lot of experience, can be worth ten or a hundred times what someone might be worth when they're just starting out. Like programming. Or game design. And you're going to have a hard time getting better and better unless you really love doing what you're trying to do. So try a bunch of things, find out what you love to do, and then ask yourself, "Which of these things could I really become good at, if I did this for a living for the next ten years?" Start there.
What advice do you have for me as I think about my future education and career plans?
Explore! Try lots of things, read about lots of things, ask lots of people about the things they do, and follow your curiosity when something attracts your interest. I was in fourth grade when I first learned that it was possible to make your own computer games. Before that, I guess I just assumed they spontaneously materialized in the store, fully formed, like action figures or LEGO sets. But once my eyes were opened to this possibility, I started reading every book I could find about how to make games, buying educational software, signing up for programming classes. At the time I had no idea what I was doing so my efforts were surprisingly ineffective, but I was persistent. I just wouldn't give up. And this interest gradually grew from a drip and a trickle here and there into a full-fledged flood of obsession that has significantly shaped my life and taken me to where I am right now.
But game development was not the only field that caught my interest. In high school, for example, I read tons of books on biology, philosophy, and how the mind works, just because I was so fascinated by these subjects. I thought I'd end up studying evolutionary biology or psychology or neuroscience in college, even though I ended up in computer science. And there's nothing wrong with that. In middle school I was big into music, and I started learning to make bamboo flutes in high school. Throughout the last several years I've been doing a lot of martial arts practice. And I'm still working as a programmer. But the key is to keep exploring. Be curious. There are so many things you could do with your life. Your life's work and passion may turn out to be something you've never even heard of yet. Before fourth grade, I'd certainly had no idea that I could make a living making games. If I hadn't been willing to explore, I would never have found this path.
And, if you want to get a job in the game industry, the best thing you can do right now is start making games. I made my first computer game in sixth grade. It wasn't a great game, but it was something, and I learned a lot in making it. And more importantly, after that I made another one. And another one. And another one. If you don't know how to make computer games, go and find out how. Look online, read books, take classes - whatever you can find. There are so many more resources out there now than there were ten years ago when I was starting out. Download a free tool like Game Maker to get started - you don't even need to learn programming. Or make board games, and test them out with your friends - no programming required. Just make games, and keep making games, and by the time you are actually trying to convince someone to hire you, you will be able say, "Look at this. I made this. And this, and this, and this."
If you want to make games, make games.
Needless to say, the views expressed here are my own and do not necessarily reflect the views of Fugazo, Inc.
What is your name and job title?
My name is Alex Cho Snyder and I work as a Game Programmer at the casual game development studio Fugazo, Inc.
How long have you had this job?
I started this job on August 9th, 2010, so I've been working at Fugazo for about six months.
Please explain what a typical day of work is like for you.
I have breakfast at home, pack a lunch, and take the bus downtown to the office. I usually get there around 9:30am, but time is pretty flexible there, so it's no problem if you get there a bit late. I go to my desk - all our desks are together in the same big open-studio-style room - turn on my computer and wait for it to start up so I can check my work email, download the latest images and files that my teammates have added to the project from the SVN repository, and start up Visual Studio, which is kind of like Microsoft Word for programming code. I also look through my work notebook to refresh my memory about what exactly I've been working on and what I was thinking about the day before.
I work on a team of about three or four other people, making Fugazo's next hidden-object adventure game. There are about two other such teams at Fugazo, each working on a different game. Each team has one designer, one programmer, and two or three artists. I'm a programmer. I like to think of it in comparison to building houses. The designer is the architect, who draws the plans for the house and manages the overall process. The artists are the ones who prepare the pieces of the house - boards, doors, roofs, siding, etc. And the programmer - me - is the contractor putting the pieces together and actually building a functional house. I like building things, so it works out. But I really don't like remodels, where I'm taking an old building that someone else made and have to tear out old parts of the building and fix it up and add new rooms and features. You never know if one wall or pillar is okay to take out or if the whole building will collapse when you do. That's the annoying part.
In more specific terms, my designer will come to me with a feature or puzzle or something that he wants me to add to the game, and describe exactly what he wants while I ask questions until I feel like I understand completely. I usually like to write out the details of the task in my notebook by hand, because it helps me wrap my brain around the problem. Then I'll either start writing ideas for possible solutions, or look through the existing code of the game to get a better understanding of how the solution will have to fit in. Then I start actually writing code, and testing it out. Most of my time is spent going back and forth between thinking about the problem, reading code, and writing code. If I get stuck I'll ask the designer for clarification, or talk to our lead programmer to ask how he would recommend solving the problem. Once I've got something actually working on screen, I'll show the designer and ask him for feedback. Either he'll suggest more things to change, or he'll give me the next feature he wants me to build.
At noon we have an hour for lunch, and I often walk down to a nearby alternative school to volunteer-teach game programming to some middle-school kids. After that I'm back to work, until around 5:30pm when everyone leaves and I take the bus home or to martial arts practice for exercise.
What have you enjoyed most about your occupation?
That is a hard question for me to answer. I love thinking of ideas for games, and hashing out designs with teammates, but as a programmer that is something I am rarely involved in directly. In my role as a programmer, my enjoyment comes from exercising my near-magical ability to create imaginary worlds that live inside a computer screen. When I have gained enough understanding and familiarity with my tools that this process is no longer a confusing struggle but a mildly stimulating problem to solve, I find this very enjoyable. This usually happens when I am asked to create a smaller puzzle within a larger adventure game, where I can visualize the end result I want and then figure out how to actually build it with computer code. When things are going smoothly, I can go from start to finish in this process within a day or two.
I like seeing the fruits of my labor up on the computer screen - the quicker and more immediate, the better. I like to take something that works, that I can see and play around with, and tweak it and adjust it until it's just right. It is very rewarding to me to see and appreciate and savor this thing I have created, and when I am deprived of that gratification for too long I can easily become frustrated. I'm quite stubborn, so I don't give up when things take a long time to sort out. That doesn't mean I have to like it, though! :p
Do you believe most of your fellow colleagues or workers enjoy their work? Why?
I think they do. But not necessarily in the way you might assume. Many people mistakenly conflate the fun of playing games with the hard work of making them. I like to compare the process of game development to cooking or baking. Most people love to eat pastries and cookies and donuts, just like most people enjoy playing games. But not everyone likes to bake those cookies, and not everyone likes to make games. If you want to become a baker, it certainly helps to like eating pastries. But it's not enough.
Some game companies are more like donut factories. They are not fun places to work. Fugazo, where I work, is more like a successful neighborhood bakery. The work isn't amazingly fun, but it's usually interesting, and the people are nice, and it's not a bad place to be all day. And at the end of a project, after a few months, you have a finished game that's pretty cool and you can feel proud of it and show your friends and family and all that. And you get to think about games all the time.
If you could change anything about your occupation what would it be?
If I could make games without ever having to sit at a desk and stare at a computer screen, I would. If I could run around in a virtual forest, climb inheritance trees and swing from conditional branches, build towers with blocks of code, and just use my physical body and my stereoscopic vision and my musical ears and my agile primate fingers, I would be so much happier. I love plants; I love being outside. I also love the ability to create virtual worlds that other people can experience, through computers. But every minute that I spend in front of a computer screen is a sacrifice that I make in exchange for this power to shape (virtual) reality.
More realistically, if I never had to renovate another programmer's poorly encapsulated user interface code, that would be awesome. Most frustrating part of my job right there. Also, if I had more teamwork throughout the day, I think I would enjoy that. I love collaboration, and I get just enough of it to avoid feeling unbearably lonely throughout the day, but I really get very little. There's something called pair programming where two people share a computer and take turns writing code and observing, and I've done that a few times in school and I think I'd very much like to do that again. However, it's obviously not as feasible in a small company like Fugazo where each game has only a single programmer to work on it.
Have you gone back for more educational training since you began the job?
Nope. For me, working at this job is all the educational training I need! It has been at least as educational as an equivalent time at school was, in the six months I've been at Fugazo. In computer programming, school can be essential to getting started, but once you're actually working, you should be learning a lot as you gain experience and your company starts branching out to new technologies and platforms. At the least, you can learn a lot from your own side projects as well.
What educational background do you have?
I graduated from the University of Washington with a Bachelor's degree in Computer Science. It took me a little less than five years at the UW to decide on my major, take all my required classes, and graduate. Throughout college, however, I had a summer internship or two working as a programmer and also made quite a few of my own games on the side, which is crucial if you're trying to get a job after graduating. Just a Computer Science degree doesn't cut it. You need to have experience working at a programming job, at least as an intern, and show that you have the passion, skill, and discipline to make your own games in your free time.
If you won the lottery and did not have to work, would you? Explain.
For a while, at least. ;) I decided to look for a job last summer so I could earn money, spend my days working on a team instead of by myself, and get experience learning from people who know what they're doing instead of fumbling around on my own. The lottery would only take care of one of those things. My life's work is to change the world through games. The most important thing I can do right now is to hone my skill at designing and programming games, and become fluent in all other aspects of the process as well. I will work at a company for as long as I need to until I'm ready to strike out on my own and form my own team, and I can't imagine finding a better place for that than Fugazo right now. A lot of game companies are not fun places to work. Fugazo is a notable exception.
What kind of strategies do you use when your job gets stressful?
Programming is often frustrating and can easily get stressful if you are not careful. I find it important to take breaks whenever I am really stuck or not thinking clearly, and I find that taking a walk right before lunch is very helpful in clearing my head. I also have started giving myself permission - with my boss's encouragement - to take short naps when I feel sleepy, especially in the afternoon. When it comes to jobs like programming that consist almost entirely of difficult problem-solving, it is often much more efficient to take a twenty-minute nap and come back refreshed than to fight back sleep deprivation for three hours without getting anything done. As with any sort of activity that involves sitting at a computer and staring at a screen all day, I've also found it very helpful to take a few minutes every so often to get up and move around, do some handstands, stretch, get my blood flowing, and help loosen whatever mental rut I might have gotten into while hunched over at my desk.
In your career field, is it difficult to balance work with home/family or personal life?
The game industry is one of the most notorious when it comes to poor work-life balance. This is a problem that is slowly improving, but it is definitely a real concern. Many companies, because of poor scheduling, can have months of forced "crunch time" at the end of a project, where people are working evenings, even weekends, continuously until the game is finished. Obviously, this is a very bad thing and it is arguably counter-productive in the long run, but many companies still do it. Even at Fugazo, where I work now, there may be a week or two of crunch at the end of a project, where I stay late in the evenings, but I've never worked weekends. Even then, no one is forcing me to stay late - I choose to keep working because I have a long list of things I want to get done, and I tend to be a perfectionist about these things. And I'll usually be the only one working late on most occasions, since no one is forced to crunch.
Outside of extreme circumstances like crunch time, I do often struggle to balance work and personal life. I wouldn't necessarily attribute this to the game industry itself. I think this has more to do with my inexperience (I've been working full-time for less than a year) and my tendency to cram way more things into my life than I could reasonably have time for. Though maybe the game industry tends to attract people like me anyway, so who knows!
What was it like when you went to high school? What kind of career planning did you have in high school?
I started high school about eight years ago. Back then, I wasn't thinking about jobs at all, but I knew that I wanted to do something with games. At the time I was doing a lot of programming on the graphing calculators we used in math class, making little games and releasing them online. I was also starting to read about using games for education and social change and became inspired to make that my life's work. As it turns out, those were the perfect things to be doing if I later wanted to start a career in game development!
What do you feel is most important when choosing a career?
There are a lot of ways to think about this question. One approach that I like is to think of something that you could see yourself getting really good at, if you spent the next ten or twenty years doing it for a living. That doesn't mean something you are already good at, necessarily, but something that you could see yourself learning to get really good at. I started learning to make games about ten years ago. The reason I choose to make games for a living now is not that I'm particularly good at it now, but I could see myself becoming really good at designing and making games over the next ten years. And that has less to do than the skills I currently have, and more to do with my passion and what I'm excited about and what I enjoy doing and learning and thinking about in my free time.
If you really love to do something, chances are that you could get really good at it - that if you kept doing it for a living over the next ten years, you wouldn't get bored and drop out - you'd keep learning and exploring and getting better and better as time goes on. I wouldn't suggest that you think about money right away. The jobs that tend to make a good amount of money are the jobs where you can keep getting better and better, where someone who is really good, with a lot of experience, can be worth ten or a hundred times what someone might be worth when they're just starting out. Like programming. Or game design. And you're going to have a hard time getting better and better unless you really love doing what you're trying to do. So try a bunch of things, find out what you love to do, and then ask yourself, "Which of these things could I really become good at, if I did this for a living for the next ten years?" Start there.
What advice do you have for me as I think about my future education and career plans?
Explore! Try lots of things, read about lots of things, ask lots of people about the things they do, and follow your curiosity when something attracts your interest. I was in fourth grade when I first learned that it was possible to make your own computer games. Before that, I guess I just assumed they spontaneously materialized in the store, fully formed, like action figures or LEGO sets. But once my eyes were opened to this possibility, I started reading every book I could find about how to make games, buying educational software, signing up for programming classes. At the time I had no idea what I was doing so my efforts were surprisingly ineffective, but I was persistent. I just wouldn't give up. And this interest gradually grew from a drip and a trickle here and there into a full-fledged flood of obsession that has significantly shaped my life and taken me to where I am right now.
But game development was not the only field that caught my interest. In high school, for example, I read tons of books on biology, philosophy, and how the mind works, just because I was so fascinated by these subjects. I thought I'd end up studying evolutionary biology or psychology or neuroscience in college, even though I ended up in computer science. And there's nothing wrong with that. In middle school I was big into music, and I started learning to make bamboo flutes in high school. Throughout the last several years I've been doing a lot of martial arts practice. And I'm still working as a programmer. But the key is to keep exploring. Be curious. There are so many things you could do with your life. Your life's work and passion may turn out to be something you've never even heard of yet. Before fourth grade, I'd certainly had no idea that I could make a living making games. If I hadn't been willing to explore, I would never have found this path.
And, if you want to get a job in the game industry, the best thing you can do right now is start making games. I made my first computer game in sixth grade. It wasn't a great game, but it was something, and I learned a lot in making it. And more importantly, after that I made another one. And another one. And another one. If you don't know how to make computer games, go and find out how. Look online, read books, take classes - whatever you can find. There are so many more resources out there now than there were ten years ago when I was starting out. Download a free tool like Game Maker to get started - you don't even need to learn programming. Or make board games, and test them out with your friends - no programming required. Just make games, and keep making games, and by the time you are actually trying to convince someone to hire you, you will be able say, "Look at this. I made this. And this, and this, and this."
If you want to make games, make games.
Related:
advice,
games,
learning,
money,
motivation,
programming
2011/01/12
Lucid Sight Dreaming
I had two lucid dreams this morning. The last lucid dream I had before that was less than a month ago. A year before that I had another. And my first one, more than a year before that. I like to think that the process is accelerating, that this reflects some underlying spiritual or psychological growth that is just beginning to manifest itself in the form of these dreams.
Perhaps.
Lucid dreams are those dreams where you realize that you are dreaming, and "wake up" within the world of the dream. Often this means that you can then control the dream, or at least influence the course of it. I've never had much success with trying to control my dreams, though. It's something that takes a lighter touch - you make something happen by expecting it do so, not by concentrating really hard and commanding it to happen - and I've had little opportunity to practice such controlled expectations in my dreams so far.
However, there is one thing that I have experienced in every lucid dream I've had. That is, a particular clarity and sharpness to the visual details of the dream world. Everything looks so much more real when I'm lucid, much more than the vague and muddled state of my ordinary dreaming. And the more lucid I am, the more calm and aware I am in my mental state, the more my sight improves. It's like putting on glasses.
To illustrate, I'll tell the story of my lucid dream last month:
2010/12/26
This morning I had a lucid dream after going back to sleep. It was my longest and most calm lucid segment yet. I was telling someone that I was dreaming, then decided to try to become lucid and started writing on a piece of paper, "I am dreaming." I saw the letters change as I read them, as they do in dreams, and continued to write on the paper and watch how my writing changed. Then I walked around, and I found that the level of my lucidity would correspond to the brightness of the space around me. I would start to lose it in dark areas, then become more aware again in bright areas with their windows open to the light and visual details outside.
That's it. The dream was notable in not feeling rushed or frantic at all. I was able to maintain my lucidity for a long time, relatively, with a calm and open mental state. It was like my mind was a net, holding everything together, and I was able to keep it from collapsing without much effort as long as I stayed in the light.
The key here was the light, and the visual details that went with it. But it wasn't until my dreams this morning that I realized the significance of this factor.
2011/01/12
I had a lucid dream. It started when I went outside to the backyard, in my dream. The openness and brightness and visual detail opened my eyes, and I became lucid. I collected my mind and did some breathing checks to confirm that I was dreaming - I found I could still breathe, even while pinching my nose shut. However, it must not have lasted too long, since I can't remember what I did after that other than walk around in the grass.
I had another lucid dream. I fell asleep again after writing about the first one, and dreamt that I came across some of the guys from Novel that I used to work with after graduating. I started walking along with them, near the university, and some others were with us too, talking about balance issues with the new MMO they are working on. There were a lot of students around, walking, too, on the sidewalks and street.
And then I opened my eyes and became lucid. Again, everything sharpened, the visual details popped out, and I realized I was in a dream.
But I found that I couldn't control the dream. I couldn't even walk anymore. When I tried to move my feet in the dream, focusing in on the feel of them pressing against the ground, I just felt my own feet in my bed, faintly but stronger and stronger the more I tried. And I realized it must be after 9am, and I must have fallen asleep again accidentally after writing in my notebook. So I allowed myself to come into my own body fully and woke up.
The interesting thing about these dreams is that they seemed to happen spontaneously, triggered not by some dream check or verbal reminder but just by the act of opening my eyes.
But with the experience of these last few lucid dreams so fresh in my memory now, I have realized that there is a particular trigger behind the lucidity I experienced, and that it is actually much easier to practice than a more conventional check like pinching my nose and trying to breathe.
What came first, the lucidity or the enhanced sight? Neither. It was the act of looking, wide-eyed, out and up, in awe, holding my entire visual field in perception, like this, that did it. The lucidity and the visual detail came together, in response.
Stepping outside in my first dream this morning triggered this act of looking. Looking outside, into the light, strengthened it in my dream from last month. And somehow, looking out at all the people, walking in sunlight, triggered it in my second dream this morning.
What this experience has told me is that the way to inspire more lucid dreams in the future is to practice this "wide-eyed" mental state often in daily waking life, rather than obsessively doing weird dream checks throughout the day that I can never seem to remember while asleep.
Because this state of mind - as well as the correspondingly muddled state of non-lucid dreaming - is one I recognize from my waking life as well. It's the same in both waking and dreaming, and I know it well. Having experienced the contrast so recently and often, relatively, I am now able to see this.
Just look up, open your eyes, let the details emerge
, and become lucid. Not a bad habit to have, even while awake. Especially while awake.
Perhaps.
Lucid dreams are those dreams where you realize that you are dreaming, and "wake up" within the world of the dream. Often this means that you can then control the dream, or at least influence the course of it. I've never had much success with trying to control my dreams, though. It's something that takes a lighter touch - you make something happen by expecting it do so, not by concentrating really hard and commanding it to happen - and I've had little opportunity to practice such controlled expectations in my dreams so far.
However, there is one thing that I have experienced in every lucid dream I've had. That is, a particular clarity and sharpness to the visual details of the dream world. Everything looks so much more real when I'm lucid, much more than the vague and muddled state of my ordinary dreaming. And the more lucid I am, the more calm and aware I am in my mental state, the more my sight improves. It's like putting on glasses.
To illustrate, I'll tell the story of my lucid dream last month:
2010/12/26
This morning I had a lucid dream after going back to sleep. It was my longest and most calm lucid segment yet. I was telling someone that I was dreaming, then decided to try to become lucid and started writing on a piece of paper, "I am dreaming." I saw the letters change as I read them, as they do in dreams, and continued to write on the paper and watch how my writing changed. Then I walked around, and I found that the level of my lucidity would correspond to the brightness of the space around me. I would start to lose it in dark areas, then become more aware again in bright areas with their windows open to the light and visual details outside.
That's it. The dream was notable in not feeling rushed or frantic at all. I was able to maintain my lucidity for a long time, relatively, with a calm and open mental state. It was like my mind was a net, holding everything together, and I was able to keep it from collapsing without much effort as long as I stayed in the light.
The key here was the light, and the visual details that went with it. But it wasn't until my dreams this morning that I realized the significance of this factor.
2011/01/12
I had a lucid dream. It started when I went outside to the backyard, in my dream. The openness and brightness and visual detail opened my eyes, and I became lucid. I collected my mind and did some breathing checks to confirm that I was dreaming - I found I could still breathe, even while pinching my nose shut. However, it must not have lasted too long, since I can't remember what I did after that other than walk around in the grass.
I had another lucid dream. I fell asleep again after writing about the first one, and dreamt that I came across some of the guys from Novel that I used to work with after graduating. I started walking along with them, near the university, and some others were with us too, talking about balance issues with the new MMO they are working on. There were a lot of students around, walking, too, on the sidewalks and street.
And then I opened my eyes and became lucid. Again, everything sharpened, the visual details popped out, and I realized I was in a dream.
But I found that I couldn't control the dream. I couldn't even walk anymore. When I tried to move my feet in the dream, focusing in on the feel of them pressing against the ground, I just felt my own feet in my bed, faintly but stronger and stronger the more I tried. And I realized it must be after 9am, and I must have fallen asleep again accidentally after writing in my notebook. So I allowed myself to come into my own body fully and woke up.
The interesting thing about these dreams is that they seemed to happen spontaneously, triggered not by some dream check or verbal reminder but just by the act of opening my eyes.
But with the experience of these last few lucid dreams so fresh in my memory now, I have realized that there is a particular trigger behind the lucidity I experienced, and that it is actually much easier to practice than a more conventional check like pinching my nose and trying to breathe.
What came first, the lucidity or the enhanced sight? Neither. It was the act of looking, wide-eyed, out and up, in awe, holding my entire visual field in perception, like this, that did it. The lucidity and the visual detail came together, in response.
Stepping outside in my first dream this morning triggered this act of looking. Looking outside, into the light, strengthened it in my dream from last month. And somehow, looking out at all the people, walking in sunlight, triggered it in my second dream this morning.
What this experience has told me is that the way to inspire more lucid dreams in the future is to practice this "wide-eyed" mental state often in daily waking life, rather than obsessively doing weird dream checks throughout the day that I can never seem to remember while asleep.
Because this state of mind - as well as the correspondingly muddled state of non-lucid dreaming - is one I recognize from my waking life as well. It's the same in both waking and dreaming, and I know it well. Having experienced the contrast so recently and often, relatively, I am now able to see this.
Just look up, open your eyes, let the details emerge
Related:
news,
perception,
sleep
2011/01/01
Yugen and Games
"As the taillights of that last ride grow small and wink out, the horizon gathers itself to your singular perspective. There is no grandeur to bait expectation, no promise to invite distraction, only the quiet of ditch and litter and grass and self; without preconceptions you begin to see your place in a different way, from the ground up. You warm to how consummate this place is in its becoming: the perfect pattern of stones along the shoulder; the fast food wrappers, their logos clinging just so to the sage; there at long rest in the shadows, that old trilobite of the highway, the fallen muffler. And so you become consummate yourself; instead of a face lost in an embarrassed crowd, you become unique and necessary to that moment, your perspective creating, for better or worse, this one place in the world. It is a time to whistle."
That was a quote by John Landretti, from his essay "On Waste Lonely Places" in the book The Future of Nature. I had written it down by hand in my notebook close to a year ago; looking back through my notes of the past year in reflection, I found it again and decided to share it.
It reminded me of this blog post, which I had just come across earlier this week. The author describes playing the small art game The Graveyard, then the bigger and decidedly-non-art game GTA IV, and how both of these games created in him an experience he called yugen, "the sudden perception of something mysterious and strange, hinting at an unknown never to be discovered."
To me it sounds like the experience of meditation, or at least the kind of meditation that I am familiar with.
And it sounds like a fruitful area of experience for notgames to explore, since this is something you are left with when you strip the "game" from "games", letting only the interaction and immersion remain.
Still, I think there is something missing, something that we will have to identify before we can really make compelling yugen-ish experiences that are not games. When you strip the distracting goals and challenges from conventional games, what you get is rarely worth writing blog posts about. If nothing else, such "gamification" is good at getting people to care about what goes on in a virtual world, and the other ways of creating engagement and involvement with a story and characters common in movies and books and such tend to be more difficult in interactive media. But I think we just don't know enough.
I suspect that there are ways to direct this experience more subtly, still from a game designer's perspective, but not so heavy-handed with goals or points or typical game-y things. More toward Knytt, perhaps, but further. Much further.
I don't know. I guess I'll just have to try it sometime.
Happy New Year.
"Offering your attention to a waste place is like finding a book in a library, a book nobody reads. Or perhaps a book harboring a single due date, one purple smudge thirty years old. And there it is in your hand by the effortless design of coincidence. You look over its pages and before is effort and presence; whether the contents have appeal is another matter, but the book does exist and is open before you, full of its telling. And so it is with these shelves and sheaves of world that daily surround us: every rock, blade, and bottle, every leaf, an invitation to an understanding."
- John Landretti, "On Waste Lonely Places", The Future of Nature
That was a quote by John Landretti, from his essay "On Waste Lonely Places" in the book The Future of Nature. I had written it down by hand in my notebook close to a year ago; looking back through my notes of the past year in reflection, I found it again and decided to share it.
It reminded me of this blog post, which I had just come across earlier this week. The author describes playing the small art game The Graveyard, then the bigger and decidedly-non-art game GTA IV, and how both of these games created in him an experience he called yugen, "the sudden perception of something mysterious and strange, hinting at an unknown never to be discovered."
Playing it, I found an odd thing. I found my head starting to clear. It wasn’t so much that I was sensing the emptiness around me - rather I was the emptiness. My thoughts were coming and going on their own - frothing up then melting away again - and slowly the oceans of my mind began to fall calm.
There was nothing mystical or arcane about it, merely an experience of being right here, right now. It was very ordinary.
To me it sounds like the experience of meditation, or at least the kind of meditation that I am familiar with.
And it sounds like a fruitful area of experience for notgames to explore, since this is something you are left with when you strip the "game" from "games", letting only the interaction and immersion remain.
The feeling of yugen hovers in the background of many games - filling me with the desire to explore those green hills behind Super Mario World’s flat levels, say - but it usually only breaks through fully when the mechanics of narrative and threat have been removed. My mind can’t empty in Another World - despite the barren, evocative landscapes - because it is so focused on avoiding death and finding a way home. It is when the designers take a step back from filling our time with obstacles and rewards, and allow us just to experience the realms they have created, that the subtler emotions like yugen are given room to manifest.
Still, I think there is something missing, something that we will have to identify before we can really make compelling yugen-ish experiences that are not games. When you strip the distracting goals and challenges from conventional games, what you get is rarely worth writing blog posts about. If nothing else, such "gamification" is good at getting people to care about what goes on in a virtual world, and the other ways of creating engagement and involvement with a story and characters common in movies and books and such tend to be more difficult in interactive media. But I think we just don't know enough.
I suspect that there are ways to direct this experience more subtly, still from a game designer's perspective, but not so heavy-handed with goals or points or typical game-y things. More toward Knytt, perhaps, but further. Much further.
I don't know. I guess I'll just have to try it sometime.
Happy New Year.
"Offering your attention to a waste place is like finding a book in a library, a book nobody reads. Or perhaps a book harboring a single due date, one purple smudge thirty years old. And there it is in your hand by the effortless design of coincidence. You look over its pages and before is effort and presence; whether the contents have appeal is another matter, but the book does exist and is open before you, full of its telling. And so it is with these shelves and sheaves of world that daily surround us: every rock, blade, and bottle, every leaf, an invitation to an understanding."
- John Landretti, "On Waste Lonely Places", The Future of Nature
Related:
art,
games,
perception,
quotes
2010/12/05
My First Time
I killed Starshine. I slit her throat.
I held her a long time before that, feeling the pulse at her throat, the warmth of her body, the movement of her breathing. Chickens can sit very calm if you hold them the right way - crouching over her, hand around her neck gently, fingers in the soft feathers of her belly.
Then upside down by the feet, similarly calm. Tied her up on the pear tree right above where my last treefrog was buried. Bright red blood dripping down through the decaying leaf litter. Phil held her wings as she convulsed in death, like a person violently vomiting, blood from a gash in the neck. I hope that she did not suffer; I fear that she did. Three times, deepening the cut. How terrible, how incompetent...
I was barefoot. My toes were painfully cold, I realized once the blood had stopped dripping and her eyes had closed. Sitting on a beach towel on the bathroom floor, drying my feet, I cried to myself, partly in pain, partly from nausea, and partly out of guilt and horror over what I had done. Maybe not long enough, but it was something. I didn't skin the body, though I helped pull some feathers out. I watched Phil do it and held the pan for the organs and meat.
Crouching there, with my knife to her throat, feeling her pulse with my hand - it was like standing on the edge of a high-dive, looking down at the water far below. We're all waiting for you. How could I do this? How could I let anyone else do this instead? But oh, it was far too easy to take that plunge. I'm sorry. And thank you.
I don't want to write about this anymore.
I held her a long time before that, feeling the pulse at her throat, the warmth of her body, the movement of her breathing. Chickens can sit very calm if you hold them the right way - crouching over her, hand around her neck gently, fingers in the soft feathers of her belly.
Then upside down by the feet, similarly calm. Tied her up on the pear tree right above where my last treefrog was buried. Bright red blood dripping down through the decaying leaf litter. Phil held her wings as she convulsed in death, like a person violently vomiting, blood from a gash in the neck. I hope that she did not suffer; I fear that she did. Three times, deepening the cut. How terrible, how incompetent...
I was barefoot. My toes were painfully cold, I realized once the blood had stopped dripping and her eyes had closed. Sitting on a beach towel on the bathroom floor, drying my feet, I cried to myself, partly in pain, partly from nausea, and partly out of guilt and horror over what I had done. Maybe not long enough, but it was something. I didn't skin the body, though I helped pull some feathers out. I watched Phil do it and held the pan for the organs and meat.
Crouching there, with my knife to her throat, feeling her pulse with my hand - it was like standing on the edge of a high-dive, looking down at the water far below. We're all waiting for you. How could I do this? How could I let anyone else do this instead? But oh, it was far too easy to take that plunge. I'm sorry. And thank you.
I don't want to write about this anymore.
Midnight, Starshine, and Princess Buttercup in their early adolescent years. Year.
2010/11/25
Origami Zergling and Hydralisk Tutorial Videos Complete
Earlier this year, I released three videos of me folding my origami hydralisk, hoping that this would help the people who got stuck trying to follow my step-by-step diagrams.
Sadly, it did not. Many people replied, asking for more clarification on the infamous Step 11.
So, being the generous and understanding origami teaching person that I am, I decided to try again, with a much slower video where I narrate each step of the way in detail, as if guiding a complete beginner.
And it seemed to work. Yay.
And, the classic...
Yeah, after seven years I finally have created some instructions that other people can follow. :p
It's very slow, so it's a long video. Slow but good. :) In eight parts on YouTube. Here's the first:
And the rest:
Also, I made a similarly slow, narrated tutorial video for my origami zergling as well. In ten parts. Here's the first:
And the rest:
And again, the acclaim:
The best part is knowing that I have improved people's lives in real, tangible ways. I give people the power to fold origami aliens. Now that's what I call real value. :)
Seriously, that's amazing. Several people who have never done origami before have commented saying that they were able to follow these instructions and make an origami zergling as their first model.
Okay, now you can start bugging me about an origami ultralisk. Maybe I'll actually make one in a few more years. ;)
Sadly, it did not. Many people replied, asking for more clarification on the infamous Step 11.
YouTube is a great place to practice NVC...
So, being the generous and understanding origami teaching person that I am, I decided to try again, with a much slower video where I narrate each step of the way in detail, as if guiding a complete beginner.
And it seemed to work. Yay.
I love how you go so slow, other just go through things so fast.
Thnx for posting this, I menaged to fold one while watching! Good tempo and very instructive!!
Most of the time people go too fast and you miss a step, but there is NO possible way you can miss a step in this. Awesome! You must be a genius o.O
thank you u are one of da best origami narrator :D
And, the classic...
god thank u after 2 years i did step 11
Yeah, after seven years I finally have created some instructions that other people can follow. :p
It's very slow, so it's a long video. Slow but good. :) In eight parts on YouTube. Here's the first:
And the rest:
- How to make an origami hydralisk - Part 1 of 8
- How to make an origami hydralisk - Part 2 of 8
- How to make an origami hydralisk - Part 3 of 8 (Step 11)
- How to make an origami hydralisk - Part 4 of 8
- How to make an origami hydralisk - Part 5 of 8
- How to make an origami hydralisk - Part 6 of 8
- How to make an origami hydralisk - Part 7 of 8
- How to make an origami hydralisk - Part 8 of 8
Also, I made a similarly slow, narrated tutorial video for my origami zergling as well. In ten parts. Here's the first:
And the rest:
- How to make an origami zergling - Part 1 of 10
- How to make an origami zergling - Part 2 of 10
- How to make an origami zergling - Part 3 of 10
- How to make an origami zergling - Part 4 of 10
- How to make an origami zergling - Part 5 of 10
- How to make an origami zergling - Part 6 of 10
- How to make an origami zergling - Part 7 of 10
- How to make an origami zergling - Part 8 of 10
- How to make an origami zergling - Part 9 of 10
- How to make an origami zergling - Part 10 of 10
And again, the acclaim:
Thanks that was the best series of explanation videos ever.
this is a very noob friendly vid. nice. you don't see origami videos this well made that often.
sir, you have my respect and the [SF] Official Seal of Approval
The best part is knowing that I have improved people's lives in real, tangible ways. I give people the power to fold origami aliens. Now that's what I call real value. :)
After 2 and a half hours of testing my persistence and determination I have completed this project. Thank you axcho, because of you, I am now the epitome of cool, the envy among my peers and I have a freakin' paper zergling.
Thank you, axcho, for these fantastic videos! I've finished my (hot pink) zergling! It can join the esteemed company of my origami hydralisks (also thanks to you)!
Thanks for the videos! I just finished my zergling, and I knew almost nothing about origami before. :D
Seriously, that's amazing. Several people who have never done origami before have commented saying that they were able to follow these instructions and make an origami zergling as their first model.
Okay, now you can start bugging me about an origami ultralisk. Maybe I'll actually make one in a few more years. ;)
2010/10/24
Why Avatar Is Important
I wrote this back in January, and somehow never got around to posting it until now. Well, here it is. Better late than never, right?
There was this other movie that everyone seems to be talking about. I saw that one, in IMAX 3D. I shamelessly add it to my list of favorite movies, along with The Matrix and Lilo & Stitch and other such gems of cinema. I may be excessively indie when it comes to games, but no one can accuse me of being a film snob.
Whatever people are saying about it, what I appreciated in that movie was that it clearly showed what people left behind when they took up agriculture and industrialization and the trend toward global corporate hegemony - I said "hegemony" haha! - that is, the fun. Not moral superiority, not environmental friendliness, not utopian peace and happiness, but a life that, despite the dangers, the high mortality rate, the lack of iPhones or toilet paper or whatever else you want to measure, a life that is richly fulfilling, challenging, rewarding, interesting, in a way that the human mind and body craves and thrives on - in a word, fun.
This pressure gradient between the two societies, the fun and the unfun, is what drove the progression of this story. And this movie drove this difference home in the way no other medium could - except for games, of course - and for that reason, it is important. That's it.
And lots of people feel it. They feel this gradient pushing them away from their own lives and into the imaginary fun of the movie, which is no place to be if you are in fact a real person. But this fun place is real, it's just out of sight, in the past, or in those pockets of the world where the fun has yet to be sucked out and converted into GDP.
But no one's talking about it like that, because the usual sides to pick, the usual ways to debate these kinds of things are so readily available. Yes, kind of sad. But it gives me hope. If you show people what they're missing, they will feel it, and they will desperately seek it out, even if they believe it to be imaginary.
So, hope for the world. I must remember my mission. This is why I chose games. Light the fire, make the spark. Don't crack the whip. Whips don't work very well on rockets anyway.
There was this other movie that everyone seems to be talking about. I saw that one, in IMAX 3D. I shamelessly add it to my list of favorite movies, along with The Matrix and Lilo & Stitch and other such gems of cinema. I may be excessively indie when it comes to games, but no one can accuse me of being a film snob.
Whatever people are saying about it, what I appreciated in that movie was that it clearly showed what people left behind when they took up agriculture and industrialization and the trend toward global corporate hegemony - I said "hegemony" haha! - that is, the fun. Not moral superiority, not environmental friendliness, not utopian peace and happiness, but a life that, despite the dangers, the high mortality rate, the lack of iPhones or toilet paper or whatever else you want to measure, a life that is richly fulfilling, challenging, rewarding, interesting, in a way that the human mind and body craves and thrives on - in a word, fun.
This pressure gradient between the two societies, the fun and the unfun, is what drove the progression of this story. And this movie drove this difference home in the way no other medium could - except for games, of course - and for that reason, it is important. That's it.
And lots of people feel it. They feel this gradient pushing them away from their own lives and into the imaginary fun of the movie, which is no place to be if you are in fact a real person. But this fun place is real, it's just out of sight, in the past, or in those pockets of the world where the fun has yet to be sucked out and converted into GDP.
But no one's talking about it like that, because the usual sides to pick, the usual ways to debate these kinds of things are so readily available. Yes, kind of sad. But it gives me hope. If you show people what they're missing, they will feel it, and they will desperately seek it out, even if they believe it to be imaginary.
So, hope for the world. I must remember my mission. This is why I chose games. Light the fire, make the spark. Don't crack the whip. Whips don't work very well on rockets anyway.
2010/10/13
Teaching Flixel
A few weeks ago, I started teaching some kids how to make games with Flixel and other free tools. I'm offering my time up as a volunteer, at a progressive school I came across through this inspiring blog. Here is an email I just wrote to my students:
Hi class,
I'm really tired right now. I should be sleeping. But I'm writing these instructions to you now because of something that is more urgent to me than sleep. River sent me an email asking me again to explain how to finish the animation and change where the bullet shoots from. He apparently wanted to figure this out enough that he bothered to remind me about it. He didn't have to do that. I don't have to do anything for you guys. But he wanted to. And because he wanted to, I will do whatever it takes to help him get there, even though I'm really busy, even though I'm tired. Because this is the whole reason that I decided to try teaching a class at PSCS. I came here on the chance that I might be able to help someone get somewhere they really want to go but can't get to by themselves. I'm not an expert in most things, but this opportunity to share what I can with people who want it is very motivating for me.
And I've been waiting for this. And now I see the beginnings of it.
I'm not attached to you wanting to learn game programming, or game design, or whatever. You love playing games, and I think there is a chance that you may come to love creating games as well, once you get more of a taste of it. It is an acquired taste. It might not be your thing. Which is fine with me. I don't really care personally either way. But if it is, and if there is a chance that it might be, I will do whatever I can to catch that spark in you, and help you kindle it into a steady flame, if you so choose. Just let me know.
Yeah. So, those instructions...
You added some code in the beginning of update() that said this:
var moved:Boolean = false;
Then you added code to each if-statement for the arrow keys, to changed moved to true, if you press an arrow key during the update.
moved = true;
So you have a virtual bucket, sitting in your computer's memory, which you call moved, in which you can put either true or false. But it doesn't do anything by itself. It just sits there.
However, it is useful. Because you can look at it. If it has true inside it, you know that an arrow key was pressed, because you put true in it whenever an arrow key is pressed. Right? If it has false inside it, you know that no arrow key was pressed.
Say you wanted to do something only if an arrow key was pressed, and another thing if no arrow key was pressed. Like play a walk animation, or play an idle animation. If you wanted to do that, then it might be helpful to look into this moved bucket, and see what's inside.
You could say...
If moved has true inside of it, then play the walk animation.
Otherwise (if it is false), play the idle animation.
And you could translate that into actual AS3 code, like this:
if (moved)
{
_box.play("walk");
}
else
{
_box.play("idle");
}
And you would put that code in update(), after all the arrow keys and such have been checked.
Some notes:
if (moved) is the same as if (moved == true) - because what you put between the parentheses in an if-statement is checked to see if it is equal to true. If it is equal to true, the code in the curly braces is run. Otherwise, it runs the code for else.
Why does if (FlxG.keys.LEFT) work to see if the left arrow key is pressed? Because FlxG.keys.LEFT is a virtual bucket that holds true if the left arrow key is pressed and false otherwise. Get it?
Also, there is no way to just stop an animation. You must have another animation to replace it. For example, you could create an animation, with _box.addAnimation(), that is called "idle" and that has only one frame in its list of frames. Then when you play that animation, the _box would stay on that one frame forever, unless you play a different animation later on.
You might also wonder whether telling the _box to play an animation, telling it again and again every frame, might make it start over from the beginning every frame and not get anywhere. There is a way to do that. But fortunately, Flixel will not restart the animation if it's already playing. So this works.
There you have it - the instructions for how to make an animation only play while moving. It will take a bit of work, a bit of thought, a bit of failure and frustration and trial-and-error in order to get it to work in your particular program. But this is the price we pay.
I do not demand success from you. But I do demand that you try, or I cannot help you. And I suggest that you try more than once, even if you fail at first. You have unlimited lives, when it comes to programming. Remember that.
Next.
Making bullets shoot from somewhere other than the top left corner of the box sprite.
This is easier.
Find the code where you first create the bullet. It looks something like this:
var bullet:FlxSprite = new FlxSprite(_box.x, _box.y);
Remember? That creates a new FlxSprite, and gives it the name bullet, and puts it at a certain spot on the screen. That certain spot on the screen happens to be the upper left corner of the _box sprite.
If the box sprite has its corner at the coordinates (5, 10) and it is 50 pixels wide and 50 pixels high, then where is its center?
I'll tell you the answer. Its center is at the coordinates (5 + 50 / 2, 10 + 50 / 2), which is the same as (5 + 25, 10 + 25), which is (30, 35).
To put it more generally, the box's center is at (_box.x + 25, _box.y + 25). Just add an offset of (25, 25) and you get the center. Right?
What if you wanted to put the bullet at the center of the box?
var bullet:FlxSprite = new FlxSprite(_box.x + 25, _box.y + 25);
Would that work? I suggest you try it out and see.
What if you want it to appear somewhere other than the center? Well, try using some other numbers, instead of 25.
Once you get that working (which I'm sure you will), try making an animation for the bullet. Can you do it?
Show me on Monday.
If you have any questions, let me know before the weekend.
Good luck.
Hi class,
I'm really tired right now. I should be sleeping. But I'm writing these instructions to you now because of something that is more urgent to me than sleep. River sent me an email asking me again to explain how to finish the animation and change where the bullet shoots from. He apparently wanted to figure this out enough that he bothered to remind me about it. He didn't have to do that. I don't have to do anything for you guys. But he wanted to. And because he wanted to, I will do whatever it takes to help him get there, even though I'm really busy, even though I'm tired. Because this is the whole reason that I decided to try teaching a class at PSCS. I came here on the chance that I might be able to help someone get somewhere they really want to go but can't get to by themselves. I'm not an expert in most things, but this opportunity to share what I can with people who want it is very motivating for me.
And I've been waiting for this. And now I see the beginnings of it.
I'm not attached to you wanting to learn game programming, or game design, or whatever. You love playing games, and I think there is a chance that you may come to love creating games as well, once you get more of a taste of it. It is an acquired taste. It might not be your thing. Which is fine with me. I don't really care personally either way. But if it is, and if there is a chance that it might be, I will do whatever I can to catch that spark in you, and help you kindle it into a steady flame, if you so choose. Just let me know.
Yeah. So, those instructions...
You added some code in the beginning of update() that said this:
var moved:Boolean = false;
Then you added code to each if-statement for the arrow keys, to changed moved to true, if you press an arrow key during the update.
moved = true;
So you have a virtual bucket, sitting in your computer's memory, which you call moved, in which you can put either true or false. But it doesn't do anything by itself. It just sits there.
However, it is useful. Because you can look at it. If it has true inside it, you know that an arrow key was pressed, because you put true in it whenever an arrow key is pressed. Right? If it has false inside it, you know that no arrow key was pressed.
Say you wanted to do something only if an arrow key was pressed, and another thing if no arrow key was pressed. Like play a walk animation, or play an idle animation. If you wanted to do that, then it might be helpful to look into this moved bucket, and see what's inside.
You could say...
If moved has true inside of it, then play the walk animation.
Otherwise (if it is false), play the idle animation.
And you could translate that into actual AS3 code, like this:
if (moved)
{
_box.play("walk");
}
else
{
_box.play("idle");
}
And you would put that code in update(), after all the arrow keys and such have been checked.
Some notes:
if (moved) is the same as if (moved == true) - because what you put between the parentheses in an if-statement is checked to see if it is equal to true. If it is equal to true, the code in the curly braces is run. Otherwise, it runs the code for else.
Why does if (FlxG.keys.LEFT) work to see if the left arrow key is pressed? Because FlxG.keys.LEFT is a virtual bucket that holds true if the left arrow key is pressed and false otherwise. Get it?
Also, there is no way to just stop an animation. You must have another animation to replace it. For example, you could create an animation, with _box.addAnimation(), that is called "idle" and that has only one frame in its list of frames. Then when you play that animation, the _box would stay on that one frame forever, unless you play a different animation later on.
You might also wonder whether telling the _box to play an animation, telling it again and again every frame, might make it start over from the beginning every frame and not get anywhere. There is a way to do that. But fortunately, Flixel will not restart the animation if it's already playing. So this works.
There you have it - the instructions for how to make an animation only play while moving. It will take a bit of work, a bit of thought, a bit of failure and frustration and trial-and-error in order to get it to work in your particular program. But this is the price we pay.
I do not demand success from you. But I do demand that you try, or I cannot help you. And I suggest that you try more than once, even if you fail at first. You have unlimited lives, when it comes to programming. Remember that.
Next.
Making bullets shoot from somewhere other than the top left corner of the box sprite.
This is easier.
Find the code where you first create the bullet. It looks something like this:
var bullet:FlxSprite = new FlxSprite(_box.x, _box.y);
Remember? That creates a new FlxSprite, and gives it the name bullet, and puts it at a certain spot on the screen. That certain spot on the screen happens to be the upper left corner of the _box sprite.
If the box sprite has its corner at the coordinates (5, 10) and it is 50 pixels wide and 50 pixels high, then where is its center?
I'll tell you the answer. Its center is at the coordinates (5 + 50 / 2, 10 + 50 / 2), which is the same as (5 + 25, 10 + 25), which is (30, 35).
To put it more generally, the box's center is at (_box.x + 25, _box.y + 25). Just add an offset of (25, 25) and you get the center. Right?
What if you wanted to put the bullet at the center of the box?
var bullet:FlxSprite = new FlxSprite(_box.x + 25, _box.y + 25);
Would that work? I suggest you try it out and see.
What if you want it to appear somewhere other than the center? Well, try using some other numbers, instead of 25.
Once you get that working (which I'm sure you will), try making an animation for the bullet. Can you do it?
Show me on Monday.
If you have any questions, let me know before the weekend.
Good luck.
Related:
creation,
learning,
motivation,
news,
programming
2010/09/19
How Artists Want to Make Games
On the notgames forum, Michaël Samyn posted this thread:
Programming in code is counter-productive for people with art-sided brains. The solution to this problem exists: graphical programming. But the people who need to implement this solution happen to be its worst enemies. Because to engineers, code-based programming beats everything.
Until somebody somewhere starts believing artists when they say they want to program in a visual language, or starts realizing that giving access to artists is the best way for a creative technology to continue evolving, I find myself settling with inferior designs. Because I cannot express myself adequately in code, I need to change my ideas, I need to talk about simpler things in a simple way.
It's like someone is forcing me to write poetry in French. French is a great language. And people who are familiar with it can write beautiful poetry. But I speak Dutch. My Dutch poems are subtle and sublime. In French, however, all I can write are nursery rhymes.
So I've been thinking about this a lot over the last several days. Actually I've been obsessively thinking about it non-stop and reading everything I can on related topics online.
I tend to do that for a different thing every week. This week, it's been this.
So there are a few pieces I've been focusing on, that seem most crucial to the success of a programming or game development tool for artists. There are probably others, but I thought I'd share what I've been thinking about so far.
One is readability through R-mode perception.
First of all, a disclaimer: When I say "R-mode" versus "L-mode", as in "Right brain" or "Relational" or "Rtistic" versus "Left brain" or "Logical" or "Linear", I don't mean to suggest that the brain is really divided into strict differences between its physical right and left halves. That is an outdated belief. But I find the terminology to be a useful shorthand.
Thinking on Michael's comments about visual flowcharts being easier for him to read than linguistic code, and looking back on my own experience, I think there really is something significant about how the code is presented and perceived, even when the underlying logic is the same.
When I am reading code (or a book!) I am usually using what I call "L-mode" perception - going through in a linear, linguistic way, and building up my mental model one step, one line of code at a time, following the logic that is expressed symbolically, in sequences like that.
However, sometimes my mind is in an "R-mode" of all-at-once, spatial perception like you'd use for looking at a painting or trying to find a certain LEGO piece in a big box of pieces. When I am in that state of mind, and I look at code (or to a lesser extent, written language) I see all the words at once and perceive the spatial relationships between them, and the underlying logic of the code is utterly incomprehensible to me. Obviously not the "right" way to read code.
But maybe it could be.
Ha, that would be a good tagline. "The right way to code." :P
The thing about R-mode perception is that it's a lot easier to be creative when you're in it. The other thing about R-mode perception is that artists are usually a lot more skilled at functioning in R-mode than they are in L-mode.
Therefore, if you had a tool that let you do programming while in R-mode rather than L-mode, it might be slightly easier to do creative things with it. At the least, there would be less inefficiency caused by switching between R-mode and L-mode whenever you think about what you want to change and then have to dive into the code to actually change it.
However, this may not even be possible.
All the visual programming editors I've seen, all the examples that have been posted here, require an uncomfortable mix of L-mode and R-mode perception in order to use. What I tend to see is a bunch of visually identical boxes connected by lines, and differentiated by text.
What you see in R-mode is the set of relationships between the boxes. But you can't tell what each of the boxes does. To do that, you must read the text and think symbolically, in L-mode. Really, very little information is conveyed through spatial relationships, through R-mode. Most of it is still sequential and symbolic.
For that reason, I find that pure written code, all L-mode, is much easier for me to deal with, since I don't need to switch around multiple times a second just to figure out what everything means. However, I suspect that there may be a way to create a pure R-mode method of programming too. But I'm not confident that it's actually possible. Just intrigued enough to try.
There are some programmers who hate the idea of visual programming, and say that it's a waste of time to use spatial relationships to convey the meaning of code. If you are one of those people and you use syntax coloring or indentation, you are a hypocrite.
So there's one aspect. Make sure your tool is R-mode accessible, if you want artists to be able to use it.
The second thing is building with functional pieces in real (or almost real) time.
Artists tend to appreciate tools where "what you see is what you get" - you're manipulating the end result, so you can immediately see the results of your actions. The process becomes more like sculpting.
Programmers tend to discount such tools as nice but unnecessary. They are used to typing in code for an hour, hitting a button, and waiting a minute for everything to compile and show up on the screen.
These are two fundamentally different mindsets, as different as a slideshow and an animation.
When you operate in the slow, "slideshow" approach, development and creativity tends to happen in an architected, "top-down" way. You have a plan, which is in your head, and then you put in a bunch of time and hard work to mold reality into the shape of that plan.
There is a fundamental shift that occurs as you decrease the time between action and result. It's as real as the shift that occurs when you hit 24 frames per second - from slideshow to animation. To your brain, it's alive, it's moving.
When you operate in the immediate, "animation" way, development tends to operate in a more exploratory, "bottom-up" process. You don't have to have an entire plan in your head. You see the results of your actions immediately, and if they are surprising or unexpected, you can adjust your plan. You can try random things and follow them if they prove to be interesting.
In the area of game design, innovation is much more likely to come out of an exploratory process than an architected one. As Jonathan Blow said earlier. It's hard to do things that haven't been done before if you have to plan it all out in your head first.
So we want a tool that allows us to sculpt the end result, with immediate feedback.
Part of this is that everything you can make should work. It may not work in the way you desire or expect, but it should still do something.
If you are painting with pixels in an art program, no matter how you put those pixels down on the screen, it will always be a functional, viewable image. It might not be pretty, but you can still see it. You are never going to run into a error message that says, "Invalid pixels at position 55, 46. Image cannot be displayed."
But if you are writing the code for a program, this sort of thing happens all the time. Most of the things you can type won't work at all. They won't turn into a program, even a broken one. There are right ways to write code, and wrong ways to write it.
I would say that this also makes a big difference. Perhaps the biggest difference is that writing code has a much higher barrier to entry, more learning how to do things at all before you can start learning how to do them well. But it also makes experimentation so much more difficult. You can't throw a bunch of random stuff together just to see what happens. Because what happens is nothing. It just won't do anything at all.
So if you can build only with pieces that work, and immediately see what changes, this would make truly artistic interactive art much easier to create.
The last thing is expressing general logic through specific examples.
This is probably the most impossible and most revolutionary but least important of the three. If you just had a tool that you'd use in R-mode, that let you shape the end results with immediate feedback, that could be awesome, and probably enough to make a huge difference.
But at the same time I am intrigued by this further vision I have of providing specific examples, which the system will extrapolate to create possible general rules for creating those examples, which you will then provide feedback on and refine in order to guide the system's hypotheses toward the end you have in mind.
Because I don't see how to actually avoid symbols when describing logic, or how to directly manipulate end results in a general way. Because games are systems, and the end results happen when you take the rules that you have set up and run them through their paces.
So maybe this is the only way to achieve those first two goals in their entirety.
What am I talking about?
You know how you draw diagrams and mockups for different things that happen in different situations in a game? Like this. It's a pretty common way to organize your thoughts when you're designing. The thing about those is they're all organized around specific examples, not general rules. So you might draw a diagram with a guy hitting a wall, showing how he bounces off or breaks through it or whatever. It's not completely specific, as you might have an abstract line standing in for any kind of wall, and a stick figure representing any kind of guy, but at the same time it's very concrete. And you can add general connotations by writing in little notes, to explain the rules behind the example more clearly.
The reason that we don't just stop there is that our game development tools require everything to be spelled out exactly - they cannot extrapolate from these examples, because there is so much ambiguity. It could mean this or it could mean that.
However, we run into a similar problem when trying to communicate our ideas to other people who are helping us make them into a reality. Especially if we are designers and we are telling programmers what to do. How do we solve this problem with other people?
Part of this is by clarifying with more examples when an area is unclear. Kind of starting at the highest level and breaking it down into more specific situations when necessary. Another part is through conversation, asking "It sounds like you're describing this... Is that right?" and responding "Yes, exactly!" or "No, I was thinking something more like this..."
Both of these could be accomplished with a special computer program instead of a human programmer. Maybe not as well, especially in terms of accuracy of translation, but in some ways better - particularly, in the time between your description of a design and seeing something on the screen. And this increase in speed could make up for the lack of accuracy, since you can adjust and correct much more quickly. And as a result, make use of exploratory design instead of architecture.
Break dynamics down into stories instead of rules. A playthrough of the entire game could be an example story, and you could create example stories of successively smaller and smaller pieces of the game until you have specified it completely. Or completely enough.
The tool generates possible rules that could create the situations you specify, and presents several for you to try out. Most likely none of them work the way you want. Pick the one that's closest, and let it generate more possibilities based on that. It's an evolutionary search. Like Biomorphs.
And stories don't always have to be specific stories about specific instances. They can be more or less abstract and universal. Like Raven, with a capital "R", who is both the character Raven and all ravens and all tricksters at once. Or the princess in the tower, or the wise old man, or the dragon in the cave. Or the stick figure on the crosswalk sign who represents all pedestrians who could ever walk this way. There is a continuum between the specific and the symbol.
I am particularly inspired by the concept of the Dreamtime. The translation of this name is misleading, as it does not refer to a time in history. It is like a parallel slice of the world running alongside and underneath the specific, physical world, where the gods and heroes walk, creating and personifying the dynamics and processes that underlie everything we see in reality.
I want a tool where I can not only shape the world as a level designer, but also shift into the Dreamtime and shape the dynamics of that world as concretely I would shape the placement of coins and mushrooms.
When this happens, we will get our interactive art.
Related:
art,
communication,
creation,
design,
evolution,
games,
myth,
perception,
programming,
story
2010/09/10
Walk or Die and other games that are notgames
I don't spend a lot of time playing games these days. Portal sits in my computer, unfinished. A borrowed copy of Psychonauts lies unopened by a dusty PS2. I have accumulated a list of more than a hundred web games yet to try, and I haven't even checked the Jay is Games archives in several months.
So, it may come as a surprise to you that today, in a bout of either procrastination or perhaps a newly strengthened determination to make a dent in my overwhelming backlog of unplayed games, I have, in fact, gone ahead and played a handful of games. Well, technically speaking, notgames.
Not sure if I've mentioned notgames yet on my blog. Officially, they do not exist. There are no notgames, nor is there a "notgames" movement. But there is a forum. :p And a blog.
One is called Hummingbird Mind. I found it very immersive, despite - or because of? - being mostly text. Immersive like a novel. Or like I Fell in Love with the Majesty of Colors, maybe.
Perhaps it helped that I found myself in a similar mental state to the protagonist. If only I could allow myself to take a nap as I did in that game. Or notgame?
Another is Looming. Same guy who made The Majesty of Colors. The black and white pixel art brought me back to my Mac SE and calculator days. I'd like to make a game in such a style sometime.
It's a good example of distributed or embedded narrative. In fact, that's all it is, really. You are an archaeologist. Piece together clues about the past in a ruined world. Like Where We Remain. I'd like to do something similar for my own game Flydrill, eventually.
And then there is Freedom Bridge, whose author even refers to it as a notgame. Not quite Passage, but I found it very effective, particularly considering how absolutely minimal it is. I do wonder whether making the graphics more detailed would improve or detract from the experience. I'm not sure, but I'd be curious to find out. I'll be thinking about what inspiration I might take from this.
And lastly, Walk or Die, by the same author. It was this notgame, perhaps the least impressive of the four, that inspired me to write this blog post and overcome many months of non-blogging inertia in doing so.
By the way, once you try these games, you should head over to the Game Trekking website for the chance to support the author of Freedom Bridge and Walk or Die in making more experimental notgames as he travels across Asia. Less than three weeks to go if we want to get this off the ground. I've pledged one hundred dollars.
Anyway.
Here's why I wanted to write this blog post in the first place. After playing Walk or Die, I wrote this post on the notgames forum, which I am now reposting here, on my blog:
Finally got around to playing your notgames. ;)
I played it for at least ten minutes, while walking on my treadmill. :) I liked it quite a bit.
Actually, I really like it. I stimulated my creativity almost like a real walk would... though it helped that my real legs were moving at the same time. :D
I really like the day/night transition. I've been wanting to make a game with a five-minute day with the changing light and sounds and creatures - I've even commissioned a song for it, with morning, day, evening, and night, and I love the song but I haven't made the game for it yet. :p
I was thinking the same thing! Press to step, control speed, and all that. Maybe even more interesting terrain to walk on, as opposed to a completely flat surface. And I could see that being interesting, focusing on the feeling of accidentally stumbling and the fear of death.
And also I wanted to see more elaboration on the "death" part of the experience, because you can still observe, and maybe see the one spot grow and change over time though you are not going anywhere, you are transforming.
"Oh, this looks like a nice place to die. I will stop here." I thought.
And maybe combined with something like We the Giants, leaving traces for other people, seeing other people's traces. Reminds me of an idea I had about a game where you walk along a pebble beach, and you can arrange pebbles and driftwood in configurations that other people can see, or you could entropy-ishly knock over a tower someone made. And close to the waves, structures are knocked over and smoothed over naturally by the water and wind, while further, toward the cliffs, footprints and structures last longer.
Not sure how that would apply here, exactly, but it's got me thinking... :)
This is like the notgame equivalent of the game Linear RPG! :D
Now I really want to take this concept and have brontosaurus make some really nice pixel art for it! And nice sounds... No music, just high quality environmental recordings.
Procedural. I've been reading about how Left 4 Dead's AI Director works (fascinating stuff!) and I wonder now about applying it to other ends. Specifically, instead of measuring "emotional intensity" and modulating stress levels, how about modulating "boredom" or "joy" or "confusion" or "interest"? The system is really not that complex. I'm reading about it because I'm trying to do something similar for my game Flydrill.
I've wanted to make a game that feels like walking in a forest. So far The Path is the closest thing I've found. And now this.
Mind if I elaborate on this concept with a real (not)game? :)
Hum. By the way, I finished two new narrated video tutorials for my origami zergling and hydralisk. They are slow, and for the first time people are actually getting all the way through to the end! I'll post about them soon...
So, it may come as a surprise to you that today, in a bout of either procrastination or perhaps a newly strengthened determination to make a dent in my overwhelming backlog of unplayed games, I have, in fact, gone ahead and played a handful of games. Well, technically speaking, notgames.
Not sure if I've mentioned notgames yet on my blog. Officially, they do not exist. There are no notgames, nor is there a "notgames" movement. But there is a forum. :p And a blog.
One is called Hummingbird Mind. I found it very immersive, despite - or because of? - being mostly text. Immersive like a novel. Or like I Fell in Love with the Majesty of Colors, maybe.
Perhaps it helped that I found myself in a similar mental state to the protagonist. If only I could allow myself to take a nap as I did in that game. Or notgame?
Another is Looming. Same guy who made The Majesty of Colors. The black and white pixel art brought me back to my Mac SE and calculator days. I'd like to make a game in such a style sometime.
It's a good example of distributed or embedded narrative. In fact, that's all it is, really. You are an archaeologist. Piece together clues about the past in a ruined world. Like Where We Remain. I'd like to do something similar for my own game Flydrill, eventually.
And then there is Freedom Bridge, whose author even refers to it as a notgame. Not quite Passage, but I found it very effective, particularly considering how absolutely minimal it is. I do wonder whether making the graphics more detailed would improve or detract from the experience. I'm not sure, but I'd be curious to find out. I'll be thinking about what inspiration I might take from this.
And lastly, Walk or Die, by the same author. It was this notgame, perhaps the least impressive of the four, that inspired me to write this blog post and overcome many months of non-blogging inertia in doing so.
...or die
By the way, once you try these games, you should head over to the Game Trekking website for the chance to support the author of Freedom Bridge and Walk or Die in making more experimental notgames as he travels across Asia. Less than three weeks to go if we want to get this off the ground. I've pledged one hundred dollars.
Anyway.
Here's why I wanted to write this blog post in the first place. After playing Walk or Die, I wrote this post on the notgames forum, which I am now reposting here, on my blog:
Finally got around to playing your notgames. ;)
I played it for at least ten minutes, while walking on my treadmill. :) I liked it quite a bit.
Actually, I really like it. I stimulated my creativity almost like a real walk would... though it helped that my real legs were moving at the same time. :D
I really like the day/night transition. I've been wanting to make a game with a five-minute day with the changing light and sounds and creatures - I've even commissioned a song for it, with morning, day, evening, and night, and I love the song but I haven't made the game for it yet. :p
One suggestion to try which might go against what you were originally exploring is requiring a steady relaxing pattern to be maintained at about the pace of an average slow walk, rather than holding the space bar.
I was thinking the same thing! Press to step, control speed, and all that. Maybe even more interesting terrain to walk on, as opposed to a completely flat surface. And I could see that being interesting, focusing on the feeling of accidentally stumbling and the fear of death.
And also I wanted to see more elaboration on the "death" part of the experience, because you can still observe, and maybe see the one spot grow and change over time though you are not going anywhere, you are transforming.
"Oh, this looks like a nice place to die. I will stop here." I thought.
And maybe combined with something like We the Giants, leaving traces for other people, seeing other people's traces. Reminds me of an idea I had about a game where you walk along a pebble beach, and you can arrange pebbles and driftwood in configurations that other people can see, or you could entropy-ishly knock over a tower someone made. And close to the waves, structures are knocked over and smoothed over naturally by the water and wind, while further, toward the cliffs, footprints and structures last longer.
Not sure how that would apply here, exactly, but it's got me thinking... :)
This is like the notgame equivalent of the game Linear RPG! :D
Now I really want to take this concept and have brontosaurus make some really nice pixel art for it! And nice sounds... No music, just high quality environmental recordings.
Procedural. I've been reading about how Left 4 Dead's AI Director works (fascinating stuff!) and I wonder now about applying it to other ends. Specifically, instead of measuring "emotional intensity" and modulating stress levels, how about modulating "boredom" or "joy" or "confusion" or "interest"? The system is really not that complex. I'm reading about it because I'm trying to do something similar for my game Flydrill.
I've wanted to make a game that feels like walking in a forest. So far The Path is the closest thing I've found. And now this.
Mind if I elaborate on this concept with a real (not)game? :)
Hum. By the way, I finished two new narrated video tutorials for my origami zergling and hydralisk. They are slow, and for the first time people are actually getting all the way through to the end! I'll post about them soon...
2010/07/28
Origami Hydralisk Tutorial Video and StarCraft II Released!
Update:
I just posted two slow, narrated tutorial videos for origami beginners - one for the zergling, and another for the hydralisk. Check them out. ;)
In case you haven't heard, StarCraft II is finally out! :D
Conveniently, Blizzard has been kind enough to time their release to coincide with the even more exciting release of my own epic, three-part TUTORIAL VIDEO for my original origami hydralisk design! ;)
A long-awaited release, most assuredly.
Rather than try to describe it to you, I'll just embed the videos right here on this blog and you can experience their amazing splendor firsthand. Just try not to let your head explode.
FOR THE SWARM! :D
It's been three years since people first started bugging me with incessant demands for a tutorial video. But now I can rest in peace, because the tutorial video is complete! :D Or not, because now they're asking when I'll be posting the instructions for my origami zergling. Oops. :p
If you want to be the first to know when I post my zergling tutorial video, go ahead and subscribe to my YouTube channel. :)
I just posted two slow, narrated tutorial videos for origami beginners - one for the zergling, and another for the hydralisk. Check them out. ;)
Conveniently, Blizzard has been kind enough to time their release to coincide with the even more exciting release of my own epic, three-part TUTORIAL VIDEO for my original origami hydralisk design! ;)
A long-awaited release, most assuredly.
Rather than try to describe it to you, I'll just embed the videos right here on this blog and you can experience their amazing splendor firsthand. Just try not to let your head explode.
- How to make an origami hydralisk - Part 1 of 3
- How to make an origami hydralisk - Part 2 of 3
- How to make an origami hydralisk - Part 3 of 3
FOR THE SWARM! :D
It's been three years since people first started bugging me with incessant demands for a tutorial video. But now I can rest in peace, because the tutorial video is complete! :D Or not, because now they're asking when I'll be posting the instructions for my origami zergling. Oops. :p
If you want to be the first to know when I post my zergling tutorial video, go ahead and subscribe to my YouTube channel. :)
instructions coming 'soon'...
2010/06/10
Game Idea Giveaway - City Basher
Last year, I wrote up this game idea giveaway for Emanuele Feronato to post on his popular Flash game development blog. But after waiting for many months without a reply from him, I decided to post it here so I can finally share it with all of you!
Be warned, this giveaway is epically long. My longest yet.
...continued from The Game Idea Giveaway Thread
Request by triqui:
The idea: City Basher
In short, City Basher is a physics-based multiplayer artillery game combined with a trading card game (like Magic: The Gathering). It's a competitive game where you try to knock over your opponent's buildings, and it is designed to work very well with microtransactions.
This game is founded on the wide appeal of vanquishing strangers over the Internet and the primal joy of toppling carefully built towers of blocks, without the bother of having to actually build them in the first place. For that reason, the game is primarily a quick deathmatch experience, like most online multiplayer games aimed at bloodthirsty teenage males. Though there is also the option for team play and casual matches between friends.
Like other multiplayer artillery games, most notably Worms, each play session is short, measured in minutes, and involves only a handful of players. But as a game supported by microtransactions, players maintain a persistent identity across play sessions, retaining their avatar, items, resources, and statistics. This is the approach taken by Gunbound, a multiplayer artillery game that was one of the earliest successful microtransaction-based games to establish itself with Western audiences. Gunbound made its money by selling avatar decorations. City Basher will do that, and more. Much more. [cue dramatic music]
Each play session takes place in a 2D arena, seen from the side. The arena is full of buildings, structures of physically-modeled blocks, some solidly stacked, some precarious. At first, the arena is a neutral territory, dominated by a huge monolith in the center. Players take their places in the arena, each one piloting a vehicle with a mounted cannon or two. The game begins, and players open fire on the buildings to convert them to their own color. When one player topples an enemy building, a new building rises up in its place, owned by the player who placed the final shot and color-coded accordingly. The session ends when the neutral monolith in the center is toppled, and players are awarded their final scores.
The play format is very flexible. The game is not zero-sum. Players play for points, not simply to defeat their opponents. If you destroy one of my buildings, you are rewarded and I am penalized, but your success does not depend on my failure. It merely happens to coincide with it. Players are never eliminated from the game, though they are free to leave at any time - their buildings are simply replaced by neutral ones. And most arenas would support a varying number of players depending on how many people are available. If there are slots open, new players can join an existing game. This is very important for a casual multiplayer game like City Basher.
Since this is a game supported by microtransactions, we want to make everything into an item that can be bought and used up. Not that players would necessarily have to pay real money for everything in the game, but it's nice to have that option. What this does is set up the expectation that things can be bought. If players get used to paying for items with virtual currency earned in the game, they'll be more open to paying real money for the really valuable items they might want later on. In City Basher, these items consist of vehicles, weapons, buildings, arenas, avatar decorations, and general enhancements.
Gameplay
An important part of most any game is the movement, how a player gets around in the world. In City Basher, vehicles encapsulate this piece of the gameplay. Every player starts with a basic vehicle that is like a slow-moving tank. But other vehicles could be bought. They might move faster, they might be smaller or larger or shaped differently, and some might even fly or hover or jump. However, movement isn't the focus of this game, so it should be kept fairly simple. As a result, each vehicle is controlled in more or less the same way - that is, with the arrow keys or with the mouse, following the mouse cursor. Also for simplicity and to minimize the effect of lag, vehicles would not be able to collide with other vehicles or knock over buildings. Instead, they would pass through other vehicles harmlessly and treat building blocks as immovable terrain.
The real fun of the game starts with the weapons. This is the part that puts the artillery in artillery games. As is typical in the genre, the basic weapon is a slow-firing cannon, which the player must aim by setting the angle and power of the shot with the mouse or keyboard. There are a lot of ways to set up the specific controls for this action, so I won't go into too much detail here. The easiest way I can imagine is just to click the mouse to set up an attack, move the cursor to set the angle and power, and click again to fire. This way, you could fire off a quick shot by double-clicking. Since attacking is a focus of the game, different weapons could even have different methods of control, as long as they support both the keyboard and the mouse.
For a game like this, there would be dozens, if not hundreds, of different weapons to buy. Some might be variations on the basic cannonball, maybe with extremely high mass for extra power on stable buildings, or a small but extremely bouncy ball that can ricochet off multiple blocks and quickly take out more delicate structures. Some weapons might shoot several balls at a time, or an explosive shell, or several balls chained together. Others might be a different kind of weapon altogether, like a rocket launcher or a block-melting death ray. There are a ton of possibilties here - just look at a game like Worms for example. Each weapon would have a certain reload rate, a waiting period of anything from a half a second to several minutes before they can fire again. This would help to give the game a more strategic, turn-based flavor, without the turns. For this reason, there could also be weapons that are weak but useful because of their rapid firing rate. Another part of the strategy would be in selecting your arsenal, since you can only bring a limited number of different weapons into each game.
The other focus of the game is on buildings. Weapons are what you use, and buildings are what you use them on. So naturally, you'd be paying a lot of attention to them. Just like there are different types of weapons, there are also different types of buildings, each one a particular configuration of blocks of various size, shapes, and masses. Some have special side effects too, that are active while the building is in play. For example, one building might increase the mass of all your other buildings while it is in play, making them harder to knock over. There could even be a building that increases the strength of gravity over the entire arena, or doubles your score from every hit. It's a lot like the way that different cards have rule-changing effects in games like Magic: The Gathering or Pokemon.
The similarities don't end there. City Basher handles buildings just like cards in a trading card game. You don't build buildings, you collect them. Each player has a bunch of building cards in their collection. Each of these cards represents a particular building type, though a player might own several copies of the same card. When you join a game, you choose a set of cards from your collection that will be available to you during the match, in the form of a deck of cards. Like any trading card game, there is a limit to the number of cards that you can include in a single deck, and a limit to the number of duplicates you can use of the same building card. This means that you have to put some thought into which ones you choose. Some players might even spend more time just designing their decks than they do in playing the actual game!
When you choose which deck you want to use for a play session, this determines the type of buildings you can get in the game. Whenever you are due to have one of your own buildings pop up in the arena - say, when you topple an opponent's building - a random card is taken from your deck, and placed in the arena as a new building. When that building is toppled, the corresponding card is returned to your deck. That means that if you have three copies of the Citadel of Awesomeness card in your deck, you can have up to three Citadel of Awesomeness buildings in play at any time. And if you have no more cards in your deck when you destroy an enemy building, that building is replaced by a neutral one instead. The most powerful buildings are designated as Legendary buildings, and can only sprout up in special Legendary building slots, of which there might only be one or two in any given arena. Legendary building cards are ignored when drawing for normal building slots. This helps keep the game balanced.
Finally, there are the arenas, where the games take place. These are not items owned by individual players, but the effect is similar, since players may have to spend points or money to access certain arenas. At its core, an arena is a 2D map of indestructible terrain with a bunch of building slots scattered around - areas on the ground where a building may sit. One of these areas is reserved for the monolith, the giant neutral building that ends that game when it is toppled. The arena defines what this monolith looks like, as well as the deck of possible neutral buildings that may pop up. Each arena also specifies how many players are allowed at a time and where they appear at the start of the game. Lastly, each arena defines its own physical properties like gravity, air resistance, and wind, as well as the background graphics and sounds that make up the feel of the place.
Monetization
In a typical microtransaction-based game, there are two types of virtual currency involved in the in-game economy. One is earned through playing the game, like experience points. The other is bought for real money, which is how the developers make a profit. City Basher is no exception. Players can exchange their real money for a virtual currency we'll call Coins, and they can also earn another virtual currency, Points, through gameplay. The names used here are just for convenience, by the way - in the actual game you'd probably want something a bit more glamorous.
Players can earn Points in a number of ways. The most common way to earn Points is to knock down an opponent's building. You don't have to knock it down completely to get points - you only have to reduce its height with your shot. Each type of building is worth a certain number of Points to topple, and you get a fraction of that for every fraction of the building's original height that you knock over. However, you only get to replace it with a building of your own if you deliver the final blow, one that topples the building completely. The advantage to having lots of your own buildings in the arena is that at the end of the game, when the monolith falls, you receive Points for each of your buildings according to their remaining height and Point value.
This results in a system where new players can join in the middle of an existing game without having any unfair advantages or disadvantages relative to the other players. It also encourages players to stick around for the whole session in order to earn bonus points at the end for their remaining buildings. At the same time, no one is bothered if they leave, since their buildings are replaced by neutral ones which yield Points just as readily as player buildings. And it works just as well for team games, since players on the same team simply share a single color, and don't earn any Points from toppling their teammates' buildings. On the whole, it is a scoring system designed to reward good players, without punishing the players who aren't as skilled. This keeps the game accessible to casual audiences. And that means more money for you.
So, let's talk a little more about money. Specifically, let's talk about what players spend it on, and why. First of all, let me emphasize that the game itself is free to play. Players are not spending money just to play the game, they are spending it to buy virtual items inside the game. This is what it means to have a game based on microtransactions. Second, it is important to understand why players would want to buy these imaginary items at all. Players will spend money not so much as an exchange but as an investment. It's not about exchanging value. Why would a player give you real money for nothing? It's about investment. A player gets some significant value through playing the game for free, and then they think that they could enjoy even greater value in the long run if they invest a little bit of their own money right now. They should feel like they're getting a great deal every time they spend money in your game. If you can keep this one principle in mind, all the rest of your monetization decisions should follow naturally.
Here's how it works in City Basher. All items are bought with either Points, Coins, or some combination of both. Some items are permanent, some get used up, and some last for a limited amount of time. Building cards and avatar decorations are permanent, as in a typical microtransaction-based game. But weapons and vehicles get used up - weapons are sold in the form of ammo, and vehicles can be used for a limited number of play sessions before they must be refueled. Only the starting weapon and vehicle last forever. This is like the rental approach to monetization. Lastly, membership cards to access special arenas and unlock special game enhancements are effective for a limited number of days before they expire, much like a subscription. Each of these items represents a different approach to microtransactions, in the hopes of appealing to as many different buying habits as possible and maximizing the revenue of the game.
Outside of the artillery game itself, there would be a sort of store interface where players could browse and shop for items. Building cards would be bought in random packs, from different editions, much like in an actual trading card game. Some editions could be bought only with Points, but the sets containing the more powerful cards must be bought with Coins. The idea is that players who really get into collecting cards are going to be the type to spend real money on the game. Avatar decorations are bought individually, mostly for Coins, though there might be some basic clothes and such that could be bought with Points instead.
Weapons are bought in bulk - that is, packs of ammunition - and for the most part can be bought with Points. For reasons of fairness, you want to be careful about charging real money for items that provide significant in-game advantages - like weapons - though it could be appropriate to charge Coins for some particularly strange or specialized types of weapons. Vehicles are similar, but since they have less of an effect on the fairness of the game, it is more appropriate to charge Coins for some of the vehicles, especially if their advantage is purely cosmetic or a matter of personal preference in the movement controls. Vehicles themselves do not get damaged or expire, but they do have a limited amount of fuel. Every time you enter a play session, you use up one unit of fuel in your chosen vehicle. The more powerful or expensive a vehicle, the more it costs to refuel it, though fuel should cost only Points since it is a recurring expense.
Arena access must be bought with Coins. Players buy membership cards, each of which provides access to several exclusive arenas for a certain amount of time. It might also be possible to include an arena editor that can be accessed in a similar way. This could be a nice place to incorporate player-created content, if you are so inclined. Other game enhancements can be bought individually with Coins, also for a limited amount of time. These may include advantages such as a larger maximum deck size, or extra weapon slots in each game. Most importantly, these enhancements would be the type of features that very dedicated players would appreciate and pay for, but that the average player would not find useful. This makes it acceptable to charge real money for such enhancements.
Permanent items - that is, building cards and avatar decorations as well as Coins and Points - can be traded freely between players. Temporary items like weapons and vehicles, however, may not. This is partly for simplicity, and partly because you want to use weapons and vehicles as a currency sink, a place where Coins and Points are removed from the game economy. And this role is undermined if players can just buy weapons from each other. In a real-world economy, this is not as important, but in a game where you can bring currency into circulation just by knocking over a few buildings, it's essential to drain that currency out of the system just as fast as it comes in, to avoid inflation. Since weapons and vehicles get used up over time, players must continually buy new ones, removing currency from circulation at a more or less constant rate. To keep the system running smoothly, you must continually balance item prices with the amount of Points that players can earn from each building type. Keep those Points flowing in and out at the same rate. No one said this would be easy!
Implementation
To actually make City Basher, you'd need a good rigid-body physics engine, like motor2 or Glaze, or even Box2D. This could also be a great project for use with the PushButton Engine, since it has built-in Box2D support and an optional networking component for making multiplayer games.
However, making any multiplayer game on this scale is always going to be a massive undertaking. Make sure that you know what you are doing before you start. If you've never made a physics-based game before, start by making a single-player prototype of the basic building-destroying gameplay. Then, if you're new to network programming, make a simple match-based multiplayer version of the game, without the special items or persistent avatars.
If you can do that, and make it fun, then you can think about taking the next step and making it massive. When you do succeed in making a massively multiplayer game, don't add in all the special items all at once. Start with the basic free game, and add items gradually, careful not to upset the balance of the game. Incremental development is the way to go.
Good luck.
References
Required reading for anyone who wants to make a game like this:
Since Emanuele Feronato never showed up to receive his idea, City Basher is open to anyone to use for free! Even you. ;)
Let me know if you decide to try making it. I'd be glad to help however I can. Post a comment!
Be warned, this giveaway is epically long. My longest yet.
...continued from The Game Idea Giveaway Thread
Request by triqui:
- what sort of game idea you're looking for
intriguing but difficult-to-implement ideas will do
- what your goals are in making this game
I would like to make a post about gameplay ideas
The idea: City Basher
In short, City Basher is a physics-based multiplayer artillery game combined with a trading card game (like Magic: The Gathering). It's a competitive game where you try to knock over your opponent's buildings, and it is designed to work very well with microtransactions.
This game is founded on the wide appeal of vanquishing strangers over the Internet and the primal joy of toppling carefully built towers of blocks, without the bother of having to actually build them in the first place. For that reason, the game is primarily a quick deathmatch experience, like most online multiplayer games aimed at bloodthirsty teenage males. Though there is also the option for team play and casual matches between friends.
Like other multiplayer artillery games, most notably Worms, each play session is short, measured in minutes, and involves only a handful of players. But as a game supported by microtransactions, players maintain a persistent identity across play sessions, retaining their avatar, items, resources, and statistics. This is the approach taken by Gunbound, a multiplayer artillery game that was one of the earliest successful microtransaction-based games to establish itself with Western audiences. Gunbound made its money by selling avatar decorations. City Basher will do that, and more. Much more. [cue dramatic music]
Each play session takes place in a 2D arena, seen from the side. The arena is full of buildings, structures of physically-modeled blocks, some solidly stacked, some precarious. At first, the arena is a neutral territory, dominated by a huge monolith in the center. Players take their places in the arena, each one piloting a vehicle with a mounted cannon or two. The game begins, and players open fire on the buildings to convert them to their own color. When one player topples an enemy building, a new building rises up in its place, owned by the player who placed the final shot and color-coded accordingly. The session ends when the neutral monolith in the center is toppled, and players are awarded their final scores.
The play format is very flexible. The game is not zero-sum. Players play for points, not simply to defeat their opponents. If you destroy one of my buildings, you are rewarded and I am penalized, but your success does not depend on my failure. It merely happens to coincide with it. Players are never eliminated from the game, though they are free to leave at any time - their buildings are simply replaced by neutral ones. And most arenas would support a varying number of players depending on how many people are available. If there are slots open, new players can join an existing game. This is very important for a casual multiplayer game like City Basher.
Since this is a game supported by microtransactions, we want to make everything into an item that can be bought and used up. Not that players would necessarily have to pay real money for everything in the game, but it's nice to have that option. What this does is set up the expectation that things can be bought. If players get used to paying for items with virtual currency earned in the game, they'll be more open to paying real money for the really valuable items they might want later on. In City Basher, these items consist of vehicles, weapons, buildings, arenas, avatar decorations, and general enhancements.
Gameplay
An important part of most any game is the movement, how a player gets around in the world. In City Basher, vehicles encapsulate this piece of the gameplay. Every player starts with a basic vehicle that is like a slow-moving tank. But other vehicles could be bought. They might move faster, they might be smaller or larger or shaped differently, and some might even fly or hover or jump. However, movement isn't the focus of this game, so it should be kept fairly simple. As a result, each vehicle is controlled in more or less the same way - that is, with the arrow keys or with the mouse, following the mouse cursor. Also for simplicity and to minimize the effect of lag, vehicles would not be able to collide with other vehicles or knock over buildings. Instead, they would pass through other vehicles harmlessly and treat building blocks as immovable terrain.
The real fun of the game starts with the weapons. This is the part that puts the artillery in artillery games. As is typical in the genre, the basic weapon is a slow-firing cannon, which the player must aim by setting the angle and power of the shot with the mouse or keyboard. There are a lot of ways to set up the specific controls for this action, so I won't go into too much detail here. The easiest way I can imagine is just to click the mouse to set up an attack, move the cursor to set the angle and power, and click again to fire. This way, you could fire off a quick shot by double-clicking. Since attacking is a focus of the game, different weapons could even have different methods of control, as long as they support both the keyboard and the mouse.
For a game like this, there would be dozens, if not hundreds, of different weapons to buy. Some might be variations on the basic cannonball, maybe with extremely high mass for extra power on stable buildings, or a small but extremely bouncy ball that can ricochet off multiple blocks and quickly take out more delicate structures. Some weapons might shoot several balls at a time, or an explosive shell, or several balls chained together. Others might be a different kind of weapon altogether, like a rocket launcher or a block-melting death ray. There are a ton of possibilties here - just look at a game like Worms for example. Each weapon would have a certain reload rate, a waiting period of anything from a half a second to several minutes before they can fire again. This would help to give the game a more strategic, turn-based flavor, without the turns. For this reason, there could also be weapons that are weak but useful because of their rapid firing rate. Another part of the strategy would be in selecting your arsenal, since you can only bring a limited number of different weapons into each game.
The other focus of the game is on buildings. Weapons are what you use, and buildings are what you use them on. So naturally, you'd be paying a lot of attention to them. Just like there are different types of weapons, there are also different types of buildings, each one a particular configuration of blocks of various size, shapes, and masses. Some have special side effects too, that are active while the building is in play. For example, one building might increase the mass of all your other buildings while it is in play, making them harder to knock over. There could even be a building that increases the strength of gravity over the entire arena, or doubles your score from every hit. It's a lot like the way that different cards have rule-changing effects in games like Magic: The Gathering or Pokemon.
The similarities don't end there. City Basher handles buildings just like cards in a trading card game. You don't build buildings, you collect them. Each player has a bunch of building cards in their collection. Each of these cards represents a particular building type, though a player might own several copies of the same card. When you join a game, you choose a set of cards from your collection that will be available to you during the match, in the form of a deck of cards. Like any trading card game, there is a limit to the number of cards that you can include in a single deck, and a limit to the number of duplicates you can use of the same building card. This means that you have to put some thought into which ones you choose. Some players might even spend more time just designing their decks than they do in playing the actual game!
When you choose which deck you want to use for a play session, this determines the type of buildings you can get in the game. Whenever you are due to have one of your own buildings pop up in the arena - say, when you topple an opponent's building - a random card is taken from your deck, and placed in the arena as a new building. When that building is toppled, the corresponding card is returned to your deck. That means that if you have three copies of the Citadel of Awesomeness card in your deck, you can have up to three Citadel of Awesomeness buildings in play at any time. And if you have no more cards in your deck when you destroy an enemy building, that building is replaced by a neutral one instead. The most powerful buildings are designated as Legendary buildings, and can only sprout up in special Legendary building slots, of which there might only be one or two in any given arena. Legendary building cards are ignored when drawing for normal building slots. This helps keep the game balanced.
Finally, there are the arenas, where the games take place. These are not items owned by individual players, but the effect is similar, since players may have to spend points or money to access certain arenas. At its core, an arena is a 2D map of indestructible terrain with a bunch of building slots scattered around - areas on the ground where a building may sit. One of these areas is reserved for the monolith, the giant neutral building that ends that game when it is toppled. The arena defines what this monolith looks like, as well as the deck of possible neutral buildings that may pop up. Each arena also specifies how many players are allowed at a time and where they appear at the start of the game. Lastly, each arena defines its own physical properties like gravity, air resistance, and wind, as well as the background graphics and sounds that make up the feel of the place.
Monetization
In a typical microtransaction-based game, there are two types of virtual currency involved in the in-game economy. One is earned through playing the game, like experience points. The other is bought for real money, which is how the developers make a profit. City Basher is no exception. Players can exchange their real money for a virtual currency we'll call Coins, and they can also earn another virtual currency, Points, through gameplay. The names used here are just for convenience, by the way - in the actual game you'd probably want something a bit more glamorous.
Players can earn Points in a number of ways. The most common way to earn Points is to knock down an opponent's building. You don't have to knock it down completely to get points - you only have to reduce its height with your shot. Each type of building is worth a certain number of Points to topple, and you get a fraction of that for every fraction of the building's original height that you knock over. However, you only get to replace it with a building of your own if you deliver the final blow, one that topples the building completely. The advantage to having lots of your own buildings in the arena is that at the end of the game, when the monolith falls, you receive Points for each of your buildings according to their remaining height and Point value.
This results in a system where new players can join in the middle of an existing game without having any unfair advantages or disadvantages relative to the other players. It also encourages players to stick around for the whole session in order to earn bonus points at the end for their remaining buildings. At the same time, no one is bothered if they leave, since their buildings are replaced by neutral ones which yield Points just as readily as player buildings. And it works just as well for team games, since players on the same team simply share a single color, and don't earn any Points from toppling their teammates' buildings. On the whole, it is a scoring system designed to reward good players, without punishing the players who aren't as skilled. This keeps the game accessible to casual audiences. And that means more money for you.
So, let's talk a little more about money. Specifically, let's talk about what players spend it on, and why. First of all, let me emphasize that the game itself is free to play. Players are not spending money just to play the game, they are spending it to buy virtual items inside the game. This is what it means to have a game based on microtransactions. Second, it is important to understand why players would want to buy these imaginary items at all. Players will spend money not so much as an exchange but as an investment. It's not about exchanging value. Why would a player give you real money for nothing? It's about investment. A player gets some significant value through playing the game for free, and then they think that they could enjoy even greater value in the long run if they invest a little bit of their own money right now. They should feel like they're getting a great deal every time they spend money in your game. If you can keep this one principle in mind, all the rest of your monetization decisions should follow naturally.
Here's how it works in City Basher. All items are bought with either Points, Coins, or some combination of both. Some items are permanent, some get used up, and some last for a limited amount of time. Building cards and avatar decorations are permanent, as in a typical microtransaction-based game. But weapons and vehicles get used up - weapons are sold in the form of ammo, and vehicles can be used for a limited number of play sessions before they must be refueled. Only the starting weapon and vehicle last forever. This is like the rental approach to monetization. Lastly, membership cards to access special arenas and unlock special game enhancements are effective for a limited number of days before they expire, much like a subscription. Each of these items represents a different approach to microtransactions, in the hopes of appealing to as many different buying habits as possible and maximizing the revenue of the game.
Outside of the artillery game itself, there would be a sort of store interface where players could browse and shop for items. Building cards would be bought in random packs, from different editions, much like in an actual trading card game. Some editions could be bought only with Points, but the sets containing the more powerful cards must be bought with Coins. The idea is that players who really get into collecting cards are going to be the type to spend real money on the game. Avatar decorations are bought individually, mostly for Coins, though there might be some basic clothes and such that could be bought with Points instead.
Weapons are bought in bulk - that is, packs of ammunition - and for the most part can be bought with Points. For reasons of fairness, you want to be careful about charging real money for items that provide significant in-game advantages - like weapons - though it could be appropriate to charge Coins for some particularly strange or specialized types of weapons. Vehicles are similar, but since they have less of an effect on the fairness of the game, it is more appropriate to charge Coins for some of the vehicles, especially if their advantage is purely cosmetic or a matter of personal preference in the movement controls. Vehicles themselves do not get damaged or expire, but they do have a limited amount of fuel. Every time you enter a play session, you use up one unit of fuel in your chosen vehicle. The more powerful or expensive a vehicle, the more it costs to refuel it, though fuel should cost only Points since it is a recurring expense.
Arena access must be bought with Coins. Players buy membership cards, each of which provides access to several exclusive arenas for a certain amount of time. It might also be possible to include an arena editor that can be accessed in a similar way. This could be a nice place to incorporate player-created content, if you are so inclined. Other game enhancements can be bought individually with Coins, also for a limited amount of time. These may include advantages such as a larger maximum deck size, or extra weapon slots in each game. Most importantly, these enhancements would be the type of features that very dedicated players would appreciate and pay for, but that the average player would not find useful. This makes it acceptable to charge real money for such enhancements.
Permanent items - that is, building cards and avatar decorations as well as Coins and Points - can be traded freely between players. Temporary items like weapons and vehicles, however, may not. This is partly for simplicity, and partly because you want to use weapons and vehicles as a currency sink, a place where Coins and Points are removed from the game economy. And this role is undermined if players can just buy weapons from each other. In a real-world economy, this is not as important, but in a game where you can bring currency into circulation just by knocking over a few buildings, it's essential to drain that currency out of the system just as fast as it comes in, to avoid inflation. Since weapons and vehicles get used up over time, players must continually buy new ones, removing currency from circulation at a more or less constant rate. To keep the system running smoothly, you must continually balance item prices with the amount of Points that players can earn from each building type. Keep those Points flowing in and out at the same rate. No one said this would be easy!
Implementation
To actually make City Basher, you'd need a good rigid-body physics engine, like motor2 or Glaze, or even Box2D. This could also be a great project for use with the PushButton Engine, since it has built-in Box2D support and an optional networking component for making multiplayer games.
However, making any multiplayer game on this scale is always going to be a massive undertaking. Make sure that you know what you are doing before you start. If you've never made a physics-based game before, start by making a single-player prototype of the basic building-destroying gameplay. Then, if you're new to network programming, make a simple match-based multiplayer version of the game, without the special items or persistent avatars.
If you can do that, and make it fun, then you can think about taking the next step and making it massive. When you do succeed in making a massively multiplayer game, don't add in all the special items all at once. Start with the basic free game, and add items gradually, careful not to upset the balance of the game. Incremental development is the way to go.
Good luck.
References
Required reading for anyone who wants to make a game like this:
- Testosterone and Competitive Play
- Space Crack: Financial Mechanics
- Flash Love Letter (2009) Part 1
- Flash Love Letter (2009) Part 2
- Designing for Virtual Item Sales
- Ten Ways to Monetize Your Flash Game
Since Emanuele Feronato never showed up to receive his idea, City Basher is open to anyone to use for free! Even you. ;)
Let me know if you decide to try making it. I'd be glad to help however I can. Post a comment!
Subscribe to:
Posts (Atom)








