Write only as much as you can revise carefully.

Brilliant. Here, in fewer than 10 words, is an approach that applies to nearly every undertaking that we intend for others to see.

Put another way: don’t drive so fast that you lose control.

Is this really Advanced material?

Every month I write entries for four categories: Beginner, Intermediate, Advanced, and Special Topic. This entry is intended for Advanced.

But, I can hear certain experienced readers objecting, isn’t overextension generally a beginner’s mistake?

That way of thinking leaves advanced developers – and everyone else putting trust in their judgment – even more vulnerable. Beginners often have a problem with overextending, certainly, though they do not yet have enough perspective to be able to recognize that as what they are getting themselves into. It is the more advanced developers that are capable of recognizing overextension, and are therefore in position to either ignore it or apply the brakes.

Experience does not render us immune to overextending ourselves. At best it can help us notice when we begin to lose control, after which we still need to take swift and deliberate action to correct for it.

Growing requires stretching a bit every time, but what ought be stretched is the presentable result. Stretching for its own sake without bound is simply stretching further into the territory that we can’t possibly polish to a presentable state. Anyone, no matter how experienced, is capable of growing a project beyond their means to finish it well.

Write only as much as you can revise carefully.

Otherwise, the project may wind up wrecked roadside while others pass it by.

And if you’re working with a team on which you are among the more experienced developers, you have other people in that car.

- Hi Chris. This is my first year in college, and I’m currently a Computer Science [CS] major. However I came in with no prior programming experience, so the math and programming classes so far have been pretty tough. I am thinking about switching my major to something more enjoyable, and just trying to teach my self game development instead. Any thoughts on whether, or maybe why, it would help to stick it out with CS? My dream job is to work in the gaming industry, though I may wind up looking into indie development.

Answer, Part 1

First, full disclosure: I was a CS major, too. That may bias my view of it, but it also means that I can provide an informed, first-hand look at how it did or didn’t help.

Everyone’s path in life and career is different. The decision is purely up to you, and as you necessarily know more about yourself than anyone else does it’s important to weigh my thoughts on this as just one more source of data.

Whether you decide to seek corporate industry work or go independent, I think that a Computer Science degree is still among the most applicable, useful, and broadly marketable backgrounds related to game development. I’ll do my best here to make a case for why I think that’s true.

Note too that, importantly, CS is also a credential respected outside of games, which can make it a practical degree to have for finding or creating back-up plans down the line if necessary.

Comp Sci != Game Making

As you’ve probably already discovered, game development generally isn’t really part of CS curriculum, except perhaps for a single high level elective class. Almost all of my game development during college came from extracurricular clubs.

Learning game development requires a good deal of self-teaching no matter what major someone is undertaking. Experience in CS is relevant though, and it complements someone’s self-education in game development by pushing development in areas that it would be easy to overlook on our own. Material from CS can be useful outside of the classroom, when working through real-world game development problems, sometimes in ways that are hard to recognize until they come up during the creative process as either challenges you’ve prepared for, or – if the skills aren’t there – as apparent dead-ends.

Comic from Abstruse Goose, shared under Creative Commons Attribution

There are no doubt routes to take that are easier or more enjoyable to take in the short term, but those paths may or may not be easier and more enjoyable in the long term. College years are partly about investing in your future capabilities and opportunities; the standards and challenges of a CS degree are just one of the established ways to stay on a solid track to do just that.

If it’s not immediately clicking, it might require spending some more time in the library studying (even if you don’t need the books there for CS, it’s handy as a well-lit place filled with other people calmly working, too), attending more of the optional tutoring and office-hours sessions available through your school, starting earlier on assignments, and staying up later sometimes to hack through getting assignments figured out and working. Many college students wind up automatically paying for resources but not making full use of them, whether via the career center, library assistance, or office hours. Before deciding that a subject isn’t working out, make sure that you’re at least getting your money’s worth and using all the mechanisms available. Outside of working on videogame projects and trying to live a rounded life in college, I spent a ton of time at office hours asking questions to try to fill in for what I didn’t understand yet from the lectures and reading.

Big Company vs Indie

A qualifier about the difference between big company work and an indie career: earnings from independent development can be really, really hit or miss, spotty and unpredictable, and in the majority of cases unprofitable. There’s a huge selection bias in the indies we hear the most about – they’re disproportionately the rare success stories that have done extraordinarily well. The countless others that are barely scraping by or losing money don’t make for good headlines.

Independent work can be a tricky and trying path to navigate, and though it’s potentially very rewarding, it should perhaps be initially thought of as something to develop on the side of some more consistent line of work as the main plan. With a bit of momentum from giving yourself a head start, and a bit of savings in the bank from doing something with a more predictable paycheck for awhile first, you’ll have better odds of lifting off the runway.

One element that helped me in my journey – though again each individual’s mileage from such choices will vary – was to minor in Business Administration. Those courses involved learning and practicing skills that were useful in every scale of work environment that I’ve been involved with, including my time alone: presenting information/ideas/yourself to others, basic financial concepts, project planning, even practical bits like resume preparation. (Even if you go independent, keeping an efficient, up-to-date, professionally presented summary of skills and work can be useful to have on hand.)

Whatever you decide, good luck on the road ahead!

Question, Part 2

- It seems like many of today’s big designers got into the industry with a non-technical major. Do you see the industry moving more towards requiring a relatable degree?

Answer, Part 2

You’re right that many of the current big and/or historical names in the industry have a seemingly random assortment of backgrounds. John Romero and David Perry were both, if I recall, completely self-taught, and did not attend university. Nintendo’s Shigeru Miyamoto went to school for industrial design. In my interview with Atari Adventure designer Warren Robinett, he mentioned that one of his early co-workers in the game industry, “had a degree in Zoology.”

Of course, Shigeru Miyamoto was born in 1952 – so for perspective, Pong hit the market (overseas, here in the US) when he was already 20 years old. Robinett’s undergraduate degree was not in Computer Science – he majored in a CS-like area of math, but when he was an undergrad CS had not yet become a standardized field of study.

That historical difference partly accounts for what you’ve rightly pointed out.

40 Years Ago

The industry didn’t exist when most of the early innovators were growing up. To the extent that some degrees were later relatable, like Robinett’s pre-CS technical/math major, no one at that time could have picked it for that purpose, because those exact jobs and products didn’t exist yet.

Another thing to keep in mind was that computing was very different in the 1960′s to early 1970′s. Far fewer people had access to computers, but among those that did, a much higher percentage of users taught themselves how to program because it was pretty central to being able to use a computer at all. Programming was one of the few activities that could be done on machines at the time; the first word processor didn’t come out until 1972, and the internet didn’t become common and commercialized until much later in the 90′s.

There also wasn’t much ‘prior art’ for a game developer to catch up on. Nearly everything being done at all was new, and by casual assessment equally valid from a business perspective until the market response to a shipped product indicated otherwise. By comparison, much has since been sorted out by now, both from a technical perspective and also from a business perspective. People have already lost a lot of time and money figuring out how to do certain things in impressively efficient ways, how to collaborate effectively on team projects, and discovering what consumers responded well or poorly to. Developers caught up on those findings have an advantage over others starting from scratch, reinventing the wheel, insisting on learning the hard way.

Now that four decades have passed, many of the surviving companies have thousands of employees (or at least compete against companies of that size), and there’s demand for high degrees of specialization for a team to be able to distinguish its products from those that competitors are able to create. Even just keeping up with inflated consumer expectations, especially on today’s higher fidelity platforms, can require specialists. Whether applying for an industry job or creating independent games as a small team, each individual is competing against a tidal wave of other eager, passionate people that have partly designed their education and adult lives around developing skills that have been found relevant to the now more established craft of videogame production.

Increased Importance of Degrees

The increased importance of degrees, though more so for applying to jobs as opposed to working independently, has also become a useful shortcut for hiring managers serving as a company’s first line of assessment. At a company with a recognizable brand, the executive producer or lead engineer can’t personally screen every applicant. Instead, the initial set of applicant submissions first has to make it past recruiters that are not necessarily game development specialists, and thus may look for specific degrees and types of prior experience as evidence of the skills they’re hiring for. Applications making that cut then move on to one or more rounds of interviews, at which point an appropriate specialist from the team may be available to help assess actual qualifications, but getting to that phase with little/no relevant professional experience is part of where the appropriate degree can help.

