I made a game.
It's called Space Lord. I've been working on it since March, on and off, and now it's finally out. Originally it was a game jam game I made last December for Ludum Dare 25, with Pat Kemp (knivel) and Teo Acosta, the same guys who made The Love Letter with me, plus another artist friend Jim Burner.
The theme was YOU ARE THE VILLAIN and once again, knivel came up with a great little concept that eventually turned into the final Space Lord that we all know and love.
Or something like that.
Play it! Don't give up right away, there's a bit of a twist. ;)
At the beginning of this year I decided to go for the #OneGameAMonth challenge. I was doing fine for the first few months, but it all broke down with Space Lord. After all the success of The Love Letter, I wanted to take all my other old game jam games and polish them up too. So I thought I'd start with Space Lord, since it seemed to be the most promising, and the closest to being really finished. Sure, it was. But it took me way more than a month to finish it, and I fought until the very end to keep to my one-game-a-month commitment, but ultimately, I failed. And it was very painful to finally reach that point.
For the first month or two, I was really getting into it, working on Space Lord whenever I could, staying up too late and getting sleep-deprived in return. I got pretty burned out after a month or two of that, and just wanted the project to be over. But I refused to give it up, or to release a game that I know I could improve upon, so I kept going. But I worked on it much more sporadically after that point. I went for long periods of time without working on any creative projects, and started feeling listless and stagnant, which made it even harder to get back into it. But whenever I did, I felt better. Making stuff makes me happy. That's just the way it works for me.
So, eventually, four months after I started, I finished. More than anything, this was a design challenge for me. I've gotten to the point where I can code these little Flixel games without too much trouble, but game design is still really hard. By that I mean the process of taking an interesting concept with a lot of rough edges and turning it into something actually fun and accessible to a decent number of people. It's even harder when you're the one coding everything, because you feel the pain of every potential design change that has you undoing a bunch of your hard work or creating a bunch more for yourself.
For Space Lord, one example was going from real-time to turn-based gameplay. I knew the game went way too fast for anyone to tell what was going on, but it still took a fair amount of willpower to actually choose to invest the effort into making it turn-based. This is another reason why it really helps to have good collaborators to work with - knivel didn't end up joining forces for the Space Lord redesign, but he was there to bounce ideas off of and help strengthen my resolve to do what I knew was right.
So, the game is on Kongregate. That was really disappointing, actually - it got only a couple hundred plays, a few comments, and a rating less than any of my other games on the site, even the really old ones. Then it sank without a trace. Ouch.
Then I put it on Newgrounds, without much optimism. It was received a bit better there, as is typical in comparing the two portals. But no momentum. I was prepared to give up on the portals and see if I could get some people to blog and tweet about it, as I think the game is quite interesting to write about, even if the players haven't been particularly excited. :p
But then it was featured on the front page of Newgrounds! And suddenly there are dozens of comments, and thousands of views. Yay? :) It's interesting what people are suggesting in the comments - there are actually people who want the game to be longer, and just want more - more space, more ships, powerups to place. Definitely a fair number of complaints about the AI. Yeah, I know, it's really simple. :p And some people who perhaps don't get it at all.
In case you're wondering, Space Lord is a level design puzzle game. Possibly the only one of its kind I've seen so far. You are the game designer. The AI player gives you a fun rating and trashes your game when it's not fun enough. It doesn't really hold your hand or structure your experience because I wanted it to feel more like the experience of actually designing a game. :p
And if you "beat" the game (if the "player" beats the game) then you can submit your design to the Hall of Fame, where other people can play it, as the player ship. More on that later. ;) But in any case, it's been fun seeing the designs that people come up with.
I might even say it's been worth it.
Of course it's been worth it! :) This is what I'm doing, polishing up my old game jam games, working on my game design skill, trying to eventually get up to the point where I can make games for education and social change and actually succeed.
I've already started polishing up my next one. Hopefully it will go a little quicker this time. ;)
Showing posts with label game. Show all posts
Showing posts with label game. Show all posts
2013/07/22
2013/03/14
A Minor Flydrill Update
Not too long after my last Flydrill update, almost two years ago, I kept tweaking the game but never released anything after that.
Until now. :o
Don't get excited, it's just a tiny update. ;) I added white outlines to the enemies so you can see them better, with a slightly darker background color. I also made the giant wall thinner in the beginning. Honestly I was just tired of having to drill for ten full seconds every time I started the game. That's why I went ahead and released this update.
I guess it's spring cleaning time for me, polishing up and releasing old stuff I've had sitting around on my hard drive for the past year or two... :)
On that note, I noticed that Google Reader will be shutting down in a few months! :( As disappointing as that is, I think it's a good opportunity to revisit my content-consumption habits and perhaps let go of my daily blog reading. Looking through all my feed subscriptions, it strikes me how few blogs are still active - really there are less than a dozen that I see updates from regularly. And I've gotten to the point where none of the stuff I read is really that valuable to me - the game design articles are not blowing my mind with new insights, the productivity articles are teaching lessons that I've already learned, and really, I think I'd get a lot more out of spending that time working on actual projects or reading books or even... playing games. I mean, it's been years since I've really sat down and just played a game, for serious. I think the last one must have been Portal. Yeah. The truth is out! :o
Well, I hope you enjoy the Flydrill update! :) May there be plenty more to come, soon.
Oh, and I almost forgot - Happy Pi Day! :D
Until now. :o
Don't get excited, it's just a tiny update. ;) I added white outlines to the enemies so you can see them better, with a slightly darker background color. I also made the giant wall thinner in the beginning. Honestly I was just tired of having to drill for ten full seconds every time I started the game. That's why I went ahead and released this update.
I guess it's spring cleaning time for me, polishing up and releasing old stuff I've had sitting around on my hard drive for the past year or two... :)
On that note, I noticed that Google Reader will be shutting down in a few months! :( As disappointing as that is, I think it's a good opportunity to revisit my content-consumption habits and perhaps let go of my daily blog reading. Looking through all my feed subscriptions, it strikes me how few blogs are still active - really there are less than a dozen that I see updates from regularly. And I've gotten to the point where none of the stuff I read is really that valuable to me - the game design articles are not blowing my mind with new insights, the productivity articles are teaching lessons that I've already learned, and really, I think I'd get a lot more out of spending that time working on actual projects or reading books or even... playing games. I mean, it's been years since I've really sat down and just played a game, for serious. I think the last one must have been Portal. Yeah. The truth is out! :o
Well, I hope you enjoy the Flydrill update! :) May there be plenty more to come, soon.
Oh, and I almost forgot - Happy Pi Day! :D
2013/01/31
Making games, not excuses
At the last minute, I've decided to accept the challenge of #OneGameAMonth. It's time to make games, not excuses.
What a great tagline.
Anyway, here I am on the site! I'm already a Level 6 Game Developer - cool, huh? :)
Not much on there yet, just the game I made for Global Game Jam 2013, which I haven't yet shared with you here because it's crude and unpolished. :p But it is complete, which is more than I can say for most other game jam games I've made.
Probably helped that we made it by modifying the code for The Love Letter, which incidentally is on GitHub, in case you missed it. ;)
Here's to making many more games this year! :D
What a great tagline.
Anyway, here I am on the site! I'm already a Level 6 Game Developer - cool, huh? :)
Not much on there yet, just the game I made for Global Game Jam 2013, which I haven't yet shared with you here because it's crude and unpolished. :p But it is complete, which is more than I can say for most other game jam games I've made.
Probably helped that we made it by modifying the code for The Love Letter, which incidentally is on GitHub, in case you missed it. ;)
Here's to making many more games this year! :D
2012/02/14
The Love Letter released!
I've been pretty quiet on the blog here lately.
But under the surface, my game development life has been roiling with barely constrained productivity and awesomeness! :D
In December, I participated in my first official game jam, the 72-hour jam for Ludum Dare 22. It was awesome. I teamed up with the artist, fledgling game designer, Flixel programmer, and all-around amazingly creative guy knivel, and I had the most intensely fun, productive weekend of programming and game development I'd had all year. No exaggeration.
The theme was ALONE, and after I suggested a game where you try to get away from all these people who keep bothering you, knivel basically came up with the entire concept of The Love Letter right then and there.
Oh, did I say "The Love Letter"? That's the game we made. Of course, we didn't have time to add a tutorial, or make it so you could actually win the game, but even then people seemed to like it, and told us to finish it, and voted us to first place in the "Theme" category of the game jam! Yay! :D
You can read more about our adventures here, in my Ludum Dare blog posts.
But anyway, that brings me to the point of this post, which is to kindly inform you that WE FINISHED THE LOVE LETTER AND IT'S VALENTINE'S DAY AND YOU SHOULD PLAY THE GAME NOW IT'S REALLY COOL!!!!!!!! :DDDD
This project has marked a turning point for me in many ways. For one thing, the game has done much better in playtesting than any of my previous games. People like it, and it's easy to understand and get into. Kind of like Pillars in that way, except an actual game instead of just a little prototype. Of course, we still haven't had a full public release yet, but even so far it has had a very promising reception. (By the way, have you played it yet? You should.)
But more importantly, I discovered that I can enjoy being the programmer on a game, working with a designer, and that this can be just as much fun or even more so than simply trying to be the designer myself. What I realized is that when I fully trust the designer - knivel, in this case - to the extent that I feel like he would make the same design decisions that I would make except faster and better, and when we occasionally disagree it is an opportunity for us both to expand our own perspectives and make a better game together then we could on our own. It's hard to be the programmer and the designer at the same time. It takes time to mentally switch between roles. When I work alongside a designer whose creativity and design sense I really admire and trust, it frees me to focus on the groundwork of programming while he scopes out the game design possibility space from above.
It also really helps to work with an artist and designer who also knows programming and can hack in features without my help if necessary! :) Just like I can fix pixel art mistakes if I see them. After my experiences making games with knivel, I don't think I would choose to work with a code-illiterate designer unless I had a really good reason to. It's so nice to be able to explain to a designer what I'm doing, what problems I'm running into, or what awesome thing I just figured out, and have that designer actually understand me. It's all about that connection, like we are just parts of one unit, the team. Without that common understanding, it's easy for friction to come up in our interactions.
So there, I'm getting more picky. ;) But in a good way. :) I'm learning what works for me.
The Love Letter was also the first project where I got really into working on it, fitting it into every crack in my schedule I could find after the game jam ended and we started fixing up the game for the release I now have the pleasure of announcing. I'd bring my laptop on the bus and work on it there. I'd work on it while eating dinner. I'd keep working on it and stay up late. I was so into it, I didn't want to stop. And I couldn't wait to get back to it. :)
Finally! :p A year ago I remember being similarly obsessed with reading Harry Potter and the Methods of Rationality, and thinking to myself, "If I wanted to make games as much as I want to read the next chapter of Harry Potter and the Methods of Rationality, I'd be making a lot more games." And now I've gotten to that point. I know what it feels like. I can tap into this with my future projects too. Which is great to think about.
But I also need to get some sleep, if I want to stay motivated, not to mention... alive? So I think I'll wrap this up.
I also participated in the Global Game Jam for the first time this year, and made another little game with knivel and the same composer (and this time you can actually get to the end). It's not quite ready for prime time yet - we're planning to give it the same sort of treatment as The Love Letter, but I'll be sure to let you know when it's done. :) Now that we're finished (or are we?) with The Love Letter, I'll probably be getting back to this game pretty soon. After I get some sleep, of course. ;)
Oh, and also, I wrote about my first ever game jam, back in October, on the Fugazo blog. It was not nearly as successful as my latest adventures, but it was educational. Hehe. :)
But under the surface, my game development life has been roiling with barely constrained productivity and awesomeness! :D
In December, I participated in my first official game jam, the 72-hour jam for Ludum Dare 22. It was awesome. I teamed up with the artist, fledgling game designer, Flixel programmer, and all-around amazingly creative guy knivel, and I had the most intensely fun, productive weekend of programming and game development I'd had all year. No exaggeration.
The theme was ALONE, and after I suggested a game where you try to get away from all these people who keep bothering you, knivel basically came up with the entire concept of The Love Letter right then and there.
Oh, did I say "The Love Letter"? That's the game we made. Of course, we didn't have time to add a tutorial, or make it so you could actually win the game, but even then people seemed to like it, and told us to finish it, and voted us to first place in the "Theme" category of the game jam! Yay! :D
You can read more about our adventures here, in my Ludum Dare blog posts.
But anyway, that brings me to the point of this post, which is to kindly inform you that WE FINISHED THE LOVE LETTER AND IT'S VALENTINE'S DAY AND YOU SHOULD PLAY THE GAME NOW IT'S REALLY COOL!!!!!!!! :DDDD
This project has marked a turning point for me in many ways. For one thing, the game has done much better in playtesting than any of my previous games. People like it, and it's easy to understand and get into. Kind of like Pillars in that way, except an actual game instead of just a little prototype. Of course, we still haven't had a full public release yet, but even so far it has had a very promising reception. (By the way, have you played it yet? You should.)
But more importantly, I discovered that I can enjoy being the programmer on a game, working with a designer, and that this can be just as much fun or even more so than simply trying to be the designer myself. What I realized is that when I fully trust the designer - knivel, in this case - to the extent that I feel like he would make the same design decisions that I would make except faster and better, and when we occasionally disagree it is an opportunity for us both to expand our own perspectives and make a better game together then we could on our own. It's hard to be the programmer and the designer at the same time. It takes time to mentally switch between roles. When I work alongside a designer whose creativity and design sense I really admire and trust, it frees me to focus on the groundwork of programming while he scopes out the game design possibility space from above.
It also really helps to work with an artist and designer who also knows programming and can hack in features without my help if necessary! :) Just like I can fix pixel art mistakes if I see them. After my experiences making games with knivel, I don't think I would choose to work with a code-illiterate designer unless I had a really good reason to. It's so nice to be able to explain to a designer what I'm doing, what problems I'm running into, or what awesome thing I just figured out, and have that designer actually understand me. It's all about that connection, like we are just parts of one unit, the team. Without that common understanding, it's easy for friction to come up in our interactions.
So there, I'm getting more picky. ;) But in a good way. :) I'm learning what works for me.
The Love Letter was also the first project where I got really into working on it, fitting it into every crack in my schedule I could find after the game jam ended and we started fixing up the game for the release I now have the pleasure of announcing. I'd bring my laptop on the bus and work on it there. I'd work on it while eating dinner. I'd keep working on it and stay up late. I was so into it, I didn't want to stop. And I couldn't wait to get back to it. :)
Finally! :p A year ago I remember being similarly obsessed with reading Harry Potter and the Methods of Rationality, and thinking to myself, "If I wanted to make games as much as I want to read the next chapter of Harry Potter and the Methods of Rationality, I'd be making a lot more games." And now I've gotten to that point. I know what it feels like. I can tap into this with my future projects too. Which is great to think about.
But I also need to get some sleep, if I want to stay motivated, not to mention... alive? So I think I'll wrap this up.
I also participated in the Global Game Jam for the first time this year, and made another little game with knivel and the same composer (and this time you can actually get to the end). It's not quite ready for prime time yet - we're planning to give it the same sort of treatment as The Love Letter, but I'll be sure to let you know when it's done. :) Now that we're finished (or are we?) with The Love Letter, I'll probably be getting back to this game pretty soon. After I get some sleep, of course. ;)
Oh, and also, I wrote about my first ever game jam, back in October, on the Fugazo blog. It was not nearly as successful as my latest adventures, but it was educational. Hehe. :)
Related:
flash,
game,
motivation,
news,
programming,
the love letter
2011/09/11
Revising Flydrill
After a year and a half, I finally updated my game Flydrill. Yay.
Ever since releasing Flydrill in March of 2010, I've been dissatisfied with the game, and embarrassed to show it to people. It wasn't a bad game - in fact it has been my best so far, but there were just so many problems I saw in it, so many things I wanted to change.
In particular, I thought that they key ingredient the game lacked was logistical gameplay. Later on, I realized that this was just one of many shortcomings, and that the core of the game and the overall structure of it could stand to be improved as well.
So what I've done this past week is improve the core gameplay.
First of all, the arbitrary dream-logic rule that you could only drill to the right is gone, and now you can drill in all four directions. This opens up a lot more possibilities for burrowing and evading through tiles, slipping out of danger through narrow gaps which you can widen into caverns as in the screen shot above. It's also a lot less confusing for new players. Why can I sometimes drill and sometimes not? That question doesn't come up anymore.
Next, I got rid of the extra lives. Now it's one hit and you're dead. Why so cruel, you ask? One answer is that this is inherently a very hardcore game, requiring the coordinated use of many skills and actions, under significant time pressure. I'd originally tried to make it more casual, and weakened the game as a result. Now, I embrace its hardcore nature. Having a single life sharpens the focus of the entire experience. You stop paying attention and you die.
Getting rid of the extra lives also means that you can no longer feel the despair of being down to your last life, with no hope of recovery. The complacency associated with having two extra lives safely tucked into your back pocket is no longer an option. No false sense of security.
And it's much less confusing. Before, I noticed that many people would lose a life and not realize it, never learning the lesson that running into a swarmer is hazardous to your health. Now, there's no question. When you touch a swarmer, you know something bad happened. And because you've learned something, you decide to try again, armed with your new knowledge. Clarity is more important than coddling.
Finally, having a single life makes it much easier for me to balance the game. I've increased the frequency of invincibility halos and decreased the frequency of portals, so that the experience alternates between frantically dashing through clouds of enemies long enough to find a halo and racing to get the most out of your halo while it lasts, maybe taking out an enemy or two just because you can. Halos are not rare experiences anymore. This alternating rhythm is now the core of the game. If you had more than one life, it wouldn't work as well because the game would drag on and on, and the extreme focus of the halo-less portions would be dulled by a false sense of security.
Along those lines, I've also greatly improved the pacing of the game. In Flydrill's very first release, the game started out very slow, and to many players, boring. In response, I crudely ramped up the pace, throwing everything at the player right away. This was not optimal. But I figured that overwhelming the player was at least better than boring them. Now, however, I think I've succeeded in making the game interesting from the very beginning, while also gradually introducing new enemies to the experience to keep it feeling fresh.
The first thing I did was increase the speed of the swarmers. Back when the game gave you multiple lives, the swarmers would start out really slow, and very gradually get faster as you progressed, slowing down whenever you lost a life. Like Pac-Man CE. However, with three lives, this meant that the swarmers started out so slow as to be totally harmless, and eventually got ridiculously fast, neither of which were fun situations.
So I made them speed up much more quickly. To compensate, I made them slow down every time a swarmer dies, whether by colliding with another enemy or with your halo of death. This creates a nice feedback loop - the swarmers get fast, but once they reach the point where they're so fast that they're running into each other, they slow down. And it means that if you can dodge the swarmers long enough, they'll slow down so you can escape safely. But as soon as you travel out of range, they'll have gotten fast enough to catch up with you again and the cycle repeats. This alternating cycle nests nicely with the larger cycle of halo having and not-having, and makes the core gameplay much more enjoyable.
The next pacing improvement I made was to space out the introduction of enemies. Now that the game was interesting just with swarmers, I could wait to introduce the other enemies, without fear of boring the player in the beginning of the game. Puffers come in shortly after swarmers, teaching you to watch where you're going as you dash madly away from danger, and then later the gunners, teaching you to use walls for cover instead of hanging around in the open, and then finally the diggers, teaching you that sometimes a cozy little burrow can be the worst possible place to hide.
Lastly, I made big solid walls appear every so often, to provide some milestones in your rightward journey, and throw in some opportunities for serious drilling. At first I'd assumed that these walls would be very dangerous places, where you are stuck frantically drilling as your enemies nip at your heels, so to speak. But as it turned out, with the four-way drilling now available, these walls became safe havens that I'd look forward to - places where I could burrow safely, feeling through the gaps in the tiles that my enemies could not fit into, where I could be pretty sure to find a halo or two in the safety of the solid wall. Unless a digger stopped by for a visit. But that made it all the more exciting. :)
And the portals, those bubble things that change the background color and clear all enemies from the screen, now have a more pronounced effect on what type of enemy you are likely to find. The colors have stronger associations - red for gunners, green for diggers, and blue for puffers - and the difficulty does not go down so much when you enter a portal. So it's not always something you want to go for, especially if you see a green portal in a nice, safe blue zone. You have to make a choice. And that makes it more interesting.
Also the portals now have big halos around them to make them easier to hit. New players often have trouble with the timing-sensitive flapping controls, and hitting a portal shouldn't be a challenge in itself. But the portals also don't appear as early to tempt these new players either, since the color changes and corresponding enemy distribution changes would totally throw off the gradual pacing I have set up.
The last change was to add a persistent high-score display, inspired by iPhone game Bit Pilot, to replace the now-useless extra lives in the upper-left corner. This game is entirely about pushing your score a bit further than last time, and I decided that I'd give this goal the attention it deserved by making your best score constantly visible as you play.
The other last change, the last last change, was to add achievement notifications.
"Achievements?" you gasp, "How crude!"
Yeah, that's what I thought at first too. But wait, there's more to this than you might at first think. I didn't go with the typical trophy-style achievements, where there is a list of things to achieve, and then you achieve them, and you are told that your achievements have been "unlocked" and now you can see them shining magnificently in your list. I mean, that would require a whole new interface to design and implement! No way!
Instead, I went with the second option.
From Chris Hecker's Achievements Considered Harmful?:
There's no list. When you do something cool, like travel 1000mm, or kill 10 enemies, or hold a halo for 20 seconds, the game tells you. When you do something even more cool, like travel 2000mm, or even 3000mm, or kill 20 enemies, or hold a halo for 40 seconds, the game tells you again. And that's it.
Short of adding coins everywhere, it's one of the few things I can do to make the player actually feel good about what they're doing in the game, instead of just making them frantic and terrified or temporarily relieved at having escaped with their single life for a few precious seconds of respite inside the safety of a wall.
The only shortcoming is that this feedback is not entirely unexpected, since the pattern is pretty easy to pick up on, and it tells you every time. I might experiment with the game only telling you the first time you do something, making its announcements much more rare and precious. But for now I think the system works pretty well.
And I didn't even have to design a new interface for it. That's the best part. ;)
The changes I'm considering next are more drastic, like adding baby fliers to guide for upgrade points and adding upgrades to spend those points on. Logistical gameplay. But I'm not sure how it will all turn out.
For the moment, I'm just glad that Flydrill is finally, at its core, a solid game. I'm not embarrassed to tell people about it anymore. :)
So try it out and tell me - what do you think?
You just added achievements!
Ever since releasing Flydrill in March of 2010, I've been dissatisfied with the game, and embarrassed to show it to people. It wasn't a bad game - in fact it has been my best so far, but there were just so many problems I saw in it, so many things I wanted to change.
In particular, I thought that they key ingredient the game lacked was logistical gameplay. Later on, I realized that this was just one of many shortcomings, and that the core of the game and the overall structure of it could stand to be improved as well.
So what I've done this past week is improve the core gameplay.
First of all, the arbitrary dream-logic rule that you could only drill to the right is gone, and now you can drill in all four directions. This opens up a lot more possibilities for burrowing and evading through tiles, slipping out of danger through narrow gaps which you can widen into caverns as in the screen shot above. It's also a lot less confusing for new players. Why can I sometimes drill and sometimes not? That question doesn't come up anymore.
Next, I got rid of the extra lives. Now it's one hit and you're dead. Why so cruel, you ask? One answer is that this is inherently a very hardcore game, requiring the coordinated use of many skills and actions, under significant time pressure. I'd originally tried to make it more casual, and weakened the game as a result. Now, I embrace its hardcore nature. Having a single life sharpens the focus of the entire experience. You stop paying attention and you die.
Getting rid of the extra lives also means that you can no longer feel the despair of being down to your last life, with no hope of recovery. The complacency associated with having two extra lives safely tucked into your back pocket is no longer an option. No false sense of security.
And it's much less confusing. Before, I noticed that many people would lose a life and not realize it, never learning the lesson that running into a swarmer is hazardous to your health. Now, there's no question. When you touch a swarmer, you know something bad happened. And because you've learned something, you decide to try again, armed with your new knowledge. Clarity is more important than coddling.
Finally, having a single life makes it much easier for me to balance the game. I've increased the frequency of invincibility halos and decreased the frequency of portals, so that the experience alternates between frantically dashing through clouds of enemies long enough to find a halo and racing to get the most out of your halo while it lasts, maybe taking out an enemy or two just because you can. Halos are not rare experiences anymore. This alternating rhythm is now the core of the game. If you had more than one life, it wouldn't work as well because the game would drag on and on, and the extreme focus of the halo-less portions would be dulled by a false sense of security.
Along those lines, I've also greatly improved the pacing of the game. In Flydrill's very first release, the game started out very slow, and to many players, boring. In response, I crudely ramped up the pace, throwing everything at the player right away. This was not optimal. But I figured that overwhelming the player was at least better than boring them. Now, however, I think I've succeeded in making the game interesting from the very beginning, while also gradually introducing new enemies to the experience to keep it feeling fresh.
The first thing I did was increase the speed of the swarmers. Back when the game gave you multiple lives, the swarmers would start out really slow, and very gradually get faster as you progressed, slowing down whenever you lost a life. Like Pac-Man CE. However, with three lives, this meant that the swarmers started out so slow as to be totally harmless, and eventually got ridiculously fast, neither of which were fun situations.
So I made them speed up much more quickly. To compensate, I made them slow down every time a swarmer dies, whether by colliding with another enemy or with your halo of death. This creates a nice feedback loop - the swarmers get fast, but once they reach the point where they're so fast that they're running into each other, they slow down. And it means that if you can dodge the swarmers long enough, they'll slow down so you can escape safely. But as soon as you travel out of range, they'll have gotten fast enough to catch up with you again and the cycle repeats. This alternating cycle nests nicely with the larger cycle of halo having and not-having, and makes the core gameplay much more enjoyable.
The next pacing improvement I made was to space out the introduction of enemies. Now that the game was interesting just with swarmers, I could wait to introduce the other enemies, without fear of boring the player in the beginning of the game. Puffers come in shortly after swarmers, teaching you to watch where you're going as you dash madly away from danger, and then later the gunners, teaching you to use walls for cover instead of hanging around in the open, and then finally the diggers, teaching you that sometimes a cozy little burrow can be the worst possible place to hide.
Lastly, I made big solid walls appear every so often, to provide some milestones in your rightward journey, and throw in some opportunities for serious drilling. At first I'd assumed that these walls would be very dangerous places, where you are stuck frantically drilling as your enemies nip at your heels, so to speak. But as it turned out, with the four-way drilling now available, these walls became safe havens that I'd look forward to - places where I could burrow safely, feeling through the gaps in the tiles that my enemies could not fit into, where I could be pretty sure to find a halo or two in the safety of the solid wall. Unless a digger stopped by for a visit. But that made it all the more exciting. :)
And the portals, those bubble things that change the background color and clear all enemies from the screen, now have a more pronounced effect on what type of enemy you are likely to find. The colors have stronger associations - red for gunners, green for diggers, and blue for puffers - and the difficulty does not go down so much when you enter a portal. So it's not always something you want to go for, especially if you see a green portal in a nice, safe blue zone. You have to make a choice. And that makes it more interesting.
Also the portals now have big halos around them to make them easier to hit. New players often have trouble with the timing-sensitive flapping controls, and hitting a portal shouldn't be a challenge in itself. But the portals also don't appear as early to tempt these new players either, since the color changes and corresponding enemy distribution changes would totally throw off the gradual pacing I have set up.
The last change was to add a persistent high-score display, inspired by iPhone game Bit Pilot, to replace the now-useless extra lives in the upper-left corner. This game is entirely about pushing your score a bit further than last time, and I decided that I'd give this goal the attention it deserved by making your best score constantly visible as you play.
The other last change, the last last change, was to add achievement notifications.
"Achievements?" you gasp, "How crude!"
Yeah, that's what I thought at first too. But wait, there's more to this than you might at first think. I didn't go with the typical trophy-style achievements, where there is a list of things to achieve, and then you achieve them, and you are told that your achievements have been "unlocked" and now you can see them shining magnificently in your list. I mean, that would require a whole new interface to design and implement! No way!
Instead, I went with the second option.
From Chris Hecker's Achievements Considered Harmful?:
For interesting tasks,
- Tangible, expected, contingent rewards reduce free-choice intrinsic motivation, and
- Verbal, unexpected, informational feedback, increases free-choice and self-reported intrinsic motivation.
There's no list. When you do something cool, like travel 1000mm, or kill 10 enemies, or hold a halo for 20 seconds, the game tells you. When you do something even more cool, like travel 2000mm, or even 3000mm, or kill 20 enemies, or hold a halo for 40 seconds, the game tells you again. And that's it.
Short of adding coins everywhere, it's one of the few things I can do to make the player actually feel good about what they're doing in the game, instead of just making them frantic and terrified or temporarily relieved at having escaped with their single life for a few precious seconds of respite inside the safety of a wall.
The only shortcoming is that this feedback is not entirely unexpected, since the pattern is pretty easy to pick up on, and it tells you every time. I might experiment with the game only telling you the first time you do something, making its announcements much more rare and precious. But for now I think the system works pretty well.
And I didn't even have to design a new interface for it. That's the best part. ;)
The changes I'm considering next are more drastic, like adding baby fliers to guide for upgrade points and adding upgrades to spend those points on. Logistical gameplay. But I'm not sure how it will all turn out.
For the moment, I'm just glad that Flydrill is finally, at its core, a solid game. I'm not embarrassed to tell people about it anymore. :)
So try it out and tell me - what do you think?
2011/05/10
Space Isn't
Experimental Gameplay Project: ZOOM in May
Step 1. Inspiration
(from Less Talk More Rock)
brontosaurus wrote:
brontosaurus wrote:
axcho wrote:
When I came to the word "dawn", the image of it brought a smile to my lips like the last line of a haiku. Thank you.
brontosaurus wrote:
axcho wrote:
axcho wrote:
Zoom into a star that you see.
Watch it get bigger, reveal itself to be a flaming ball of gas.
Planets?
Pan to empty blackness.
Zoom into the blackness, more blackness, more...
Then a faint hint of something on the left, a speck, a smudge.
Center on it, zoom in, don't lose it...
See it resolve, grow brighter, more defined.
It is an entire galaxy.
Zoom out so it is again small.
Double-tap to name it.
This is like exploring a fractal.
This is like Jason Rohrer's Inside a Star-Filled Sky.
But without the shooting gameplay.
It is like Eric Svedang's Kometen.
But without the orbiting mechanic.
It is like The Scale of the Universe.
Is there a story? Characters to know?
Only the story of your fellow observers.
Read the names of stars, competing names.
Touch one to lend it your support.
You can name one star every day.
One name to add, like one cow to click.
A name grows with every click, until it is tweeted.
As your names are favored by your peers, you grow in influence.
Step 1. Inspiration
(from Less Talk More Rock)
brontosaurus wrote:
skydome
zoom in and out
galaxies
nebula
dawn
brontosaurus wrote:
super nova
black holes
intelligence
from this distant vantage point,
adrift in an ocean of space and time....
adrift in an ocean of space and time....
axcho wrote:
When I came to the word "dawn", the image of it brought a smile to my lips like the last line of a haiku. Thank you.
brontosaurus wrote:
:)
axcho wrote:
axcho wrote:
Zoom into a star that you see.
Watch it get bigger, reveal itself to be a flaming ball of gas.
Planets?
Pan to empty blackness.
Zoom into the blackness, more blackness, more...
Then a faint hint of something on the left, a speck, a smudge.
Center on it, zoom in, don't lose it...
See it resolve, grow brighter, more defined.
It is an entire galaxy.
Zoom out so it is again small.
Double-tap to name it.
This is like exploring a fractal.
This is like Jason Rohrer's Inside a Star-Filled Sky.
But without the shooting gameplay.
It is like Eric Svedang's Kometen.
But without the orbiting mechanic.
It is like The Scale of the Universe.
Is there a story? Characters to know?
Only the story of your fellow observers.
Read the names of stars, competing names.
Touch one to lend it your support.
You can name one star every day.
One name to add, like one cow to click.
A name grows with every click, until it is tweeted.
As your names are favored by your peers, you grow in influence.
Step 3. Rock
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/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!
2010/03/10
Flydrill and Logistical Gameplay

