Jeff On Games

Update: Better late than never, my talk is now on my site.

Happy New Year!

For those that don't know, in May (or so) I moved from Boston to Charlottesville, VA. Thankfully, the awesome people at Fire Hose have allowed me to stay with them and work remotely, so I haven't moved companies. I have, however, moved communities.

Charlottesville isn't a huge center for game development, but I think if could be a great place for game companies in the future. There's a lot of talent to be had from the neighboring universities (UVA, JMU, GMU, Virginia Tech, and William and Mary are all fairly close) and it's just a great place to live. It's not a big city, but that's actually what I like about it.

To try to help this along, I've created the Charlottesville Game Developers meet-up group. We've had a few small meetings so far, with mostly me talking, but coming up over the next few months, we're going to have some great talks about starting companies, working with the city of Charlottesville, and maybe more! (By the way, if you'd like to come visit Charlottesville and give a talk, let me know and we'll work something out).

Tonight, I'm giving a talk on tips for game jams. Since UVA has been nice enough (at my urging) to host a Global Game Jam site this year, I'm making sure everyone comes in prepared. Most of the tips come from my previous post mortems of game jams, but there will be some new stuff in there. I'll try to be sure to post the slides tomorrow as well, so everyone can get the benefit.

Anyway, if you're in the Charlottesville area, come out to our meetings! I'm really looking forward to seeing what the Charlottesville community can produce over the next year.

This weekend Boston Game Jams ran Cardboard Jam, a game jam where everyone made board or card games instead of making digital games. I have to say, I think I had way more fun at this game jam than at almost any other digital jam I've been a part of for a few reasons.

First, there's no tech choices or learning curve. At game digital game Jams, the first thing you have to do (once you have a game you want to create) is decide what technology you want to work in. This can be tough when you have multiple people who all come with different tech backgrounds and make them try to work together. Either you end up choosing teams based on tech that people know, or a few people end up working in tech they are unfamiliar with. This can make many digital game jams more about overcoming technical challenges, rather than overcoming design challenges in the game.

Second, other than the theme of the materials, there was no theme for this Jam. Though originally I thought this was a detriment, I am beginning to think that the lack of theme contributed to making this Jam awesome. In every game jam I've participated in, the themes have been aesthetic. They're themes like "immigration," "extinction," or "deception," and although they offer a good constraint on the Jam (and place everyone on equal footing for implementing an idea), they force most Jammers to think in terms of aesthetic first, mechanic last. This is why most Jammers can't "finish," because they're actually pushing for an aesthetic, rather than mechanical goal.

Last, jamming in board games meant that iteration cycles were really, really fast, which meant that you could focus on and tune the game and the mechanics quickly, which resulted in better games across the board. The game I worked on took about 10 minutes to play, and after initial discussion, we did nothing but play it, with short discussions in between. We probably play tested the game 50 times, each time with slightly tweaked rules to attempt to address problems we were seeing in the previous play through. Iteration times like this not only let you learn more about the game you're creating, but more about game design in general, since you see the results of you actions quickly. This speed of iteration and learning would have been impossible in a digital game jam, since implementing rule changes requires too many cycles. In digital game jams, if you get two to three full playtests in before time is up you're lucky, and that's including for teams that use prebuilt engines like Unity.

So in closing, if you get a chance to participate in a board game jam, you absolutely should. There's less stress, more learning, and way more collaboration. That, and you end up with an actually complete board game at the end, which is super awesome.

GDC is over, and my talk "From College To Industry: 20 Lessons Learned for Getting the Most out of Your Early Career" went fairly well I think.  The room was packed, which was no small feat considering how big it was, but I think that was mainly because those attending the Career Seminar had nowhere else to go during that time.  I could be wrong, though.  The title could have been that good.

