Although no official release date has been announced, it won’t be long before the first ‘freemium’ game will reach the Xbox 360. The title in question is Dungeon Fighter Online, made by Nexon. They are also responsible for the possibly better known Maple Story.

Cripple

Freemium games have been thriving in your browser, among other places, for a couple of years now. In short, it means offering the game for free or a very low price, while the developer earns money by selling additional in-game content. Only a small percentage of a whole lot of players needs to by something frequently, to generate income capable of sustaining the game while hopefully also creating some profit for the developer.

The term freemium has gotten a negative reputation, because the quality of the actual products is often not very high. Also, sometimes the gameplay is ‘cripple’, like Minecraft’s Markus Persson describes it. You are almost forced to buy the additional content, in order to be able to still get something out of the game.

So the arrival of freemium on a platform like Xbox LIVE Arcade doesn’t seem like something to look forward to. But there are two reasons to be enthusiastic about this news. First of all, these titles will also have to pass Microsoft’s quality control. If your game is not good enough, you will not release on Xbox 360. So some quality is guaranteed and the problems described above will be less apparent. In other words, free games that can be expanded the way you want! The second reason is that this is the start of something much bigger.

Potential

This is the first sign that the platform is opening up, to go along with a changing market and to concede to the wishes of developers. Because they want to use new and alternative business models, which have proven themselves elsewhere. Freemium, micro transactions, social features, persistence, metrics and ‘connected gaming’ are all properties of a new generation of games.

A few tools are already available in a basic form on the current consoles, they’re just not very ‘connected’ yet. Sending messages to friends is possible, but they can’t be sent from within the game with relevant information. Your list of friends and what they’re doing can be useful, but you rarely see something more than a friend filter on a leaderboard. There is an elaborate online shopping system, but offering a game for free and buying content from within the application hasn’t been possible until now.

If you are familiar with FarmVille, or played recent iOS or Android games, all this doesn’t sound very new. Hopefully you will also have experienced what the potential of these types of features is, if they are added to fun games in a supporting manner. More openness of the platform, more control over content and more information on players will give developers a better grip on their revenue, but will certainly also provide opportunities for game design. That’s the side that interests me most and where a huge challenge lies ahead for designers of traditional console games.

So, before you continue, please take a look in my portfolio to see how DigIt works exactly. It’s been a while since we completed DigIt, but I thought the design notes I made then (while playing the game on my Nokia 7610) would make for an interesting article about hands-on game design. We’ll start off with the one change to the game mechanics and then review the interface to better support gameplay.

Simpler level meter, simpler game

The old level meter, including the minimum indicator

The change in the game design is actually pretty simple. It’s more of a removal than it is a change, really. Before we get to what’s going to happen, let’s take a look at the current situation. DigIt uses a level meter, which shows your progress in the current level. Fill it up and you proceed to the next level. Currently the level meter includes a minimum indicator. This is where the level meter starts after leveling up and it allows the player to make some errors, because the game is over if your level meter is empty. This meter is depleted by pressing the wrong number or pressing at an incorrect time. After watching other people play and playing the game extensively myself, I figured out that this minimum indicator on the level meter was completely absolete. The game already contained another way you could lose: running out of allowed errors. This was something people understood, while the use of the small line on the level meter was kind of unclear, as was the meter going down.

Losing based on level progress or on overall game performance didn’t need to be both present and getting rid of this little interface item would make the game as a whole even more simple and easy to understand. This conclusion would improve the game in multiple ways. First, the line on the level meter would be gone, not raising any questions on what it is and does. Second, the level meter doesn’t have to be able to go down, it only has to go up. Third, the only thing you have to watch out for is the number of errors you can still make. Of course, in theory this would make the game a little easier. It is possible for the player to have more allowed general errors than the previous level meter would allow before failing. But at the moment this would become an issue, it is still unlikely that the player would make so many errors in a row that the level meter would run out before the number of allowed errors. I mean, the meter also increases on correct button presses, while the allowed errors only increase on going to the next level. The level in which players start running into trouble should be about the same.

