Game designer

|
My name is Adriaan de Jongh and I am a game designer. I recently graduated as a master student Game Design & Development at the Utrecht School of the Arts in the Netherlands. I like to sail, kitesurf and to play drums. |
|
Twitter
Linked-in
Email me : |
I graduated! Hooray! Lets bring that into perspective.
Four-and-a-half years ago I started at the Utrecht School of the Arts (or Hogeschool voor de Kunsten Utrecht – HKU – in Dutch). I was 16 years old when I got accepted for the course Game Design & Development and I was barely capable of doing anything. I recall I called myself an artist during those days, as my only skill was a bit of photoshop. Fellow students were a lot more mature than I was (they probably still are) and I had to fight to keep up. Maybe I was a bit too young when I started, but I made it through nevertheless. I was a bit less of the typical ‘student’, you could say.
I must say I can not recall all lectures and projects in those first two years, although I did take extensive notes during each and every one of them. I remember how I managed to fuck up my first exercise, the ‘perfect a4′ exercise, in which all you had to do was turn in a blank A4 with your name, a date, the lecturer’s name and some other data – I got the date wrong. I get the exercise now, though: it is about the experience of the paper. Just one person aced the test back then, I now understand why he did. Correct information is just part of the deal, feel is the rest.
I remember I learned how to make low-poly 3D models from Kent Kuné, who later became the most influential game designer in my career. I made a pirate-tricycle for his lessons which was pretty awesome. I remember programming Tic Tac Toe in C++ for this bare-footed programming lecturer, something I currently cannot reproduce. I remember interaction design and psychology lessons which were too theoretical to be of practical value. I remember this awesome level design workshop which my team and I nailed with a fantastic looking Team Fortress 2 level.
There were a few visionaries at the HKU too. These people taught me how to differentiate game mechanics from other parts of a game. And why ‘serious’ games should not be called that way (but rather applied games, because they should be fun).
But the biggest memory that remains is that I did not finish a single game in the first two years. I had not learned how to make games at all. I remember realizing that. It was pretty painful. But ending the two first years also marked the end of the theoretical side of the Game Design & Development course. Practical exercises were coming up!
What changed everything was my internship at W!games, now Vanguard Entertainment, where I worked on Gatling Gears for half a year as part of my third year internship. I learned very valuable lessons there which completely defined the designer I currently am. I learned to see challenges in tasks which I understood fully. For all my life I had been quitting on tasks after I figured out on how to do it. Thankfully my mentor René Derks recognized this problem and I took his advise with grace. I learned to separate emotions from design from lead game designer Chris Nengerman, who brilliantly stepped back from any discussion when it became a fierce discussion and went back to every person separately to calmly talk about it.
But most of all, I saw Kent Kuné building games in his spare time. He knew a bit how to script with the Unity3D game engine and was able to create any prototype he wanted. Every week, he would show me a new version of something. I was amazed, completely inspired to work with the Unity3D to build some of my own ideas. It was pretty tough in the beginning, but it was definitely a beginning! Kent showed me the importance of having your own tools and testing your own ideas. Games can only be fun when they can be played. I can not imagine what I would be doing now without this knowledge.
After my internship, I refined my scripting skills with the half-year student project Vogels!, which turned out to be pretty successful in terms of health games. I did not learn a lot from Vogels! in particular. Keeping it simple was the main message, but it was during this project that I started to think about the meaning of experience in the context of games. That my games were being played by real people with real thoughts and experiencing their own thing. And that everything they did wrong was my fault. An important realisation, especially when you want to grow as a game designer.
Although making games for handicapped people felt immensely good, I wanted to focus more on entertaining games. My fourth year’s project, The Jelly Reef, was a great introduction to exactly that, but surprisingly taught me more about managing other people than about game design. It taught me about intrinsic motivation of myself and others, leaving others with responsibility, communication and – most of all – I learned about working hard the hard way.
It was during this project I had my so-called ‘burnout.’ I remember I worked on either the project or a project of my own every minute I was awake, for two straight weeks. My body literally stopped me from continuing like that. I have been learning how to deal with hyperventilation, stress and adrenaline ever since. It’s coming along slowly, but my struggle is becoming less.
The Jelly Reef was a great product of the extra miles some of us took to make the game the way it is. All of the team deserves credit for that. Some people in the team really did prove themselves and these are very likely the people I will be working with even after graduation.
And then, of course, my graduation project. The HKU offers a special program, that I still fail to understand, in which you stick 3 more months onto your Bachelor project plus a bigger paper (a so-called supportive narrative) to make it a Master project. My supportive narrative turned out to be a good insight into my way of thinking as a designer: analyzing a problem, coming up with solutions, building those solutions, testing those solutions and then drawing a conclusion.
Right now, it is too early to reflect on the game I have been working on during my graduation project, Fingle. It is still not done, but it definitely will be soon, and a reflection can then be found on my blog. A full blown iPad game. My first commercial title. The first of many, I hope. I couldn’t have wished for a better ending at the HKU than to graduate with this game. It is a true piece of art, if I may say so myself. I can’t wait to tell you everything about it, but that has to wait for a bit longer, unfortunately!
And then, suddenly, I graduate.
Adriaan de Jongh,
Master of Arts in Design for Digital Cultures
Together with my friend Bojan Endrovski, I will be starting a game studio.
Hello world
It has been silent for quite a while on my blog. Nothing coincidental, I tell you! I’ve been increasingly busy with my graduation project and supportive narrative. And I moved and have no internet and my new place. Anyway.
For my project, I set out to make an iPad game that would explore interesting social interaction. This is a vision, meaning it basically means nothing at all without a more concrete idea. I started brainstorming and generating ideas and build a number of prototypes in Unity to test the ideas. As I am an official Apple Developer, I could try my ideas directly on the iPad. The following is a video I made right at the ver beginning of this project, showing how I can prototype on the iPad.
From all of the prototypes I build, the project quickly came down to 2 concepts and, after some more iteration and playtesting, 1 concept. I will get into this concept more specific in another article later.
I’m currently working together with Bojan Endrovski (http://furiouspixels.blogspot.com/), a very talented programmer with whom I worked with creating The Jelly Reef and who is currently building a full featured iOS engine. The concept I prototyped will be the first game built in his engine, which is quite exciting. So far, most of the core elements of the concept are implemented and running smoothly already. We have set up most of the pipeline and will go into full production anytime now.
Building this iPad game is quite exciting but also a big challenge. Not only is it our first iPad game, it is also our first commercial title, which means the responsibility is completely ours – if the game flops, it is our fault. We are convinced we can make a solid game out of the concept, but there are still a number of things we don’t have so much experience with, most of them aside from the game. We have some ideas – I’ll discuss them when the time comes!
Stay tuned for my next article! Exciting times!
I participated in this year’s Global Game Jam more with the role of programmer than a designer. Another chance to make an awesome game with a team, in 48 hours. Simply put, you move a small creature around and make sure he doesn’t get eaten. And you do that by letting him eat your fellow creatures. And entering his rear entrance. And eating him from the inside, after which he will explode. It’s crazy. You can download and play it at the end of this article!
But let me put emphasis on ‘chance’ in ‘another chance to make an awesome game’. Because you might as well be working 48 hours on a game that might not be as awesome as you would hope. And in my opinion, that is what happened to our team that weekend. We showed that we were truly capable of building a game, but the core idea of the game just didn’t show the potential of becoming an original or refreshing game. We were eager to build a game and we were certain that it was the course of creation that would make the game awesome, but that turned out to be a wrong assumption. That is the biggest lesson of my global game jam 2011.
As I mentioned, I do think we showed that we were fully capable of creating a game in the amount of time that was there. We prioritized well, we worked hard and had a pipeline all set up in just a matter of hours. We came really, really close to creating the game we had in mind. And big kudos to us for that!
What I think I personally did right this project was looking at the game from a user experience a lot more. This made me see a lot of usability issues, that we were -sort of- able to fix in the time we had, making the game actually playable and understandable for players without us having to say anything. Unfortunately, some bugs caused inconsistencies in the game, making it confusion for the player and painful for us creators to watch them struggle with it. But hey, we made a game in 48 hours, you can’t always have everything.
Maybe it was my experience with previous playtests too. I’ve seen people struggle with my previous games and that sure opens your eyes to some of the more standard mistakes and assumptions. Its hard to explain, I guess that is why they call it experience.
Enough talk. Play Bottom Feeders! Windows or Mac. Forgive me for its flaws.
After months of hard work, my team and I can proudly present to you, The Jelly Reef!
“The jellyfish, pink and green, need your help. Sit down around the Microsoft Surface and swipe the water with your fingers to guide the jellyfish away from harm. Save as many as you can to discover more dangerous locations, strong currents and more captured jellyfish.”
“[..] an entertaining game for the lobby in the building of the Dutch Game Garden, which would simultaneously introduce you to all the companies that reside in the building.”
www.thejellyreef.com – check it out!
For even the smallest project, I write reflection on the course of the project. Creating The Jelly Reef has been a completely new experience for me in many ways. Read on to see why.
Assignment interpretation
The assignment we were given was in conflict with itself, and that became more and more clear to us near the end of the project. We were making a fun game, but also a game that needed to introduce the different companies that resident in the Dutch Game Garden. In a hindsight, we did a good attempt trying to aim for both byproducts, but the final game has unfortunately suffered from it. The introduction of DGG residents feels like a completely separate entity, outside the fun of the game.
Two things we could have done to cope with this problem. First, if we would have been honest with ourselves regarding this problem, as this problem was hinted to us mid-project already, we could have looked for a different implementation. But the other thing that we could have done is to have the courage to talk about this problem with the client and negotiate about what he wanted us to make and what we wanted to make. Obviously, we wanted the game to be all about fun, the client wanted it to be all about the introduction. Did we fail miserably by starting with a game concept in which these two goals weren’t merged?
Development
Our programmers Jeroen, Bojan and Peter did a fantastic job. Being students, it is amazing what they managed to squeeze into 3 months of development time. And this is simply because of the effort they put into the project and all the extra time they spent from the beginning on, ‘instead’ of at the end of the project. The excellent communication between the design department and the development department resulted in a robust level editor that was designed to make it easy for us designers to create the game. All their time was well spent.
From my perspective, the technical development process was handled fantastically. They used iterative methods to make their own schedule, had a very down to earth todo list and stuck more or less to their plan. Their feature lock gave a good sense of how close we were getting to the end. Every feature in their code was well thought through and was always made with a designer or an artist watching over their back. Although they were still required to crunch in the last two weeks, I am absolutely sure that it was not caused by faulty development planning. Read on.
Graphics
Our artists Tim, Tim, Bas and Sandra have been working hard on every asset or level in the game. It looks fantastic, but getting there was a rough ride. Because of a few unfortunate events, I felt that half of the art team was not really ‘connected’ to the game, and by that I mean that sometimes the artists would create bits and pieces of the game without actually iterating on it or seeing it in action, placed in the game, before tagging it as final. This caused a tremendous workload for the development team at the end of the project, as we discovered that implementing the art assets required more features that we had built so far. But where we suffered most was coping with the feedback issues the game had. More on that later.
Feeling connected to the game is crucial and it is the role of each individual as well as every lead of the team to make sure every single person is working on the game and not on individual assets. Only by putting your hard work in a context can you judge its effectiveness. This is one of the most important lessons I have learned from this project.
But this problem did not just come from faulty personal development processes. More difficulties caused this. We did not have enough hands on building the game, putting placeholders and trying to implement all the cool stuff the art team had created. Three weeks before the deadline, our team was forced to split up because our local Surface table broke down. Also, during the project, my body started hyperventilating as a result of the rough time I was giving myself, and I was required to take a week off for my physical condition, leaving the rest of the team behind without the ‘game visionary’ that I tried to be. Unfortunately, our team was not able to cope with all of these difficulties entirely. It had a negative effect on the game and on the spare time of everyone of us.
Don’t get me wrong; the eight unique, multi-layered levels look absolutely amazing and the animations just make you want to touch the game. Kudos to each and every one of the art team.
Design
Overall, I was not satisfied with the design process that took place for the gameplay content that is in the game. The nine levels we have were also the nine levels we first came up with. Sherida and I started way too late with creating and thinking of levels and that was one of the reason why art was having a huge workload at the end of the project. We also did not playtest enough. There was always the raw fun of swiping the jellies and avoiding death, but I do not feel we came any further. Finding the right puzzles and seeking for fun situations were things I would have loved to do. In this perspective, I think the design department failed. Sure, the eventual game is fun, but we left that more to luck than to thoughts. I feel responsible.
Admittedly, for this project I spent more attention to the code department than the art department. Because of my previous experiences, I felt it was more easy for the development team to lose track of the overview than the art team… which is a pretty common mistake by many developers, under the name of ‘feature creep’. Although that seemed to be less the case for our programming team, I can remember a few specific moments where I could stop them from making more than what the game would require. I think that my focus on the code department is what made me ignorant for the workload of the art for the levels. If I would have noticed that sooner, we would have started creating levels earlier and much more of my idea of a good design process would have come true.
Let me note here that part of the reason we started so late on the levels was because of that hyperventilating week I took off, right when it was time to start working on the level design. As my role was crucial in the two-man design department, not much design happened in the week I had to rest. A lot can or can not happen in a week. That week would have made a difference!
Another thing that went wrong with creating The Jelly Reef was usability design. It started way too late and wasn’t recognized as visual design at first, requiring both a designer and an artist. Not having the right artist on location required insane communication skills from the design department which was more or less impossible. Visual artists iterating on words, can you imagine. It resulted in that 80/20 thing big shots often talk about: in our case, 80% of the user’s experience was created in the last 20% of our project time. People didn’t get it, we saw that too late and had to work very hard on the last moment to make people understand. And to be honest, even now usability could use a few iterations more.
As for motivation design, we had a pretty sweet model implemented into the game, but to be honest… we have no idea whether it is working too. As said before, we did not playtest early and enough.
Project Management
In total, It took us 4 weeks longer than expected to finish the game. On a 3 months project, that is a lot.
What project management meant to me this project was actually people management. I wanted everyone to achieve the best result for the sake of the project. I have always believed that it is the responsibility of the project coordinator to keep all the team members motivated, but this project I have found something that only every individual can do for himself; taking initiative, showing discipline to iterate on your work and killing your darlings. In some rare cases I couldn’t help myself taking that impossible road of trying to help an inactive team member‚ its the feeling that you get when you are given a chance but there is nothing you can do to take it. But my actions to change the mentality of some of my team mates, maybe even their character, were and will always be unsuccessful.
Every department created and updated his own agenda, more or less based on their own workload. We never set milestones based on those assumptions, but I don’t think that has had a negative effect on the game. We did the best we could and we did not need to manage that.
Individual Reflection
As the project coordinator, I feel that most of the mistakes I made had to do with treating the different personalities in our team, expectations of team members and communication. It remains incredibly difficult to work in a team.
There have been moments that I wish I had been more honest and strict against one or two of my team members, but I have seen team coordinators doing that in other projects; it is not the kind of guy I want to be. I think I can be a hard worker, also trying to push the limits of others, but I will always try to keep the atmosphere friendly. I do not want to create games in a social environment where people are afraid to show me their weaknesses. I have seen this going wrong in enough student projects already. I rather deal with the downside, having a few demotivating people in your team and work hard with the rest.
Other Notes
This project I have seen the power of all-rounders. People who are not afraid of looking at difficulties that arise outside of their field of study. From my own perspective I think that I was able to create some very interesting levels because both the art and code team granted me great insight into their challenges and strengths. I saw multiple examples in our team that proved some people to be all-rounders and their effort was really what connected all the departments.
Am I overall satisfied? Yes, very! I’ve seen a lot of people playing the game, putting themselves in the dangerous world of the jellies – feeling good when they manage to save a few, face palming when they fail to do so. And the childen that played it – don’t get me started on that, It will get me all emotional!!! The Jelly Reef is not a finished product, but it sure shows its potential a hundred percent!