While there may be capable applicants without relevant degrees, unfortunately there are often enough qualified applicants that do have relevant degrees that it’s easier and more cost/time efficient for a company to hire primarily from the latter pool, for which less screening may be required since college admissions and professors may be thought of as a very specific sort of filter.

Comp Sci is More Than Programming

A CS degree is not just about knowing how to program. Having a particular degree is often also interpreted as evidence, correlative beyond the scope of what’s covered directly by the curriculum for that degree, that someone is dedicating themselves to some predictable set of knowledge, skills, and values. Companies need all kinds of people to thrive, but from a purely practical perspective, it doesn’t take much imagination to picture how a “CS person” can fit in and benefit a company that creates software. Computer Science rewards attention to efficiency, feasibility, robustness, extensibiliy, self-correction, and some other less easily pinpointed but equally useful priorities, in ways that specifically apply to computer programs. (I.e. while it’s true that plenty of subjects may reward attention to efficiency and feasibility, traditional CS approaches these in an extremely rigorous fashion by dealing with their theoretical limits.)

The increase in people hired that have relevant degrees, from the above factors, has created a positive feedback loop. When the people with those credentials get promoted over the years into more senior-level positions, they’re even more likely to value that same (or similar) credential among incoming candidates at an interview stage.

Game Degrees

Another option within the spectrum – which you haven’t asked about directly but I’ll address here for sake of completeness – is in degrees more specifically and narrowly about videogame development. These haven’t been around as long as Computer Science, making them a bit less standardized, and consequently more of an unknown, unproven value to many people in industry. Anyone with a CS background has a pretty clear idea of what someone with a CS degree from another school likely covered, but there’s so much variety between game degrees that it’s hard to know what skills and work culture to expect unless someone in a hiring position is personally familiar with that exact school and educational program.

Partly as an effect of having not been around as long, there are also fewer senior-level people (yet) from those types of educational backgrounds.

The flip side is that some of the same factors that have made the CS degree of more interest to the industry are likely at work for those more game specific degrees: easy shortcut for hiring managers, evidence of (probable) commitment to certain knowledge and attitudes beyond the curriculum, and as time progresses, more senior level people coming from that background will be held up as evidence of the type of value associated with those degrees.

That path can also be a more risky value proposition to students, however, since those degrees sometimes cost comparatively more (being seen as more vocational, and thus framed more as a financial investment) and can be more limiting to videogame industry work. Students with those degrees have less of a clear back-up plan, not only if they can’t find a fit in the game industry, but also if the game industry undergoes a major shift as it did when arcades mostly phased out, when MMO’s seemed like the next/only big thing for awhile, when digital/mobile distribution lowered barriers-to-entry for competitors with much smaller staff, and as social games have grown to absorb an increasingly sizable chunk of game company investment capital.

How good of a back-up plan comes out of a mostly game-specific degree varies greatly between how individual schools have chosen to implement such programs. I have heard peers in such programs report everything from their studies being typical Computer Science in-disguise, to specific tool training (which can seem the most useful in the short term, but can be the least useful in the long term – teach yourself the tools, instead!), to amounting to little more than an excuse for networking. Remember though that a recruiter without direct connections to the particular program (perhaps less likely outside the industry than within it) may not have an easy way to quickly discern one of the above from another, and that could affect whether an application makes it to a stage in the process at which someone with the necessary domain knowledge takes the time to sort out the candidate’s relevant capabilities.

Closing

The case, by contrast, for a CS degree is that its emphasis is on fundamental concepts, which aim to extend well into the future largely independent of specific technologies or how the market may change. At any time in game industry history, even just a five year span has covered some pretty dramatic changes, but a proficiency for the skills and mindset of proper software development has remained central and relevant.

Lastly, as a reminder: I have only an outside, second-hand perspective of the alternatives. Your best bet for gaining a more balanced perspective would be to pitch this same question to some game developers with different backgrounds. There’s no one right way to go about it, though the odds are better some ways than others.

Please note that all of the games below require a modestly up-to-date version of the Flash Player (free).

Vision by Proxy: Second Edition

> > Play in Browser – Trailer Video < <

Artsy Puzzle Platformer

2.7 million plays, won Best of SIEGE 2011 Student Showcase

VbP:SE did better than we expected, making it to the front pages of several major Flash game portals in the US and abroad. We’re currently working on a sequel (Ms Vision by Proxy) in which we attempt to address the game’s brevity by involving more character eyes. The short length of VbP:SE probably worked a bit to its advantage though, since it kept the scope such that players can get through the full game comfortably in one sitting.

Some people especially disliked the bonus levels, while other players specifically preferred those stages, both for the same reasons: they focus on platforming instead of puzzle solving. The game was short enough, all included, that players who like either were mostly able to slog through the ones they felt so-so about. In any case it worked out well having these types of stages separated conceptually as a post-story second play through, rather than forcing both level types into the same timeline. It’s a trick akin to what’s seen in Portal or Mirror’s Edge – at a much smaller scale, of course.

The game also would have suffered more from being too short if we hadn’t milked the engine, level parts, eyes, and cinematic sequences to squeeze in twice the levels. Most importantly we were able to get this increase in length without creating any new art assets nor needing to program any additional features. I just spent an extra day in the level editor churning out 9 more levels and throwing away the 6 I liked least to leave my preferred set of 3 remaining, which is a fairly common way that I like to do level design when time and tools allow it.

MechStrike

> > Play in Browser < <

Set-and-Play Sideview Action

90,000 plays, 85% on Chinese web portals

I feel like this game had just the right number of unit types: 11. More would have been harder to learn, and fewer would have limited depth and variety.

Early on during development we briefly explored what it would take to make a more complex and involved simulation with more detailed AI, stat, and strategy options, though we ultimately decided that something like Gratuitous Space Battles might not make sense for an in-browser gaming audience. That worked out for the best anyhow, since we didn’t have the time outside of classes during the semester to pull off something on that scale and polish. We made a lot of compromises to keep gameplay quick and to the point. In the end we made it simple and quick for players to get set up, which turned out to be vital for a game like this since trial, error, and observation is necessary to learn how each of the weapons and units work out against and alongside one another (from emergence, though, not from any contrived countering or boosting relationships).

It’s surprisingly difficult to come up with cool, non-cheesy names for futuristic military units that haven’t already been done to death. Our writer came up with excellent names for each of the units, in addition to helping us come up with a varied set of weapons and abilities and writing the opening crawl. The techno-metal track we selected from Kevin MacLeod’s Creative Commons library fit really well, but like any MacLeod music people hear the songs in YouTube videos and other games. MechWarrior 2 was a source of inspiration for us, and the song we picked has a similar vibe to Dragon’s Teeth from MechWarrior 2: Mercenaries.

Though my animation engine wasn’t particularly great, our mech artist did a really nice job with the individual mech body parts. Without cool looking mechs the game wouldn’t have worked at all. Our main UI designer wound up doing all of our final tank and plane art near last minute (not her fault – originally someone else was going to make them), and thankfully they came out distinct and recognizable despite the time limitations. Our original plans included the ability for mechs to lose their limbs during battle, as they do in MechWarrior games, which we wound up cutting since our mechs didn’t look as good without arms, and if mechs lost any of their few weapons during battle it would only drag out the endgame.

When there’s only a few units left in a well-matched battle it can be kind of suspenseful… but it mostly just highlights the weakness and inaccuracy of my AI. In my defense, for about half of the project we had someone else onboard specifically to focus on AI programming, though on account of outside obligations he wound up parting before really getting started. That type of uncertainty is simply a risk of making hobby/extracurricular videogames, since we have no pay nor course credit to offer. The core gameplay still works with the mostly functional AI I stitched together.

We were considering having multiple rounds per configuration, with players able to make changes to their AI or weapon settings between rounds but not to which vehicles are included, but I’m glad that idea didn’t make it. Part of the fun is quickly mixing up fresh scenarios, and being forced to watch a poorly chosen team lose again and again would be rough. The single round simplicity of our matches and how quickly they can be set up even made it possible for Henry and I to play indirectly via Facebook:

