DADIU stands for Danmarks Akademi for Digital Interaktiv Underholding, which is Danish for Denmark’s Academy for Digital, Interactive Entertainment. It’s not a university, but rather a fairly unique collaborative organisation that every year arranges game development projects for students from a series of Danish university-level educations. Whereas most educational game projects give groups of 4-6 students a whole semester or more to create a game, DADIU takes the opposite approach: teams of 12-15 students get one month to make a game. Under the old DADIU system, which I have the fortune to be among the last participants of, the programme consists of two projects, a practice run in May of the first year and a graduation project in March the year after. I’ve been told the new system will only have one project, during the fall.
Still with me? All right. I’m gonna go on a bit more about DADIU; if you’d rather know what the hell is up with the post title, skip to the sentence marked in bold below the next picture.
I had my first DADIU project, the practice run, this May. It was an incredible experience that I enjoyed immensely. DADIU is brilliant for pretty accurately recreating the structure and the dynamics of a real game development project – each team is composed of students from completely different educations, working with pre-assigned roles in a strictly defined (but optionally enforced) hierarchy, in the same room for 8 hours a day. The management team is the project manager, the game director, and the game designer (that would be me). An art director and a lead programmer further make up the leads. The rest of the team consists of a number of programmers, CG artists, animators, one or more graphic designers, and a sound designer. The practice run is executed under strict constraints (this year we had to design a game for 3-7-year-olds, playable with just the mouse and the left mouse button, featuring 3D and AI with critical importance to the gameplay, and playable in a browser) and all teams must use the Unity engine.
As a game designer on this project, I had so much fun. I like to think I have the qualities to make a good lead designer, because I won’t hesitate to decisions on the spot when necessary but I also respect everyone’s competences and creative input and I understand how to delegate tasks and share creative power rather than trying to do everything myself. On DADIU teams, the major conflict zone tends to be between the director and the designer, because their areas of responsibilities are a little poorly defined. Further, the game director is a person from the animation line on the Danish Film School, who will often have no prior experience with game development and no knowledge of the medium as such, yet has been given veto and creative oversight by the organisation. Fortunately I got a director who was fully aware of these issues and we were both determined to collaborate, give each other space, and work together.
I will say, however, that if we’d had a level designer on this project, I would have been bored far more often than I want to be. I feel that it’s important as a designer in a lead position to set an example for the team by working hard, and personally I enjoy getting my hands dirty if there’s time – since we had no level designer, I did all the level design and construction myself, which was the only reason my position wasn’t purely managerial.
At the end of the project, I had to hand in a personal report to our DADIU contact person at the ITU. It explains every facet of the project in more detail, focussing on my responsibilities and how I handled them. If you think you might find that interesting, you can download it here 
, it’s 8 pages and weighs a mere 589 KB.
The game we made in May is called Imachination. It’s a game for 7-year-olds about digging through Earth from Denmark to China with a huge construction vehicle stocked with weaponised tools and building equipment. At its most basic level, Imachination is an arcade shooter in the vein of Robotron 2084, but it has one very significant fundamental twist: your weapons fire automatically at a predefined rhythm, all you have to do is move and aim.
As you will see if you choose to read the report, it’s not a decision I’m particularly happy with in hindsight. Personally I enjoy playing the game and I think it works great, and so does most of the team. The problem is only about half the people who’ve played the game agree. Far too many players think it’s unsatisfying not to have to click to shoot – clicking gives the player a very direct connection to what’s going on in the game, and many players simply don’t find our gameplay involving enough without it.
If you’ve played Invisible War, the sequel to Deus Ex, you’ll be familiar with the concept of universal ammunition: instead of each weapon using an individual ammunition type that is spent and replenished independently from the ammunition for other weapons, every weapon shares a single pool of generic ammunition. This has the advantage of making game balance somewhat simpler for the designers, but the fairly significant disadvantage of making side-arms pointless (if you’re out of ammo for your primary weapon, you’re also out of ammo for all your other weapons) and making heavy weapons too expensive (the flame thrower for example will eat up all your ammo very fast, and then you’re stuck with melee weapons). It’s an original design decision that looked perfectly innovative on paper, but in practice it doesn’t really work – at least not the way it was implemented in Invisible War (Mass Effect 2 makes the whole thing work simply by divorcing the ammo expenditure of its weapons from each other, while picking up one clip will still add its ammunition to every weapon the player has).
Though it’s obviously not quite the same, I can’t help but think of the auto-firing weapons in Imachination as my own universal ammunition. There were signs of controversy already during development (I once read that Warren Spector himself was worried about universal ammo; likewise, one of our industry consultants repeatedly spoke out against it during our meetings), but the idea stayed, I guess primarily because it was sold convincingly to the rest of the team – everybody understood the reasons why it was a good idea, so the reasons why it might be a bad idea weren’t given sufficient weight. Finally, it’s a streamlining of the core gameplay that makes the designer’s job somewhat easier (in the case of Imachination, it was the least complicated way of handling our one-button constraint) but takes something away from the gameplay that most players enjoy.
In the end, the problem isn’t that only half the players think the game is fun without clicking to attack, the problem is that all players would have thought the game was fun if the clicking had been there – I introduced a problem without really fixing another one.
I’d like to think I’ve learned from this. Learned to be more careful about what to innovate in the future perhaps, and to test the game even more with people outside the team, even if there’s not really time to run those tests. If nothing else, I’ve learned that when there is shooting, the player wants to be the one doing it.
If you have twenty minutes to spare, please do give Imachination a try and let me know what you think. It runs in your browser if you have the Unity web player, it only has 3 levels, and all you need to know is that your health regenerates if you avoid taking damage for a while, everything else of importance is explained in the brief tutorials at the start. Drop me a comment to let me know what you think if you play it 
It is fun to play even for we not quite seven years old…. ahem.
Even without having to click to fire, turning the vehicle to hit the baddies with your chosen mode of attack still gave me a child-like sense of fun. It looks (visually) lovely to boot.
Played it and liked it; it reminded me of Stratosphere: Conquest of the skies, as I’ve been keen to mention to you. I looked the old boy up after playing Imachination, and had great fun with it, so i highly recommend doing the that to anyone wanting more of the same. Simply for exploring this type of gameplay again, and reminding me of stratosphere, I’m grateful =]
Considering the limitations, you surely made the right choice in adding customization of the vehicle.. it’s a simple mechanic that a 7-yearold can relate to, but it adds depth and ownership. It’s probably the best use of the left-mouse-button-only interface around; think of the sims, for example, and how it has immense depth with basically nothing but this interface.
In terms of concepts, I think perhaps you’re lacking powerups – another mechanic that gives the player a sense of personal entitlement because he has earned a reward. It’s a key component of shmups and other arcady type games, particularly those considered kids games, so yea, pretty straight forward addition. Double speed or super-powered-weapons for instance. But that’s all that comes to mind for outright additions.
But you’re right that the biggest problem is that the player does not directly interact with the game to fire the weapons. As a result, it’s much harder to hit stuff, to the point that it feels like luck rather than skill (I tried really hard to shovel the little creatures in the first level, but I couldn’t make it without them damaging me!).
It takes away ownership of the individual kills with, for example, the big shovels. And you’re right…It may be that it isn’t perceived as a problem by half the players but then, players don’t know whats good for them much of the time, so it easily remains a problem regardless of that.
You’re not the only one to have made this mistake though…the first dungeon siege is much less fun than diablo was, for example, precisely because it automates too much. To the designers at gas powered games (probably chris taylor in particular), it must’ve seemed that the incessent imprecise turbo-clicking most diablo players do when playing the game was a problem to be solved…turns out, the alternative that gpg thought up robbed the players of their feeling of skill and accomplishment.
Is it comparable to universal ammo? Sure, in that it’s probably come about in a somewhat similar manner, from what you describe. The real lesson to be learned, then, is how to avoid making a mistake in this manner. Now how the heck you’d do _that_, I’d like to know. Particularly given the time constraints of the project…not enough time for real iterative development in self analysis, and your entire team thinks it’ll work…given those conditions, how are you supposed to catch it?
Should I propose a fix in your specific instance, well, I would have the digger always drive towards the mouse curser, and have it “dig its feet in” when you click it…like a siege tank from star craft. You even have this functionality, you just use it for something else. It still overloads the left mouse button with more functionality than I’d like, but from a UI standpoint, that _is_ what has to happen.
Problem is, I don’t think I would have protested in any vocal way had I been on the team, so the fact that you can come up with something that seems like a workable solution doesn’t mean you’ll be able to tell that there’s a problem in the first place.
Your suggestion – to be extra careful about where you innovate – is perhaps the best bet. If you’d played a similar game, and were able to test out your innovation in as similar setting as possible, directly comparing two solutions to the same problem (one traditional and one innovative) – perhaps you’d be able to tell what’s better…because I’m not sure just “being extra careful” would have saved IO from universal ammo, do you?
Ah, anyway, I ramble on too much. Hope you find some of it useful.
I never expected to read the term “for shits and giggles” in a university paper, excellent work!
Unfortunately, I still have to find a suitable computer to play imachination on. I am on windows now, but the internet connection is excruciatingly slow down here
Yeah that’s why I like production reports much better than “real” papers, you don’t have to be formal