I've always been intrigued by game development. The idea of experimenting with a bunch of novel game concepts and game technologies, building something truly your own, and then unleashing it for other people to enjoy is somehow inherently very compelling to me.
However, I'm yet to do anything notable in the area of game development. So far my own projects have been very modest at best, ranging from a simple worm game (Java applet link) and a pong clone to a game of life simulation (Java applet link), which hardly qualifies as a game in the first place.
I've also participated in two larger projects that had to do with game development. Both of them were university of Turku (a port city in Finland) project courses where we, the students, were tasked to design and build a game.
Neither of these project courses however resulted in an actual working game.
Now, a lot could be said about both of those courses in terms of what went wrong there, but a much more fruitful discourse can be given in the light of what was learned.
I shall go into more depth with this in another blog post, but to at least give you some idea of what was going on in the courses here's the combined lessons I learned from them:
Work does not equal the work process. You might think you're doing fine when you have a nice work process going on and when you can measure progress, but concentrating on executing this process alone does not necessarily yield the results you want. The project can still end up being late one day at a time. This lesson came to me when I was acting as the scrum master for the first time and was happily leading the project in a very waterfall like way step by step. I honestly did not see that one coming until the course was over. A huge lesson learned there.
The existence of a project leader is vital to a project's success. I believe this holds at least in the setting where our projects took place ie. when there are many (10+) students involved with no strict guidance. In the other course we did not have a designated project leader, which resulted in democratic voting (and arguments) to take place whenever there was something of importance to be decided. As you can probably guess this was not a very effective way to work. There are many other takeaways from the course but I think this one was one of the main lessons.
In March of this year an opportunity arose for me to take my game development interest to another level altogether. As we were discussing with the teacher ways to make the course better for the next Spring, we suggested having a practical introductory course in Autumn where the students could get a base level understanding on game development before the actual project course took place.
The idea was immediately very compelling to the teacher and we then set out to plan what sorts of things should be discussed in it. I began listing things with a friend that we would have liked to have known before this year's course:
“Basic understanding on graphics engines would kind of be useful, right?”
“Yup, definitely”
“Also the scene graph, graphics primitives, and linear algebra should be familiar to those steeped in code because those are likely to be used often.”
“Oh, and of course the coders should have practical understanding on the chosen game development technology itself before the project course.”
...
After we were done with the “laundry” list the teacher asked my friend if he would be interested in giving a course that covered such topics in the coming Spring. My friend agreed and then after a while he asked me whether I would be interested in participating in the course as a teacher myself.
“Well, I don't understand much about those topics at the moment and I've never been a teacher myself. I am very willing to learn however and I do believe that I can teach what I've learned to other people. So, yeah I can agree to be the co-teacher if such a course will take place. :)”
That was one of those moments that it just made a lot of sense to say yes even though I had every reason to say no as well.
The funny thing with promises something like that is that it's a kind of spoken contract which you will want to honour. You put yourself in such a bind where you're supposed to do something that you would like to do anyway. This creates sort of an external motivator for you to deliver what you signed up for and that is a very good thing indeed.
So now, after studying practical (meaning coding etc.) game development and game engine architecture for the whole summer 2-3 days per week I can proudly say that I've acquired knowledge that I believe is worth passing on to fellow students during this Autumn's introductory course at university of Turku in Finland.
In some later post(s) I shall discuss the particularities of the game technologies we chose to utilize and the architectural aspects of the game engine we've built for the purpose of creating a scifi first-person adventure game.
No comments:
Post a Comment