The team had a bit of back and forth about whether the players should be able to do anything during the match. Proposals included pressing a key to time deployment of a second wave of units, using the mouse to fire an orbital super weapon, toggling some AI variables, or directly controlling a lone commander unit. In the end we went with pure spectatorship, with shared camera control, which has a very different feel than being involved during the action by prolonging a sense of hope rather than demanding constant focus. Although we added little smoke and sparks to damaged units, we opted to leave precise vehicle health bars out of gameplay, partly for the uncertainty that their absence adds to excitement. Being able to identify the clear winner well before the end of the match, which could have messed up the experience, is much harder to do reliably since it’s unclear how many more hits the units left on the field will be able to sustain.

Huge robots walking past one another mid-battlefield just looked wrong, and combined with their slow speed we couldn’t get away with it as we did with the tanks and jets. Instead, we programmed the mechs to stop and fight toe-to-toe with one another until one or the other exploded. All three mechs also have a special mech-vs-mech melee attack implemented: the humanoid walker slashes with the energy sword (instant kill to any unit), the chicken walker kicks, and the spider performs a stomping action.

We didn’t mean to make melee so rare as it came out, that happened only by late accident while trying to patch up other tuning imbalances. These attacks played a pretty pivotal role in the first build or two we released, with matches often coming down to mechs destroying each other point blank in the middle of the stage. The inevitable melee gave extra importance to fielding a humanoid walker. In later tunings (including the current version, 1.04) we improved the weapon accuracy for most units, decreased mech armor slightly, and increased the effectiveness of machinegun usage between mechs at medium range. These changes combined to make mech melee virtually never take place, though technically it’s still there and will happen if matches unfold in a sufficiently peculiar way.

In hindsight, a way to save a launch team configuration for more rapid experimentation in sandbox would have been nice. Not only would it help players experiment faster, but it also would have made testing and iterating on game balance easier for us.

Zylatov Sisters

> > Play in Browser – Trailer Video < <

80′s-ish Arcade Action/Platformer, designed for shared screen co-op

130,000 plays

Unlike most other games that I’ve worked on, after finishing work on this I still really enjoy playing it.

As an experiment in modular game design to help reduce overhead Zylatov Sisters was successful in producing a good amount of variety and giving a number of beginning developers in our videogame development club a mix of experience. (I’ve previously written HGD entries about our process, and also some of our design decisions)

Many players are finding it unacceptably difficult, though we understood from the outset that we wanted to make a game with pinball or classic-arcade pacing: constant vulnerability, typically 1-3 minute sessions after a modest amount of practice, and replaying to earn increasingly higher scores. Further, we knew that the usual in-browser gaming audience might not necessarily go for this type of structure since it’s an outdated taste. Players widely accustomed to videogames that are designed to be plowed through by persistence are presented here instead with levels that aren’t meant to be consistently completed.

There’s also a steep learning curve in that the arena-nature of each level means it’s hardest right when each stage begins, when all enemies are still alive. Start the round carefully enough to survive and aggressively enough to cut down some of the horde, and with the remaining lives the odds of survival within that level improve considerably. Fewer enemies left in a stage also makes it easier to retrieve gun/item boxes, which can help improve survival odds for the start of the next level.

This was never meant to be a commercial game though, so we felt ok with simply making the game that we wanted to play.

Our decision to make any level equally eligible for selection as the first level gives the game variety for a high level of play and makes it easier for students on the team to show their work to peers. We also randomize which level shows up first, so that every player gets a slightly different first experience. However the lack of any intro, tutorial, or beginning level(s) served to further alienate players that found the game too difficult at first. We perhaps ought to have at least picked out a few of the easiest levels, and made the first level upon game start randomized from between those instead of all maps.

We also received frustrated feedback about the game’s default controls, which we set with co-op in mind. Even though the controls can be reconfigured from the main menu, relatively few people seem to be taking advantage of that. We perhaps should have gone with our original plan of using different default key mappings for single player vs co-op play, which we strayed away from late in development from fear that doing so would throw people off when trying co-op. Supporting that decision would also require a slightly different menu system, which we didn’t have time left to do late in the schedule. Unfortunately some players are finding the single player controls needlessly cramped, then simply quitting forever before either trying co-op or realizing that the controls can be easily reconfigured.

In other words: fully reconfigurable controls cannot make up for default controls that people don’t like. Especially with a free game, people have no investment in making the experience work for them and can easily switch to something else, so if they don’t immediately like the default mapping it’s over – player lost.

On the plus side, more so than the other games I’ve mentioned here, people that do like this game seem to be returning to play it semi-regularly. That makes sense given the arcade model we were trying to emulate. By comparison though, it doesn’t really make much sense to play VbP:SE more than once, and MechStrike‘s novelty and mechanics favor head-to-head play but don’t offer much single player replay.

Our inclusion of co-op only support weapons worked out well for two-player, but may have strained our single player weapons offering a bit by comparison. We partly mitigated this by the three types of special weapons that can appear for getting a 5X or higher multiplier. However because it takes a bit of practice and luck to earn those, they don’t do much to help first impressions. The two-player support weapons can be really powerful for assists if used effectively with the other player’s help, though here again, tuning the game to keep those co-op weapons from being overpowered rendered single-player even more unforgiving.

Co-op also lets players revive one another indefinitely. As long as at least one player remains alive and can find a chance to either finish the current level or kneel briefly by the fallen sister, it’s possible to just keep going. Two experienced players working together can go on a roll for quite awhile, which in light of the game’s harsh difficulty can be especially rewarding.

The aftermath stat and throwaway “award” screens (GoldenEye 007 style) worked well for giving players a moment to reflect on each round. Without them I think a hard jump from game over right back to level select menu would have been too jarring.

Outside testers really helped out a lot near the end of the project. I put out a call via Facebook and Twitter, and also had a few classmates try it out in person where I could more easily observe and ask questions. It led to some important spot fixes to several stage layouts/assets, tweaks for more responsive controls (running then turning used to slip much more, as if on ice), and focused us on which wish list items were most important to implement with the time we had left (including saving high scores locally and the option to customize controls).

One of our members oversaw narrative design in addition to helping out as another technical game designer/artist. That can be a tricky role to play on a project that aims for an mid-80′s action arcade aesthetic, but he understood from the outset that the goal was low-fi retro, and he was flexible to the specific needs of the project. Since the genre is pretty light on written text outside of the intro (which players of this sort of game tend to skip anyhow), he instead improvised other ways to help establish the game’s atmosphere: recommending the game’s main font, drawing the title screen background to set the mood, and authoring his levels with a deliberate progression.

Our team members making chiptunes for this project really shined (several of them don’t have online portfolios yet, though one does), pulling off a Castlevania/MegaMan-ish vibe pretty well in a number of tracks. I’ve been enjoying the soundtrack separately from the game. Tying specific songs to each stage helped give each level a consistent personality, beyond what feel we could achieve through changes in layout, tile art, and enemy/item/spawn placement. The best way to browse the game’s music and see who’s responsible for each track is to play Zylatov Sisters and scroll around on the level select screen.

Last semester, I put together and updated a single summary presentation of highlights from those slides, which is now available on SlideShare as Controlling Project Size for Student/Hobby Videogame Development.

If you already know how to program (and/or some other fundamental videogame development skills) but are looking to transition into non-commercial group projects, concepts in these slides may help save some heartache or common dead ends and ease the transition:

http://www.slideshare.net/chrisdeleon/studenthobby-videogame-project-scope-control

Conceptually this entry is along similar lines to Galaga and Making Interesting Decisions, although Mediated Input focuses on contrast between athletics and real-time videogames rather than pure-decision games and real-time videogames.

Topics discussed include:

• Which types of tacit skills direct-control simulations train well for, and why
  
  
• Separating execution from strategy in games
  
  
• Performance probability as a function of personal ability, preparation, and circumstance
  
  
• Market benefits of controller-based gameplay
  
  
• Distinction between tool use and mediated input
  
  
• Limitations and design for motion control

The write-up is available in PDF on Scribd:

>> View it at http://www.scribd.com/doc/79048987/Mediated-Input <<

The benefits of this transition are broader distribution (easy to reach thousands of players, or more, within days), trivial cross-platform support, and simplification of user experience (no install, configuration, or uninstall – just visit a URL). As tradeoffs: total file size matters for loading/download time, and keeping up performance can involve a few tricks. However both of those tradeoffs are matters developers are historically used to working with for other reasons, such a limited media storage and older processors, so there are traditions and patterns for designing to get the most out of such constraints.