DigIt already is a pretty simple game, but changing the level meter and connected mechanics in the ways proposed will hopefully make it even more understandable and fun to play. Looking at how often the first version of the game was played, it’s amazing this is the only thing I ran into. It just goes to show that even a small game like this can benefit from playtesting and you’re not likely to get everything right the first time.

Interface iterations

As DigIt ran on my old Flash Lite 2.0 enabled Nokia 7610, I was able to play the game extensively myself and show it to anybody that would like to play it. This resulted in the proposed design change above, but it also made me more aware of how the game actually played on a mobile phone. I wasn’t really a mobile gamer, other than playing on my DS and PSP, and during development on PC you look at the game very differently. We did build small prototypes back then, testing whether new implementations would actually work on the intended platform. But these were more technical tests than usability tests, something that we could do with the version that we had at the end of the project. And even though DigIt plays really well, even on a phone with the weirdest number pad ever, there is still room for improvement. Before I discuss the thought and design process in reinventing the visual interface, I’ll first name every interface element so you’ll know what I’m talking about when addressing them individually. Below is a DigIt screenshot with numbered interface explanations.

Original DigIt interface

1. Scoring area: Three hit areas where you can stop the ball to score points. One center, two sides.
2. Number indicator: Displays the current number key you have to press to stop the ball.
3. Level: The number of the current level you’re in.
4. Ball: The ball you have to stop inside the scoring area by pressing the number displayed.
5. Path: Shows the path of how the ball will move on screen.
6. Level meter: Displays your progress within the current level.
7. Combo: The number of consecutive correct button presses, acting as a score multiplier.
8. Errors: The amount of errors you are still allowed to make before you go game over.
9. Score: The points you collected up until now.

As you can see, the level meter still contains the red line as the minimum indicator. When looking at this interface and playing the game this way, there were two conclusions I made to what was wrong with it:

• There should be a stronger visual indication of the level progress. When you’re paying attention to the number and scoring area, it’s hard to see how far you actually are from leveling up.
• The same goes for the error and combo numbers. These should be closer to the scoring area, because it is information the player requires all the time.

Result of iteration 1

This resulted in the first schematic redesign. The error and combo numbers have been moved up, so you can view them more easily when watching the scoring area. The level meter lost its minimum indicator and grows larger towards the right, with the blocks there changing color more noticably. The score has been repositioned to take better advantage of the screen space left open by the new level meter. As you can see, the position of a lot of interface items has remained the same. When looking at this ‘improved’ interface, I again noticed two things that might be interesting to look at:

• The level number is pretty far away from the level progress. It is possibly better to connect these two things visually, because they are functionally connected as well.
• The score is placed all the way at the bottom of the screen, it can’t possibly be farther away from the attention center at the top of the screen. Your score might be interesting to see, especially when you’re getting close to the highest score.

Result of iteration 2

Take a look at the next schematic redesign. Nothing much has changed really. The score is now positioned below the number to press and the level number that was once there is now placed at the score’s old location. Not much of an improvement, is it? Logically it might be, but it still didn’t feel right. This time, there were three things that came to mind:

• The area where the action is going on (scoring area, combo, errors) is separated from the area where the progress can be seen (level meter, level number, score).
• More importantly, when looking at the physical characteristics of a mobile phone, the action area is very separated from the number buttons on the hardware. This means you have to look far away from the action area when trying to visually locate the button you should press.
• Repositioning the score number is actually more confusing for gameplay. It is updated at the same time as the number you should press and at the very start of the game, your score is so low that it could be the same as a possible number to press.

Result of iteration 3

This resulted in the final schematic interface redesign for DigIt. The upper part of the screen is now not used at all, only for the ball to pass through. The most important change is that the scoring area has been moved to the lower part of the screen, the error and combo numers went along with it. The level progress, level number and score now have a more neat position at the bottom of the screen. This way, all relevant information is grouped together and very close to the part of the hardware used to play the game. The level meter’s shape has changed a bit, to allow a calmer composition. Showing the player is nearing the end of a level can also be done with other visual methods.

A big change