I've been making a game.
It's called Flydrill.
Explore an infinite dream world. Survive an endless nightmare. How far can you fly?
On the 23rd of October, in 2008, I had a dream where I was this little abstract flying thing like the flier from Flywrench. I was in a maze of square tiles, and I could drill to the right. Little swarming dots chased after me. When I woke up, I decided to turn it into a real game.
And so, more than a year later, I did - with a bit of help from some helpful people, an exceedingly helpful game engine, and some "inspiration" from Canabalt, Left 4 Dead, and Pac-Man Championship Edition. Though I've only ever played one of those games. I'll let you guess which one.
But I'm not here to go on and on about how I made this game. I've already done that, in this thread on the Flixel forums. And I'll probably be posting another blog post, soon, about how to get Flixel and Mochi Live Updates and the Newgrounds API all working nicely together. But this isn't it.
Every time I release a game, I discover new blind spots in my understanding of game design. This latest game is no exception. The feedback I've gotten on Newgrounds and Kongregate has led me to some interesting new hypotheses about the basic principles of Flash game design.
Here they are.
I've become convinced that Logistical gameplay is the single most important factor in predicting a Flash game's eventual success or failure. Of secondary importance is the Tactical gameplay. Flydrill is the first game I've made where the Tactical gameplay is really solid - in fact, I think it's better than most Flash games in this regard - but it has no Logistical gameplay to speak of. And the player response shows it - great reviews, but a mediocre overall rating.
If my hypothesis is correct, then adding Logistical gameplay to Flydrill should make it a very successful game in terms of portal ratings and popularity.
So, what is "Logistical gameplay" anyway?
I first came across this term in the book 21st Century Game Design by Chris Bateman. Corresponding to the four personality types in the Keirsey Temperament Sorter, he identifies four categories of gameplay skills: Strategic, Diplomatic, Logistical, and Tactical. My own analysis is based on the research in the book. Read it if you want to learn more.
According to Wikipedia, "Logistics is the management of the flow of goods, information and other resources, including energy and people, between the point of origin and the point of consumption in order to meet the requirements of consumers."
What does this mean for games? When it comes to Flash games, at least, Logistical gameplay often means lots of upgrades and items and achievements to serve as the requirements for in-game resources, and various ways to convert player time and skill into these in-game resources, whether experience points or virtual cash.
But logistics isn't just about grinding for an achievement. All gameplay revolves around choices.