AS3 is also free to use, provided you know how to navigate command-line. If you’re using Windows then FlashDevelop is even available as a free IDE to manage project files and compiler settings.

I’ve already written a number of entries and sample projects about AS3, but they’re a bit spread about. Since I’ve been pulling together the same links for multiple replies, it seemed time for a new summary post specifically on this subject.

MXMLC Install and Basics

MXMLC is the name of the command-line compiler used to translate ActionScript 3 code into a SWF file for usage in the Flash player/plug-in.

• Part 1: MXMLC Command-Line Compilation – download and usage
  
  
• Part 2: Flash Game Core Tutorial – images, input, audio, collision, real-time updates
  
  
• Part 3: Motion Tutorial – button-like key handling, move-to-click, gravity bounce

Recompilation Scripts, Opening the Debugger – Using scripts for recompilation, and getting started with the command-line debugger

Remember to add a MochiBot to swfs as a way to keep track of plays. Many plays occur not on the original sites submitted to (Kongregate, Newgrounds, or otherwise), but instead on dozens or hundreds of other sites where the swf gets reposted. Using a few lines to add MochiBot to the project makes it possible to see where on the internet the game has been rehosted, and makes it easy to see simple graphs and counters for total plays.

It’ll be handy to bookmark Adobe’s official ActionScript 3 reference site to verify which functions and variables are available on existing classes, as well as checking which imports are needed for particular types of built-in functionality.

Sample Code

Beginner AS3 sample code (zip) – Very basic, but functional and ready for compilation

Everyone’s Platformer – Advanced platformer example, built from the ground up, that incorporates external file loading, optimized collision detection, a built-in level editor, and a variety of other features

This engine was used as the foundation for Vision by Proxy: Second Edition.

Everyone’s Platformer Level Editor Manual – Usage documentation for the level editor built into Everyone’s Platformer

2D Platformer Advanced Collision Detection – Technical and conceptual documentation about the collision detection in the Everyone’s Platformer AS3 example above

One not by me, but particularly useful if you have more retro-style games as the target, is the EZPlatformer example for Flixel. We used this tutorial as the foundation for Zylatov Sisters, as described in the entry on process for that project.

How to Monetize?

My main advice on Flash game monetization is to hold off a bit before aiming to do it. I make this suggestion for two reasons:

1. Focusing on money for early projects can get in the way of freely exploring design ideas and technical lessons, stunting opportunities to develop the skills that can later pay off.
   
   
2. Prematurely going after money is unlikely to be successful anyway, a bit like someone trying to sell their first attempts at poetry or oil painting. It generally takes considerable practice and experimentation to get to that level.

Although there are a variety of platforms available to support microtransactions, most of the people I know that have made money through Flash games did so through either licensing their games (getting paid to site lock and rebrand them), using their games to help win competitions leading to XBLA/PSN/WiiWare deals, or as portfolio samples to land decently paying (if inconsistent) contract work.

I don’t know anyone doing particularly well from ads in Flash games. Perhaps someone somewhere is, but as far as I can tell ads junk up the experience, and rarely make enough to justify that negative effect on the design. If deliberating the addition of ads, do the math as to the number of views necessary for the ads to produce any non-trivial earnings – and consider the risk that the inclusion of ads may turn off some folks from returning to the game or sharing it. It is not simply a matter of deciding whether to make no money or some money, the latter by sticking ads in or on the game; if that “some” amounts to a really trivial amount relative to the time put into it, it may wind up serving no real purpose other than annoying players off the bat.

Elephant in the Room: HTML5

I touched on this question briefly a couple of months ago in Picking a Programming Language, but let’s address it head-on with a bit more detail here.

For interactive websites, yes, HTML5 is absolutely replacing Flash.

For real-time videogames, HTML5 seems to still be a long way from taking Flash’s place.

HTML5 renders differently on various browser and platform pairings. Like any website code subject to browser implementation, this can result in far more complicated testing, and even require branching in the code to account for different set ups.

HTML5 has trouble with basic audio. One common workaround for HTML5′s audio inadequacies is to use Flash for the audio. This clearly defeats whatever anti-Flash reasons drive some people to use HTML5.

(If you are using HTML5 for audio though, avoid using mp3.)

Out of the few dozen HTML5 games I’ve seen, their main selling point is that they’re made in HTML5 – not that they do anything new or different that players find value in, not because they were faster or easier for the developers to make, and not on account of the games being particularly good.

To double check my concerns about HTML5, I went to HTML5Games.com, an aggregation site. I tried to play a well rated, top ranked game, but every few seconds the game reloaded every tab that I had open, including the tab that the game was in. I was never actually able to see it in action, but at least closing that tab put everything back to normal. While I recognize that every HTML5 game doesn’t fail that severely, it probably doesn’t take many experiences like that one for a non-programmer to abandon a games site. I’ll bet that game works fine in Google Chrome, which has excellent HTML5 support, however if we’re going to require our players to install and use a particular browser our web games will immediately be at a major disadvantage.

Nor has it actually mattered much that these real-time HTML5 games are more likely to work on mobile devices than Flash. For interactive websites, it matters that HTML5 runs on mobile devices. For real-time videogames, typically programmed to use keyboard controls, or using mouseover/hover effect, etc. even if the swf ran flawlessly on mobile devices, most Flash games wouldn’t be usable on those platforms anyway without a substantial redesign. Moreover, Internet Explorer still has limited HTML5 support, and since it’s the default browser on the dominant operating system that’s a pretty significant set of users being lost as a tradeoff.

But, someone as recently asked, what about the Angry Birds implementation in HTML5? Though it’s admittedly an impressive port, it came only after the game’s massive success on iPhone set up the company to have resources for thoroughly testing and accounting for every browser and OS combination to get their completely designed game ported. (The core gameplay of Angry Birds, as a bit of an aside, follows in the footsteps of the style popularized earlier by the Flash game Crush the Castle.)

HTML5 seems to offer the cross-browser quagmire of web design to game design. Although, if the goal is to make an interactive multimedia website, HTML5 fits that task great. HTML5 is also a viable candidate for non-real-time games that primarily consist of navigating menus and clicking buttons to select choices. For the types of real-time games I develop, AS3 still looks like it will be the reasonable choice for the foreseeable future.

1. The license indicates that use of the assets is “limited to a single application” – this is a one-time use license.
   
   
2. That same license dictates that “You must not incorporate the Work in a work which is created for Resale by you or your client.” – anything produced using even a single one of these assets (including the textures) can never legally be sold.
   
   
3. Non-exclusive rights to assets make them extraordinarily less valuable. When players start seeing what are obviously the same assets in other games it makes the developers using those assets look either cheap, amateur (this is clip art), or worse, like a thief (the majority of players do not understand nor expect licensing of content to happen across games). Exception to this expectation is made, if ever, for sequels of the same game, which concern #1 prevents anyway.
   
   
4. Using generic assets in games for anything besides far off background decoration (ex. outsourced/generic assets may do if you need a few dozen spooky tree silhouettes on the horizon) dilutes a videogame’s opportunity to dictate and present a characteristic style. Whatever art your game requires that isn’t from the pack – and such art will always be needed for menus, interface, player character, cursor, etc. – will not match the art in the game.
   
   
5. On a similar point: leaning on generic assets also tightly constrains a developer’s design freedom since they’ll be unequipped to extend on the same art style. If your game needs a chaingun, it won’t match the art style of the sniper rifle from the pack; if your game needs a robot factory, it won’t match the art style of the hospital from the pack, etc. Generally it would be far better to use a slightly less professional style but one that you or someone on the team is able to match with consistency across the entire game. If you’re really bad at in-game art, you’d still be better off using placeholder programmer art for everything, then once the game works and plays well enough to persuade a capable artist to get involved, fixing the problem that way. Or, alternatively, finding a style to employ that fits your constraints (pixelated and stickman games have both done fine, when the gameplay was done right) or strengths (ex. programmatic effects, minimalist design, etc.).

I don’t think that the people selling these assets have any ill intentions. But I think that in practice, whether or not it was their intention, they’re making a quick buck off people that will be no better off with the pack than they were before.

There are other types of files in the bundle besides artwork – a couple of Unity tutorials, example particle systems, etc. – but there’s no reason to suspect they are any better than similar things which can be found free elsewhere.