The version of DigIt now available in my portfolio is still the old version, as I moved on to other projects and a full time job in game development since then. Quite some time has passed since I made DigIt and much has changed in the world of mobile phones and their games. To make it work now, it would probably need another, bigger redesign. I already had some brainstorms with my former DigIt colleague about this, but we’re both too busy with the games at our jobs to actually work on it. Writing this article got me motivated, though…

Real 3D gameplay is what editor in chief Niels ‘t Hooft was asking for after Nintendo’s presentation of the 3DS. It was the same angle in which I was looking at the presentation of this new handheld and the first batch of games. It’s a topic that has been keeping me busy for quite some time now. Not only regarding the Nintendo 3DS, but with regard to using 3D in games in general.

Interactive

Up until now, 3D is mostly presented as an additional way of showing images, like what happens with movies. But to get to 3D gameplay, the technology will have to tie into the interactive nature of games. Designers need to view 3D not as a development like High Definition, but along the same lines as touch input, voice input and dual screens (to stay with Nintendo handhelds). I admit, my examples are mostly about methods of input. 3D is not, but for me it’s about the fact that they can influence interaction and create new possibilities for designers to do something with.

Now, I haven’t touched a 3DS yet and have only played on a PS3 with 3D glasses on for a very short amount of time, so as a designer I am not yet capable of throwing well-founded ideas out there. But still, I’m pretty confident that ‘real’ 3D gameplay is possible. In the comments on Niels’s report, a few interesting possibilities already came to light. It might take a while before developers will discover more briliant applications and be able to implement them successfully. That greatly depends on hardware and how the illusion of 3D is brought to life. 3DS games have a 3D screen available by default and can combine this with other device functionality. Zelda games have usually been very good at offering ingenious puzzles, since the DS also at connecting them to the possibilities of the hardware. If innovation doesn’t come from there, then maybe it will spring from the creative minds of Level-5 (Professor Layton) or Cing (Another Code, Hotel Dusk).

Point of view

My opinion is that, at this time, we do not have a complete picture of what is going to be possible with 3D. Not only regarding the visual effect, but also regarding the techniques behind it. Sony applied for a patent last year, on using 3D technology to replace split screen multiplayer. So both users will use the entire screen, but they’ll see different things. It has little to do with 3D gameplay, but it’s another approach that could lead to new ideas and there are probably more ways to look at it. But there’s a danger to using 3D in gameplay as well, if the player is not prepared for it. I remember a puzzle from Another Code for the DS, in which the reflection of the upper screen in the bottom screen showed the solution. Briliant use of new functionality, in a game that suits it well, but no player will solve a puzzle like that without a walkthrough.

I hope we will get to a point where 3D gameplay gets its own conventions, that designers and players know how to deal with it and that it transcends the gimmick stage. The 3DS having its own 3D screen is a nice start, although Nintendo doesn’t seem to demand 3D to release on the platform. My pre-order has been made, but without a game, though.

A trailer for the game can be found here. Maybe it’s a little too chaotic to notice what’s actually going on, but I can assure you it’s very easy to pick up this incredibly fun and competitive game. The project’s main supervisor was Vanguard’s producer René Derks, who recently let the JARRR students pass their final exam with flying colors.

Gameplay

In a nutshell, General Conflict is a free for all last man standing game for up to four players, involving bombs and collapsing terrain. Players move around the battlefield to collect bombs, which they can then throw forward or drop behind them. Exploding bombs destroy a layer of the tile they’re on and blast players away from them. You fall into the water, you lose a life. Whoever can survive the longest in this constantly changing fragile landscape will be the winner. Players are able to climb back onto a tile from the edge by rapidly pressing a button, but this becomes harder after taking more hits from bombs. You do have a couple of lives and the ability to spawn where you want, and there’s also a team battle mode and multiple levels.

Hands-on

As part of the supervising team from Vanguard, I’ve seen the game develop from concept to what it is now. I’ve been impressed by the progress made in each iteration and some tough design decisions that were made. Getting a game to a stage as polished as this, especially in a school project, is quite the accomplishment. We’ve been playing it regularly at Vanguard and you really should give it a try if you ever manage to get your hands on it. Get a chance to do so at tomorrow’s Utrecht School of the Arts project market.