There are many Flash games that focus on Logistical gameplay. But the best example that I've found is a little game called Toss the Turtle. Actually, it's not little at all, it's big - packed with items and upgrades to buy, achievements to earn, and tons of variables to tweak and improve on the way to the perfect turtle toss. You can see this formula repeated in many top-rated games, from Learn to Fly to Infectonator : World Dominator. Why? Logistics. Each of these games is heavily Logistical, with a bit of Tactics thrown in.
But what is Tactics?

In Toss the Turtle, the Tactical gameplay consists of choosing when to shoot your turtle for extra height, and using the arrow keys to slightly adjust the turtle's trajectory. It's not much, but it gives players some non-Logistical skills to work on between trips to the upgrade shop.
But the purest example of Tactical gameplay that I've seen so far is the ingeniously simple Particles. All you do is avoid the bouncing balls for as long as you can - no upgrades, no story, no fancy graphics. But the gameplay it creates is very effective, and very Tactical - reading and responding to constantly shifting patterns of safety and danger.
There are other types of gameplay that tend to be less critical for success in the Flash game market - namely, Strategy and Diplomacy. But these can be very important for long-term success, because these are the deeper skills valued by hardcore players.

But also important to mention is that Fantastic Contraption also supports Logistical gameplay, because each puzzle is predefined, and the solution can be discovered by trial and error - in other words, Logistical optimization - if no ingenious Strategic insights come to mind. This means that all the players who prefer Logistical gameplay will still get some enjoyment of the game, rating it highly and sharing it with their friends, even if they don't like it enough to pay for it.