Zylatov Sisters is now finished and online. It’s the result of 10 weeks of work by 10 student developers, myself included. We created it alongside classwork and our various other obligations – none of us were on it full-time. We used an unusual design process to orchestrate our work and decisions in a modular fashion with minimal management overhead, which increased ownership over particular elements for each designer. I documented the first four weeks of that process in a previous HGD entry about the making-of. I think it worked out pretty well, came together better than I expected, and required significantly less coordination than I’m used to doing with other teams.

Zylatov Sisters a fixed difficulty game, tuned and paced to the difficulty of pinball in terms of approximate expected time per ball/life. The player is almost always within seconds of losing a life. Loss tends to occur from a lapse in attention, errors in timing, or overreaching in taking excessive risks under pressure. Player high scores are stored locally, rather than using global leaderboards. Gameplay is endless until all lives are lost, striving for an ever higher score rather than trying to overcome a boss or fixed number of levels. The enemy AI types are simple, each a combination of momentum and randomness, making them fairly easy to anticipate (or at to least interpret the probability of loss due to being within any given distance and angle of them) but impossible to manipulate.

Stringing together frags raises the player’s multiplier, with special events happening at 5X (crate appears with special weapons or extra lives), 10X (temporary invulnerability), and 15X (instant level clear), serving to temporarily recognize varying degrees of exhilarating emergent moments. The game features no unlocks, partly because I didn’t want it to be a digestible, completable experience, partly because it works better this way for student portfolios, and partly because I wanted to follow my own theory that with varied content, everything should be unlocked. This resulted in a ‘horizontal’ game design, more like a row of pinball tables to pick from, rather than a sequentially locked tunnel. Which level players see first is random every time to avoid any notion of a “first” level.

We also made the decision to credit our inspirations upfront: Super Crate Box, Bubble Bobble, and pinball. We did this because (a.) as students, we see real value in crediting sources and believe it’s the right thing to do and (b.) our game is sufficiently different from any of the inspirations that we’re not worried about it being redundant. It’s atypical to see this type of acknowledgement in entertainment/fiction, for a variety of reasons, not the least of which is that on the rare occasions when we do see it there’s either large settlement payments made under duress (as with Harlan Ellison’s acknowledgment at the end of Terminator), or comes across as a junky SEO attempt to get search attention (“If you liked Angry Birds, then you’ll love…”). For what it’s worth, Vlambeer, Super Crate Box‘s developers, gave us their blessing via e-mail, however I did not attempt to contact Taito. Taito is a big overseas corporation, Bubble Bobble came out 25 years ago, and the original designer Fukio “MTJ” Mitsuji (who is the only person I would care to hear the ok from) passed away in 2008.

In a similarly odd decision, we crammed all the credits upfront. I first tried this approach with Alice in Bomberland. I did so because I wanted to credit individuals rather than an abstract logo, but also because I’ve never worked with the same team twice – any such logo would be a one-off anyway, rather than a meaningful brand. In this case it’s also relevant that Zylatov Sisters is intended as portfolio work for students, so specificity and visibility regarding contributions helps toward that end. Lastly, given my own priorities as a hobby videogame development evangelist, I like that this approach emphasizes to players that games are a craft made by people working together. (This last point may sound silly or obvious to adults, but as a child it didn’t occur to me until I saw “Made in Japan” on a SNES cartridge – the layers of consumer process are very distancing. Games just seemed like magical things that mysteriously showed up on shelves for purchase, like apples or hot dogs.)

Anyhow, nothing I write here is going to say more about Zylatov Sisters than playing Zylatov Sisters (click here to play). This isn’t a post-mortem in a magazine about some $60 game for hardware you may or may not own, that would need weeks of play to yield context. It’s a free 6 MB cross-platform game, with all content unlocked upfront, played entirely in-browser, involving rounds that typically last 1-5 minutes. Give it a shot!

Note: If the above game links don’t work, try playing it on NewGrounds. If that doesn’t load either, a newer version of Flash player might be needed.

[Updated: the rest of the paper, Mediated Input, is now finished and available]

The paper as a whole focuses on mediated input: the use of mechanical and/or electrical controls rather than full-body athletic movements. Input mediation is present when using a button to virtually swing a sword or pass a ball, but not when using our arms to execute the same tasks in reality.

Context

Content leading up to this section, not included in this entry, explores mediated input as the reason why training simulations are successful for cars and aircraft but much less so for sports performance. I then detail the relationship between physical skills and strategic skills in athletic play. In short, I attempt to show in that while these timing and spatial concepts that follow indeed also apply to athletic skills, the complexity of coordination required for sports fundamentals makes the timing and spatial challenges less prominent except at very high levels of well-matched skill, and consequently less accessible to players that are unable or unwilling to commit considerable time to years of deliberate practice.

The excerpt below relates to the nature of skill in mediated input. In other words: since videogame players are able to make complex actions happen at the press of a button, what does is it mean for someone to be better or worse at these actions? How does design of mediated input lead to skills that can be improved by practice?

Excerpt from Latest Draft

Mediated input makes how some action is performed a non-issue, to bring emphasis to when and whether that action is performed. Instead of spending years practicing to achieve expert level in how to swing a baseball bat or complete a long pass, mediated input lets a player press a button to trigger a consistent performance of some action.

Although the main use of mediated input that interests me – videogames – takes place entirely in virtual space, that isn’t the only place where we can find mediated input. Pinball, for example, mediates input to transform button pressing into consistent, mechanical in-game actions. The steering wheel and pedals in a car, or likewise the joystick, throttle, and switches used in planes and helicopters, are also primarily mechanical, physical examples. Because primitive cases are easiest to dissect, and both the physical simulation and input devices for older videogames were comparatively simpler to those seen used in today’s games, in this section I focus primarily on examples in classic arcade videogames. I emphasize the existence of these more complex examples to recognize that though I’m mostly writing about simple arcade button controls, newer and specialized gaming controllers including high-end joysticks, steering wheels, and dual-analog controllers are still mediated input, and my sense is that many of the same ideas covered here can apply to those with a bit of extra work and extrapolation.

Margin of Error

The most basic skill that can be judged by mediated input is pure response time: how long does it take the player to respond to a visual or audio cue?

Difficulty in this case begins as a question of how long after the game’s cue a player can still press the button to accomplish the intended purpose. If responding anytime within one second of the cue is equally successful, nearly anyone could do it; if the allowed window is tuned closer to the typical reaction time, around 150-250 ms, occasional failure from hesitation becomes more likely. Where this becomes more interesting, however, is in considering the consequence for missing the optimal window in either direction.

Just as a golfer needs to weigh the risks of what may happen if their shot strays spatially from where they aim (perhaps accepting a less ideal distance or line to avoid risk of water hazard or sand trap), a player using mediated input needs to consider the consequences of their press or release straying temporally from its intended moment. Depending on how a particular game is designed, pressing earlier or later than the window for the player’s intended result may produce no effect, a weaker effect, a less predictable effect, or simply some different result that might have been desirable in a different context or strategy.

Some games, including Centipede [Atari 1982] and Space Invaders [Taito 1978], limit a player’s rate of fire to a single shot on screen at a time. An emergent effect of this limit is that firing too early or too late can miss a moving target, leaving the player defenseless until the shot either leaves the screen or hits something else. (Galaga [Namco 1981] used a similar reload system, though allowing 2 shots on screen at once.)

This pattern of vulnerability following a poorly timed action is still quite common. In addition to still being based by reload or rate of fire limitations for gun-oriented games, in hand-to-hand and melee fighting games this often appears as a period of vulnerability after an attack misses its mark. One example of this is the momentary pause that occurs after Voldo’s Elbow Smash in Soul Caliber II [Namco 2002], which leaves the character briefly exposed to counterattack if the strike misses.

Spatial Relationships

In addition to gauging time, another factor in skill for mediated input is a player’s ability to reliably gauge distances. Distances in this case may be between currently motionless objects, as in gauging a projectile’s range, or combined with the previous consideration for timeliness to extrapolate distances into the immediate future. Although performing that Elbow Smash attack with poor timing leaves Voldo exposed, what makes any particular timing poor is that Voldo is at that moment out of range. An experienced player acquires through practice and experimentation a more exact and accurate feel for the ranges of various attacks and the movement speeds of characters to line up or avoid particular collisions.