Disclaimer: Although very much inspired by Greed Corp and Mistbound, General Conflict holds no relationship to Vanguard’s current or future projects. The project was issued to the Utrecht School of the Arts by Vanguard in an ongoing relationship with Dutch game development related education.

Most of the games in my portfolio have a demo or complete playable version available, but video provides a quick way to get an impression of the game without having to play it. Opposed to screenshots, video actually shows the game in action.

So in the last couple of weeks, I’ve been making and collecting videos for all but one project in my portfolio. You can find them on their specific project pages, but here’s a list of all the videos as hosted on YouTube:

• Greed Corp official gameplay trailer
• Crusade in Jeans gameplay footage
• DigIt gameplay explanation
• Red Bull Knockout gameplay footage
• Red Bull BC One tech demo gameplay footage

As you can see, a trailer for Gatling Gears is missing. That’s because it doesn’t exist yet. But stay tuned, it won’t be long before the list will be complete…

Receiving an award for Greed Corp out of the hands of legendary Katamari Damacy designer Keita Takahashi (now officially named Katamari-san, thanks to my colleague René) was just one of the highlights. In the above picture, from left to right: fellow game designer Harry van Mierloo, creative director Marcel du Long, producer René Derks, the legendary Katamari-san, and me.

W!Games and Karami merge into Vanguard Games

W!Games changes its name once again (it used to be Woedend! Games), but with good reason. The studio is merging with Karami, a small studio founded by Martin de Ronde and Michiel Mol, of Guerrilla fame. Gamasutra picked up the press release that went out about this, but they also did an interview with Martin on the strategic and practical reasons behind this merger. It also describes a bit more what Karami was and what Vanguard is actually going to do.

Arthur Houtman as CEO of Vanguard

Arthur is such an industry heavyweight, him being Vanguard’s CEO deserved a press release on its own. In the short time he’s been with us, he has already shared some entertaining and insightful stories. I’m sure his years of experience at Disney Online and Atari will have a positive impact on the studio and its products.

EA announces Gatling Gears

The project I’ve been working on after Greed Corp, Gunstorm, got an official new name and will be published in a partnership with Electronic Arts. That new name is Gatling Gears, but I still catch myself calling it Gunstorm every now and then. You’d think we get our inspiration for game names from Epic, right? Anyway, I must say I’m very proud a big publisher like EA has so much confidence in our next game and will help to make it an even bigger success. Check out the official press release here.

Dutch Game Awards and PC release for Greed Corp

Yesterday and the day before, it was once again time for the annual Game in the City event in Amersfoort, The Netherlands. In the evening of the first day, the Control Industry Dinner also took place there, including the ceremony for the Dutch Game Awards. Greed Corp was nominated in four categories and we won two of them! By earning the Best PC/Console Game Award and Control Industry Award, Greed Corp is officially the best game released in 2010 by a Dutch developer, according to the professional jury and all Control readers that voted. The actual awards themselves, one red owl and one black, turned out to be very fragile and it seems we were not the only ones having trouble keeping them in one piece.

Winning these awards is a great addition to the other Greed Corp related news we announced last week. It’s finally coming out on PC! The boxed version will appear in Germany on December 3, with more details incoming.

Seems like Greed Corp made quite an impact. Lets hope we will be able to continue to do so with Gatling Gears and all of Vanguard’s future projects. I think we’re off to a good start.

Now, Adriaan is still attending the same school as I went to, the Utrecht School of the Arts, which is why I was pleasantly surprised by his in depth observations on game development. And this is not just making obvious remarks, it really shows that Adriaan experienced these pitfalls first hand and that he has learned from them. Given that he has come to these conclusions so early in his career, and based on my collaboration with him at W!Games, I’m sure that Adriaan will come a long way in the industry.

On to the list then. Before I discuss all points separately, here’s an overview in the order Adriaan used:

• Entering production without something fun
• Start big, end up small
• Peer reviews not taken seriously
• Starting too late with playtesting
• Not enough games played
• Too much importance on design documentation
• Not taking advantage of placeholders
• Not keeping design documentation up-to-date
• No external playtesting