No? I'm talking about spot-the-difference games. The gameplay in these games is not Strategic, Logistical, or Tactical. It's about finding the discrepancies between two different points of view, and resolving these differences. Diplomacy, abstracted. Difference games often support interesting artwork or involved storylines - see Dream or 4 Differences for example - which can provide players with a sort of imagined Diplomacy of conflicts to resolve and different characters to empathize with, even if it has nothing to do with the actual gameplay.
So that's some interesting background information. But why would I say that Logistical gameplay is the single most important factor in predicting a Flash game's eventual success or failure?
On page 91 of 21st Century Game Design, I came across a table citing this study on the distribution of the Myers-Briggs personality types across the general US population.
Here's what I found:
- 50% of the US population prefers Logistical skills (SJ)
- 25% of the US population prefers Tactical skills (SP)
- 15% of the US population prefers Diplomatic skills (NF)
- 10% of the US population prefers Strategic skills (NT)
If you make a game that focuses exclusively on Logistical and Tactical gameplay, you will automatically capture 75% of your potential market. If you focus exclusively on Tactical gameplay, as I did with Flydrill, you will capture only 25% of players. Oops.
Hmm, that explains a lot.
Tower defense games effectively combine Logistics and Tactics into a single package, which helps explain their popularity and continued success. Puzzle games combine Logistics and Strategy. And the only reason we don't see more Diplomatic games is that no one knows how to make them. Difference games are the closest we've come.
So there you have it. If you want to make a Flash game that appeals to the majority of players, you must be sure to include some excellent Logistical gameplay. How to do that, of course, is the subject for another blog post. ;)
Until next time...
2009/12/29
Game Idea Giveaway - Freetrace
...continued from The Game Idea Giveaway Thread
Request by Geekman:
The weird idea: Databomb
The normal idea: Freetrace

