Looking back at 5 years of a game development education. In this post I will lead you through my first year and my experiences.
original post can be found here.
As I am busy with my graduation, I found my mind wandering off lately thinking about the past and the choices I have made. From the moment I decided I wanted to follow a game development course until right now, where I am doing my graduation at a small company called Digital Dreams to get my bachelor degree from a game development course.
With these posts I want to give people an insight on how things went for me from start to finish and my opinion on the different aspects I encountered during this journey.
Do keep in mind that the games industry is an ever evolving industry where new strategies, technology and principles get introduced or evolved and so does this game development course. The course as it is today, is not the same in every way as it was when I started.
It was all about to start and I was very excited, I was going to start learning how to make games so what's not to be excited about?! At this point I was pretty confident because well.. I helped making a 3D engine (even though I had a hard time) and I worked through the summer to get my skill up some more. I do have to note that this was 5 years ago and some details are a bit vague, but I'm sure most of it will come back as I write!
As I mentioned in the previous post, IGAD was split up in 2 variations when I decided to enroll, programming and visual arts. I don't think I have to explain what that means. They were also busy setting up a different variation that is now known as Indie Game Development (or IGD in short), this course had a bit of a slow start where it lacked some proper definition (in my opinion), but it is essentially a more generalized course. Where the programming and visual arts variation go more in depth in their topics, IGD gives you a bit of both worlds. A few years ago, they also introduced a brand new variation: Design and Production (or D & P in short) . As you might have guessed, this variation emphasizes on game design and the business/production side of games.
Before D & P was introduced, game design was part of a shared curriculum between the programmers and the artists. Personally, I did not really mind as I was still a creative person and I thought that design was a very interesting topic. During the first year, we were taught Ludology and even though I personally liked it, plenty of my fellow programmers did not and well, I couldn't really blame them that much. The ones that did not like it were the programmers that just wanted to program. Get told what to do and do what they're good at.
Personally, I found that if I could think in the same perspective as the designer, implementation of certain functionality would probably require less tuning and tweaking because you might just understand what the designer is after when he can't explain it properly or simply understand it a little better. Of course in time and with more experience, this will become less and less of an issue when the programmer and designer gain more knowledge. Next to that, I simply enjoyed being dragged into the discussion or brainstorms that were aimed at design even if I was not able to bring something useful to the table. Not only just for the sake of letting them hear my voice on the matter, most beginning designers start with a "how hard can it be" attitude, and I would gladly explain just how hard their idea was. The best encounter I had was the "Yeah well, a friend of mine is a programmer and he says it's doable" and then I simply explain that his friend is probably right, but the scope simply doesn't fit within the time limit and the combined experience of the team.
During this period we were taught how to make a concept document with some given constraints. We were given a theme (Crabs) and with that theme we had to make a board game. There was a catch: it had to be integrated. That meant that we couldn't just do whatever we wanted, we had to obey to the rules of the crabs so to say. For example, we couldn't just make the game take place in a dessert, as crabs don't live there (or maybe they do, but then we had to back that up and still make a game about it) or make crabs suddenly get wings so they could fly. We had to study crabs and their behavior and apply that to our concept.
I wouldn't be me if I didn't search for something that wasn't "ye olde" crab you can find at the beach or something more common. I initially searched for crabs that were living in the desert or something and I did find something, but it all lead to dead ends and I didn't find enough information to make a fitting game concept about it. On my search I did find something else interesting though: the Jamaican Bromeliad Crab! This little guy had some interesting things I could use, so I did!
The block after that, we were given the concept document of another person and as a team of 2, we had to make the concept into a full fledged design. This could mean that you got another persons master piece that explained everything perfectly or something you would break your head over, trying to figure out what that person was on when writing. Luckily for us, we had a rather clear concept! I can't really remember all the details of that particular concept, but I do remember that we made it in the same style as the Labyrinth board game.
The third block was about interface design and it was given by a new teacher and well.. I have to admit that I didn't really like it and that's all I can (and probably want to) remember. I think the main problem I had with this course was that it was largely not applied to Games. Interface design is a broad topic that doesn't necessarily only applies to games, but to software in general or even hardware. It had some interesting topics as to why some things were considered good or bad, but the whole topic was a bit dull. I know the teacher was trying her best to make such a boring topic more interesting, but to me (and most others) it was just not something I generally liked. This has been addressed to the teacher as well, and she did her best to apply it more to video games for us, but it was already a bit too late.
Lastly, we were introduced to QA. Every team had to play a game and report bugs about it. I thought it was a meaningful learning experience. You had to pick a game (not sure if we had a list or not), play through it and submit any bugs you would find in a tool called Mantis bug tracker. As a programmer, this made me realize how hard it can be sometimes to describe a bug in such a (meaningful) way so it is useful for the producing team to fix it.
The team I was in was somewhat lucky though, we were able to do the QA of a promising game that was being developed at our school by second year students. They were in a polishing state and still had plenty of bugs laying around!
I don't think I have mentioned it, or if it was obvious, but IGAD is an international course and is being taught in English. So among the more related course, we were also taught English. Most of the people already knew English because of previous education and at the start we were given a test to see our capability of speaking proper English, those who passed we exempted and didn't have to follow it anymore. I can speak English and I can make myself perfectly clear in English, but due to the fact that it was a little more then 5 years ago that I had any lessons in English and my written grammar, or at least the theory behind it, was rather poor, I was not exempted.
As with most educations, you start the year with plenty of people and IGAD was no exception. With the English test plenty of people were exempted and so the class became pretty small and personal and that's a good thing because this way there was more room for individual guidance. One thing I also liked was that the teacher tried her best to keep it all applied to game development, the fact that she also had classes for other courses at the NHTV and wasn't really a person that (had) worked in the games industry like the other teachers, made it of course rather hard to keep it technical. Instead, the focus was set to communication towards studios. Think of application letters and resumes. This was during our first block (in case you don't know how this education system works, there are 4 blocks in a year with different classes), the second block was more general, but the nice teacher made up for that.
We were only given English classes the first 2 blocks, which I didn't really mind. It was nice to have a refresher, but I didn't want a full year of that.
The other half of the year we were given more production related classes. During the third block the emphasis was being laid on project management: Team skills, the process of game development, task scheduling and so on. The timing of this class was perfect because it was right after the first half year of GameLab (it's half a year, one day a week that simulates a working environment where you make a game. I will get into this later). Because no one really had any real experience, a lot of things went wrong during this GameLab and with this course, we were basically told why and how it went wrong. The fitting assignment of making a post mortem about this made you reflect back with the knowledge you now (hopefully) had!
The last block was a more zoomed out view on the previous class that focused more on the different business models, licensing, outsourcing and whatnot. In all this was probably more suited for producers, but it was nice to take a look into how it all worked (nothing in detail though) at the business side of things.
Something else that was mostly useful was the GTF course, which stood for something along the line of Game Technology Fundamentals. During our first block, we pretty much got lectured in some game development related terminology, which wasn't bad at all. Everything was explained perfectly fine and we had to do some research on specific topics so it wouldn't be just sitting and listening what everything meant. I can't recall every topic, but as it was a shared course between the artists and the programmers, it were terms that would be important to know from both sides.
During the second block programmers would do something art related en artists would do something programming related. This was, in my opinion, a very essential class due to the fact that we got to know how models were ideally set up/made and could properly communicate what could be wrong to the artists should errors arise! Also some terminology would be more clear so day to day communication between artists and programmers would be less troublesome. From the other side, the artist would make a small game in Flash/Actionscript to see that some things take time to implement properly.
The third block was supposed to be an extension of the previous one, but more focusing on the technical tool-chain from art to game engine. This was probably one of the most useless classes I had. Not really due to the intention, but simply because we could get away with loading a model into an existing engine and be done with it! In the end I got a model to load in the Ogre 3D engine, which isn't the greatest achievement when looking back at it.
The last block was about audio, which was alright, but also not really applied or directly useful (to me at least). It was more about how sound works and more of use to people actually making audio. I don't remember a lot, but thinking back this course might have been useful to audio engineers. I think due to the fact that this course was given in the first year and people generally don't really know what to specialize in yet, it wasn't as useful as it could be, but also because it was more focused on making the audio, it wasn't as valuable to programmers as it could be, or to artists for that matter.
To prevent this post from becoming too long, I have split it up in 2 sections where in this one I focused on the more non programming related courses. The next post will follow soon as there is more to be told about my first year! It will be more programming oriented and about GameLab.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