Before you continue reading, I suggest you take a look at what Adriaan said about these topics. I will not repeat everything he wrote, but rather focus on some aspects and add my own thoughts on why these pitfalls occur and how they can be avoided. Also, I arranged the order a bit so they fit my story better.

Entering production without something fun

Adriaan states that games that are not already fun before they enter production, will struggle to become fun during that stage. I think this is the most important pitfall of them all. If not for the primary reason of knowing that people will want to play your game because it is fun, then for all the secondary effects on the development process Adriaan mentions, specifically those regarding to the lack of a unified vision. Of course, creating that fun experience is the hardest task for a game designer and putting a time constraint on that creates the risk of stepping into this pitfall. The problem is, if you don’t, many people of other disciplines might end up having to wait, delaying the project. But isn’t that a risk worth taking, if the result is a cool game you can actually sell? I mean, if you can’t prove a game is going to be fun, you shouldn’t be making it in the first place.

Start big, end up small

The project’s scope is indeed usually bigger at the start than it is at the end. Especially during school projects, I noticed that people had the tendency to just put all the cool ideas in there, increasing the game’s size to unrealistic proportions. There’s nothing wrong with being ambitious, and coming up with cool features can be very motivating, but not if you’re going to end up having to remove have your game. Contrary to what Adriaan says, I think you should start big. It’s the creative director or lead designer’s job to prioritize and to set a clear starting point. That should be that ‘something fun’ as mentioned above, supported by a scope document describing a game that is up to par with the competition. If your design is modular and you have tech to match, you might not end up removing half your game. You could be adding cool stuff everybody was motivated to work towards. That is, of course, if time and budget wouldn’t put a stop to that.

Starting too late with playtesting

I can not stress this enough. The first thing I got to do when I started at W!Games, was set up regular user tests. Weekly, eventually. This indeed led to a more stable version and better end results, as Adriaan says and no one would argue, but I would like to put the focus on the very start of the project. The most common excuse I’ve heard is that there is nothing to test yet. Not true. There is always something to test, even if it’s just presenting your concepts to a focus group, or playing paper prototypes. Early playtesting is key to creating that ‘something fun’, with and for people that will buy your game. How do you know  for sure that your game is fun if the only ones who believe that are the ones making it? Another excuse is that there are too many things not done yet, assuming that the obvious will obscure any useful results. Also not true. Many testers will also look through the obvious, either because they know it’s not done or because they don’t care, and go right to the core of your game. And even if they don’t, I’m sure they’ll have something useful to say about the things that aren’t done yet. So, start early (if you have something to show your colleagues, you have something to test) and don’t stop until you have a Master build.

Peer reviews not taken seriously

I know the feeling of being too absorbed in your own work to see what’s going on with the rest of the game. That’s why it’s a good thing that most of my fellow designers notify me and others whenever they’ve made good progress or just have something cool to show. I try to do that as well, because I respect my colleagues and appreciate their input. If you’re not doing user tests, at least take your colleagues seriously. They’ve been hired for a reason, they play games, they know stuff. Put your ego aside and ask for reviews regularly if they’re not part of the development process already (they should be), both from your equals and superiors. You’re making a game together, so if they have ideas on how to improve it, you should listen. You might even become a better designer yourself.

No external playtesting

The examples Adriaan gives might seem funny, but he is absolutely right. Of course you assume that, as the greatest designer that ever lived, your design implementation works. Maybe it does, but after working on it for some time, you get used to it and lose the fresh view of a player new to your game. By bringing in external testers, with varying experience and characteristics but still somehow in your target audience, you get so many more and diverse views on your game. Maybe they’re not the observations of a professional designer, but they don’t need to be. You can get those using peer reviews, but what you need here is feedback on how actual gamers perceive and interact with your game. You need to test things like difficulty and pacing ‘in the wild’. The more data you have, the more you can distill from that. Your testers are not making your game and you’re still calling the shots. If you end up not using anything or just getting confirmation, that’s useful as well. And there’s another use for it I experienced first hand. Ever had to convince other people, other disciplines, that changes needed to be made to improve the game, without getting through? If your external testers come to the same conclusion, confront your colleagues with those results. User testing is not just for mechanics, interface or controls, it’s for your whole game. That means art and sound as well, even to see if your tech holds up.

