Author Archives: David Mullich
Hacking The Classroom
Last Saturday I attended an event called Hack The Classroom at Loyola Marymount University. Aimed at K-12 teachers working at the Archdiocese of Los Angeles, the six-hour program consisted of talks on the future of technology in education and hands-on workshops on how to hack your classroom with the top iPad Apps, Google Docs, and other technology. My wife, a Catholic high school teacher, had invited me to go with her, and since I was about to head up development of a educational software project myself, I was interested to attend.
Not having been inside a school in over thirty years — aside from visiting my wife’s classroom, attending my children’s open houses and delivering an occasional talk to students about game development — I really didn’t know much about changes in teaching approaches that had taken place since I was a kid. I was immediately blown away by the keynote presentation about technology as core curriculum, which related the evolution of educational thinking, from traditional (Web 1.0) to current (Web 3.0).

Whereas education in my youth was closed and industrial, the current view is that education should be open and ubiquitous.
Most surprising to me was the concept of “flipping the classroom”: the idea that teachers should present their lectures at the student’s home (via online presentation software), and that “homework” should be done in the classroom so that students having problems can be assisted by teachers or more advanced students acting as tutors. This is a form of blended learning which encompasses any use of technology to leverage the learning in a classroom, so a teacher can spend more time interacting with students instead of lecturing.
As excited as I was about these new approaches, I was somewhat dismayed that there was a need for workshops to show teachers how to use such simple resources as Google Drive, Twitter and even Wikipedia. However, I’ll give the teachers credit for recognizing that there was a need for them to step up and learn about the technology that their own students use everyday.
There are plans for future Hack The Classroom events organized for other educator groups. You can learn more here.
Why Do Game Developers Crunch?
Crunch time. It’s the bane of game development. In order to meet a launch deadline, I’ve often had to work 60, 80, even 100 hours a week on a game I was developing. I remember visiting a developer’s office at midnight while I was producing a Who Framed Roger Rabbit game for Disney, when suddenly the lead programmer pulled a pillow out of his desk drawer and then dived under the desk to catch a couple hours of sleep before resuming his debugging work.
No matter where I’ve worked, no matter what the circumstances, the project eventually involves crunch time for the development team. Those of us who work in the game industry take it for granted, but those who work outside of the industry (especially my wife) often ask me, “why does crunch time need to happen?”
Actually,there are lots of factors contributing to crunch time:
- Many games are dependent upon creative and/or technical innovation, which is difficult to predict and schedule.
- Game design is an iterative process. The only way to tell if your game is fun is to observe playtesters playtest it, and if they have problems understanding or enjoying your game, you have to go back, find a solution to the problem, fix it, and then playtest it again. So, it is difficult to predict how many iterations it will take before a game is good enough to fix.
- Game development is a very complicated endeavor, often involving hundreds of thousands of lines of code and art assets, or even more. There are millions of things that can go wrong, and people make mistakes, especially when they are under pressure or tired.
- Game publishing is very competitive, and so publishers put pressure on developers to make games faster, cheaper and better. Often those expectations are unrealistic, requiring developers to work overtime to meet a deadline.
- Some game development teams, especially in the early days of the game industry, are staffed by very young and passionate people who put all of their energies in making a game, even at the expense of their personal lives during the length of the project. This lead to the stereotype of the game developer with no life. I once had a boss at a large publishing company me, “You’re not a real game developer unless you are work 60 hours a week” even when you’re not struggling to meet a deadline. Today, there are companies who work with a Crunch Time Culture, although the game industry has realized that employee burn-out is a problem and are try to find ways to avoid it.
Thankfully, I think things are getting better. While crunch time still happens far too often, more and more managers in the game industry are realizing that working such longer hours is unhealthy and that crunch time can cause more problems than it fixes. Now we just need to find some other way to get 20 hours of productivity out of an 8-hour work day.