Likewise for the shots in Centipede and Space Invaders that miss: the reason why some shot timing is wrong and other timing is right is a matter of how the player times the projectiles to lead and meet intended targets. Rather than simply having a light come on or a sound play, as we might see in a pure test to measure reaction time, videogames typically require a player to interpret spatial and temporal relationships as timing cues.

Fixed Delay After Cue

Another form of difficulty takes shape as a fixed delay between the hint and the action that requires response. In the same way that spatial relationships require gaining a feel for consistent distances, this aspect of skill requires learning to pause for consistent delays. Rather than the player rushing to press a button as quickly as possible within some time after a signal, the window of time when input will yield a desired effect begins instead some learnable period of time after the need for that input is telegraphed.

I am using “telegraphed” here in how the term is used for athletics, meaning to transmit subtle, generally unintentional warning prior to performing some action. Since this provides an opponent with information about what’s about to happen, telegraphing makes it easier for the opponent to respond appropriately and follow with a suitable counter. In many sports, among them fencing, wrestling, and American football, athletes train partly to overcome instinctive tendencies to telegraph (except when deliberately faking out or misleading). Even a subconscious glance may be enough to give away intention, spoiling an opportunity to catch an opponent off guard.

First, note that in the case of mediated input, telegraphing by human players is a much less nuanced or important issue than it is in athletics. While it’s true that in head-to-head fighting games like Street Fighter II [Capcom 1991] a player may infer and thus counter which action is most likely to follow a leading attack (a simple example being Ken performing a jump kick followed immediately by a leg sweep), that chain of actions is hardly a subtle or unintended instinct to be trained away. A Street Fighter II character doesn’t have problems with eyes glancing, feet pointing, or balancing shifting in telltale ways. If anything, watching a player’s changes in finger or wrist positions during play might provide clues, but at best those clues would be ambiguous, and the pace of what happens on-screen prevents that tactic from being feasible.

On the other hand, telegraphing is often designed as a weakness for computer controlled characters in single player games, as a way to keep gameplay fair. Because events in videogames are not subject to the same physical limitations as bodies in sports, an attack in virtual space can happen practically instantly, within a single 1/60th second update cycle. To make up for this, telegraphing is usually built into enemy animations or attack sequences. Part of the player’s challenge then becomes learning how long after the hint the matching action will follow. Boxers in Mike Tyson’s Punch-Out!! [Nintendo 1987] on NES do this, for example with Bald Bull’s character crouching a consistent amount of time before each uppercut. More recently Demon’s Souls [From Software 2009] employed similar animation cues, as when Silver Skeleton enemies attack quickly, though always a fixed interval after the animation draws the sword back.

Due to the enemy’s increased vulnerability following a missed attack, similar to Voldo after his Elbow Smash, games typically integrate this delay after cue into a sequence of events to be learned then practiced:

1. The player tries unsuccessfully to attack the enemy under normal circumstances, quickly discovering that this type of enemy has a high or certain probability of blocking, deflecting, or countering plain attacks.
   
   
2. The enemy telegraphs an upcoming attack on the player.
   
   
3. After pausing for an amount of time the player has learned through observation (or trial and error), the player dodges the enemy’s attack just as it happens. Note that the attack animation in these cases is typically too fast to be reliably handled by waiting for the actual attack to start before reacting. This necessitates the player paying attention to the enemy’s telegraphing.
   
   
4. The player immediately follows up using input to close the gap created by dodging.
   
   
5. The player attacks right as he or she is coming within range of the enemy, before enough time has passed for the enemy to recover. As a matter for difficulty tuning, increasing how long the enemy remains vulnerable after each miss decreases how precisely the player needs to learn the timing and distances involved.

At least a game mechanics level, Mike Tyson’s Punch-Out!! and melee in Demon’s Souls can be largely understood as a nearly constant repetition of the above sequence for the player to master those timings against numerous types of characters. Mike Tyson’s Punch-Out!! adds difficulty by having a number of different telegraphed move types per opponent, whereas Demon’s Souls increases difficulty by having the player juggle the sequence at different phases for multiple enemies at once. Boss characters in both games tend to be characterized by more severe consequences for getting the timing wrong in response to telegraphing.

Assistance by Partial Automation