Regardless, the slides for the talk are now posted and available for anyone.  I've been asked to give this talk a few more times, but I think I'm going to revise it a bit.  I really want to emphasize the two points about knowing business and making sure all the founders of a company are on the same page.  Of all the points in my talk, these two feel like the most important, but also the most belabored by other speakers, and also the most ignored.  They may be lessons that you have to learn the hard way, but want to do everything I can to really hammer those points home.  Hopefully I can accomplish that with revisions.

If you attended the talk, I'd love to hear your opinions and feedback.

Just to keep people in the know, I'm giving two talks in the coming months. The first will be at Games Forum Germany (site is in German, obviously, thought the talk will be in English) on either January 27^th or 28^th, I don't really know which. The talk is titled "Data Driven is Half the Battle" and will be talking about why just setting up data driven code isn't enough, and how (both from a high level and a low level) you can create a system for giving others on your team the ability to edit your data quickly and easily.

The second talk will be at GDC, as part of the Game Career Seminar, which takes place on the Friday of the conference and is focused at students. That talk is called "From College to Industry: 20 Lessons for Getting the Most out of your Early Career" and is about, well, getting the most out of your early career. It is basically a lessons learned talk about my 10 years attending GDC, and my 6 years in the game industry. While that isn't a really long time in the game industry (anymore), I feel that some of the lessons I've learned over that time will only really be apropos to students for a short time, and thus it is most useful for me to give the talk now, when it will be most useful to them. I will be practicing this talk twice in front of student groups around the Boston area, once at WPI and once at a local SIGGRAPH meeting, to make sure that the talks really hit all the right notes and lessons and are as useful as possible to the GDC student population.

Both talk's slides will be posted on line after the talks, and the GFG talk will probably be cross posted to the Toolsmiths, since it is a tools related talk.

I've been thinking recently that I should make a list of my favorite games of all time, especially as I find it harder and harder to find games that I like. For now, though, I want to mention several games that don't have the wide spread popularity I think they should, even in the development community. I'm always surprised when I'm talking to game developers and bring up specific games that I feel are "cannon" that they haven't played. So here's a list of 5 specific titles I think you should play.

