Last week, UWE held a ModJam. Five days, three teams, three games: All using the Spark Engine. You can read daily updates from the jam here – Monday, Tuesday, Wednesday, Thursday, Friday. Today, we sat down to think about what went wrong, what went right, and what is going to happen to each of these mods.
First up, what’s happening with the mods! You will be able to play them very soon. At the start of the modjam, we decided to use an internal build of NS2 that is not yet public. That build is currently being playtested and prepared for release. It is scheduled for release on Thursday, though such is the process of releasing builds that we cannot be sure. Once it is released we will put all three mods up on the Steam workshop, and you will be able to play them to your hearts content!
Of course, they are not quite finished. So far from finished in fact that the real fun that will come from their release will be what you choose to do with them. Along with the Steam Workshop release, we are going to release the mod source code. Hopefully, some clever community modders will take on the challenge of turning a mod like Last Stand into a game that really shines.
During the jam, many of us in the San Francisco office spent lots of time working closely with those offsite. This was a wonderful experience, as distance can sometimes be a barrier to collaboration. By using tools like Teamspeak and even Twitch.tv, offsite programmers, artists, mappers, and designers could fully participate in the jam.
Small game developers like UWE typically encourage people to be ‘T-shaped,’ which is a fun way of saying: ‘Be very good at one thing, but understand and be effective at lots of things.’ This philosophy is amplified during a jam, when people have the opportunity (and are encouraged by their peers) to dabble in areas of development they do not normally participate in. For example, programmers creating levels, designers creating game code, or artists designing games.
A verbose and corporate way of describing this situation would be ‘multidisciplinary cross-pollination.’ When people better understand what their team-mates are doing, they can work together better. Programmers that understand the workflow of artists can build better tools, and artists that understand the limits of code can create better art. The process also breaks down the traditional programmer / artist / designer / other divides, that can appear outmoded and inefficient at a small, nimble studio like UWE.
Spending a week using our own mod-tools has alerted us to some of their weaknesses. They work well, and work fast. But there are areas where they can cause frustration to modders. Now that we are aware of the problems in the mod-pipeline, we can make changes to the Spark Source Development Kit (SDK) to make creativity easier. Everyone had a blast during the ModJam and we will no doubt have more of them, each time learning new lessons and become better at making games.