This post is available in audio form.
Play the game discussed here, Buggy 3D (web/Unity), for a better idea of what this entry describes, or for comparison check out the OpenGL original. For reference here’s a video of real buggy, and additional information.
Transcript of the Audio:
Hi, Chris DeLeon here for HobbyGameDev. This is the story of how, over the summer, I spent less than a day to make a web port of a game that five years ago I made with Allegro, C++, and OpenGL, and in the process changed the way that I’m thinking about what constitutes good design–good game design in particular–as a function of the platform and the situation in which players encounter it.
The game that I was porting was a game in which I was simulating the buggy races at Carnegie Mellon. The buggy races are these games where, these physical games, where the fraternities and other organizations would build this little tube, this little “bulletproof” tube, very sturdy very safe, it had brakes inside and steering mechanisms. Some of the smallest girls on campus would drive these things. But they weren’t powered. Runners, both male or female depending on the competition or the runs taking place, would push it like a relay race up a hill, it would then be steered by the driver all the way down this long, curvy hill, and then be pushed back up a hill by another set of runners.
Simultaneous to when that happens each year are the booths over at Spring Carnival. Booths were these structures that formerly were little lemonade stands long ago, but over many generations have evolved into these much more complicated, multiple-story structures that are sort of build like a house, with some real carpentry work and some real architecture work going into them, filled with decorations based on some sort of theme like SpongeBob or Titanic, or Sesame Street–those were all licensed, but many of them were abstract like Under the Sea or Aztec. In those booths were games. Those games historically had been physical games. It was traditional carnival-style stuff where you were throwing a bean bag into holes, where you’re popping balloons with a dart, or maybe where you were slinging frisbees with some sort of slingshot band-type mechanism.
Around the time I came in, and I don’t think this is purely coincidental, there began to be an emergence of digital games being used in these booths instead. We would program a sort of videogame to be played by the people going through these lines.
The booths attracted long lines of people. They would stand in line for a long time then get to see the insides of the booth, and play a couple of games on the way out. Sometimes people would give away prizes, little blow pops or candies of various sorts, little take-home stuff like you might get in an arcade.
So one way to think of these little digital games is like an arcade game. Because of the long line we had to churn people through. We couldn’t make it a long game, we couldn’t make it very deep in terms of having to give them a tutorial or anything. We had to let them step up, play it, get it immediately, and then leave. In that way it’s a little bit like an arcade game.
But it’s not exactly like an arcade game.
Whereas arcade games are built around the idea of replayability, because they have to encourage someone to put another coin in, in the case of a booth game, most booth games–and that includes this one that I ported–are designed to only ever be played once per player. Maybe, at most, a few times, but certainly not with the level of practice that you would expect for a game like Donkey Kong, Asteroids, Space Invaders, or Defender. In those games you have to get replay to even survive more than maybe 30 seconds to a minute, to even figure out what in the world you’re doing you have to replay and practice. Whereas in these settings we had to support people walking up, playing the game, walking away from it, and never going back, but still having a story to tell, still feeling like they got something worthwhile out of that experience.
So that’s a different context. On the one hand, with a real arcade game, you are expecting players to replay it. On the other hand in a booth game, you are expecting players will not be able to replay it. These booths by the way get torn down after three days. There’s really a very narrow window of time in which these games are live inside of these booths.
There were other design constraints as well. Whereas in arcade you have a self-selecting audience of the kind of player who feels like they’re up to that challenge, like they don’t mind getting knocked down a few times to survive that onslaught to practice and get better at it, to play these abusively difficult games. In the booths we kind of expect everyone coming through is going to play it. These are public carnivals, open to the general public, so we have children, older players, we have people that don’t necessarily play videogames coming through, we’ve got people dragging along girlfriends, boyfriends, spouses, younger brothers, older brothers, people of all shapes and sizes and ages and backgrounds and relationships to videogames were playing this game in the booth. This is as opposed to, on the other side, with an arcade game there’s a self-selecting audience: hardcore gamer who knows what they’re getting themselves into.
A bunch of design decisions had to be made around that. Our booth game is in many ways much more shallow in terms of gameplay from what would be in an arcade game. In an arcade game you have to award that replay. For booth… in the original game you had a running mat, you would stamp your feet real fast–we built it off of a DDR mat we had modified–that was to run your relay racer up the hill faster, and then you steered. But the trick was, when you can’t practice in a racing game you never know what corner is coming up, you can’t really expect the player to have mastered the tuning of the controls yet, so the steering in the buggy game is basically an illusion.
I mean really, we’re giving you a sensation of agency, we’re letting you veer left to right along the course, but you’re sort of being dragged along this pipe at roughly the speed that’s based on how well you had done your running portion. The only real skill was that button jamming for the running portions. The steering is just kind of there so you feel like you’re in control as you’re going down the hill. You can’t crash, you can’t spin out, you can’t accidentally hit the other relay race buggies, it’s really kind of an illusion.
That would have been the wrong decision in an arcade, because it would have meant that the player’s decisions don’t really matter in that case. But in the booth setting that was absolutely the right way to go. The alternative was the have young children or players that were outside the age gap or demographic we’d expect for these kind of games wrecking or slowing down or getting lost or being confused by what the course is doing. It was always their first time playing, they had no chance to practice it. Instead this worked out much better so that everyone walking away could feel like they did it, like they succeeded at it. Even if they got third place they still finished the race.
It also gave us a window of time to know how long this race was going to take. At minimum speed you’re still going to cross that finish line in a known amount of time so we can keep that line moving through.
Here were design decisions that would have been wrong in one context that were right in another. Nowhere is the more obvious than when I just ported it over the summer. Originally the game took 10 days to develop, that included the modeling and texturing, but that was only 2-4 days of development. I also had to develop my own level design tool for it, had to develop my own model importer, had to write some of the rendering code, some of the miscellaneous junk that was needed to make this game work, that Unity has built into it. And so I was able to reproduce in less than a day with Unity. Now it works online, now it can be played on Mac as well, now it can be played on newer Windows machines.
But it becomes obvious when viewed on a computer screen how much this game, which at the time was pretty well respected as a pretty great example of a booth game in filling that niche and that role pretty well, how much it doesn’t stand up as a PC game, as even a web game. Suddenly the graphics, which merely by being representative of the landmarks on that end of our campus, were pretty neat for people to see on the screen so unexpectedly as they’re going to the booths at Carnival. On a computer screen, and you know five years have passed but that’s not really the difference here, they just don’t hold up. You can see them multiple times, and so you can see all the problems with them, that were maybe not so evident when you only had one run through and that was it.
When it comes to the difficulty of the game, it used to not matter that you could practice or that you couldn’t practice. Now that you can practice, now that it’s real easy to click and play again, you pretty quickly realize how much randomness there is in the outcome. It’s a little bit out of your hands. You can jam those run buttons faster to improve your chances, but sometimes you’re just going to win or you’re just going to lose, and that’s just the nature of the game. We just needed to give people a complete, coherent experience that they could walk away from and explain and describe to their friends.
This has got me thinking more and more about the games we design on multiple platforms, and how those shape our notion of good game design. In the example of this game that I ported to the web, it’s not just that I could get away with worse graphics for a game someone only plays once, but that when it comes to gameplay decisions like level of actual control over the vehicle vs the illusion of control, what was a bad decision for an arcade game was a good decision for the booth game and vice versa. This was based on the nature of replay and the self-selection of audience playing each of these games.
That seems like a function right: the frequency they’re playing it, how they’re finding it, how they self-select for it. This seems to reflect to me: economic models have changed over the generations, this was around the start of summer so I had just completed work on my pinball thesis, where I had focused on how this early transition to arcade videogames had shaped games around killing you in 1-3 minutes, in trying to encourage you to replay, unlike in the way that for console games you really wanted to facilitate longer sitting down periods of time. You wanted to facilitate longer epic journeys. All of a sudden you wanted to be able to save your progress.
Then it was comparatively simpler than how it has gone now, dovetailing in a million directions, where we have games being funded through open beta like Minecraft, in which the community is constantly giving feedback during its development. You see similar things going on with KickStarter, where some projects have turned away from publisher funding to seek other ways to facilitate the creation of their game. You see it in microtransactions in free-to-play games, where in a different way than with shareware, you have a game where people can play for free, but they’re then egged on to want these additional things they have a way to pay for.
That case, right, has evolved from piracy, in that here was a model that was harder to pirate. Or likewise for MMOs. which partly they realized here’s a way to get people to pay for a game and pay even more for one game over time as opposed to a one-time purchase.
On each of those games, a decision which might seem like a bad design decision for a different payment scheme or a different platform, becomes good in a different one. It’s not just a matter of what you can get away with, it’s not just a matter of trying to raise more money through it, it’s about rethinking that if that payment scheme affects the frequency with which people play it, or the crowd of people who are playing it, then that decision could genuinely become better or worse for that crowd when played in those sort of intervals.
This is like how early on what was great for an arcade videogame quickly fell out of favor for being a console game. This is also like how, when MMOs first came out, players who were fans of traditional, convention games were critical of the mechanics in the MMOs and saw them as just dumb skinner boxes–that is, games of addiction where it’s just risk and reward. I was guilty of this at that time too. Of course when Facebook games came out, and those are being funded by a very different model, through a different payment scheme by players, played by a different crowd of people, other developers (myself included, my advisor Dr. Ian Bogost included) were critical of those just being Skinner boxes, risk reward addiction machines. But when I was researching the older history of games I realized pinball used to be accused of being a Skinner box, or a gambling addiction machine.
It’s occurred to me that, what’s happening, is there’s this set of games that we like–as an individual, each individuals going to have a different set of them–and in many cases it’s whatever happened to be prevalent in the market when it caught our eye and we thought, “Oh, I like that, those are videogames. I’m going to play those, I’m going to buy those, I’m going to read about those, I’m going to study them, even learn to develop them (in some cases).” Then when the economic models change out from under us and point us toward crating a different style of game for a different audience, we look at them and say you know what, those aren’t really games, that’s something different, those aren’t really videogames, that’s not what I grew up with and that’s not what I know. Maybe it’s just reaching a different audience.
This becomes problematic because it’s part of when, especially in the arc of the past 10-20 years, I know growing up I always though I enjoy videogames, and had spent so much of my life already to playing them and sharing them with friends and learning about them, I just wished more people would like them. I dreamed of a day when so many more people would play these games and they would reach all kinds of people. Every time that has happened–first with MMOs, then with casual games on the Wii and for iPhone, and with web casual, then you’ve got your Zynga/social/Facebook apps and so on–there was a pressure against it.
Even before some of that with the Sims, we saw this. The players that had grown up in the more hardcore audience before that under a certain economic model of how games were paid for, bought, developed, and funded, we saw those things and thought yeah, but that’s not really a game. You know, Sims doesn’t really have that clear crisp goal defined at the end for whether you’ve won, whether or not you’ve killed the enemy or he killed you.
MMOs don’t really have an ending at all. There’s a continuous drag on and it’s largely about the people there. When we looked at casual games we wondered, are you even really in control of Wii bowling? Wii Sports in general, when you play baseball and don’t have to control the outfield, what’s going on? We thought it should matter that practice was needed to play outfield, but for that audience being reached by that platform, that turned out to be a much smarter decision on Nintendo’s part than to make them run to the ball, pitch the ball to the right plate, and so on.
I’m really starting to develop a curiosity now for how these different economic models and platform positionings affect our ideas of good and bad game design. Especially because, and this is where rubber hits the road, I work on free games! A lot of what I make are free games. And so there is no economic model. There’s no self-selection among the audience, besides people willing to play a free game. This has me wondering: in what context would something be a smart decisions for a console, microtransaction, or MMO game but a bad idea for a free game or vice versa. What we’ve just been discussing is that each of these different ways that people pay for and find games, and different habits that are structured into them lead to different ideas of what constitutes good or bad, smart or unwise, design decisions in those contexts.
Free games are both a weird mixture of many contexts, and in some ways lack a context in as clear a fashion. They reach a much larger crowd. I heard from a peer–I can’t remember who the quote came from, but he was telling me (and I think I saw the same effect on my own iOS applications) if you take a paid application on the App Store which had a pretty decent star rating and you make it free your rating will go down. Right? Wrap your mind around that. When you have a game and it’s doing pretty well and has a good star rating, and it costs money, then you make it free, your rating goes down.
You’re losing the filter that, when it had cost associated with it, a higher percentage of the buyers would only get it if they knew they would like it, if they heard from a friend that it’s enjoyable, if they played it on a friend’s phone and decided it’s something they’re going to like. You had self-selection of people only buying it if they knew what they were getting, or at least were pretty sure they were going to like it based on what they could tell from the screenshots and the text. Of course when it’s free, you get a lot more people rolling in, who maybe find it’s not their thing, but they’re going to play it and have expectations and demands as players, but then they’re going to reject it and give it poor ratings.
Even ratings I think factor into this system of how people find the games that they wind up playing, how they wind up selecting into them. These ratings now so often affect something like Kongregate, in terms of the order that games appear on the page or which ones appear on the front page.
How does the use of ratings for a game’s platform affect the good and bad design decisions for that platform, not just to affect the rating, but in terms of the types of players that those sort of environments attract.
Of course a lot of the free games that are developed, I’m guilty of this too some of the time, are really straight mimicry of another one of these platforms, where we clearly are appealing to “this is like an NES game,” “this is like an arcade game,” “this is kind of like a spinoff of an RTS,” a certain style of PC game, downloadable, or MMO. But I’m referring to a different case of when games don’t mimic or at least don’t clearly allude to what they’re trying to be, when we’re out in the nebulous space.
But anyway I think there’s more to this than I can possibly try to wrap myself around and convey today. I’m more starting a thread than trying to tie one up.
Again where all this started was: I ported this game which was originally built to be played once, ever, by anyone, per person, to this web format where replaying and retrying is just so easy that it very quickly falls apart as to the game it once was. I thought it was really a great example of a good booth game, and now I just feel like it is an awful, awful example of a web game. I think thinking about that distinction and why is productive exercise in design.
If nothing else, if you’ve got an old PC game you developed with OpenGL or C++, and it doesn’t work anymore on nice, newer machines, consider porting that stuff to Unity if you’ve still got the textures and models, it doesn’t take long at all and can put your game in front of more people. But you might discover along the way that it doesn’t evoke the same response when it’s played on the web as it did in downloadable.
One last thought about that: Unity allows us of course to export downloadable programs, or to make it playable on the web, or to make it playable on iOS devices or other sorts of platforms. And I’m curious about why and when there are decisions, not just about download time or something else, why in some cases it may pay off to make a game which is download only versus one that’s played in browser.
I think we made a bad call on this on Freezing Solid–I’ll just call myself out on it–we thought we should make the game accessible to everyone and just make the web playable version up there on the site for Freezing Solid. Whereas now I think that because it emulated this 90’s PC context, trying to strive for the MechWarrior 2 type stuff, I think maybe it would have been a wiser decision there to have only provided the downloadable version of PC and Mac, and not provided the web player, for a number of reasons related to or at least on the edge of this problem space I’m describing.
That’s all for now, thanks for listening in.
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!