1. Strife: I mention Strife in conversation a lot, and I'm always surprised how few people have even heard of it. Strife is a plot based, almost open world RPG like first person shooter, based on the Doom 2 engine, and was actually the last game to use the Doom 2 engine. In my opinion, the game was largely ignored mostly because it game out the same year as Quake, and the graphics couldn't compete with the more modern 3D engine. That said, the story is reasonable, the dialog is good to great at times, there are interesting choices to be made (though, unfortunately, mostly in dialog) and the level design is pretty fantastic. If you play Strife, you'll realize why I feel horribly let down by 90% of FPS games. If you can find a copy of the game, you can either play it in DOSBOX, or use the zdoom engine, which will allow the game to run natively in windows.
2. Star Control 2: Now available in a renamed open source format, there is NO excuse for anyone to not play this game, save lack of time, but even then I'd say you should find the time. Another open world game, Star Control 2 basically gives you a galaxy to explore, and very little direction, at least at the beginning. However, it's very good about chaining elements together, or giving you pointers if you get stuck. The story and dialog are some of the best I've ever encountered in a game. The choices, again mostly though dialog, have actual impact, and you feel repercussions for most things that you do, eventually. Just play Star Control with a pad and paper, because people will tell you coordinates for things, names of stars, and information, which no in game system keeps track of, one of its few failings.
3. Beyond Good and Evil: A platformer RPG with an interesting story, an interesting mechanic involving photography, great action / escape sequences, and amazing music, this game got passed up by the general buying public partially because the title has nothing to do with the game and partially because there was little to no marking for it. Thankfully, an HD version is being released in 2011, and you should pick it up when it comes out. When you play it, pay close attention to the puzzle design, and how the puzzles build on each other from stage to stage, as well as the variety of encounters throughout the game. In addition, note the various music, camera, and speed tricks that are used to provide the game with a really amazing atmosphere.
4. Quest for Glory 4: If you know me, you know I can't talk about games without bringing the conversation around eventually to Quest for Glory 4. This is adventure gaming done right, with light RPG elements that keep the game especially interesting. The 4^th game in the series I feel is especially interesting because it deals with a lot of really dark and mature subject matter, and although it's standard lock and key puzzles (you don't really have too many choices about how to solve puzzles), very frequently in the game you'll find yourself wondering if you actually did what was "right". The story aside, the game also has fantastic puzzle design, and does not contain any of Sierra's traditional "unsolvable" puzzles.
5. Intelligent Qube: This game is almost unknown, and actually extremely rare. It's a real time puzzle game for the PS1 where you're a guy on a big box trying to get rid of other boxes before you get crushed by them. The game is exceedingly hard without practice, but the style of it is amazing, specifically because of the music and sound. It was so insanely epic for what was, essentially, a pretty standard puzzler. If you can find a copy (or emulate a copy) I highly recommend you do.

I've been thinking a lot recently about motivation. Specifically, what was my motivation for wanting to get into the game industry? What was it that drew me towards it despite horror stories of crunch, burnout, and under-appreciation? I decided to get into the game industry despite all of that, but why?

I know for many, the answer is simple: they love games. Others love the community of game developers.

I got into the game industry for a different reason. Sure I loved games. Sure I loved the community of game developers, but I wanted more.

In his recent retirement letter, J Allard talks about his initial decision to work at Microsoft:

During every interview, I'd challenge, "'A computer on every desk and in every home' is quaint, but why stop there?" and the typical response would be along the lines of, "That's just our ante." I liked that... +1 Microsoft.

…

I couldn't believe it, but it was impossible to dismiss the similarity and authenticity I felt in every conversation. On the flight home, I contemplated these discussions, the passion and IQ of the people I had encountered and their invitation to create my own space to drive a bigger agenda alongside them. It clicked. The "computer on every desk..." rhetoric was a ruse, the real purpose and ambition of these people was much, much broader:

"Make the world a better place through technology."

Like every idealistic college hire, this was the unicorn I was looking for. I wanted to do something bigger than me – "change the world!" – with a bunch of people who respected and could augment my superpowers. I had visited the Justice League of Geeks and they had invited me in and had shown me the secret handshake.

When I wanted to join the game industry, I had a similar thought process. I wanted to make the world a better place through games. That bears repeating.

I wanted to make the world a better place through games.

I think my problem now is that I was also very specific on how I wanted to do this. Certainly, there are ways to make the world better through educational games, games for health, or so called "serious games," but this wasn't particularly what I was thinking.

Growing up enjoying adventure games (specifically Sierra adventure games, many of which had more serious tones than other games in the genre) as well as many really good books, I wanted to see games reach a level of literary expression that rivaled our best works of literature. I wanted to see games deal with more mature themes, not in terms of sex and violence, but in terms of how we, as people, interact. I wanted games to take a hard look at subjects like ethics, racism, political freedoms, war, peace, trust, and betrayal among others. I felt games were in a unique place to do this because, if they allowed you to make hard decisions and see the impacts of those decisions, the lessons would necessarily be more poignant. And I believed it was all possible through story, given enough talent and enough thought.

Interestingly, for my first 7 years of GDC, every GDC only made me more convinced that this was possible, and that there were others out there thinking the same things. I would leave every year more invigorated at the possibilities of our medium, and that it was only a matter of time before we started seeing really good literary quality games.

2010 was year 8, and I came out of it a little less hopeful, for a few reasons.

First, I've realized GDC is a self-selecting group of individuals who want to discuss the "hard problems" of making games. These are the types of people that, even if they don't want the same things I do from games, they do want to discuss it. They are excited by the possibilities, even if they don't believe it to be interesting or possible. And with that said, there were fewer people talking about the hard problems this year. It's hard to explain, but GDC this year (for me at least) felt like the industry had exhaled, so to speak. Some of the spark was gone.

Second, I haven't seen games moving toward that direction in a long time. Investigations into actual ethics in games, and real consequential action I think hit its peek with Ultima 4, and with the exception of a few bright spots here and there (Ultima 6, Deus Ex), it hasn't resurfaced. And I feel both the game industry and the gaming culture moving away from such games.

Third, even if I was able to write such a game, I don't think the audience is there for it. Not enough people would buy the game for anyone to justify the effort needed to make it happen. Such a game doesn't work as a small, simple game, or in bite-size chunks. It's an undertaking that seems to provide very little reward. Generally, I think this is true for culture across the board, not just for games. Our media consumption is leaning towards pop-fiction in all forms. Don't-make-me-think media, or (more likely) tell-me-what-to-think media.

Lastly, even if the market were there, I cannot point to a company who shares this ideal. I can point to people (some indie developers, some of the art game crowd, some IF writers), but no groups. There are no Microsoft's. Even Microsoft isn't Microsoft anymore, in the game industry or out of the game industry.

I wanted to make the world a better place through games.

So my question is, given that I've found that my original motivation for entering the industry fading, how do I keep myself motivated? I don't want to leave the industry, but without this initial motivating factor being made manifest….. perhaps there are better ways to make the world a better place? Through technology? Through other ways?

I know this whole blog post sounds ridiculously whiney and / or pompous. And I'd like to be clear that I'm not leaving the industry any time soon, but I still feel my old motivations hanging over me. Maybe I'm getting older, and getting excited over little steps isn't cutting it for me anymore. Now, I'm sure someone can point out games or movements that I'm missing, but from where I'm sitting, I feel like real innovation and evolution, especially in the story department of games, is hard to come by, which is making it hard for me to see a place where I'd be comfortable. Maybe I'm just wearing blinders and ignoring signs that this is taking place? Here's hoping.

Last weekend, I took part in the Global Game Jam, like I did last year and let me say it was just as fun, if not MORE fun this year than last. Our game, Quest for Stick, was really, really awesome this year, and you can learn more about it from the GGJ page and from our Twitter account. We even have a video of a complete play through of the game. The game is super pretty, only a little bit buggy, and generally I think accomplished everything we wanted.

But this year I went in knowing what to expect. How'd I do this year? What did I learn?

What Went Right

1. The Team. Last year, I said one of the things that went right was having a team. This year, that was even more so. We had a total of 7 people working full time on the game, which, initially, I thought was way too many. So much so that I actually asked people to leave the team and considered leaving the team myself to reduce the number of people. But, when it came down to it, I decided I wanted to work on the game idea and went with the other 6 people to create the game. Honestly, 7 people may still have been too many, as communication and tasking did get hard near the end of the project, but there's no way the game would have been anything near what it was if we didn't have at least that many people. Everyone was basically tasked the whole time, and the game came out great because of it.
   
2. Getting Down To Business: We spent very little time talking design this time, which worked out to our advantage. Although we spent a lot of time later arguing about how exactly the game was going to play, it didn't take away from everyone working, which was good. We got down to making something playable quickly, and didn't try to design too much stuff up front.
   
3. Tools choice: Last year, I was super happy with XNA. This year, the team used AngelXNA, even though I was the only one familiar at all with it, and I was the really the only one well versed in XNA. Even though I spent a lot of time helping people understand Angel / XNA, it was still, by far, better than attempting to use only XNA. It performed a lot of the heavy lifting for us in terms of doing animations, placing and managing actors, and, surprisingly, editing levels, though this is its own bullet point.
   

What Went Wrong

1. Unclear tasking: Occasionally, we got duplicated work or weird moments of down time because, like most game jams, people just shouted out things they needed. Kate was really the only person keeping track of most of these tasks, and really only for herself. For the artists, no one was really in charge of knowing what art was still needed and who was doing what. For a team this large, what we needed to create and consult a list on a whiteboard or cork board that had any asset requests, who was potentially doing them, what was in progress and what was up for grabs. This would have avoided duplicated work and would have given us an idea of how much work was left.
2. Late Playable: Despite my work to prevent this (more on this later), we still didn't end up with an actual playable game until mid day on the last day. Just having *SOMETHING* sometime on Saturday to hand to the artists and designers to make levels on would have helped. We did have lots of pieces that worked, essentially, but didn't get them integrated together fast enough.
3. Encapsulation problems: We had three programmers working together on individual parts of the game, which helped not only keep them tasked without stomping on each other, but made it so people were in charge of very small systems. However, some of the systems were weirdly encapsulated, and required copying and pasting over when we actually got to the point of integrating. Though this actually ended up *helping* at the very end, I would have liked fewer instances where I had to copy and paste the code from one class to another in order to integrate a new system into the main game.

What Didn't Work

So, these things really didn't go wrong, but they were things I was hoping would help us during the jam, but didn't.

1. The Simple CI: Before the Jam, I wrote a simple python script that would query a mercurial repository, pull down new code, build it, copy it up to a network location, then message everyone over gchat. This was awesome in theory, but not so much in practice for a few reasons. First, it didn't work so well. If anyone was signed out of gchat when it went to message them, the CI would get stuck in an endless loop. Second, the network drive would occasionally flake out and not be able to take the new build. Third, we didn't have anything the team could play until Sunday, so the CI ended up being useless until then.
   
2. The Angel Editor: The editor in Angel was an awesome idea, but when we got to the Jam, it was buggy and untested. It didn't save out things correctly, crashed, spawned items in weird places, and didn't work at all with our custom actors. In addition, the editor saved all levels out to the build directory, which was great for everyone but the people who were using it. Besides fixing the other editor bugs, in the future, the editor will probably need to detect whether a debugger is attached, and figure out where to put the levels from there, or create a custom levels folder that can be easily moved back and forth and through to an integratable build.
   

All and all, an awesome Jam. Please play Quest for Stick, and let me know what you think. I'm super proud of it.

I've complained about Game Informer before. As "the world's #1 video game magazine" it leaves a lot to be desired. Mostly I think it's just catering to its audience though, so frequently I just give it a pass.

Over the weekend, I read the latest issue of Game Informer and the following letter caught my eye:

I'm writing about your interview with David Cage in issue 198. He stated that video games are unable to generate an emotional experience like those present in movies, and I have to disagree. I feel that video games can offer even more of an experience than movies because of the opportunity to fill the shoes of the lead character.

The letter goes on, but that's the important part. Now, I don't agree with David Cage, but I don't agree with the writer of this letter either. I hear the "fill the shoes" / "you are the main character" argument concerning games and emotion a lot, and before I give my opinion on the subject, I want to ask these questions:

1. When was the last time you actually felt like you were the main character in a game, or, that the main character was you? And…
2. Can you name a time where you had a heightened emotional experience as a result of that feeling that could not have been achieved in any other medium?

I'd like to hear responses on this before I give my own.

I didn't do this last year. I don't know why. I probably wasn't in a reflective mood last year. This year, I've been in a very reflective mood, as you can probably tell from many of my blog posts over the year. I reflected on a lot of things: open standards and web identity, DLC, the possibility of being an indie game developer, and the state of computer science education. Until August, I was even able to post about twice a month, which is pretty good for me.

Besides blogging, what did I do in 2009?

• Me and several other Tools SIG members launched of the Toolsmiths blog, which is going very well, though we have dropped off a bit. Hopefully we'll be able to pick up again in the New Year.
• I participated in the Global Game Jam, which was a blast, and I'm sure will be a blast again this year. I've made plans already to make this a rockin Jam, and get everyone as coordinated as possible right out of the starting gate. We'll see how that goes.
• Darren and I also created AngelXNA, which I've been using and enjoying, and hopefully improving for this year's Global Game Jam. (More on that in another blog post).
• I learned to love distributed version control, a trend that I'm sure will continue.

So what didn't I do in 2009 that I really wanted to get done? The main one is that I didn't finish a game. I've got three currently on my plate, two of which are mostly coded one of which is still in prototype, but nothing finished. This is really frustrating for me for a few reasons. First, the longer I wait to release, the harder it will be to stand out, especially on services like XBLIG. Second, like most people, I entered the game industry to create games, but I've yet to see an actual design of my own make it to a finished, polished state, only ever to a useable prototype. I know this is true for many people, but considering my background I should be able to finish a game. I am going to try very hard to correct this this year.

What do I think is coming in the New Year and new decade? Hopefully you'll see my first game. For more serious predictions, I think you could do worse than listening to Joe Ludwig.

I think that we'll also see more trends towards user created content and personalization, to the point where I think you will actually, eventually, see a game come out on a console that will allow user created mods. The groundwork for this is already being laid out by the Rock Band Network, although it's still a long way from there to a console mod community.

Here's to a new year, new adventures, and hopefully some new games!

My good friend and educator Bill Crosbie is asking some tough questions on Twitter, specifically about what to teach fledgling game programmers to make them the most marketable to game companies when they graduate. Now, you might not be able to tell from the Twitter conversations, but Bill is actually very concerned about giving his students a good, foundations based, computer science education, while also giving them the opportunity to make games, and giving them skills that they can immediately transfer into the workplace, all in less than the two years he happens to have them. And what he's asking are actually really hard questions, and got me thinking: What would I want out of programmers coming out of two year and four year programs, both those that are focused on game development, and those that aren't? What can I tell Bill to do to make sure that I would at least consider hiring his better students?

The Never Ending Conflict

This comes down to a never ending conflict that educators are well aware of: the conflict between giving a student marketable skills, teaching them the tools and technologies that are relevant "right now" that they can put on a resume and will immediately generate hits on job search websites, and giving them an actual solid education in computer science and software engineering. Ask most programmers in the game industry (at least the ones I know) and they will tell you the later is more important, but look at who actually gets hired and the former plays a very obvious role. The problem is that when I'm hiring a programmer, I want someone who's smart and gets things done, but I also don't want to take the time to teach them all of the skills that they're going to use on a daily basis. It's a tough balance, and getting programmers that don't understand things about your core technologies, or at least their underlying principles, can be dangerous.

In addition, technologies go out of date so fast that teaching one specifically can be counterproductive. C++ has been the de facto standard in the game industry almost since inception, as we've needed the control and power that C++ provides, but the technology that we're working with under the hood can dictate exactly how we can use C++. Students taught to think about single threads of execution on x86 processors, using primitives that would be perfectly fine in other industries (like stl vectors and strings) would be screwed in today's game industry, an industry which is (now) all about squeezing as much performance as possible out of multiprocessor, multicore systems on x86, x64, PPC and Cell chipsets. And interestingly, this is exactly what's happened. Students taught to think ONLY in an object oriented paradigm have trouble parallelizing their code and thinking in terms of small executable chunks that don't suffer from things like race conditions and cache misses, if they even know what those are.

But what's academia to do? Most game developers won't even look at a programmer unless they have C++ experience, understand OO concepts, have done at least some work in DirectX, OpenGL, or Win32 programming, and has as a significant portfolio of work. This leaves professors looking to help game industry hopefuls little time to discuss things that are essential to computer scientists, like the benefits and pitfalls of functional languages, strong and weak typing, lazy evaluation, early and late binding, combinatorics, state machines and automata theory, synchronization patterns (semaphores versus critical sections), common concurrency issues and how to avoid them, and even compiler and virtual machine theory. Even if they get through all that theory, how many schools will be able to talk about the inner workings of modern chipsets, cache coherency, synchronization primitives, compiler intrinsics, and virtual memory? If you're a recent college graduate that can actually give me a definition on all of those terms, explain how they're relevant to modern computer software and game programming, and has a fundamental understanding of any modern game API, you're way better than I was when I graduated, and maybe better than I am now because I'm not sure even I could do it. And I can't tell you how much of it is important to know when you graduate, and how much you can learn either on the job, or on your own. Even the IGDA curriculum framework lists so much stuff that it would be almost impossible to push through in a 2 or even 4 year program. You have to pick and choose.

So if I can't figure it out, what's an educator supposed to do? Take a best guess I suppose. Fundamentally, though, I think they need to teach what colleges and universities have said they're teaching for years.

Teaching How To Think, How To Learn, and How To Work With The Tools

Most liberal arts colleges and universities still say they teach their students how to think. They're not necessarily teaching skills, and I like that. That's what I want from my programmers: I want them to know how to think, and, more importantly, how to learn. But there's nothing that says that this must all be done with theory, or that it should be done purely with theory. In my mind, the problem is that Computer Science and Computer Game Programming programs come out of science and math programs, and follow their pattern for how to structure classes: either 3 credit classes with focused homework assignments with little to no cross class application, or 4 credit labs where a single lab is considered enough to create a program that demonstrates theory. This is not only not enough time, but it doesn't encourage long examinations of hard topics, it doesn't encourage learning by failure, and it doesn't encourage learning why it all works the way it does.

How many schools actually look to the art world for inspiration? In most art schools, you have 3 credit studio classes, which last actually 6 to 10 hours per week, have only 2 to 3 projects per semester, and are combined with classes on fundamentals that can help improve project work. I don't think I ever had a class structured this way during my computer science education. The closest I ever got was a Software Engineering class, which wasn't really about software engineering as much as software planning, which is completely different. But, for programmers, these project classes should not necessarily be introducing new technology. At least at the start, students should work from the base competencies of whatever the school was teaching the previous semester, and early project classes should expect failure (though not say this out right), and encourage students to spend several days at the end of projects to examine their work for flaws in their design and flaws in their process, not flaws in the final product. This is where we teach students how to learn, and how to find the problems in their own work: by screwing it up royally.

In addition, I feel that early theory classes should be kept separate from those that are teaching applications of programming, especially those that are focused on programming in specific languages. However, the two classes should be linked together and move in conjunction. Each class on algorithms and data structures should be paired with the class that teaches its specific application to the language they're working in, thereby teaching both programming and theory. This I think is the major failing of most CS programs. They teach programming, usually in a specific language, and expect the students to pick up theory on the way. In the worse cases, the students return later to have classes specifically on theory, which is sometimes a repeat of what they already learned, just presented as theory instead of a feature of the specific language. By making that clear separation of learning theory and learning practice in two separate but joined classes, your students should progress faster in both. It also creates a flow in teaching and a reason to move to languages as you progress. When theory classes are ready to introduce things like how memory works, caches, cache coherency, pointers, and the like, that's when you can move your classes on programming into teaching C++. As you learn concepts in functional languages, you can start teaching ML in programming classes. As they learn the theory, they can see how it was applied in the language they're learning.

Finally, by the end of any given program, students should be spending a majority of time in studio classes, working on projects that utilize everything they've learned with frequent review of architecture and progress from their professor. However, this should be supplemented with theory classes that go beyond what they'll need to use on simple projects, like topics in programming languages, lexer / parsers, and the ability to prove algorithms correct, and include seminars in currently relevant technology and concepts (guest speaker series are great for this).

Doesn't Answer The Question

Interestingly, I'm not sure if this actually answer's Bill's questions, but it gets a lot of thoughts off of my head. I actually had an entire set of semester plans that went with this post, but scrapped it when I realized I have absolutely no experience in that regard. I can tell you what I want, which is basically separate theory and practice classes joined at the hip in early stages, followed by advanced topics in CS and software engineering paired with Studio classes. But, for me to tell you exactly how those classes should be structured doesn't make any sense.

So hopefully, without answering the question, I've been at least a little helpful.