In short, the idea is a puzzle game where you erase a drawing. It is inspired by the practice of walking a labyrinth - that is, following a winding, circular path for prayer or meditation. In this game, you trace the lines of an existing drawing with a virtual eraser by clicking and dragging, trying to do so as smoothly and efficiently as possible.
Each line is actually made up of many pixels, and like a typical drawing application, you can erase these pixels in an area around the mouse cursor. But to keep things a little more interesting, your eraser strength is inversely proportional to the speed at which you move it. That is, moving the eraser quickly will hardly affect the pixels underneath, while moving very slowly will erase them completely. This makes wild scribbling ineffective.
What's the challenge? I've recently discovered the joys of swarming enemies, and I think they'd work out great in this game. These swarmers would fly around the screen, chasing after your eraser - your mouse cursor. If one of them hits you, your health or perhaps a score multiplier would be reduced. But the swarmers wouldn't be able to pass through the lines of the drawing.
As you erase, you end up dismantling your own protection bit by bit. If you want to succeed, you must be careful to maximize your protection throughout instead of erasing haphazardly.
Some lines may create living eraser crumbs when you erase them. These crumbs destroy the swarming enemies on contact. So you can use them for defense. Some protective crumbs might stay where they are, while other types might move in defensive swarms themselves or chase after the enemy swarmers.
For an extra challenge, the eraser could be a limited resource that runs out the more you erase. This would encourage you to keep your eraser strokes efficient. Or the scoring system could reward efficient erasing by giving out more points for each pixel you erase, and less if you are trying to erase pixels that are already blank.
The game would be divided into levels, each one a unique drawing made up of curved or angular lines. When you erase the whole thing, you get your score and the next level is unlocked. There might also be an opportunity for randomly generated levels or an endurance mode with drawings that continually regenerate in interesting patterns.
You'll want to collaborate with an artist on this one, though this may be difficult since each drawing must take both gameplay and aesthetic considerations into account. For this reason, I would suggest starting with abstract patterns that make for fun gameplay and interesting puzzles to solve, and then enlist the help of an artist after that.
Implementation would be fairly straightforward - no fancy physics involved. All you'd need are basic bitmap manipulations and collisions, and some simple swarming behavior. Let me know if you want any help! Good luck. :)
Request by Geekman:
- what sort of game idea you're looking for
Puzzle, Adventure
- what your goals are in making this game
To make it simple yet unique and fun
- what games you've made already
No Popular games (yet)
- your favorite Flash games
Fancy Pants, Dino Run, Wone, Sling, Roller Coaster Rush
- your abilities in game design, programming, art, and sound
Game design-Ok, Programming-Intermediate, Art - Ok, Sound - Bad
- your preferences in game design, programming, art, and sound
Programming
The weird idea: Databomb
The normal idea: Freetrace