The level of automatic behavior resulting from a button press can also affect the type of skill applied. In the two cases just discussed, player controls affect a single on-screen avatar, but in Mike Tyson’s Punch-Out!! the button to dodge immediately returns the player to position to follow with a punch (automating step #4 in the above sequence), whereas in Demon’s Souls the player has to use movement commands to manually return within striking range after dodging.

Similar but more extreme contrast can be seen in the difference between fighting mechanics in a game like Skyrim [Bethesda 2011] versus a now standard MMO like World of Warcraft [Blizzard 2004]. Attack actions for Skyrim, at least for melee, require telegraph reading as well as drilled timing and spatial estimation for a more forgiving version of the sequence outlined for Demon’s Souls. By comparison, in WoW the player specifies which enemy they mean to target, and how, after which automation takes over and handles the delivery of attacks in a more mathematically predictable way. By removing the action-style gameplay, WoW distills the more strategic considerations over which opponents to engage, in what order, and with what type of attack.

Compare too the level of abstraction allowed by automation in virtual football games: rather than making the player indicate the angle and force behind a throw, as they might in an artillery game, by convention players are instead only responsible for which player to pass to and when. In this way Madden games emphasize the strategic level of football rather than the challenges involved in performing fundamentals. The angles and forces for the throw to be attempted are handled automatically, for much the same reason that WoW automates the combat details. Mediated input enables players to deal with the sport at a level of abstraction that is normally only accessible to people with copious experience, talent, and body mass.

Fixed Delay After Input

The relationship between timing and input commands also needs to be learned from the other direction: a player has to consistently account for the timing between initiating an action and the consequential moment(s) of that action.

In Skyrim the larger, heavier melee weapons don’t deliver damage until a few fractions of a second into their animation, which is enough of a difference to throw off a player’s rhythm when trying to move in to strike between the enemy’s missed swings.

In the case of mediated input for virtual baseball games, even though the button press automatically swings the bat the same way every time, there is still some delay between pressing the button and the bat being straight across home plate. In these cases, depending on the game’s implementation, the player may need to press the swing button a bit before the ball passes into the strike zone, rather than waiting for it to reach the point in space at which the player means to hit it.

In Donkey Kong [Nintendo 1981] barrels roll at a constant speed and Jumpman’s running jumps always rise to a consistent height, moving laterally at a fixed speed. Since the barrels are almost tall enough to reach Jumpman’s feet during a leap, a very basic skill to be mastered in Donkey Kong is learning how far away a barrel should be in order for a jump to safely clear it, to account for how long it takes Mario to reach the pinnacle of his jump. Jumping over the large scorpions in Pitfall! [Activision 1982] involved a nearly identical skill.

A subtle variation on this aspect occurs in later games such as Super Mario Bros [Nintendo 1986] that varied jump height and time based on how long the player held the button. Mario’s artificial momentum delays the effect of releasing the button, making a bit of practice necessary to consistently land on platforms at various heights and distances.

Accountability for Multiple Entities

Splitting attention across multiple player entities is another aspect of difficulty possible with mediated input that doesn’t have a clear analog in sport. I referred earlier to Demon’s Souls attacking the player with multiple entities at once, but what I intend to highlight here is the inverse: the player needing to simultaneously control and oversee the welfare of multiple entities.

In Missile Command [Atari 1980] the player had 3 different missile bases to protect, each independently being a point of vulnerability, ammunition, and defense. Rather than being responsible for spatial awareness around a single avatar, as is often the case, attention in such games needs to be shared across several units, playing either by gestalt or by quickly shifting focus to simulate multitasking.

In a real-time strategy (RTS) game like StarCraft [Blizzard 2000], the player’s attention becomes split among managing the state and actions for dozens or even hundreds of units. Here again an element of automatic behavior comes into play, made possible by the computer medium: units in an RTS game are able to assume basic intentions on behalf of the player. Without requiring granular instruction, units can be given a goal (ex. reach a certain point on the map, attack a certain enemy, guard a certain ally) and they will independently handle seeing to that goal’s completion (navigating around obstacles, firing until the target is destroyed, following the ally). The units in these types of games fire in self-defense, without requiring instruction by the player to do so. As with the above examples of automation, these assumed behaviors elevate the level of abstraction for the game’s skills, letting the player focus more on strategic decisions instead of getting bogged down in overseeing each independent entity’s immediate actions.

Actions Per Minute

Even with the mediated input and unit automation, it’s still possible for a player in StarCraft to become tied up by needing to micromanage. That occurs when a player becomes out-micromanaged by their opponent.

Issuing orders in the game is done via mouse, in combination with keyboard shortcuts, and that mouse fills many purposes depending upon which on-screen element is under the cursor when clicked. Because the screen’s interface buttons and unit selection areas are small in comparison to the mouse’s coordinate space, a physical skill becomes relevant for RTS games that’s not applicable to many other genres: using the mouse very quickly and accurately to achieve a high number of Actions Per Minute (APM). APM refers to how many meaningful commands a player can issue to the game each minute, which ranges from around 50 for casual players to 150 or more for professionals (numbers via StarCraft Wiki). Possessing a substantial advantage over the opponent in this skill makes it possible for one player to overwhelm the other by spreading attention among more tasks than he or she can handle.

Missile Command, using a large trackball for coordinate control rather than a mouse, is one of the earlier precursors in which APM can play a major role in player success. Combined with the skills mentioned earlier about properly estimating how positions will change over time (a factor emphasized in Missile Command by the warheads traveling at slow, constant velocities), later levels of the game overwhelm players by demanding a high level of speed and precision with the controls that becomes physically difficult.

Button Flick

Although it’s more rare, physical coordination can also be an issue when pressing a button. In pinball, there are ball control maneuvers that require extremely fast press-and-release, or alternatively very rapid release-then-repress. Even if a player knows exactly what needs to be done, having just watched another player demonstrate and describe the move, it takes practice to execute these moves consistently without failing to press or release the button far enough to alternate its signal, or by making the switch slightly too long, spoiling the desired effect. Instead of hopping the pinball smoothly from one flipper to another, it might instead be tossed up against the slingshot bumper, or else simply roll into the drain.

For videogames in which it is advantageous to be able to mash a button very rapidly, as when getting up from being knocked down in Mike Tyson’s Punch-Out!! or escaping grapples in wrestling and zombie games, experimentation with different ways to hold the controller may be necessary before someone can find a method that works best for them.

Controller Contortions

Physical skill can also become a factor when there are more buttons to manage than fingers to press them. Even handling 5 buttons with 4 fingers in Guitar Hero [Harmonix 2005] becomes difficult, despite the game’s visual representation and memorable audio cues being an idealized expression of each button’s required timing for press and release.

Although the Nintendo’s 64′s controller is only meant to use buttons on 2 of its 3 holding grips at once, some games such as BattleTanx: Global Assault [3DO 1999] included situations with input mappings that involve controls on all 3 grips. This forced players to discover unusual ways to hold the controller to maintain simultaneous access to all relevant actions.

What to Act Upon

Mediated input frees the player to focus not only on when and whether to perform an action, but by extension, to what. This is part of the decision space mentioned as a consideration for battle in World of Warcraft. There may be strategic reasons to attack enemies in a particular order, such as prioritizing enemies that heal or otherwise provide boosts to their peers.

One way to manage playfield risk in Asteroids [Atari 1979] is to focus on one asteroid and its children fragments before breaking open others. This approach can significantly reduce the number and speed of tiny obstacles to dodge.

In Bubble Bobble [Taito 1986], enemies trapped in a player’s bubble but not popped quickly enough become angry, changing color and moving much faster than normal enemies. This provides incentive for the player to deal with tasks according to a certain method, namely following through promptly on the kill for trapped enemies, rather than haphazardly trapping enemies whenever it’s momentarily convenient to do so.

Chord Progressions

Adapting this term loosely from musical vocabulary, in this context a chord progression refers to a string of timed inputs to achieve some repeatable effect. The role of chord progression in skill for mediated input is in the ability to practice then replay a sequence on demand to fulfill a particular purpose.

Note that this is not the same as performing a special move in Street Fighter II, since the purpose of that type of input sequence is to initiate an action unrelated to its constituent input events. A chord progression, by contrast, is simply the sum of its well-timed individual parts.

In Gravitar [Atari 1982], bringing the ship quickly into a controlled hover is an important fundamental skill. Likewise, safely performing a flip from hover to strafe a target, then returning to back to hover, is another primitive chord progression that builds off the ability to achieve hover.

In Bubble Bobble, learning to climb walls by releasing a bubble against a wall at the correct time while bouncing off the previous bubble is another example.

Activating pinball flippers rapidly but at slightly different times (a slap save) is a common chord progression used to save the ball from draining.

Chord progressions in first-person shooters might include circle strafing while keeping an opponent in the player’s reticle (universal among FPS games) or executing a rocket jump while taking minimum damage (as in Team Fortress [TFS 1996] or Quake 3 [id 1999]).

Similar to how a professional hockey player practices fundamentals so that they can shoot for an intended part of the goal, rather than worrying about how to use their stick to make the puck get there, identifying and becoming fluent at the chord progressions for a game empowers a player to deal with the game at a more strategic level. Rather than struggling anew each time to bring the Gravitar ship under control or to figure out how to reach higher areas in Bubble Bobble stages, a player comfortable with the basic chord progressions can instead focus attention on where and when to stop the ship, or when and why to climb a wall. A player experienced with safe and consistent rocket jumping in Team Fortress gains access to additional routes in certain maps.

Another feature shared between chord progressions and athletic skills is that a player’s execution of either is likely to never quite be perfect, to always involve a bit of unpredictable variation, and to be a potential source of error during play.

Angles and Analog

My emphasis throughout has mostly been on the usage of action buttons. Although modern ports and remakes don’t often make it clear, Asteroids only used buttons, having separate buttons to turn left and turn right rather than using a joystick. Early joysticks were frequently constrained to one axis, as was the case for a vertical stick on Defender [Williams 1980] or the horizontal stick for Bubble Bubble. On account of being handled in either hardware or software as digital (non-analog) input, in practice early joysticks offered functionality identical to a pair of buttons simply built in way that prevents them from being simultaneously pressed.

However trackballs and “paddles” (dial wheels) were common among early controls, and were used in Centipede and Pong [Atari 1972] respectively. Here it becomes necessary to reiterate that it isn’t the use of action buttons that qualifies interaction as mediated input; it’s the use of a device requiring only efficient expression of user intent which then gets automatically transformed into a consistent and learnable action.

For actions that are either happening or not, and the place of user intent is solely related to timing those actions, a button is the appropriate control. When a player instead is responsible for indicating a position along a line, a dial works well for rapidly indicating fine spatial distinctions; when a player needs to indicate angle and magnitude, a trackball or analog joystick fits that role well.

However this added fidelity introduces one or more axes of physical coordination to be mastered by the player.

In Pong, in which players set the paddle’s vertical position by twisting an analog dial, part of the challenge is learning how much rotation is needed to move the paddle to the position intended without under- or overshooting. Note here that an alternative input device that would enable the player to more directly indicate where they wish for the paddle to be, such as an iPad’s touchscreen or the vertical movements of a computer mouse, actually interferes to some degree with Pong‘s central difficulty and sense of accomplishment.

When the player intends to use the analog stick to sneak in Super Mario 64 [Nintendo 1996], a twitch outsize the threshold to sneak may cause the character to briefly run instead; when the player intends to walk at a certain angle relative to the camera to cross a narrow bridge, frequent adjustments may be needed to find and stay along that line. Particularly since SM64 was among the earliest popular games to use an analog thumbstick, part of the game’s difficulty derived from, and balanced against, learning to handle that form of mediated input.

Defying Principles for Effect

Mediated input enables a player to express intentions efficiently, easily, and directly. Deliberate inversions of those ideals can be used to accomplish particular effects. There are occasionally gameplay reasons for mediated input to be deliberately inefficient, unnaturally mapped, or indirect.

Designed Inefficiency

In Street Fighter II, executing special moves requires a sequence of button and joystick inputs in order to throw fireballs, perform jumping uppercuts, or a number of other moves unique to each character. Unlike chord progressions, these special moves are all or nothing; the end result is a completely separate maneuver, not a string of separate input events over time.

These moves are not unstoppable – most leave a player vulnerable to certain other attacks – so it’s not as though whichever player is able to perform these maneuvers wins. Conceivably, extra buttons could have been provided for each player, to instantly and consistently execute each character’s special moves. If the sequences only existed to accommodate lack of buttons, there are certainly shorter, simpler, and easier sequences or combinations that might have been used, and in that case the same commands might even be used for every character (as is largely the case for Super Smash Bros [Nintendo 1999]).

Instead, the inefficiency, delay, and inherent clumsiness in executing special moves is that way by design. The power and range of each move is offset by the risk of attempting but failing to accomplish the attack, contributing to the strategy, excitement, and unpredictability of head-to-head matches.

Counterintuitive Mapping

Directional controls typically use a natural mapping, meaning that the correlation between input and action is obvious: moving the joystick left moves the character left, moving the joystick down moves the character down, and so on. Super Bomberman [Hudson Soft 1993] on SNES usually follows this scheme, but when the player picks up a poison Skull item that player’s controls temporarily reverse, switching left with right and up with down. Secret of Mana [Square 1993] applied this same type of input reversal for the Confused status caused by certain attacks and spells.

In these cases, the controls are abruptly and temporarily made counter-intuitive in order to cause the player to struggle at a basic task that was previously trivial.

Indirect Control

Directness is another central quality of mediated input. Absolute and immediate mappings provide the most direct control: hold left to move left, then release left to stop moving left. Games like RoboTron 2084 [Williams 1982] and Adventure [Atari 1979] exhibit that type of direct control. In contrast, a number of early space games including Spacewar! [Russell et al. 1962], Computer Space [Atari 1979], and Asteroids employed vehicle-relative rotational steering, and a thrust button to add speed along the ship’s current heading, but no brakes. The indirectness of these controls requires players to develop a sense for estimating how much room the ship needs in order to evade danger or come to a stop.

The difficulty and replay value in these games is based at least partly on the difficulty and satisfaction of mastering these estimations.

To be Continued…

After the section included here, the full paper closes with an analysis of implications and issues around designing for motion controls. That segment, along with the earlier part of this paper distinguishing athletic skill from strategic skill in sport, will be posted separately at a later date.

[Updated: the rest of the paper, Mediated Input, is now finished and available]

Game progamming is not something someone goes from not knowing to knowing, in the same way that someone goes from not knowing how to drive to knowing how to drive, or from not knowing how to read to being able to read. Even disregarding other purposes of programming, looking specifically at programming for videogame creation, there is an enormous range of potential outcomes, and many different metrics by which someone’s work might be evaluated.

The question is a bit like asking how long it takes to learn how to paint a picture, or how to play an instrument. Getting set up and putting a paint-covered brush on canvas or producing a musical note can probably happen on day one, but after that there are people who devote decades of their lives to becoming better and/or more versatile at these tasks. Then there’s everyone in-between, from people a few weeks or months in (able to poorly mimic the prior work of others), to those a few years in (able to effectly mimic and perhaps personalize the prior work of others), to those several or more years in that begin to identify with the art, striving to excel in either classical execution or exploring to discover a distinctly personal style.

Game programming is similar. Getting a development environment installed and configured to turn sample code from a book or website into a runnable application can probably happen on day 1, or at least within the first few days depending on the amount of troubleshooting needed. Once that works, there are a few fundamental concepts and new vocabulary words to pick up, then a bit of puzzling over example code to make sense out of why it behaves as it does. This is typically followed by being able to modify example code to achieve slightly different results, increasingly so until someone’s familiar with enough patterns and basics to start building something on their own. Even still, that first something will usually be quite familiar to previous dabbling, more a partial mash-up of ideas than a project made from scratch, but there’s nothing wrong with doing that to gain practice.

From here, there are countless directions in which to grow in the art of game programming. Someone might focus their energy on writing well-documented, easily understood code, learning about best practices to work more effectively with one or more other programmers on a team. Such skills are essential for career programmers on large teams, although their importance among solo and hobby developers varies so long as they are able to produce the results they desire. Someone could become a specialist in highly technical details or specific problems that other programmers count on libraries or engines to solve, learning how to write better network code, graphics rendering/effects, memory management, custom file formats (such as levels, packed images, etc.), or ways to address common issues involved in making in-game artificial intelligence. It’s also an option within the repitoire of a game programmer to delve into hardware interfacing and the construction of custom input or output devices, to make games utilizing new types of controllers (think about how games like DDR and Guitar Hero might have started) or unusual forms of output (tactile feedback, external LEDs, etc.).

Then there is the matter of learning more programming languages and development tools. Occasional shifts in technology – along with an acquired sense for when it’s appropriate to switch between competing technologies – can feel like setbacks at the time, but in the long haul they can save a lot of time and effort if done wisely.

Also like painting or playing an instrument, some people will find that they immediately feel somewhat natural about it, or seem to achieve presentable efforts earlier in their exploration of the form, while others may need a bit more time to fiddle and experiment before feeling as comfortable. How long someone takes to feel like they have a handle on it isn’t necessarily a sign of how much they’ll accomplish with it though – like any creative endeavor, persistence and plenty of practice will gradually outpace others that don’t work at it.

Any game programmer is also able to stretch themselves too thin or to focus, either taking on a task at the edge of what they can keep organized and directed through to completion, or, alternatively, doing what they have a lot of practice at doing well. An inexperienced programmer may technically be able to make an RPG from scratch, but it will be a very bad one by historical standards. Likewise, a very experienced programmer can still make a simple breakout-style or classic tank game of the sort that an inexperienced programmer might be wise to take on, but it could likely be done by the expert in much less time, with (virtually) no crash issues, and/or at a much higher level of overall polish.

The last similarity to painting or playing an instrument is that, especially at a hobby level for personal enrichment and enjoyment, game programming is something that anyone with enough patience can learn to do. Not everyone that paints is going to make works of art that sell for huge sums of money – very, very few will – and likewise the majority of people that play an instrument will likely never do so professionally. We’re quite used to painting and instrument playing being a healthy part of life without needing to see careers defined by them, for example hanging up paintings by our relatives around the home, or playing guitar in the company of friends. I’m eager to see the generation after ours find it increasingly normal to compete in the freeware videogame made by a close relative, or to hang out on weekends playing a videogame made by one or more of those friends playing.

Of course if someone does have a professional interest in game making, whether at a company or going it alone, they are much more likely to build momentum and relevant skills by creating videogames as a hobby than by simply talking and thinking about it.

This goes back to the opening question. Professional videogame programmers – including lifelong programmers with world-renowned accomplishments in the videogame industry – are still in the process of learning game programming, in the sense that they are continually learning new practices to make the most of new technologies. Someone is never done learning game programming until they are completely done with programming videogames, since the very act of programming videogames always involves some experimentation, digging through APIs, and solving problems that are new to us (even when said problems have been solved by someone else, some other way, some other time before, for all but very hardest and most general of problems we can often solve them on our own in less time and effort than it would take to dig up and adapt someone else’s solution).

But, roughly speaking, I’d offer the following estimates (remember that this is time to learn how to do something, not the time it takes to do it once learned) -

Recompiling and running existing sample code: 1 day.

Being able to tweak someone else’s code: a few days, to a few weeks.

Being able to significantly add to or change example code: a few months, to a few years, depending on the complexity of code being altered, or the size of the change being made.

Here there is already a massive dovetail of differences – adding a weapon to someone else’s 2D sh’mup example code is a very different undertaking than adding network play to an open-sourced single-player 3D game. To continue, though -

Being able to write a crummy game from scratch: a few months.

Being able to make a decent game: 1-3 years of practice.

Ability to create something a stranger might like: 2-5 years.

Ability to create something strangers might buy: 5-15 years, though obviously varies based on the price, the strangers, the project, the presentation, and a million other factors outside the programming itself.

Note too that due to the team nature of game development beyond the smallest scale, it’s somewhat possible to “import experience” by partnering with someone that has been doing it longer. Working with someone that has more practice with videogame creation can improve the overall quality of work coming from everyone on the team, due to the added ability for the team as a whole to detect and avoid common issues, to employ tried-and-proven strategies that have worked out on previous projects, and to build while accounting for how the big picture will need to come together by some fixed date in the future. When working alone, by comparison, those skills typically need to be learned cumulatively by working first on simple enough games that the light at the end of the tunnel is visible from the moment the project starts, then gradually incrementing project complexity in a way that the lessons learned from past projects can be built upon for the next.

In closing, here’s a fine comic about the “Teach Yourself C++ in 21 Days” books, and another software engineer’s excellent overview of the time and process involved in learning how to program.