ETH GameLab – How not to do a game


First, let’s be clear! The ETH or the EPFL are not place to learn how to create a video-game. They are places where students become engineers. So when you have a course named “Game Programming Laboratory”, don’t ever think there is gonna be quality coming out of it. If you want some numbers, none of the game ever created during this course has ever been released on Steam, any consoles and any smartphones. So let’s look at the menu of the final game (the one given to the jury) I had the honor to be involved in:

BeastmakerEvolution 2015-05-23 10-08-43-97

If you recognize the background behind the image, yes, it is the typical background of a unity 3d skybox. I mean, seriously, 1080p is a default screen resolution, not 800×600. I guess it is a detail, but it is also a beginner mistake. The image should be fitting every screen resolution. I also don’t speak about the extreme loading time of 5 seconds. Console programmers knows that a so long loading time at the start of the game means no license. Okay, let’s see the game now:

BeastmakerEvolution 2015-05-23 10-08-06-56

Can you see what you have to do? Do you feel submerged by the amount of data shown on the screen? Let me explained it! Beast Maker Evolution is a card-based fighting game, where the players prepare their attacks three rounds in advance. You’re not convinced? Me neither… I guess I was not the game designer on this game. How stupid is it to play three rounds in advance. You completely lose the control, which is an important feeling in card game and in fighting game. All you do by playing three rounds in advance is playing randomly, even the play-testing showed it. Guess what the team did after the disastrous result of the play-testing… Nothing. Nothing was changed. I guess that is the engineer philosophy:

“Sire, we have a problem. We have done some tests on the structures for the new bridge. Unfortunately, it falls, it can hold more than one car.

— I guess it is too late. Let’s construct it anyway!”

Seriously! Even when I do a gamejam, at the end of the week-end, if something does not work during the play-testing, I try to find a solution, even in a rush. I guess two weeks is too short for the team (no, not my team, the team I was involved in, nuance).

Okay, I may be harsh, I guess it was their first time creating a game. The things I will still never forget is our first meeting to brainstorm the game. As I nice designer, I was trying to get everyone involved. The first hour of the meeting, we found two different ideas. The second hour, we tried to deepen one of them. And in ten minutes, they chose an other idea. I was pissed off from the beginning. I guess you should never listen the one who has experiences in game development. What a bad idea it could be!

So, the team started by this idea of having 3d model with different parts evolving during the different rounds, after playing with the cards. Sounds too ambitious for three months. Guess what I repeated over and over again: Impossible. The artist, who sort of took the lead of the project (and what a disastrous lead) insisted that 3d model would be easier for her than 2d animation. There is no universe in the entire multiverse where this is true. So I went in Hong Kong and at my return, we should have had a first protoype. I was motivated to work on it, even if it was not the best game ever. I would help as much as I can. But that demotivated me so much and really made me realize that I was involved with incompetent people. You want to see it? Here it is:

Unity 2015-05-23 10-40-45-14

After 2 months of production, all that was implemented by not one, but two programmers was something that I could implement in less than a day. I even showed it to my roommate, guess what he said: “This is not a game! They did it in two months?” When a non-programmer says something like this, you know that there is a problem with the team you’re involved with. I can write a whole book of the all the flaws the games have, that the team has, but now let’s look at the course:

The course is divided between different phases:
  • Part 1: Formal game proposal (3 weeks)
  • Part 2: Physical Prototype (1 week)
  • Part 3: Interim Report (4 weeks)
  • Part 4: Alpha Release (3 weeks)
  • Part 5:Playtesting (1 week)
  • Part 6: Public Presentation + Conclusion (2 weeks)

You read it well, each team has 4 weeks before they even touch a line of code. They also ask the ETH student to use a “technical innovation”. I found that completely unproductive in a game development context. If it was a hackathon with oculus rifts and leap motion controller why not, but when you have 3 months to make a game (which is a pretty short amount of time), where every two weeks or even more you ask for deliverable (which is way too much) and you ask for a technical innovation, then the ETH students are gonna defend crazy, too ambitious ideas. The Playtesting comes way too late. It should be put in the Interim Report or at last at the Alpha Release phase.

Also, a physical prototype? For a computer video-game? I like the idea, but to make it mandatory is a bit too much for me. How would you for instance make a physical prototype of Super Splash Fisticuffs, my shooting fighting platformer game where cat, owl, luchador and robot shoot themself out of a stage with water gun?

vlc 2015-04-20 23-41-00-74

Tell me how the core mechanic on a paper prototype can be as fun as in the computer video-game version. I guess it can’t. But Super Splash Fisticuffs is still a good game, and with a paper prototype maybe it would have been less fun to play. In this case, if it was my ETH project with ETH students, they would say: “We have to change the mechanic! We have to add other mechanic to make it more fun! Let’s make it a MMORPG! Let’s make it 3d, it will be more fun!”

The point I’m making is that ETH students are not game development students, they are completely disconnected of the reality of this area. The reality is that game development is versatile, iterative and needs constant adaptation. ETH are use to follow a set of homework, not to create something. If this course want to be the main course in Switzerland for the development of video-game, it should be more free (no damn restriction like “technical innovation”), should have clearly less homework (all this time could be put in making the game). But I guess no ETH student, nor ETH assistant will read this blog post. Because at the end, the ETH is still on the hill and it is still needed to climb it.

One thought on “ETH GameLab – How not to do a game

  1. Good to read a voice of critic. Though i agree with most of what you have said, i believe we had ample opportunities to make a good game, the one that could go on to an actual console release. I guess one of the teams – Evolution Party – had a crack at it too. That was a pretty good game. Yes academic institutions can be rigid with their own criteria of syllabus and course points to complete. But i believe they provide a good framework for you to improve on, dissent, make ruckus and create something good. At the end of the day we can’t put all the blame on an academic institution for our own frailties.

Leave a Reply

Your email address will not be published. Required fields are marked *