In short, the idea is a puzzle game where you erase a drawing. It is inspired by the practice of walking a labyrinth - that is, following a winding, circular path for prayer or meditation. In this game, you trace the lines of an existing drawing with a virtual eraser by clicking and dragging, trying to do so as smoothly and efficiently as possible.
Each line is actually made up of many pixels, and like a typical drawing application, you can erase these pixels in an area around the mouse cursor. But to keep things a little more interesting, your eraser strength is inversely proportional to the speed at which you move it. That is, moving the eraser quickly will hardly affect the pixels underneath, while moving very slowly will erase them completely. This makes wild scribbling ineffective.
What's the challenge? I've recently discovered the joys of swarming enemies, and I think they'd work out great in this game. These swarmers would fly around the screen, chasing after your eraser - your mouse cursor. If one of them hits you, your health or perhaps a score multiplier would be reduced. But the swarmers wouldn't be able to pass through the lines of the drawing.
As you erase, you end up dismantling your own protection bit by bit. If you want to succeed, you must be careful to maximize your protection throughout instead of erasing haphazardly.
Some lines may create living eraser crumbs when you erase them. These crumbs destroy the swarming enemies on contact. So you can use them for defense. Some protective crumbs might stay where they are, while other types might move in defensive swarms themselves or chase after the enemy swarmers.
For an extra challenge, the eraser could be a limited resource that runs out the more you erase. This would encourage you to keep your eraser strokes efficient. Or the scoring system could reward efficient erasing by giving out more points for each pixel you erase, and less if you are trying to erase pixels that are already blank.
The game would be divided into levels, each one a unique drawing made up of curved or angular lines. When you erase the whole thing, you get your score and the next level is unlocked. There might also be an opportunity for randomly generated levels or an endurance mode with drawings that continually regenerate in interesting patterns.
You'll want to collaborate with an artist on this one, though this may be difficult since each drawing must take both gameplay and aesthetic considerations into account. For this reason, I would suggest starting with abstract patterns that make for fun gameplay and interesting puzzles to solve, and then enlist the help of an artist after that.
Implementation would be fairly straightforward - no fancy physics involved. All you'd need are basic bitmap manipulations and collisions, and some simple swarming behavior. Let me know if you want any help! Good luck. :)
2009/12/10
Game Idea Giveaway - Prejudice
...continued from The Game Idea Giveaway Thread
Request by kokosan:
The normal idea: Metastability
The weird idea: Prejudice