Not enough games played

I agree strongly with Adriaan that especially designers should have played and continue to play a lot of games. You can actually see what works and what doesn’t, honing your design intuition and allowing you to give examples when necessary. Varied examples, preferably. I strongly dislike people that always refer to the same game or same developer when trying to make a point. Carefully noting all the factors involved in a design issue and knowing what game to learn from, both good or bad, is a very useful and required skill for a designer. You should be able to communicate all that verbally or on paper, but playing those games with the team is a good way to easily demonstrate what you’re talking about. I try to play as many games in as many genres as I can and I notice how I benefit from that in my daily job. If designers don’t have adequate experience playing games, you risk ending up reinventing the wheel or stepping into pitfalls that could have been avoided. Not only does a lot of gaming help you with specific design solutions, it also gives you a better view of the current market and your direct competition. In my case, I consider myself to be the target audience for most projects I work on, which helps a great deal in setting guidelines for my design work.

Too much importance on design documentation

Adriaan is talking about the start of the project here. The focus should be on trying out new ideas and proving a core mechanic, not on fleshing out an entire game on paper. It’s extremely unlikely that a designer will indeed get it completely right the first time, just by sitting in an ivory tower and crunching out a purely theoretical design document. As Adriaan states, doing and experimenting will not only prove or disprove your ideas, it can also lead to new ones and to what he calls ‘happy accidents’. That’s a pretty funny term. What he means by that, is that you may find your ‘something fun’ in something you didn’t design on purpose. As a designer, you should know what emergent gameplay is. Maybe it will pop up in your prototypes and if it’s cool, you’re still able to alter your design to better facilitate it. Setting up and maintaining design documentation is of course a good thing, especially when the team and the project get bigger, but that’s just for reference and should be based on experience rather than assumptions. Base your documentation on the first things you make, not the other way around.

Not keeping design documentation up-to-date

As mentioned above, design documentation should be usable as a reference. It communicates to every team member how things are expected to work and how the game will turn out. People losing faith in it is something you just can’t afford. If that happens, a lot of time has gone to waste and it will cost you even more. First because you’re going to have to catch up, second because people are going to ask you to explain it to them in person. Of course, it’s always a good idea to go through a new part of the design documentation with the people involved, so you know they understand and they know where to find the information they need and have a good starting point. But the game will develop and change, so the documentation will have to lead the way but follow as well. When deadlines are tight, updating documentation usually loses out to actually making the game and that’s when things could go wrong. Time should be alloted to work on proper and recent documentation, because what’s even worse than people not using it, is people using outdated information to build the wrong thing. To make it easier on yourself, just include the minimum information you need to eliminate any room for interpretation, using visuals and bullet points rather than walls of text. Leave out unnecessary details, like your views on how your design should be implemented technically. You’ll have less data to maintain and leave some much appreciated freedom for your colleagues. If how it should work is clear, leave the rest to them.

Not taking advantage of placeholders

I don’t have anything to add to Adriaan’s point here, other than how to avoid this pitfall. Designers just need certain ingredients to be able to test their theories and create initial implementations of their design. The more they can do on their own to iterate on certain parts of the game, the better. You don’t need finished models and animations to see if a certain mechanic works, as long as it has the ability to do what it has to do within the game. Sometimes that might indeed require specific visuals, possibly because the way something looks is part of the mechanic or the abilities of an object. So if artists won’t provide placeholders, either because they refuse or there isn’t any time, get the tools and learn the skills to do it yourself. You can also shop for something useful within all the assets that are already available.

Wrapping up: my own two cents

Adriaan’s list of pitfalls is quite extensive and useful for any game developer, not just designers. He covered pretty much all the pitfalls I’ve experienced and know about myself, except for one. I’m not surprised Adriaan didn’t mention it, because he probably hasn’t come across it yet and it’s not something school projects focus on. If you’ve read my comments carefully, you might be able to guess what it is. I’ve mentioned selling your game and your target audience a couple of times, so I would like to sign off with a pitfall specifically about that. And I must say that it’s getting more dangerous every day to step into this one.

Selling your game is just as important as making it

