Project Spark’s Soren Hannibal says the industry is at risk of losing out on software engineers if it can’t make learning to code easier.
The journey of a thousand miles begins with a single step, and Microsoft’s Soren Hannibal is trying to make that very first stride a little less intimidating. The technical director of Team Dakota is working on Project Spark, a game creation tool that spans the Microsoft platform family and uses an approachable, visual programming “language” designed to get people creating and sharing new games without ever having to touch a line of code. Speaking with GamesIndustry International in advance of his GDC Next talk this Wednesday, Hannibal acknowledged that while many of the barriers to would-be game developers have come down in recent years, the very first barrier can still appear awfully high.
“Starting to program these days, there are so many more options, but also so much more information you need before you can start,” Hannibal said. “When I started programming on the Commodore 64, it came with a book, and that was how you could learn to program. These days you have to find the right packages, download and figure out how compilers work. There are so many different things you need now to even write your first line of code. This way you find out if it’s something you’re interested in without having to spend months learning things by yourself.”
Having an easy introduction to programming concepts and logic at an early age could accomplish a lot more than just adding a few extra game developers to the industry in the years to come.
“Starting to create video games is the perfect introduction into software engineering, right? It gives you instant feedback. You’re still learning a lot of the same concepts…”
“I feel like if we don’t do that, we’re going to lose a whole generation of people that would get into software engineering as a whole,” Hannibal said. “Starting to create video games is the perfect introduction into software engineering, right? It gives you instant feedback. You’re still learning a lot of the same concepts and the same way of thinking that you would when you get further. It’s going to not be as alienating to people.”
The idea of a game that lets players make other games is nothing new. Hannibal said one of his biggest inspirations for Project Spark was Sensible Software’s Shoot-‘Em-Up Construction Kit for Commodore 64. More recently, there have been some high-profile efforts like Little Big Planet, Trials Evolution, and Battleblock Theater.
“I think one key factor is that [those] all are titles that deliver a game first and editing tools second,” Hannibal said. “They all ship with a lot of pre-made levels within the genre they focus on, and they prioritize playing before creating, and as a consequence, a very low percentage of users really create. I think we are different because for us, creation is the core of our experience. We try to make creating fun and not intimidating, and we make it possible to engage yourself at the depth you desire, so it’s not a ‘one-size-fits-all’ design.”
When Hannibal says Project Spark is a set of editing tools first and a game second, it can be taken quite literally. The project has its roots in the Kodu Game Lab, a Microsoft game creation tool released on Xbox Live Indie Games in 2009. The $5 program let players create simple 3D games where they could use simple “if-then” statements to wire up AI behaviors with the help of cute pictures. But Hannibal said where Kodu was a small project bootstrapped by a handful of people, Project Spark is taking the idea and putting a proper team and the full weight of Microsoft behind it.
One of the benefits of that institutional support is that it comes with institutional learnings from previous efforts, like Kodu, Trials, or Battleblock Theater. And those learnings will be particularly helpful when it comes to dealing with the headaches (and crude behaviors) that seem inherent to user-generated content.
“The good news is that from those experiences, we know that for each griefer out there, there are a lot of users that care about the community,” Hannibal said. “Of course, the more flexible your tools are, the more ways there are to make something inappropriate. Therefore, while the percentage of offensive content is probably not that high, we expect a wide variety in the ways people try to be offensive.”
“Without having a great game, you’re never going to have something that is going to be monetized anyway.”
To address the issue, the developers will have two distinctions for games: Curated or non-curated. A small internal team will mark projects as curated to denote the most popular or interesting levels that don’t contain anything inappropriate. Additionally, if enough users flag a project as inappropriate, it will be hidden until the moderation team can review it and weigh in with a final verdict.
That community aspect won’t just be limited to keeping everyone else in line. Hannibal said the team is also doing what it can to encourage collaboration.
“We do a lot rewarding you for creating, and recognizing when you’re specializing in something, whether it’s becoming an artist, or a level designer, or a programmer,” Hannibal said. “We focus a lot on rewarding you for working with other people and if other people use your work.”
One thing that isn’t clear about Project Spark yet is its business model. Hannibal declined to discuss it, saying simply that the details had not been worked out yet, and that the team is focused more on making a great experience first.
“Without having a great game, you’re never going to have something that is going to be monetized anyway,” Hannibal explained.
The business model isn’t the only uncertainty surrounding Project Spark. After all, a creation tool that doesn’t offer its designers any surprises probably wouldn’t be that creative to start with. As an example of the sort of surprises the developers have already seen, one user testing the game made a mock-up of the solar system with planets moving around the sun. Another user then took that idea and expanded on it by simulating the gravitational pull on objects floating through the solar system.
That sort of functionality was never intended, but Hannibal said such surprises have become the norm so far. Sometimes the testers actually seem to have a leg up on the developers, because they’re engaging with the toolset with fewer notions about how things are supposed to work, or what options were designed with which functions in mind.
“Some of the things that have been the most fascinating to me have been watching how people have been inspired by each other, and how they’ve worked around limitations we had in the engine and just surprised us,” Hannibal said.
While it’s great to see the game accomplishing its goal of fostering creativity like that, having so many people using its functions in ways the developers never intended could make the process of updating Project Spark a very difficult endeavor. After all, if they botch a patch, they aren’t just breaking their own game; they could be breaking everyone else’s as well.
“It is scary,” Hannibal admitted. “It is very scary to deal with compatibility. It’s kind of the equivalent of writing Visual Studio, but making sure that if you make a new language, that everything else will work with it. It’s ridiculously scary to deal with.”
Of course, it’s perfectly normal to fear the unknown, and for better or worse, Project Spark’s future fits squarely in that category.
“We don’t know necessarily what it’s going to look like in the future,” Hannibal said. “We can’t wait to go out and see what the world will be inspired to do. When we see their ideas, we will take them and expand on our tools to further what we can do. We focus on adding features to give you as many options as possible and trying to remove every boundary we can.”