In short, the idea is Geometry Wars combined with Crayon Physics, with rules based on the dynamics of racial or cultural discrimination.
Like Geometry Wars, the game takes place in a field with a bunch of shapes in it. Everything in the game is a polygon, of varying shape, size, color, texture, and mass. Random shapes appear on different sides of the screen, proceeding past each other and disappearing off the opposite side, somewhat like Mondrian Provoked, or a large volume of pedestrian traffic. Unlike Geometry Wars, however, you cannot shoot. Instead, with deft strokes of the mouse, you ram into enemies with your sharp corners to do damage, while avoiding theirs.
Not every shape is an enemy, however. This is where the "prejudice" part comes in. At the top of the screen is a row of icons, each one depicting a particular shape. When the game begins, there is only one icon in this row - that is, the evil shape who has somehow wronged you in the past. Perhaps it killed your father. Anyway.
This evil shape, like all shapes, has several defined characteristics, such as area, number of edges, perimeter length, shortest distance across, longest distance across, color, and texture. Any shape that you encounter in the field is an enemy if it shares at least one of these traits with the evil shape. That's the prejudice part. The more traits it shares, there more points you get when you damage it and kill it. But if you attack a shape that does not share any of these traits, you lose points. Pretty simple.
There's more. You can add shapes to your "evil" list. How? If another shape happens to damage you, bumping into you with one of its sharp corners, then, naturally, it's evil. And it gets added to the row of icons at the top of your screen as a new evil shape. When your "evil" list is full - when it has more than, say, four icons in it - then the oldest shape is bumped off the list.
So any shape that shares a trait with any of the "evil" shapes in your list is an enemy that you can attack. These shapes are given a suspicious dark tint, for your discriminatory convenience. But in general, most shapes are content to mind their own business on their journey across the screen. Few shapes will attack you outright unless they are provoked, and some might even run away. This personality trait has nothing to do with a shape's "enemy" status - it's simply a way to modulate the difficulty of the game as you progress.
As if that's not complicated enough already, there's another twist to the idea. Not only can you have enemies, but you can have allies, too. This is where the Crayon Physics drawing engine comes into play.
When you have earned enough points from lynching enemy shapes, you can choose to spend some of those points to create allies. When you create an ally, you simply draw a shape in the mouse with the handy ally editor, and assign it a color and texture. Then, the ally gets added to a second row of icons at the bottom of the screen - your "good" list. There is always at least one shape in the "good" list - your own shape. The twist is that any shape in the field that shares a trait with any good shape - any ally - is not considered an enemy, even if it shares traits with an evil shape. So having allies reduces the number of shapes that you can legally attack.
But allies can be useful. Marked with a white tint, they swarm around you to shield you from aggressive shapes, and can also help you attack. When you hold down the mouse button, they swarm in tighter and flock with your velocity, so you can direct them in coordinated attacks. And if your very own shape is killed, then you can continue playing as the next ally in the list.
Like your "evil" list, your "good" list has a limited number of slots. If an ally is killed, its icon stays in the list. You wouldn't want to forget an ally killed in battle, would you? But if your list is full and you buy a new ally, the oldest icon is pushed off the list, though its corresponding ally remains in the field.
I want to explain the movement controls in a little more detail, as well. You move your shape with the mouse. One vertex of this polygon is the forward vertex, the point of a spike most easily used for attacking, and this vertex is made to follow the mouse cursor. This allows you to control both rotation and velocity with simple mouse movement. Allies swarm around you loosely, using a simple swarming algorithm. Just like your shape, they move from their forward vertices, which you would assign when you first draw them. When you hold down the mouse button, they try to swarm closer, and they also try to match your velocity and direction with a flocking algorithm, making their forward vertices point in the same direction as yours. This should allow you to direct their attacks.
That is all. Let me know what you think of the idea!
Request by kokosan:
- what sort of game idea you're looking for
a game involving physics
- what your goals are in making this game
Have fun developing it, and to get players to have fun playing it
The normal idea: Metastability
The weird idea: Prejudice