The game development process is very much goal oriented. At the end of the schedule, the game needs to be finished and shipped. But nowadays it’s not sufficient anymore to just put your game out there and hope for the best. Of course, quality will get you a long way and should always be a requirement for the game you’re making. But there’s so much more you can do to possibly increase awareness and sales, way before the game is even finished. Exposure is key. The more people know about your game before it comes out and know that it’s awesome, the more you will sell. How to get that exposure and fanbase is a whole different story, but the pitfall is to not account for this during the development process. By selling I don’t just mean getting people to make that transaction, I mean the entire process of them wanting and playing your game. There’s more than enough material you can use to get out there, start a community, and to get and keep people excited about your game and your studio. Your players are the key to success, not just the game. The more you involve them in the conversation, the more they will reward you. While it’s only logical to focus on production, with schedules and budgets and all, that conversation needs to be an integral part of the development process. Ignore your players, and you might have an even bigger challenge than delivering a game.

Although I was okay with the way my portfolio looked before, it was a little bit cluttered and maybe contained too much information. This made it harder than necessary to find and get to what a game designer’s portfolio should be all about: the games! So now there’s this convenient list of all my projects on the left side of every page. I also made sure you always have access to my contact details.

Another thing I wanted to focus on is my blog. I admit, it wasn’t updated for a long time, but that’s partly because of the way it was integrated into my portfolio prior to this complete overhaul. It was tucked away, and because I was new to blogging there was a lot of content that shouldn’t have been there in the first place. So hopefully, with a more prominent position and the lessons learned, I can give and maintain a boost to my blog. I saved all the content I wrote before, some of it will find its way here sooner or later.

So what didn’t make the cut? Well, at first I wanted my portfolio to also include my web design projects, but I found out that was exactly the reason why it all became too complicated and broad. Also, I quit making websites professionally a while ago and only do the occasional job. As I have more work and possible clients than I want to handle at any one time, I figured it wouldn’t be necessary to promote my web design abilities in my portfolio in order to attract new projects. And more importantly, my personal focus is on game design. Another thing that I left out is my game writing. I wrote hundreds of reviews, walkthroughs and other articles of which many were published, but this portfolio is not aimed at game journalism so I decided to leave all of it out. You can still find a little bit on both topics on the About page though.

Although this website is now officially online again, I still have some things to take care of. Some projects need additional visuals and downloadable assets, maybe there are other projects I did that are worth mentioning. For my blog, of course I need to get posting and I also want to look into trackbacks and tweetbacks for the comment section. But as this blog is not well known, it will probably take a while before I get the first regular comment. You can be the first!

When working on a game in school projects, you have an enormous amount of freedom. Unless it’s specified within the assignment, you choose an engine, a platform and methodology yourself. Nobody stresses about the details. But as soon as you start working as a professional designer on commercial titles, precisely those smallest details will be the subject of rigorous scrutiny.

Free play

All of a sudden you’re not working on a game that you can create in your own image anymore and will work on an average PC. Now you’re building a product that’s going to be released on one or more carefully constructed, very specific platforms. This means that you need to develop based on the capabilities and characteristics of those consoles. As a designer, fortunately you don’t need to be directly concerned with the technical capacity or graphical power of, for example, a PS3, but that doesn’t mean you can do what you want. A big part of the time I spent on Greed Corp, I’ve been working on studying and complying to guidelines set up by the platform holders: the so called Technical Certification Requirements.

Mass Effect

Sony, Microsoft and Nintendo all have their own names for this, but it comes down to the same thing. So what is in those requirements? Of course, it’s documentation is confidential, so I’ll give an example for a console I currently have nothing to do with: the Wii. That notice about putting on your wrist strap, so that your television doesn’t get hurt, needs to be there for a certain amount of time. Even whether you’re allowed to dismiss that notice or not, and if so with what buttons, is dictated by Nintendo. Another, obvious requirement, is how big your downloadable game is allowed to be in actual file size. Those are not really rules that concern my work specifically, but that’s different when platform holders make it mandatory for your game to include Achievements and Leaderboards, for example.