In short, the idea is Geometry Wars combined with Crayon Physics, with rules based on the dynamics of racial or cultural discrimination.
Like Geometry Wars, the game takes place in a field with a bunch of shapes in it. Everything in the game is a polygon, of varying shape, size, color, texture, and mass. Random shapes appear on different sides of the screen, proceeding past each other and disappearing off the opposite side, somewhat like Mondrian Provoked, or a large volume of pedestrian traffic. Unlike Geometry Wars, however, you cannot shoot. Instead, with deft strokes of the mouse, you ram into enemies with your sharp corners to do damage, while avoiding theirs.
Not every shape is an enemy, however. This is where the "prejudice" part comes in. At the top of the screen is a row of icons, each one depicting a particular shape. When the game begins, there is only one icon in this row - that is, the evil shape who has somehow wronged you in the past. Perhaps it killed your father. Anyway.
This evil shape, like all shapes, has several defined characteristics, such as area, number of edges, perimeter length, shortest distance across, longest distance across, color, and texture. Any shape that you encounter in the field is an enemy if it shares at least one of these traits with the evil shape. That's the prejudice part. The more traits it shares, there more points you get when you damage it and kill it. But if you attack a shape that does not share any of these traits, you lose points. Pretty simple.
There's more. You can add shapes to your "evil" list. How? If another shape happens to damage you, bumping into you with one of its sharp corners, then, naturally, it's evil. And it gets added to the row of icons at the top of your screen as a new evil shape. When your "evil" list is full - when it has more than, say, four icons in it - then the oldest shape is bumped off the list.
So any shape that shares a trait with any of the "evil" shapes in your list is an enemy that you can attack. These shapes are given a suspicious dark tint, for your discriminatory convenience. But in general, most shapes are content to mind their own business on their journey across the screen. Few shapes will attack you outright unless they are provoked, and some might even run away. This personality trait has nothing to do with a shape's "enemy" status - it's simply a way to modulate the difficulty of the game as you progress.
As if that's not complicated enough already, there's another twist to the idea. Not only can you have enemies, but you can have allies, too. This is where the Crayon Physics drawing engine comes into play.
When you have earned enough points from lynching enemy shapes, you can choose to spend some of those points to create allies. When you create an ally, you simply draw a shape in the mouse with the handy ally editor, and assign it a color and texture. Then, the ally gets added to a second row of icons at the bottom of the screen - your "good" list. There is always at least one shape in the "good" list - your own shape. The twist is that any shape in the field that shares a trait with any good shape - any ally - is not considered an enemy, even if it shares traits with an evil shape. So having allies reduces the number of shapes that you can legally attack.
But allies can be useful. Marked with a white tint, they swarm around you to shield you from aggressive shapes, and can also help you attack. When you hold down the mouse button, they swarm in tighter and flock with your velocity, so you can direct them in coordinated attacks. And if your very own shape is killed, then you can continue playing as the next ally in the list.
Like your "evil" list, your "good" list has a limited number of slots. If an ally is killed, its icon stays in the list. You wouldn't want to forget an ally killed in battle, would you? But if your list is full and you buy a new ally, the oldest icon is pushed off the list, though its corresponding ally remains in the field.
I want to explain the movement controls in a little more detail, as well. You move your shape with the mouse. One vertex of this polygon is the forward vertex, the point of a spike most easily used for attacking, and this vertex is made to follow the mouse cursor. This allows you to control both rotation and velocity with simple mouse movement. Allies swarm around you loosely, using a simple swarming algorithm. Just like your shape, they move from their forward vertices, which you would assign when you first draw them. When you hold down the mouse button, they try to swarm closer, and they also try to match your velocity and direction with a flocking algorithm, making their forward vertices point in the same direction as yours. This should allow you to direct their attacks.
That is all. Let me know what you think of the idea!
Game Idea Giveaway - Metastability
...continued from The Game Idea Giveaway Thread
Request by kokosan:
The weird idea: Prejudice
The normal idea: Metastability

In short, the idea is Tower of Goo combined with Crayon Physics, with a little bit of Tetris on the side. I know I've expressed annoyance at the countless Crayon Physics clones out there that waste a powerful physics engine with narrow gameplay goals. This is my attempt to design an alternative, a game that makes use of Crayon Physics' full potential.
Like in Tower of Goo, your goal is to build a tower as tall as you can. The world consists of a large horizontal platform, an island in a sea of bottomless nothingness. Random polygonal shapes form a layer of rubble on this island, which you can drag around with the mouse to form structures or just to toss off the island, never to be seen again. You can also draw your own shapes as in Crayon Physics, and drag these shapes around as well. New shapes drop down from the sky every so often, providing you with new material as well as threatening the stability of your tower.
You use these shapes to build a tower, but crucially, they must alternate between drawn and found shapes. And the tower is only valid if no drawn shapes touch the ground, the island platform. Otherwise, you could just draw a really tall shape and use that as your tower. Alternating means that a drawn shape must not touch any other drawn shape, only found shapes, and vice versa. If two shapes of the same type touch, the tower is invalid, and the offending shapes are highlighted in a conspicuous manner. To make this easy to see, drawn shapes should be colored differently than found shapes, and perhaps a beam of light shines down from the heavens if the tower is valid.
The height of the tower, measured from the ground, translates into your score. While it may seem that you could just draw really tall shapes and cheat, this does not provide an advantage. Bigger shapes are less stable, and since mass would be proportional to area, they would be so heavy that they might simply crush the shapes beneath them.
The game could provide a special timed mode, though this is not necessary since the shapes raining down provide their own form of time pressure, and the width of the island limits the maximum height of the tower. There could also be modes for different island widths, and different amounts of rain. You could even include a mode where the player can build several towers on the same island, with their combined heights added up for the final score.
I think this game could be awesome. If I didn't have a ton of other projects already, I'd make it myself. So you'd better do a good job of it! ;) Please keep me involved if you go through with this, as I can help you playtest and polish the design to its full potential and connect you with some good artists who know how to awesome-ify a game like this. If it succeeds, who knows - I could see Metastability making the same transition as Tower of Goo, toward the full-blown, award-winning World of Goo. There's a lot you could do with it.
Request by kokosan:
- what sort of game idea you're looking for
a game involving physics
- what your goals are in making this game
Have fun developing it, and to get players to have fun playing it
- what games you've made already
Colorfill, a fill the screen type of game (Qix-like), SnakeBox, a snake game in 3D
- your favorite Flash games
Bloons, Bejeweled, this kind of games easy to grasp and where you have fun instantly.
- your abilities in game design, programming, art, and sound
mostly programming, game design OK, no artistic skills
- your preferences in game design, programming, art, and sound
Programming, definitely.
The weird idea: Prejudice
The normal idea: Metastability

In short, the idea is Tower of Goo combined with Crayon Physics, with a little bit of Tetris on the side. I know I've expressed annoyance at the countless Crayon Physics clones out there that waste a powerful physics engine with narrow gameplay goals. This is my attempt to design an alternative, a game that makes use of Crayon Physics' full potential.
Like in Tower of Goo, your goal is to build a tower as tall as you can. The world consists of a large horizontal platform, an island in a sea of bottomless nothingness. Random polygonal shapes form a layer of rubble on this island, which you can drag around with the mouse to form structures or just to toss off the island, never to be seen again. You can also draw your own shapes as in Crayon Physics, and drag these shapes around as well. New shapes drop down from the sky every so often, providing you with new material as well as threatening the stability of your tower.
You use these shapes to build a tower, but crucially, they must alternate between drawn and found shapes. And the tower is only valid if no drawn shapes touch the ground, the island platform. Otherwise, you could just draw a really tall shape and use that as your tower. Alternating means that a drawn shape must not touch any other drawn shape, only found shapes, and vice versa. If two shapes of the same type touch, the tower is invalid, and the offending shapes are highlighted in a conspicuous manner. To make this easy to see, drawn shapes should be colored differently than found shapes, and perhaps a beam of light shines down from the heavens if the tower is valid.
The height of the tower, measured from the ground, translates into your score. While it may seem that you could just draw really tall shapes and cheat, this does not provide an advantage. Bigger shapes are less stable, and since mass would be proportional to area, they would be so heavy that they might simply crush the shapes beneath them.
The game could provide a special timed mode, though this is not necessary since the shapes raining down provide their own form of time pressure, and the width of the island limits the maximum height of the tower. There could also be modes for different island widths, and different amounts of rain. You could even include a mode where the player can build several towers on the same island, with their combined heights added up for the final score.
I think this game could be awesome. If I didn't have a ton of other projects already, I'd make it myself. So you'd better do a good job of it! ;) Please keep me involved if you go through with this, as I can help you playtest and polish the design to its full potential and connect you with some good artists who know how to awesome-ify a game like this. If it succeeds, who knows - I could see Metastability making the same transition as Tower of Goo, toward the full-blown, award-winning World of Goo. There's a lot you could do with it.
Subscribe to:
Posts (Atom)