These requirements are not to be taken lightly, because the platform holder will just deny your game if they find enough that doesn’t adhere to their demands. The problem for smaller developers, who are working with a certain platform for the first time, is that this documentation can be quite extensive. I can imagine that bigger studios have people that work specifically on this, made it through the process multiple times and apparently get away with certain things because of their big name. The best example of this are the on-screen texts in Mass Effect 2, which are pretty much unreadable on old fashioned televisions, but Bioware got away with it.

Functional

Since the current generation of consoles, everything got a lot more extensive, because additional functionality like online gaming and user profiles all get their own set of rules. The most difficult requirements are the ones that influence the core of your game, the part you were already going to do or already needed. Additions like Achievements are fairly easy to include in the design, but to implement a flawless system for complicated matchmaking, like the one in Greed Corp, is quite a task. As a designer within a relatively small company, which publishes the game itself, this all falls on your plate. Often this means that you need to read quite a lot before you can become creative and problem solving. It’s even more annoying if it turns out your design doesn’t completely comply to the regulations. Especially if you think you came up with something better and just want to work on ‘real’ game design.

But I’m not complaining about these seemingly outrageous regulations made up by platform holders. On the contrary, because if there’s something I learned from scrutinizing all these TCRs, it’s that they’re there for a reason. They make sure there’s consistency between products on the same platform and that means that as a designer, you can take advantage of conventions gamers are familiar with. Also, it isn’t always about limitations, but also about a solid foundation and proven solutions. Once you’ve learned that lesson, TCRs will become part of your overall design workflow and it will become a challenge to make a single design that will cover as many platforms as possible, so you will succeed on all of them with the same implementation.

For the games industry, the second week of March was all about the Game Developers Conference. Although this biggest industry event in the world is always the stage for new stories and announcements, there was one message that dominated my Twitter feed and the usual gaming websites: the PlayStation Arc is now called PlayStation Move.

The future

Even after GDC, information and videos are hard to miss, with a comical note in the form of presentations from the future by Kevin Butler, so called vice president of everything at PlayStation. These promotional images are almost completely aimed at the player, at what this development ultimately means for the consumer. But I find it much more interesting to know what technology like Move and Microsoft’s Natal could mean to me as a designer. How can I use it in my games and as an inspiration for new ideas?

Hardcore

The Wii has mostly shown us that motion control can be used quite well for funny, small games, with a more serious implementation here and there. Now that two platform holders that usually attract a more hardcore audience heavily invest in this, I’m quite curious about the Socoms and Fables among the motion controlled games.

Not exactly those games, of course, but the prestigious projects that attract the already existing target audiences of Sony and Microsoft. Audiences that, in my opinion, have higher demands when it comes to functionality of hardware and its implementation, within games they would like to play. Not entirely coincidentally, both games I gave as an example are already in development. How Fable III will work with Natal exactly remains to be seen, but the fact that the controls of Socom 4 look very much like most Wii shooters slightly disappoints me.

Rule of thumb

I think the problem is that some developers, stimulated by publishers and platform holders for understandable reasons, try to force the technology into their game. Not as an alternative or improvement, but just because it seems to be the new standard.

I admit, whenever I see new footage or information on Move or Natal, I usually try to come up with ways of how our game Greed Corp could be played with it. The same goes for the game I’m currently working on. But I think that, as a designer, you shouldn’t wonder how your game is going to be played with this technology. So instead, I try to ask myself how the technology could be beneficial to my game. The rule of thumb should be that a game will be more fun and will play better with motion control. If not, you’re totally missing your goal as a designer and I would also just rather sit on a couch holding a controller myself.

24-year-old young lady please

Although I don’t see myself talking to a 12-year-old boy all day, I’m very much interested in really new experiences like Molyneux’s Milo. The idea itself is completely inspired by Natal, which by definition should make that the best way to play it. Just like some traditional games will not lend themselves well to motion control, not all products specifically designed for it will be more playable with a controller.

I’m looking forward to experimenting with Move and Natal, to see what capabilities are hiding behind the most logical applications. Hopefully this will lead to a couple of innovative concepts and product improvements. So there you are: eventually the success or failure of motion control in general lies with the designer, not with the manufacturer.